Missing config in yaml output after using the conversion tool

Versions

Refinery:
https://github.com/honeycombio/refinery/releases/tag/v2.1.0

Steps to reproduce
Config options that are missing or present but commented out after using the conversion tool but are not listed in the comments at the bottom of the file:
logger: type, logger: level, UseTLS and UseIPV6Identifier
V1 file that was input to the conversion tool:
ListenAddr = '<IP_ADDRESS>:8080'
GRPCListenAddr = '<IP_ADDRESS>:4317'
PeerListenAddr = '<IP_ADDRESS>:8081'
CompressPeerCommunication = true
APIKeys = ['*']
HoneycombAPI = 'https://api.honeycomb.io'
SendDelay = '2s'
TraceTimeout = '60s'
MaxBatchSize = 500
SendTicker = '100ms'
LoggingLevel = 'error'
UpstreamBufferSize = 10000
PeerBufferSize = 10000
AddHostMetadataToTrace = true

Collector = 'InMemCollector'
Metrics = 'honeycomb'
Logger = 'honeycomb'

[HoneycombLogger]

LoggerHoneycombAPI = "https://api.honeycomb.io"
LoggerAPIKey = "<Insert API key here>"
LoggerDataset = "Refinery Logs"
LoggerSamplerEnabled = true
LoggerSamplerThroughput = 10

[HoneycombMetrics]

MetricsHoneycombAPI = "https://api.honeycomb.io"
MetricsAPIKey = "<Insert API key here>"
MetricsDataset = "Refinery Metrics"
MetricsReportingInterval = 15

[PeerManagement]
Type = "redis"
RedisHost = "<redis hostname>:6379"
RedisPassword = ""
UseTLS = false

IdentifierInterfaceName = 'eth0'
UseIPV6Identifier = false

[InMemCollector]
MaxAlloc =<PHONE_NUMBER>

CacheCapacity = 640000

V2 config output:
######################################
## Honeycomb Refinery Configuration ##
######################################
#
# created on 2023-10-04 at 03:57:41 UTC from refinery.toml using a template generated on 2023-08-02 at 23:32:03 UTC

# This file contains a configuration for the Honeycomb Refinery. It is in YAML
# format, organized into named groups, each of which contains a set of
# configuration values. Text preceded by two comment characters (##) is
# informational only. Text preceded by a single comment character (#) indicates
# a value that is commented out and not used; it should be uncommented to enable
# it.

###########################
## General Configuration ##
###########################
General:
  ## General contains general configuration options that apply to the
  ## entire Refinery process.
  ####
    ## ConfigurationVersion is the file format of this particular
    ## configuration file.
    ##
    ## This file is version 2.
    ## This field is required. It exists to allow the configuration system to
    ## adapt to future changes in the configuration file format.
    ##
    ## default: 2
    ## Not eligible for live reload.
    ConfigurationVersion: 2

    ## MinRefineryVersion is the minimum version of Refinery that can load
    ## this configuration file.
    ##
    ## This setting specifies the lowest Refinery version capable of loading
    ## all of the features used in this file. If this value is present, then
    ## Refinery will refuse to start if its version is less than this
    ## setting.
    ##
    ## default: v2.0
    ## Not eligible for live reload.
    MinRefineryVersion: v2.0

    ## DatasetPrefix is a prefix that can be used to distinguish a dataset
    ## from an environment in the rules.
    ##
    ## If telemetry is being sent to both a classic dataset and a new
    ## environment called the same thing, such as `production`, then this
    ## parameter can be used to distinguish these cases. When Refinery
    ## receives telemetry using an API key associated with a Honeycomb
    ## Classic dataset, it will then use the prefix in the form `{prefix}.
    ## {dataset}` when trying to resolve the rules definition.
    ##
    ## Not eligible for live reload.
    # DatasetPrefix: ""

    ## ConfigReloadInterval is the average interval between attempts at
    ## reloading the configuration file.
    ##
    ## Refinery will attempt to read its configuration and check for changes
    ## at approximately this interval. This time is varied by a random amount
    ## up to 10% to avoid all instances refreshing together. In installations
    ## where configuration changes are handled by restarting Refinery, which
    ## is often the case when using Kubernetes, disable this feature with a
    ## value of `0s`. If the config file is being loaded from a URL, it may
    ## be wise to increase this value to avoid overloading the file server.
    ##
    ## Accepts a duration string with units, like "15s".
    ## default: 15s
    ## Not eligible for live reload.
    # ConfigReloadInterval: 15s

###########################
## Network Configuration ##
###########################
Network:
  ## Network contains network configuration options.
  ####
    ## ListenAddr is the address where Refinery listens for incoming
    ## requests.
    ##
    ## This setting is the IP and port on which Refinery listens for incoming
    ## HTTP requests. These requests include traffic formatted as Honeycomb
    ## events, proxied requests to the Honeycomb API, and OpenTelemetry data
    ## using the `http` protocol. Incoming traffic is expected to be HTTP, so
    ## if SSL is a requirement, put something like `nginx` in front to do the
    ## decryption.

    # ListenAddr: "<IP_ADDRESS>:8080"

    ## PeerListenAddr is the IP and port on which to listen for traffic being
    ## rerouted from a peer.
    ##
    ## Incoming traffic is expected to be HTTP, so if using SSL use something
    ## like nginx or a load balancer to do the decryption.

    # PeerListenAddr: "<IP_ADDRESS>:8081"

    ## HoneycombAPI is the URL of the upstream Honeycomb API where the data
    ## will be sent.
    ##
    ## This setting is the destination to which Refinery sends all events
    ## that it decides to keep.
    ##
    ## default: https://api.honeycomb.io
    ## Eligible for live reload.
    # HoneycombAPI: "https://api.honeycomb.io"

##############################
## Access Key Configuration ##
##############################
AccessKeys:
  ## AccessKeys contains access keys -- API keys that the proxy will treat
  ## specially, and other flags that control how the proxy handles API
  ## keys.
  ##
  ####
    ## ReceiveKeys is a set of Honeycomb API keys that the proxy will treat
    ## specially.
    ##
    ## This list only applies to span traffic - other Honeycomb API actions
    ## will be proxied through to the upstream API directly without modifying
    ## keys.
    ##
    ## Not eligible for live reload.
    ReceiveKeys:
      - *

    ## AcceptOnlyListedKeys is a boolean flag that causes events arriving
    ## with API keys not in the `ReceiveKeys` list to be rejected.
    ##
    ## If `true`, then only traffic using the keys listed in `ReceiveKeys` is
    ## accepted. Events arriving with API keys not in the `ReceiveKeys` list
    ## will be rejected with an HTTP `401` error.
    ## If `false`, then all traffic is accepted and `ReceiveKeys` is ignored.
    ##
    ## Eligible for live reload.
    # AcceptOnlyListedKeys: false

########################
## Refinery Telemetry ##
########################
RefineryTelemetry:
  ## RefineryTelemetry contains configuration information for the telemetry
  ## that Refinery uses to record its own operation.
  ####
    ## AddRuleReasonToTrace controls whether to decorate traces with Refinery
    ## rule evaluation results.
    ##
    ## When enabled, this setting causes traces that are sent to Honeycomb to
    ## include the field `meta.refinery.reason`. This field contains text
    ## indicating which rule was evaluated that caused the trace to be
    ## included.
    ## This setting also includes the field `meta.refinery.send_reason`,
    ## which contains the reason that the trace was sent. Possible values of
    ## this field are `trace_send_got_root`, which means that the root span
    ## arrived; `trace_send_expired`, which means that TraceTimeout was
    ## reached; `trace_send_ejected_full`, which means that the trace cache
    ## was full; and `trace_send_ejected_memsize`, which means that refinery
    ## was out of memory.
    ## These names are also the names of metrics that refinery tracks.
    ## We recommend enabling this setting whenever a rules-based sampler is
    ## in use, as it is useful for debugging and understanding the behavior
    ## of your Refinery installation.
    ##
    ## Eligible for live reload.
    # AddRuleReasonToTrace: false

    ## AddSpanCountToRoot controls whether to add a metadata field to root
    ## spans that indicates the number of child spans.
    ##
    ## The added metadata field, `meta.span_count`, indicates the number of
    ## child spans on the trace at the time the sampling decision was made.
    ## This value is available to the rules-based sampler, making it possible
    ## to write rules that are dependent upon the number of spans in the
    ## trace. If `true`, then Refinery will add `meta. span_count` to the
    ## root span.
    ##
    ## default: true
    ## Eligible for live reload.
    # AddSpanCountToRoot: true

    ## AddHostMetadataToTrace specifies whether to add host metadata to
    ## traces.
    ##
    ## If `true`, then Refinery will add the following tag to all traces: -
    ## `meta.refinery.local_hostname`: the hostname of the Refinery node
    ##
    ## default: true
    ## Eligible for live reload.
    # AddHostMetadataToTrace: true

############
## Traces ##
############
Traces:
  ## Traces contains configuration for how traces are managed.
  ####
    ## SendDelay is the duration to wait before sending a trace.
    ##
    ## This setting is a short timer that is triggered when a trace is
    ## complete. Refinery waits for this duration before sending the trace.
    ## The reason for this setting is to allow for small network delays or
    ## clock jitters to elapse and any final spans to arrive before sending
    ## the trace. Set to "0" for immediate sending.
    ##
    ## Accepts a duration string with units, like "2s".
    ## default: 2s
    ## Eligible for live reload.
    # SendDelay: 2s

    ## BatchTimeout is how frequently Refinery sends unfulfilled batches.
    ##
    ## By default, this setting uses the `DefaultBatchTimeout` in `libhoney`
    ## as its value, which is `100ms`.
    ##
    ## Accepts a duration string with units, like "500ms".
    ## Eligible for live reload.
    # BatchTimeout: 500ms

    ## TraceTimeout is the duration to wait before making the trace decision
    ## on an incomplete trace.
    ##
    ## A long timer; it represents the outside boundary of how long to wait
    ## before making the trace decision about an incomplete trace.
    ## Normally trace decisions (send or drop) are made when the root span
    ## arrives. Sometimes the root span never arrives (for example, due to
    ## crashes) and this timer ensures sending a trace even without having
    ## received the root span.
    ## If particularly long-lived traces are present in your data, then you
    ## should increase this timer. Note that this increase will also increase
    ## the memory requirements for Refinery.
    ##
    ## Accepts a duration string with units, like "60s".
    ## default: 60s
    ## Eligible for live reload.
    # TraceTimeout: 60s

    ## MaxBatchSize is the maximum number of events to be included in each
    ## batch for sending.
    ##
    ## This value is used to set the `BatchSize` field in the `libhoney`
    ## library used to send data to Honeycomb.
    ## If you have particularly large traces, then you should increase this
    ## value. Note that this will also increase the memory requirements for
    ## Refinery.
    ##
    ## default: 500
    ## Eligible for live reload.
    # MaxBatchSize: 500

    ## SendTicker is the interval between checks for traces to send.
    ##
    ## A short timer that determines the duration between trace cache review
    ## runs to send. Increasing this will spend more time processing incoming
    ## events to reduce `incoming_` or `peer_router_dropped` spikes.
    ## Decreasing this will check the trace cache for timeouts more
    ## frequently.
    ##
    ## Accepts a duration string with units, like "100ms".
    ## default: 100ms
    ## Eligible for live reload.
    # SendTicker: 100ms

###############
## Debugging ##
###############
Debugging:
  ## Debugging contains configuration values used when setting up and
  ## debugging Refinery.
  ####
    ## DebugServiceAddr is the IP and port where the debug service runs.
    ##
    ## The debug service is generally only used when debugging Refinery
    ## itself, and will only run if the command line option `-d` is
    ## specified. If this value is not specified, then the debug service runs
    ## on the first open port between `localhost:6060` and `localhost:6069`.
    ##
    ## Should be an ip:port like "localhost:6060".
    ## Not eligible for live reload.
    # DebugServiceAddr: "localhost:6060"

    ## QueryAuthToken is the token that must be specified to access the
    ## `/query` endpoint.
    ##
    ## This token must be specified with the header
    ## "X-Honeycomb-Refinery-Query" in order for a `/query` request to
    ## succeed. These `/query` requests are intended for debugging Refinery
    ## during setup and are not typically needed in normal operation. If not
    ## specified, then the `/query` endpoints are inaccessible.
    ##
    ## Not eligible for live reload.
    # QueryAuthToken: "some-private-value"

    ## AdditionalErrorFields is a list of span fields to include when logging
    ## errors happen during the ingestion of events.
    ##
    ## For example, the span too large error. This is primarily useful in
    ## trying to track down misbehaving senders in a large installation. The
    ## fields `dataset`, `apihost`, and `environment` are always included. If
    ## a field is not present in the span, then it will not be present in the
    ## error log.
    ##
    ## Eligible for live reload.
    # AdditionalErrorFields:
      # - trace.span_id

    ## DryRun controls whether sampling is applied to incoming traces.
    ##
    ## If enabled, then Refinery marks the traces that would be dropped given
    ## the current sampling rules, and sends all traces regardless of the
    ## sampling decision. This is useful for evaluating sampling rules.
    ## When DryRun is enabled, traces is decorated with `meta.refinery.
    ## dryrun.kept` that is set to `true` or `false`, based on whether the
    ## trace would be kept or dropped. In addition, `SampleRate` will be set
    ## to the incoming rate for all traces, and the field
    ## `meta.refinery.dryrun.sample_rate` will be set to the sample rate that
    ## would have been used.
    ##
    ## Eligible for live reload.
    # DryRun: true

#####################
## Refinery Logger ##
#####################
Logger:
  ## Logger contains configuration for logging.
  ####
    ## Type is the type of logger to use.
    ##
    ## The setting specifies where (and if) Refinery sends logs.
    ## `none` means that logs are discarded.
    ## `honeycomb` means that logs will be forwarded to Honeycomb as events
    ## according to the set Logging settings.
    ## `stdout` means that logs will be written to `stdout`.
    ##
    ## default: stdout
    ## Not eligible for live reload.
    ## Options: stdout honeycomb none
    # Type: stdout

    ## Level is the logging level above which Refinery should send a log to
    ## the logger.
    ##
    ## `warn` is the recommended level for production.
    ## `debug` is very verbose, and should not be used in production
    ## environments.
    ##
    ## default: warn
    ## Not eligible for live reload.
    ## Options: debug info warn error panic
    # Level: warn

######################
## Honeycomb Logger ##
######################
HoneycombLogger:
  ## HoneycombLogger contains configuration for logging to Honeycomb. Only
  ## used if `Logger.Type` is "honeycomb".
  ####
    ## APIHost is the URL of the Honeycomb API where Refinery sends its logs.
    ##
    ## Refinery's internal logs will be sent to this host using the standard
    ## Honeycomb Events API.
    ##
    ## default: https://api.honeycomb.io
    ## Not eligible for live reload.
    # APIHost: "https://api.honeycomb.io"

    ## APIKey is the API key used to send Refinery's logs to Honeycomb.
    ##
    ## It is recommended that you create a separate team and key for Refinery
    ## logs.
    ##
    ## Not eligible for live reload.
    APIKey: <API KEY REDACTED>

    ## Dataset is the dataset to which logs will be sent.
    ##
    ## Only used if `APIKey` is specified.
    ##
    ## default: Refinery Logs
    ## Not eligible for live reload.
    Dataset: "Refinery Logs"

    ## SamplerEnabled controls whether logs are sampled before sending to
    ## Honeycomb.
    ##
    ## The sample rate is controlled by the `SamplerThroughput` setting.
    ##
    ## default: true
    ## Not eligible for live reload.
    # SamplerEnabled: true

    ## SamplerThroughput is the sampling throughput for logs in events per
    ## second.
    ##
    ## The sampling algorithm attempts to make sure that the average
    ## throughput approximates this value, while also ensuring that all
    ## unique logs arrive at Honeycomb at least once per sampling period.
    ##
    ## default: 10
    ## Not eligible for live reload.
    # SamplerThroughput: 10

###################
## Stdout Logger ##
###################
StdoutLogger:
  ## StdoutLogger contains configuration for logging to `stdout`. Only used
  ## if `Logger.Type` is "stdout".
  ####
    ## Structured controls whether to use structured logging.
    ##
    ## `true` generates structured logs (JSON). `false` generates plain text
    ## logs.
    ##
    ## default: true
    ## Not eligible for live reload.
    # Structured: true

########################
## Prometheus Metrics ##
########################
PrometheusMetrics:
  ## PrometheusMetrics contains configuration for Refinery's
  ## internally-generated metrics as made available through Prometheus.
  ####
    ## Enabled controls whether to expose Refinery metrics over the
    ## `PrometheusListenAddr` port.
    ##
    ## Each of the metrics providers can be enabled or disabled
    ## independently. Metrics can be sent to multiple destinations.
    ##
    ## Not eligible for live reload.
    # Enabled: false

    ## ListenAddr is the IP and port the Prometheus Metrics server will run
    ## on.
    ##
    ## Determines the interface and port on which Prometheus will listen for
    ## requests for `/metrics`. Must be different from the main Refinery
    ## listener. Only used if `Enabled` is `true` in `PrometheusMetrics`.

    # ListenAddr: "localhost:2112"

####################
## Legacy Metrics ##
####################
LegacyMetrics:
  ## LegacyMetrics contains configuration for Refinery's legacy metrics.
  ## Version 1.x of Refinery used this format for sending Metrics to
  ## Honeycomb. The metrics generated that way are nonstandard and will be
  ## deprecated in a future release. New installations should prefer
  ## `OTelMetrics`.
  ##
  ####
    ## Enabled controls whether to send legacy-formatted metrics to
    ## Honeycomb.
    ##
    ## Each of the metrics providers can be enabled or disabled
    ## independently. Metrics can be sent to multiple destinations.
    ##
    ## Not eligible for live reload.
    Enabled: true

    ## APIHost is the URL of the Honeycomb API where legacy metrics are sent.
    ##
    ## Refinery's internal metrics will be sent to this host using the
    ## standard Honeycomb Events API.
    ##
    ## default: https://api.honeycomb.io
    ## Not eligible for live reload.
    # APIHost: "https://api.honeycomb.io"

    ## APIKey is the API key used by Refinery to send its metrics to
    ## Honeycomb.
    ##
    ## It is recommended that you create a separate team and key for Refinery
    ## metrics.
    ##
    ## Not eligible for live reload.
    APIKey: <API KEY REDACTED>

    ## Dataset is the Honeycomb dataset where Refinery sends its metrics.
    ##
    ## Only used if `APIKey` is specified.
    ##
    ## default: Refinery Metrics
    ## Not eligible for live reload.
    # Dataset: "Refinery Metrics"

    ## ReportingInterval is the interval between sending legacy metrics to
    ## Honeycomb.
    ##
    ## Between 1 and 60 seconds is typical.
    ##
    ## Accepts a duration string with units, like "30s".
    ## default: 30s
    ## Not eligible for live reload.
    ReportingInterval: 15s

###########################
## OpenTelemetry Metrics ##
###########################
OTelMetrics:
  ## OTelMetrics contains configuration for Refinery's OpenTelemetry (OTel)
  ## metrics. This is the preferred way to send metrics to Honeycomb. New
  ## installations should prefer `OTelMetrics`.
  ##
  ####
    ## Enabled controls whether to send metrics via OpenTelemetry.
    ##
    ## Each of the metrics providers can be enabled or disabled
    ## independently. Metrics can be sent to multiple destinations.
    ##
    ## Not eligible for live reload.
    # Enabled: false

    ## APIHost is the URL of the OpenTelemetry API to which metrics will be
    ## sent.
    ##
    ## Refinery's internal metrics will be sent to the `/v1/metrics` endpoint
    ## on this host.
    ##
    ## default: https://api.honeycomb.io
    ## Not eligible for live reload.
    # APIHost: "https://api.honeycomb.io"

    ## APIKey is the API key used to send Honeycomb metrics via
    ## OpenTelemetry.
    ##
    ## It is recommended that you create a separate team and key for Refinery
    ## metrics.
    ## If this is blank, then Refinery will not set the Honeycomb-specific
    ## headers for OpenTelemetry, and your `APIHost` must be set to a valid
    ## OpenTelemetry endpoint.
    ##
    ## Not eligible for live reload.
    # APIKey: ""

    ## Dataset is the Honeycomb dataset that Refinery sends its OpenTelemetry
    ## metrics.
    ##
    ## Only used if `APIKey` is specified.
    ##
    ## default: Refinery Metrics
    ## Not eligible for live reload.
    # Dataset: "Refinery Metrics"

    ## ReportingInterval is the interval between sending OpenTelemetry
    ## metrics to Honeycomb.
    ##
    ## Between `1` and `60` seconds is typical.
    ##
    ## Accepts a duration string with units, like "30s".
    ## default: 30s
    ## Not eligible for live reload.
    # ReportingInterval: ""

    ## Compression is the compression algorithm to use when sending
    ## OpenTelemetry metrics to Honeycomb.
    ##
    ## `gzip` is the default and recommended value. In rare circumstances,
    ## compression costs may outweigh the benefits, in which case `none` may
    ## be used.
    ##
    ## default: gzip
    ## Not eligible for live reload.
    ## Options: none gzip
    # Compression: gzip

#####################
## Peer Management ##
#####################
PeerManagement:
  ## PeerManagement controls how the Refinery cluster communicates between
  ## peers.
  ####
    ## Type is the type of peer management to use.
    ##
    ## Peer management is the mechanism by which Refinery locates its peers.
    ## `file` means that Refinery gets its peer list from the Peers list in
    ## this config file.
    ## `redis` means that Refinery self-registers with a Redis instance and
    ## gets its peer list from there.
    ##
    ## default: file
    ## Not eligible for live reload.
    ## Options: redis file
    Type: redis

    ## Identifier specifies the identifier to use when registering itself
    ## with peers.
    ##
    ## By default, when using a peer registry, Refinery will use the local
    ## hostname to identify itself to other peers. If your environment
    ## requires something else, (for example, if peers cannot resolve each
    ## other by name), then you can specify the exact identifier, such as an
    ## IP address, to use here. Overrides `IdentifierInterfaceName`, if both
    ## are set.
    ##
    ## Not eligible for live reload.
    # Identifier: "<IP>"

    ## IdentifierInterfaceName specifies a network interface to use when
    ## finding a local hostname.
    ##
    ## By default, when using a peer registry, Refinery will use the local
    ## hostname to identify itself to other peers. If your environment
    ## requires that you use IPs as identifiers (for example, if peers cannot
    ## resolve each other by name), then you can specify the network
    ## interface that Refinery is listening on here. Refinery will use the
    ## first unicast address that it finds on the specified network interface
    ## as its identifier.
    ##
    ## Not eligible for live reload.
    IdentifierInterfaceName: eth0

    ## UseIPV6Identifier specifies that Refinery should use an IPV6 address
    ## as its identifier.
    ##
    ## If using `IdentifierInterfaceName`, Refinery will default to the first
    ## IPv4 unicast address it finds for the specified interface. If this
    ## value is specified, then Refinery will use the first IPV6 unicast
    ## address found.
    ##
    ## Not eligible for live reload.
    # UseIPV6Identifier: false

    ## Peers is the list of peers to use when Type is "file", excluding self.
    ##
    ## This list is ignored when Type is "redis". The format is a list of
    ## strings of the form "host:port".
    ##
    ## Not eligible for live reload.
    # Peers:
      # - <IP>
      # - <IP>

###########################
## Redis Peer Management ##
###########################
RedisPeerManagement:
  ## RedisPeerManagement controls how the Refinery cluster communicates
  ## between peers when using Redis. Only applies when
  ## `PeerManagement.Type` is "redis".
  ##
  ####
    ## Host is the host and port of the Redis instance to use for peer
    ## cluster membership management.
    ##
    ## Must be in the form `host:port`.
    ##
    ## Should be an ip:port like "localhost:6379".
    ## Not eligible for live reload.
    Host: "<host>"

    ## Username is the username used to connect to Redis for peer cluster
    ## membership management.
    ##
    ## Many Redis installations do not use this field.
    ##
    ## Not eligible for live reload.
    # Username: ""

    ## Password is the password used to connect to Redis for peer cluster
    ## membership management.
    ##
    ## Many Redis installations do not use this field.
    ##
    ## Not eligible for live reload.
    # Password: ""

    ## Prefix is a string used as a prefix for the keys in Redis while
    ## storing the peer membership.
    ##
    ## It might be useful to override this in any situation where multiple
    ## Refinery clusters or multiple applications want to share a single
    ## Redis instance. It may not be blank.
    ##
    ## default: refinery
    ## Not eligible for live reload.
    # Prefix: refinery

    ## Database is the database number to use for the Redis instance storing
    ## the peer membership.
    ##
    ## An integer from 0-15 indicating the database number to use for the
    ## Redis instance storing the peer membership. It might be useful to set
    ## this in any situation where multiple Refinery clusters or multiple
    ## applications want to share a single Redis instance.
    ##
    ## Not eligible for live reload.
    # Database: 0

    ## UseTLS enables TLS when connecting to Redis for peer cluster
    ## membership management.
    ##
    ## When enabled, this setting sets the `MinVersion` in the TLS
    ## configuration to `1.2`.
    ##
    ## Not eligible for live reload.
    # UseTLS: false

    ## UseTLSInsecure disables certificate checks when connecting to Redis
    ## for peer cluster membership management.
    ##
    ## This setting is intended for use with self-signed certificates and
    ## sets the `InsecureSkipVerify` flag within Redis.
    ##
    ## Not eligible for live reload.
    # UseTLSInsecure: false

    ## Timeout is the timeout to use when communicating with Redis.
    ##
    ## It is rarely necessary to adjust this value.
    ##
    ## Accepts a duration string with units, like "5s".
    ## default: 5s
    ## Not eligible for live reload.
    # Timeout: 5s

#########################
## Collection Settings ##
#########################
Collection:
  ## Collection contains the settings that are relevant to collecting spans
  ## together to make traces. If none of the memory settings are used, then
  ## Refinery will not attempt to limit its memory usage. This is not
  ## recommended for production use since a burst of traffic could cause
  ## Refinery to run out of memory and crash.
  ##
  ####
    ## CacheCapacity is the number of traces to keep in the cache's circular
    ## buffer.
    ##
    ## The collection cache is used to collect all spans into a trace as well
    ## as remember the sampling decision for any spans that might come in
    ## after the trace has been marked "complete" (either by timing out or
    ## seeing the root span). The number of traces in the cache should be
    ## many multiples (100x to 1000x) of the total number of concurrently
    ## active traces (trace throughput * trace duration).
    ##
    ## default: 10000
    ## Eligible for live reload.
    CacheCapacity: 640000

    ## AvailableMemory is the amount of system memory available to the
    ## Refinery process.
    ##
    ## This value will typically be set through an environment variable
    ## controlled by the container or deploy script. If this value is zero or
    ## not set, then `MaxMemory` cannot be used to calculate the maximum
    ## allocation and `MaxAlloc` will be used instead. If set, then this must
    ## be a memory size. 64-bit values are supported. Sizes with standard
    ## unit suffixes (`MB`, `GiB`, etc.) and Kubernetes units (`M`, `Gi`,
    ## etc.) are also supported. If set, `Collections.MaxAlloc` must not be
    ## defined.
    ##
    ## Eligible for live reload.
    # AvailableMemory: 4Gb

    ## MaxMemoryPercentage is the maximum percentage of memory that should be
    ## allocated by the span collector.
    ##
    ## If nonzero, then it must be an integer value between 1 and 100,
    ## representing the target maximum percentage of memory that should be
    ## allocated by the span collector. If set to a non-zero value, then once
    ## per tick (see `SendTicker`) the collector will compare total allocated
    ## bytes to this calculated value. If allocation is too high, then traces
    ## will be ejected from the cache early to reduce memory. Useful values
    ## for this setting are generally in the range of 70-90.
    ##
    ## default: 75
    ## Eligible for live reload.
    # MaxMemoryPercentage: 75

    ## MaxAlloc is the maximum number of bytes that should be allocated by
    ## the Collector.
    ##
    ## If set, then this must be a memory size. 64-bit values are supported.
    ## Sizes with standard unit suffixes (`MB`, `GiB`, etc) and Kubernetes
    ## units (`M`, `Gi`, etc) are also supported. See `MaxMemory` for more
    ## details. If set, `Collections.AvailableMemory` must not be defined.
    ##
    ## Eligible for live reload.
    MaxAlloc: 6400M

##################
## Buffer Sizes ##
##################
BufferSizes:
  ## BufferSizes contains the settings that are relevant to the sizes of
  ## communications buffers.
  ##
  ####
    ## UpstreamBufferSize is the size of the queue used to buffer spans to
    ## send to the upstream Collector.
    ##
    ## The size of the buffer is measured in spans. If the buffer fills up,
    ## then performance will degrade because Refinery will block while
    ## waiting for space to become available. If this happens, then you
    ## should increase the buffer size.
    ##
    ## default: 10000
    ## Eligible for live reload.
    # UpstreamBufferSize: 10_000

    ## PeerBufferSize is the size of the queue used to buffer spans to send
    ## to peer nodes.
    ##
    ## The size of the buffer is measured in spans. If the buffer fills up,
    ## then performance will degrade because Refinery will block while
    ## waiting for space to become available. If this happens, then you
    ## should increase this buffer size.
    ##
    ## default: 100000
    ## Eligible for live reload.
    PeerBufferSize: 10000

###############################
## Specialized Configuration ##
###############################
Specialized:
  ## Specialized contains special-purpose configuration options that are
  ## not typically needed.
  ####
    ## EnvironmentCacheTTL is the duration for which environment information
    ## is cached.
    ##
    ## This is the amount of time for which Refinery caches environment
    ## information, which it looks up from Honeycomb for each different
    ## `APIKey`. This information is used when making sampling decisions. If
    ## you have a very large number of environments, then you may want to
    ## increase this value.
    ##
    ## Accepts a duration string with units, like "1h".
    ## default: 1h
    ## Eligible for live reload.
    # EnvironmentCacheTTL: 1h

    ## CompressPeerCommunication determines whether Refinery will compress
    ## span data it forwards to peers.
    ##
    ## If it costs money to transmit data between Refinery instances (for
    ## example, when spread across AWS availability zones), then you almost
    ## certainly want compression enabled to reduce your bill. The option to
    ## disable it is provided as an escape hatch for deployments that value
    ## lower CPU utilization over data transfer costs.
    ##
    ## default: true
    ## Not eligible for live reload.
    # CompressPeerCommunication: true

    ## AdditionalAttributes is a map that can be used for injecting
    ## user-defined attributes into every span.
    ##
    ## For example, it could be used for naming a Refinery cluster. Both keys
    ## and values must be strings.
    ##
    ## Eligible for live reload.
    # AdditionalAttributes:
      #  ClusterName: MyCluster
      #  environment: production

###############
## ID Fields ##
###############
IDFields:
  ## IDFields controls the field names to use for the event ID fields.
  ## These fields are used to identify events that are part of the same
  ## trace.
  ##
  ####
    ## TraceNames is the list of field names to use for the trace ID.
    ##
    ## The first field in the list that is present in an incoming span will
    ## be used as the trace ID. If none of the fields are present, then
    ## Refinery treats the span as not being part of a trace and forwards it
    ## immediately to Honeycomb.
    ##
    ## Eligible for live reload.
    # TraceNames:
      # - trace.trace_id
      # - traceId

    ## ParentNames is the list of field names to use for the parent ID.
    ##
    ## The first field in the list that is present in an event will be used
    ## as the parent ID. A trace without a `parent_id` is assumed to be a
    ## root span.
    ##
    ## Eligible for live reload.
    # ParentNames:
      # - trace.parent_id
      # - parentId

############################
## gRPC Server Parameters ##
############################
GRPCServerParameters:
  ## GRPCServerParameters controls the parameters of the gRPC server used
  ## to receive OpenTelemetry data in gRPC format.
  ##
  ####
    ## Enabled specifies whether the gRPC server is enabled.
    ##
    ## If `false`, then the gRPC server is not started and no gRPC traffic is
    ## accepted.
    ##
    ## Not eligible for live reload.
    Enabled: true

    ## ListenAddr is the address Refinery listens to for incoming GRPC
    ## OpenTelemetry events.
    ##
    ## Incoming traffic is expected to be unencrypted, so if using SSL, then
    ## put something like `nginx` in front to do the decryption.

    ## Not eligible for live reload.
    ListenAddr: "<IP_ADDRESS>:4317"

    ## MaxConnectionIdle is the amount of time to permit an idle connection.
    ##
    ## A duration for the amount of time after which an idle connection will
    ## be closed by sending a GoAway. "Idle" means that there are no active
    ## RPCs. "0s" sets duration to infinity, but this is not recommended for
    ## Refinery deployments behind a load balancer, because it will prevent
    ## the load balancer from distributing load evenly among peers.
    ##
    ## Accepts a duration string with units, like "0s".
    ## default: 0s
    ## Not eligible for live reload.
    # MaxConnectionIdle: 0s

    ## MaxConnectionAge is the maximum amount of time a gRPC connection may
    ## exist.
    ##
    ## After this duration, the gRPC connection is closed by sending a
    ## `GoAway`. A random jitter of +/-10% will be added to
    ## `MaxConnectionAge` to spread out connection storms.
    ## `0s` sets duration to infinity; a value measured in low minutes will
    ## help load balancers to distribute load among peers more evenly.
    ##
    ## Accepts a duration string with units, like "3m".
    ## default: 3m
    ## Not eligible for live reload.
    # MaxConnectionAge: 3m

    ## MaxConnectionAgeGrace is the duration beyond `MaxConnectionAge` after
    ## which the connection will be forcibly closed.
    ##
    ## This setting is in case the upstream node ignores the `GoAway`
    ## request. "0s" sets duration to infinity.
    ##
    ## Accepts a duration string with units, like "60s".
    ## default: 60s
    ## Not eligible for live reload.
    # MaxConnectionAgeGrace: 60s

    ## KeepAlive is the duration between keep-alive pings.
    ##
    ## After this amount of time, if the client does not see any activity,
    ## then it pings the server to see if the transport is still alive. "0s"
    ## sets duration to 2 hours.
    ##
    ## Accepts a duration string with units, like "1m".
    ## default: 1m
    ## Not eligible for live reload.
    # KeepAlive: 1m

    ## KeepAliveTimeout is the duration the server waits for activity on the
    ## connection.
    ##
    ## This is the amount of time after which if the server does not see any
    ## activity, then it pings the client to see if the transport is still
    ## alive. "0s" sets duration to 20 seconds.
    ##
    ## Accepts a duration string with units, like "20s".
    ## default: 20s
    ## Not eligible for live reload.
    # KeepAliveTimeout: 20s

##################
## Sample Cache ##
##################
SampleCache:
  ## SampleCache controls the sample cache used to retain information about
  ## trace status after the sampling decision has been made.
  ##
  ####
    ## KeptSize is the number of traces preserved in the cuckoo kept traces
    ## cache.
    ##
    ## Refinery keeps a record of each trace that was kept and sent to
    ## Honeycomb, along with some statistical information. This is most
    ## useful in cases where the trace was sent before sending the root span,
    ## so that the root span can be decorated with accurate metadata. Default
    ## is `10_000` traces. Each trace in this cache consumes roughly 200
    ## bytes.
    ##
    ## default: 10000
    ## Eligible for live reload.
    # KeptSize: 10_000

    ## DroppedSize is the size of the cuckoo dropped traces cache.
    ##
    ## This cache consumes 4-6 bytes per trace at a scale of millions of
    ## traces. Changing its size with live reload sets a future limit, but
    ## does not have an immediate effect.
    ##
    ## default: 1000000
    ## Eligible for live reload.
    # DroppedSize: 1_000_000

    ## SizeCheckInterval controls how often the cuckoo cache re-evaluates its
    ## remaining capacity.
    ##
    ## This cache is quite resilient so it does not need to happen very
    ## often, but the operation is also inexpensive. Default is 10 seconds.
    ##
    ## Accepts a duration string with units, like "10s".
    ## default: 10s
    ## Eligible for live reload.
    # SizeCheckInterval: 10s

###################
## Stress Relief ##
###################
StressRelief:
  ## StressRelief controls the Stress Relief mechanism, which is used to
  ## prevent Refinery from being overwhelmed by a large number of traces.
  ## There is a metric called `stress_level` that is emitted as part of
  ## Refinery metrics. It is a measure of Refinery's throughput rate
  ## relative to its processing rate, combined with the amount of room in
  ## its internal queues, and ranges from `0` to `100`. `stress_level` is
  ## generally expected to be `0` except under heavy load. When stress
  ## levels reach `100`, there is an increased chance that Refinery will
  ## become unstable.
  ## To avoid this problem, the Stress Relief system can do deterministic
  ## sampling on new trace traffic based solely on `TraceID`, without
  ## having to store traces in the cache or take the time processing
  ## sampling rules. Existing traces in flight will be processed normally,
  ## but when Stress Relief is active, trace decisions are made
  ## deterministically on a per-span basis; all spans will be sampled
  ## according to the `SamplingRate` specified here.
  ## Once Stress Relief activates (by exceeding the `ActivationLevel`), it
  ## will not deactivate until `stress_level` falls below the
  ## `DeactivationLevel`. When it deactivates, normal trace decisions are
  ## made -- and any additional spans that arrive for traces that were
  ## active during Stress Relief will respect the decisions made during
  ## that time.
  ## The measurement of stress is a lagging indicator and is highly
  ## dependent on Refinery configuration and scaling. Other configuration
  ## values should be well tuned first, before adjusting the Stress Relief
  ## Activation parameters.
  ## Stress Relief is not a substitute for proper configuration and
  ## scaling, but it can be used as a safety valve to prevent Refinery from
  ## becoming unstable under heavy load.
  ##
  ####
    ## Mode is a string indicating how to use Stress Relief.
    ##
    ## This setting sets the Stress Relief mode.
    ## "never" means that Stress Relief will never activate.
    ## "monitor" is the recommended setting, and means that Stress Relief
    ## will monitor the status of Refinery and activate according to the
    ## levels set by fields such as `ActivationLevel`.
    ## "always" means that Stress Relief is always on, which may be useful in
    ## an emergency situation.
    ##
    ## default: never
    ## Eligible for live reload.
    # Mode: never

    ## ActivationLevel is the `stress_level` (from 0-100) at which Stress
    ## Relief is triggered.
    ##
    ## This value must be greater than `DeactivationLevel` and should be high
    ## enough that it is not reached in normal operation.
    ##
    ## default: 90
    ## Eligible for live reload.
    # ActivationLevel: 90

    ## DeactivationLevel is the `stress_level` (from 0-100) at which Stress
    ## Relief is turned off.
    ##
    ## This setting is subject to `MinimumActivationDuration`. The value must
    ## be less than `ActivationLevel`.
    ##
    ## default: 70
    ## Eligible for live reload.
    # DeactivationLevel: 70

    ## SamplingRate is the sampling rate to use when Stress Relief is
    ## activated.
    ##
    ## All new traces will be deterministically sampled at this rate based
    ## only on the `traceID`. It should be chosen to be a rate that sends
    ## fewer samples than the average sampling rate Refinery is expected to
    ## generate.
    ## For example, if Refinery is configured to normally sample at a rate of
    ## 1 in 10, then Stress Relief should be configured to sample at a rate
    ## of at least 1 in 30.
    ##
    ## default: 100
    ## Eligible for live reload.
    # SamplingRate: 100

    ## MinimumActivationDuration is the minimum time that Stress Relief will
    ## stay enabled once activated.
    ##
    ## This setting helps to prevent oscillations.
    ##
    ## Accepts a duration string with units, like "10s".
    ## default: 10s
    ## Eligible for live reload.
    # MinimumActivationDuration: 10s

    ## MinimumStartupDuration is the minimum time that Stress Relief will
    ## stay enabled.
    ##
    ## This setting is used when switching into Monitor mode.
    ## When Stress Relief is enabled, it will start up in stressed mode for
    ## at least this set duration of time to try to make sure that Refinery
    ## can handle the load before it begins processing it in earnest. This is
    ## to help address the problem of trying to bring a new node into an
    ## already-overloaded cluster.
    ## If this duration is `0`, then Refinery will not start in stressed
    ## mode, which will provide faster startup at the possible cost of
    ## startup instability.
    ##
    ## Accepts a duration string with units, like "3s".
    ## default: 3s
    ## Eligible for live reload.
    # MinimumStartupDuration: 3s

###################################################
## Config values removed by the config converter ##
###################################################
  ## The following configuration options are obsolete and are not included
  ## in the new configuration:
  ##
    ## - PeerManagement.Strategy
    ## - Collector
    ## - InMemCollector.CacheOverrunStrategy
    ## - SampleCacheConfig/SampleCache.Type

@elainemccloskey thanks for bring this to our attention. I was able to reproduce your scenario.  We will continue to investigate.


Columns: Allow to set wrap or no wrap of text per column.

USE CASE
The contents of the cell of a column could be wraped
SOLUTION DESCRIPTION
A new option in the PrimeNG attribute and affects only the front-end of the table.

Final solution.
In the column editor a user can mark "word wrap" per column. From the backend you can declare which columns can be wraped by the user (by default all). The boolean type columns, in the frontend will be always false and disabled for modification since it doesn't make sense (they don't have text).
An example:


Replace SQLAlchemy & Pydantic with SQLModel

Since the author of FastAPI created SQLModel in order to be able to reduce the amount of code being maintained by combining models of both libraries, how about replacing them with an SQLModel based solution? :wink

Hey, @S1SYPHOS, thanks for the issue!
FastAPI supports Pydantic V2 since June 2023, SQLAlchemy is at 2.0+ since January 2023.
SQLModel got proper Pydantic V2 support just last month, SQLAlchemy 2.0 in November 2023.
At least for now, I think this is not the way to go (since Tiangolo is the solo maintainer and FastAPI is the priority, it's very likely that SQLModel will always be far behind Pydantic and SQLAlchemy). Specially since migrating from SQLAlchemy + Pydantic to SQLModel is easier than the other way around. Plus, since SQLModel is just a superset on SQLAlchemy and Pydantic, everything should work properly if you just migrate the models to SQLModel.
It's something I think a lot of people would like though, so I'm thinking about creating a minimal template using SQLModel. What do you think?

Thanks for your thorough explanation, I wasn't quite aware of all points you raised. Also it makes me think about using SQLModel after all 😅
However, having a minimal template (or maybe an commented out example) for people to get going quickly would be super appreciated! 🙏

I think SQLModel is really cool, and it really makes stuff simpler, I stopped using it when FastAPI got Pydantic V2 and SQLModel had no support for it in sight. I still use it when I want to make quick stuff though (building POCs etc).
I'll start creating the SQLModel version as a solution for this issue!

One reason I use SqlAlchemy directly is because I believe SQLModel does not have support async (https://docs.sqlalchemy.org/en/20/orm/extensions/asyncio.html) with SqlAlchemy 2.0, does it? is my understanding correct?

As I'm getting more and more familiar with this project, I see the value of keeping both libraries separate 😅

Thank you very much! May I also express my admiration for your fastcrud project while I'm at it, it's a really cool project!

Thanks, @S1SYPHOS! Really appreciate it.

One reason I use SqlAlchemy directly is because I believe SQLModel does not have support async (https://docs.sqlalchemy.org/en/20/orm/extensions/asyncio.html) with SqlAlchemy 2.0, does it? is my understanding correct?

I see no reason for it not to work, since it's just a superset of sqlalchemy with pydantic compatibility built in.

As I'm getting more and more familiar with this project, I see the value of keeping both libraries separate 😅

It's a really cool idea, I just think it's not there yet.

I'd like to express my admiration for this FastAPI-boilerplate project here. Congratulations, @igorbenav!
I also want to share my project fastapi-async-sqlmodel-boilerplate which was inspired by this project. In it, I've made the necessary migration from SQLAlchemy + Pydantic to SQLModel:
FastAPI Async SQLModel Boilerplate
I'm using it in production, and it's been great.
Hope it helps someone.

Hey, @joaoflaviosantos, really cool. More of a Feature-based structure, plus the sqlmodel part, so another option for everyone!

Hey, guys, SQLModel-boilerplate is live and mentioned in the readme! I'd love for you to give it a try.

Closed by #137

I'll have a look later, thanks!


Unable to be authenticated by gitlab

Preflight Checklist

[x] I agree to follow the Code of Conduct that this project adheres to.
[x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Describe the bug
When I don't use the nginx proxy, the oauth2 authentication by selecting gitlab for the storage is successful to show check page, however if you click Authorize, it will jump to 500. But when I go through the nginx proxy, gitlab always reports an error:
An error has occurred
The authorization server does not support this response type.
Below is my entire nginx configuration file

server {
    listen 80;
    server_name drawio.com;

    location / {
        return 302 https://$server_name$request_uri;
    }
}

server {
    listen 443 ssl;
    server_name drawio.com;

    ssl_certificate /etc/certificate/a.crt;
    ssl_certificate_key /etc/certificate/a.key;

    location / {
        proxy_pass https://1x.xx.xx.xx:28081;
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # Preserve OAuth2 and GitLab authentication parameters
        proxy_set_header Authorization $http_authorization;
        proxy_set_header Cookie $http_cookie;
        proxy_set_header X-Requested-With $http_x_requested_with;
        proxy_set_header Accept $http_accept;
    }
}

To Reproduce
Steps to reproduce the behavior:

Go to main page
Click on Save diagrams to GitLab
Scroll down to 'Create a Blank Diagram'
See error

Expected behavior
Successfully use gitlab for storage
Screenshots

draw.io version (In the Help->About menu of the draw.io editor):

draw.io version 21.0.2 release

Desktop (please complete the following information):

Browser chrome

Additional context
The Request URL between pass nginx or not is:
https://gitlab.com/oauth/authorize?client_id=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&scope=api read_repository write_repository&redirect_uri=https%3A%2F%2Fdrawio.com%2Fgitlab.html&response_type=token&state=123
https://gitlab.com/oauth/authorize?client_id=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&scope=api read_repository write_repository&redirect_uri=https%3A%2F%2Fserver.com:8080%2Fgitlab.html&response_type=code&state=cId%3Dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx%26domain%3Dcom%26token%3D1tkgd9ukh0usl2iiksv2007jes4dfc7h2s87gdpc46hr3dv5510
And I use docker-compose to deploy it.
version: '3.6'
services:
  drawio:
    image: jgraph/drawio
    restart: always
    volumes:
      - ./ca-certificates/:/usr/local/share/ca-certificates/:ro
    ports:
      - '1x.xx.xx.xx:28080:8080'
      - '1x.xx.xx.xx:28081:8443'
    environment:
      - DRAWIO_BASE_URL=https://drawio.com
      - DRAWIO_GITLAB_URL=https://gitlab.com
      - DRAWIO_GITLAB_ID=xxxx
      - DRAWIO_GITLAB_SECRET="xxxx"

I really don't get it, doesn't anyone have such a need? There's been a ton of gitlab configuration questions from a few years ago, but I couldn't even find a complete tutorial, even in the blog at diagrams.net.

I also have this kind of problem. I suspect that the response type does not support “token”.
so did you solve the problem？

No, I give it up. I am currently using obsidian plugin to save my flowchart, and achieve multi-terminal synchronization through obsidian.

No, I give it up. I am currently using obsidian plugin to save my flowchart, and achieve multi-terminal synchronization through obsidian.

Hi,
I'm currently working on this issue. Can you please update me with details on how you setup both gitlab and draw.io (self-hosted, app setting, ...)
I've tried the integration using gitlab.com and self-hosted draw.io instance and it works.
I've used OAuth app (https://docs.gitlab.com/ee/integration/oauth_provider.html) with redirect url as https://drawio.example.com/gitlab (note it's not gitlab.html) also DRAWIO_GITLAB_URL=https://gitlab.com/oauth/token
Note: http support will be added in the next release

@Ch4mpa9ne Might I ask how did you pass gitlab oauth part? What changes did you make to pass auth stage?


Is it a must to upgrade to 0.29?

From yesterday, when I start a new project and run react-native init xxx , if react native version is 0.27 or under in packadge.json, there is always a "RCTBundleURLProvider.h not found" error.
Seems RCTBundleURLProvider.h is a new file came with 0.29, am I right?
Now I am forced to use 0.29 but I still don't know if it can work with my older version's code or plugins.

I have encounter some RCT bundle issue too. I was not able to find the bug in the source file. so I have downgraded to 0.28. Everything seems smooth.

I think it should be encouraged to upgrade to the newest version, 'cause each version contains lots of improvements. :)

As @zhileichen said, each version brings new features and bug fixes although some breaking changes. If your environment allow it, you should definitely update your React Native version.
I'm not sure I understand the part that you run react-native init and if react native version is 0.27 or under?
Don't forget to run the upgrade tool react-native upgrade as described here : Upgrading Documentation.

We support only the latest version of React Native so it's generally a good idea to upgrade. These are some of the tradeoffs to help you make a decision that's right for your use case:
Benefits of upgrading:

Bug fixes usually are committed to the next version of React Native. Sometimes they are cherry picked into the current version and we do a patch release.
Only the latest version and master are supported. So if you're using the latest version and find a bug, we can look into it. Otherwise, we have so many issues that we can't support old versions.
New components and modules may only work on the latest version.

Downsides of upgrading:

React Native updates often. You might want to update only every month instead of every two weeks.
Sometimes there are breaking changes
Community native modules might stop working unless the authors update the modules

I would say that upgrading is usually the right decision unless your app is complete and you don't plan to work on it very much in the future. It does require work to stay up-to-date and sometimes write some native code to keep your native modules working, so keep that cost in mind when choosing to pull in native modules.


Option - Animation option

Allow, throught an option, to specify how the animation should works:

it is moving camera ?
Do objects are moving ?
These animations could be combined. (default: static)

Animation is now an option used by configurable objects and not a real option. Examples:

--stars-dynamic
--camera-dynamic/--camera-dynamic
--planets-dynamic
...


Use absoluteURL instead of relativeURL for next/prev links

Motivation

Fixes #780 & https://github.com/babel/website/issues/1693

Our docs prev/next button is build with relative path in mind. But relative path is really relative
If our current url is https://babeljs.io/docs/en/babel-plugin-transform-runtime
 will translate to https://babeljs.io/docs/en/babel-register
If our current url is https://babeljs.io/docs/en/babel-plugin-transform-runtime/
 will translate to https://babeljs.io/docs/en/babel-plugin-transform-runtime/babel-register which is wrong
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Before
Go to https://docusaurus.io/docs/en/installation/ (notice the ending slash /) and click previous/next button, 404 page

After
Go to http://localhost:3000/docs/en/installation/ and click previous/next button, no problem

@yangshun @JoelMarcey
Actually we always use relative url for next/prev in sidebar.
Docusaurus 1.2.0
https://github.com/facebook/Docusaurus/blob/3755522681bc5ea805be4aa6b06d5dfdf3226ec1/lib/core/DocsLayout.js#L84-L90
Docusaurus < 1.2.0
https://github.com/facebook/Docusaurus/blob/aee255219bedc97b55048cdb4703742cbb7c247e/lib/core/DocsLayout.js#L70-L73
I do feel my solution of removing trail slashes is a bit hacky though 😃.
Anyway, I'm changing it to use absolute URL with my latest commit so this bug will no longer exist 👍

Actually we always use relative url for next/prev in sidebar.

@endiliey Do we have next/prev in sidebar? What I mean is that in the left sidebar nav, we use absolute URLs, which is the approach I feel is better and we should do that for the next/prev buttons within the doc page.

@yangshun Sorry. I mean next/prev button in docs 😢
Anyway, changes updated. We now use absolute URL


From mongo， transactions become irreversible after ~40 second, not ~3 second!

Image: boscore/bos:v3.0.2
Contracts: v3.0.2
Block producers:  3
I send transaction to contract and get trx_id.
Then, I query the transaction pushed from mongodb.  I find: updatedAt - createdAt = 34 seconds.
How to make transaction irreversible in mongdb in 3 seconds.
[root@psn230m2 node]# cl push action ab add '
> {
>     "account": "alice",
>     "name": "lis4",
>     "age":  "22",
>     "phonenumber":<PHONE_NUMBER>3,
>     "address": "address"
> }' -p alice; cl get info
executed transaction: e8d4dc466178ebaf287a2eefd0b5257430a1063a2eb6ff8ecd8833df7141f311  136 bytes  371 us
#            ab <= ab::add                      {"account":"alice","name":"lis4","age":22,"phonenumber":"13911113333","address":"address"...
warning: transaction executed locally, but may not be confirmed by the network yet         ]

{
  "server_version": "b24a643a",
  "chain_id": "cf057bbfb72640471fd910bcb67639c22df9f92470936cddc1ade0e2f2e7dc4f",
  "head_block_num": 12630,
  "last_irreversible_block_num": 12627,
  "last_irreversible_block_id": "00003153c189190ff3581b3ebbb74f7b7342cc6dae2c3dce78d14e14e7c9cd03",
  "head_block_id": "000031565edfffa072fac5cb73117f9b7353aa9523f83a7b9d67b13e78fbab74",
  "head_block_time": "2019-11-13T08:13:39.000",
  "head_block_producer": "prod1",
  "current_view": 2,
  "target_view": 3,
  "last_stable_checkpoint_block_num": 12601,
  "virtual_block_cpu_limit": 200000000,
  "virtual_block_net_limit":<PHONE_NUMBER>,
  "block_cpu_limit": 199529,
  "block_net_limit": 1048440,
  "server_version_string": "v3.0.2"
}

> db.transactions.find({"trx_id":"e8d4dc466178ebaf287a2eefd0b5257430a1063a2eb6ff8ecd8833df7141f311"}).pretty()
{
	"_id" : ObjectId("5dcbbb33cc9bc8e1007691b0"),
	"trx_id" : "e8d4dc466178ebaf287a2eefd0b5257430a1063a2eb6ff8ecd8833df7141f311",
	"accepted" : true,
	"actions" : [
		{
			"account" : "ab",
			"name" : "add",
			"authorization" : [
				{
					"actor" : "alice",
					"permission" : "active"
				}
			],
			"data" : {
				"account" : "alice",
				"name" : "lis4",
				"age" : 22,
				"phonenumber" : "13911113333",
				"address" : "address"
			},
			"hex_data" : "0000000000855c34046c6973341675be2a3d0300000012e58c97e4baace5b882e8a5bfe59f8ee58cba"
		}
	],
	"context_free_actions" : [ ],
	"context_free_data" : [ ],
	"createdAt" : ISODate("2019-11-13T08:13:39.511Z"),
	"delay_sec" : 0,
	"expiration" : "2019-11-13T08:14:09",
	"implicit" : false,
	"max_cpu_usage_ms" : 0,
	"max_net_usage_words" : 0,
	"ref_block_num" : 12627,
	"ref_block_prefix" :<PHONE_NUMBER>,
	"scheduled" : false,
	"signatures" : [
		"SIG_K1_KWL2aLiwGDxeSz1ztRrYDkLREPXvcAnDXd5ffLuagNqzZ7d7oPe29vF5Uz6etvkPPKKFaDDDUbKz4txELrqb5Px8H4nLdH"
	],
	"signing_keys" : {
		"0" : "EOS7HxPMkfyL69PqLXduP9YfuvVad8e3Nry6ryDGaJ2u8BKB2zUUm"
	},
	"transaction_extensions" : [ ],
	"block_id" : "0000315714cf74bf07cb9f2158e54794f6b30dce2114d91d097dd1199e8c2cd3",
	"block_num" : 12631,
	"irreversible" : true,
	"updatedAt" : ISODate("2019-11-13T08:14:25.030Z")
}

is the head-lib normal in mongodb-plugin enabled node?

is the head-lib normal in mongodb-plugin enabled node?

"head_block_num": 12630,
"last_irreversible_block_num": 12627
head_block_num-last_irreversible_block_num is always around 3.
{
  "server_version": "b24a643a",
  "chain_id": "cf057bbfb72640471fd910bcb67639c22df9f92470936cddc1ade0e2f2e7dc4f",
  "head_block_num": 12630,
  "last_irreversible_block_num": 12627,
  "last_irreversible_block_id": "00003153c189190ff3581b3ebbb74f7b7342cc6dae2c3dce78d14e14e7c9cd03",
  "head_block_id": "000031565edfffa072fac5cb73117f9b7353aa9523f83a7b9d67b13e78fbab74",
  "head_block_time": "2019-11-13T08:13:39.000",
  "head_block_producer": "prod1",
  "current_view": 2,
  "target_view": 3,
  "last_stable_checkpoint_block_num": 12601,
  "virtual_block_cpu_limit": 200000000,
  "virtual_block_net_limit":<PHONE_NUMBER>,
  "block_cpu_limit": 199529,
  "block_net_limit": 1048440,
  "server_version_string": "v3.0.2"
}

In batch-pbft, irreversible_block signals are emitted upon the lscb advancing, and by default, old plugins tend to capture these signals to update their db status. Probably we will introduce a new channel dedicatedly emitting newly applied lib signals.

Expect this issue to be resolved first


[20.09] python3Packages.toggl-cli: 2.1.0 -> 2.2.1

Motivation for this change
Backport of: https://github.com/NixOS/nixpkgs/pull/99607
ZHF: #97479
https://hydra.nixos.org/build/128023281
https://hydra.nixos.org/build/127640071
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Builds on NixOS with nix-build -A python3Packages.toggl-cli https://github.com/austinbutler/nixpkgs/archive/toggl-cli-backport.tar.gz, though I didn't test beyond result/bin/toggl --help. I assume the individual commits are all cherry-picks from master and therefore fine.
I don't have merge powers so that's all I can offer.


Looks like Cgo-related changes that spew will need to take into account for Go 1.10.
Meanwhile, you can make tip failure an allowed failure (with fast finish):
matrix:
  allow_failures:
    - go: master
  fast_finish: true

See here for an example .travis.yml.

I've merged the necessary changes to the tests to work with the latest tip to master.  Please update this per the review and I'll get it merged.

please rename the PR title to reflect reality

Ah, I amended the commit, but the PR title doesn't update when that happens, which is a little annoying. This should be ready for review again.


DRILL-5242: The UI breaks when rendering profiles having unknown metrics

Skip any metrics whose metric ID is unknown, This prevents any ArrayIndexOutOfBoundsException from being thrown and breaking the UI rendering.

@sudheeshkatkam Please review the PR and label the JIRA, so that @jinfengni can get it into the commit list for master.

+1

This closes PR #742


feat!: change registry spec to imagespec

this is cleaner; registry is an implementation detail that the end person doesn't care about
Closes #2189

@h4ck3rk3y when is the release date for it?
is there any package using it? do you plan to upgrade them?


Adding Collaborators/Partners to the Homepage

Suggest to add brands & vendors, who are involved or want to get involved with U3M to the u3m.info webpage. Open for suggestions

Currently collecting content for u3m.info website. Will consider one section for brands & vendors.


Support Multi Stage Builds

Shows error when using multi-stage builds.
The line with second FROM shows error.

Also came here for the same reason. Great tool btw.. very cool.

Ditto, any timescales for this guys?

Apologies for the radio silence! I plan to look into this soon-ish.

@jaydp17 @alexellis @TheYorkshireDev Opened a PR that allows for more than one FROM command, interpreting each as the beginning of a new stage. The PR essentially just makes the linting a little more lenient - I didn't attempt to add any new multi-stage specific checks.
I would love your opinions on if you think this is the right approach or if you have ideas for additional checks that should be made for multi-stage builds.

Didn't hear back from anyone for over a week, so went ahead and merged #84, which has been published to npm as version 1.4.0. Give it a shot and let me know if it does the trick. Thanks!

Came for the same Issue. Great tool btw!

Haha, nothing quite like getting a response 18 months after commenting. Better late than never :+1:


[R-package] Weighted Training - Different results (cross entropy) when using .weight column Vs inputting the expanded data (repeated rows = .weight times)

Problem:
I have a binomial prediction problem. One characteristic of my problem is that I have many rows of data with the same dependent and independent criteria. I am trying to speed up learning by using weighted learning (by aggregating (rolling up on all columns) the same data rows together and giving count of the rows as weights). However, When I compare the results of the two exercises, I do not get same result in terms cross entropy, Out of sample error on a different dataset.
Data Formats
Weighted Training data format
weight	entity	outcome	covariates
2	         E1	             0	           EC1
3	         E2	             1	           EC2

Expanded Data training format
entity	outcome	covariates
E1	            0	              EC1
E1	            0	              EC1
E2	            1	              EC2
E2	            1	              EC2
E2	            1 	              EC2

Outcome = 0 -> Failure
Outcome = 1 -> Success

Number of rows in expanded data is equal to sum of weight variable in weighted training
###### Expanded data format LGB run ########
Input_data <- TRAINING DATASET # (Expanded data format in the excel)

## Create LGB Data for the expanded data set format
outcome_name <- "output"
weight_name <- "weight"

Input_data_mat <- Input_data %>% select(-all_of(outcome_name))

# create the lgb data without the weight variable
lgb_data <-
  lgb.Dataset(
    data = Input_data_mat %>%
      as.matrix(),
    label = Input_data %>%
      pull(!!rlang::sym(outcome_name))
  )

params <- list(objective = "cross_entropy",max_bin = 5000,
               learning_rate = 0.01,max_depth = -1,num_leaves = 31)

## Train the model with exactly the same params and No .weight variable
lgb_mod <- lgb.cv(
  params = params,
  data = lgb_data,
  nrounds = 10000,
  early_stopping_rounds = 5
)

## Compare the best iteration and best score
print(glue::glue(" The best iteration is: {lgb_mod$best_iter} & best CE : {lgb_mod$best_score}"))

## Train the lgb model based on the cross validated parameters
lgb_trained_model <- lgb.train(params = params,
                               data = lgb_data,
                               nrounds = lgb_mod$best_iter)

## Generate OOS predictions on the test data
test_data <- TEST DATA for predictions (again in the expanded format)

test_matrix <- test_data %>%
                        select(-all_of(outcome_name)) %>% as.matrix()

## Make predictions on the above datasets
predictions <- predict(lgb_trained_model, test_matrix)

###### WEIGHTED TRAINING SCHEME ########

Input_data <- TRAINING DATASET (Weighted training data format in the excel WITH)

## Create LGB Data for the new data set format
outcome_name <- "output"
weight_name <- ".weight"

## Prepare model matrix for inputtng to lgb.dataset
Input_data_mat <-  Input_data %>%
  select(-all_of(outcome_name),
         -all_of(weight_name))

# create the lgb data with the weight variable
lgb_data <-
  lgb.Dataset(
    data = Input_data_mat %>%
      as.matrix(),
    label = mod_data %>%
      pull(!!rlang::sym(outcome_name)),
    weight = mod_data %>%
      pull(!!rlang::sym(weight_name))
  )

params <- list(objective = "cross_entropy",max_bin = 5000,
               learning_rate = 0.01,max_depth = -1,num_leaves = 31)

## Train the model with exactly the same params and No .weight variable
lgb_mod <- lgb.cv(
  params = params,
  data = lgb_data,
  nrounds = 10000,
  early_stopping_rounds = 5
)

## Compare the best iteration and best score
print(glue::glue(" The best iteration is: {lgb_mod$best_iter} & best CE : {lgb_mod$best_score}"))

## Train the lgb model based on the cross validated parameters
lgb_trained_model <- lgb.train(params = params,
                   data = lgb_data,
                   nrounds = lgb_mod$best_iter)

## Generate OOS predictions on the test data
test_data <- TEST DATA for predictions (again in the weighted format)

## Create LGB Data for the new data set format
outcome_name <- "nbrx_brand"
weight_name <- ".weight"

## Create the new prediction dataset. Remove outcome and weight variables
test_data_pred <- test_data %>%
  select(-all_of(outcome_name),
         -all_of(weight_name)) %>%
  as.matrix()

## Make predictions on the above datasets
predictions <- predict(lgb_trained_model, test_data_pred)

## Get predictions from model and weight in the same frame
output <- as.data.frame(cbind(test_data$.weight,predictions))

## Get the total nbrx predicted
output$total <- output$V1 * output$predictions

## Get total sum nbrx for the predictions
print(glue::glue("Total predicted output :{sum(output$total)}"))

When I compare the cross entropy of the two model runs as well as the out of sample predictions. They are very different. OOS Predictions are different by on average 50%.
Questions

Am I doing it correctly?
Is there an example in R for me to replicate?

Can you please add three backticks before and after the code for proper formatting?
You will need to remove all regularizations like min_sum_hessian etc. to have a chance that the results match. Not all of them are 0. Interesting question though.

Thanks for using LightGBM. Sorry it took so long for someone to respond to you here.
I've reformatted your question to make the difference between code, output from code, and your own words clearer. If you're not familiar with how to do that in markdown, please see https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax.

To @mayer79 's point... there are many parameters in LightGBM whose impact on the final model produced are sensitive to the number of rows in the training data, for example:
Parameters evaluated against a sum of row-wise values:

min_sum_hessian_in_leaf
min_gain_to_split

Parameters evaluated against a count of rows:

min_data_in_leaf
min_data_in_bin
min_data_per_group (for categorical features)

Duplicating rows changes those sums and counts. For example, imagine a dataset with 0 duplicates where you train with min_data_in_leaf = 20 (the default). LightGBM might avoid severe overfitting because it will not add splits that result in a leaf having fewer than 20 cases. Now imagine that you duplicated every row in the dataset 20 times, and retrained without changing the parameters. LightGBM might happily add splits that produced leaves which only matched 20 copies of the same data... effectively memorizing a single specific row in the training data! That'd hurt the generalizability of the trained model.
You can learn about these parameters at https://lightgbm.readthedocs.io/en/latest/Parameters.html.
I recommend just proceeding with the approach you described... eliminating identical rows by instead preserving only one row for each unique combination of ([features], target) and using their count (or even better, % of total rows) as a weight. That'll result in less memory usage and faster training, and you should be able to achieve good performance.

NOTE: I did not run your example code, as its quite large and (crucially) doesn't include the actual training data. If you're able to provide a minimal, reproducible example (docs on what that is) showing the performance difference, I'd be happy to investigate further. Please note the word "minimal" there especially... it is really necessary to train for 10,000 rounds, with 5000 bins per feature, to demonstrate the behavior you're asking about? Is it really necessary to use {glue} for just formatting a print() statement, instead of sprintf() or paste0()? If you could cut down the example to something smaller and fully-reproducible, it'd reduce the effort required for us to help you.

@jameslamb: Fantastic explanation, thanks!


Add inline registration

I added a few changes to #290. @irdan can you give my changes a once over?

@smcgregor HTML should in fact live in HTML instead of javascript, good call.  The styling is also way better than the vanilla I had in place.
Not that most people would do this, but you get a weird UI if you do the following:

Submit a valid email
Disconnect your network
Submit another request

This causes both the success and the failure message to appear at the same time because the success does not clear when the failure is presented.  If you submit another valid email, the error message disappears but there is no 'new' success messaged added.
I also noticed that if you close the modal and then enter it again the state is maintained.  Which seems a bit odd. If you care to address the issues I mentioned, I made a gist of the diff that would address them.

Updated the pull request per your comments.

Awesome :+1: to merging this.


[Sketchpacks Relay] Multiple manifest.json files prevent plugin from being indexed

Hey @tarunmangukiya,
We've found one more issue that is preventing your plugin from being indexed in our registry.
It seems that you have more than one manifest.json within your repo. Sketchpacks API doesn't know which one to parse.
We recommend placing the manifest.json that you want Sketchpacks to index closest to the root of your source code. Similar to package.json.
Once you've made those changes, please uninstall then reinstall Sketchpacks Relay on this repository. (We're working on a dashboard to help with this uninstall/reinstall process)
Let us know if there is anything else we can help clarify.

@adamkirkwood Thanks for mentioning. I have removed multiple manifest.json files, and kept only one that's related to the plugin.
Let me reinstall the Sketchpacks Relay.
Thanks 👍

Hello Adam,
I have resolved the issue and re-installed the plugin yesterday. But still the Sketchpacks Relay has to picked up the plugin.
Can you look into the same?
Best,
Tarun
From: Adam<EMAIL_ADDRESS>Sent: 10 July 2017 08:35 PM
To<EMAIL_ADDRESS>Cc: Tarun<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: [Iconscout/logodrop] [Sketchpacks Relay] Multiple manifest.json files prevent plugin from being indexed (#1)
Hey @tarunmangukiyahttps://github.com/tarunmangukiya,
We've found one more issue that is preventing your plugin from being indexed in our registry.
It seems that you have more than one manifest.json within your repo. Sketchpacks API doesn't know which one to parse.
We recommend placing the manifest.json that you want Sketchpacks to index closest to the root of your source code. Similar to package.json.
Let us know if there is anything else we can help clarify.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Iconscout/logodrop/issues/1, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AL5HRl3q70SgrK4mo--zuGepJR6V8Uzyks5sMj2ugaJpZM4OS-sQ.


Unable to install on Mac M1

Hi
I have issues with installing callvis on M1 Pro Mac.
Device

Mac Apple M1 Pro

Steps to reproduce

brew instal graphviz
go install github.com/ofabry/go-callvis@latest

Error
# github.com/goccy/go-graphviz/internal/ccall
In file included from dotgen.c:15:
../../../../go/pkg/mod/github.com/goccy/go-graphviz@v0.1.1/internal/ccall/dotgen/dotsplines.c:2310:13: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
../../../../go/pkg/mod/github.com/goccy/go-graphviz@v0.1.1/internal/ccall/dotgen/dotsplines.c:2310:13: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
../../../../go/pkg/mod/github.com/goccy/go-graphviz@v0.1.1/internal/ccall/dotgen/dotsplines.c:2504:16: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
../../../../go/pkg/mod/github.com/goccy/go-graphviz@v0.1.1/internal/ccall/dotgen/dotsplines.c:2504:16: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]

It installed fine for me here. Those warnings didn't halt the install.

Yes, you're right.


java.lang.IllegalArgumentException: byteCount < 0: -2

I'm trying to download this file

http://freetamilebooks.com/download/இட-ஒதுக்கீடு-உரிமை-epub/

always getting IllegalArgumentException. Don't know the reason. Using following code snippet. Same code working for other file url.
    val fetchConfiguration = FetchConfiguration.Builder(this)
                 .setDownloadConcurrentLimit(3)
                 .build()

    fetch = Fetch.getInstance(fetchConfiguration)

    val url = "https://www.engineerhammad.com/2015/04/Download-Test-Files.html"
    val file = getExternalFilesDir(Environment.DIRECTORY_DOWNLOADS)?.absolutePath + "/Test.html"

    val request = Request(url, file)
    request.priority = Priority.HIGH
    request.networkType = NetworkType.ALL

    fetch.enqueue(request)

@khaleeljageer Just tested the link. For some reason the server response header is returning the content length of -2. That is incorrect. It should be greater than 0.
Response:
Accept-Ranges = bytes
Content-Range = bytes 0--2/-1
Conent-Length = -2
Something does not seem right with this response. You may want to contact the webserver administrator. Hope this helps.

@khaleeljageer Just tested the link. For some reason the server response header is returning the content length of -2. That is incorrect. It should be greater than 0.
Response:
Accept-Ranges = bytes
Content-Range = bytes 0--2/-1
Conent-Length = -2
Something does not seem right with this response. You may want to contact the webserver administrator. Hope this helps.
Also you can create a custom download that fetch can use. See the sample app on how to create a custom downloader.

May we have error callback instead of crash exception?

An error callback can be added.

@jpvs0101 Just looked into this some more. An error callback can be added but I does not make much sense. If a client connection is not successful in the fun execute(request: Downloader.ServerRequest, interruptMonitor: InterruptMonitor): Downloader.Response?  method the Parallel or Sequential downloader that is handling the download needs to know this so they stop and return control to the download manager to enqueue other downloads. An error callback would only be for your debug purposes. An alternative would be the following code:
   override fun execute(request: Downloader.ServerRequest, interruptMonitor: InterruptMonitor): Downloader.Response? {
        try {
            return super.execute(request, interruptMonitor)
        } catch (e: Exception) {
            //log error
        }
        return null // this will still cause the download to fail/error
    }

I am open to more options/debate.

Just reviewed this some more and an error callback will not be added to the Downloader for the following reasons:

If an exception is thrown, then it is most likely an IO error that we cannot recover from and the download will need to be marked as having failed.

The downloader  already has a method called fun onServerResponse(request: ServerRequest, response: Response). This method is called to report the success or failure of a server request.


Next.js can't be built when importing Resource from middleware

Steps to reproduce:

Set up basic next.js deployment
Add a middleware.ts file, import Resource from sst and try to use it (e.g. Resource.MySecret.value)

Error
Module build failed: UnhandledSchemeError: Reading from "node:process" is not handled by plugins (Unhandled scheme).
Webpack supports "data:" and "file:" URIs by default.
You may need an additional plugin to handle "node:" URIs.
Import trace for requested module:
node:process
./node_modules/.pnpm/sst<EMAIL_ADDRESS>./node_modules/.pnpm/sst<EMAIL_ADDRESS>
SST version: 0.0.403

can you try using 3.0.33 of the sst package?

It works with 3.0.33 🥳 Thanks!


Add non-directive usage example to solid-dnd website

All the examples currently show the directive usage only. Add an explicit example to show manually wiring things up as directives don't work when wrapping custom components.

Added a 'fine grained' / custom drag handle to the examples at https://solid-dnd.com/#examples


ModuleNotFoundError: No module named 'multiprocessing', while using ProcessPoolExecutor

I compiled these code
import time
from concurrent.futures import ProcessPoolExecutor

def run():
    time.sleep(1)
    print(1)

def main():
    with ProcessPoolExecutor() as pool:
        pool.submit(run())

if __name__ == '__main__':
    main()

with command : python -m nuitka --standalone --mingw64   --show-memory --show-modules --show-progress  --plugin-enable=multiprocessing  --output-dir=dist  main.py.
Then I run it:
D:\Documents\processPoolExecutor\dist\main.dist>main.exe
Traceback (most recent call last):
  File "D:\DOCUME~1\PROCES~1\dist\MAIN~1.DIS\main.py", line 2, in <module>
  File "D:\DOCUME~1\PROCES~1\dist\MAIN~1.DIS\concurrent\futures\__init__.py", line 44, in __getattr__
  File "D:\DOCUME~1\PROCES~1\dist\MAIN~1.DIS\concurrent\futures\process.py", line 51, in <module>
ModuleNotFoundError: No module named 'multiprocessing'

D:\Documents\processPoolExecutor\dist\main.dist>

Missing stdlib dependency, https://nuitka.net/doc/factory.html

Part of the 0.9 release that I just made.


Not extracting C# files

The program only extracts image files and .dll files.

Resolved by myself

It isn't supposed to extract C# files.


Handle write to path in non-existant directory

Attempts to create a directory for any output file.
Also clarifies some errors messages.

Thanks for your contribution @romanlevin


does not starts on windows 10

conda create --name chainlit-env python=3.9
conda activate chainlit-env
pip install chainlit
chainlit hello
'chainlit' is not recognized as an internal or external command,
operable program or batch file.

This means that the chainlit executable is not in your PATH (happens sometimes on windows). You should see a message asking you to add it to your PATH with the actual path to the chainlit executable at the end of the pip install output.

This means that the chainlit executable is not in your PATH (happens sometimes on windows). You should see a message asking you to add it to your PATH with the actual path to the chainlit executable at the end of the pip install output.

There is no message asking to add chainlit to the path. How can I find the chainlit installed path?


Sprints can't be create in release displayed

Description
After creates a release, the user have to be able to create a sprint.
Expected behavior
Inside the Releases, the user have to be able to create a Sprint for the release displayed.
Current behavior
The sprint is not created unless the user clicks in the release card

Steps to reproduce the behavior

Create a release
Create a Sprint

Checklist

[ ] This issue has a significant name.
[ ] This issue has labels.
[ ] This issue has screenshots (if necessary).

The problem in this issue, is that the release_id from the release displayed is different from what is in the varible, probably because this variable is not been refreshed.

Issue solved #364


Warning declare by rust while compiling

warning: Found feature = ... in target.'cfg(...)'.dependencies. This key is not supported for selecting dependencies and will not work as expected. Use the [features] section instead: https://doc.rust-lang.org/cargo/reference/features.html

Fixed  by #133


Cannot find module './full-chrome-versions'

When I started a fresh project I got the following error message

<EMAIL_ADDRESS>dev C:\Users\felix\Documents\Code\Vue
node build/dev-server.js
Starting dev server...
ERROR  Failed to compile with 1 errors                                                                         20:57:00
error  in ./src/main.js
Module build failed: Error: Cannot find module './full-chrome-versions' (While processing preset: "C:\Users\felix\Documents\Code\Vue\node_modules\babel-preset-env\lib\index.js")
at Function.Module._resolveFilename (module.js:469:15)
at Function.Module._load (module.js:417:25)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object. (C:\Users\felix\Documents\Code\Vue\node_modules\electron-to-chromium\index.js:4:26)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object. (C:\Users\felix\Documents\Code\Vue\node_modules\babel-preset-env\lib\normalize-options.js:11:27)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
@ multi ./build/dev-client ./src/main.js
Listening at http://localhost:3000

How can I solve this?

Possibly related: https://github.com/vuejs/vue-cli/issues/394

I think the issue is in /node_modules/electron-to-chromium/index.js
They are mixing up full-chromium-versions with full-chrome-versions
If you have the luxury of a local build, you can hack it to make the build work.

Looks like the dev is releasing hotfixes now: https://github.com/Kilian/electron-to-chromium/commit/ab29cb73d4e24b053a70690bd8fa0b31dc7895f6

https://github.com/Kilian/electron-to-chromium/commit/f7b9b31cfdebfb48c69ede129b4376a3d9eb9f49

Sorry about that. 1.3.2 should fix this.

@Kilian Can confirm. Thanks


Microfluidic device to analyse oesophageal biopsy cells

A microfluidic device to analyse Cytosponge specimens for early detection of Oesophageal Adenocarcinoma. Cytosponge is a non endoscopic device created in our lab to retrieve million of cells from an oesophagus but there is a need for rapid analysis at a single cell level.

Video about CytoSponge
Contact person: Gianmarco Contino (gc502)
Organisation and Department: University of Cambridge and Addenbrooke’s Hospital
What would you like to learn? How to make microfluidic devices that combine antibody selection and single cell processing.
What can you teach people? The clinical aspects, biology and biomarkers of Oesophageal adenocarcinoma and how we can retrieve and analyse million of cells from a non endoscopic device created in our lab and now in a phase 3 clinical trial.

Hello,
I am a molecular biologist who has worked in an industry prior to my PhD, in the detection and analysis of circulating single cancer cells. I am interested in your project. Please reply if you are still looking for someone to work in this project.
Best,
Prabha


TF2 : AttributeError: module 'keras' has no attribute 'initializers'

System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04):  Mac
TensorFlow version and how it was installed (source or binary): 2.5.1
TensorFlow-Recommenders-Addons version and how it was installed (source or binary): 0.4.0
Python version: 3.9
Is GPU used? (yes/no): no

Describe the bug
Traceback (most recent call last):
File "de_demo.py", line 5, in
import tensorflow_recommenders_addons as tfra
File "python3.9/site-packages/tensorflow_recommenders_addons/init.py", line 29, in
from tensorflow_recommenders_addons import dynamic_embedding
File "python3.9/site-packages/tensorflow_recommenders_addons/dynamic_embedding/init.py", line 93, in
from tensorflow_recommenders_addons.dynamic_embedding.python.ops.tf_patch import (
File "python3.9/site-packages/tensorflow_recommenders_addons/dynamic_embedding/python/ops/tf_patch.py", line 39, in
kinit_K = K.initializers
AttributeError: module 'keras' has no attribute 'initializers'
Code to reproduce the issue
try:   import keras as K   kinit_K = K.initializers except ImportError:   kinit_K = None   pass  # for compatible with standalone Keras
Other info / logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached.

Hi @songyaheng , we confirm this issue has been resolved in the latest version, pls check it and feel free to reopen it when needed. https://github.com/tensorflow/recommenders-addons/releases/tag/v0.5.0


Fix NDFT tests

The fixes include:

fftshift added for FFT <-> NDFT matrix test
Added a test to compare NDFT vs NUFFT. This is crucial and sets the tone for autodiff modules.
Adding normalize to support ortho, this is important as mostly all NUFFT is normalized.
Removed a test test_ndft_grid_matrix, which tries o get the FFT matrix and match to a gridded NDFT matrix. But this is too complex and not generalizable currently. The test seems redundant so I removed it.

Good catch ! could you detail a bit which things were wrong (and why) ?
Also, lint your code ;)

@paquiteau Ill let you add this test for CD! I think that its good practice to run it before every release. (More importantly, we need to make it run right now to make sure the tests run fine.)

Can i merge when green? @paquiteau


upgrade dependencies to fix npm package deprecate warning

Summary
When trying to install jest, npm will give following warning:
$ npm install jest
npm WARN deprecated<EMAIL_ADDRESS>Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue

I've upgrade istanbul-api to latest release, minimatch have been upgrade to 3.0.2 and the problem is fixed.
Test plan
npm install don't give the warning now.

Current coverage is 87.44% (diff: 100%)

Merging #1779 into master will not change coverage

@@             master      #1779   diff @@
==========================================
  Files            38         38
  Lines          1211       1211
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           1059       1059
  Misses          152        152
  Partials          0          0

Powered by Codecov. Last update 46f1bc9...c692c13

thank you!


Interface polish points

Several points needing polish:

[x] Hide release notes button on API startup page (maintenance page)
[x] Switching between gene view and evidence view the UI does not jump, nor Map and Network view. But between those two sets (such as switching from evidence to map view) the UI moves slightly. They don't seem to have the same padding.
[x] Selected Species is no longer going green
[x] Release notes needs the KG version (and additional Metadata in header is missing).
[x] P value shows N/A (nice) but the same should be the case for User_Genes (right now it says 1, but I think the backend is either passing N/A or 0). I think N/A here would be good..
[x] Rename headers: (1) Gene view: Accession, Gene, Chr, Nt start, Evidence, KnetScore, Select. (2) Evidence view: Omit/Add, Type, Description, P-Value, Genes, Gene List, Select.
[x] Move "Download as TAB delimited file" to below the table in gene and evidence views.
[x] Replace "Select gene(s) and click "Create Network" button below to see the network." with a small help icon (which when clicked brings up a small version of the release notes popup, written: "Select genes from either Gene View, Evidence View or Map View and click "Create Network" to generate an interactive Knowledge network containing only the selected genes and relevant evidence."). A few other changes too, leading gene view looking more like this:
[x] Make Genome Region Search "Genes" box not be a box. (Since it's not editable it should just be text).

I'll update this thread in the comments as/if more things come to light.

[ ] Make API error page's Reload and Home Page button sizes the same.

@manlikleo. @Arnedeklerk did someone verify this? It's usually preferable that a ticket is tested by someone else other than the assignee, so that we can have multiple opinions and tests on at least two running environments.

@marco-brandizi

A few more points:

[ ] only show X on second (and beyond) Genome Region Search boxes OR if text has been filled into first one.
[ ] Centre align the X in genome region search.
[ ] BUG: clicking on any example query while having multiple open Genome Region Searches results in the page crashing.

@Arnedeklerk, it's not good to stash so many issues in single tickets, it makes it difficult to track history,  relate commits to issues and relate tests (when we can write them, eg, in Java) to issues.
If there is at least something that keeps multiple issues together, fine, else split them into multiple tickets and possibly unite them by means of an epic ticket and mark it with the 'epic' label (no puns intended...).

@marco-brandizi Sure, it just feels trivial for some of these points as they're often very small. That said, this ticket has now grown considerably in size and maybe it's best to keep them seperate.
Using epics is fine, but Github has limited functionality for Epics. I can Label things with epic, but there are already some ongoing unrelated projects there. Since there are quite a few tickets like this I think I'll just label them all with UI/UX, which will group them nicely, too.


table

your work is awsome  about table1 and table2
can we use table in remnote 1.4 ? there is not a great CSS like yours  these days , before remnote update last two month  ,  so sad

Hi, @Huang-Yujiong
Sorry to hear that.
but Martin said in this video
he already would have broken ground to make tables so we better have to watch him.
For technical reasons, CSS tables do not work anymore unless remnote changes its structure or CSS organization makes other rules.

I saw a message from hannesfrank about tag-related gimmicks from the discord channel, he already requested an updated version and just waiting for martin to pull the request so we will use it like before. please wait for the next remnote update!

thank you verymuch