Can't use https

Greetings,
I can't seem to get https working. Http works fine though. Below is my server.yml file. I have key.pem and cert.pm configured.
I running kubuntu 23.10 and I'm using systemd to control the service. The config below works just fine with http. But if i comment the listen-http line and uncomment the next 3 lines, I get errors when I restart the service.
# ntfy server config file
# server:
#   listen:
#     - port: 48800
#       protocol: http
#     - port: 44300
#       protocol: https
#       cert: /home/iomari/ssl-certificate/ntfy.csr
#       key: /home/iomari/ssl-certificate/ntfy.key
#
# Please refer to the documentation at https://ntfy.sh/docs/config/ for details.
# All options also support underscores (_) instead of dashes (-) to comply with the YAML spec.

# Public facing base URL of the service (e.g. https://ntfy.sh or https://ntfy.example.com)
#
# This setting is required for any of the following features:
# - attachments (to return a download URL)
# - e-mail sending (for the topic URL in the email footer)
# - iOS push notifications for self-hosted servers (to calculate the Firebase poll_request topic)
# - Matrix Push Gateway (to validate that the pushkey is correct)
#
base-url : "https://<IP_ADDRESS>"

# Listen address for the HTTP & HTTPS web server. If "listen-https" is set, you must also
# set "key-file" and "cert-file". Format: [<ip>]:<port>, e.g. "<IP_ADDRESS>:8080".
#
# To listen on all interfaces, you may omit the IP address, e.g. ":443".
# To disable HTTP, set "listen-http" to "-".
#
listen-http: ":48880"
# listen-https: ":443"
# key-file: /root/ssl-certificate/key.pem
# cert-file: /root/ssl-certificate/cert.pem

# server:
#   listen:
#     - port: 48800
#       protocol: http
#     - port: 44300
#       protocol: https
#       cert: /home/iomari/ssl-certificate/ntfy.csr
#       key: /home/iomari/ssl-certificate/ntfy.key

# Listen on a Unix socket, e.g. /var/lib/ntfy/ntfy.sock
# This can be useful to avoid port issues on local systems, and to simplify permissions.
#
# listen-unix: <socket-path>
# listen-unix-mode: <linux permissions, e.g. 0700>

# Path to the private key & cert file for the HTTPS web server. Not used if "listen-https" is not set.
#
# key-file: <filename>
# cert-file: <filename>

# If set, also publish messages to a Firebase Cloud Messaging (FCM) topic for your app.
# This is optional and only required to save battery when using the Android app.
#
# firebase-key-file: <filename>

# If "cache-file" is set, messages are cached in a local SQLite database instead of only in-memory.
# This allows for service restarts without losing messages in support of the since= parameter.
#
# The "cache-duration" parameter defines the duration for which messages will be buffered
# before they are deleted. This is required to support the "since=..." and "poll=1" parameter.
# To disable the cache entirely (on-disk/in-memory), set "cache-duration" to 0.
# The cache file is created automatically, provided that the correct permissions are set.
#
# The "cache-startup-queries" parameter allows you to run commands when the database is initialized,
# e.g. to enable WAL mode (see https://phiresky.github.io/blog/2020/sqlite-performance-tuning/)).
# Example:
#    cache-startup-queries: |
#       pragma journal_mode = WAL;
#       pragma synchronous = normal;
#       pragma temp_store = memory;
#       pragma busy_timeout = 15000;
#       vacuum;
#
# The "cache-batch-size" and "cache-batch-timeout" parameter allow enabling async batch writing
# of messages. If set, messages will be queued and written to the database in batches of the given
# size, or after the given timeout. This is only required for high volume servers.
#
# Debian/RPM package users:
#   Use /var/cache/ntfy/cache.db as cache file to avoid permission issues. The package
#   creates this folder for you.
#
# Check your permissions:
#   If you are running ntfy with systemd, make sure this cache file is owned by the
#   ntfy user and group by running: chown ntfy.ntfy <filename>.
#
# cache-file: <filename>
# cache-duration: "12h"
# cache-startup-queries:
# cache-batch-size: 0
# cache-batch-timeout: "0ms"

# If set, access to the ntfy server and API can be controlled on a granular level using
# the 'ntfy user' and 'ntfy access' commands. See the --help pages for details, or check the docs.
#
# - auth-file is the SQLite user/access database; it is created automatically if it doesn't already exist
# - auth-default-access defines the default/fallback access if no access control entry is found; it can be
#   set to "read-write" (default), "read-only", "write-only" or "deny-all".
# - auth-startup-queries allows you to run commands when the database is initialized, e.g. to enable
#   WAL mode. This is similar to cache-startup-queries. See above for details.
#
# Debian/RPM package users:
#   Use /var/lib/ntfy/user.db as user database to avoid permission issues. The package
#   creates this folder for you.
#
# Check your permissions:
#   If you are running ntfy with systemd, make sure this user database file is owned by the
#   ntfy user and group by running: chown ntfy.ntfy <filename>.
#
# auth-file: <filename>
# auth-default-access: "read-write"
# auth-startup-queries:

# If set, the X-Forwarded-For header is used to determine the visitor IP address
# instead of the remote address of the connection.
#
# WARNING: If you are behind a proxy, you must set this, otherwise all visitors are rate limited
#          as if they are one.
#
# behind-proxy: false

# If enabled, clients can attach files to notifications as attachments. Minimum settings to enable attachments
# are "attachment-cache-dir" and "base-url".
#
# - attachment-cache-dir is the cache directory for attached files
# - attachment-total-size-limit is the limit of the on-disk attachment cache directory (total size)
# - attachment-file-size-limit is the per-file attachment size limit (e.g. 300k, 2M, 100M)
# - attachment-expiry-duration is the duration after which uploaded attachments will be deleted (e.g. 3h, 20h)
#
# attachment-cache-dir:
# attachment-total-size-limit: "5G"
# attachment-file-size-limit: "15M"
# attachment-expiry-duration: "3h"

# If enabled, allow outgoing e-mail notifications via the 'X-Email' header. If this header is set,
# messages will additionally be sent out as e-mail using an external SMTP server.
#
# As of today, only SMTP servers with plain text auth (or no auth at all), and STARTLS are supported.
# Please also refer to the rate limiting settings below (visitor-email-limit-burst & visitor-email-limit-burst).
#
# - smtp-sender-addr is the hostname:port of the SMTP server
# - smtp-sender-from is the e-mail address of the sender
# - smtp-sender-user/smtp-sender-pass are the username and password of the SMTP user (leave blank for no auth)
#
# smtp-sender-addr:
# smtp-sender-from:
# smtp-sender-user:
# smtp-sender-pass:

# If enabled, ntfy will launch a lightweight SMTP server for incoming messages. Once configured, users can send
# emails to a topic e-mail address to publish messages to a topic.
#
# - smtp-server-listen defines the IP address and port the SMTP server will listen on, e.g. :25 or <IP_ADDRESS>:25
# - smtp-server-domain is the e-mail domain, e.g. ntfy.sh
# - smtp-server-addr-prefix is an optional prefix for the e-mail addresses to prevent spam. If set to "ntfy-",
#   for instance, only e-mails to<EMAIL_ADDRESS>will be accepted. If this is not set, all emails to
#<EMAIL_ADDRESS>will be accepted (which may obviously be a spam problem).
#
# smtp-server-listen:
# smtp-server-domain:
# smtp-server-addr-prefix:

# Web Push support (background notifications for browsers)
#
# If enabled, allows ntfy to receive push notifications, even when the ntfy web app is closed. When enabled, users
# can enable background notifications in the web app. Once enabled, ntfy will forward published messages to the push
# endpoint, which will then forward it to the browser.
#
# You must configure web-push-public/private key, web-push-file, and web-push-email-address below to enable Web Push.
# Run "ntfy webpush keys" to generate the keys.
#
# - web-push-public-key is the generated VAPID public key, e.g. AA1234BBCCddvveekaabcdfqwertyuiopasdfghjklzxcvbnm1234567890
# - web-push-private-key is the generated VAPID private key, e.g. AA2BB1234567890abcdefzxcvbnm1234567890
# - web-push-file is a database file to keep track of browser subscription endpoints, e.g. `/var/cache/ntfy/webpush.db`
# - web-push-email-address is the admin email address send to the push provider, e.g<EMAIL_ADDRESS># - web-push-startup-queries is an optional list of queries to run on startup`
#
# web-push-public-key:
# web-push-private-key:
# web-push-file:
# web-push-email-address:
# web-push-startup-queries:

# If enabled, ntfy can perform voice calls via Twilio via the "X-Call" header.
#
# - twilio-account is the Twilio account SID, e.g. AC12345beefbeef67890beefbeef122586
# - twilio-auth-token is the Twilio auth token, e.g. affebeef258625862586258625862586
# - twilio-phone-number is the outgoing phone number you purchased, e.g. +18775132586
# - twilio-verify-service is the Twilio Verify service SID, e.g. VA12345beefbeef67890beefbeef122586
#
# twilio-account:
# twilio-auth-token:
# twilio-phone-number:
# twilio-verify-service:

# Interval in which keepalive messages are sent to the client. This is to prevent
# intermediaries closing the connection for inactivity.
#
# Note that the Android app has a hardcoded timeout at 77s, so it should be less than that.
#
# keepalive-interval: "45s"

# Interval in which the manager prunes old messages, deletes topics
# and prints the stats.
#
# manager-interval: "1m"

# Defines topic names that are not allowed, because they are otherwise used. There are a few default topics
# that cannot be used (e.g. app, account, settings, ...). To extend the default list, define them here.
#
# Example:
#   disallowed-topics:
#     - about
#     - pricing
#     - contact
#
# disallowed-topics:

# Defines the root path of the web app, or disables the web app entirely.
#
# Can be any simple path, e.g. "/", "/app", or "/ntfy". For backwards-compatibility reasons,
# the values "app" (maps to "/"), "home" (maps to "/app"), or "disable" (maps to "") to disable
# the web app entirely.
#
# web-root: /

# Various feature flags used to control the web app, and API access, mainly around user and
# account management.
#
# - enable-signup allows users to sign up via the web app, or API
# - enable-login allows users to log in via the web app, or API
# - enable-reservations allows users to reserve topics (if their tier allows it)
#
# enable-signup: false
# enable-login: false
# enable-reservations: false

# Server URL of a Firebase/APNS-connected ntfy server (likely "https://ntfy.sh").
#
# iOS users:
#   If you use the iOS ntfy app, you MUST configure this to receive timely notifications. You'll like want this:
#   upstream-base-url: "https://ntfy.sh"
#
# If set, all incoming messages will publish a "poll_request" message to the configured upstream server, containing
# the message ID of the original message, instructing the iOS app to poll this server for the actual message contents.
# This is to prevent the upstream server and Firebase/APNS from being able to read the message.
#
# - upstream-base-url is the base URL of the upstream server. Should be "https://ntfy.sh".
# - upstream-access-token is the token used to authenticate with the upstream server. This is only required
#   if you exceed the upstream rate limits, or the uptream server requires authentication.
#
# upstream-base-url:
# upstream-access-token:

# Rate limiting: Total number of topics before the server rejects new topics.
#
# global-topic-limit: 15000

# Rate limiting: Number of subscriptions per visitor (IP address)
#
# visitor-subscription-limit: 30

# Rate limiting: Allowed GET/PUT/POST requests per second, per visitor:
# - visitor-request-limit-burst is the initial bucket of requests each visitor has
# - visitor-request-limit-replenish is the rate at which the bucket is refilled
# - visitor-request-limit-exempt-hosts is a comma-separated list of hostnames, IPs or CIDRs to be
#   exempt from request rate limiting. Hostnames are resolved at the time the server is started.
#   Example: "<IP_ADDRESS>,ntfy.example.com,<IP_ADDRESS>/24"
#
# visitor-request-limit-burst: 60
# visitor-request-limit-replenish: "5s"
# visitor-request-limit-exempt-hosts: ""

# Rate limiting: Hard daily limit of messages per visitor and day. The limit is reset
# every day at midnight UTC. If the limit is not set (or set to zero), the request
# limit (see above) governs the upper limit.
#
# visitor-message-daily-limit: 0

# Rate limiting: Allowed emails per visitor:
# - visitor-email-limit-burst is the initial bucket of emails each visitor has
# - visitor-email-limit-replenish is the rate at which the bucket is refilled
#
# visitor-email-limit-burst: 16
# visitor-email-limit-replenish: "1h"

# Rate limiting: Attachment size and bandwidth limits per visitor:
# - visitor-attachment-total-size-limit is the total storage limit used for attachments per visitor
# - visitor-attachment-daily-bandwidth-limit is the total daily attachment download/upload traffic limit per visitor
#
# visitor-attachment-total-size-limit: "100M"
# visitor-attachment-daily-bandwidth-limit: "500M"

# Rate limiting: Enable subscriber-based rate limiting (mostly used for UnifiedPush)
#
# If enabled, subscribers may opt to have published messages counted against their own rate limits, as opposed
# to the publisher's rate limits. This is especially useful to increase the amount of messages that high-volume
# publishers (e.g. Matrix/Mastodon servers) are allowed to send.
#
# Once enabled, a client may send a "Rate-Topics: <topic1>,<topic2>,..." header when subscribing to topics via
# HTTP stream, or websockets, thereby registering itself as the "rate visitor", i.e. the visitor whose rate limits
# to use when publishing on this topic. Note: Setting the rate visitor requires READ-WRITE permission on the topic.
#
# UnifiedPush only: If this setting is enabled, publishing to UnifiedPush topics will lead to a HTTP 507 response if
# no "rate visitor" has been previously registered. This is to avoid burning the publisher's "visitor-message-daily-limit".
#
# visitor-subscriber-rate-limiting: false

# Payments integration via Stripe
#
# - stripe-secret-key is the key used for the Stripe API communication. Setting this values
#   enables payments in the ntfy web app (e.g. Upgrade dialog). See https://dashboard.stripe.com/apikeys.
# - stripe-webhook-key is the key required to validate the authenticity of incoming webhooks from Stripe.
#   Webhooks are essential up keep the local database in sync with the payment provider. See https://dashboard.stripe.com/webhooks.
# - billing-contact is an email address or website displayed in the "Upgrade tier" dialog to let people reach
#   out with billing questions. If unset, nothing will be displayed.
#
# stripe-secret-key:
# stripe-webhook-key:
# billing-contact:

# Metrics
#
# ntfy can expose Prometheus-style metrics via a /metrics endpoint, or on a dedicated listen IP/port.
# Metrics may be considered sensitive information, so before you enable them, be sure you know what you are
# doing, and/or secure access to the endpoint in your reverse proxy.
#
# - enable-metrics enables the /metrics endpoint for the default ntfy server (i.e. HTTP, HTTPS and/or Unix socket)
# - metrics-listen-http exposes the metrics endpoint via a dedicated [IP]:port. If set, this option implicitly
#   enables metrics as well, e.g. "<IP_ADDRESS>:9090" or ":9090"
#
# enable-metrics: false
# metrics-listen-http:

# Profiling
#
# ntfy can expose Go's net/http/pprof endpoints to support profiling of the ntfy server. If enabled, ntfy will listen
# on a dedicated listen IP/port, which can be accessed via the web browser on http://<ip>:<port>/debug/pprof/.
# This can be helpful to expose bottlenecks, and visualize call flows. See https://pkg.go.dev/net/http/pprof for details.
#
# profile-listen-http:

# Logging options
#
# By default, ntfy logs to the console (stderr), with an "info" log level, and in a human-readable text format.
# ntfy supports five different log levels, can also write to a file, log as JSON, and even supports granular
# log level overrides for easier debugging. Some options (log-level and log-level-overrides) can be hot reloaded
# by calling "kill -HUP $pid" or "systemctl reload ntfy".
#
# - log-format defines the output format, can be "text" (default) or "json"
# - log-file is a filename to write logs to. If this is not set, ntfy logs to stderr.
# - log-level defines the default log level, can be one of "trace", "debug", "info" (default), "warn" or "error".
#   Be aware that "debug" (and particularly "trace") can be VERY CHATTY. Only turn them on briefly for debugging purposes.
# - log-level-overrides lets you override the log level if certain fields match. This is incredibly powerful
#   for debugging certain parts of the system (e.g. only the account management, or only a certain visitor).
#   This is an array of strings in the format:
#      - "field=value -> level" to match a value exactly, e.g. "tag=manager -> trace"
#      - "field -> level" to match any value, e.g. "time_taken_ms -> debug"
#   Warning: Using log-level-overrides has a performance penalty. Only use it for temporary debugging.
#
# Check your permissions:
#   If you are running ntfy with systemd, make sure this log file is owned by the
#   ntfy user and group by running: chown ntfy.ntfy <filename>.
#
# Example (good for production):
#   log-level: info
#   log-format: json
#   log-file: /var/log/ntfy.log
#
# Example level overrides (for debugging, only use temporarily):
#   log-level-overrides:
#      - "tag=manager -> trace"
#      - "visitor_ip=<IP_ADDRESS> -> debug"
#      - "time_taken_ms -> debug"
#
# log-level: info
# log-level-overrides:
# log-format: text
# log-file:

In Tamil, lines starting with "#" are comments. So you don't really have TLS configured at all.

Maybe you didn't read my post carefully.
The current config works because the 3 https lines are commented out. If I uncomment them I get errors.

Troubleshooting is best done on discord or matrix. Feel free to join.
If you get errors, it is a really really really good idea to include screenshots or copied text of the errors. Otherwise we cannot help.
You've done the equivalent of your mom telling you "my computer is broken" without giving any more details 😊

systemctl restart ntfy ; sleep 2 ;doas systemctl status ntfy
× ntfy.service - ntfy server
     Loaded: loaded (/lib/systemd/system/ntfy.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Wed 2023-11-22 19:08:49 WAT; 401ms ago
    Process: 1446959 ExecStart=/usr/bin/ntfy serve --no-log-dates (code=exited, status=1/FAILURE)
   Main PID: 1446959 (code=exited, status=1/FAILURE)
        CPU: 148ms

Nov 22 19:08:49 egwfw systemd[1]: ntfy.service: Scheduled restart job, restart counter is at 5.
Nov 22 19:08:49 egwfw systemd[1]: Stopped ntfy server.
Nov 22 19:08:49 egwfw systemd[1]: ntfy.service: Start request repeated too quickly.
Nov 22 19:08:49 egwfw systemd[1]: ntfy.service: Failed with result 'exit-code'.
Nov 22 19:08:49 egwfw systemd[1]: Failed to start ntfy server.

The output of: sudo journalctl -xeu ntfy.service

░░ A start job for unit ntfy.service has finished with a failure.
░░
░░ The job identifier is 39865 and the job result is failed.
Nov 22 19:08:48 egwfw systemd[1]: Started ntfy server.
░░ Subject: A start job for unit ntfy.service has finished successfully
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit ntfy.service has finished successfully.
░░
░░ The job identifier is 40173.
Nov 22 19:08:48 egwfw ntfy[1446862]: INFO Listening on :80[http] :443[https], ntfy 2.7.0, log level is INFO (tag=startup)
Nov 22 19:08:48 egwfw ntfy[1446862]: FATAL listen tcp :80: bind: address already in use (exit_code=1)
Nov 22 19:08:48 egwfw ntfy[1446862]: listen tcp :80: bind: address already in use
Nov 22 19:08:48 egwfw systemd[1]: ntfy.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ An ExecStart= process belonging to unit ntfy.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
Nov 22 19:08:48 egwfw systemd[1]: ntfy.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit ntfy.service has entered the 'failed' state with result 'exit-code'.
Nov 22 19:08:48 egwfw systemd[1]: ntfy.service: Scheduled restart job, restart counter is at 1.
░░ Subject: Automatic restarting of a unit has been scheduled
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ Automatic restarting of the unit ntfy.service has been scheduled, as the result for
░░ the configured Restart= setting for the unit.
Nov 22 19:08:48 egwfw systemd[1]: Stopped ntfy server.
░░ Subject: A stop job for unit ntfy.service has finished
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A stop job for unit ntfy.service has finished.
░░
░░ The job identifier is 40273 and the job result is done.
Nov 22 19:08:48 egwfw systemd[1]: Started ntfy server.
░░ Subject: A start job for unit ntfy.service has finished successfully
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit ntfy.service has finished successfully.
░░
░░ The job identifier is 40273.
Nov 22 19:08:48 egwfw ntfy[1446891]: INFO Listening on :80[http] :443[https], ntfy 2.7.0, log level is INFO (tag=startup)
Nov 22 19:08:48 egwfw ntfy[1446891]: FATAL listen tcp :80: bind: address already in use (exit_code=1)
Nov 22 19:08:48 egwfw ntfy[1446891]: listen tcp :80: bind: address already in use
Nov 22 19:08:48 egwfw systemd[1]: ntfy.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ An ExecStart= process belonging to unit ntfy.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
Nov 22 19:08:48 egwfw systemd[1]: ntfy.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit ntfy.service has entered the 'failed' state with result 'exit-code'.
Nov 22 19:08:48 egwfw systemd[1]: ntfy.service: Scheduled restart job, restart counter is at 2.
░░ Subject: Automatic restarting of a unit has been scheduled
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ Automatic restarting of the unit ntfy.service has been scheduled, as the result for
░░ the configured Restart= setting for the unit.
Nov 22 19:08:48 egwfw systemd[1]: Stopped ntfy server.
░░ Subject: A stop job for unit ntfy.service has finished
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A stop job for unit ntfy.service has finished.
░░
░░ The job identifier is 40373 and the job result is done.
Nov 22 19:08:48 egwfw systemd[1]: Started ntfy server.
░░ Subject: A start job for unit ntfy.service has finished successfully
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit ntfy.service has finished successfully.
░░
░░ The job identifier is 40373.
Nov 22 19:08:48 egwfw ntfy[1446911]: INFO Listening on :80[http] :443[https], ntfy 2.7.0, log level is INFO (tag=startup)
Nov 22 19:08:48 egwfw ntfy[1446911]: FATAL listen tcp :80: bind: address already in use (exit_code=1)
Nov 22 19:08:48 egwfw ntfy[1446911]: listen tcp :80: bind: address already in use
Nov 22 19:08:48 egwfw systemd[1]: ntfy.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ An ExecStart= process belonging to unit ntfy.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
Nov 22 19:08:48 egwfw systemd[1]: ntfy.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit ntfy.service has entered the 'failed' state with result 'exit-code'.
Nov 22 19:08:49 egwfw systemd[1]: ntfy.service: Scheduled restart job, restart counter is at 3.
░░ Subject: Automatic restarting of a unit has been scheduled
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ Automatic restarting of the unit ntfy.service has been scheduled, as the result for
░░ the configured Restart= setting for the unit.
Nov 22 19:08:49 egwfw systemd[1]: Stopped ntfy server.
░░ Subject: A stop job for unit ntfy.service has finished
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A stop job for unit ntfy.service has finished.
░░
░░ The job identifier is 40473 and the job result is done.
Nov 22 19:08:49 egwfw systemd[1]: Started ntfy server.
░░ Subject: A start job for unit ntfy.service has finished successfully
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit ntfy.service has finished successfully.
░░
░░ The job identifier is 40473.
Nov 22 19:08:49 egwfw ntfy[1446932]: INFO Listening on :80[http] :443[https], ntfy 2.7.0, log level is INFO (tag=startup)
Nov 22 19:08:49 egwfw ntfy[1446932]: FATAL listen tcp :80: bind: address already in use (exit_code=1)
Nov 22 19:08:49 egwfw ntfy[1446932]: listen tcp :80: bind: address already in use
Nov 22 19:08:49 egwfw systemd[1]: ntfy.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ An ExecStart= process belonging to unit ntfy.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
Nov 22 19:08:49 egwfw systemd[1]: ntfy.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit ntfy.service has entered the 'failed' state with result 'exit-code'.
Nov 22 19:08:49 egwfw systemd[1]: ntfy.service: Scheduled restart job, restart counter is at 4.
░░ Subject: Automatic restarting of a unit has been scheduled
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ Automatic restarting of the unit ntfy.service has been scheduled, as the result for
░░ the configured Restart= setting for the unit.
Nov 22 19:08:49 egwfw systemd[1]: Stopped ntfy server.
░░ Subject: A stop job for unit ntfy.service has finished
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A stop job for unit ntfy.service has finished.
░░
░░ The job identifier is 40573 and the job result is done.
Nov 22 19:08:49 egwfw systemd[1]: Started ntfy server.
░░ Subject: A start job for unit ntfy.service has finished successfully
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit ntfy.service has finished successfully.
░░
░░ The job identifier is 40573.
Nov 22 19:08:49 egwfw ntfy[1446959]: INFO Listening on :80[http] :443[https], ntfy 2.7.0, log level is INFO (tag=startup)
Nov 22 19:08:49 egwfw ntfy[1446959]: FATAL listen tcp :80: bind: address already in use (exit_code=1)
Nov 22 19:08:49 egwfw ntfy[1446959]: listen tcp :80: bind: address already in use
Nov 22 19:08:49 egwfw systemd[1]: ntfy.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ An ExecStart= process belonging to unit ntfy.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
Nov 22 19:08:49 egwfw systemd[1]: ntfy.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit ntfy.service has entered the 'failed' state with result 'exit-code'.
Nov 22 19:08:49 egwfw systemd[1]: ntfy.service: Scheduled restart job, restart counter is at 5.
░░ Subject: Automatic restarting of a unit has been scheduled
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ Automatic restarting of the unit ntfy.service has been scheduled, as the result for
░░ the configured Restart= setting for the unit.
Nov 22 19:08:49 egwfw systemd[1]: Stopped ntfy server.
░░ Subject: A stop job for unit ntfy.service has finished
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A stop job for unit ntfy.service has finished.
░░
░░ The job identifier is 40673 and the job result is done.
Nov 22 19:08:49 egwfw systemd[1]: ntfy.service: Start request repeated too quickly.
Nov 22 19:08:49 egwfw systemd[1]: ntfy.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit ntfy.service has entered the 'failed' state with result 'exit-code'.
Nov 22 19:08:49 egwfw systemd[1]: Failed to start ntfy server.
░░ Subject: A start job for unit ntfy.service has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit ntfy.service has finished with a failure.
░░
░░ The job identifier is 40673 and the job result is failed.

I'm a very patient person, but I ask you to learn to do some work yourself. Read the error message, or ask ChatGPT to interpret what's wrong. It's quite obvious.
I'll close this ticket, as it is clearly not a ntfy bug. Happy Thanksgiving :turkey:


Install moderation dashboard and assign content types to workflow

Summary

Update the install hook so it runs.
Adds the base content types to the default editorial workflow during install.
Enables the Moderation Dashboard and associated user permissions by default during install.
Metadata

Question
Answer

Did you use a meaningful pull request title?
yes

Did you apply meaningful labels to the pull request?
yes

Did you perform a self review first?
yes

Documentation reflects changes?
no

CHANGELOG reflects changes?
yes

Unit/Functional tests reflect changes?
yes

Did you perform browser testing?
yes

Risk level
Low

Relevant links
JIRA issue, bug reports, security alerts, etc.

https://thinkoomph.jira.com/browse/RIG-22

@pfrilling thanks, addressed requested changes.


Chore: getKeys() comment fix

Clarifies that getKeys fetches the keys of all active keysets if no keysetId parameter is given.

It looks like staging hasn't fully caught up with rc-2? I can remove the unrelated changes here if needed @gandlafbtc.


Update TileDB-SOMA to use somacore==1.0.21

Update somacore version and implement the following changes from somacore:

Update name and arguments in the Scene methods for adding new assets.
Change the create methods for the PointCloudDataFrame and GeometryDataFrame classes to directly take the CoordinateSpace as an argument instead of only accepting a tuple of axis names.
Use new factory method for creating a CoordinateSpace from axis names.

sc-57491
sc-56260

sc-57488


The Twig date filter stopped working correctly after changing to own filter

Hello
As the title says the date filter not working correctly.
All of the following variants do not work:
{{ 'now'|date('F jS \\a\\t H:i') }}
{{ 'now'|date('F jS, Y') }}
{{ 'now'|date(config.system.pages.dateformat.short) }}
{{ 'now'|date(config.system.pages.dateformat.long) }}

but they work with the standard Twig date filter.
Also, maybe you'll consider changing own filter name to something different (maybe tdate if it's related to translation) from the predefined standard Twig filter name to avoid confusion.
I guess when someone uses standard Twig filter, the results are expected as they described in Twig documentation.
Besides, Twig has some extensions (Intl and Date in particular) which are working fine. For example:
{{ page.date|localizeddate('long', 'short', grav.language.getLanguage) }}
{{ '01.01.2017'|time_diff }}

I personally use these extensions as a plugin:
<?php
namespace Grav\Plugin;

use Grav\Common\Plugin;
use Symfony\Component\Translation\Translator;
use Symfony\Component\Translation\Loader\YamlFileLoader;

class TwigExtensionsPlugin extends Plugin
{
    /**
     * @return array
     */
    public static function getSubscribedEvents()
    {
        return [
            'onPluginsInitialized' => ['onPluginsInitialized', 0],
        ];
    }

    /**
     * Initialize configuration
     */
    public function onPluginsInitialized()
    {
        if ($this->isAdmin()) {
            $this->active = false;
            return;
        }

        $autoload = __DIR__ . '/vendor/autoload.php';

        if (file_exists($autoload)) {
            require_once $autoload;

            $this->enable([
                'onTwigExtensions' => ['onTwigExtensions', 0]
            ]);
        }
    }

    public function onTwigExtensions()
    {
        $extensions = (array) $this->config->get('plugins.twigextensions.extensions');

        if (in_array('date', array_map('strtolower', $extensions))) {
            $language = $this->grav['language']->getLanguage();

            $translation = __DIR__ . '/translations/date.' . $language . '.yaml';

            if (file_exists($translation)) {
                $translator = new Translator($language);
                $translator->addLoader('yaml', new YamlFileLoader());
                $translator->addResource('yaml', $translation, $language, 'date');
            }
        }

        foreach($extensions as $extension) {
            $extension_class = '\Twig_Extensions_Extension_' . ucfirst($extension);
            if (class_exists($extension_class)) {
                if (stripos($extension, 'date') !== false && isset($translator)) {
                    $this->grav['twig']->twig->addExtension(new $extension_class($translator));
                } else {
                    $this->grav['twig']->twig->addExtension(new $extension_class());
                }
            }
        }
    }
}

Are you using the latest stable Grav, or develop?

From the title I assume develop, where I merged https://github.com/getgrav/grav/pull/731/files recently.
Can you define "do not work"? What's the expected output, what you get instead?

Hello,
I am testing develop.
The expected output:
{{ 'now'|date('F jS \\a\\t H:i') }}  —> March 24th at 12:56
{{ 'now'|date('F jS, Y') }} —> March 24th, 2016
{{ 'now'|date(config.system.pages.dateformat.short) }} —> 24th Mar 2016
{{ 'now'|date(config.system.pages.dateformat.long) }} —> March 24th at 12:56pm

Instead I get empty string.
It returns false in debug bar when trying like this {{ dump('now'|date('F jS \\a\\t H:i')) }}

I added this change to allow Grav to automatically translate the dates, according to the locale.
Might depend on the locale used.
Using english (or no languages setup) I get
March 24S \P\t 11:10
March 24S, 2016
24S Mar 2016
March 24S \P\t 11:10P

Using italian I get
Marzo 24S \P\t 10:50
Marzo 24S, 2016
24S Mar 2016
Marzo 24S \P\t 10:50P

There's a problem with the date format however, S P and t are unsupported by that "translation" function I added.
Will look into that, but definitely should not be an empty object. What's your languages setup?

I am testing the default develop download without changing anything in configuration except enabling the debugging.
If it matters I am testing on Windows the locale and regional settings of the OS is Russian.

I noticed the same weird \P\t in my test setup, wasn't sure where that was coming from. So does seem to be a  problem with formatting at least.

Sorry, sticky button!

Reverted the date change in https://github.com/getgrav/grav/commit/7158dd9beb8b80065558669557d10ae20fda4356, now it's back to the original Twig date filter.

DateTime does not handle the locale, it needs the Intl extension and a date format using IntlDateFormatter to do it, but that does not allow all the Date format identifiers accepted by DateTime, so there was a bit of adjustment to do.
Using strftime, my original try, is not a working way as the date format is too different and not everything handled by DateTime does work with strftime.
Some plugins, including "Archives", rely on the date being in english to build the archives links, so that would break this functionality.

I think loading the Intl twig extension http://twig.sensiolabs.org/doc/extensions/intl.html as you suggested is the way to go.

Added a PR to load the Intl Twig extension if needed https://github.com/getgrav/grav/pull/758


[KickStarter] unable to extract OpenGraph description.

[x] I've verified and I assure that I'm running youtube-dl 2016.08.22

Before submitting an issue make sure you have:

[x] At least skimmed through README and most notably FAQ and BUGS sections
[x] Searched the bugtracker for similar issues including closed ones

What is the purpose of your issue?

[x] Bug report (encountered problems with youtube-dl)
[ ] Site support request (request for adding support for a new site)
[ ] Feature request (request for a new functionality)
[ ] Question
[ ] Other

$ y -v 'https://www.kickstarter.com/projects/1420158244/power-drive-2000/widget/video.html'
[debug] System config: []
[debug] User config: ['-4', '-f', 'best', '--prefer-free-formats', '--no-cache-dir', '--no-mtime', '--youtube-skip-dash-manifest']
[debug] Command-line args: ['-v', 'https://www.kickstarter.com/projects/1420158244/power-drive-2000/widget/video.html']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2016.08.22
[debug] Python version 3.6.0a4 - Linux-4.7.0-rc7-686-i686-with-debian-stretch-sid
[debug] exe versions: ffmpeg 3.1.2, ffprobe 3.1.2, rtmpdump 2.4
[debug] Proxy map: {}
[KickStarter]<PHONE_NUMBER>: Downloading webpage
WARNING: unable to extract OpenGraph description; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
[debug] Invoking downloader on 'https://ksr-video.imgix.net/projects/1784048/video-533555-h264_high.mp4'

https://www.kickstarter.com/projects/1420158244/power-drive-2000/widget/video.html

Thanks. This video does not have a description, and there would not be warnings in this case.


using 2 URIs

I’m using 2 UIRs – local & Remote. I have 10 messages/events. I expect all 10 will appear on both elastic servers. What actually happens is the 10 log messages split between the 2 URIs (one has 4 and the other 6)

Elasticsearch will load balance across all url's rather than sending to both. You would have to add mulitple nlog targets to send to 2 different instances.


Add polling logic to speed up bridge IT

Signed-off-by: Georgi Sabev<EMAIL_ADDRESS>

Looks good. Thanks!


[SPARK-35398][SQL] Simplify the way to get classes from ClassBodyEvaluator in CodeGenerator.updateAndGetCompilationStats method

What changes were proposed in this pull request?
SPARK-35253 upgraded janino from 3.0.16 to 3.1.4, ClassBodyEvaluator provides the getBytecodes method to get
the mapping from ClassFile.getThisClassName to ClassFile.toByteArray directly in this version and we don't need to get this variable by reflection api anymore.
So the main purpose of this pr is simplify the way to get classes from ClassBodyEvaluator in CodeGenerator.updateAndGetCompilationStats method.
Why are the changes needed?
Code simplification.
Does this PR introduce any user-facing change?
No
How was this patch tested?
Pass the Jenkins or GitHub Action

Test build #138505 has started for PR 32536 at commit 738bdc6.

Waiting for CI

cc @maropu @srowen

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43025/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43025/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/43025/

Test build #138505 has finished for PR 32536 at commit 738bdc6.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/138505/

Test build #138606 has started for PR 32536 at commit 5ddb354.

Test build #138606 has finished for PR 32536 at commit 5ddb354.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43127/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/138606/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43127/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/43127/

Test build #138611 has started for PR 32536 at commit c1deabe.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43132/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43132/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/43132/

Test build #138611 has finished for PR 32536 at commit c1deabe.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/138611/

New test cases will fail when running with other tests, let me check this.

@maropu
Reservoir in com.codahale.metrics.Histogram is ExponentiallyDecayingReservoir, it's values are statistical samples, not complete sets, when the size of values exceeds the threshold(1028), the new values may not be inserted into values.
I printed size of METRIC_GENERATED_CLASS_BYTECODE_SIZE and METRIC_GENERATED_METHOD_BYTECODE_SIZE in
CodeGenerationSuite.beforeAll method, their results are all 1028.
So this case will fail  when run
mvn test -pl sql/catalyst

and this case will success  when run
mvn test -pl sql/catalyst -DwildcardSuites=org.apache.spark.sql.catalyst.expressions.CodeGenerationSuite

@maropu for the above problem, can we add a case similar to the following to compare the result of reflection api and using ClassBodyEvaluator.getBytecodes api directly ?
val codeBody = s"""
        public java.lang.Object generate(Object[] references) {
          return new TestMetricCode(references);
        }

        class TestMetricCode {

          public TestMetricCode(Object[] references) {
          }

          public long sumOfSquares(long left, long right) {
            return left * left + right * right;
          }
        }
      """
    val evaluator = CodeGenerator.createClassBodyEvaluator()
    evaluator.cook("generated.java", codeBody)

    import scala.collection.JavaConverters._
    val bytecodesWithApi = evaluator.getBytecodes.asScala
    val bytecodesWithReflectionApi = {
      val scField = classOf[ClassBodyEvaluator].getDeclaredField("sc")
      scField.setAccessible(true)
      val compiler = scField.get(evaluator).asInstanceOf[SimpleCompiler]
      val loader = compiler.getClassLoader.asInstanceOf[ByteArrayClassLoader]
      val classesField = loader.getClass.getDeclaredField("classes")
      classesField.setAccessible(true)
      classesField.get(loader).asInstanceOf[java.util.Map[String, Array[Byte]]].asScala
    }

    assert(bytecodesWithApi == bytecodesWithReflectionApi)

Ah, okay. Thank you for the investigation. If so, I think we don't need to add tests. Instead of it, could you update the PR description to describe how you checked if the stats values are the same (Adding the code example above looks fine)?

Test build #138682 has started for PR 32536 at commit 8db3551.

Kubernetes integration test unable to build dist.
exiting with code: 1
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43203/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/43203/

Test build #138682 has finished for PR 32536 at commit 8db3551.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class UpdatingSessionsExec(
class UpdatingSessionsIterator(

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/138682/

Thank you, @LuciferYang . Merged to master.

thx all ~


Fix/template return string

relates to the coment in #98

I think this should be good to go - but lets first check if we actually have tests for rendering strings at this position.

Yes! We do have tests for this! I added the change directly to the 1.0 branch with some other changes and fixes.


Setting SWIFT_INSTALL_OBJ_HEADER to YES

Setting SWIFT_INSTALL_OBJ_HEADER to YES helps carthage update use flag cache-build and project doesn’t rebuild after each update
If SWIFT_INSTALL_OBJ_HEADER doesn't set to YES build process doesn't generate EmitterKit-Swift.h.
If EmitterKit-Swift.h doesn't generate carthage cannot check swift's version parsed from that file so build cache is invalid and each time project is rebuilding

@maercam Good work, thanks for the help! Clearly, I don't use Carthage. 😛

@maercam Do you think #41 should be merged?

I don't yet. I can look at it later. Could you make release with my last changes?

@maercam Yes I will, but I'd like to merge that PR along with it, if possible. I also have two other commits in progress that will be included in the next release. Coming up shortly.

v5.2.0 has been released 🎉


Boarding stopped at 10 people

When boarding starts, no more than 10 people are boarded. Find below the log:
2023-07-23 16:23:45.296 [INF] [ GsxController:RunLoadingServices ] Waiting 90s before calling Boarding  2023-07-23 16:25:55.568 [INF] [ GsxController:RunLoadingServices ] Calling Boarding Service (Default)  2023-07-23 16:25:55.569 [INF] [ GsxController:SetPassengers      ] Passenger Count set to 148  2023-07-23 16:25:55.571 [INF] [ GsxController:SetPassengers      ] Crew Boarding disabled  2023-07-23 16:25:55.571 [DBG] [ GsxController:MenuOpen           ] Opening GSX Menu  2023-07-23 16:25:55.902 [DBG] [ GsxController:MenuWaitReady      ] Wait ended after 300ms  2023-07-23 16:25:55.902 [DBG] [ GsxController:MenuItem           ] Selecting Menu Option 4 (L-Var Value 3)  2023-07-23 16:25:57.355 [INF] [ GsxController:RunLoadingServices ] Boarding Service active  2023-07-23 16:25:58.767 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:00.176 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:01.591 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:03.018 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:04.494 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:05.941 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:07.366 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:08.779 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:10.213 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:11.673 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:13.148 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:14.589 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:16.031 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:17.474 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:18.904 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:20.350 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:21.778 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:23.227 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:24.641 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:26.050 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:27.515 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:28.991 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:30.433 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:31.843 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:33.271 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:34.860 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:36.445 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:37.994 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:39.521 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:41.075 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:42.607 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:44.162 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 0) (planned (148))  2023-07-23 16:26:45.667 [DBG] [ FenixContoller:BoardPassengers   ] (num 10) (current 0) (planned (148))  2023-07-23 16:26:47.102 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:26:48.628 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:26:50.113 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:26:51.538 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:26:52.984 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:26:54.412 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:26:55.872 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:26:57.299 [DBG] [ FenixContoller:BoardPassengers   ] Passenger Num was above 15!  2023-07-23 16:26:58.729 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:00.154 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:01.686 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:03.156 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:04.628 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:06.103 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:07.638 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:09.171 [DBG] [ FenixContoller:BoardPassengers   ] Passenger Num was above 15!  2023-07-23 16:27:10.691 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:12.196 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:13.720 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:15.262 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:16.748 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:18.262 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:19.793 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:21.253 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:22.805 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:24.335 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:25.827 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:27.319 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:28.889 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:30.343 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:31.868 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:33.416 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:34.949 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:36.453 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:37.942 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:39.464 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:41.000 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:42.488 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:43.967 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:45.425 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:46.982 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:48.547 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:50.095 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:51.640 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:53.102 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:54.609 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:56.178 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:57.744 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:27:59.284 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:00.825 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:02.389 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:03.917 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:05.409 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:06.931 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:08.431 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:09.948 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:11.375 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:12.801 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:14.218 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:15.698 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:17.210 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:18.672 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:20.133 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:21.547 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:23.005 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:24.503 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:25.945 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:27.403 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:28.882 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:30.358 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:31.792 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:33.223 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:34.766 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:36.220 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:37.660 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:39.153 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:40.600 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:42.062 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:43.498 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:44.924 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:46.358 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:47.805 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:49.230 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:50.686 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:52.124 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:53.647 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:55.221 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:56.709 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:58.400 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:28:59.989 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:01.628 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:03.167 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:04.662 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:06.190 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:07.735 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:09.251 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:10.857 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:12.414 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:14.027 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:15.660 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:17.135 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:18.614 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:20.151 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:21.631 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:23.099 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:24.579 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:26.092 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:27.543 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:29.061 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:30.670 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:32.190 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:33.778 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:35.349 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:36.842 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:38.489 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:40.085 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:41.653 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:43.121 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:44.627 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:46.215 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:47.800 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:49.455 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:51.060 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:52.577 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:54.148 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:55.675 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:57.213 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:29:58.701 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:00.164 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:01.703 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:03.189 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:04.664 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:06.126 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:07.568 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:09.073 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:10.524 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:11.946 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:13.394 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:14.820 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:16.264 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:17.692 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:19.163 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:20.629 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:22.052 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:23.501 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:25.121 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:26.683 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:28.172 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:29.648 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:31.109 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:32.584 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:34.076 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:35.586 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:37.057 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:38.499 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:39.994 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:41.511 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:42.975 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:44.465 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:45.926 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:47.368 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:48.869 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:50.331 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:51.822 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:53.301 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:54.790 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:56.293 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:57.770 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:30:59.310 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:00.770 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:02.233 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:03.734 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:05.239 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:06.696 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:08.173 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:09.682 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:11.167 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:12.667 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:14.168 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:15.644 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:17.103 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:18.609 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:20.082 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:21.575 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:23.076 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:24.622 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:26.189 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:27.675 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:29.235 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:30.792 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:32.347 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:34.033 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:35.637 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:37.155 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:38.661 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:40.198 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:41.645 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:43.143 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:44.719 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:46.261 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:47.798 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:49.332 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:50.852 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:52.390 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:53.902 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:55.454 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:57.089 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:31:58.640 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:00.128 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:01.635 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:03.146 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:04.658 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:06.173 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:07.649 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:09.160 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:10.633 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:12.105 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:13.559 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:15.005 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:16.542 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:18.035 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:19.508 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:21.034 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:22.557 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:24.125 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:25.649 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:27.181 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:28.718 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:30.315 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:31.896 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:33.483 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:34.989 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:36.500 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:38.067 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:39.642 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:41.191 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:42.712 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:44.223 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:45.718 [DBG] [ FenixContoller:BoardPassengers   ] (num 0) (current 10) (planned (148))  2023-07-23 16:32:45.720 [INF] [ GsxController:RunLoadingServices ] Boarding completed

Seems you have set GSX Passenger Density to Extreme

The De-/Boarding Speed of Passengers is dependant on the Passenger Density Setting (GSX In-Game Menu -> GSX Settings -> Timings). Higher Density => faster Boarding. BUT: The Setting Extreme is too extreme! Boarding does not work with this Setting.

Nope, I have the setting on Very Dense

Hmm strange, have it set on 'Very Dense' myself all the Time without Problems (and just tested it).
But the Log shows very clearly that the Passengers coming in too fast (or more specifically the Change in Numbers Variable-wise is too big).
Is your Time Acceleration still on 1x?

What Version of the MobiFlight WASM Module have you installed?

Time Acceleration is 1x, yeah. I have the MobiFlight WASM Module version 0.6.0

I have the same issue with the setting on "Dense"

Some People? Where? Link?
Just made a Test yesterday because of another Topic and had no Issues again with Boarding.

On a private Discord. I've reinstalled Fenix2GSX and updated GSX to the latest version and I still have the same issue. These are my GSX timings settings:

Looks like I fixed it deselecting Estimate Passengers Number option on GSX Settings.

That is a bit strange - I have that on all the Time 🤔
Do you have your Simbrief Account configured in GSX and have "Ignore Time" enabled? Maybe the Issue arises when GSX has no valid SimBrief Flightplan loaded?

Yep, I have a Simbrief account configured but the Ignore Time checkbox is not enabled.

Ah okay, then GSX will not load the Flightplan if the SimTime does not match the Flightplan.
Could you please confirm if it still happens with SimBrief Account configured, Ignore Time enabled and Estimate Passenger Number and enabled again?
I'm still a bit puzzled why that happens with that Option, because I have that on all Time and never saw that Issue (but I have Ignore Time also set)

Added to Readme


New problems

Coverage decreased (-0.3%) to 99.739% when pulling e8b8c0464716d88478131aa7a269a69131b89e2a on vepiteski:NewProblems into 253b34e7b87cb1cc4270882c4caa4b194e558187 on JuliaOptimizers:master.


Failed when lq_folder starts with '/'

https://github.com/open-mmlab/mmediting/blob/48ca8e1707e203445c296f363c5a4c9fc6b09bf3/mmedit/apis/restoration_video_inference.py#L96

@Z-Fran  Please check this issue.

Hi, we have fixed this bug in MMEditing 2.0. You can reference https://github.com/open-mmlab/mmediting/blob/1.x/mmedit/apis/restoration_video_inference.py#L103. Thank your submitting issues. We will fix this bug of master branch later.


SendErrors is restrictive when considering that not all errors are ValidationErrors - FluentResults

Given that an endpoint needs to handle both requests and responses, the current implementation of SendErrors is heavily weighted towards problems on the request.
Full Disclosure, I am (trying) to use FluentResults to manage the errors that occur in the Application, Domain or Infrastructure layer. Calls to services within these layers return Result or Result<T>.
Throwing Exceptions is expensive, so I try to avoid throwing unnecessary exceptions such as when a record cannot be found in the database. Sure, I could return null, but in other circumstances, null could mean two or three things.  Therefore, the Result class allows me to record each type of error that has occurred (usually one) lower in the stack, and pass them back up to the endpoint, which has some pre-determined logic to decide what to do with specific error types, or if it can't give a more appropriate response (400, 403, 409 etc) then as a last resort it will return 500. Error messages and formats are standardised and even objects required by the errors are captured, for full information relating to the problem.
There are lots of things that can go wrong, are not exceptional, and other processes up the stack should know about before continuing.
On with the problem. SendErrors simply send the validation errors to the client. Which to me, means validation on the input. Errors that happened in my other layers, once the request was received, understood and validated are simply lost. It would be great if we could return some other (non-typed) response in the body. That doesn't require me to throw an exception because something happened that I expected could happen.
Something like
    protected Task SendErrorsAsync(object response, int statusCode = 400, CancellationToken cancellation = default)
    {
        return HttpContext.Response.SendErrorsAsync(response, statusCode, Definition.SerializerContext, cancellation);
    }

Happy to share some specific code or a demo-repo if needed.

you do have the option to write your own SendErrors() as an extension method targetting IEndpoint interface.
the downside to that would be you'd have to preface your call with this.SendErrors...
you'd be able to avoid that by extending/subclassing Endpoint<TRequest,TResponse> classes and adding your overload there.
would that do it?

I've arrived at the same result through trial and error. Its a work around. (this.SendResult()) but the end result is the same.
Writing the Endpoint class extensions, is a fair chunk of work, given the different options, including the mapping endpoint classes too (which sub-class Endpoint, and implement an interface).
All of the "logic" to handle Results would probably need to be implemented multiple (identical) times in many ResultExtension<TReq, TRes> classes, and I hate repeating myself. Again Extension Methods might help to reduce the DRY, but its not straight forward.
Taking the FluentResults aspect away. Could we look at this from the point of view I have which is, Not all errors are validation errors. Could some way of reporting non-validation errors be implemented?
Putting FR back into the frame, It might make it easier to bridge the gap between FluentResults and this Library if I were able to report Errors as a response, Not validation errors, and not the response that the endpoint ususally makes.

so does adding the following overload to the endpoint base class enable you to do what you want?
protected Task SendErrorsAsync(object response, int statusCode = 400, CancellationToken cancellation = default) {}

if so, that's an easy fix...

I think so, I also think it'd need a mapping function ("Interceptor"?) which could be set when configuring the library to intercept those responses and change the result to a specific code and object.
public class EndpointDiscoveryOptions()
{
    public Task<Action<object>>? SendErrorsInterceptor { internal get; set }
}

which would be used like this
        serviceCollection.AddFastEndpoints(opt =>
        {
            opt.SendErrorsInterceptor = o =>
            {
                if (o is ResultBase and { IsFailed: true } failedResult)
                    await SendErrorsAsync("Standardized Error Message - failedResult.Error", StatusCodes.Status400BadRequest);
            };
        });

Run the "interceptor", before you start returning a response, check after the interceptor has run, whether a response has started, if so, do nothing, else return the original SendErrors request.
This means, I can pass in any error result, I don't have to worry (in the endpoint) about what type of error response I should be sending. That can be set at the application level.

Sure, i'll have a go.
I had another thought, which occurred  to me last night. We could simply allow for an interceptor on SendAsync. Which would do the same thing, Without having to create or amend any overloads of Endpoint.

When processing SendAsync(), look in the configuration for an interceptor that can handle that type
If none found, skip to 4
If found, run the interceptor
Check to see if a response has been returned
If yes, skip 6
Send the default SendAsync response.

Could even type the interceptors and SendAsync, so that its all strongly typed. Let me have a go at a PR. We can go from there.

#366 Opened for your review

v<IP_ADDRESS>-beta has been pushed to nuget with the PR.
would like to see your HandleAsync() and IResponseInterceptor code with this in action.
if you can do a small sample repo and throw it up on github, i can link it from the documentation as an example on how to use FE together with FluentResults library. no big deal... only if you have some free time ;-)
thanks for the PR.

Absolutely. Let me see what space I get tomorrow. :)

Just another note, on testing with my actual project, its working a treat.
One thing that would be great, is the ability to access the Endpoint.Send.cs methods as you have to basically write all response logic again. You seem only to be accessing public properties of the endpoint (At first glance endpoint base), and the HttpContext, so I think its do-able.
If they were extension methods, rather than partial methods, we could really be winning, you'd access them through HttpResponse and have to pass in an EndpointBase, plus the response, code and canx token.
Let me know your thoughts, and if you think its a go, I'll raise a separate issue.

such extension methods already exist: https://github.com/FastEndpoints/FastEndpoints/blob/main/Src/Library/Extensions/HttpResponseExtensions.cs
this is for sending the responses from within the interceptor right?
if so, we already have the ability to do a similar thing when shorcircuiting from within pre-processors: https://fast-endpoints.com/docs/pre-post-processors#short-circuiting-execution

@dj-nitehawk I found myself in the same boat as kcadduk in that I would like to send custom errors that are not validation problems.
The solution here is not ideal for me, since I have created my own Endpoint class which extends the normal one. In this, I would just like to do:
var myCustomErrors = new ApiErrorResponse();
SendErrors(myCustomErrors, 500);

And I want to avoid adding an extra pipeline for this since it is not obvious for my developers how it works, I prefer if we can just hit F12(Go to definition) and follow our flow.
I looked at using the ExtensionMethod for HttpContext but then I don't have access to the SerializerContext since that is private.
I could look into creating a PR for this if you think an overload for SendErrors are okay?

@SpaceOgre i believe the new TypedResults support would work for you. that way you can send whatever shape/response you like as with typical minimal apis.
there's also the SendResultAsync method for sending any IResult:
sealed class ApiErrorResponse : IResult
{
    public string ErrorMsg { get; set; }

    public async Task ExecuteAsync(HttpContext ctx)
    {
        await ctx.Response.SendAsync(this, 500, ...); //can pass down SerializerContext also
    }
}

sealed class SomeEndpoint : EndpointWithoutRequest
{
    public override void Configure()
    {
        Get("error");
        AllowAnonymous();
    }

    public override async Task HandleAsync(CancellationToken ct)
    {
        await SendResultAsync(new ApiErrorResponse { ErrorMsg = "blah blah" });
    }
}

@dj-nitehawk I tried to get it to work with TypedResults but did not get all the way.
But the SendResultAsync might be a nice way to do it.
How would I get hold of the SerializerContext? I have not been able to figure that out :(

nothing special there
[JsonSerializable(typeof(ApiErrorResponse))]
public partial class ApiErrorResponseCtx : JsonSerializerContext { }

await ctx.Response.SendAsync(this, 500, ApiErrorResponseCtx.Default);

@dj-nitehawk thanks, yeah that was not that hard.


Add VLAN to devices without IP addresses

Hello netbox maintainers.
I have PPPoE concentrators that has many access VLANs without ip, I haven't found a way to add the VLANs on an interface to such equipment.
Thanks for all

Marking this as a duplicate of #150, but to be honest I don't think it's very likely to be implemented. Tracking VLAN assignments to individual interfaces would introduce a lot of overhead with little benefit.

This is very important for our PPPOE hubs. We use several VLANs linked to BRIDGES. They serve to aggregate customers by geographical areas and to facilitate the relocation of IP blocks between these equipments.Thank you :)


ProxyCreated event is not being emitted in unpublished projects

We are not emitting the ProxyCreated event in unpublished projects (this event is triggered in the App contract). Because of this, we are losing track of created proxies and the status --fetch/--fix command won't work properly after publishing.
Potential fix: https://github.com/zeppelinos/zos/issues/291.

Related to https://github.com/zeppelinos/zos/issues/291

Closing as status command is deprecated


Prepare v0.30.1 no protobuf

This PR is the no-protobuf companion PR to https://github.com/lightstep/lightstep-tracer-javascript/pull/243.
Reviewers, please scrutinize this as this hasn't been released in a little while and the merge and resolve conflicts phase was a pretty delicate process with lots of margin for error.

related to #242

Hey @mwear posting here just in case. We missed changing the index.d.ts files to account for our nodejs_url change. Here's the pr to do so #245

Published: https://www.npmjs.com/package/lightstep-tracer/v/0.30.1-no-protobuf


Applying heatmap overlay in 3D

Hi.  Documentation does not say how to apply a 3D heatmap.  For instance, I am inputing an MRI (87x75x100) to my model and the gcampp injected returns a heatmap that is (2x3x5).  It is not clear how to apply that.  Also, if I use ggcamp I obtain an axial result but my input was sagittal.  It is not a big issue, it's just a matter of rotating, but it was not intuitive. Therefore I am not sure if the heatmap returned by gcampp is also rotated.  I have no clue on how to use it on 3D data.  Best regards.

Hi,

Documentation does not say how to apply a 3D heatmap. For instance, I am inputing an MRI (87x75x100) to my model and the gcampp injected returns a heatmap that is (2x3x5). It is not clear how to apply that.

Most models use some kind of bottleneck architecture. So the layers in the middle are smaller than the layer at the input/output. If you extract attention maps at the middle of these models the attention maps will be smaller as well.  Simply rescale your attention maps if you want to superimpose the 3D attention maps on your input. For 2D this is done automatically, but I did not implement that yet for 3D, so you need to do it yourself.

Also, if I use ggcamp I obtain an axial result but my input was sagittal. It is not a big issue, it's just a matter of rotating, but it was not intuitive.

Hmm, I will have a look into this within the next days.
Best
Karol

Hi. Documentation does not say how to apply a 3D heatmap. For instance, I am inputing an MRI (87x75x100) to my model and the gcampp injected returns a heatmap that is (2x3x5). It is not clear how to apply that. Also, if I use ggcamp I obtain an axial result but my input was sagittal. It is not a big issue, it's just a matter of rotating, but it was not intuitive. Therefore I am not sure if the heatmap returned by gcampp is also rotated. I have no clue on how to use it on 3D data. Best regards.

Hi, I am using the M3d-Cam to apply a 3D heatmap.But now i met some problems that i can get the output dirs,but there are no  3D heatmap in it. My usage is as follows.

can you send your codes to me to solve this problem? Thank you !

Hi,
are you able to generate attention maps with the default inject arguments like this?
model = medcam.inject(model, output_dir="attention_maps", save_maps=True)
If yes, add more of your current arguments successively until the bug occurs.
Can you also send me the code were you call the forward of your model?
Best
Karol

Hi,
are you able to generate attention maps with the default inject arguments like this?
model = medcam.inject(model, output_dir="attention_maps", save_maps=True)
If yes, add more of your current arguments successively until the bug occurs.
Can you also send me the code were you call the forward of your model?
Best
Karol

Hello,
I have tried your methods , but there are still no results. The outcome is as follows

Hi,
are you able to generate attention maps with the default inject arguments like this?
model = medcam.inject(model, output_dir="attention_maps", save_maps=True)
If yes, add more of your current arguments successively until the bug occurs.
Can you also send me the code were you call the forward of your model?
Best
Karol

Hello,
I have tried your method, but there are still no results.  The outcome are as follows

The forward of my model is as follows

Ah, I get the problem now.
Medcam backups & replaces the models original forward with its own which should be called just "forward".
This wont work in your case as your forward is called "forward_global" and "forward_local", so medcam can't find them.
Try to rename the forward that you are using to "forward".

Hello!

Documentation does not say how to apply a 3D heatmap. For instance, I am inputing an MRI (87x75x100) to my model and the gcampp injected returns a heatmap that is (2x3x5). It is not clear how to apply that.

Most models use some kind of bottleneck architecture. So the layers in the middle are smaller than the layer at the input/output. If you extract attention maps at the middle of these models the attention maps will be smaller as well. Simply rescale your attention maps if you want to superimpose the 3D attention maps on your input. For 2D this is done automatically, but I did not implement that yet for 3D, so you need to do it yourself.

I am sorry for this very late response.  I was using this code:
class_names = ['CN','EMCI','MCI','LMCI','AD']
model = densenet121(channels=1, num_classes=len(class_names), drop_rate=0.7).to(device)
model = medcam.inject(model, output_dir="attention_maps", backend='ggcam', label=4, save_maps=True, metric='wioa')
model = torch.nn.DataParallel(model).to(device)
model.load_state_dict(torch.load('../../Alzheimer-ResNets/results-6-2-2020-extended/cuda-epoch-109-alzheimer-densenet121.pth'))
According to the documentation layer default value is 'auto'.  And the library was saying "Selected module layer: features".  Therefore, I believe I was not using a middle layer.  Am I right?

Also, if I use ggcamp I obtain an axial result but my input was sagittal. It is not a big issue, it's just a matter of rotating, but it was not intuitive.

Hmm, I will have a look into this within the next days.

Did you look into this?
I appreciate very much your work.  Thank you.
Best regards,
Braulio  J. Solano-Rojas

Hi bsolano
Did you manage to solve the problem of overlaying attention maps on the 3D input volume. I am facing the same problem. In my case I get 6x6x6 sized attention maps from the last convolution layer. My input volume to the network is 110x110x110. I am not sure how to overlay these attention maps on the input volume of images. Your help in this regard will be appreciated.
Thank you


[SPARK-47538][BUILD] Remove commons-logging dependency

What changes were proposed in this pull request?
This PR aims to remove commons-logging dependency in favor of jcl-over-slf4j.
Why are the changes needed?

https://slf4j.org/legacy.html#jclOverSLF4J

To ease migration to SLF4J from JCL, SLF4J distributions include the jar file jcl-over-slf4j.jar. This jar file is intended as a drop-in replacement for JCL version 1.1.1. It implements the public API of JCL but using SLF4J underneath, hence the name "JCL over SLF4J."

Does this PR introduce any user-facing change?
No.
How was this patch tested?
Pass the CIs.
Was this patch authored or co-authored using generative AI tooling?
No.

https://slf4j.org/legacy.html#jclOverSLF4J
jcl-over-slf4j is intended as a drop-in replacement for commons-logging, maybe we should exclude commons-logging in all places.

Thanks. Let me try that way, @pan3793 .

Thank you, @pan3793 .

All tests passed. Could you review this dependency PR, @yaooqinn ?

Hi @dongjoon-hyun. We can also remove the lines from the NOTICE*/LICENSE*?

Oh, thanks. Sure!

Thank you, @pan3793 , @yaooqinn , @HyukjinKwon !
Merged to master for Apache Spark 4.0.0.


Update to the newest version of all our libraries

I want to patch something in scala-storage…
but that brings in new versions of scalatest and other libraries…
so I tried to update everything else…
and now I'm in dependency hell.
Currently stuck on deprecation errors coming out of Circe.

Yeah, I'm hoping we don't have too many more "move the entire world" PRs like this.

merging as this is passing, and should only have minor conflicts with the PATCH pull request


invalid version: unknown revision loop

This issue occurs in Go 1.18, and 1.19, and several other versions I've tried. To reproduce:
cd `mktemp -d`
go mod init hello
go get github.com/anacrolix/torrent

This gives:
go<EMAIL_ADDRESS>invalid version: unknown revision<PHONE_NUMBER>cb

I know this revision is missing, it likely disappeared in a rebase or something, and may finally have been flushed from the Google proxy. Both the github.com/anacrolix/torrent and github.com/anacrolix/dht/v2 modules depend on each other (but there are no circular package dependencies or it wouldn't compile). I believe they depend on versions that trickle down to the revision that is missing above, but it's not possible to break this cycle. In recent versions I've made both modules depend on versions of each other that shouldn't depend on older versions that trickle down but it doesn't work. You can try my latest attempt to break this cycle via go get github.com/anacrolix/torrent@unknown-dht-version using the reproduce steps above.
The downstream issue is https://github.com/anacrolix/torrent/issues/776.

Go 1.16 helpfully produces more output:
go get<EMAIL_ADDRESS>updating to
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>invalid version: unknown revision<PHONE_NUMBER>cb

CC @bcmills, @matloob.

Duplicate of #48024

Closing as duplicate.
(I'll give some specific guidance on how to resolve the problem on https://github.com/anacrolix/torrent/issues/776 later today — I don't mean to leave you in the lurch!)

This issue has mutated into https://github.com/golang/go/issues/55955.


Complete the initial website  [Feedback thread]

https://github.com/MindTooth/srcery.github.io
Please give feedback.

Moved the site to https://github.com/srcery-colors/srcery.  Continue discussion there.


mbed compile --flash does not respect 'artifact_name'

When using mbed compile --flash, it uses the default binary name for flashing (the parent directory) instead of the one given by the mbed_app.json parameter artifact_name. It correctly generates a binary with the artifact_name during linking.
mbed --version:  1.10.5
mbed_app.json: { artifact_name: "bar", ... }
mbed compile --flash output:
Building project bar (UBLOX_EVK_ODIN_W2, GCC_ARM)
Scan: foo-cwd
Link: bar
Elf2Bin: bar
...
Image: ./BUILD/UBLOX_EVK_ODIN_W2/GCC_ARM/bar.bin
[mbed] ERROR: Build program file (firmware) not found "./BUILD/UBLOX_EVK_ODIN_W2/GCC_ARM/foo-cwd.bin"

Where foo-cwd is the parent directory name and the default name, and bar is the name given by artifact_name in mbed_app.json.

Appending artifact-name as an explicit command line arg works.
mbed compile --flash --artifact-name bar
So this issue is that the value in mbed_app.json is not overriding artifact-name when building the fw_name for this phase.