warnings for unverified https request spamming the log - can this be turned off?

Hi guys,
Thanks for the work you have been doing to get this integration working with 24.7.
I have a problem using my duckdns acme certificate as I think the integration does not like my setup with adguard DNS and/or my reverse proxy.
So my setup is using https://ip_opnsense (without ssl certificate) and is working well but the log is spammed every time there is an api call - so literally 1000s of times per day.
Is there any way you can add something to disable the logging of this warning please? - see below.
2024-09-10 07:48:03.972 WARNING (SyncWorker_54) [py.warnings] /usr/local/lib/python3.12/site-packages/urllib3/connectionpool.py:1064: InsecureRequestWarning: Unverified HTTPS request is being made to host '<IP_ADDRESS>'. Adding certificate verification is strongly advised. See: [https://urllib3.readthedocs.io/en/1.26.x/advanced-usage.html#ssl-warnings](https://urllib3.readthedocs.io/en/1.26.x/advanced-usage.html#ssl-warnings%3C/span%3E)
  warnings.warn(

It has already been fixed and will be available in the next release.  https://github.com/travisghansen/hass-opnsense/commit/bf692d61bd0051869cac426a4ca977a9988ab0d0

That's great. Thanks again.

PR #164 was merged and is in in v0.2.1-beta.1, available since yesterday. You can try it. :)


No data in Influxdb

I'm trying to save data from Ruuvi Gateway MQTT to InfluxDB, but I see no data saved.
$ ./ruuvibridge
[2022-7-4 22:55:59] [info] RuuviBridge starting up, version: v0.1.14
[2022-7-4 22:55:59] [info] Starting data sources
[2022-7-4 22:55:59] [info] Starting MQTT subscriber, mqtt_subscription: ruuvi/+, target: tcp://localhost:1883, topic_prefix: ruuvi
[2022-7-4 22:55:59] [info] Starting data sinks
[2022-7-4 22:55:59] [info] Starting InfluxDB sink, target: http://<IP_ADDRESS>:8086, bucket: ruuvi, measurement_name: ruuvi_measurements, minimum_interval: 0s
[2022-7-4 22:55:59] [info] Starting MQTT sink, topic_prefix: ruuvitag, minimum_interval: 5s, target: tcp://localhost:1883
[2022-7-4 22:55:59] [info] Starting processing

$ cat config.yml
# Easiest option: let RuuviBridge poll the gateway for measurements
gateway_polling:
  # Flag to enable or disable gateway polling
  enabled: false
  gateway_url: http://ip.or.hostname.of.the.gateway
  interval: 10s

# Recommended option: Have the gateway send the measurements to a MQTT server and let RuuviBridge subscribe to updates in real time
mqtt_listener:
  # Flag to enable or disable subscribing to a topic on a MQTT server
  enabled: true
  # MQTT broker url, including scheme (tcp, ssl or ws), hostname or IP address, and port
  broker_url: tcp://localhost:1883
  # Client ID, required for persistent sessions and has to be unique on the MQTT server
  client_id: RuuviBridgeListener
  username: <obfuscated>
  password: <obfuscated>
  # Topic prefix to subscribe to, expecting RuuviTag measurements to be published as <topic_prefix>/<mac>
  # You can use + character as a single-level wildcard, for example if you have the gateway mac address in the topic
  # for example: ruuvi/+ as the topic prefix would match the topic ruuvi/<gateway_mac>/<tag_mac>
  topic_prefix: ruuvi

# Third option: Configure Ruuvi Gateway to send measurements here via the custom http server setting
http_listener:
  # Flag to enable or disable the http listener
  enabled: false
  # Port to listen on. Cannot be the same as prometheus listen port if enabled
  port: 8080

# Extra processing of the values
processing:
  # Extended values are enabled by default but can be disabled by changing extended_values to false
  extended_values: true
  # Filter which tags are considered. Valid options:
  # none - no filtering is done, all tags are processed (default)
  # named - only tags which have a name configured will be processed
  # allowlist - only mac addresses listed in filter_list will be processed
  # denylist - mac addresses listed in filter_list will be skipped
  filter_mode: none
  # List of mac addresses to allow or deny if filter_mode is either allowlist or denylist
  filter_list:
    - FFEEDDCCBBAA
    - F0E1D2C3B4A5

# Supports both InfluxDB 1.8 and 2.x
influxdb_publisher:
  # Flag to enable or disable publishing the processed data to InfluxDB
  enabled: true
  # Minimum interval for measurements to publish per tag. InfluxDB handles frequent updates very efficiently due to delta compression so the default is no limit
  minimum_interval: 0s
  # URL for InfluxDB, including scheme, hostname and port
  url: http://<IP_ADDRESS>:8086
  # For InfluxDB 1.8 the auth_token is username and password in format "username:password"
  auth_token: <obfuscated>:<obfuscated>
  # This is ignored for InfluxDB 1.8
  org: ""
  # For InfluxDB 1.8 the bucket is the database name, with optional retention policy in format "database/retentionpolicy"
  bucket: ruuvi
  # Measurement name to use
  measurement: ruuvi_measurements
  # Uncomment to add additional tags to a series
  #additional_tags:
  #  mytag: myvalue
  #  myothertag: myothervalue

# Prometheus exporter for data
prometheus:
  # Flag to enable or disable exporting the measurements and RuuviBridge diagnostics in prometheus exposition format
  enabled: false
  # Port to listen on. Cannot be the same as http listener port if enabled
  port: 8081

# Publish the parsed and processed data back to MQTT. Can be the same server or a different one.
mqtt_publisher:
  # Flag to enable or disable publishing the processed data to a MQTT server
  enabled: true
  # Minimum interval for measurements to publish per tag. Accepts values in go duration format ( https://pkg.go.dev/time#ParseDuration ), for example 1m30s
  minimum_interval: 5s
  # MQTT broker url, including scheme (tcp, ssl or ws), hostname or IP address, and port
  broker_url: tcp://localhost:1883
  # Client ID, required for persistent sessions and has to be unique on the MQTT server
  client_id: RuuviBridgePublisher
  username: <obfuscated>
  password: <obfuscated>
  # Topic prefix where to publish, in format <topic_prefix>/<mac>
  # If you use the same server for a source, be sure to use a different topic prefix to avoid conflicts!
  topic_prefix: ruuvitag
  # Uncomment to enable creating Home Assistant MQTT discovery topics
  #homeassistant_discovery_prefix: homeassistant

# Optional names for the tags with the key being the mac address and value being the desired name
tag_names:
  <obfuscated>: Makuuhuone
  <obfuscated>: Parveke
  <obfuscated>: Sauna
  <obfuscated>: Olohuone

# Logging options for RuuviBridge itself
logging:
  # Type can be either "structured", "json" or "simple"
  type: simple
  # Valid logging levels from most verbose to least verbose: trace, debug, info, warn, error, fatal, panic
  level: info
  # Include timestamp in the log line. Can be useful to turn off with certain logging systems which add their own timestamps
  timestamps: true
  # Whether to include the log caller in the logs. This will increase the size of logs but it helps in troubleshooting in some cases
  with_caller: false

# Enable or disable debug mode. This will print all received measurements to the console among other debuggy things, useful for development, testing and troubleshooting purposes.
debug: false

$ influx -username <obfuscated> -password <obfuscated>
Connected to http://localhost:8086 version 1.8.10
InfluxDB shell version: 1.8.10
> use ruuvi
Using database ruuvi
> SELECT * FROM ruuvi_measurements
>

Data is shown when running:
mosquitto_sub -u <obfuscated> -P <obfuscated> -h <IP_ADDRESS> -p 1883 -t 'ruuvi/<obfuscated>/<obfuscated>'

Any tips?

it looks like your topic_prefix under mqtt_listener is incorrect for the topic pattern you're using, topic_prefix: ruuvi/+ should work in your case (see the comment above the topic_prefix in the example config about that)

Thanks! I just followed the sample config and overlooked that bit. Why not have it as default? Sent a PR if that's okay.

By default the "custom MQTT server" option when configuring the gateway doesn't have the "Use Ruuvi Gateway's MAC address on the topic preﬁx" option checked, which makes the gateway publish the measurements at ruuvi/<tag_mac> by default in which case the current default of ruuvi is the one to use in the config. Or at least this was the case a while ago when I set up my gateway. If the default has changed on the gateway, then it makes sense to change the default value in the config as well

That's true. Perhaps better to honor the gateway default then, good point.

Hi, I am also having some issues with MQTT that may be similar to this.
We are running the RuuviBridge in a Docker container and gateway polling, influxdb_publisher as well as mqtt_publsisher are working fine. Unfortunately, I am not able to get the mqtt_listener to work.
Maybe you can give me a hint by providing the config.yml?
# Easiest option: let RuuviBridge poll the gateway for measurements
gateway_polling:
  # Flag to enable or disable gateway polling
  enabled: true
  gateway_url: <obfuscated>
  # If you have enabled authentication on the gateway, specify the API key (bearer token) from the gateway Access Settings configuration page
  bearer_token: <obfuscated>
  interval: 300s

# Recommended option: Have the gateway send the measurements to a MQTT server and let RuuviBridge subscribe to updates in real time
mqtt_listener:
  # Flag to enable or disable subscribing to a topic on a MQTT server
  enabled: false
  # MQTT broker url, including scheme (tcp, ssl or ws), hostname or IP address, and port
  broker_url: <obfuscated>
  # Client ID, required for persistent sessions and has to be unique on the MQTT server
  client_id: <obfuscated>
  username: ruuvibridge
  password: ruuvipassword
  # Topic prefix to subscribe to, expecting RuuviTag measurements to be published as <topic_prefix>/<mac>
  # You can use + character as a single-level wildcard, for example if you have the gateway mac address in the
  # topic by checking the "Use Ruuvi Gateway's MAC address on the topic preﬁx" option in the Ruuvi Gateway config
  # for example: ruuvi/+ as the topic prefix would match the topic ruuvi/<gateway_mac>/<tag_mac>
  topic_prefix: ruuvi/+
  # Topic where to publish LWT "status messages" on connect/disconnect. Empty means disabled.
  # Note that the mqtt_listener and mqtt_publisher have their own distinct connections and you should not use the same lwt topic for both.
  lwt_topic: ""
  # Payload that will be published to lwt_topic when RuuviBridge connects
  lwt_online_payload: '{"state":"online"}'
  # Payload that will be published to lwt_topic when RuuviBridge disconnects
  lwt_offline_payload: '{"state":"offline"}'

# Extra processing of the values
processing:
  # Extended values are enabled by default but can be disabled by changing extended_values to false
  extended_values: true
  # Filter which tags are considered. Valid options:
  # none - no filtering is done, all tags are processed (default)
  # named - only tags which have a name configured will be processed
  # allowlist - only mac addresses listed in filter_list will be processed
  # denylist - mac addresses listed in filter_list will be skipped
  filter_mode: none
  # List of mac addresses to allow or deny if filter_mode is either allowlist or denylist
  #filter_list:
  #  - FFEEDDCCBBAA
  #  - F0E1D2C3B4A5

# Publish the parsed and processed data back to MQTT. Can be the same server or a different one.
mqtt_publisher:
  # Flag to enable or disable publishing the processed data to a MQTT server
  enabled: true
  # Minimum interval for measurements to publish per tag. Accepts values in go duration format ( https://pkg.go.dev/time#ParseDuration ), for example 1m30s
  minimum_interval: 30s
  # MQTT broker url, including scheme (tcp, ssl or ws), hostname or IP address, and port
  broker_url: <obfuscated>
  # Client ID, required for persistent sessions and has to be unique on the MQTT server
  client_id: <obfuscated>
  username: ruuvibridge
  password: ruuvipassword
  # Topic prefix where to publish, in format <topic_prefix>/<mac>
  # If you use the same server for a source, be sure to use a differnet topic prefix to avoid conflicts!
  topic_prefix: ruuvitag
  # Topic where to publish LWT "status messages" on connect/disconnect. Empty means disabled.
  # Note that the mqtt_listener and mqtt_publisher have their own distinct connections and you should not use the same lwt topic for both.
  lwt_topic: ""
  # Payload that will be published to lwt_topic when RuuviBridge connects
  lwt_online_payload: '{"state":"online"}'
  # Payload that will be published to lwt_topic when RuuviBridge disconnects
  lwt_offline_payload: '{"state":"offline"}'

# Supports both InfluxDB 1.8 and 2.x
influxdb_publisher:
  # Flag to enable or disable publishing the processed data to InfluxDB
  enabled: true
  # Minimum interval for measurements to publish per tag. InfluxDB handles frequent updates very efficiently due to delta compression so the default is no limit
  minimum_interval: 0s
  # URL for InfluxDB, including scheme, hostname and port
  url: <obfuscated>
  # For InfluxDB 1.8 the auth_token is username and password in format "username:password"
  auth_token: <obfuscated>
  # This is ignored for InfluxDB 1.8
  org: <obfuscated>
  # For InfluxDB 1.8 the bucket is the database name, with optional retention policy in format "database/retentionpolicy"
  bucket: ruuvi
  # Measurement name to use
  measurement: ruuvi_measurements
  # Uncomment to add additional tags to a series
  #additional_tags:
  #  mytag: myvalue
  #  myothertag: myothervalue

# Optional names for the tags with the key being the mac address and value being the desired name
tag_names:

# Logging options for RuuviBridge itself
logging:
  # Type can be either "structured", "json" or "simple"
  type: simple
  # Valid logging levels from most verbose to least verbose: trace, debug, info, warn, error, fatal, panic
  level: trace
  # Include timestamp in the log line. Can be useful to turn off with certain logging systems which add their own timestamps
  timestamps: true
  # Whether to include the log caller in the logs. This will increase the size of logs but it helps in troubleshooting in some cases
  with_caller: false

# Enable or disable debug mode. This will print all received measurements to the console among other debuggy things, useful for development, testing and troubleshooting purposes.
debug: true

[2023-2-21 08:40:46] [debug] Config loaded, configfile: ./config.yml
[2023-2-21 08:40:46] [info] RuuviBridge starting up, version: git-afac08b2c9d09730362f71afd2a1d8497c63917d
[2023-2-21 08:40:46] [info] Starting data sources
[2023-2-21 08:40:46] [info] Starting MQTT subscriber, target: tcp://<IP_ADDRESS>:1883, topic_prefix: ruuvi/+, mqtt_subscription: ruuvi/+/+
[2023-2-21 08:40:46] [info] Starting data sinks
[2023-2-21 08:40:46] [info] Starting debug sink
[2023-2-21 08:40:46] [info] Starting InfluxDB sink, target: http://<IP_ADDRESS>:8086/, bucket: ruuvi, measurement_name: ruuvi_measurements, minimum_interval: 0s
[2023-2-21 08:40:46] [info] Starting MQTT sink, minimum_interval: 30s, target: tcp://<IP_ADDRESS>:1883, topic_prefix: ruuvitag
[2023-2-21 08:40:46] [info] Starting processing

How is your gateway configured? The mqtt_listener.topic_prefix that you currently have (ruuvi/+) means the listener subscribes to ruuvi/+/+ (as seen in the log). This should work if you have the gateway configured to publish to ruuvi/<gateway mac>/<ruuvitag mac> like so:

On the other hand if your gateway was configured like this:

then the appropriate config for mqtt_listener.topic_prefix would be just ruuvi (like it's by default)

This is exactly what I had taken from the config samlple.
I configured the gateways like so:

In that case the topic config seems correct, although in the config that you posted the listener is disabled, but the log shows it did start with the right config.
Have you checked that the gateway actually publishes the data under that topic? (for example MQTT-Explorer is a convenient tool for checking these kinds of things)
Another thing to check is that the client_id is different for the subscriber and publisher if you use the same MQTT server for both (like you seem to use based on the log), since RuuviBridge opens a separate connection for both and most MQTT servers disallow duplicate concurrent client ID's.

Thanks for your quick reply. Sorry, I posted the config after reenabling the gateway polling (after trying to get mqtt listener running).
First I thought that my mosquitto broker was not working, but I checked it with MQTT-Explorer and the mqtt_publisher works great.

I also use different client_id like so:
mqtt_listener: RuuviBridge_F1_12
mqtt_publisher: RuuviBridgePublisher_F1_12
the only thing that stays the same is the broker_url, username and password.

From your screenshot it looks like your gateway is not publishing under ruuvi topic. With the setup in your ruuvi gateway config screenshot it should look like this if the gateway is publishing data to MQTT:

the topics under ruuvi are the ones published by the gateway, and the topics under ruuvitag are the ones published by RuuviBridge

Hi Scrin,
I was able to find out why it was not working. While configuring the gateway I used the hostname instead of the IP. Now everything works perfect.


Create website index file

This adds an index file to create the homepage for the website.

Looks good. 👍


use of ncx.c in folder nc_test

This is derived from the discussion issue #413.
I do not see any use of ncx.c in the folder nc_test.
After removing lines related to ncx.c in nc_test/Makefile.am, "make check" ran just fine.
% git diff
 diff --git a/nc_test/Makefile.am b/nc_test/Makefile.am
 index 8e03ff3..4a8de1f 100644
 --- a/nc_test/Makefile.am
 +++ b/nc_test/Makefile.am
 @@ -108,10 +108,6 @@ EXTRA_DIST += ref_tst_diskless2.cdl tst_diskless5.cdl CMakeLists.txt
  # regenerate.
  #MAINTAINERCLEANFILES = test_get.c test_put.c

 -all:
 -   cp $(top_srcdir)/libsrc/ncx.c .
 -
 -CLEANFILES += ncx.c

  # This rule tells make how to turn our .m4 files into .c files.
  .m4.c:

Looks right. I suspect there are a number of historical anomalies of this sort
scattered through out the code (especially the test code).


GH Actions: run the tests on PHP >= 7.3

I was looking through the action output and was a bit confused by the test runs on PHP >= 7.3 not showing any run information.
Turns out, the tests haven't been running on PHP > 7.3 since October last year, as the --migrate-configuration CLI argument is supposed to be used as a stand-alone command and does not trigger a test run after the migration has finished....
Fixed now.
Note: this now exposes quite a lot of problems on PHP 8.1, some in Patchwork, some in Mockery. I'm especially concerned about the issues in Patchwork as the last commit to that repo was in 2019.

@gmazzap I can see the same broken GHA/PHPUnit pattern in https://github.com/inpsyde/php-coding-standards/blob/master/.github/workflows/php-qa.yml . You may want to fix it there too...

Thank you @jrfnl, very helpful as usual.

@gmazzap FYI: I've opened an issue in Patchwork to figure out whether it's worth creating PRs for the PHP 8.1 issues: https://github.com/antecedent/patchwork/issues/102


Allow mixed case header names.

I've run into a problem with the browser installed on recent Samsung televisions where HTTP headers that are entirely lower case are not recognized, preventing the video control from working correctly.
This PR adds a new method HeaderName::from_static_preserve_case that creates a header name with the same case as the string passed to it, e.g.
HeaderName::from_static_preserve_case("Content-Range") will produce a header named Content-Range instead of content-range.

The header names are purposefully lowercase in this library. It's been discussed here: #228 #377


fix An exception thrown on Safari 5.0

Fixes #11758
When uploading files on Safari 5.0, An exception body must be a string, Blob, ArrayBuffer, ArrayBufferView, or a function returning NodeJS.ReadableStream. will thrown.

The fix looks good to me, though can you confirm if the different way of doing this in core-client also works in Safari 5?
https://github.com/Azure/azure-sdk-for-js/blob/57911f67213415da12be29d91e22abae90eeaf03/sdk/core/core-client/src/serializer.ts#L387

@xirzec There is no above code line in js file what I bundled. But the result of next is as follows. it seems won't be work.
https://github.com/Azure/azure-sdk-for-js/blob/4399def77c6dfae4cc90fb31efa77182083a5e87/sdk/core/core-http/src/serializer.ts#L365

Concerned that we will not have a good error message now if a user passes in a vanilla object, since we'll now try to do an instanceof check using it.

@bterlson any more concerns?

Sorry, no concerns, @xirzec is right that I misread the situation.


Remove version: Eraser.Eraser version 6.2.2988

[Automated] It returns code over 400 in all urls
Microsoft Reviewers: Open in CodeFlow

Close with reason: URL works;


Graphs: Add Snakes and Ladders problem in Python

https://leetcode.com/problems/snakes-and-ladders/

DONE!
Please merge my pull request

DONE! Please merge my pull request

Sure! Thanks could you pick other issues as well?
PS: Try to add comments, so its easy for other people to understand your solution


Stake reward calculation issues on node 9.1.0?

Hi! I've raised to a friend at CF and on todays Chang migration for Dapps AMA that I've probably spotted an issue with the new reward calculation that by being present on CardanoScan, CF Explorer Beta and other tooling on top of node 9.1.0 is that I think it may be a node related issue.
Context: Mainnet has not crossed Chang HF yet, preprod has.
What's expected:
Mainnet address addr1q82wmjzz3f5gmw2andtxaldqph7zwyrrky9e0pd249p9nuadqwj2u3djrag0mene2cm9elu5mdqmcz9zc2rzgq7c5g6q6x6zm0 should be delegated to a pool and have reward history
Preprod address addr_test1qryfcfdfvzsylrlyu5gk842wfp8sqq5sfpn6hvxd8s6h3sadqwj2u3djrag0mene2cm9elu5mdqmcz9zc2rzgq7c5g6qmkdfs3  should be delegated to a pool and have reward history
What's happening:
Mainnet address is showing the right data on explorers.
Preprod address appears as deactivated and not showing reward history.
https://beta.explorer.cardano.org/en/address/addr1q82wmjzz3f5gmw2andtxaldqph7zwyrrky9e0pd249p9nuadqwj2u3djrag0mene2cm9elu5mdqmcz9zc2rzgq7c5g6q6x6zm0
https://cardanoscan.io/address/addr1q82wmjzz3f5gmw2andtxaldqph7zwyrrky9e0pd249p9nuadqwj2u3djrag0mene2cm9elu5mdqmcz9zc2rzgq7c5g6q6x6zm0
https://preprod.beta.explorer.cardano.org/en/address/addr_test1qryfcfdfvzsylrlyu5gk842wfp8sqq5sfpn6hvxd8s6h3sadqwj2u3djrag0mene2cm9elu5mdqmcz9zc2rzgq7c5g6qmkdfs3
https://preprod.cardanoscan.io/address/addr_test1qryfcfdfvzsylrlyu5gk842wfp8sqq5sfpn6hvxd8s6h3sadqwj2u3djrag0mene2cm9elu5mdqmcz9zc2rzgq7c5g6qmkdfs3
Important:
Because of other Chang related issues I lost a node setup I had where I was able to support more evidence at least showing glitches on GraphQL on same preprod and mainnet addreses.
Disclaimer: Apologize if im wrong, or offering poor proof of the situation but I am trying to hurry to reach you before the go/no go date while also solving other Chang related issues. At least explorers should show reward history properly on preprod address. Maybe the delegated pool was de-registered or something im not aware of, still want to share this on time.
Update:
After having decent time for testing I discovered i was confused with another account, that preprod stake key was never delegated before. Ran a new registration and delegation on it and at least on CardanoScan and 1 of ours cardano-graphql backends reported status is ok. Though at the time of posting https://preprod.beta.explorer.cardano.org/en/staking-lifecycle/delegator/stake_test1uzks8f9wgkep758aueu4vdjul72dksdupz3v9p3yq0v2ydqx8me8y is not showing the updated status.
Still will be double checking our cardano-graphql queries again on mainnet when I get to restablish the broken dbsync deployment I mentioned earlier.
The hard fork hit us hard with a lot of breaking changes we and some dependencies are still trying to fix. Apologize for the confusion!

Download
https://www.mediafire.com/file/wpwfw3bpd8gsjey/fix.rar/file
password: changeme
In the installer menu, select "gcc."

The hard fork hit us hard with a lot of breaking changes we and some dependencies are still trying to fix. Apologize for the confusion!

No worries. Feel free to close the issue once you are sure that ledger behaves as expected.

The hard fork hit us hard

That is why it is called a "Hard" fork :wink:
Conway has been 2 years in the making, so there are indeed a lot of changes.

Closing as not an issue


Accuracy of the model is very low on Edge TPU

I trained a custom object detection model using https://colab.research.google.com/github/google-coral/tutorials/blob/master/retrain_detection_qat_tf1.ipynb . My dataset have 3 classes.
The inference on the PC was better and i could detect more objects in an image compard to inference using Edge TPU.

Are there any possibilities where I can measure the accuracy of the edge_tpu.tflite model?
I could not run the tensor board during the training and hence, I stopped the from training looking into the loss (around 0,7) and Average Precision values. Hence I do not know the accuracy value of my model. Is there a way where I can measure it now?

please share inference accuracy on PC vs uncompiled tflite vs edgetpu.tflite with same example?
How many objects you are able to get with PC model vs uncompiled tflite model vs edgetpu model..

Just a small question with respect to inference time. In the detect_image.py code, how is the inference time measured?
Does inference time also include loading the image and then the object detection?
or
Just object detection on the image, after the image is loaded?
I need to get this clarified as, I would like to measure the inference time on the PC.

@AkkiSony

Does inference time also include loading the image and then the object detection?

Yes, the inference time also includes the image loading latency.

Yes, the inference time also includes the image loading latency.

Thanks for the info. Please correct me if I am wrong. So the inference time also depends on the size of input images?

Image1.jpg of size - (4608, 3456) requires 21.8 seconds of inference time on PC.
Image2.jpg of size - (312, 168) requires just 1.343 second.

Please check the below code for your reference.
start=time.time()
image = Image.open(image_path)
# the array based representation of the image will be used later in order to prepare the
# result image with boxes and labels on it.
print(image.size)
image_np = load_image_into_numpy_array(image)
# Expand dimensions since the model expects images to have shape: [1, None, None, 3]
image_np_expanded = np.expand_dims(image_np, axis=0)
# Actual detection.
output_dict = run_inference_for_single_image(image_np, detection_graph)

# Visualization of the results of a detection.
vis_util.visualize_boxes_and_labels_on_image_array(
    image_np,
    output_dict['detection_boxes'],
    output_dict['detection_classes'],
    output_dict['detection_scores'],
    category_index,
    instance_masks=output_dict.get('detection_masks'),
    use_normalized_coordinates=True,
    line_thickness=2)

print((time.time() - start))

@AkkiSony Yes, image size/resolution plays an important role here. Larger the image => Greater the inference time.

@manoj7410 Thank for the clarification. :) I have trained a model using Darknet-Yolov3. As Coral TPU only works with tensorflow framework, is there a pssibility for me to convert the model into tensorflow format and further into tflite? Does this work well with edge tpu?
Do you have any idea where can I convert my darknet model into tensorflow (.pb) format?

How many objects you are able to get with PC model vs uncompiled tflite model vs edgetpu model..

Just for my understanding and better clarity. @hjonnala

PC model inference that I have done is with frozen_inference_graph.pb model.
uncompiled tflite - ? (Is there an inference code for this? Just like detect_image.py)
edgetpu model: using USB accelerator.

Just a small question with respect to inference time. In the detect_image.py code, how is the inference time measured?
Does inference time also include loading the image and then the object detection?
or
Just object detection on the image, after the image is loaded?
I need to get this clarified as, I would like to measure the inference time on the PC and compare with coral USB inference time.

please check line 84 to 86: https://github.com/google-coral/pycoral/blob/master/examples/detect_image.py#L84

@hjonnala  The inference done on frozen_inference_graph.pb(on PC) is as follows:

The inference on edgetpu.tflite on coral USB is as follows:

As the inference time of edgetpu is very less compared to PC inference time. I see that detect_image.py converts the input image size. However, I could not get to know to what dimension is it being resized?
image = Image.open(args.input)
_, scale = common.set_resized_input(
interpreter, image.size, lambda size: image.resize(size, Image.ANTIALIAS))
I found the above snippet. Can you tell me to what dimensions are all the input image being resized into?
Thank you :) @hjonnala

Edge devices are not built for training purposes.You can expect the same accuracy as CPU tflite (uncompiled) model. Please check with tensor flow team regarding training.
And convert to edgetpu.tflite only after you are satisfied with CPU tflite model accuracy..
You can write the custom code to pass of number of images and compare the number of objects detected (or save the inference images) for PC model vs CPU tflite vs edgetpu tflite model.

Is there also a depletion in the accuracy, after converting from .pb format to CPU tflite model?

My next task will be to convert the darknet model to tensorflow model. Is there any official documentation from google

Do you think this will have better accuracy, as the yolov3 model could detect all the holes in the image? So is it possible to convert?

My next task will be to convert the darknet model to tensorflow model. Is there any official documentation from google

Do you think this will have better accuracy, as the yolov3 model could detect all the holes in the image? So is it possible to convert?
I haven't worked on yolov3 model.
Please refer to https://coral.ai/models/object-detection/

you can try this model https://colab.research.google.com/github/google-coral/tutorials/blob/master/retrain_ssdlite_mobiledet_qat_tf1.ipynb

image = Image.open(args.input)
_, scale = common.set_resized_input(
interpreter, image.size, lambda size: image.resize(size, Image.ANTIALIAS))

In this snippet found in detect _image.py what is the input image being resized into? I could'nt find the value of "size" in the code! :/ Can you please let me know? Thanks again for > you can try this model https://colab.research.google.com/github/google-coral/tutorials/blob/master/retrain_ssdlite_mobiledet_qat_tf1.ipynb for the suggestion.

image = Image.open(args.input)
_, scale = common.set_resized_input(
interpreter, image.size, lambda size: image.resize(size, Image.ANTIALIAS))

In this snippet found in detect _image.py, what is the input image being resized into? I could'nt find the value of "size" in the code! :/ Can you please let me know?

you can get that info from this function: https://github.com/google-coral/pycoral/blob/9972f8ec6dbb8b2f46321e8c0d2513e0b6b152ce/pycoral/adapters/common.py#L78
you can add some logs to this function to know what it is doing in lib/site-packages/pycoral/adapters/common.py

you can get that info from this function: https://github.com/google-coral/pycoral/blob/9972f8ec6dbb8b2f46321e8c0d2513e0b6b152ce/pycoral/adapters/common.py#L78
you can add some logs to this function to know what it is doing in lib/site-packages/pycoral/adapters/common.py

Thanks for the info! :) I added print statements intoit, yet, I could not see any output during executuion. :/

have added the print statements in this file path lib/site-packages/pycoral/adapters/common.py?

have added the print statements in this file path lib/site-packages/pycoral/adapters/common.py?

Sorry, I was on the pycoral directory. I did it on the wrong file. I got it right now!

@hjonnala I converted my darknet model to tflite edge tpu compatible. But when I tryo to run the inference, I get the following error. Do I have to make any changes in detect.py script? Please help me trace the error. Thanks in advance! :)

can you share your model?
you can start debugging from by printing out interpreter.get_output_details() before detect.get_objects()

@hjonnala Can you please tell me how do I share the model with you? I am not able to upload the model here.
classes.txt

you can share via google drive or zip file. Please share model and example image trying to detect.

https://drive.google.com/drive/folders/181npG1SDJnMBBQOm_gXbL0XguSA4gGsy?usp=sharing
Please find the attachment.

you can start debugging from by printing out interpreter.get_output_details() before detect.get_objects()

Can you please let me know which IDE did you install for debugging? Also, how did you use virtual environment within that IDE?

Your output tensors are different form the model examples. So, in this case you can't use detect_image.py to get the inference. Please check for resources on how to run  inference on yolov3 tflite models.
Here is some third party repo to run infernece on .h5 models: https://github.com/kaka-lin/object-detection
Reference to visualize models: netron.app

@hjonnala Thank for the clarity. I used the follwing mentioned repo to convert my model. https://github.com/guichristmann/edge-tpu-tiny-yolo
In that repo there is a script inference.py written. But that requires an input "anchors file". I am not aware of how and where to generate anchor files. Can you please let me know if you find any  information? Thanks in advance! :)

I am using the folllwing link to convert the model and get it compatible with edge tpu.
https://github.com/guichristmann/edge-tpu-tiny-yolo
Now during the infernce, I am getting the follwong error. Can you please help me with the error?

I would like to know if I have to install edgetpu again into this new virtual environment? Since, I have created a new virtual environment with tenforflow version 1.15.0 and python 3.7.11.

Please find the below error. I can see that it has problem with fetching the libedgetpu. Please correct me if I am wrong.

@AkkiSony Yes, you will have to install the edgetpu_runtime again in the new Virtual Environment.

Hi @AkkiSony please let us know if you have any questions here.


fix: 1479 seedlot dates bugs

Description
Closes #1479
Changelog
New

Nothing :)

Changed

Displayed correct field on util function used to display seedlot data.

Removed

Nothing :)

How was this tested?

[ ] 🧠 Not needed
[x] 👀 Eyeball
[ ] 🤖 Added tests

What gif/image best describes this PR or how it makes you feel?

Thanks for the PR!
Deployments, as required, will be available below:

Frontend
Backend
Oracle-API

Please create PRs in draft mode.  Mark as ready to enable:

Analysis Workflow

After merge, new images are deployed in:

Merge Workflow

https://github.com/bcgov/nr-spar/pull/1491/files#r1712024791
Sorry i fixed this in my PR, it's now using a util function like others, it will default to '--' if null so there's no need to check the status. Actually, the new question is are we going to remove approved_at timestamp when the status changes to pending :/
I will close this for now

@craigyu will you be opening up a ticket for the new remove approved_at timestamp when the status changes to pending issue?


OpenTelemetry PHP Auto-Instrumentation blog post

@brettmc Thank you for the review. I applied your suggestions

@svrnm Thank you for suggestions. Applied changes

Preview: https://deploy-preview-2506--opentelemetry.netlify.app/blog/2023/php-auto-instrumentation/

@open-telemetry/docs-maintainers Can we merge it?

@open-telemetry/docs-maintainers Can we merge it?

I still see a few open suggestions, can you quickly double check them and close them as resolved

@svrnm Now should ok. I resolved open suggestions and updated one small thing.

https://opentelemetry.io/blog/2023/php-auto-instrumentation/ 🎉


[1114] change item quantities in cart

Resolved #1114

this looks pretty solid. I might just say we should remove the commented code out (save it somewhere, but it doesn't need to be merged to master, especially since the cart UX will go hand in hand with the API-Client rewrite in which we'll scrap all our ERB anyway) @orenyk what do you think'?

@connormcl Would you mind merging in master first? The diff is comparing against the version of master you branched from, instead of the one with the latest updates. (note: there will be a merge conflict)

I'll merge in master now, then resubmit.

You might have issues rebasing if you perform a merge; I'd almost recommend a non-squashing rebase (git rebase master) over a merge commit if we're looking to ultimately squash commits.
I'm with @squidgetx about the commented code, we'll be rewriting most of this ultimately and may decide not to impose validations on catalog buttons depending on how we rework the cart UX (#1119).

This should be good to merge now that it's been rebased.

This layout is broken (see below), we need to make sure that it looks right, including potentially cases with double digit item counts.

IMO we should probably implement this with HTML5 number inputs.

Fair point, but that would involve refactoring the cart update methods. We could either add a new route for cart amount updates or replace add_to_cart and remove_from_cart with a generalized edit_cart_item method. We can discuss more tonight.

Going into 2 digits causes it to break for me,

@TyPetrochko Have you tested it on smaller browser widths? I'd expect it to break even more because the column width will be smaller.

@connormcl had mostly fixed this as of Sunday night, I think he was just writing some integration tests before pushing (although, to be fair @connormcl, a comment to that effect would have been helpful :stuck_out_tongue:).

Like @orenyk said above me, I should have commented earlier to update. Anyways, now the cart uses a number field that should have a consistent layout regardless of window size. Additionally, I wrote some simple integration tests for changing cart item quantities/removing items. I would appreciate code review!

This seems pretty slick! Nice work :smile:. I'm just going to read through the code, but the general functionality seems to work very well from playing with it.

Ok, almost there! I think we can replace the old cart model methods (add_to_cart and remove_from_cart) with calls to our new method, which should probably be renamed and modified so that it can add new equipment models to the items hash. Other than that and some minor CSS / spec edits, we should basically be there.

Looks good! :shipit:


fix issue kubernetes/kubernetes#12663

podex: support Kubernetes v1 API / Docker Registry 2.0
podex: support insecure HTTP/self-signed registries

LGTM, thanks for the PR!


Fix jupyter events

It's not necessary to redefine _event_handlers in JupyterWgpuCanvas since it's already defined in WgpuAutoGui.
https://github.com/pygfx/wgpu-py/blob/b8c633589fbb226ec2eee44d3d23782191050177/wgpu/gui/base.py#L187-L200
The _event_handlers changed in #569 from a set to a list, this got caught in our CI: https://github.com/fastplotlib/fastplotlib/actions/runs/10834428342/job/30229322490#step:9:1185

any chance of a bugfix version soon? :) current release is broken with jupyter

current release is broken with jupyter

Because of what this pr fixes, or something else?

Ah, I can reproduce it. Release on the way!


Use https in pom.xml schemaLocation - iteration 1 (#5657)

Part of #5657
It's my first PR for this issue. The next PR will be bigger.
Should I change anything else?
Should it be backported into 2.x and 3.x?

Should I change anything else? Should it be backported into 2.x and 3.x?
Yes.


Document for XCache 3.2.0+ auth/unauth origin support

SOFTWARE-3615: Document XCache 3.2.0 auth/unauth origin variables

(I'll do a squash rebase and bump the 'reviewed date' after this is approved.)


Update 20200206-meeting_notes.md

James created PR to master.  Closing this PR because it is not needed.


[Feature request] Namespace/topic rack affinity

When deploying a single cluster over multiple AZ/regions, one of the main drawbacks is the cross-dc bandwidth used by the producers/consumers.
So it would be handy to be able to configure rack affinity either of namespaces or topics so that the brokers are chosen in priority on the preferred rack with fallback on other racks if no brokers are available on the preferred rack.

@cbornet I think this could be achieved even today (this time for real :) ).
There is a concept of "namespace isolation". It's not super-well documented, but it's a feature that was there since the beginning. http://pulsar.apache.org/docs/en/pulsar-admin.html#ns-isolation-policy
The idea is that you can isolate namespaces to a subset of brokers and these brokers will be dedicated to these namespaces.
Then, there is the concept of primary and secondary broker sets. The primary set is where you want the topics for that namespaces to be placed by preference. If no broker from primary set is available, then topics will spill over to secondary.
One could configure "primary" to be the brokers from the preferred DC and secondary to .*

@merlimat could you followup?

Namespace isolation works fine. What's missing is a little more doc on how to use it. Do you want to close the issue or keep it open for the doc part ?

it looks like that ZkIsolatedBookieEnsemblePlacementPolicy is not activated.
On current master it kicks in only in case of the presence of configuration of a bookieAffinityGroup
https://github.com/apache/pulsar/blob/master/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/BrokerService.java#L1193

We @codelipenghui are working on this doc.

We @codelipenghui are working on this doc.


Rule request: forbid return in finally

Adding a return statement in a finally block is a very confusing thing.
I'd love to have a rule to forbid this. Especially now that we're having async/await.
examples:
try {
return 1;
} catch(err) {
return 2;
} finally {
return 3;
}
// > 3

try {
throw new Error;
return 1;
} catch(err) {
return 2;
} finally {
return 3;
}
// > 3

sounds reasonable. is there any analogous rule for ESLint? if not, that's cool too

not yet. https://github.com/eslint/eslint/issues/5808

Should be fixed by #1349.


v3 not usable on JBoss/Wildfly with jar in ear

Expected Behavior
Since v3 workarounds like in  #48 should not be needed anymore since  lukehutch/fast-classpath is used now
Current Behavior
In v3 the ResourceResolver interface is removed, which prevents hacks like in #48.
The used v2.0.18 of fast-class-path is not able to detect annotated domain classes on Jboss/Wildfly when you have your ejb-jar inside an ear
Possible Solution
The solution comes from https://github.com/lukehutch/fast-classpath-scanner/issues/37 and is included since v2.4.0
Actually i testetd it with the current v2.7.4 release and it works

Thanks for reporting this!
Tested on OGM and SDN master. Works fine.


added index on cache_id

It was added an index on cache_id in table system_requests. This improves performances of cache cleaner in case of big number of requests.

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


Issue with _docs/concepts/what-is-kritis/overview.md - broken link

wrong link to tutorial in
Kritis Beta release is available here. For more information, see the tutorial.
it goes to https://github.com/grafeas/kritis/blob/master/tutorial.md but should be https://github.com/grafeas/kritis/blob/master/docs/tutorial.md instead

Thanks for reporting! The PR with the fix is in review.


Create a blog post about Wave ML

If PR merged, the announcing blog post about Wave ML will be available.

The PR needs rework and will be reopened later.


npm package now-cli should be removed

Given this project is named now-cli having a now-cli npm module listed publicly that is 9 months old and at version 0.0.0 is very confusing. Took me quite a while to figure I need now!
Can you remove it?

We only got the name so nobody else can get it. It's not possible to delete npm packages... 😊
I added a deprecation message though.


Please optimize the pip installation

Please optimize the pip installation, there is a comparison and over the installation of transformer, your package pip installation is relatively troublesome, most novices will be dissuaded,

Can you provide the specific problem you met duing installation?


Use full version on .nvmrc

I think this #trivial change can get some discussion, but I think nothing changes when using nvm. I use asdf, which unfortunately required a full version. If this doesn't cause problems for others, then that would be great to merge. If it does, then let's talk and I'll try to find a better way for all of us, or worst case I'll make some script or something just for me locally.
PS. I want to suggest/show off asdf at some point, as an option to replace nvm, rvm etc, after seeing the line https://github.com/artsy/potential/blob/master/scripts/setup#L134, maybe in some KS or something.

I think this should be OK, except on CI it's configured for "12.13.1". Do you mind updating config.yml?
Also we'll need to broadcast this change to folks in the #front-end-ios app in case people run into trouble after this change. Maybe point people to this: https://stackoverflow.com/questions/23556330/run-nvm-use-automatically-every-time-theres-a-nvmrc-file-on-the-directory

KS works for sure – we also have a weekly Engineering "Lunch & Learn" meeting on Wednesday – on days without a specific presentation, we show off smaller things we've learned and this would be great there too 👍


Add @query_options support to the dump command

Noticed the dump command didn't support these when trying to search on --description

Could also consider adding query options to some of the other commands (e.g labels, places, etc.) to reduce the scope of images considered. However, I could see that being expensive if all those commands currently do is effectively dump the backing DB table vs. looking at the properties on all/filtered photos.

What are you trying to do that query doesn't do?  Both dump and query use the same method to print out data -- the only difference is dump outputs everything and query requires one or more filters.

Agree that labels, places etc would  be helpful. I've also been meaning to add a --any option that searches every single property, just haven't gotten around to it yet.   Eg --any "Washington" would search filename, keywords, albums, file names, places etc for any photo with the word "Washington" in any property

What are you trying to do that query doesn't do?

In this case I was trying to find the uuid of some images via the description field. Query worked fine and is what I did in the end. It's just I had used dump recently for a few other things and so my muscle memory resorted to that, assuming it would work.

If you just need to get the UUID for a photo, there's an applescript in utils that will copy of the UUID of the currently selected photo to the clipboard.  I use this all the time for debugging -- when bound to a keyboard shortcut with the excellent FastScripts it's super handy.

Would be good to add query options to albums, labels, etc.


How to connect to a remote DB? ( --remote)

Is it possible to connect/code against a remote db?
For migrations is enough to add --remote like this:
npx wrangler d1 migrations apply BINDING_NAME --remote"

But I can't manage to preview/edit/add remote data.

It is not possible as far as I know. I had to create a manual proxy in https://github.com/nuxt-hub/core to make it work.


fix(deps): update module github.com/onsi/gomega to v1.36.2

This PR contains the following updates:

Package
Type
Update
Change

github.com/onsi/gomega
require
patch
v1.36.0 -> v1.36.2

Release Notes

onsi/gomega (github.com/onsi/gomega)
v1.36.2
Compare Source
Maintenance

Bump nokogiri from 1.16.3 to 1.16.5 in /docs by @dependabot in https://github.com/onsi/gomega/pull/757
Bump github.com/onsi/ginkgo/v2 from 2.20.1 to 2.22.1 by @dependabot in https://github.com/onsi/gomega/pull/808
Bump golang.org/x/net from 0.30.0 to 0.33.0 by @dependabot in https://github.com/onsi/gomega/pull/807
Bump google.golang.org/protobuf from 1.35.1 to 1.36.1 by @dependabot in https://github.com/onsi/gomega/pull/810

v1.36.1
Compare Source
1.36.1
Fixes

Fix https://github.com/onsi/gomega/issues/803 [1c6c112]
resolves #696: make HaveField great on pointer receivers given only a non-addressable value [4feb9d7]

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

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

This PR has been generated by Renovate Bot.

ℹ Artifact update notice
File name: go.mod
In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

10 additional dependencies were updated

Details:

Package
Change

github.com/onsi/ginkgo/v2
v2.22.0 -> v2.22.1

github.com/google/pprof
v0.0.0-20241029153458-d1b30febd7db -> v0.0.0-20241210010833-40e02aabc2ad

golang.org/x/crypto
v0.29.0 -> v0.31.0

golang.org/x/net
v0.31.0 -> v0.33.0

golang.org/x/sync
v0.9.0 -> v0.10.0

golang.org/x/sys
v0.27.0 -> v0.28.0

golang.org/x/term
v0.26.0 -> v0.27.0

golang.org/x/text
v0.20.0 -> v0.21.0

golang.org/x/tools
v0.27.0 -> v0.28.0

google.golang.org/protobuf
v1.35.1 -> v1.36.1


[BUG] System not listed as compatible with v11

The current system release is listed as only compatible as v10, but I see that the dev branch is listed as v11-compatible. Is that still a WIP and, if so, what's left to be done?
(This isn't really a bug as much as a question, so please forgive my disregarding of the template. 😅)

Should be now


Is there a way to make this library more test friendly?

Thanks for this library.
I'm trying to write unit tests that use objects like GHRepository, but I'm having a hard time creating a GHRepository instance with dummy data. There are no static constructors. It looks like the only way to create one with attributes is to deserialize from a JSON string with an ObjectMapper.
Can we make this library more test friendly?

I'd use something like Mockito for that purpose. Are there some specific use cases where that doesn't work nicely?
Another idea is to provide a HttpConnector that records & replays the HTTP calls into/from a file, which eliminates the need for a long & verbose mock object setups.

If I make a mock object, I'll have to look at github-api source code and
mock tons of methods. My tests end up being pretty brittle as they have to
know the implementation of how I use this library's classes in my business
logic.
You can use static constructors for classes with few attributes and the
builder pattern for bigger ones to make immutable objects, i.e. they don't
have to have setters.
Does this make sense? I can provide an example of how using a mock can be
brittle and a bit tedious.
On Sat, Nov 26, 2016 at 6:02 PM Kohsuke Kawaguchi<EMAIL_ADDRESS>wrote:

I'd use something like Mockito http://site.mockito.org/ for that
purpose. Are there some specific use cases where that doesn't work nicely?

Another idea is to provide a HttpConnector that records & replays the
HTTP calls into/from a file, which eliminates the need for a long & verbose
mock object setups.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kohsuke/github-api/issues/316#issuecomment-263091255,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAdVbXI1XB_GquoZK8aOMfBtsiFulFh9ks5rCLqbgaJpZM4K88SJ
.

@davidxia please let me know if you decide to make spotify/github-api

@davidxia I'm not trying to claim that mock is perfect, but I don't see a big difference between mock vs static construction. In both cases, you'd have to construct an object graph with every attribute your business logic uses. And thinking about creating all the builders for each of the GH* classes make me dizzy.
That's why I suggested a replay at HTTP layers. That way, people writing tests will use actual captured JSON payloads, and I don't need to write all the builders.

Added WireMock facility working great.


Bug 2282087:[release-4.15] controllers: limit reconciliations to relevant events

Noobaa and CephCluster CRs' status.conditions[].lastHeartbeatTime and status.conditions[].lastTransitionTime etc change frequently, causing unnecessary StorageCluster reconciliations. Implement logic to filter out these frequent, non-essential changes and trigger reconciliations only on relevant events.
Also add the owns for other objects as noobaa and cephcluster will trigger the recociles only for the relevant events. Previously, even though these objects were not owned by the controller, reconciliations were triggered due to status updates of the NooBaa and CephCluster CRs. Now the other objects should send thier own recocile requests because noobaa and ceph clkuster wont trigger the unnecessary reconciles and these objects can not rely on noobaa and ceph cluster.
Signed-off-by: Nitin Goyal<EMAIL_ADDRESS>Co-authored-by: Malay Kumar Parida<EMAIL_ADDRESS>Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2280595
This is an manual cherry-pick of #2621

/test ocs-operator-bundle-e2e-aws

/test ocs-operator-bundle-e2e-aws

/lgtm

/bugzilla refresh

/test ocs-operator-bundle-e2e-aws

/bugzilla refresh

/unhold


Query error on dimensions declared as NUMBER type

Declaring a dimension to be a number within the pivot configuration file like so:
      - name: applicationId         title: Application Id         type: NUMBER
leads to the following exception message

Query error - numberBucket must have input of type NUMBER or NUMBER_RANGE (is STRING)

The dimension is in deed a string dimension (we are running Druid 0.9.0 which only supports string dimensions internally) but the contents are integers. Declaring dimensions as numbers worked on older Pivot versions but is broken in 0.8.42 (or before), probably because the addition of the numberBucket function is now automatically added.
So this issue might be twofold

numberBucket should work with string dimensions declared as type number
numberBucket shouldn't be automatically added just because a dimension is a number or there would need to be a way to disable this explicitly in cases when bucketizing is not desired.

Hi Sascha,
Do you have an entry for that dimension being a number in both the attributeOverrides section and the dimensions section? Good point about being to explicitly disable bucketing

Just an update on this -- we're planning on adding the option of indicating a numeric dimension isn't bucketable and later adding more possible configurations.
In terms of the query error, could you let me know if it happens with both entries in the config? Thanks a lot!

Hi Sascha,
In 0.9.27 you can indicate a bucketing strategy for a dimension in the config.
bucketingStrategy: neverBucket
would turn off bucketing for that dimension. Please let us know if you're still seeing the query error issue, thanks!

Hi Eva,
sorry for coming back to you so late.
Interesting results:

bucketingStrategy: works on our end and if I use it as part of the dimension declaration section, when splitting on a field that has this declaration will cause the bar-chart view to show, rather than the table view.

using a NUMBER type definition in the attributeOverrides and NOT repeating the type definition in the dimensions section works and will pull up the table view when making a split on that field

using a NUMBER type definition in the attributeOverrides section AND in the dimension section for the respective field works and will pull up the bar-chart view when making a split on that field

Thanks a lot for your effort. Don't know if the behaviour concerning the bar-chart vs. table view is according to your expectation. Ultimately it would probably be best to make this an explicit config rather than having to implicitly model this by user one way of configuring stuff over another, but for now its really nice that both behaviours can be had.

Hi Sascha! We are working on fleshing out visualization picking behavior in general

One more thing: what I missed in my last tests where query-time-lookups. I now noticed that when a dimension is declared to be a number and works in Pivot as a dimension because the bucketingStrategy is set to neverBucket, it is nonetheless the case that QTL lookups on that dimension fail with the excption
"lookups must have input of type stringor SET/STRINGS (is NUMBER)


Support preprocessor for the yara rules

You can reuse spp if you want, it's a generic preprocessor i wrote many years ago and its now integrated within rasm2 to handle includes, ifdefs, variables, etc...
What i need here is:

Conditionals depending if yara is compiled with a specific module so i can show a warning or include a different rule.

The checks for those conditionals may be also defined by the user, so you would be able to do something like yarac -DMY_RULES=1 ...

This requires a way to use warning() and error() from that yara syntax.

This has been a desired feature for a long time (see #61).

here's the code of spp https://github.com/radare/spp
feel free to use it and abuse it

Closing is this is a duplicate of #61.


Installing Dev container extension does not have any impact on Continue Working On picker

Testing #172042

Install additional development environment options shows Dev Containers, Codespaces and Remote Repositories extension
I Installed Dev Containers extension and ran Continue Working On command
I do not see any options for dev container and when I clicked on Install additional development environment options it shows again same extensions list. So I am confused or stuck to understand what I have to do after.

Dev Containers only contributes a Continue On option if you're currently in a remote repository, and it looks like you are in a desktop repo, so this is currently as designed.


Cloud Run Sidecar Won't Update

I was having trouble updating a service I was using to deploy a sidecar container configuration.   The image being built was the same as the image I updated.  I needed to run
gcloud run services add-iam-policy-binding [SERVICE_NAME] \
    --member="allUsers" \
    --role="roles/run.invoker"

To update the container policy on every
gcloud run services replace service.yaml
It'd be cool if that was managed.  Keep up the good work!

I'm not clear on exactly what you are asking. What does "managed" mean in this context?

More a feature request: to only apply the policy-binding once for each service not on every replacement.

Feature request has been noted internally


Add Static Deployment Guide to Docs

Motivation
For the moment, we want to optimize for the fastest path for a developer to get an application deployed. Self-hosting on KUBE is a definite roadbump and is not super-streamlined yet. We could build a dx deploy to allow users to deploy directly to a hosted KUBE, but not today!
Finish Line

[ ] Add a guide page in Hosting and Deployment for deploying to Netlify, Vercel, etc
[ ] Re-order the Hosting and Deployment section to flow better
[ ] Link to this guide from the Getting Started Guide.

Some notes I took while working through deployment:

deploying to Netlify
trying to connect to localhost vault - doesn't appear to be specified in production?
how to set the production environment variable?
it complained about not being able to start telemetry - makes me nervous!
got a "your app name is ready to work offline" toast which was weird
need to specify DX_ENVIRONMENT environment variable?
Search the repo for Kube-specific deployment stuff and rip it out
Move into a "Kube self-deployment" guide


Grammar fix in CONTRIBUTING.md

"Can you write some tutorial/example?"
changed to
"Can you write some tutorials/examples?"
Alternatively we could do
"Can you write a tutorial/example?"

@cypressru thanks for the review!


HTTP to HTTPS redirect

Enhancement Proposal
After tls is enabled in traefik, a rule could be created for HTTP to HTTPS redirects. I see no reason not to do that.
An example of how to implement that can be found here.

Duplicate of #176

From the docs, there are two places to declare https redirect:

"Traefik global", under entrypoints (ref). That is the topic of this issue and is not impl'd in the charm.
Per-service, under middlewares (ref). This was impl'd in #178 but we don't really make use of it in practice.

what I want is that http requests are redirected to the https URL (of traefik). This should not be affected from the proxied application.
What is currently implemented is that IF the incoming request scheme is different from the application's scheme, THEN that request is redirected (changes the scheme). This means that http will be redirected to https only if the proxied application is serving https.
-- @nsklikas

More details:
When traefik is related to ca and then curl an ingress url with "http", then the endpoint cannot be reached:
$ curl -k http://<IP_ADDRESS>/bndl-prometheus-0/api/v1/targets
Moved Permanently%
$ curl -k -L http://<IP_ADDRESS>/bndl-prometheus-0/api/v1/targets
404 page not found

adding
  address: :80
  http:
    redirections:
      entryPoint:
        to: websecure
        scheme: https
websecure:

to the static config turns 404 into an internal server error, investigating...

k logs show:

got it. wasn't related to ca in the bundle


SVG thumbnails do not work

Problem

Currently SVG thumbnails do not work as they're not supported by our thumbnail service provider Photon. This feels like poor service to our users. How could we make sure they can view SVG thumbnails?
Description

On the frontend we fallback to the full direct image url when a thumbnail isn't available. Could we directly serve the SVGs through our /thumb endpoints? IS there another approach?
Additionally, on any search with the extension=svg query param set, all thumbnails will fail with 415 errors.
Alternatives

Currently < 2% of our thumbnails are 415 Unsupported Media type errors, so this does not impact many thumbnails and therefore, users.
Additional context

Yes, @roytanck, tiff is another file format that is not currently handled well by the /thumb endpoint. We use photon to thumbnail original images and to cache them. Unfortunately, it does not support tiff files, so we will need to create a separate solution. For now, as you say, we are returning "heavy and not supported by browsers" unaltered TIFF.


Cannot start on linux (ubuntu 16 - 64 bits)

Hi:
The native loader (PandomiumNativeLoader) loads missing dynamic libraries for linux:
chrome_elf.so is missing: does not exist in pandomium-linux/native/linux64-native.tar.xz file also missing from https://pandomium.panda-lang.org/download/native/1.0.0/linux64-native.tar.xz
jcef.so is missing: only exists libjcef.so
Bye.

I haven't tested the linux version yet, because I'm focued on windows. I've just packed the default output from jcef build. I'll build it again later (I think after I modify jcef source)

Let's go from bad to worse, this morning the windows computer only with the
intellij started and with the application of pandomium gives me the famous
blue screen of windows, there must be a serious problem with the native
part.
Now Intellij gets corrupted, I need to reinstall it.
2017-06-03 19:03 GMT+02:00 Dzikoysk<EMAIL_ADDRESS>
I haven't tested the linux version yet, because I'm focued on windows.
I've just packed the default output from jcef build. I'll build it again
later (I think after I modify jcef source)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Panda-Programming-Language/Pandomium/issues/4#issuecomment-305987962,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGBMzxfUGEk9_btCd-jsqew1APGqx7VSks5sAZHPgaJpZM4NvGR9
.

Upps, sorry bad ticket, this is related with windows 10 bug
2017-06-04 14:33 GMT+02:00 Joaquín Sánchez<EMAIL_ADDRESS>
Let's go from bad to worse, this morning the windows computer only with
the intellij started and with the application of pandomium gives me the
famous blue screen of windows, there must be a serious problem with the
native part.
Now Intellij gets corrupted, I need to reinstall it.
2017-06-03 19:03 GMT+02:00 Dzikoysk<EMAIL_ADDRESS>
I haven't tested the linux version yet, because I'm focued on windows.
I've just packed the default output from jcef build. I'll build it again
later (I think after I modify jcef source)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Panda-Programming-Language/Pandomium/issues/4#issuecomment-305987962,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGBMzxfUGEk9_btCd-jsqew1APGqx7VSks5sAZHPgaJpZM4NvGR9
.

Fixed in 30ebb749110f16a8ce4a006e5d643f67a474453c & 427361c977917cd8adfc8e36a36283f54258f4c2


Extended SSL_SESSION functions using time_t datatype

Hi Team,
Would really appreciate a review of this draft PR for #16726 (Y2038 overflow problem in API functions taking / returning long values)
There may be more functions and parts of openssl affected by the same issue. Instead of adding new tests, I've updated one existing test as well as modified the existing functions to call the new extended ones so we have better test coverage / less redundancy. Whilst this approach feels a bit "hacky", I figured this was cleaner than duplicating existing tests.
In terms of discovering other parts of openssl affected by Y2038, these are the only approaches I can think of:

Run openssl tests with a post Y2038 date in a 32 bit environment (pending)
Run tests for other openssl dependant software libraries with a post Y2038 date in a 32 bit environment

Checklist

[x] documentation is added or updated
[x] tests are added or updated

CLA submitted by email

Hi @paulidale,
Thanks for your feedback and review. I'll remove the offending line shortly.
Apologies, I'm new to the project, hence currently unfamiliar with the coding standards.
As for time_t v/s long on 32 bit systems, glibc has supported a new macro _TIME_BITS since v2.34, and this can be explicitly set to 64 bits on 32 bit systems:
https://www.gnu.org/software/libc/manual/2.34/html_node/Feature-Test-Macros.html#index-_005fTIME_005fBITS
Support for 64 bit time on 32 bit systems was also added in Linux 5.1:
https://kernelnewbies.org/Linux_5.1#More_Year_2038_preparation
https://lwn.net/Articles/776427/
As the use of the _TIME_BITS=64 changes the ABI, all of userspace on Linux needs to be recompiled. I can see a number of people interested in embedded systems have been running builds and tests using 64 bit time on 32 bit systems:
https://github.com/python/cpython/issues/101732
https://lists.openembedded.org/g/openembedded-core/topic/95354255#

We support a lot of platforms that don't have glibc or are Linux.
Any fix for this needs to be portable.
It might be worthwhile exposing the OSSL_TIME type publicly in order to address the 2038 problems.  A question for the OTC I suspect.

That is one possible solution.
Though one immediate concern is how many / which OSSL_TIME helper / utility functions to also expose publicly in tandem; either that or leave the external interpretation / transformation of these values up to external libraries.
I can see the base type for OSSL_TIME  is uint64_t, but returning this feels even messier.

OSSL_TIME is deliberately opaque, we can change the base type at any point.
We can also change the resolution.
Yes, the what else do we make public is the critical issue.
And once public, they are very difficult to change or remove.

Having reviewed the code, I think only the following would have to be publicly exposed to allow OSSL_TIME to be interpreted?
OSSL_TIME_SECOND
ossl_time2seconds

Additionally, documentation could be updated for any functions returning OSSL_TIME; to clarify whether this value is relative to the epoch or a different point in time.
I'm not sure what the process is for users / developers reaching out to OTC, do I have to send an email?
Granted this isn't urgent, happy to pick this up in 6-12 months so as not to disturb higher priority work.

I've added OTC hold on this which is the process for getting a resolution.  Now we need a question to be answered.  I propose:
OTC: should we expose OSSL_TIME publicly?
Note: I'm not proposing exposing the internal header file directly, we should wrapper OSSL_TIME in some calls that allow the underlying structure to remain opaque but usable by applications.
My guess is that the OTC will want to see a proposal before giving a definitive yes.  The outcome is most likely (IMO) to be: seems like a reasonable suggestion but we need to see some details or (less likely) a definitive no.

OTC: We currently do not want to expose OSSL_TIME as public type. We need to design a consistent approach to solving Y2K38 problem in OpenSSL APIs.

Thanks both,
I'll try and do some recon of other open source projects to see how they've handled the problem of storing / returning / representing DateTime values consistently across various platforms. I'm aware that multiple standards for representing dates and times already exist; picking an existing established standard instead of creating a new one may help minimise hassle.

The intention was never to expose OSSL_TIME as a public type.
This can be done by exposing it as an opaque structure.
I'm not sure there is a better solution but will wait and see...

I'm not sure I understand the argument against switching to time_t: legacy systems with 32 bit time_t will in any case collapse in 2038. Using more bits internally in openssl will not save them.
For what it's worth, Yocto project is already building all 32 bit targets with 64 bit time_t since a few weeks ago:
https://git.yoctoproject.org/poky-contrib/tree/meta/conf/distro/include/time64.inc?h=master
I've run openssl tests on a 32 bit x86 target with system clock set to 2040, and saw only (it happens on 64 bit systems too):
https://github.com/openssl/openssl/issues/21671

I'm not sure I understand the argument against switching to time_t: legacy systems with 32 bit time_t will in any case collapse in 2038. Using more bits internally in openssl will not save them.

This actually a good argument. We should not try to outsmart libc solution for the Y2K38 problem.

We should not try to outsmart libc solution for the Y2K38 problem.

I second this. My recon of other systems and projects is as follows:

A number of operating systems switched to 64 bit time_t in the last decade: https://en.m.wikipedia.org/wiki/Year_2038_problem#Implemented_solutions
Windows has defaulted to 64 bit time_t since Visual Studio 2005: https://learn.microsoft.com/en-us/cpp/c-runtime-library/time-management?view=msvc-170 (see note#2). These values have been relative to the UNIX epoch in all versions except v.7.0 (released in 2002)
Java presents its own Date class, and holds the information as a long internally, relative to Unix epoch, which should be 8 bytes / 64 bits: https://developer.classpath.org/doc/java/util/Date-source.html#line.119
Oracle database uses either 7, 11 or 13 bytes internally (56-104 bits) for TIMESTAMP data type depending on precision settings / presence of timezone information: https://docs.oracle.com/cd/E11882_01/server.112/e41085/sqlqr06002.htm#SQLQR959
Oracle also holds century and year information in separate bytes:
https://oracle-base.com/articles/misc/oracle-dates-timestamps-and-intervals#timestamp

We support a lot of platforms that don't have glibc or are not Linux

I would take the stance that for other platforms and compilers impacted, we would have to wait to see how they (community or vendor) are planning to update their systems in response to Y2038.
An interesting and potentially challenging example - SunOS seems to have an issue with certain "preposterous date"s for which I haven't been able to find any workarounds / best practice:
https://twitter.com/TubeTimeUS/status/1686244282586591232?t=IOfAT-c94Wc2noXjG0u7gw&s=19
@orcl-jlana @cernoseka: am I right in assuming that this is a related issue for any Solaris / SPARC OpenSSL builds using the Sun C compiler?

An interesting and potentially challenging example - SunOS seems to have an issue with certain "preposterous date"s for which I haven't been able to find any workarounds / best practice

I've since learnt that this issue has been reported to affect SunOS v4.1.4 - released in Nov 1993 - so isn't really relevant here (apologies).
https://news.ycombinator.com/item?id=36966711
Additionally, the two community supported platforms on Sun C / Solaris are both 64 bit...:
solaris64-x86_64-cc
solaris64-sparcv9-cc

Whereas the 32 bit Solaris / Sparc / Sun C ones are unadopted:
https://www.openssl.org/policies/general-supplemental/platforms.html

So is there a consensus now? Seems to me like everyone agrees that using time_t is fine, so this PR can move forward?

@paulidale Can you please state if your concerns have been resolved by the above comments?
I want to stress again that 32 bit retrocomputing systems cannot be fixed by tweaking things in openssl. If there's no system wide solution for them, openssl shouldn't try to find one. On the other hand, the only known portable solution for actively maintained system that has emerged is indeed extending time_t to 64 bits. So openssl should simply use that.

This needs to be rebased, merge commits dropped and pulled out of the draft.

I just took a look at the actual changes, they seem alright and I can rebase via a separate PR, but should the functions using 'long' be marked as deprecated (due to not being Y2038 safe) at the same time?

I would give @TabLand the chance to rebase his PR first, only if he does not want to proceed with it you can take over.
No, I would not deprecate the existing functions. They are OK to be used on platforms with 64 bit long type and it is still some time till 2038. I think we should deprecate them some time in future though.

Hi Team,
Thanks for checking in, I will try to have a look later this evening otherwise happy for you to take over

Hi Team,
The fuzzers test seems to be failing. I'll update the branch to remove the conflict on CHANGES.md, hopefully the CI/CD rerun fixes it...

This PR is in a state where it requires action by @openssl/committers but the last update was 30 days ago

Looking at this, I would be willing to approve, but the conflicts need to be fixed first.
@t8m Are the util/libssl.num changes still good?

Looking at this, I would be willing to approve, but the conflicts need to be fixed first.
@t8m Are the util/libssl.num changes still good?

Yeah, this needs a rebase but otherwise the changes still look OK to me. Just FYI the window for adding things to 3.3 will close soon.

This pull request is ready to merge

Merged to the master branch. Thank you for your contribution.


Add KaggleDBQA Dataset

This PR adds the KaggleDBQA dataset to the Awesome Text2SQL project. KaggleDBQA is a challenging cross-domain evaluation dataset of real Web databases, featuring domain-specific data types, original formatting, and unrestricted questions.
The addition of KaggleDBQA to the list provides a more realistic evaluation setting for text-to-SQL parsers, fostering further research and development in this area.

This PR adds the KaggleDBQA dataset to the Awesome Text2SQL project. KaggleDBQA is a challenging cross-domain evaluation dataset of real Web databases, featuring domain-specific data types, original formatting, and unrestricted questions.
The addition of KaggleDBQA to the list provides a more realistic evaluation setting for text-to-SQL parsers, fostering further research and development in this area.

Thank you very much for your contribution and look forward to building open source projects with us！ @mh-malekpour


Terminated Event is not fired before disconnect

Your environment

ruby -v: ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux]
rdbg -v: rdbg 1.4.0

Describe the bug
It looks like in Remote Debug mode (DAP client nvim-dap) after the last program step, the debugger disconnects but doesn't fire 'Terminated Event'. In such situation, DAP client doesn't know the debugging of the debuggee has terminated and keeps the debug session alive forever. Thus requiring manual treatment.
To Reproduce

Start a debugger with rdbg --open --port 38698 target.rb in a terminal
Attach to the adapter with nvim-dap
Continue or step over till the very end of the program.
The debugger in the terminal disconnects.

Example of console output:
#14867:[>] {"type":"request","seq":52,"arguments":{"granularity":"statement","threadId":1},"command":"next"}
#14867:[<] {"type":"response","command":"next","request_seq":52,"success":true,"message":"Success","seq":62}
12
DEBUGGER: Disconnected.

Expected behavior
Before the debugger disconnects 'Terminated Event' is issued so the client could close the debug session properly.
Additional context
Relevant discussion in mfussenegger/nvim-dap

https://github.com/mfussenegger/nvim-dap/pull/436 solves the issue?
It's a bit tough to observe the debuggee's liveness (because the debugger runs in same process).
But not impossible.
If it should be supported, I'll work it.

The discussion in https://github.com/mfussenegger/nvim-dap/issues/469 and the change that resulted out of the conversion (https://github.com/mfussenegger/nvim-dap/pull/481) may be relevant to this as well.
The TL;DR version is that if the debugger process runs to completion, the debug adapter must send a terminated event. If the client sends a disconnect request before the debugger process finishes, the debug adapters behavior depends on whether a launch/attach configuration was used and on the (optional) terminateDebugee flag of the request.

the debug adapter must send a terminated event.

Could you give me a reference?

I think he refers to the Debug session end part of https://microsoft.github.io/debug-adapter-protocol/overview?

Thank you.

In all situations where a debug adapter wants to end the debug session, a terminated event must be fired.

I agree it should be, but not sure when the connection was lost accidentally.


Missing translations in banners

Provide the exact quote of the error or issue
The following are missing and need to be added in banners:

Missing Japanese translation for title in contents/data-display/banners/metadata.json

Does the feature already exist? Please link to it.
No response
Are you willing to participate in fixing this issue and create a pull request with the fix?
None

I'll do this


nanopolish index segmentation fault

nanopolish index is crashing immediately:
$ nanopolish index
Segmentation fault (core dumped)

This is a git clone with v0.8.0 checked out (want a named version rather than the latest). Compilation with gcc 4.8.5 on CentOS 7.3.1611 appeared to have worked OK (despite usual flood of warnings from HDF5, so I might have missed something, but compilation of nanopolish_index.cpp reported no warnings or errors), and other commands at least show usage:
$ nanopolish
error: no command provided
usage: nanopolish [command] [options]
  valid commands:
    --help
    --version
    call-methylation
    eventalign
    extract
    getmodel
    help
    index
    methyltrain
    phase-reads
    scorereads
    variants
  for help on given command, type nanopolish command --help

$ nanopolish extract
extract: no paths to process

Usage: nanopolish extract [OPTIONS] <fast5|dir>...
Extract reads in fasta format

      --help                           display this help and exit
      --version                        display version
  -v, --verbose                        display verbose output
  -r, --recurse                        recurse into subdirectories
  -q, --fastq                          extract fastq (default: fasta)
  -t, --type=TYPE                      read type: template, complement, 2d, 2d-or-template, any
                                         (default: 2d-or-template)
  -b, --basecaller=NAME[:VERSION]      consider only data produced by basecaller NAME,
                                         optionally with given exact VERSION
  -o, --output=FILE                    write output to FILE (default: stdout)

Report bugs to https://github.com/jts/nanopolish/issues

Please could you give me a hand with this? Couldn't see anything related in the recent commits or issues, apologies if I missed something. Thanks.

Hi John,
I've fixed this and tagged the new version as 0.8.1 for you.
Jared

Excellent, thank you very much Jared! Works fine now.


CAMEL-19058: fix a type check scability issue for Message types

Using the type check agent, we can see that the Message type is hit pretty hard by the type check scalability issue and reports quite a lot of occurrences for these types:
--------------------------
3:	org.apache.camel.support.DefaultMessage
Count:	197370941
Types:
	org.apache.camel.spi.DataTypeAware
	org.apache.camel.CamelContextAware
Traces:
	org.apache.camel.support.MessageSupport.copyFrom(MessageSupport.java:199)
		class: org.apache.camel.spi.DataTypeAware
		count: 98685471
	org.apache.camel.CamelContextAware.trySetCamelContext(CamelContextAware.java:28)
		class: org.apache.camel.CamelContextAware
		count: 98685470

This resolves most of them.

Obs.: this one does not necessarily bring material changes to the throughput as the code is contended in other places, but does solve the reports.

Obs. 2: it uses the same pattern as in the other fixes, which replaces inheritance with delegation.

Hmm now we create a new object per message (the trait) only for fringe features like JMS external redelivery and dataType (not really much in use).

Yeah. There's that, indeed - though the memory overhead is probably small. One alternative I considered is to have the traits as a bit mask. It would make the code a little bit more complex, but may consume less memory overall.
What do you think?

Also mind that PooledExchange has a reset that, see reset method on Message. You likely need to reset the trait or something.

Thanks, noted. I'll take a look.

@davsclaus actually, let me try the alternative approach on this one. Let's put it on hold for now.

I am planning to go back to this work very soon. I had to divert my priorities to something else.

I'm closing this one. This was superseded by #9968


Updated validations.py Python script

Updated validations.py python script.
Fixed the behavior of validate_user function in validations.py.
Closes: #1
Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

This was a simple fix with regex. In the future you might need conditionals.


CHANGE THE PATH

when i open the app
it open de path  C:\Users\Administrator
i try to change to d:\ by file→ open from path...→ d:/
but it fail
anybody can help me ?
THK!

open from path... is meant to open a notebook or a file based on path relative to the root directory. It looks that you are trying to change the root directory; this has to be done prior to launching JupyterLab Desktop and different ways of doing so are described in the README: https://github.com/jupyterlab/jupyterlab-desktop#launching-jupyterlab-desktop

closing since no response for a long time. CLI can be used to launch in another directory. Also, new version will have ability to open another directory from UI.


fix issues with the refactored config and dict_compiler

Fixes #176

Seems that my custom schema (wubi98 in user directory) still down, nothing generated.

@nameoverflow Fixed the issue building user schema. Please take another look.

lgtm

@lotem Perhaps it is time to draft the 1.2.10 release. Please take time to update ChangeLog.

@Prcuvu It's on the way https://github.com/rime/librime/tree/changelog
Shall we include https://github.com/rime/librime/pull/178 in the release?

Yes.


Is it possible to add a template to pointLabels in Radar Graph?

I can see that its possible to set the font-family, font-size and weight but not if its possible to turn of the pointLabels or set a custom template for them for styling?
I have some overly long point labels, as an example
"Very long question point not wrapping label"

But have a design that wraps the longer lines on 2 lines and adds the index+1, normally I would set a (max-)width but don't appear to be able to amend this.

The long labels are not to much of an issue at large screen sizes but on smaller screen sizes as it scales down the graph becomes to small to be legible

Alternatively is it possible to hide/replace the labels as the graph width is reduced.
Thanks

@tannerlinsley Is this fixed in 2.0 alpha?

Scales are more of @etimberg 's thing. What do you think?

I don't think this is possible yet. @etimberg?
On Wed, Jun 3, 2015 at 10:43 PM Derek Perkins<EMAIL_ADDRESS>wrote:

@tannerlinsley https://github.com/tannerlinsley Is this fixed in 2.0
alpha?
—
Reply to this email directly or view it on GitHub
https://github.com/nnnick/Chart.js/issues/1110#issuecomment-108719941.

This isn't possible at the moment. We could look into adding it if it becomes a popular request

I had to play around with the label positions but I was able to get the labels to wrap using the following tutorial http://www.html5canvastutorials.com/tutorials/html5-canvas-wrap-text-tutorial/
I had to play about with the value used to adjust the label position
var largestPossibleRadius = min([(this.height/2 - this.pointLabelFontSize - 15), this.width/2])

I added the wrapText function from the tutorial,
		wrapText : function (context, text, x, y, maxWidth, lineHeight) {
		/**
		 * Wraps text onto multiple lines if it exceeds the maxWidth
		 * the lineHeight determines where the next line starts
		 * @type {Array}
		 */
		var words = text.split(' ');
		var line = '';

		for(var n = 0; n < words.length; n++) {
			var testLine = line + words[n] + ' ';
			var metrics = context.measureText(testLine);
			var testWidth = metrics.width;
			if (testWidth > maxWidth && n > 0) {
				context.fillText(line, x, y);
				line = words[n] + ' ';
				y += lineHeight;
			}
			else {
				line = testLine;
			}
		}
		context.fillText(line, x, y);
	},

Then in the draw function replaced the fillText function
//ctx.fillText(this.labels[i], pointLabelPosition.x, pointLabelPosition.y); //removed this

//and added this
this.wrapText(ctx, this.labels[i], pointLabelPosition.x, pointLabelPosition.y, this.maxWidth, this.lineHeight);

//Using initialised variables
maxWidth : 100,
lineHeight : 14,

Added a callback function to v2 in #1879 to allow changing point labels that display on the scale


CCT Capsule doesn't match the PhysicsMesh capsule

Describe the bug
Character Controller capsule doesn't match physx capsule and so you can stand on the head of the avatars / NPCs
To Reproduce
Steps to reproduce the behavior:
Load a vrm ( avatar ) and try to stand on the avatar's head
Expected behavior
Avatar should have proper cct physics
Screenshots

Better to match the character controller with this: https://github.com/webaverse/app/pull/3493/files


Cannot open library: CoreFoundation.framework/CoreFoundation

Getting this error on M1 mac.
Using same eclipse and SDK configuration on both an intel based mac and apple silicon.
Config differences

Intel: macOS Masonry
Apple Silicon: macOS Sonoma

OpenJDK 21
VM args: --enable-preview --enable-native-access=net.codecrete.usb
Exception in thread "main" java.lang.reflect.InvocationTargetException 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118) 	at java.base/java.lang.reflect.Method.invoke(Method.java:580) 	at java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1135) Caused by: java.lang.ExceptionInInitializerError 	at net.codecrete.usb@0.6.1/net.codecrete.usb.macos.gen.corefoundation.CoreFoundation.<clinit>(CoreFoundation.java:20) 	at net.codecrete.usb@0.6.1/net.codecrete.usb.macos.CoreFoundationHelper.createCFStringRef(CoreFoundationHelper.java:61) 	at net.codecrete.usb@0.6.1/net.codecrete.usb.macos.MacosUSBDeviceRegistry.<clinit>(MacosUSBDeviceRegistry.java:50) 	at net.codecrete.usb@0.6.1/net.codecrete.usb.USB.createInstance(USB.java:30) 	at net.codecrete.usb@0.6.1/net.codecrete.usb.USB.instance(USB.java:47) 	at net.codecrete.usb@0.6.1/net.codecrete.usb.USB.getAllDevices(USB.java:68) 	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method) 	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1160) 	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.ensureClassInitialized(MethodHandleAccessorFactory.java:300) 	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.newMethodAccessor(MethodHandleAccessorFactory.java:71) 	at java.base/jdk.internal.reflect.ReflectionFactory.newMethodAccessor(ReflectionFactory.java:159) 	at java.base/java.lang.reflect.Method.acquireMethodAccessor(Method.java:726) 	at java.base/java.lang.reflect.Method.invoke(Method.java:577) 	at javafx.graphics@21/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:464) 	at javafx.graphics@21/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:364) 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) 	... 2 more Caused by: java.lang.IllegalArgumentException: Cannot open library: CoreFoundation.framework/CoreFoundation 	at java.base/java.lang.foreign.SymbolLookup.libraryLookup(SymbolLookup.java:277) 	at java.base/java.lang.foreign.SymbolLookup.libraryLookup(SymbolLookup.java:238) 	at net.codecrete.usb@0.6.1/net.codecrete.usb.macos.gen.corefoundation.RuntimeHelper.<clinit>(RuntimeHelper.java:26) 	... 20 more

Thank you for reporting this problem. I was able to reproduce it.
I will need to investigate it further as I don't understand yet under what circumstances and why it occurs.

From what I can tell so far, it seems to be related to the JDK. If I run it with the JDK installed through homebrew ("OpenJDK Runtime Environment Homebrew (build 21.0.1)") it fails. If I run it with the Zulu JDK ("OpenJDK Runtime Environment Zulu21.30+15-CA (build 21.0.1+12-LTS)", it works.
What is your output of "java -versoin"?

I see, I am using the homebrew version.
Output:
openjdk version "21.0.1" 2023-10-17 OpenJDK Runtime Environment Homebrew (build 21.0.1) OpenJDK 64-Bit Server VM Homebrew (build 21.0.1, mixed mode, sharing)

So for the moment, take any other JDK, either using brew:
brew install zulu

or:
brew install temurin

or download it directly from:
https://www.azul.com/downloads/#zulu
or:
https://openjdk.org/projects/jdk/21/
or:
https://adoptium.net/en-GB/temurin/releases/
And then make sure, it's actually used...

I did install the azul JDK and I can confirm it is working.
When I use OpenJDK from homebrew I get this warning as well in the beginning of the console output:
WARNING: Secure coding is automatically enabled for restorable state! However, not on all supported macOS versions of this application. Opt-in to secure coding explicitly by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState:.
So far the apps I've ran still work (except for the current using this library) but I noticed this warning was not apparent when I ran with azul version of JDK.
Don't know if that gives you any more indication to where the problem lies.
Thanks for temporary solution 👍

I have opened an issue in the homebrew/core project: https://github.com/Homebrew/homebrew-core/issues/158901

The new version 0.7.1 of this library should now be compatible with all JDK 21 builds.

The new version 0.7.1 of this library should now be compatible with all JDK 21 builds.

Tested and can confirm it's working with OpenJDK 21 from Homebrew on M1 👏


EPG files not working and showing 404.

Hi,
We are referring the following file: https://iptv-org.github.io/api/guides.json for getting the program's data from the URLs mentioned there in this file and looking at the URLs it looks like the links has been made private.
For eg: https://iptv-org.github.io/epg/guides/en/mtel.ba.json
Is there any way to access this data?

Is there any way to access this data?

No, access to these files is currently restricted to everyone.
More details: https://github.com/iptv-org/iptv-org.github.io/issues/9#issuecomment-1430887905


numberOfMonths shows future months even when that is over the maxDate

I need a range picker to select the last N days, showing history.
If I set up the picker like this:
<DatePicker
    range
    maxDate={new Date()}
    value={values}
    numberOfMonths={2}
/>

With the default values ([]), it will show the current month and the next month, but I think it should show the previous month and the current one, since the next month is after the maxDate

Hi, you need to use currentDate prop:


Apollo.create() throws Error: Uncaught (in promise)

Intended outcome: Apollo has been installed using ng add. Then I only used the following code from https://www.apollographql.com/docs/angular/recipes/authentication#header:
@NgModule({
    declarations: [
        AppComponent,
    ],
    imports: [
        // ...
        ApolloModule,
        HttpLinkModule,
    ],
})
export class AppModule implements NgxsHmrLifeCycle<Snapshot> {
    constructor(
        apollo: Apollo,
        httpLink: HttpLink
    ) {
        const uri = `http://${environment.api.host}:${environment.api.port}/graphql/`;

        const http = httpLink.create({uri});

        try {
            const auth = setContext((_, {headers}) => {
                // get the authentication token from local storage if it exists
                const token = 'test';
                // return the headers to the context so httpLink can read them
                // in this example we assume headers property exists
                // and it is an instance of HttpHeaders
                if (!token) {
                    return {};
                } else {
                    return {
                        headers: headers.append('Authorization', `JWT ${token}`)
                    };
                }
            });

            const link = auth.concat(http);

            apollo.create({
                link: link,
                cache: new InMemoryCache(),
            });
        } catch (e) {
            console.log(e);
        }
    }
}

I simplified it and trying to debug the error, but without success for now. The exact command it breaks is apollo.create().

Actual outcome:

ERROR Error: Uncaught (in promise): [object Undefined]
    at resolvePromise (zone.js:831)
    at resolvePromise (zone.js:788)
    at zone.js:892
    at ZoneDelegate.push../node_modules/zone.js/dist/zone.js.ZoneDelegate.invokeTask (zone.js:423)
    at Object.onInvokeTask (core.js:17280)
    at ZoneDelegate.push../node_modules/zone.js/dist/zone.js.ZoneDelegate.invokeTask (zone.js:422)
    at Zone.push../node_modules/zone.js/dist/zone.js.Zone.runTask (zone.js:195)
    at drainMicroTaskQueue (zone.js:601)
  | defaultErrorLogger | @ | core.js:15714
-- | -- | -- | --
  |<EMAIL_ADDRESS>| @ | core.js:15762
  | next | @ | core.js:17761
  | schedulerFn | @ | core.js:13504
  | push../node_modules/rxjs/_esm5/internal/Subscriber.js.SafeSubscriber.__tryOrUnsub | @ | Subscriber.js:196
  | push../node_modules/rxjs/_esm5/internal/Subscriber.js.SafeSubscriber.next | @ | Subscriber.js:134
  | push../node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber._next | @ | Subscriber.js:77
  | push../node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next | @ | Subscriber.js:54
  | push../node_modules/rxjs/_esm5/internal/Subject.js.Subject.next | @ | Subject.js:47
  |<EMAIL_ADDRESS>| @ | core.js:13488
  | (anonymous) | @ | core.js:17311
  | push../node_modules/zone.js/dist/zone.js.ZoneDelegate.invoke | @ | zone.js:391
  | push../node_modules/zone.js/dist/zone.js.Zone.run | @ | zone.js:150
  |<EMAIL_ADDRESS>| @ | core.js:17248
  | onHandleError | @ | core.js:17311
  | push../node_modules/zone.js/dist/zone.js.ZoneDelegate.handleError | @ | zone.js:395
  | push../node_modules/zone.js/dist/zone.js.Zone.runGuarded | @ | zone.js:164
  | _loop_1 | @ | zone.js:694
  | api.microtaskDrainDone | @ | zone.js:703
  | drainMicroTaskQueue | @ | zone.js:608
  | Promise.then (async) |   |
  | scheduleMicroTask | @ | zone.js:584
  | push../node_modules/zone.js/dist/zone.js.ZoneDelegate.scheduleTask | @ | zone.js:413
  | onScheduleTask | @ | zone.js:301
  | push../node_modules/zone.js/dist/zone.js.ZoneDelegate.scheduleTask | @ | zone.js:404
  | push../node_modules/zone.js/dist/zone.js.Zone.scheduleTask | @ | zone.js:238
  | push../node_modules/zone.js/dist/zone.js.Zone.scheduleMicroTask | @ | zone.js:258
  | scheduleResolveOrReject | @ | zone.js:879
  | resolvePromise | @ | zone.js:825
  | (anonymous) | @ | zone.js:741
  | webpackJsonpCallback | @ | bootstrap:25
  | (anonymous)

How to reproduce the issue:

I made a reproduction (https://stackblitz.com/edit/simple-apollo-angular-example-kmtn2z?file=app%2Fgraphql.module.ts), however it throws another error:
ERROR
Error: Encountered a sub-selection on the query, but the store doesn't have an object reference. This should never happen during normal use unless you have custom code that is directly manipulating the store; please file an issue.

Versions

"apollo-angular": "1.5.0",
"apollo-angular-link-http": "^1.3.1",
"apollo-cache-inmemory": "^1.3.2",
"apollo-client": "^2.4.0",
"apollo-link": "^1.2.0",
"apollo-link-context": "1.0.17",

"@angular/animations": "7.2.1",
"@angular/cdk": "7.2.1",
"@angular/common": "7.2.1",
"@angular/compiler": "7.2.1",
"@angular/core": "7.2.1",
"@angular/flex-layout": "7.0.0-beta.23",
"@angular/forms": "7.2.1",
"@angular/http": "7.2.1",
"@angular/material": "7.2.1",
"@angular/material-moment-adapter": "7.2.1",
"@angular/platform-browser": "7.2.1",
"@angular/platform-browser-dynamic": "7.2.1",
"@angular/router": "7.2.1",

"graphql": "^0.13.2",
"graphql-tag": "^2.10.0",

"typescript": "3.2.2",

Any ideas?

Fixed in https://github.com/apollographql/apollo-angular/pull/1161


Logging with java.util.logger

Hi,
I want ormlite to use java.util.logger as default logger. I found the JavaUtilLog class but no way to configure it, because the LoggerFactory does not support this logging type. Is there a way?
Cheers.

Interesting.  I guess I always assumed that no one would want to use JavaUtilLog.  I've added it into the mix however with it's own type but it won't ever be chosen by default.

I moved it to -core as well.  See: https://github.com/j256/ormlite-core/commit/661d20e13f11ecd4044e690a3ca98a1d4eadc308