Chart UUID not exposed in API but required when creating dashboard via API

In order to create a dashboard with the API, the UUID(s) of charts on the dashboard must be supplied in the serialized JSON object in the position_json attribute of the request to POST /dashboard/ (attribute name uuid).  This UUID is apparently created internally with the chart (say, during a POST to /chart/) but the UUID value is not returned in the create chart response, nor by any other chart-related API, making it impossible to know / ascertain the UUID of charts via the API and therefore create a dashboard with the API immediately following creation of charts with the API.
Noting that chart UUIDs can be determined if they are manually added to a dashboard through the UI and then a GET /dashboard/{pk}` is performed.
Expected results
Upon creating a chart, the UUID of the chart should be returned in the response JSON from POST /chart/.
Actual results
No UUID is returned.
How to reproduce the bug
Prerequisites:

CSRF is disabled (add WTF_CSRF_ENABLED = False to superset/config.py)
Install curl for testing the API and jq for parsing JSON
SUPERSET_HOST=localhost:8088
SUPERSET_USER=admin; SUPERSET_PASSWORD=admin

Obtain a TOKEN
TOKEN=$(curl -s http://$SUPERSET_HOST/api/v1/security/login -H 'accept: application/json' -H 'Content-Type: application/json' -d '{ "password": "'$SUPERSET_PASSWORD'", "provider": "db", "refresh": true, "username": "'$SUPERSET_USER'" }' | jq -r .access_token)

Look up flights dataset
DATASOURCE_ID=$(curl -s -H 'Authorization: Bearer '$TOKEN'' http://$SUPERSET_HOST/api/v1/dataset/'?q=%7B%0A%20%20%22filters%22%3A%20%5B%0A%20%20%20%20%7B%0A%20%20%20%20%20%20%22col%22%3A%20%22table_name%22%2C%0A%20%20%20%20%20%20%22opr%22%3A%20%22eq%22%2C%0A%20%20%20%20%20%20%22value%22%3A%20%22flights%22%0A%20%20%20%20%7D%0A%20%20%5D%0A%7D' | jq -r '.result[0].id')

Create a chart
curl -s 'http://'$SUPERSET_HOST'/api/v1/chart/' \ -H 'Authorization: Bearer '$TOKEN'' \ -H 'Accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "datasource_id": '$DATASOURCE_ID', "description": "Test", "slice_name": "Test", "datasource_type": "table", "viz_type": "bar", "params": "{\n  \"adhoc_filters\": [],\n  \"annotation_layers\": [],\n  \"bar_stacked\": false,\n  \"bottom_margin\": \"auto\",\n  \"color_scheme\": \"supersetColors\",\n  \"comparison_type\": \"values\",\n  \"datasource\": \"10__table\",\n  \"extra_form_data\": {},\n  \"granularity_sqla\": \"ds\",\n  \"groupby\": [\n    \"AIRLINE\"\n  ],\n  \"label_colors\": {},\n  \"left_margin\": \"auto\",\n  \"limit\": 500,\n  \"line_interpolation\": \"linear\",\n  \"metrics\": [\n    {\n      \"aggregate\": null,\n      \"column\": null,\n      \"expressionType\": \"SQL\",\n      \"hasCustomLabel\": false,\n      \"isNew\": false,\n      \"label\": \"AVG(COALESCE(\\\"AIRLINE_DELAY\\\",0))\",\n      \"optionName\": \"metric_7f2c9v9wh7o_rkdrxg4i2pk\",\n      \"sqlExpression\": \"AVG(COALESCE(\\\"AIRLINE_DELAY\\\",0))\"\n    }\n  ],\n  \"order_desc\": false,\n  \"rich_tooltip\": true,\n  \"rolling_type\": \"None\",\n  \"row_limit\": null,\n  \"show_bar_value\": false,\n  \"show_brush\": \"auto\",\n  \"show_controls\": false,\n  \"show_legend\": true,\n  \"slice_id\": 465,\n  \"time_grain_sqla\": null,\n  \"time_range\": \"No filter\",\n  \"time_range_endpoints\": [\n    \"inclusive\",\n    \"exclusive\"\n  ],\n  \"timeseries_limit_metric\": [],\n  \"url_params\": {},\n  \"viz_type\": \"bar\",\n  \"x_axis_format\": \"%m/%d/%Y\",\n  \"x_axis_label\": \"Day\",\n  \"x_ticks_layout\": \"auto\",\n  \"y_axis_bounds\": [\n    null,\n    null\n  ],\n  \"y_axis_format\": \"SMART_NUMBER\",\n  \"y_axis_label\": \"Average Delay (mins) by Airline\"\n}" }'

Notice that no UUID is returned in the response (example):
{   "id": 139,    "result": {     "datasource_id": 10,      "datasource_type": "table",      "description": "Test",      "params": "{\n  \"adhoc_filters\": [],\n  \"annotation_layers\": [],\n  \"bar_stacked\": false,\n  \"bottom_margin\": \"auto\",\n  \"color_scheme\": \"supersetColors\",\n  \"comparison_type\": \"values\",\n  \"datasource\": \"10__table\",\n  \"extra_form_data\": {},\n  \"granularity_sqla\": \"ds\",\n  \"groupby\": [\n    \"AIRLINE\"\n  ],\n  \"label_colors\": {},\n  \"left_margin\": \"auto\",\n  \"limit\": 500,\n  \"line_interpolation\": \"linear\",\n  \"metrics\": [\n    {\n      \"aggregate\": null,\n      \"column\": null,\n      \"expressionType\": \"SQL\",\n      \"hasCustomLabel\": false,\n      \"isNew\": false,\n      \"label\": \"AVG(COALESCE(\\\"AIRLINE_DELAY\\\",0))\",\n      \"optionName\": \"metric_7f2c9v9wh7o_rkdrxg4i2pk\",\n      \"sqlExpression\": \"AVG(COALESCE(\\\"AIRLINE_DELAY\\\",0))\"\n    }\n  ],\n  \"order_desc\": false,\n  \"rich_tooltip\": true,\n  \"rolling_type\": \"None\",\n  \"row_limit\": null,\n  \"show_bar_value\": false,\n  \"show_brush\": \"auto\",\n  \"show_controls\": false,\n  \"show_legend\": true,\n  \"slice_id\": 465,\n  \"time_grain_sqla\": null,\n  \"time_range\": \"No filter\",\n  \"time_range_endpoints\": [\n    \"inclusive\",\n    \"exclusive\"\n  ],\n  \"timeseries_limit_metric\": [],\n  \"url_params\": {},\n  \"viz_type\": \"bar\",\n  \"x_axis_format\": \"%m/%d/%Y\",\n  \"x_axis_label\": \"Day\",\n  \"x_ticks_layout\": \"auto\",\n  \"y_axis_bounds\": [\n    null,\n    null\n  ],\n  \"y_axis_format\": \"SMART_NUMBER\",\n  \"y_axis_label\": \"Average Delay (mins) by Airline\"\n}",      "slice_name": "Test",      "viz_type": "bar"   } }
Nor is it in the GET /chart/{pk}:
From above response:
CHART_ID=139
curl -s -H 'Authorization: Bearer '$TOKEN'' -H 'accept: application/json' 'http://'$SUPERSET_HOST'/api/v1/chart/'$CHART_ID | jq .
{   "description_columns": {},   "id": 139,   "label_columns": {     "cache_timeout": "Cache Timeout",     "dashboards.dashboard_title": "Dashboards Dashboard Title",     "dashboards.id": "Dashboards Id",     "description": "Description",     "owners.first_name": "Owners First Name",     "owners.id": "Owners Id",     "owners.last_name": "Owners Last Name",     "owners.username": "Owners Username",     "params": "Params",     "slice_name": "Slice Name",     "viz_type": "Viz Type"   },   "result": {     "cache_timeout": null,     "dashboards": [],     "description": "Test",     "owners": [       {         "first_name": "Superset",         "id": 1,         "last_name": "Admin",         "username": "admin"       }     ],     "params": "{\n  \"adhoc_filters\": [],\n  \"annotation_layers\": [],\n  \"bar_stacked\": false,\n  \"bottom_margin\": \"auto\",\n  \"color_scheme\": \"supersetColors\",\n  \"comparison_type\": \"values\",\n  \"datasource\": \"10__table\",\n  \"extra_form_data\": {},\n  \"granularity_sqla\": \"ds\",\n  \"groupby\": [\n    \"AIRLINE\"\n  ],\n  \"label_colors\": {},\n  \"left_margin\": \"auto\",\n  \"limit\": 500,\n  \"line_interpolation\": \"linear\",\n  \"metrics\": [\n    {\n      \"aggregate\": null,\n      \"column\": null,\n      \"expressionType\": \"SQL\",\n      \"hasCustomLabel\": false,\n      \"isNew\": false,\n      \"label\": \"AVG(COALESCE(\\\"AIRLINE_DELAY\\\",0))\",\n      \"optionName\": \"metric_7f2c9v9wh7o_rkdrxg4i2pk\",\n      \"sqlExpression\": \"AVG(COALESCE(\\\"AIRLINE_DELAY\\\",0))\"\n    }\n  ],\n  \"order_desc\": false,\n  \"rich_tooltip\": true,\n  \"rolling_type\": \"None\",\n  \"row_limit\": null,\n  \"show_bar_value\": false,\n  \"show_brush\": \"auto\",\n  \"show_controls\": false,\n  \"show_legend\": true,\n  \"slice_id\": 465,\n  \"time_grain_sqla\": null,\n  \"time_range\": \"No filter\",\n  \"time_range_endpoints\": [\n    \"inclusive\",\n    \"exclusive\"\n  ],\n  \"timeseries_limit_metric\": [],\n  \"url_params\": {},\n  \"viz_type\": \"bar\",\n  \"x_axis_format\": \"%m/%d/%Y\",\n  \"x_axis_label\": \"Day\",\n  \"x_ticks_layout\": \"auto\",\n  \"y_axis_bounds\": [\n    null,\n    null\n  ],\n  \"y_axis_format\": \"SMART_NUMBER\",\n  \"y_axis_label\": \"Average Delay (mins) by Airline\"\n}",     "slice_name": "Test",     "viz_type": "bar"   },   "show_columns": [     "cache_timeout",     "dashboards.dashboard_title",     "dashboards.id",     "description",     "owners.first_name",     "owners.id",     "owners.last_name",     "owners.username",     "params",     "slice_name",     "viz_type"   ],   "show_title": "Show Slice" }
Environment

superset version: 1.2.0rc2

Checklist
Make sure to follow these steps before submitting your issue - thank you!

[X] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[X] I have reproduced the issue with at least the latest released version of superset.
[X] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context
Related issue:
#15457 Creating a dashboard with API does not result in a functioning dashboard

Maybe a little too late, but I had a similar problem. A quick-and-dirty fix is to edit the charts/api.py file as follows:
https://gist.github.com/hitzelc/10ad912bd246d4358728a8407ac2c842
You can see the addition in line 291. Now chart creation via a POST to the /chart/ endpoint will return the uuid associated with the chart.
The way I use this is as follows:

create a dashboard, get its id (POST /dashboard/)
create chart(s), with the desired dashboard id in the arguments (POST /chart/)
grab the uuid of these charts and update the dashboard with some position JSON that I hammer together (PUT /dashboard/)

Note: the position JSON is kind of a pain...when you create a dashboard via API is has no position JSON at all, even after you add charts to it. You have to manually save/edit any dashboard to have a position JSON associated with it. So I recommend you make your dashboards by hand with the charts you want, and then export that chart and steal that position JSON as a starting point (assuming your goal is to automate dashboard creation moving forward).

I would recommend against closing this ticket-- this is still an issue I am facing and it seems exceedingly onerous to figure out how to access the dashboard ID and do so right now.

It's been another year and a half, and the import/export code has changed quite a bit since then. Closing this as stale since it's been silent for so long, and we're trying to steer toward a more actionable Issues backlog. If people are still encountering this in current versions (currently 3.x) please open a new Issue with renewed context, or a PR to address the problem. Thanks for understanding.

This really seems like an important issue so it would be a good idea to keep it open. uuids are not exposed in the API which makes it almost impossible to really control dashboards from the API. So perhaps it should be included?


whitelists.yaml error

Installed from https://hub.crowdsec.net/author/crowdsecurity/configurations/whitelists cscli parsers install crowdsecurity/whitelists
my file:

description: "Whitelist events from private ipv4 addresses"
whitelist:
reason: "private ipv4/ipv6 ip/ranges"
ip:
- "<IP_ADDRESS>"
- "privacy"
cidr:
- "<IP_ADDRESS>/34"

after systemctl reload crowdsec or a regular stop/start i get the following error:
msg="Error decoding parsing configuration file '/etc/crowdsec/parsers/s02-enrich/whitelists.yaml': yaml: line 7: did not find expected key"

Hello @stratege1401
It seems the yaml is invalid, did you let a space slip a the beginning on the cidr line ? :wink:

space slip or not, i did a cscli parsers install crowdsecurity/whitelists
Then, i changed to my value ( notice my first cidr value was wrong ).
Now, it seem to work....


Tier 8 harvesters bug

There seems to be a bug in witch the tier 8 harvesters go faster and faster in harvesting, getting stacks, at a time after 20-30 seconds of running.
Even weirder if the max stacksize of the inventory is bigger (like with dank nulls) sometimes it gives the max stack size (even the 2B) or just a very big amount.
This seems to happens only on tier 8s, but maybe it's just a lot slower in tier 7s and down. Tested with the latest version of the mod and the previous one.

Well, I can pretty much confirm that if the speed thing is really happening, it's not exclusive to the tier 8s, since they're all controlled by the same code. They just change some variables to fit themselves, like the speed, outputs, and price. I can't see anything that would cause it though. Did you add an extra space ripper before it started? The outputs are per ripper. As for the stack size issue, my best guess is that it's because of something to do with the inventories since each stack is either of size one or of whatever was dropped by a mob if it's that harvester. That and I'm using a Forge provided method to do the actual insertion of the items. Thanks for your participation, by the way!

I tested the speed thing and didn't see any change, it's pretty fast so I think it was just an illusion. With that and my thinking that there's nothing I can do about the stack sizes, I'll close this for now. Thanks!

So to answer some questions and add some details:

no there was just one space ripper. In my survival I had 4 of them, up to the 7s, then I upgraded and my dank null (maxed out) starter filling in with dimensional shard (rftools) 2B per space at a time.
After that I testwd in a fresh world with one space ripper in a vanilla chest and it happened 64s per iteration of the machine.
-resetting the machine (getting a new one for example) seems to change the random output, like one time with coal, one time with gold and so on.
-this is presenten (at least it seems) in all harvesters that are fast enought, so ore, soil ... And so on. Maybe, because of the fact that they are all the same, I didn't see it for lower tears due to time, I'm probably going to test it overnight with a server to see if it happens with tear 7s.
-the issue seemed to diminish in the latest update, since before that it was filling chest at a ridiculous speed, where in the latest update is "x stacks" per harvest. Still means that I did get 100k iron in 5 minutes, but ...
If it's not clear I love the mod, and I like how it's a lag free (almost) alternative for most stuff, inspired by woot, envorimental tech  and those sorts of mods, so no problem for the input, I will continue to give because I'd really like to see this mod take off on tech packs now that 1.16 seems to be growing.

I forget which one it was, I guess it was the last one, but in a recent update, I fixed an issue where the harvesters weren't consuming power. Maybe that was what caused the speed thing. Thanks for the supportiveness!


Add more item-level documentation

We could probably spend a whole week trying to improve it. For me it's good enough for the first release.


Suffix wildcards

adds ability to use suffix as a wildcard
exposes wildcards to CLI with --wildcards_<input_name> options (like --filter_*)

@tkkuehn had a go at this after trying out  snakebids2dicom.
The edit needed was actually fairly minimal, just needed to deal with suffix as a special case and regex differently, but while I was at it I exposed the wildcards list to the CLI too (will be more generally useful)..
I've also edited snakebids2dicom with this change, look out for a PR soon on that, and will be pushing some data to orthanc server too

Looks great! Would be good to add a test to cover this case, but otherwise I think this is ready to merge.

Thanks for adding the test @tkkuehn, I'll merge this in now!


CodeKaro Webiste

Prerequisites

[X] I am a GSSoC-22 Participant
[X] I checked to make sure that this issue has not already been filed

Description
A website where you can find all the coding contest which will going to happen in future
Tech Stack
React

Please assign this issue to me sir @abhijeet007rocks8

Please Review MY PR  @manisha-27 @abhijeet007rocks8


feat(provider-sdk)!: support directional link storage

feat(provider-sdk)!: support storing directional links
refactor(provider-sdk)!: remove link_name

Feature or Problem
This PR adds support to the provider SDK to store links in 2 different hashmaps, one for links where the provider is the source and one for where the provider is the target. This directionality is necessary in order to properly store different configuration, WASI interfaces, and different links where the provider is the source.
I don't believe this is a breaking change technically but I did modify the logic for link storage so providers might unknowingly depend on that, so a minor bump is appropriate.
Related Issues

Release Information
provider-sdk v0.5.0
Consumer Impact

Testing

Unit Test(s)

Acceptance or Integration

Manual Verification

This should also assist with #1882 and solving this problem for all providers


Added Yubikey support

Authentication can be done with certificate + username + Yubikey OTP

Sorry, this was submitted accidentally.  It's not ready to be contributed.


[CARBONDATA-2436][Query] Resolved Block pruning problem post the carbon schema restructure.

Currently DataMap is pruning with segmentproperties from the 0th block of BlockletDataMap is not
correct. As post restructure if the table is updated then all the block will not have
symmetric schema within the same segments.
Solution : It must be ensured the block could be pruned with the same schema.
Note: This is just a temporary fix only the main BlockletDataMap. The Segmentproperties is also
used for the MinMaxIndexDataMap also, the complete fix could be discussed at below mailing thread.     Refactored SegmentPropertiesFetcher to resolve pruning problem post the carbon schema restructure
…
Be sure to do all of the following checklist to help us incorporate
your contribution quickly and easily:

[X] Any interfaces changed?
NA
[X] Any backward compatibility impacted?
NA
[X] Document update required?
NA
[X] Testing done
Please provide details on
- Whether new unit test cases have been added or why no new tests are required?
- How it is tested? Please attach test report.
- Is it a performance related change? Please attach the performance test report.
- Any additional information to help reviewers in testing this change.
Added test case to verify the restructured table update and filter query scenario
[X] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/5610/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/4449/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/5615/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/4454/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/4456/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/4704/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/4709/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/4486/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/5646/

LGTM


getting error

Hello,
when i try to open gridsome in brower, getting following error
vue.runtime.esm.js?2b0e:619 [Vue warn]: Error in getter for watcher "$metaInfo": "TypeError: Cannot read property 'strapi' of null"

found in

---> <Index> at src/pages/Index.vue
       <App> at node_modules/gridsome/app/fallbacks/App.vue
         <Root>

can you tell me what went wrong?
thanks.

Hi,
i don't know what exactly wend wrong, but i run the same issue today. And I fond fix for that.
Just run:
yarn strapi install graphql

inside backend folder and restart strapi server.

Hello,
thanks for the fix, it works now.
eventhough admin panel shows graphql is installed...i guess there is a glitch.
Also.... this setup always connects to strapi.... it doesn't generate static files but instead always connects to strapi server.... am i correct?
thanks.

may be i missed somewhere but i thought this would export all data to markdown files into gridsome by parsing data using graphql.

another thing i found is... eventhough it is fetching data dynamically, whenever i add a new portfolio, i need to stop and start gridsome develop each time.

another thing i found is... eventhough it is fetching data dynamically, whenever i add a new portfolio, i need to stop and start gridsome develop each time.

It's the way how gridsome works. It needs to have all data at build time. So it fetch data only once and then when you develop it rebuild only templates.

another thing i found is... eventhough it is fetching data dynamically, whenever i add a new portfolio, i need to stop and start gridsome develop each time.

It's the way how gridsome works. It needs to have all data at build time. So it fetch data only once and then when you develop it rebuild only templates.

Also.... this setup always connects to strapi.... it doesn't generate static files but instead always connects to strapi server.... am i correct?
just like any typical DB based (php or wordpress) type of setup right?

Actually you can use it as static site. You just need to rebuild site every time you change data in Strapi. You can use webhook for that if you have CD which support that. For example with netlify build hook.

Also.... this setup always connects to strapi.... it doesn't generate static files but instead always connects to strapi server.... am i correct?
just like any typical DB based (php or wordpress) type of setup right?

Actually you can use it as static site. You just need to rebuild site every time you change data in Strapi. You can use webhook for that if you have CD which support that. For example with netlify build hook.

thanks, that clarifies.

thanks, that clarifies.


fix: Use 'tomli' package instead of 'toml' package.

The 'toml' package breaks on valid 'pyproject.toml' files which prevents Tryceratops from being integrated properly.
The 'tomli' package provides TOML 1.0 and 'tomllib' compatibility.
Had a similar patch accepted by the YAPF project in 2022.
Example of breakage with toml:
$ hatch --env develop run tryceratops
Traceback (most recent call last):
  File "/home/me/.local/share/hatch/env/virtual/accretive/5On6b-gH/develop/bin/tryceratops", line 8, in <module>
    sys.exit(main())
  File "/home/me/.local/share/hatch/env/virtual/accretive/5On6b-gH/develop/lib/python3.8/site-packages/tryceratops/__main__.py", line 66, in main
    entrypoint(prog_name="tryceratops")
  File "/home/me/.local/share/hatch/env/virtual/accretive/5On6b-gH/develop/lib/python3.8/site-packages/click/core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
  File "/home/me/.local/share/hatch/env/virtual/accretive/5On6b-gH/develop/lib/python3.8/site-packages/click/core.py", line 1078, in main
    rv = self.invoke(ctx)
  File "/home/me/.local/share/hatch/env/virtual/accretive/5On6b-gH/develop/lib/python3.8/site-packages/click/core.py", line 1434, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/me/.local/share/hatch/env/virtual/accretive/5On6b-gH/develop/lib/python3.8/site-packages/click/core.py", line 783, in invoke
    return __callback(*args, **kwargs)
  File "/home/me/.local/share/hatch/env/virtual/accretive/5On6b-gH/develop/lib/python3.8/site-packages/tryceratops/__main__.py", line 48, in entrypoint
    pyproj_config = load_config(dir)
  File "/home/me/.local/share/hatch/env/virtual/accretive/5On6b-gH/develop/lib/python3.8/site-packages/tryceratops/files/discovery.py", line 118, in load_config
    config = toml.load(toml_file)
  File "/home/me/.local/share/hatch/env/virtual/accretive/5On6b-gH/develop/lib/python3.8/site-packages/toml/decoder.py", line 134, in load
    return loads(ffile.read(), _dict, decoder)
  File "/home/me/.local/share/hatch/env/virtual/accretive/5On6b-gH/develop/lib/python3.8/site-packages/toml/decoder.py", line 362, in loads
    raise TomlDecodeError("Unterminated string found."
toml.decoder.TomlDecodeError: Unterminated string found. Reached end of file. (line 292 column 1 char 8542)

Successful run after switch to tomllib:
$ hatch --env develop run tryceratops
Done processing!
Nothing to check!
$ hatch --env develop run tryceratops sources
Done processing!
 I just need to update/fix the GHA to ensure all tests are still passing (which I believe will be).
I'm planning on doing it later today, so expect a release today.


Update changelog, bump gh-pages package and normalize-url

The last yarn audit error (normalize-url) seems to be not fixable without updating the gh-pages package we use to publish docs as it depends on a too old version of the package, so even if we force a newer one, it wouldn't work. I'd advise not fixing it right now and waiting for gh-pages to update itself: https://github.com/tschaub/gh-pages/issues/392
This is a dev dependency, so projects depending on ourl ibrary won't be exposed to gh-pages and its subdependencies


NameError oddity, undefined python variable reference

In 1.0.4 I noticed this odd traceback for an undefined identifier.
I am using python 3.12.3
import asteval

interpreter = asteval.Interpreter()

interpreter.eval('i_dont_exist', raise_errors=True)

Output:
REDACT\venv\Scripts\python.exe REDACT\test.py
Traceback (most recent call last):
  File "REDACT\venv\Lib\site-packages\asteval\asteval.py", line 293, in run
    ret = handler(node)
          ^^^^^^^^^^^^^
  File "REDACT\venv\Lib\site-packages\asteval\asteval.py", line 513, in on_name
    return self._getsym(node)
           ^^^^^^^^^^^^^^^^^^
  File "REDACT\venv\Lib\site-packages\asteval\asteval.py", line 505, in _getsym
    self.raise_exception(node, exc=NameError, msg=msg)
  File "REDACT\venv\Lib\site-packages\asteval\asteval.py", line 242, in raise_exception
    raise exc(self.error_msg)
NameError: name 'i_dont_exist' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "REDACT\venv\Lib\site-packages\asteval\asteval.py", line 293, in run
    ret = handler(node)
          ^^^^^^^^^^^^^
  File "REDACT\venv\Lib\site-packages\asteval\asteval.py", line 356, in on_expr
    return self.run(node.value)  # ('value',)
           ^^^^^^^^^^^^^^^^^^^^
  File "REDACT\venv\Lib\site-packages\asteval\asteval.py", line 299, in run
    self.raise_exception(node, expr=expr)
  File "REDACT\venv\Lib\site-packages\asteval\asteval.py", line 242, in raise_exception
    raise exc(self.error_msg)
NameError: name 'i_dont_exist' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "REDACT\venv\Lib\site-packages\asteval\asteval.py", line 293, in run
    ret = handler(node)
          ^^^^^^^^^^^^^
  File "REDACT\venv\Lib\site-packages\asteval\asteval.py", line 432, in on_module
    out = self.run(tnode)
          ^^^^^^^^^^^^^^^
  File "REDACT\venv\Lib\site-packages\asteval\asteval.py", line 299, in run
    self.raise_exception(node, expr=expr)
  File "REDACT\venv\Lib\site-packages\asteval\asteval.py", line 242, in raise_exception
    raise exc(self.error_msg)
NameError: name 'i_dont_exist' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "REDACT\venv\Lib\site-packages\asteval\asteval.py", line 337, in eval
    return self.run(node, expr=expr, lineno=lineno, with_raise=raise_errors)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "REDACT\venv\Lib\site-packages\asteval\asteval.py", line 299, in run
    self.raise_exception(node, expr=expr)
  File "REDACT\venv\Lib\site-packages\asteval\asteval.py", line 242, in raise_exception
    raise exc(self.error_msg)
NameError: name 'i_dont_exist' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "REDACT\test.py", line 7, in <module>
    interpreter.eval('i_dont_exist', raise_errors=True)
  File "REDACT\venv\Lib\site-packages\asteval\asteval.py", line 343, in eval
    raise self.error[-1].exc(errmsg) from exc
                                          ^^^
NameError: name 'exc' is not defined. Did you mean: 'exec'?

Process finished with exit code 1

Seems there is a reference to an undefined python variable in this case.
Perhaps it needs: except Exception as exc: in the handlers, it seems this error is possible in two places when looking at eval
def eval(self, expr, lineno=0, show_errors=True, raise_errors=False):
    """Evaluate a single statement."""
    self.lineno = lineno
    self.error = []
    self.start_time = time.time()
    if isinstance(expr, str):
        try:
            node = self.parse(expr)
        except Exception:
            errmsg = exc_info()[1]
            if len(self.error) > 0:
                lerr = self.error[-1]
                errmsg = lerr.get_error()[1]
                if raise_errors:
                    raise lerr.exc(errmsg) from exc # HERE exc does not exist
            if show_errors:
                print(errmsg, file=self.err_writer)
            return None
    else:
        node = expr
    try:
        return self.run(node, expr=expr, lineno=lineno, with_raise=raise_errors)
    except:
        errmsg = exc_info()[1]
        if len(self.error) > 0:
            errmsg = self.error[-1].get_error()[1]
        if raise_errors:
            raise self.error[-1].exc(errmsg) from exc # HERE exc does not exist
        if show_errors:
            print(errmsg, file=self.err_writer)
    return None

@Teriks Thanks, and sorry for the trouble.    #129 and #131 were similar issues.
Apparently, having sensible exceptions and reasonable handling of raise_errors is right at the threshold of my ability to do well ;)
I've updated the code and added a test so that this should now work.  I'll choose to be cautiously optimistic but maybe not completely confident this is the end of it ;)

@Teriks this should now be fixed, and in version 1.0.5, so closing.


Oracle Hint support for SELECT statements.

Single and multi line hints, i.e.
SELECT /*+ CHOOSE */ empno, ename, sal, job FROM emp;
SELECT --+ CHOOSE
empno, ename, sal, job FROM emp;

Thx for contributing. I will look into it. Give me some time.


v20.1.9 release notes

Fixes https://github.com/cockroachdb/docs/issues/8856.

This change is

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/e84b3f909267b4cd3e4744395d00a8ff82a19da9/
Edited pages:

releases/v20.1.9.md

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/c550c98526a85e621a3ca33e913cfcea4bc85244/
Edited pages:

releases/v20.1.9.md

@JuanLeon1 Updated dates and added latest commit message. Please review for accuracy.

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/6bb2e4c361a48a360ab3ccc0cef915068edff0a6/
Edited pages:

releases/v20.1.9.md


added .gitignore, github action & github templates

Signed-off-by: André Bauer<EMAIL_ADDRESS>
added gitignore file
added github issue template
added github pr template
added github action for pr ci

lints all bash scripts
uses helm template & kubeval to validate created k8s schemas (https://github.com/instrumenta/kubeval/)
lints chart (https://github.com/helm/chart-testing-action)
installs chart in a kind cluster (https://github.com/helm/kind-action & https://github.com/helm/chart-testing-action)

@monotek I assume you pulled this from an existing setup using github actions? I haven't used it before but it looks thorough, and i'd love to dive in and learn a bit more there

@monotek I assume you pulled this from an existing setup using github actions? I haven't used it before but it looks thorough, and i'd love to dive in and learn a bit more there

yes, mostly copied from https://github.com/kiwigrid/helm-charts

@monotek I assume you pulled this from an existing setup using github actions? I haven't used it before but it looks thorough, and i'd love to dive in and learn a bit more there

yes, mostly copied from https://github.com/kiwigrid/helm-charts

Thanks - I haven't looked through those before, I'll take a look and also at that any-resource chart. Very interesting.

It does!


Input fields don't emit (and thus round-trip) offset value when binding against DateTimeOffset fields

Was working on the ASP.NET Core App-building Workshop and discovered an interesting issue when model binding to properties of type DateTimeOffset, especially when the application is running on a machine with a different system locale (and thus default time zone) than the DateTimeOffset values being edited.
Consider a Tag Helper use like <input asp-for="StartTime" />, where StartTime is defined as public DateTimeOffset StartTime { get; set; } on the model. The rendered HTML for the input field will not include the offset value: <input class="form-control" type="datetime-local" id="StartTime" name="StartTime" value="2017-08-14T09:00:00.000" /> . When this is posted back, the model bound value will now have an offset of the machine's system locale, even if the field wasn't changed, resulting in a different value.
We need to consider what the correct behavior of the helpers should be here, and how it interacts with the HTML5 datetime-local field type. Or perhaps we need specific guidance (and maybe helpers/binders) for handling DateTimeOffset values.
@rynowak @Eilon

@dougbu can you take a look and share thoughts on this?

type="datetime-local" is incomplete for scenarios involving systems that are in potentially-different time zones. Browsers and the W3C have deprecated the complete choice (type="datetime").
Options include:

The W3C School's recommendation is to include a separate field allowing users to specify the timezone of their choice. This solution should probably be about scaffolding and not MVC itself.
MVC could however expand <input asp-for="{some DateTimeOffset expression}"/> into two elements. One would be the requested <input/> (of type datetime-local) and the other a <select> containing well-known timezones. This would be a breaking change and it would be difficult to style the generated elements. For example, should all attributes in the source <input/> be applied to the <select>? Also, how would less-frequently-used timezones be chosen?
Another choice would be to determine the browser's timezone from request headers. Then, model bind using the correct offset and generate RFC3339-compliant strings for that timezone. I'm not sure this information is consistently available…
Finally, could mostly punt the issue and use type="text" with one of the round-tripping formats e.g. 0:yyyy-MM-ddTHH:mm:ss.fffK instead of auto-selecting datetime-local. type=datetime-localwould still be supported when chosen in the .cshtml. One downside here is end users must be cognizant of their timezone as an offset from UTC. Another is correctly-formatted values aren't particularly usable. (That said, many desktop browsers treattype="datetime-local"` as if it were text anyhow.)

Thanks Doug, but given that 'DateTimeOffset' is the generally recommended way to store dates in .NET now, I think we need to think more about a first-class way to support this better. It isn't always about the time-zone the user is in, but just the general proper handling of the data being bound. In this case, you suffer data loss which is terrible. We need to to mitigate that somehow, e.g. render a hidden field with original offset and have the model binder use it in connection with the value in text box when binding. Ideally we need a solution for user selection of the offset too though.

@DamianEdwards your "data loss" is my "incomplete" 😺 (I didn't mention the user's timezone except in :three:)
To clarify, data loss occurs today in two ways: Users can't see what timezone a value is in and model binding can't infer what timezone a user meant. About all that works semi-cleanly is round-tripping when the user does not make a change. I agree a separate field (option :two: perhaps with an added hidden field or tag helper attributes to control the generated field) avoids the data loss in both directions.
Is there another generally-accepted approach I've missed?
Separately, should MVC generate something different when the user explicitly chooses type="datetime-local" versus when that type is defaulted based on the expression?

Data is lost when the original value has an offset that is different to the server's system locale. That should be fixed as it's clearly a bug in our handling of this end-to-end.
First class support for offset selection is a more advanced matter that we should investigate.

Data is lost when the original value has an offset that is different to the server's system locale.

Yes, the chosen RFC3339 format (yyyy-MM-ddTHH:mm:ss.fff) simply truncates the offset. That breaks even the round-tripping case because the implicit assumption is the offset corresponds to the server's current timezone. Good news is this happens less often because .NET parses even values like 2017/10/01T12:35+7:00 into a DateTimeOffset with the current offset e.g. 2017-09-30T22:35:00.000-07:00 where I'm at.
I'm unsure about offering a partial solution e.g. just providing the hidden field only helps with round-tripping data the server provided.

We can talk in person then. It's simply broken for cross-timezone scenarios, and we have no guidance on allowing selection of time-zone on top of that. We need to do something here.

Looks like this is actually a regression in ASP.NET Core 2.0.0. We currently run in RFC 3339-compliant mode and render DataTimeOffset properties using type="datetime-local" by default. It should take both changes to lose the offset and neither behaviour was the default in MVC 5.x.
This appears to also be a regression from ASP.NET Core 1.1.0 behaviour. We switched to be RFC 3339-compliant by default in in 1.0.0-rc2 (see issue #4102, PR #4250 and 6b369ef2). But, the change to use type="datetime-local" didn't happen until 2.0.0-preview1 (see issue #4871, PR #5664 and f95d49c8).
I'll test ASP.NET Core 1.1 to confirm the defaults round-trip the offset later today or tomorrow…

Have confirmed problem does /not/ exist in ASP.NET Core 1.1.0.

Possible approaches:

Stop using type="datetime-local" for DateTimeOffset values i.e. undo part of the breaking change we took in 2.0.0 (#4871 et cetera). This will mean DateTimeOffset values are shown as text fields containing the full value. (Might choose to use type="text" to make that explicit since few if any current browsers support type="datetime".) This is both a breaking change and an unbreak of the 2.0.0 regression.
Add a type="hidden" field containing the Offset value for DateTimeOffset values used in <input/> tag helpers and Html.Editor[For](...). This would also require a DateTimeOffset model binder which combines the two fields. Unfortunately, this may break some with a workaround for #6648 already in place. This approach also fixes only part of the problem: Unless the offset or associated timezone is visible in the form, users are very likely to submit values that are misinterpreted.
Implement 1. and document the heck out of possible issues when using DateTimeOffset with type="datetime-local" in an ASP.NET Core application. Since type="datetime-local" will remain available (as an explicit choice), .cshtml authors can create forms which consistently make the offset obvious to their users.
Implement 4. plus the model binder mentioned in #2. This approach avoids the default data loss on user submission but allows .cshtml authors to easily create forms that allow their users to choose offsets.

If we're talking about taking this in 2.0.1, I recommend doing 1. initially. That's an E2E fix which involves very little code.

I'm probably leaving out another half dozen approaches. Please speak up, especially if you have an idea we could implement in a patch.

I agree on fixing this via option 1 in a servicing release. We may need to offer a quirk switch to enable opting in to the 2.0 RTM behavior given the breaking nature of the fix.
Beyond that I don't care to think too much about right now other than I think we should do a much better job of supporting DateTimeOffset via features or guidance.

You should audit how well ASP.NET Core handles DateTimeKind at the same time. Converting between ISO dates and DateTime(local,utc,unspecified) + DateTimeOffset is surprisingly complex.

Allow me to offer some guidance.  First, to clear up a few points:

<input type="datetime-local" /> is specifically for date and time without an offset.  RFC 3339 specifically requires an offset.  Therefore, they are incompatible.
RFC 3339 is a profile of the ISO 8601 standard.  There are other profiles in the standard, including one that is date and time without an offset.  Therefore, if we truncate the offset, we are not RFC 3339 compliant, but we are still ISO 8601 compliant.  However, that profile should be used with a DateTime with .Kind == DateTimeKind.Unspecified only.  Using it for a DateTimeOffset, or a DateTime with Local or Utc kind would be in error.
Time zone information is not present in HTTP Request headers, so the idea of model-binding to that is out.  Additionally, I'll echo @DamianEdwards in that DateTimeOffset values are regularly passed with offsets other than the browser's or the server's.
Locale and time zone are orthogonal concepts. I think instead of locale, you meant the server's local time zone setting.  However, this should be considered irrelevant, as it's a system-wide setting.  One can set the default locale of a specific application, but one cannot set the local time zone of an application without potentially affecting all other programs on the server.

Regarding presenting the user with a drop-down lists of time zones, I'll point out that the example @dougbu linked to on Mozilla's site is flawed.  Time zone names can only be mapped to identifiers such as those used with TimeZoneInfo.Id (either Windows or IANA representations depending on runtime platform).  Names should not be assigned to numeric offsets, as that would be a gross misrepresentation.  For more on this, see "Time Zone != Offset", from the timezone tag wiki on StackOverflow
The ideal mapping for DateTimeOffset would have been <input type="datetime" />, which no longer exists in the HTML spec.  Using <input type="text" /> would work, but it requires the developer to bring their own date/time picker controls, manage formatting, validation, etc.
My recommendation is to use <input type="datetime-local" /> and a <select /> drop-down list of offsets.
Offsets are interesting.  To be future-proof and spec-compliant with RFC 3339 and ISO 8601, they would have to support any valid ±HH:mm from -23:59 to +23:59 and every minute in between.  However a reduced list is indeed possible.  We only support offsets from -14:00 to +14:00 on DateTimeOffset anyway, so hopefully Kiritimati never implements daylight saving time.  ;)
I've written some code in this dotnetfiddle that shows how to build a list of offsets, both in "simplified" form that shows just the current offsets used throughout the world (covering both standard and daylight time), and how to build an expanded form showing all representable offsets that a DateTimeOffset value might use.  I recommend making that an option the user can set via attribute, with simplified being the default.
Of course, one might want to generate the full list via JavaScript to save on bandwidth - but that's not currently possible with the simplified form without pulling in JS libraries.

By the way, a similar drop-down list is already in use as a common control in the Azure Portal.  For example, try to create a scheduled web job, and you'll notice the schedule asks for a Date, Time, and UTC Offset.  The offsets in the list are created from code similar to what I gave in my fiddle above.

The points @JamesNK and @mj1856 raised are important especially for our long-term plans and the guidance we eventually provide.
With respect to #6648 aka our short-term fixes, our plan was basically to stop auto-selecting type="datetime-local" (and the associated format) for DateTimeOffset values. As @mj1856 makes clear, we should at least include DateTime values with Kind==DateTimeKind.Utc in that change. This will expand the breaking change we're discussing i.e. MVC will generate different HTML and lose use of browsers' datetime wizards in the default case.
Going beyond the above, I'd appreciate input on:

Is the distinction between Kind==DateTimeKind.Local and Kind==DateTimeKind.Unspecified important enough to further expand the above breaking change? DateTime values originally with these Kinds that lose that Kind after a round trip still describe the original point in time. And, choosing type="datetime-local" only for Kind==DateTimeKind.Unspecified values affects loads more people. (DateTimeKind.Local seems very common.)
Can we help people who have explicitly chosen type="datetime-local" in the short term? Users with e.g. <input asp-for="ADateTimeOffset" type="datetime-local" /> or Html.EditorFor(m => m.ADateTimeOffset, templateName: "datetime-local") in their .cshtml files may also be at corruption risk.
Similarly, can we help people who have explicitly chosen type="time" in the short term? That type choice also by default uses a format string which leaves out Kind and Offset information. It's good this must be explicitly requested. But, …
Do any browsers still support (i.e. use a wizard for) type="datetime" but truncate the offset MVC provides when submitting form data? I'm probably borrowing trouble here but would like to know.

A couple of quibbles:

MVC makes no claim of RFC 3339 compliance or at least shouldn't claim such compliance. Instead the software (since at least ASP.NET MVC 5.2.3) has a mode named after the RFC but only uses the full format (aka the date-time production) for type="datetime" fields. Other formats selected in this mode correspond to the full-date and partial-time productions as well as the format used for type="datetime-local": full-date "T" partial-time. MVC will only auto-select the type="datetime-local" format; the rest must be explicitly requested. Fortunately, MVC 5.2.3 and ASP.NET Core versions prior to 2.0.0 auto-selected type="datetime" in the same cases.
Unless in the (misnamed) RFC 3339 mode, MVC doesn't auto-select format strings at all -- just the generated type attribute. Unfortunately, that mode has been the default since ASP.NET Core 1.0.0.
MVC does no conversions between DateTime and DateTimeOffset values. The framework does however convert both to and from strings.

This is what Json.NET does with DateTimeKind (and DataContractSerializer which I largely followed).
2017-08-30T20:45:13+00:00 = Local
2017-08-30T20:45:13Z = UTC
2017-08-30T20:45:13 = Unspecified
And vice-versa when serializing. Plus DateTimeOffset always includes the offset when serializing.
DateTimeOffset = 2017-08-30T20:45:13+00:00

Thanks @JamesNK - Yes, that's the expected behavior.  Though worth noting that if an offset is present and thus a DateTime is assigned DateTimeKind.Local, the date and time value must be adjusted accordingly.  In the given example, if my local time zone is Pacific, then 2017-08-30T20:45:13+00:00 becomes 2017-08-31T03:45:13-07:00, which becomes 2017-08-31T03:45:13 with DateTimeKind.Local.  I think this is already happening in Json.NET.  It's slightly screwy - but thus is the nature of DateTimeKind.
@dougbu - further response forthcoming.  Thanks.

It turns out f95d49c8 was stronger than I remembered and a few potential workarounds e.g. Html.EditorFor(m => m.StartTime, templateName: "DateTime") won't help. I'll list what /will/ work prior to a #6648 fix after some testing…

I did some testing.  Presently with a DateTime value in the model, we create <input type="datetime-local" />.  Regardless of Kind of the value in the model, we treat it as if it were DateTimeKind.Unspecified, such that a value compatible datetime-local is used.  No adjustment of value is made.  In other words, just 2017-09-01T00:00:00.000, even if the kind was Local or Utc.  Basically, Kind doesn't round-trip.
(Also, the docs need updating to show datetime-local instead of datetime.)
If we wanted to be able to round-trip DateTimeKind, similar to what Json.NET is doing, we'd have to persist the kind somewhere, such as an associated hidden input field.  That said, I don't think DateTimeKind round-tripping is that big of a deal.  Users are somewhat used to this, going back to the early days of ASP.NET, for both WebForms and MVC.  If you ask a user for date and time input, the general expectation is that the value you receive is DateTimeKind.Unspecified.  If you meant for that to be interpreted as UTC time, then you can use DateTime.SpecifyKind to set it explicitly.  Similarly, if you meant it to be interpreted as time in a specific time zone, then TimeZoneInfo.ConvertTime would be employed.  Let the user continue to do that for DateTime.
For DateTimeOffset, there's indeed work to do.  However, it would only matter if a DateTimeOffset was in the UI model in the first place.  There are indeed scenarios for picking a date, time, and offset in user input, but they are much less common than picking a date or a date and time.  I still think the best approach for this is <input type="datetime-local"/><select /> with the select list being populated by at least the simplified offsets (per my earlier example).  Of course, I'm making an assumption that the concerns @dougbu raised about styling two controls could be resolved.
All of the above and current implementations leave <input type="date" /> and <input type="time" />  unaddressed, and there are indeed many use cases for both date-only (ex: date-of-birth) and time-only (ex: business hours) entry in HTML forms.  (Otherwise they wouldn't be in HTML5.)  To address these, could we please promote the System.Time package I contributed two years ago out of corefxlab?  That code introduces a System.Date type that would cleanly map to <input type="date" />, and a System.TimeOfDay type that would cleanly map to <input type="time" />.
To answer some questions posed:

Is the distinction between Kind==DateTimeKind.Local and Kind==DateTimeKind.Unspecified important enough to further expand the above breaking change?

It is quite a distinction, in that Local only represents the machine where the code it's running.  This should be discouraged in web applications, as the server's time zone is generally irrelevant, and is a global setting for all apps on the machine.  Really, any DateTimeKind.Local usage should be avoided in ASP.NET.  I am working on addressing guidance for this in aspnet/Docs#3992.

DateTime values originally with these Kinds that lose that Kind after a round trip still describe the original point in time.

No, they don't.  They have the same date and time values, but when Kind is Unspecified, there is no point in time being represented.  It's a civil date (as on a calendar), and a time of day (as on a wall-clock).  The context of how that relates to a point on the universal timeline is lost.  However, like I said, that's probably ok here - as that's how it's always been and there are workarounds.

And, choosing type="datetime-local" only for Kind==DateTimeKind.Unspecified values affects loads more people. (DateTimeKind.Local seems very common.)

I think Local is only common due to developers reaching for DateTime.Now.  As mentioned above, not a good idea in a web app.  Unspecified is the default when loading DateTime values from a SQL Server (with or without EF), and is the default when just using the constructor new DateTime(y, m, d, ...). So it's just as common, IMHO.
I think the confusion around the word "local" here is part of the problem.  HTML5 is borrowing terminology from ISO8601 (as do Noda Time, Java 8, and others).  In that context, "local" just means "local to someone somewhere", where in .NET local means "on the local machine where the code is executing".  (BTW, there's a bike-shed for this in tc39/proposal-temporal#33 if you're interested).
Really, DatetimeKind.Unspecified is the only correct alignment for <input type="datetime-local" />.

Can we help people who have explicitly chosen type="datetime-local" in the short term?

We can warn them in documentation, but I cannot think of any technical way to resolve this other than that already described.  Round-tripping the offset in a hidden field doesn't seem like a good option, as it doesn't allow the user to adjust it. (ex: Pacific is now -07:00 (PDT), but maybe -08:00 (PST) for a different date).

Similarly, can we help people who have explicitly chosen type="time" in the short term?

YES - by promoting the System.Time package out of corefxlab as mentioned above, and suggesting users adopt it for date-only and time-only values.

Do any browsers still support (i.e. use a wizard for) type="datetime" but truncate the offset MVC provides when submitting form data?

No, according to this chart, and still limited support for ``type="datetime-local"`. I tested myself on Chrome, Edge, FF, and IE (all latest on Win10) and found the same results.

MVC does no conversions between DateTime and DateTimeOffset values.

Sure, but .NET does have a one-way implicit cast from DateTime to DateTimeOffset.  It uses the Kind to set the offset.  It gets folks into trouble every so often (from my own experiences and on StackOverflow).

Thanks very much @mj1856. <input type="datetime-local" .../><select ...>...</select> is certainly the right way forward in our guidance if not our helpers.
However, I'd like to focus this issue on what we can do about losing Offsets and possibly Kinds in our next 2.0 patch. Updating the helpers would be too large a breaking change for a patch e.g. the change would ruin HTML layout. It would also be an unusually large amount of new code. Once we decide on guidance and product changes or some mix for the future, I'll open the appropriate MVC 2.x and Docs issues.
@dougbu:

Is the distinction between Kind==DateTimeKind.Local and Kind==DateTimeKind.Unspecified important enough to further expand the above breaking change?

@mj1856:

I don't think DateTimeKind round-tripping is that big of a deal

...

It is quite a distinction,

...

DatetimeKind.Unspecified is the only correct alignment for <input type="datetime-local" />

What is the bottom line here? Should MVC's next patch change how <input asp-for="ADateTime"/> and Html.EditorFor(m => m.ADateTime) work or not? (Changing things for ADateTimeOffset is a given.)

could we please promote the System.Time package I contributed two years ago out of corefxlab?

Seems like a good idea. But, what does "promote" mean in this context?

For DateTime

The MVC behavior isn't ideal because DateTimeKind is not ideal.
Since there are workarounds (using DateTime.SpecifyKind after binding), I recommend leaving this as currently implemented.  All DateTime types should produce an <input type="datetime-local" />.
AFAIK, Kind has never fully round tripped in an MVC control, so I don't see this as anything urgent.
The documentation should be updated to reflect datetime-local instead of datetime, and perhaps mention the workaround in a note block.  I can send a PR for both if you like.

For DateTimeOffset

We agree on the two fields for the long-term solution, with the key bit being the select is a list of offsets, not a list of time zones.
For the short-term I recommend switching this to <input type="text" />.  It is a better option than <input type="datetime-local" /> since it wont lose offset.  It doesn't present a UI, but neither did the previous <input type="datetime" /> since it never fully came to be.
It's worth noting that DateTimeOffset may not be the best option for the use case @DamianEdwards identified - at least not for the UI model.  Typically, having DateTime fields and a separate time zone selection works best.  The application logic can then compute the DateTimeOffset values, rather than asking the user to pick the offset.  This is most likely what end users will do, and aligns with other guidance I give with regard to scheduling.

For Date and TimeOfDay

I'm not sure what the process is for promotion from corefxlab, but I would expect it to go through some sort of scrutiny and ultimately land in corefx.
Currently, it is only available in the corefxlab myget feed.  This would make it available as a public Nuget package.
At that point, ASP.NET could map Date to <input type="date" /> and TimeOfDay to <input type="time" />.
This seems like a good fit for ASP.NET Core 2.1 on the roadmap.

Going back to workarounds:

If the UI can change significantly, use <input type="datetime-local" .../><select ...>...</select> or a similar HTML helper combination, populating the drop-down as @mj1856 described above. This is the only option that maintains pickers for DateTimeOffset values in modern browsers.
If the UI cannot change that much and the .cshtml files use Html.Editor(...) or Html.EditorFor(...) with DateTimeOffset expressions, add an editor template for DateTimeOffset e.g.

  @model DateTimeOffset
  <input asp-for="@Model" type="datetime" class="form-control" />

If the .cshtml files use <input/> tag helpers with DateTimeOffset expressions, change all of them to include type="datetime". Browsers will ignore the type (treating it as type="text") but MVC will choose a format string that round-trips the Offset.
To more explicitly handle the 3. case, change the relevant tag helpers to include type="text" asp-format="{0:o}". A custom format string including "K" or "zzz" also works.
If it's easier to handle the 2. and 3. cases in the model, add annotations to DateTimeOffset properties e.g.

  [DisplayFormat(ApplyFormatInEditMode = true, DataFormatString = "{0:o}")]
  [UIHint("text")]

To handle the 2. and 3. cases centrally, add an IDisplayMetadataProvider implementation in the Startup class e.g.

  services.AddMvc(options => options.ModelMetadataDetailsProviders.Add(new DatetimeMetadataProvider()));
...

  private class DatetimeMetadataProvider : IDisplayMetadataProvider
  {
      public void CreateDisplayMetadata(DisplayMetadataProviderContext context)
      {
          if (context.Key.ModelType == typeof(DateTimeOffset) ||
              context.Key.ModelType == typeof(DateTimeOffset?))
          {
              // If model type hasn't been annotated as we'd like...
              var metadata = context.DisplayMetadata;
              if (string.IsNullOrEmpty(metadata.EditFormatString) &&
                  string.IsNullOrEmpty(metadata.DataTypeName) &&
                  string.IsNullOrEmpty(metadata.TemplateHint))
              {
                  // Fix things up. TemplateHint = "DateTime" does not help. Changing EditFormatString is not
                  // required when using DateTimeOffset. Then again, the default DateTimeOffset format in most
                  // locales loses sub-Second information.
                  metadata.EditFormatString = "{0:o}";
                  metadata.TemplateHint = "text";
              }
          }
      }
  }

The above choices also work for DateTime values if your application needs to round-trip the Kind.

@dougbu - I agree with most of that.  Note that K format specifier is for DateTime and zzz specifier is for DateTimeOffset.  Don't mix them, since zzz on a DateTime doesn't properly reflect the Kind but rather the OS time zone.
I do think it's super important that datetime-local be preserved for use cases of just picking a date and time with a DateTime, and the expectation that Kind == DateTimeKind.Unspecified is reasonable.  Round-tripping the kind in this particular case is not essential.  However, if it's possible to add a parameter for the tag helper that would allow for specifying Kind to set, that would be useful.

I really appreciate your suggestions @mj1856!

The documentation should be updated to reflect datetime-local instead of datetime, and perhaps mention the workaround in a note block. I can send a PR for both if you like.

This seems like cruft in the documentation and I agree we should improve it. Suggest we also mention:

MVC 5.x (yeah, a historical reference 😈) and ASP.NET Core 1.x do use type="datetime" for DateTime and DateTimeOffset values. This amounts to type="text" except for the format string MVC auto-selects.
The ASP.NET Core 2.0.x patch may use type="datetime" again if that temporary fix is simpler.

A PR would certainly help. @scottaddie? @Rick-Anderson?

I do think it's super important that datetime-local be preserved

Agreed. I'm not going to make any changes undoing a developer's explicit selection of this type. This issue is limited to MVC's auto-selection based on the datatypes.

Right, I mean that datetime-local is currently the auto-selected choice for this type, and I think it should remain so.

FYI I edited my earlier comment because using type="text" is actually quite simple.

The ASP.NET Core 2.0.x patch may use type="datetime" again if that temporary fix is simpler.

7e4a8fe47

@mj1856 Please let me know if you plan to submit a docs PR for this; otherwise, I'll add it to my list of things to do.

@scottaddie - Yep, will do shortly.  Thanks.


Should we migrate to newer NetTS ASIO API?

just a general question, not a bug report:
I started using Beast about a year ago with the legacy ASIO APIs (io_service, io_service::strand, boost::bind, boost::asio::placeholders, etc) before the new NetTS APIs were released. In Dec, the first official Beast was released in Boost and it also coincided with the first release of NetTS-style ASIO.
I'm wondering if it's recommended to update my code base to use the newer NetTS-style ASIO APIs. How long are the legacy ASIO API going to be supported by ASIO and Beast? (I'm not familiar with the roadmap for NetTS and the state of activities there... Are there still likely to be changes in NetTS APIs at this point?)

I'd say that you should upgrade to the new API at earliest convenience to get some of the nice features of the new API (e.g. support for move-only CompletionHandlers). While the old API is deprecated, I don't expect it to disappear any time soon, because ASIO has had fairly good long-term stability of its API in the past.

If history is any indication, the legacy Asio APIs will likely be supported for a very long time. There is little upside to removing them, and the downside is significant (breaking everyone's code that uses the legacy interfaces). I would expect that the Asio author will try to maintain them for as long as possible.

ok, thanks for the feedback!


i18n example broken on server load

How to reproduce:
download https://github.com/nuxt/nuxt.js/tree/dev/examples/i18n
yarn
and then any:
yarn dev

yarn generate
hs -p 3000 dist/

yarn build
yarn start

and load http://localhost:3000/fr/about/
In all of the cases, the server will send the French html,
but upon hydration it will silently (nothing in console) be replaced with English.
Furthermore, the active base state in the Vue devtool will be
locales:Array[2]
0:"en"
1:"fr"
locale:"fr"

while $vm0.$i18n.locale is 'en';

tl;dr:
after server load and hydration at non-default lang, for example /fr/about/
$vm0.$i18n.locale is not equal to $vm0.$store.state.localewhich is fr, but to the default en instead.

Wildly enough, it does not happen at https://i18n.nuxtjs.org/fr/about

Facing this issue after updated to rc8 today.

@wushan what version did you update from? I will see if downgrading to that fixes my issue or the example.

@qm3ster I am facing the same issue, but I noticed that if you commit to the store the lang parameter in the plugin code too it starts working. Don't know if it could be a valid solution though...
In plugin/i18n.js
import Vue from 'vue'
import VueI18n from 'vue-i18n'

Vue.use(VueI18n)

export default ({ app, store, route }) => {
  const locale = route.params.lang || 'en'
  store.commit('SET_LANG', locale)
  // Set i18n instance on app
  // This way we can use it in middleware and pages asyncData/fetch
  app.i18n = new VueI18n({
    locale: store.state.locale,
    fallbackLocale: 'en',
    messages: {
      'en': require('~/locales/en.json'),
      'fr': require('~/locales/fr.json')
    }
  })
}

In middlewares/i18n.js
export default function ({ isHMR, app, store, route, params, error, redirect }) {
  // If middleware is called from hot module replacement, ignore it
  if (isHMR) return
  // Get locale from params
  const locale = params.lang || 'en'

  if (store.state.locales.indexOf(locale) === -1) {
    return error({ message: 'This page could not be found.', statusCode: 404 })
  }
  // Set locale
  store.commit('SET_LANG', locale)
  app.i18n.locale = store.state.locale

  // If route is /en/... -> redirect to /...
  if (locale === 'en' && route.fullPath.indexOf('/en') === 0) {
    return redirect(route.fullPath.replace(/^\/en/, '/'))
  }
}

I think this related with changes that comes with rc7. https://github.com/nuxt/nuxt.js/commit/8dca35821621aa28e977eda189049d594464662e

In rc8, I blindly swapped
  <% plugins.filter(p => p.ssr).forEach(plugin => { %>
  if (typeof <%= plugin.name %> === 'function') await <%= plugin.name %>(ctx, inject)<% }) %>
  <% if (plugins.filter(p => !p.ssr).length) { %>
  if (process.browser) { <% plugins.filter(p => !p.ssr).forEach(plugin => { %>
    if (typeof <%= plugin.name %> === 'function') await <%= plugin.name %>(ctx, inject)<% }) %>
  }<% } %>

  <% if (store) { %>
  if (process.browser) {
    // Replace store state before calling plugins
    if (window.__NUXT__ && window.__NUXT__.state) {
      store.replaceState(window.__NUXT__.state)
    }
  }
  <% } %>

to
  <% if (store) { %>
  if (process.browser) {
    // Replace store state before calling plugins
    if (window.__NUXT__ && window.__NUXT__.state) {
      store.replaceState(window.__NUXT__.state)
    }
  }
  <% } %>

  <% plugins.filter(p => p.ssr).forEach(plugin => { %>
  if (typeof <%= plugin.name %> === 'function') await <%= plugin.name %>(ctx, inject)<% }) %>
  <% if (plugins.filter(p => !p.ssr).length) { %>
  if (process.browser) { <% plugins.filter(p => !p.ssr).forEach(plugin => { %>
    if (typeof <%= plugin.name %> === 'function') await <%= plugin.name %>(ctx, inject)<% }) %>
  }<% } %>

And it fixed the issue. @Vampirkod was right.
@Atinux, can you comment on what the downside would be? Why was 8dca358 implemented?

Hi,
It's because we want to add the possibility of plugnis to register dynamic module and replaceState before make it fail.
Actually with rc9, I am introducing serverStoreState which is equal to window.__NUXT__.state.

You mean when a client-only plugin wants to add a store module?

I am sorry, does middleware not run on the client during server load?
As a temporary fix I added
if (app.i18n.locale !== store.state.locale) {
  app.i18n.locale = store.state.locale
}

after
 if (store.state.locale !== locale) {
  store.commit('SET_LANG', locale)
  app.i18n.locale = store.state.locale
 }

But it only fixes after the first clientside navigation?

@qm3ster  this would helps
export default (ctx) => {
  const { isClient, app, store } = ctx;
  // this would be by default in rc9, so in future you not need this 3 lines
  if (isClient) {
    ctx.serverStoreState = window.__NUXT__.state;
  }

  app.i18n = new VueI18n({
    locale: isClient ? ctx.serverStoreState.locale : store.state.locale,
    fallbackLocale: 'en',
    messages: messages: {
      'en': require('~/locales/en.json'),
      'fr': require('~/locales/fr.json')
    },
  });
};

I get what you mean, but the big problem is that when state is replaced, it seems to break reactivity in my case.
It would be far superior if I could just initialize VueI18n to point at the store.
// middleware/i18n.js
/*...*/
if (store.state.i18n.locale !== locale) {
  store.commit('i18n/SET_LANG', locale)
  app.i18n.locale = store.state.i18n.locale // so that this line is removed
}

(The state.i18n is because I moved the whole i18n configuration object into a store module so that I can later manage loading locales. My plugin is now just the following: )
// plugins/i18n.js
import Vue from 'vue'
import VueI18n from 'vue-i18n'

Vue.use(VueI18n)

export default({app, store}) => {
  app.i18n = new VueI18n(store.state.i18n)
}

It should be fixed with rc9, I moved back store hydration before plugins execution


Include coordinates in input events.

I want to know exactly where I clicked on an object.

This is specific to button input events correct?  Title doesn't say that but description implies it.  Just want to be sure. @eanders-MS

Yes, button input events.


Dimmer 'Not Supported' in iOS 10 Home app

Added a dimmer switch as the 'Kitchen Lights' to the network and it works fine at the switch and through the zway app but iOS 10 doesn't like it. Reports the dimmer as 'Not Supported' with no options. Another switch and plug both work fine with it.
From http://raspberrypi.local:8083/ZAutomation/api/v1/devices
{"data":{"structureChanged":true,"updateTime":1483390183,"devices":[{"creationTime":1482625027,"creatorId":5,"deviceType":"text","h":-1261400328,"hasHistory":false,"id":"InfoWidget_5_Int","location":0,"metrics":{"title":"Dear Expert User","text":"If you still want to use ExpertUI please go, after you are successfully logged in, to  Menu > Devices > Manage with ExpertUI   or call  http://MYRASP:8083/expert  in your browser.   It apparently sees the dimmer device but then does not publish any lightbulb service to HomeKit.
Can you run homebridge with DEBUG enabled for ZWayServer, like so:
DEBUG=ZWayServer homebridge -I

for instance, or whatever other switches you are already passing to homebridge. You should see a bit more information about the decision process of mapping Z-Wave to HomeKit devices, and paste those lines here.

Looks like that warning at the very end is the issue.
ZWayServer Fetching Z-Way devices... +0ms
[Wed Jan 04 2017 04:08:22 GMT+0000 (UTC)] Loading 1 accessories...
[Wed Jan 04 2017 04:08:22 GMT+0000 (UTC)] [Front Garage Door] Initializing LiftMaster accessory...
ZWayServer Authenticating... +304ms
ZWayServer Authenticated. Resubmitting original request... +68ms
ZWayServer Got typeKey text for vdev InfoWidget_5_Int +42ms
ZWayServer { deviceType: 'text', probeTitle: undefined, probeType: '' } +1ms
ZWayServer Got typeKey battery.Battery for vdev BatteryPolling_7 +12ms
ZWayServer { deviceType: 'battery', probeTitle: 'Battery', probeType: '' } +1ms
ZWayServer Got typeKey switchBinary for vdev ZWayVDev_zway_3-0-37 +2ms
ZWayServer { deviceType: 'switchBinary',
ZWayServer   probeTitle: undefined,
ZWayServer   probeType: '' } +0ms
ZWayServer Got typeKey switchBinary for vdev ZWayVDev_zway_4-0-37 +1ms
ZWayServer { deviceType: 'switchBinary',
ZWayServer   probeTitle: undefined,
ZWayServer   probeType: '' } +0ms
ZWayServer Got typeKey switchMultilevel.multilevel for vdev ZWayVDev_zway_5-0-38 +2ms
ZWayServer { deviceType: 'switchMultilevel',
ZWayServer   probeTitle: undefined,
ZWayServer   probeType: 'multilevel' } +0ms
ZWayServer Got grouped device InfoWidget_5_Int consiting of devices: +2ms
ZWayServer InfoWidget_5_Int - text +0ms
ZWayServer WARN: Didn't find suitable device class! +1ms
ZWayServer Got grouped device BatteryPolling_7 consiting of devices: +0ms
ZWayServer BatteryPolling_7 - battery.Battery +0ms
ZWayServer WARN: Didn't find suitable device class! +0ms
ZWayServer Got grouped device ZWayVDev_3-0 consiting of devices: +0ms
ZWayServer ZWayVDev_zway_3-0-37 - switchBinary +0ms
ZWayServer Got grouped device ZWayVDev_4-0 consiting of devices: +1ms
ZWayServer ZWayVDev_zway_4-0-37 - switchBinary +0ms
ZWayServer Got grouped device ZWayVDev_5-0 consiting of devices: +1ms
ZWayServer ZWayVDev_zway_5-0-38 - switchMultilevel +0ms
[Wed Jan 04 2017 04:08:23 GMT+0000 (UTC)] Initializing platform accessory 'Christmas Tree'...
ZWayServer Got typeKey switchBinary for vdev ZWayVDev_zway_3-0-37 +6ms
ZWayServer { deviceType: 'switchBinary',
ZWayServer   probeTitle: undefined,
ZWayServer   probeType: '' } +0ms
ZWayServer Got typeKey switchBinary for vdev ZWayVDev_zway_3-0-37 +26ms
ZWayServer { deviceType: 'switchBinary',
ZWayServer   probeTitle: undefined,
ZWayServer   probeType: '' } +0ms
ZWayServer Loaded services for Christmas Tree +3ms
[Wed Jan 04 2017 04:08:23 GMT+0000 (UTC)] Initializing platform accessory 'Patio Light'...
ZWayServer Got typeKey switchBinary for vdev ZWayVDev_zway_4-0-37 +8ms
ZWayServer { deviceType: 'switchBinary',
ZWayServer   probeTitle: undefined,
ZWayServer   probeType: '' } +0ms
ZWayServer Got typeKey switchBinary for vdev ZWayVDev_zway_4-0-37 +10ms
ZWayServer { deviceType: 'switchBinary',
ZWayServer   probeTitle: undefined,
ZWayServer   probeType: '' } +0ms
ZWayServer Loaded services for Patio Light +1ms
[Wed Jan 04 2017 04:08:23 GMT+0000 (UTC)] Initializing platform accessory 'Kitchen Lights'...
ZWayServer Got typeKey switchMultilevel.multilevel for vdev ZWayVDev_zway_5-0-38 +5ms
ZWayServer { deviceType: 'switchMultilevel',
ZWayServer   probeTitle: undefined,
ZWayServer   probeType: 'multilevel' } +0ms
ZWayServer WARN: Only the InformationService was successfully configured for ZWayVDev_zway_5-0-38! No device services available! +1ms

Can you confirm what version you're on?
npm list -g | grep homebridge-zway

I think you're still on 0.4.0 or an earlier 0.5 alpha... If so you should probably try npm install -g<EMAIL_ADDRESS>. You should be able to roll back to the other version if for some reason you have problems, just make a note of what version you're on.

That fixed it. I was at 0.4.0. The repository still has it as the current version. Placed the new code in and its working like a charm. Now I just need to finish up my Pentair plugin. Thanks!


feat: global style groups

Allow defining style groups with a set of style rules that can be applied to multiple views.
This is the 3rd PR of a series aiming to replace #1058

🚀 🚀


Add support for connection to Azure OpenAI

I would like to connect my LangChain app to Azure OpenAI, is it possible?

@dudu-upstream yes, should be easy to add. Will keep you updated.

Thanks! I will try to do it myself if it shouldn't be that hard

<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-ai-openai</artifactId>
    <version>1.0.0-beta.2</version>
</dependency>

I have seen ms release azure openai java client beta, maybe we can try.

@stormrise AFAIK Azure has the same API as OpenAI, so it would be nice to re-use existing OpenAI client that we use instead of bringing in a new dependency.

@dudu-upstream did you manage to add it yourself? Do you still need this? Thanks

@dudu-upstream did you manage to add it yourself? Do you still need this? Thanks

we need it, could you pls add it ?

@dudu-upstream @stormrise @kaltindas we've added integration with Azure OpenAI in 0.21.0. Unfortunately we don't have access to it, so we've developed it blindly by docs without ability to test. Please check and provide your feedback, thank you!

@dudu-upstream @stormrise @kaltindas we've added integration with Azure OpenAI in 0.21.0 (see AzureOpenAi*Model classes). Unfortunately we don't have access to it, so we've developed it blindly by docs without ability to test. Please check and provide your feedback, thank you!

Unfortunately there is an Issue but it should be easy to fix.
It should be also possible to pass modelId/deploymentId ... https://learn.microsoft.com/en-us/azure/ai-services/openai/reference
Otherwise we get "WARN: Exception was thrown on attempt 1 of 3: dev.ai4j.openai4j.OpenAiHttpException: {"error":{"code":"404","message": "Resource not found"}}" Failure ...
Because in Azure you can have multiple deployments ...

Hi, unfortunately there is an Issue ...
EmbeddingModel embeddingModel = AzureOpenAiEmbeddingModel.builder()                     .apiKey("azure_key")                     .baseUrl("https://my-resource.openai.azure.com/")                     .build();
Here it should be possible to pass the model-id/deployment-id ...
Otherwise we get {"error":{"code":"404","message": "Resource not found"}} wenn we call ' ingestor.ingest(document);'
            EmbeddingStoreIngestor ingestor = EmbeddingStoreIngestor.builder()                     .splitter(new ParagraphSplitter())                     .embeddingModel(embeddingModel)                     .embeddingStore(embeddingStore)                     .build();             ingestor.ingest(document);

Hi @kaltindas did you try to define baseUrl as "https://{your-resource-name}.openai.azure.com/openai/deployments/{deployment-id}"? Also, it seems you need to specify apiVersion. If it does not work, please provide logs. Thanks!

You're right, after specifying the api-version and using the modelName in the basePath, the code worked. The following code is functioning:
EmbeddingModel embeddingModel = AzureOpenAiEmbeddingModel.builder()     .apiKey("key")     .apiVersion("2023-05-15")     .baseUrl("https://my-resource.openai.azure.com/openai/deployments/text-embedding-ada-002")     .build();
Additionally, if the array we're trying to embed with the embeddingModel.embedAll() method exceeds 16, it throws an "InvalidRequestError: Too many inputs. The max number of inputs is 16." error. I've managed to handle this by  using a for loop with 16 iterations steps :) . You can add this information to the documentation if you want.
https://learn.microsoft.com/en-us/azure/ai-services/openai/faq#i-am-trying-to-use-embeddings-and-received-the-error--invalidrequesterror--too-many-inputs--the-max-number-of-inputs-is-1---how-do-i-fix-this-

@kaltindas thanks, goog to know. I will add this iteration logic inside the lib so that users don't need to do it manually.

@kaltindas may I ask you to test other Azure classes? Much appreciated!
AzureOpenAiChatModel model = AzureOpenAiChatModel.builder()
                .apiKey("key")
                .apiVersion("2023-05-15")
                .baseUrl("https://my-resource.openai.azure.com/openai/deployments/gpt-3.5-turbo")
                .build();
        AiMessage answer = model.sendUserMessage("hello");
        System.out.println(answer);

AzureOpenAiLanguageModel model = AzureOpenAiLanguageModel.builder()
                .apiKey("key")
                .apiVersion("2023-05-15")
                .baseUrl("https://my-resource.openai.azure.com/openai/deployments/text-davinci-003")
                .build();
        String answer = model.process("hello");
        System.out.println(answer);

AzureOpenAiStreamingChatModel model = AzureOpenAiStreamingChatModel.builder()
                .apiKey("key")
                .apiVersion("2023-05-15")
                .baseUrl("https://my-resource.openai.azure.com/openai/deployments/gpt-3.5-turbo")
                .build();
        model.sendUserMessage("hello", new StreamingResponseHandler() {

            @Override
            public void onNext(String token) {
                System.out.print(token);
            }

            @Override
            public void onComplete() {
                System.out.println();
                System.out.println("completed");
            }

            @Override
            public void onError(Throwable error) {
                error.printStackTrace();
            }
        });

AzureOpenAiStreamingLanguageModel model = AzureOpenAiStreamingLanguageModel.builder()
                .apiKey("key")
                .apiVersion("2023-05-15")
                .baseUrl("https://my-resource.openai.azure.com/openai/deployments/text-davinci-003")
                .build();
        model.process("hello", new StreamingResponseHandler() {

            @Override
            public void onNext(String token) {
                System.out.print(token);
            }

            @Override
            public void onComplete() {
                System.out.println();
                System.out.println("completed");
            }

            @Override
            public void onError(Throwable error) {
                error.printStackTrace();
            }
        });

Thank you!

AzureOpenAiStreamingLanguageModel model = AzureOpenAiStreamingLanguageModel.builder()
.apiKey("key")
.apiVersion("2023-05-15")
.baseUrl("https://my-resource.openai.azure.com/openai/deployments/text-davinci-003")
.build();
model.process("hello", new StreamingResponseHandler() {
        @Override
        public void onNext(String token) {
            System.out.print(token);
        }

        @Override
        public void onComplete() {
            System.out.println();
            System.out.println("completed");
        }

        @Override
        public void onError(Throwable error) {
            error.printStackTrace();
        }
    });

I tried all 4 code snippets you provided, and they all work flawlessly. The responses are coming through! Everything is in order.

You've done a great job with a blind implementation. You are awesome :)

@kaltindas 😊 Thank you for your help with testing!

@kaltindas sorry for disturbing, but I need your help since I dont have access to Azure OpenAI :( Do you have the same problem as described here? Thanks!


pls provide banti_segmenter binary  for mac osx

I do not have access to a Mac, if you can download the source code and compile and upload a binary, that would be awesome :)

page.py in the banti module of release v2.0 does everything that banti_segmenter can do. The banti_segmenter has been renamed antanci_telugu_ocr.


Initial commit of FLoating Point Tests.

This PR contains the FP tests for all extensions. The tests are sorted and placed into repos
depending on the first ISA configuration which introduces the corresponding instruction canonically
i.e according to the categorisation in Chapter 26 of the spec.
Detailed coverage statistics and the normalised CGF for the isa configuration RV64IFD
can be found here. The html report hasn't been
included in the PR due to its large size(approx 230 MB). A markdown version of the coverage
statistics can be found here.
Explanation for missing coverage

The coverage computation for the fused operations(f[n]madd*,f[n]msub*) hasn't been completed
yet due to the time taken(approx 48 hours). Further updates will address this issue.
The coverage for the fcvt instructions where the width of the destination representation is
larger than the width of the source representation(such as fcvt.d.s) will not meet coverage
goals due to a bug in the gcc-toolchain.
Refer to this issue for more information.

The diffs aren't getting generated for this pr. I have outlined the change below for ease of review:

Changes to the arch_test.h header file here.
Changes to the tests.

RV32F
RV32D
RV64F
RV64D

Removed all the old reports from riscv-test-stats directory(only for the F and D extensions)


Update smoke_alarm.py

added DEVELCO to the MODELS_INFO: as it fixes the battery level indication

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 83.484%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
6733

Relevant Lines:
8065

💛  - Coveralls

Codecov Report
Base: 83.48% // Head: 83.48% // No change to project coverage :thumbsup:

Coverage data is based on head (b0c51f2) compared to base (7788036).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff           @@
##              dev    #2062   +/-   ##
=======================================
  Coverage   83.48%   83.48%
=======================================
  Files         249      249
  Lines        8065     8065
=======================================
  Hits         6733     6733
  Misses       1332     1332

Impacted Files
Coverage Δ

zhaquirks/develco/smoke_alarm.py
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

added develco to smoke alarm


Wrong TMDB/TVDB ids for some shows

Hello guys,
I've developed a quick python script that uses the Trakt API with Tautulli to scrobble my watched content on my plex.
I've tried in postman with Good Doctor S01E01, it worked perfectly.
When I wanted to try it live with my current show Suits (2011), Tautulli sent the right TMDB/TVDB id to the script that have pushed it to the Trakt API (tried boths). I've tried to reproduce the issue in postman with the tmdb id : 37680 and it returned me a completely other episode name and the wrong show.
Here's the request and it's result with headers :
POST https://api.trakt.tv/scrobble/start
headers:
trakt-api-key: my_key
trakt-api-version: 2
Content-type: application/json

BODY: {"episode": {"season": 5, "number": 12, "ids": {"tmdb": 37680}}, "progress": 75, "app_version": "1.0", "app_date": "2022-10-13"}

RESPONSE:
{
    "id": 0,
    "action": "start",
    "progress": 75,
    "sharing": {
        "facebook": false,
        "twitter": false,
        "tumblr": false
    },
    "episode": {
        "season": 1,
        "number": 32,
        "title": "Spin the Batfink",
        "ids": {
            "trakt": 41466,
            "tvdb": 835361,
            "imdb": null,
            "tmdb": 37680,
            "tvrage": null
        }
    },
    "show": {
        "title": "Batfink",
        "year": 1966,
        "ids": {
            "trakt": 663,
            "slug": "batfink",
            "tvdb": 82703,
            "imdb": "tt11425960",
            "tmdb": 665,
            "tvrage": null
        }
    }
}

I think for some show, the ids section is completly wrong which causes the wrong episode in the wrong show to be scrobbled.
Can you look into that ?
Thanks :)

You are sending TMDB ID 37680 to find the episode, which the API is doing correctly. It's finding https://trakt.tv/shows/batfink/seasons/1/episodes/32.
What you actually want to do is send the show TMDB ID for Suits, so the JSON structure needs to reflect that.
{
  "show": {
    "title": "Suits",
    "ids": {
      "tmdb": 37680
    }
  },
  "episode": {
    "season": 5,
    "number": 12
  }
}

Oh okay, i've just tried and of course it fixes my script !
After checking with the doc, it's mentionned inside it but it's not very clear, can you maybe describe more in the JSON POST Data description instead of redirecting to the whole lot of examples to make it clearer ? :)
thanks for the help !


Change Date Picker to only be range OR Single day

Date picker will only serve as a range date picker or a single day picker. Prop range controls that.
This is in preparation for upcoming nav change which will not have any pages which can be both ranged and single day pages.

So on the

not have any pages which can be both ranged and single day pages.
What are we doing with slow zones? As slow zones both has a "today" value as well as a range that lets you see changes over time. Are we just going to have the range only apply to some, and have the today options always shown as today?

Discussed with @devinmatte
We came to the conclusion:

Trip explorer will revert to having the swappable date range picker or something similar.
all Overview sub pages will have the range only date picker. Slow zones map will be pinned to the end date with a visual indicator to show it is not a range view.


upload image not working

Hi, I am getting this error for image upload,

Is there a way around this?

@yatharthsharma fixed this issue in the master branch code and will work in the next release.


Mentions of Foundation for Public Code to possibly address

As this repository has been transferred from the Foundation for Public Code namespace, there might be a couple of places where the Foundation is mentioned that this community may want to address. The places where, I think, it makes sense to address it somehow are:

[ ] README.md
[ ] 404.md
[ ] CODE_OF_CONDUCT.md
[ ] CONTRIBUTING.md
[ ] foreword.md
[ ] print-cover.html
[ ] publiccode.yml

And, of course, GOVERNANCE.md, but there is already a suggestion for that change.
Finally, the theme this repository is using for the Jekyll build of the site, is a branded one too. How to address that might be worth its own issue, as it is a larger change, possibly addressed by forking the theme.

Will start looking at this tomorrow.

It looks like it would be helpful to have a short explanation of the relationship between this and the Foundation for Public Code, to help:

people who know something about the Standard but may not know why/that this is now the leading version
people who are complete newcomers, but need to know why to trust this (ie, it was initiated by a team of experts at a credible institution, and has since been moved to community governance/maintenance).

I propose something like this, based on governance.md:

The Standard for Public Code is a community governed project. It was started by the Foundation for Public Code in 2019.
Started by the Foundation for Public Code in 2019, the Standard for Public Code has been community governed since 2024.

@ElenaFdR Agree, and I like your suggestions. Currently it would be rather confusing for someone looking at this coming the outside and not knowing the history.

How to go about: "To raise a concern, please email<EMAIL_ADDRESS>(Code of Conduct)?


Feature request: allow custom timestamps for metrics

Use case
I'm creating a lambda to report metrics from an external source to Cloudwatch for observability within AWS. I'm looking for a way to set a custom timestamp for the metrics emitted each invocation.
The metrics I'm querying from the external source will basically be a list of (metric name, value) tuples for a specific time. This specific time will be in the recent past, maybe a few minutes old, but I'm not sure that matters here.
I can easily add the key and values to metrics, however I cannot set an explicit time because Metrics does not expose a way and the the time ultimately always set to datetime.now() when rendered to emf.
Solution/User Experience
I'm imagining a simple api to set the timestamp on the Metrics object. If a timestamp is not specific then the current time should be used.
metrics = Metrics()

@metrics.log_metrics
def lambda_handler(event: dict, context: LambdaContext):
    time = ...
    metric_values: list[(string, string)] = ...
    for (name, value) in metric_values:
            metrics.add_metric(name=name unit=MetricUnit.Count, value=value)
   metrics.set_timestamp(time) # <---

Alternative solutions
aws-embedded-metrics-python supports setting the timestamp on their MetricLogger class.
Acknowledgment

[X] This feature request meets Powertools for AWS Lambda (Python) Tenets
[X] Should this be considered in other Powertools for AWS Lambda languages? i.e. Java, TypeScript, and .NET

@pseidel-kcf just checking to see if you would like to work on this one?

Thanks for the follow up.
I don't have capacity to work on this.
This is no longer a blocker for me because the external source from my example is implementing a built-in way to export metrics.

No problem! We'll keep it in the backlog to see if there's more interest in this feature. Thank you so much for opening this!

@rubenfonseca Would it be possible for me to contribute to this? I'd be interested. Let me know

Hey everyone! I submitted a PullRequest to add this new feature, but I have some questions.
1 - Timestamp type

According to the AWS Documentation timestamp is a number representing the time stamp used for metrics extracted from the event. Values MUST be expressed as the number of milliseconds after Jan 1, 1970 00:00:00 UTC.

That said, should we only allow int inputs with epoch value, or should customers be able to pass datetime objects and have them converted internally?
2 - Invalid values
If a customer passes an invalid number, we will emit a warning and fallback to the current timestamp instead of raising an exception.
I'm still working on the pull request and I expect to have it merged by next week.
Thank you.

1 - I agree that we should start simple with "int", as we can always overload the function later if there's the demand for other types
Great job picking this up Leandro


thermald: add function for blocking cloudlog instead of sleep

perform fsync after cloudlog.info to make sure logs are written to disk before shutdown

Making a blocking cloudlog is quite a bit more complicated than this. I would recommend something simpler for a first contribution.

Making a blocking cloudlog is quite a bit more complicated than this. I would recommend something simpler for a first contribution.

Does it have to use logmessaged? In one of the comments it says that you can use the get_file_handler in the case that logmessaged isn't running. This uses SwaglogRotatingFileHandler which can call emit directly, which then calls flush on the file stream. So might just have to make sure to fsync

Think the cleanest solution is to set the DoShutdown param. Then manager will handle the rest of the shutdown. That shuts down logmessaged cleanly before shutting down.

https://github.com/commaai/openpilot/pull/23528