DTVF: Meta-data display enhancement

Based on the King's Lynn visualisation, it would be great to allow for the following features in the future:

include meta-data for time series (as discussed already)
allow for custom ordering of displayed metadata, potentially even nesting
display multiple values per key (currently only the first result is displayed in case the FIA returns multiple triples for the same key, e.g. a building having multiple usages)

Despite the visualisation bit, I am not sure whether additional quantities are actually retrieved properly by the FIA. I just saw that even though the LastUpdate is provided by the FIA query for each forecast timeseries (screenshot), the visualisation receives a response with all last updates as property nested within one observation timeseries node (i.e. Visibility observation):
{"meta":[{"Elevation":"\"21.0\"^^<http://www.w3.org/2001/XMLSchema#float> [m]","Type":"ReportingStation","Identifier":"3482","Data source":"Met Office DataPoint","Name":"Marham"}],"time":[{"data":["Visibility observation"],"values":[[9000,50000,55000,60000,50000,55000,50000,50000,50000,40000,35000,30000,27000,26000,35000,40000,50000,24000,3000,100,14000,25000,35000,50000,24000,75000,25000,75000,75000,55000,20000,29000,35000,75000,75000,65000,65000,60000,10000,45000,13000,19000,26000,9000,12000,3200,4200,35000,6000,40000,55000,50000,40000,55000,55000,45000,55000,45000,65000,40000,40000,50000,75000,65000,55000,45000,35000]],"timeClass":"Instant","valuesClass":["Number"],"id":0,"units":["m"],"time":["2023-02-27T08:00:00Z","2023-02-27T09:00:00Z","2023-02-27T10:00:00Z","2023-02-27T11:00:00Z","2023-02-27T12:00:00Z","2023-02-27T13:00:00Z","2023-02-27T14:00:00Z","2023-02-27T15:00:00Z","2023-02-27T16:00:00Z","2023-02-27T17:00:00Z","2023-02-27T18:00:00Z","2023-02-27T19:00:00Z","2023-02-27T20:00:00Z","2023-02-27T21:00:00Z","2023-02-27T22:00:00Z","2023-02-27T23:00:00Z","2023-02-28T00:00:00Z","2023-02-28T01:00:00Z","2023-02-28T02:00:00Z","2023-02-28T03:00:00Z","2023-02-28T04:00:00Z","2023-02-28T05:00:00Z","2023-02-28T06:00:00Z","2023-02-28T07:00:00Z","2023-02-28T08:00:00Z","2023-02-28T09:00:00Z","2023-02-28T10:00:00Z","2023-02-28T11:00:00Z","2023-02-28T12:00:00Z","2023-02-28T13:00:00Z","2023-02-28T14:00:00Z","2023-02-28T15:00:00Z","2023-02-28T16:00:00Z","2023-02-28T17:00:00Z","2023-02-28T18:00:00Z","2023-02-28T19:00:00Z","2023-02-28T20:00:00Z","2023-02-28T21:00:00Z","2023-02-28T22:00:00Z","2023-02-28T23:00:00Z","2023-03-01T00:00:00Z","2023-03-01T01:00:00Z","2023-03-01T02:00:00Z","2023-03-01T03:00:00Z","2023-03-01T04:00:00Z","2023-03-01T05:00:00Z","2023-03-01T06:00:00Z","2023-03-01T07:00:00Z","2023-03-01T08:00:00Z","2023-03-01T09:00:00Z","2023-03-01T10:00:00Z","2023-03-01T11:00:00Z","2023-03-01T12:00:00Z","2023-03-01T13:00:00Z","2023-03-01T14:00:00Z","2023-03-01T15:00:00Z","2023-03-01T16:00:00Z","2023-03-01T17:00:00Z","2023-03-01T18:00:00Z","2023-03-01T19:00:00Z","2023-03-01T20:00:00Z","2023-03-01T21:00:00Z","2023-03-01T22:00:00Z","2023-03-01T23:00:00Z","2023-03-02T00:00:00Z","2023-03-02T01:00:00Z","2023-03-02T02:00:00Z"],"properties":[{},{},{},{},{},{},{},{},{},{},{},{"LastUpdate":"\"2023-03-02T02:00:00.000Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime>"},{"LastUpdate":"\"2023-03-02T02:00:00.000Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime>"},{"LastUpdate":"\"2023-03-02T02:00:00.000Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime>"},{"LastUpdate":"\"2023-03-02T02:00:00.000Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime>"},{"LastUpdate":"\"2023-03-02T02:00:00.000Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime>"},{"LastUpdate":"\"2023-03-02T02:00:00.000Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime>"},{"LastUpdate":"\"2023-03-02T02:00:00.000Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime>"},{"LastUpdate":"\"2023-03-02T02:00:00.000Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime>"},{"LastUpdate":"\"2023-03-02T02:00:00.000Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime>"},{"LastUpdate":"\"2023-03-02T02:00:00.000Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime>"},{"LastUpdate":"\"2023-03-02T02:00:00.000Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime>"},{"LastUpdate":"\"2023-03-02T02:00:00.000Z\"^^<http://www.w3.org/2001/XMLSchema#dateTime>"}]},{"data":["WindDirection observation"],"values":[[45,22.5,45,45,67.5,45,45,22.5,45,45,45,45,45,22.5,45,0,0,292.5,337.5,0,22.5,0,337.5,0,337.5,22.5,45,0,0,22.5,22.5,0,22.5,22.5,22.5,22.5,45,45,67.5,22.5,45,0,22.5,315,337.5,337.5,0,337.5,22.5,0,22.5,22.5,45,22.5,22.5,45,45,22.5,45,22.5,45,67.5,67.5,90,67.5,0,0]],"timeClass":"Instant","valuesClass":["Number"],"id":1,"units":["Â°"],"time":["2023-02-27T08:00:00Z","2023-02-27T09:00:00Z","2023-02-27T10:00:00Z","2023-02-27T11:00:00Z","2023-02-27T12:00:00Z","2023-02-27T13:00:00Z","2023-02-27T14:00:00Z","2023-02-27T15:00:00Z","2023-02-27T16:00:00Z","2023-02-27T17:00:00Z","2023-02-27T18:00:00Z","2023-02-27T19:00:00Z","2023-02-27T20:00:00Z","2023-02-27T21:00:00Z","2023-02-27T22:00:00Z","2023-02-27T23:00:00Z","2023-02-28T00:00:00Z","2023-02-28T01:00:00Z","2023-02-28T02:00:00Z","2023-02-28T03:00:00Z","2023-02-28T04:00:00Z","2023-02-28T05:00:00Z","2023-02-28T06:00:00Z","2023-02-28T07:00:00Z","2023-02-28T08:00:00Z","2023-02-28T09:00:00Z","2023-02-28T10:00:00Z","2023-02-28T11:00:00Z","2023-02-28T12:00:00Z","2023-02-28T13:00:00Z","2023-02-28T14:00:00Z","2023-02-28T15:00:00Z","2023-02-28T16:00:00Z","2023-02-28T17:00:00Z","2023-02-28T18:00:00Z","2023-02-28T19:00:00Z","2023-02-28T20:00:00Z","2023-02-28T21:00:00Z","2023-02-28T22:00:00Z","2023-02-28T23:00:00Z","2023-03-01T00:00:00Z","2023-03-01T01:00:00Z","2023-03-01T02:00:00Z","2023-03-01T03:00:00Z","2023-03-01T04:00:00Z","2023-03-01T05:00:00Z","2023-03-01T06:00:00Z","2023-03-01T07:00:00Z","2023-03-01T08:00:00Z","2023-03-01T09:00:00Z","2023-03-01T10:00:00Z","2023-03-01T11:00:00Z","2023-03-01T12:00:00Z","2023-03-01T13:00:00Z","2023-03-01T14:00:00Z","2023-03-01T15:00:00Z","2023-03-01T16:00:00Z","2023-03-01T17:00:00Z","2023-03-01T18:00:00Z","2023-03-01T19:00:00Z","2023-03-01T20:00:00Z","2023-03-01T21:00:00Z","2023-03-01T22:00:00Z","2023-03-01T23:00:00Z","2023-03-02T00:00:00Z","2023-03-02T01:00:00Z","2023-03-02T02:00:00Z"]},{"data":["AirTemperature observation"],"values":[[2.2,5.5,6.8,6.1,7.1,7.3,7.4,7.9,7.1,6,4.3,2.5,1.4,1,3.3,2.2,1.8,1,0,-0.2,-0.2,1.6,3,3.6,4.7,5.3,6.4,6.9,7.9,7.3,7.2,7.5,6.2,5.3,5.1,5,4.6,4.6,4.4,4.3,4,4,3.5,3.9,3.2,3.2,1.8,2,3.7,5.7,7,6.5,7.1,8.3,7.4,6.4,6.7,6.4,5.2,5.1,5.1,5,5.1,3.5,2.1,0.6,0.5]],"timeClass":"Instant","valuesClass":["Number"],"id":2,"units":["Â°C"],"time":["2023-02-27T08:00:00Z","2023-02-27T09:00:00Z","2023-02-27T10:00:00Z","2023-02-27T11:00:00Z","2023-02-27T12:00:00Z","2023-02-27T13:00:00Z","2023-02-27T14:00:00Z","2023-02-27T15:00:00Z","2023-02-27T16:00:00Z","2023-02-27T17:00:00Z","2023-02-27T18:00:00Z","2023-02-27T19:00:00Z","2023-02-27T20:00:00Z","2023-02-27T21:00:00Z","2023-02-27T22:00:00Z","2023-02-27T23:00:00Z","2023-02-28T00:00:00Z","2023-02-28T01:00:00Z","2023-02-28T02:00:00Z","2023-02-28T03:00:00Z","2023-02-28T04:00:00Z","2023-02-28T05:00:00Z","2023-02-28T06:00:00Z","2023-02-28T07:00:00Z","2023-02-28T08:00:00Z","2023-02-28T09:00:00Z","2023-02-28T10:00:00Z","2023-02-28T11:00:00Z","2023-02-28T12:00:00Z","2023-02-28T13:00:00Z","2023-02-28T14:00:00Z","2023-02-28T15:00:00Z","2023-02-28T16:00:00Z","2023-02-28T17:00:00Z","2023-02-28T18:00:00Z","2023-02-28T19:00:00Z","2023-02-28T20:00:00Z","2023-02-28T21:00:00Z","2023-02-28T22:00:00Z","2023-02-28T23:00:00Z","2023-03-01T00:00:00Z","2023-03-01T01:00:00Z","2023-03-01T02:00:00Z","2023-03-01T03:00:00Z","2023-03-01T04:00:00Z","2023-03-01T05:00:00Z","2023-03-01T06:00:00Z","2023-03-01T07:00:00Z","2023-03-01T08:00:00Z","2023-03-01T09:00:00Z","2023-03-01T10:00:00Z","2023-03-01T11:00:00Z","2023-03-01T12:00:00Z","2023-03-01T13:00:00Z","2023-03-01T14:00:00Z","2023-03-01T15:00:00Z","2023-03-01T16:00:00Z","2023-03-01T17:00:00Z","2023-03-01T18:00:00Z","2023-03-01T19:00:00Z","2023-03-01T20:00:00Z","2023-03-01T21:00:00Z","2023-03-01T22:00:00Z","2023-03-01T23:00:00Z","2023-03-02T00:00:00Z","2023-03-02T01:00:00Z","2023-03-02T02:00:00Z"]},{"data":["WindGust observation"],"values":[[7,18,15,23,21,19,19,22,22,21,18,10,7,8,7,7,9,5,7,7,8,6,8,7,11,16,19,19,22,25,24,25,22,21,17,15,14,15,13,11,13,6,3,6,5,5,5,8,7,8,17,21,19,24,22,22,18,19,15,9,10,10,13,9,10,9,9]],"timeClass":"Instant","valuesClass":["Number"],"id":3,"units":["mi/h"],"time":["2023-02-27T08:00:00Z","2023-02-27T09:00:00Z","2023-02-27T10:00:00Z","2023-02-27T11:00:00Z","2023-02-27T12:00:00Z","2023-02-27T13:00:00Z","2023-02-27T14:00:00Z","2023-02-27T15:00:00Z","2023-02-27T16:00:00Z","2023-02-27T17:00:00Z","2023-02-27T18:00:00Z","2023-02-27T19:00:00Z","2023-02-27T20:00:00Z","2023-02-27T21:00:00Z","2023-02-27T22:00:00Z","2023-02-27T23:00:00Z","2023-02-28T00:00:00Z","2023-02-28T01:00:00Z","2023-02-28T02:00:00Z","2023-02-28T03:00:00Z","2023-02-28T04:00:00Z","2023-02-28T05:00:00Z","2023-02-28T06:00:00Z","2023-02-28T07:00:00Z","2023-02-28T08:00:00Z","2023-02-28T09:00:00Z","2023-02-28T10:00:00Z","2023-02-28T11:00:00Z","2023-02-28T12:00:00Z","2023-02-28T13:00:00Z","2023-02-28T14:00:00Z","2023-02-28T15:00:00Z","2023-02-28T16:00:00Z","2023-02-28T17:00:00Z","2023-02-28T18:00:00Z","2023-02-28T19:00:00Z","2023-02-28T20:00:00Z","2023-02-28T21:00:00Z","2023-02-28T22:00:00Z","2023-02-28T23:00:00Z","2023-03-01T00:00:00Z","2023-03-01T01:00:00Z","2023-03-01T02:00:00Z","2023-03-01T03:00:00Z","2023-03-01T04:00:00Z","2023-03-01T05:00:00Z","2023-03-01T06:00:00Z","2023-03-01T07:00:00Z","2023-03-01T08:00:00Z","2023-03-01T09:00:00Z","2023-03-01T10:00:00Z","2023-03-01T11:00:00Z","2023-03-01T12:00:00Z","2023-03-01T13:00:00Z","2023-03-01T14:00:00Z","2023-03-01T15:00:00Z","2023-03-01T16:00:00Z","2023-03-01T17:00:00Z","2023-03-01T18:00:00Z","2023-03-01T19:00:00Z","2023-03-01T20:00:00Z","2023-03-01T21:00:00Z","2023-03-01T22:00:00Z","2023-03-01T23:00:00Z","2023-03-02T00:00:00Z","2023-03-02T01:00:00Z","2023-03-02T02:00:00Z"]},{"data":["DewPoint observation"],"values":[[1.4,3.8,3.4,1.7,1.4,2.2,1.6,0.6,0.5,1,1.1,0.3,0.2,0.2,2.1,0.3,0.5,0.2,-0.7,-0.8,-0.6,1.3,2.7,3.1,3.7,3.7,4.1,3.8,4.9,4.3,3.8,4.1,4.5,3.6,3.4,3.8,3.4,3.5,3.5,3.6,3.3,3.3,2.8,3.4,2.6,2.8,1.2,1.6,3.3,5.4,4.6,5.2,5.2,4.6,4.2,4.2,3.1,3,3,3.4,3.3,3.2,1.6,0.7,-0.5,-1.2,-1.1]],"timeClass":"Instant","valuesClass":["Number"],"id":4,"units":["Â°C"],"time":["2023-02-27T08:00:00Z","2023-02-27T09:00:00Z","2023-02-27T10:00:00Z","2023-02-27T11:00:00Z","2023-02-27T12:00:00Z","2023-02-27T13:00:00Z","2023-02-27T14:00:00Z","2023-02-27T15:00:00Z","2023-02-27T16:00:00Z","2023-02-27T17:00:00Z","2023-02-27T18:00:00Z","2023-02-27T19:00:00Z","2023-02-27T20:00:00Z","2023-02-27T21:00:00Z","2023-02-27T22:00:00Z","2023-02-27T23:00:00Z","2023-02-28T00:00:00Z","2023-02-28T01:00:00Z","2023-02-28T02:00:00Z","2023-02-28T03:00:00Z","2023-02-28T04:00:00Z","2023-02-28T05:00:00Z","2023-02-28T06:00:00Z","2023-02-28T07:00:00Z","2023-02-28T08:00:00Z","2023-02-28T09:00:00Z","2023-02-28T10:00:00Z","2023-02-28T11:00:00Z","2023-02-28T12:00:00Z","2023-02-28T13:00:00Z","2023-02-28T14:00:00Z","2023-02-28T15:00:00Z","2023-02-28T16:00:00Z","2023-02-28T17:00:00Z","2023-02-28T18:00:00Z","2023-02-28T19:00:00Z","2023-02-28T20:00:00Z","2023-02-28T21:00:00Z","2023-02-28T22:00:00Z","2023-02-28T23:00:00Z","2023-03-01T00:00:00Z","2023-03-01T01:00:00Z","2023-03-01T02:00:00Z","2023-03-01T03:00:00Z","2023-03-01T04:00:00Z","2023-03-01T05:00:00Z","2023-03-01T06:00:00Z","2023-03-01T07:00:00Z","2023-03-01T08:00:00Z","2023-03-01T09:00:00Z","2023-03-01T10:00:00Z","2023-03-01T11:00:00Z","2023-03-01T12:00:00Z","2023-03-01T13:00:00Z","2023-03-01T14:00:00Z","2023-03-01T15:00:00Z","2023-03-01T16:00:00Z","2023-03-01T17:00:00Z","2023-03-01T18:00:00Z","2023-03-01T19:00:00Z","2023-03-01T20:00:00Z","2023-03-01T21:00:00Z","2023-03-01T22:00:00Z","2023-03-01T23:00:00Z","2023-03-02T00:00:00Z","2023-03-02T01:00:00Z","2023-03-02T02:00:00Z"]},{"data":["AtmosphericPressure observation"],"values":[[1032,1032,1032,1033,1033,1032,1032,1032,1032,1032,1033,1033,1033,1033,1033,1033,1034,1034,1034,1034,1033,1034,1034,1033,1034,1033,1034,1033,1033,1032,1032,1032,1032,1032,1032,1033,1033,1033,1033,1033,1034,1033,1033,1032,1032,1031,1031,1031,1031,1031,1030,1030,1030,1029,1028,1028,1027,1026,1027,1027,1027,1027,1027,1027,1027,1027,1027]],"timeClass":"Instant","valuesClass":["Number"],"id":5,"units":["hPa"],"time":["2023-02-27T08:00:00Z","2023-02-27T09:00:00Z","2023-02-27T10:00:00Z","2023-02-27T11:00:00Z","2023-02-27T12:00:00Z","2023-02-27T13:00:00Z","2023-02-27T14:00:00Z","2023-02-27T15:00:00Z","2023-02-27T16:00:00Z","2023-02-27T17:00:00Z","2023-02-27T18:00:00Z","2023-02-27T19:00:00Z","2023-02-27T20:00:00Z","2023-02-27T21:00:00Z","2023-02-27T22:00:00Z","2023-02-27T23:00:00Z","2023-02-28T00:00:00Z","2023-02-28T01:00:00Z","2023-02-28T02:00:00Z","2023-02-28T03:00:00Z","2023-02-28T04:00:00Z","2023-02-28T05:00:00Z","2023-02-28T06:00:00Z","2023-02-28T07:00:00Z","2023-02-28T08:00:00Z","2023-02-28T09:00:00Z","2023-02-28T10:00:00Z","2023-02-28T11:00:00Z","2023-02-28T12:00:00Z","2023-02-28T13:00:00Z","2023-02-28T14:00:00Z","2023-02-28T15:00:00Z","2023-02-28T16:00:00Z","2023-02-28T17:00:00Z","2023-02-28T18:00:00Z","2023-02-28T19:00:00Z","2023-02-28T20:00:00Z","2023-02-28T21:00:00Z","2023-02-28T22:00:00Z","2023-02-28T23:00:00Z","2023-03-01T00:00:00Z","2023-03-01T01:00:00Z","2023-03-01T02:00:00Z","2023-03-01T03:00:00Z","2023-03-01T04:00:00Z","2023-03-01T05:00:00Z","2023-03-01T06:00:00Z","2023-03-01T07:00:00Z","2023-03-01T08:00:00Z","2023-03-01T09:00:00Z","2023-03-01T10:00:00Z","2023-03-01T11:00:00Z","2023-03-01T12:00:00Z","2023-03-01T13:00:00Z","2023-03-01T14:00:00Z","2023-03-01T15:00:00Z","2023-03-01T16:00:00Z","2023-03-01T17:00:00Z","2023-03-01T18:00:00Z","2023-03-01T19:00:00Z","2023-03-01T20:00:00Z","2023-03-01T21:00:00Z","2023-03-01T22:00:00Z","2023-03-01T23:00:00Z","2023-03-02T00:00:00Z","2023-03-02T01:00:00Z","2023-03-02T02:00:00Z"]},{"data":["RelativeHumidity observation"],"values":[[94.4,88.6,78.5,72.8,66.4,69.4,66,59.1,62.1,69.7,79.2,85.1,91.6,94.2,91.7,87,90.8,94.2,94.3,94.9,96.5,97.8,97.9,96.5,93.2,89.1,84.9,80.2,81,80.8,78.6,78.7,88.6,88.6,88.5,91.6,91.7,92.5,93.7,95.1,95.1,95.1,95.2,96.4,95.7,97.1,95.5,97,97.1,97.9,84.4,91.3,87.5,77.1,79.8,85.6,77.4,78.5,85.4,88.5,87.9,87.9,77.7,81.5,82.6,87.5,86.9]],"timeClass":"Instant","valuesClass":["Number"],"id":6,"units":["%"],"time":["2023-02-27T08:00:00Z","2023-02-27T09:00:00Z","2023-02-27T10:00:00Z","2023-02-27T11:00:00Z","2023-02-27T12:00:00Z","2023-02-27T13:00:00Z","2023-02-27T14:00:00Z","2023-02-27T15:00:00Z","2023-02-27T16:00:00Z","2023-02-27T17:00:00Z","2023-02-27T18:00:00Z","2023-02-27T19:00:00Z","2023-02-27T20:00:00Z","2023-02-27T21:00:00Z","2023-02-27T22:00:00Z","2023-02-27T23:00:00Z","2023-02-28T00:00:00Z","2023-02-28T01:00:00Z","2023-02-28T02:00:00Z","2023-02-28T03:00:00Z","2023-02-28T04:00:00Z","2023-02-28T05:00:00Z","2023-02-28T06:00:00Z","2023-02-28T07:00:00Z","2023-02-28T08:00:00Z","2023-02-28T09:00:00Z","2023-02-28T10:00:00Z","2023-02-28T11:00:00Z","2023-02-28T12:00:00Z","2023-02-28T13:00:00Z","2023-02-28T14:00:00Z","2023-02-28T15:00:00Z","2023-02-28T16:00:00Z","2023-02-28T17:00:00Z","2023-02-28T18:00:00Z","2023-02-28T19:00:00Z","2023-02-28T20:00:00Z","2023-02-28T21:00:00Z","2023-02-28T22:00:00Z","2023-02-28T23:00:00Z","2023-03-01T00:00:00Z","2023-03-01T01:00:00Z","2023-03-01T02:00:00Z","2023-03-01T03:00:00Z","2023-03-01T04:00:00Z","2023-03-01T05:00:00Z","2023-03-01T06:00:00Z","2023-03-01T07:00:00Z","2023-03-01T08:00:00Z","2023-03-01T09:00:00Z","2023-03-01T10:00:00Z","2023-03-01T11:00:00Z","2023-03-01T12:00:00Z","2023-03-01T13:00:00Z","2023-03-01T14:00:00Z","2023-03-01T15:00:00Z","2023-03-01T16:00:00Z","2023-03-01T17:00:00Z","2023-03-01T18:00:00Z","2023-03-01T19:00:00Z","2023-03-01T20:00:00Z","2023-03-01T21:00:00Z","2023-03-01T22:00:00Z","2023-03-01T23:00:00Z","2023-03-02T00:00:00Z","2023-03-02T01:00:00Z","2023-03-02T02:00:00Z"]},{"data":["WindSpeed observation"],"values":[[3,7,10,13,11,11,13,16,15,14,8,6,5,5,3,6,3,1,6,6,5,3,6,6,8,11,9,14,13,15,17,16,14,11,8,9,9,8,5,7,3,3,2,3,3,3,3,5,3,5,10,11,11,15,14,14,13,11,6,5,6,7,7,6,6,8,7]],"timeClass":"Instant","valuesClass":["Number"],"id":7,"units":["mi/h"],"time":["2023-02-27T08:00:00Z","2023-02-27T09:00:00Z","2023-02-27T10:00:00Z","2023-02-27T11:00:00Z","2023-02-27T12:00:00Z","2023-02-27T13:00:00Z","2023-02-27T14:00:00Z","2023-02-27T15:00:00Z","2023-02-27T16:00:00Z","2023-02-27T17:00:00Z","2023-02-27T18:00:00Z","2023-02-27T19:00:00Z","2023-02-27T20:00:00Z","2023-02-27T21:00:00Z","2023-02-27T22:00:00Z","2023-02-27T23:00:00Z","2023-02-28T00:00:00Z","2023-02-28T01:00:00Z","2023-02-28T02:00:00Z","2023-02-28T03:00:00Z","2023-02-28T04:00:00Z","2023-02-28T05:00:00Z","2023-02-28T06:00:00Z","2023-02-28T07:00:00Z","2023-02-28T08:00:00Z","2023-02-28T09:00:00Z","2023-02-28T10:00:00Z","2023-02-28T11:00:00Z","2023-02-28T12:00:00Z","2023-02-28T13:00:00Z","2023-02-28T14:00:00Z","2023-02-28T15:00:00Z","2023-02-28T16:00:00Z","2023-02-28T17:00:00Z","2023-02-28T18:00:00Z","2023-02-28T19:00:00Z","2023-02-28T20:00:00Z","2023-02-28T21:00:00Z","2023-02-28T22:00:00Z","2023-02-28T23:00:00Z","2023-03-01T00:00:00Z","2023-03-01T01:00:00Z","2023-03-01T02:00:00Z","2023-03-01T03:00:00Z","2023-03-01T04:00:00Z","2023-03-01T05:00:00Z","2023-03-01T06:00:00Z","2023-03-01T07:00:00Z","2023-03-01T08:00:00Z","2023-03-01T09:00:00Z","2023-03-01T10:00:00Z","2023-03-01T11:00:00Z","2023-03-01T12:00:00Z","2023-03-01T13:00:00Z","2023-03-01T14:00:00Z","2023-03-01T15:00:00Z","2023-03-01T16:00:00Z","2023-03-01T17:00:00Z","2023-03-01T18:00:00Z","2023-03-01T19:00:00Z","2023-03-01T20:00:00Z","2023-03-01T21:00:00Z","2023-03-01T22:00:00Z","2023-03-01T23:00:00Z","2023-03-02T00:00:00Z","2023-03-02T01:00:00Z","2023-03-02T02:00:00Z"]},{"data":["PrecipitationProbability forecast"],"values":[[16,9,8,6,10,12,9,14,13,12,16,13,12,10,9,0,0,7]],"timeClass":"Instant","valuesClass":["Number"],"id":8,"units":["%"],"time":["2023-02-28T03:00:00Z","2023-02-28T06:00:00Z","2023-02-28T09:00:00Z","2023-02-28T12:00:00Z","2023-02-28T15:00:00Z","2023-02-28T18:00:00Z","2023-02-28T21:00:00Z","2023-03-01T00:00:00Z","2023-03-01T03:00:00Z","2023-03-01T06:00:00Z","2023-03-01T09:00:00Z","2023-03-01T12:00:00Z","2023-03-01T15:00:00Z","2023-03-01T18:00:00Z","2023-03-01T21:00:00Z","2023-03-02T00:00:00Z","2023-03-02T03:00:00Z","2023-03-02T06:00:00Z"]},{"data":["WindDirection forecast"],"values":[[0,337.5,337.5,22.5,22.5,22.5,45,45,22.5,0,22.5,22.5,22.5,22.5,45,67.5,22.5,22.5]],"timeClass":"Instant","valuesClass":["Number"],"id":9,"units":["Â°"],"time":["2023-02-28T03:00:00Z","2023-02-28T06:00:00Z","2023-02-28T09:00:00Z","2023-02-28T12:00:00Z","2023-02-28T15:00:00Z","2023-02-28T18:00:00Z","2023-02-28T21:00:00Z","2023-03-01T00:00:00Z","2023-03-01T03:00:00Z","2023-03-01T06:00:00Z","2023-03-01T09:00:00Z","2023-03-01T12:00:00Z","2023-03-01T15:00:00Z","2023-03-01T18:00:00Z","2023-03-01T21:00:00Z","2023-03-02T00:00:00Z","2023-03-02T03:00:00Z","2023-03-02T06:00:00Z"]},{"data":["AirTemperature forecast"],"values":[[0,3,5,8,8,5,4,4,4,4,5,7,7,5,4,2,1,1]],"timeClass":"Instant","valuesClass":["Number"],"id":10,"units":["Â°C"],"time":["2023-02-28T03:00:00Z","2023-02-28T06:00:00Z","2023-02-28T09:00:00Z","2023-02-28T12:00:00Z","2023-02-28T15:00:00Z","2023-02-28T18:00:00Z","2023-02-28T21:00:00Z","2023-03-01T00:00:00Z","2023-03-01T03:00:00Z","2023-03-01T06:00:00Z","2023-03-01T09:00:00Z","2023-03-01T12:00:00Z","2023-03-01T15:00:00Z","2023-03-01T18:00:00Z","2023-03-01T21:00:00Z","2023-03-02T00:00:00Z","2023-03-02T03:00:00Z","2023-03-02T06:00:00Z"]},{"data":["UVIndex forecast"],"values":[[0,0,1,1,1,0,0,0,0,0,1,1,1,0,0,0,0,0]],"timeClass":"Instant","valuesClass":["Number"],"id":11,"units":["1"],"time":["2023-02-28T03:00:00Z","2023-02-28T06:00:00Z","2023-02-28T09:00:00Z","2023-02-28T12:00:00Z","2023-02-28T15:00:00Z","2023-02-28T18:00:00Z","2023-02-28T21:00:00Z","2023-03-01T00:00:00Z","2023-03-01T03:00:00Z","2023-03-01T06:00:00Z","2023-03-01T09:00:00Z","2023-03-01T12:00:00Z","2023-03-01T15:00:00Z","2023-03-01T18:00:00Z","2023-03-01T21:00:00Z","2023-03-02T00:00:00Z","2023-03-02T03:00:00Z","2023-03-02T06:00:00Z"]},{"data":["Visibility forecast"],"values":[[4000,20000,40000,40000,40000,40000,40000,20000,20000,20000,40000,40000,40000,40000,40000,40000,40000,40000]],"timeClass":"Instant","valuesClass":["Number"],"id":12,"units":["m"],"time":["2023-02-28T03:00:00Z","2023-02-28T06:00:00Z","2023-02-28T09:00:00Z","2023-02-28T12:00:00Z","2023-02-28T15:00:00Z","2023-02-28T18:00:00Z","2023-02-28T21:00:00Z","2023-03-01T00:00:00Z","2023-03-01T03:00:00Z","2023-03-01T06:00:00Z","2023-03-01T09:00:00Z","2023-03-01T12:00:00Z","2023-03-01T15:00:00Z","2023-03-01T18:00:00Z","2023-03-01T21:00:00Z","2023-03-02T00:00:00Z","2023-03-02T03:00:00Z","2023-03-02T06:00:00Z"]},{"data":["FeelsLikeTemperature forecast"],"values":[[-3,0,2,4,4,2,2,3,2,2,3,4,4,3,2,-1,-2,-1]],"timeClass":"Instant","valuesClass":["Number"],"id":13,"units":["Â°C"],"time":["2023-02-28T03:00:00Z","2023-02-28T06:00:00Z","2023-02-28T09:00:00Z","2023-02-28T12:00:00Z","2023-02-28T15:00:00Z","2023-02-28T18:00:00Z","2023-02-28T21:00:00Z","2023-03-01T00:00:00Z","2023-03-01T03:00:00Z","2023-03-01T06:00:00Z","2023-03-01T09:00:00Z","2023-03-01T12:00:00Z","2023-03-01T15:00:00Z","2023-03-01T18:00:00Z","2023-03-01T21:00:00Z","2023-03-02T00:00:00Z","2023-03-02T03:00:00Z","2023-03-02T06:00:00Z"]},{"data":["RelativeHumidity forecast"],"values":[[96,98,90,67,71,86,88,95,94,92,89,75,76,87,92,83,89,89]],"timeClass":"Instant","valuesClass":["Number"],"id":14,"units":["%"],"time":["2023-02-28T03:00:00Z","2023-02-28T06:00:00Z","2023-02-28T09:00:00Z","2023-02-28T12:00:00Z","2023-02-28T15:00:00Z","2023-02-28T18:00:00Z","2023-02-28T21:00:00Z","2023-03-01T00:00:00Z","2023-03-01T03:00:00Z","2023-03-01T06:00:00Z","2023-03-01T09:00:00Z","2023-03-01T12:00:00Z","2023-03-01T15:00:00Z","2023-03-01T18:00:00Z","2023-03-01T21:00:00Z","2023-03-02T00:00:00Z","2023-03-02T03:00:00Z","2023-03-02T06:00:00Z"]},{"data":["WindGust forecast"],"values":[[7,9,13,25,25,20,16,13,13,11,13,22,20,13,11,11,16,16]],"timeClass":"Instant","valuesClass":["Number"],"id":15,"units":["mi/h"],"time":["2023-02-28T03:00:00Z","2023-02-28T06:00:00Z","2023-02-28T09:00:00Z","2023-02-28T12:00:00Z","2023-02-28T15:00:00Z","2023-02-28T18:00:00Z","2023-02-28T21:00:00Z","2023-03-01T00:00:00Z","2023-03-01T03:00:00Z","2023-03-01T06:00:00Z","2023-03-01T09:00:00Z","2023-03-01T12:00:00Z","2023-03-01T15:00:00Z","2023-03-01T18:00:00Z","2023-03-01T21:00:00Z","2023-03-02T00:00:00Z","2023-03-02T03:00:00Z","2023-03-02T06:00:00Z"]},{"data":["WindSpeed forecast"],"values":[[7,7,9,16,16,11,7,4,4,4,7,13,13,7,4,7,7,4]],"timeClass":"Instant","valuesClass":["Number"],"id":16,"units":["mi/h"],"time":["2023-02-28T03:00:00Z","2023-02-28T06:00:00Z","2023-02-28T09:00:00Z","2023-02-28T12:00:00Z","2023-02-28T15:00:00Z","2023-02-28T18:00:00Z","2023-02-28T21:00:00Z","2023-03-01T00:00:00Z","2023-03-01T03:00:00Z","2023-03-01T06:00:00Z","2023-03-01T09:00:00Z","2023-03-01T12:00:00Z","2023-03-01T15:00:00Z","2023-03-01T18:00:00Z","2023-03-01T21:00:00Z","2023-03-02T00:00:00Z","2023-03-02T03:00:00Z","2023-03-02T06:00:00Z"]}]}


File opening is no more working Linux & Mac

Open file with VS code is no more working, tried to update but no hope. open on last opening file only

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Feature: Markdown shortcut

Thank you for developing a great project. There is a request.
When entering markdown, for example ,

`
a
a
`

If you enter in the order of, it will be ,

`
`
Move the cursor back one
a
a

If you enter in the order of, it will not be .
I have a habit of inputting the latter, and I am very happy that the latter is also recognized.

@ghost Any chance you could take a look at Maksim's comment above and maybe update the bug description? It's proving a little difficult to debug currently.

Closing this as its difficult to repro.


Can I get the exact location of the problem?

As the title
I see that the current problem information output only contains the function name.
Can I get the exact location of the problem? Such as line of problem in the source file
Is there any better way

I am open to proposition, but keep in mind that LLVM-IR does not have information about "source file".
The best thing I can do now is to provide: function name, block name (or id), instruction offset in the block (or global instruction id), LLVM IR reconstructed instruction and problematic vreg name.

I have made some progress：
Source code line counts can be mapped into LLVM IR files with debug information
such as:
clang example.c -c -emit-llvm -g
And llvm_ir provide DebugLoc
vandalir can get line through methods like
.........................
let loc = func.get_debug_loc();

I created a fork and experimented with let souffle to output the line

feel free to send a pull request.


[blake3] build failure

Operating system
macOS
Compiler
apple clang
Steps to reproduce the behavior
crosscompile blake3 for x86_64 from a arm mac.

Failure logs
[4/6] : && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -pipe -fPIC -mmacosx-version-min=10.14 -arch x86_64 -mfpmath=sse -msse2 -mno-sse4.1 -mno-sse4.2 -mno-sse4a -DNDEBUG -Os -mmacosx-version-min=10.14 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk -mmacosx-version-min=10.14 -dynamiclib -Wl,-headerpad_max_install_names -arch x86_64   -current_version 1.3.3 -o libblake<IP_ADDRESS>.dylib -install_name @rpath/libblake3.0.dylib CMakeFiles/blake3.dir/blake3.c.o CMakeFiles/blake3.dir/blake3_dispatch.c.o CMakeFiles/blake3.dir/blake3_portable.c.o   && :
FAILED: libblake<IP_ADDRESS>.dylib
: && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -pipe -fPIC -mmacosx-version-min=10.14 -arch x86_64 -mfpmath=sse -msse2 -mno-sse4.1 -mno-sse4.2 -mno-sse4a -DNDEBUG -Os -mmacosx-version-min=10.14 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk -mmacosx-version-min=10.14 -dynamiclib -Wl,-headerpad_max_install_names -arch x86_64   -current_version 1.3.3 -o libblake<IP_ADDRESS>.dylib -install_name @rpath/libblake3.0.dylib CMakeFiles/blake3.dir/blake3.c.o CMakeFiles/blake3.dir/blake3_dispatch.c.o CMakeFiles/blake3.dir/blake3_portable.c.o   && :
Undefined symbols for architecture x86_64:
  "_blake3_compress_in_place_avx512", referenced from:
      _blake3_compress_in_place in blake3_dispatch.c.o
  "_blake3_compress_in_place_sse2", referenced from:
      _blake3_compress_in_place in blake3_dispatch.c.o
  "_blake3_compress_in_place_sse41", referenced from:
      _blake3_compress_in_place in blake3_dispatch.c.o
  "_blake3_compress_xof_avx512", referenced from:
      _blake3_compress_xof in blake3_dispatch.c.o
  "_blake3_compress_xof_sse2", referenced from:
      _blake3_compress_xof in blake3_dispatch.c.o
  "_blake3_compress_xof_sse41", referenced from:
      _blake3_compress_xof in blake3_dispatch.c.o
  "_blake3_hash_many_avx2", referenced from:
      _blake3_hash_many in blake3_dispatch.c.o
  "_blake3_hash_many_avx512", referenced from:
      _blake3_hash_many in blake3_dispatch.c.o
  "_blake3_hash_many_sse2", referenced from:
      _blake3_hash_many in blake3_dispatch.c.o
  "_blake3_hash_many_sse41", referenced from:
      _blake3_hash_many in blake3_dispatch.c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

Additional context
No response

I don't know much about the vcpkg build specifically, but this reminds me of issues I've run into where a macOS build is trying to make a "fat" binary that includes both x86 and ARM implementations, and the build logic gets confused about what files it shold include, and you end up with errors about missing x86-specific symbols. I don't know if I went about this the right way, but I had to solve a similar issue here: https://github.com/oconnor663/blake3-py/blob/806fbed0c92455e15d99039d8fd974e49beaf845/c_impl/setup.py#L90-L158. @BurningEnlightenment what do you think?

I need some more info to debug this.

crosscompile blake3 for x86_64 from a arm mac.

Do you use a custom CMake toolchain or do you rely on the vcpkg provided one?

Failure logs

Please provide us with the CMake configure logs and the CMakeCache.txts, otherwise it is impossible to trace the configuration logic.

This issue hasn’t been updated in 3 month, if it is still an issue, please reopen this issue.


[MPORT-502] Rewrite Requests validation class

@zendesk/dingo @zendesk/vegemite @zendesk/wattle
Description
This rewrite is necessary because of there are some edge cases that were not considered, which resulted in App uploads failing in production.
The initial approach includes searching for Request Methods and evaluating these addresses.
Problems discovered:

Regex grabs everything after the request methods including .then(..).catch(...).

/api/v2/channels/voice/stats/current_queue_activity.json").then(function requestDone(data)
{cqa=data.current_queue_activity,resolve()})})}function getAgentActivity(){return
agents.online=0,agents.available=0,new Promise(function(resolve,reject)
{client.request("/api/v2/channels/voice/stats/agents_activity.json").then(
function requestDone(data)
...
...
URI(request.captures[0]) -> URI::InvalidURIError: bad URI(is not URI?)

package.read converts everything to double quoted strings, retaining the \" and \t as well, therefore regexing off this wouldn't work effectively.
There is always the possibility we can miss the address when a developer does this.

var url = 'http://www.google.com/abc'
client.request(url).then(successHandler).catch(failHandler)

Also as we loop through each files, and with every file loop, we loop through the four request methods regex. Don't know what is the O notation on that. This can be reduced by a simple Regex union.

In this new approach, we scan for everything that looks like a url or ip address. We also file.read.gsub(/\"/, '').
Approach

When we detect http urls, we call this out in a warning.

When we detect any IP address, we determine if they are either a loopback, link_local or private.

TODOs:

[x] Update Specs
[x] Use localization for .join(', ') - txt.apps.admin.error.app_build.listing_comma
[x] Create localization branch for new string

References

https://zendesk.atlassian.net/browse/MPORT-502

Risks
[low] App upload fails when validating app

Looks good @keitheous, just left some minor comments.
As the new guy I'd be keen to know what our long term thinking around security is for this stuff. Anyone could get around what we're doing now by doing something as simple as `var ip = "127" + ".0.0.1" in their code.


fix client_lb_end2end_test ClientLbPickArgsTest.Basic flakiness

Can you say what the bug was?

The bug is documented in the comments in the PR.

Known issues: #26595
The "Bazel RBE Windows Debug C/C++" error is an infrastructure failure.


Update dependencies

Codecov Report

Merging #142 (c78cdfe) into main (df0ff89) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main      #142   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           29        29
  Lines          199       199
  Branches        44        47    +3
=========================================
  Hits           199       199

Continue to review full report at Codecov.

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


ci doesn't show running if retriggered after failing

CI failed initially and then was retriggered but the status doesn't show that it is running

it seems this got fixed some how  😄
Failed status

after retriggering


Fix calculation of pointer index for motion events

I made a silly mistake in #64 and got the operator precedence wrong.

Thanks! If you could publish a new version to crates.io soon that would be great, since this fixes scrolling in Servo (and probably fixes other weird touch input bugs in every app using this crate).

Done.


installation: failed to create database on OS X

Following the installation guide to install Invenio on OS X, @nharraud and I got following error when creating the database $ inveniomanage database create on master branch:
Test connection...      [ERROR]

************************************************************************
** DATABASE CONNECTIVITY ERROR:                                       **
** (_mysql_exceptions.OperationalError) (1045, "Access denied for     **
** user 'master'@'localhost' (using password: YES)").                 **
**                                                                    **
** Perhaps you need to set up database and connection rights?If yes,  **
** then please execute:                                               **
** console> inveniomanage database init --yes-i-know                  **
** The values printed above were detected from your configuration. If **
** they are not right, then please edit your invenio-local.conf file  **
** and rerun 'inveniocfg --update-all' first.                         **
**                                                                    **
** If the problem is of different nature, then please inspect the     **
** above error message and fix the problem before continuing.         **
************************************************************************

We fixed that issue by editing the invenio.cfg file: (invenio)$ vim var/invenio.base-instance/invenio.cfg:

replacing master with root in CFG_DATABASE_USER = u'master' and
add CFG_DATABASE_PASS = u'' (if you haven't set a root password)

I had the same problem recently. I found a solution with the grants setup using @'%' instead of @localhost. So if you simply add another grant that use @localhost in place of %, it works.

Added 2.1 milestone as it can be a potential problem for people when installing on OS X. We can try adding to the database init script an additional grant that uses @localhost in addition to @'%.

@hachreak Can you please have a look?  "master" vs "root" sounds like a PostgreSQL vs MySQL thing...

@tiborsimko The problem is not coming from the user name. As said by @jalavik, 'myuser'@'%' does not include 'myuser'@'localhost' on mysql. Thus we need to perform two grants.
https://www.stormconsultancy.co.uk/blog/development/bug-of-the-day/todays-gotcha-localhost-is-not-included-in-the-wildcard-when-granting-mysql-permissions/

@nharraud Yes, and I also pointed out that "master" should not be really used as a default string if people don't have any CFG_DATABASE_USER defined?  (rather "root", although the regular user would be called "invenio", not "root", by default)

@tiborsimko it comes from the installation guide when people call their database same as the branch they are working on ...

@jirikuncar Aha, OK :smile: FWIW in invenio-devscripts I've been using "inveniomaster" DB userr and name, so that I could have "inspiremaster", etc, for all the overlays I may be working on.  (Naked "master" seems too short to me.)


[Bug][Config-UI] Configuring GitLab data scopes gets error: TypeError Cannot read properties of null (reading 'gitlabId')

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
On v0.16.0-beta9, when selecting certain GitLab data scopes during creating a blueprint, I ran into the following error:

Notice how the checkboxes of the first 3 repos on the 3rd column were grayed out in the following screenshot:

I can select other repos without issue:

But when I try to select the ones whose checkboxes were grayed out, I ran into the error above.
What do you expect to happen
I'm able to select all displayed GitLab data scopes.
How to reproduce
See above.
Anything else
No response
Version
main
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

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

hi, @hezyin
Looks like a previous issue, what version are you using? Have you cleared the cache?

@mintsweet I'm certain it's not due to cache. I was still able to reproduce this exact bug on a fresh instance of v0.16.0-beta14 in Incognito mode.

It turned out this is not a bug. code-analytics cannot be directly selected since it's not a repo, but a group.

I am getting the exact same error, but pretty sure I'm selecting repos, since groups are always greyed out and not selectable.
TypeError: Cannot read properties of null (reading 'gitlabId')
It's particularly frustrating after selecting a few dozen repos already, clicking through the various levels and then having to redo it again every time.

v0.16.0-beta17


Update MyTeams to use new  library mgt-spfx

Q
A

Bug fix?
[x ]

New feature?
[ ]

New sample?
[ ]

Related issues?
fixes #X, partially #Y, mentioned in #Z

add mgt-spfx library to my-teams controls

Thanks Joao! I noticed that you created the PR from master to master and not dev, so I copied all the changes directly to the dev branch and added you to the contributors list of the next release.
Testing and all seems good :)
(closing the PR)


Proper way of bundling rust-ffi WASM file in both ydoc-server (launched on electron "client" side) and gui2 (in browser).

After merging #8893 the rust-ffi is used by both ydocs server and gui2. These two projects are run in different environment - ydocs server is run in node, by electron's client, the second is loaded in electron browser. This makes some problems:
The WASM is compiled with --target web option, which by design is not suitable for running in node. We still can use it in none, but have to load the file manually. Currently, we have hard-coded path pointing to gui2 assets, what is very bad, because that path may change every time WASM file changes.
Moreover, the WASM is also used in tests and dev runs, where the path will differ.
We should make some reliable way to load and initialize Wasm package in both (all three, if include dev/test) environments.

Let's do it after removing GUI1 and cleaning repo a bit (#8484)

What we want to achieve?

First, remove any hard-coded paths to assets if possible
Then, perhaps we could change build target to no-modules if  time allows.


Can't understand how to add multiple validators

I'm playing with the Repl on svelte site and I can't understand 3 things
1°) If I use the default code I don't have any error displayed for 5 minimal  characters.
2°) If I remove the comments and have the
 const form = useForm({
	// 		minimalExample: { validators: [minLength(5)] }
	// })

I got the error if entered less than 5 char
3°) I can't find a way of adding a second validator for example maxLength = 15

Ok, you are right, the problem was I was waiting for a message without getting out of focus from the input....
And for the maxLength, I didn't add the on="maxLength" on the Hint.....
My Bad....


TILA-254 display events inside accordions

also changed getting of reservation unit data so that only the required data is retrieved
handling of null values

Looks good, but maybe we should wait for https://github.com/City-of-Helsinki/tilavarauspalvelu-ui/pull/17 to clear before merging this.

Looks good, but maybe we should wait for https://github.com/City-of-Helsinki/tilavarauspalvelu-ui/pull/17 to clear before merging this.


Fixed unrecognized Jira request types problem

Fixed an issue where if a Jira request type is unrecognized, the whole API call will crash out.
Instead, this PR implements a way to gracefully handle an unrecognized value by filtering null types.

#2061  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @tommylau523 and the rest of your teammates on  Graphite

Merge activity

Jun 13, 5:05 PM EDT: @tommylau523 merged this pull request with Graphite.


Use Vanilla Cherry Grove Biome

Use minecraft:cherry_grove instead of terraformgenerator:cherry_grove in 1.20

So you means you need to use custom biome features like custom sky color and custom water color?
I just think the advancement "Adventuring Time" cannot be achived if there is no vanilla cherry_grove biome.
Maybe I can write a datapack to override that advancement.

It’s because custom biome registration happens in a specific way and I was waiting for 1.18/1.19 support to be culled before removing the custom cherry grove.
Is that andvancement achievable already despite the cherry groves? I don’t think the plugin actually uses every biome

Okay, the plugin doesn't use every biome that the advancement needs. Also, I didn't change all the code correspond to cherry grove, for example, cherry grove beach. Maybe I should close this pull request.
I'm going to write a datapack to fix this.


New StrictlyPositiveNumber type

Description
We would like to add a StrictlyPositiveNumber type representing strictly positive numbers.
This new type should also be serializable.
/** Represents a strictly positive number. */
sealed interface StrictlyPositiveNumber<out N : Number> {
    /** The value of this number. */
    val value: N

    /** Returns the string representation of this number. */
    override fun toString(): String
}

/**
 * Returns this number as an encapsulated [StrictlyPositiveNumber] of type [N],
 * which may involve rounding or truncation, or returns an encapsulated
 * [IllegalArgumentException] if this number is negative.
 */
fun <N : Number> N.toStrictlyPositiveNumber(): Result<StrictlyPositiveNumber<N>> = TODO()

Checklist

[ ] Implement the type with its builder.
[ ] Make the type serializable.
[ ] Test on all platforms.
[ ] Refactor.
[ ] Update the Unreleased section in changelog.

We will not implement this new type for now.


Observable modified Condition/Decision coverage

http://dl.acm.org/citation.cfm?id=2486803

Proprietary data. Do not think it can be made public


fix: keyippo.authenticate now returns an authenticated supabase client

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 83.25%. Comparing base (cc43985) to head (338fb06).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #27      +/-   ##
==========================================
+ Coverage   82.73%   83.25%   +0.51%
==========================================
  Files           3        3
  Lines         388      400      +12
  Branches       70       70
==========================================
+ Hits          321      333      +12
  Misses         67       67

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


14405 replicas

Hey one thing I found is that the various implementations of ReplicaSet and ReplicaList (immutable, singleton) don't handle equals and hash code correctly.
You probably want an AbstractReplicaSet and AbstractReplicaList with no storage that define how equals (against any derived class of AbstractReplicaSet or List depending).

Uh I may have brain farted there. I don't think there is an issue.

I'm not totally crazy. I added a ReplicaSet.of method and when I call it I get Replicas.of instead which is a little nuts.
What I don't get is I am explicit invoking ReplicaSet and it's a static method! This is some of the craziest language behavior I have ever seen.

bq. You probably want an AbstractReplicaSet and AbstractReplicaList with no storage that define how equals (against any derived class of AbstractReplicaSet or List depending).
fixed, moved equals and hashCode up to base class

Reminder we wanted to disallow the creation of transiently replicated keyspaces in mixed version clusters.

Can we get more thorough tests for Replicas, ReplicaList, and ReplicaSet. I'm not looking for 100% coverage, but things like equality and hash code, order sensitivity of hash code output and equals results.
ReplicaList, containsEndpoint, filter, intersect, subList, normalizeByRange (I am not sure this is equivalent to Range.normalize they look very different).
Then tests for methods in Replicas like containsEndpoint.

Some test failures https://circleci.com/gh/aweisberg/cassandra/1223#tests/containers/60
https://circleci.com/gh/aweisberg/cassandra/1225#tests/containers/46
The dtest failure I suspect is it failing to notice the node move and push the notification. I haven't run it multiple times yet to see if it is flakey or not.

ReplicaSet can be a map from endpoint to replica, which might help with both iteration and access to endpoints
Should it be keyed by endpoint or range? I don't think what we want is consistent.

Additional note, forbid the use of counters with transient replication?


feat: add missing TypeNode type guards

PR Checklist

[ ] Addresses an existing open issue
[ ] That issue was marked as status: accepting prs
[x] Steps in CONTRIBUTING.md were taken

Overview
Type guards for TypeNodes.

Marking as blocked on #51

oops. I didn't check if these were all already defined in ts itself.

Closing for now.
Once #51 is resolved, if needed the changes can be remade in a new PR.


Please add AS0051

Please add rule AS0051: The property 'contextSensitiveHelpUrl' must be specified.

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

ID: 03cc1f40-cea7-5449-10a6-9736f9713c53
Version Independent ID: afcd6e13-c135-08ba-f973-cab671fb579c
Content: AppSourceCop Analyzer - Business Central
Content Source: dev-itpro/developer/analyzers/appsourcecop.md
Service: dynamics365-business-central
GitHub Login: @solsen
Microsoft Alias: solsen

Thanks for the feedback. We've just updated the analyzer rulesets including the appsourcecop.


Does it work on Linux

Cannot get it work on Ubuntu 16.04 LTS neither on cygwin
But works fine on Windows 10
Error :
me@my-ubu1604lts:~/gimme-aws-creds/bin$ ./gimme-aws-creds
Traceback (most recent call last):
File "./gimme-aws-creds", line 13, in
from gimme_aws_creds.main import GimmeAWSCreds
ImportError: No module named 'gimme_aws_creds'

If you installed gimme-aws-creds with pip3 or python3 setup.py install, the executable should have been installed as /usr/local/bin/gimme-aws-creds. Can you try running it from there and see if that fixes the error?

Dropping the ./ from your execution command will cause the OS to search your path for the executable, instead of trying to execute from the local folder.

Hi,
I ran : python3 setup.py install
then I got :
...
Installed /usr/local/lib/python3.5/dist-packages/python_dateutil-2.7.2-py3.5.egg
Searching for cryptography
Reading https://pypi.python.org/simple/cryptography/
Best match: cryptography 2.2.2
Downloading https://files.pythonhosted.org/packages/ec/b2/faa78c1ab928d2b2c634c8b41ff1181f0abdd9adf 9193211bd606ffa57e2/cryptography-2.2.2.tar.gz#sha256=9fc295bf69130a342e7a19a39d7bbeb15c0bcaabc7382e c33ef3b2b7d18d2f63
Processing cryptography-2.2.2.tar.gz
Writing /tmp/easy_install-yrz9i9tk/cryptography-2.2.2/setup.cfg
Running cryptography-2.2.2/setup.py -q bdist_egg --dist-dir /tmp/easy_install-yrz9i9tk/cryptography -2.2.2/egg-dist-tmp-ghj0n4ki
c/_cffi_backend.c:15:17: fatal error: ffi.h: No such file or directory
compilation terminated.
error: Setup script exited with error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
After installing libffi-dev on Ubuntu using apt (libffi-devel for RHEL) and I ran again
I got this :
...
Installed /tmp/easy_install-rh9p9rys/cryptography-2.2.2/.eggs/pycparser-2.18-py3.5.egg
/usr/lib/python3.5/distutils/dist.py:261: UserWarning: Unknown distribution option: 'python_requires'
warnings.warn(msg)
no previously-included directories found matching 'docs/_build'
warning: no previously-included files matching '*' found under directory 'vectors'
build/temp.linux-x86_64-3.5/_openssl.c:493:30: fatal error: openssl/opensslv.h: No such file or directory
compilation terminated.
error: Setup script exited with error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
Then I apt libssl-dev, ran pip3 install and could see many warnings till got :
...
Installed /usr/local/lib/python3.5/dist-packages/cryptography-2.2.2-py3.5-linux-x86_64.egg
Searching for jeepney
Reading https://pypi.python.org/simple/jeepney/
Best match: jeepney 0.3.1
Downloading https://files.pythonhosted.org/packages/18/17/7dbc70bc13dc9c8ba8c9b25fbc8b75dffb6bc7e56c3d7cecd87e6b563e5f/jeepney-0.3.1.tar.gz#sha256=a6f2aa72e61660248d4d524dfccb6405f17c693b69af5d60dd7f2bab807d907e
Processing jeepney-0.3.1.tar.gz
Writing /tmp/easy_install-rxzl1zhl/jeepney-0.3.1/setup.cfg
Running jeepney-0.3.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-rxzl1zhl/jeepney-0.3.1/egg-dist-tmp-58z4flvf
/usr/lib/python3.5/distutils/dist.py:261: UserWarning: Unknown distribution option: 'python_requires'
warnings.warn(msg)
error: Setup script exited with error: can't copy 'jeepney/integrate': doesn't exist or not a regular file
So I ran :
sudo pip install jeepney
sudo pip install cryptography
sudo pip install docutils
And finally I could get it work.
I think you should include more requirements from my experience : trying to run gimme-aws-creds from a fresh Ubuntu server (apt-g update && apt-g upgrade done before cloning gimme-aws-creds)
Thanks,

I noticed this yesterday on a fresh Ubuntu 16.04 installation, except in my case all I needed was libssl-dev.
We can do more testing, but the dependency chain should be taking care of all the dependencies.  We don't directly reference jeepney, cryptography, or docutils in our code.


Extended Window functionality with additional buttons

Description of the new feature / enhancement
One of the most desired features is "always on top" is (#13) and it seems we might get this in the not so distant future. We will be sooooooooooo happy when this feature comes to us...!!!
However, what about some other useful functions such as

Minimize to tray
Roll-up to Titlebar
Make window transparent (incl. click-transparency)
Highlight window with coloured frame
etc.

These functions are contained in DesktopFusion for example and simple programs from the old days, such as eXtra Buttons, had similar features.
Wouldn't that be a wonderful feature extension for PowerToys? Windows should have this natively, but that's a different story. Are there any plans to extend window functionality and handling by any of those tools...?
Does anybody know any free legacy tools such as eXtra Buttons which still work with Win 10 (and possibly Win 11)?
Scenario when this would be used?
During everyday use.
Supporting information
No response

Thanks for your suggestions. I think some of them have been mentioned already, but that's okay.

This is multiple features into one.  Due to this, I'm going to have to close this.  Example, Roll up + min to tray are different and neither exist


Cannot Download and use the CopyMove.zip from the Baidu Cloud Link

The CopyMove.zip folder in the Baidu Cloud Link is corrupted. Cannot extract the Copymove images. Can you fix the CopyMove images?

Hi, it's not corrupted. Maybe try it again when your network connection is stable.


Q4 goal: Integrate BinderHub into JupyterHub (funded by GESIS)

Technical Progress
These are broad outcomes of technical progress that need to happen for smoother UX. We currently have code that is decent demo quality, but needs to get closer to production quality

[ ] Complete productionizing @jupyterhub/binderhub-client JS library and release on npmjs, so we can use the same code as binderhub for talking to the binderhub API
[ ] Get jupyterhub-fancy-profiles to a first release, including deployment on at least one other hub that does not use binderhub building (to make sure it is a broadly useful project)
[ ] Make sure auth works ok, so arbitrary users who are not authenticated with the JupyterHub can not use the binderhub API to autobuildi

Out of scope items
Since work will continue in Q1, the following items are explicitly marked as out of scope for Q4.

URL compatibility with mybinder.org, so users can more easily shift
Options for figuring out how to expose the content of the repository to the end user on their home directory in a persistent way.
Long term planning for where binderhub-service and jupyter-fancy-profiles repo live. There is ongoing conversation in the jupyterhub community about a jupyterhub-contrib org, so let's wait on that.

Deploy this on non-2i2c infrastructure
We need to make sure that all this work is not 2i2c specific. While the tech work has proceeded in a non-2i2c specific way, we currently don't have any deployment of this outside 2i2c infrastructure. This means there isn't clear step by step documentation on tying together the three projects (z2jh, binderhub-service, jupyterhub-fancy-profiles) that make this workflow possible.
We work potentially with Sima Attar to get a deployment running elsewhere - either on GCP (we have funding to setup a spare project) or on other infrastructure they have access to. The outcome of this is documentation that can be followed by anyone to set this up.
Write a blog post about this complex yet 'upstream first' process
There's been a lot of work done in making this goal possible, spread out across multiple projects - kubespawner, binderhub, zero-to-jupyterhub-on-k8s, repo2docker, jupyterhub-fancy-profiles, etc. For organizations approaching contributing major features to an open source ecosystem, this can be quite daunting! So we write a blog post describing how we did this, including the exporation paths that didn't go anywhere.

Hi @yuvipanda, I might be able to help with the deploy on non-2i2c infrastructure. Can you point me to where I can start?

I had a nice conversation with Sima a few days ago, and we're working on getting this all set up on GCP. I've given her access to the earlier GCP project we used for testing (binderhub-service-development I think), and are going to take it slow :)

Would love for you to try it out too, @rgaiacs

We probably should also add documentation, for users and admins. Having documentation is also relevant for the NFDI and CESSDA to allow them to deploy this.

Some next steps from chatting with @arnim:

Write a 'status report' blog post for the 2i2c blog, with a focus on all the upstream work that has happened: https://hackmd.io/hiPdQpL7ScC6_IHopInf0A
Figure out what would be useful to post to the Jupyter blog - particularly, the fact that we had to thread the needle via many parts of the Jupyter ecosystem to get this to happen.
Cleanup some issues for a demo @arnim is giving on Nov 23.

Thank you @yuvipanda .
These next step are perfect 👍

As an update, Sima has spent some time getting acquainted with GCP and set up a z2jh there to test (https://2i2c.slack.com/archives/C03RLNFM43F/p1699262794125269).
Next step is to try deploy binderhub-service there alongside.

Just had a meeting with @simaattar2003 on the deployment.

We've done a lot this quarter!

We published https://2i2c.org/blog/2024/jupyterhub-binderhub-gesis/, which lists all the work that has happened through this grant. Thanks to everyone for their review!
We have a working demo at imagebuilding-demo.2i2c.cloud, and folks have been testing it out.
There's now a npm package for binderhub-client that's upstream
I've been working with @simaattar2003 via video calls, creating documentation for recreating this setup elsewhere. This is ongoing work.

I'm going to close this out, and create a new issue for Q1 2024. Thanks everyone.


Name constructors in obj.js.

#791

hi @kkujala , this patch looks good, but there was some misunderstanding :(
For my comment in https://github.com/mozilla/pdf.js/pull/793#issuecomment-3038671, I intended to say "don't worry if you end up with one big patch", but I still was agreeing with Artur. We should do this renaming stuff in one patch, that makes the refactoring like you have done it for obj.js for all files in the PDF.JS repo.
I'm so sorry that this wasn't that clear and I try to do better in the future.
Do you mind doing the constructor refactoring for all the files in the PDF.JS repo at once? If you are pissed because of me (and I understand if you are!) let me know and I take over the job, if you don't want to do it anymore.
You're doing an awesome job and I hope you feel how sorry I am for this and I just don't want to loose you as a core contributor to the team :(

@jviereck, I was a bit puzzled about that big patch thing. And really, I have no bad feelings. Maybe I was a bit annoyed to do exacly same patch as before. And reaching a consensus do take some time I guess due to different timezones..
Thank you for your kind words! I do appreciate them :)
The good thing is that doing this change in a one big go forced me to automate this as far as possible. Shell script + sed + grep did wonders.

Patch looks good + tests all pass: +1 from me.


NTR: [Stalled ribosome sensor activity]

Hi GO,
I would need a term to describe proteins that sense stalled ribosomes. 2 proteins have now been identified that directly sense stalled ribosomes and trigger a response (MAP3K20 and GCN1)
Thanks
Sylvain
Name: Stalled ribosome sensor activity
Category: Function
Definition: A molecule that recognizes stalled ribosomes and initiates a signalling response.
Child of GO:0043022 ribosome binding
PMID:32610081
PMID:32289254
PMID:36638793

Hi @edwong57,
Any news on this request? I discussed with Paul Thomas and Pascale and we agreed to create this term (although we would like to represent these sensors in a different way in the future)
Thanks
Sylvain

@sylvainpoux, I'll work on it today.


Segmentation Fault phyml

running in quay.io/biocontainers/snvphyl-tools:1.8.2--pl5262h779adbc_5
. PhyML needs at least three sequences to perform an analysis./data/jobs_directory/000/146/tool_script.sh: line 22:    23 Segmentation fault      (core dumped) phyml --input 'snvAlignment.phy' '' --datatype 'nt' --multiple '1' --bootstrap '-4' -t 'e' --model 'GTR' -f 'm' --pinv 'e' --nclasses '4' --alpha 'e' --search 'BEST' -o 'tlr' --r_seed '0' --no_memory_check > '/data/jobs_directory/000/146/outputs/galaxy_dataset_86b13ec3-088c-42f6-9183-d1a03aca7826.dat'

Thanks for pointing this out. I am aware of this issue. You have to run SNVPhyl with at least two input samples to successfully complete the analysis (2 input samples + reference genome = 3 genomes total for building a tree).


Add noirVersion to Noir circuits

This PR updates all of our current Noir circuits (both in circuit_database/ and in circuit_tutorials/) to include the new field from the Sindri manifest: noirVersion.  This field allows users to specify whether we should apply the Noir prover version [0.17.0, 0.18.0, 0.19.4, 0.22.0, 0.23.0].  This is the first of two PR's that patches our existing circuits, which have been assuming the 0.17.0 prover version.  The next PR introduces more circuits of other versions - see #70
Reviewer Testing:

[ ] For each compressed circuit in circuit_database/noir, submit to the frontend (stage server) and ensure compilation is successful:

[ ] not_equal.tar.gz
[ ] not_equal.zip
[ ] decision_tree.tar.gz
[ ] decision_tree.zip
[ ] billion_zk_vote.tar.gz
[ ] billion_zk_vote.zip

[ ] Ensure the sindri.json file at circuit_tutorials/noir/pagerank/circuits has a field for the noirVersion and that it is set to 0.17.0

Note that lint was expected to fail.  The lint test hits our production server, which does not have this new field deployed yet.

Giving credit where it's due - @stasiacarson found a missing field.  Addressed in this commit: https://github.com/Sindri-Labs/sindri-resources/pull/71/commits/4d6c5b8bf5ad39640e75147cae5576344f3727bc


Scope: Use Rust apps?

Cosmic is a very new desktop and very bare bone.
But it is programmed in Rust.
Should the scope of the project recommend native rust apps to be included?
Example this flatpak as foto manager
https://flathub.org/apps/app.fotema.Fotema
Suggestion:
Change scope to reflect the preference of rust apps over Gtk or QT apps
if a similar functionality can be achieved with a rust counterpart.
Cosmic native > rust app > Gtk app or Qt app.
If this change is accepted I can take the time to find recommendable rust apps native and flatpak.

I think this would be part of a larger question about this image. Do we want this image to only provide the COSMIC desktop, or do we want this image to be a more opinionated experience akin to Bluefin and Aurora?
I personally think that the base cosmic image we provide is important for further downstreams to use, since Fedora doesn't have a COSMIC base image; however, I also think it'd be nice for us to in addition provide an opinionated image with a full experience, which could definitely include rust applications.

I personally think that the base cosmic image we provide is important for further downstreams to use, since Fedora doesn't have a COSMIC base image

I completely agree.  We should be treating this image as if it were provided by Fedora, then the opinionated changes will be added downstream (for example in Bazzifin) or external custom images.

My current plan is to only install COSMIC community apps that have flatpaks with Supernova but I'm still working on figuring out the build system and such.

I have a few open thoughts on this and would like to share them.
I think a middle ground between bare bone and opinionated.
Basically offer OOTB experience for the most important tasks.
Photo
Video
Music
Web
File Management
With a little bit of opinionated changes like
blueman for bluetooth
network manager gui
Pipewire gui
Archiv manager
This way the image stays bare bone but it also offers needed base functionality until cosmic integrates these features.
Try to send a file via bluetooth.
Try to change the bluetooth profile of headphones.
Try to change the firewalld zone for an interface.
Try to set a default file association for xyz.
...
their is barebone and their is barely useable.
Cosmic as alpha is the later. And that is okay and to be expected.
Is every downstream project supposed to layer the same base packages for base functionality?
What should be added is the gnome keyring.
At least until cosmic offers an integration or an own implementation.
Because without it apps start to save login details in a non favourable manner. (gnome keyring is not auto unlocked atm, even if pkgs have been added).

The network parts should land soonish though I also don't know about including somethings since COSMIC hasn't had it's first release yet.

My current plan is to only install COSMIC community apps that have flatpaks with Supernova but I'm still working on figuring out the build system and such.

Just in case you want to check out bluebuild for your image.
You can take a look at my repo.
https://github.com/idnovic/secureblue-extended
https://blue-build.org
My image is very customised but I use nearly every feature of the build system.
Took me a few days to sort everything out.
I can recommend blue build for personal images over upstream buildha + podman.
That said I decided to keep gnome for the moment and follow cosmic desktop development.

My image is forked from the cosmic image but once it is all in Fedora 41 I plan to use the template from ublue instead I think. It seems to be updated and better supported for features.

I agree that this image should be a vanilla Fedora COSMIC experience. Having it opinionated on top of a brand new DE may be too much. Personally, I'm using the Pop!OS alpha and vanilla COSMIC alpha on top of Fedora 40 right now and it's pretty great as is. It's going to be even better when it's actually done.


Permanently borders only turn on if you mouse over each token

When the Permanent Borders setting is turned on, it only shows no borders on login, refresh or scene switch until you mouse over a token. Each token you mouse over gets a border that stays on permanently but every other token doesn't have one.
I would expect them to all be on constantly with this feature.
Foundry: 10.291
DnD5e 2.1.5
Border Control 2.0.2

I close this ticket beacuse is referenced to the v10 and there is anotehr ticket about this for v11, the sad truth is i cannot solve this on v11 either


[parquet-thrift] improve performance of thrift push-down code

A user reported seeing slowness when projection push-down code is active, which seems to stem from ProtocolEventsAmender.
Details can be found in https://github.com/Parquet/parquet-mr/issues/406
Reporter: Dmitriy V. Ryaboy / @dvryaboy
PRs and other links:

GitHub Pull Request #7

Note: This issue was originally created as PARQUET-7. Please see the migration documentation for further details.

Dmitriy V. Ryaboy / @dvryaboy:
playing with the code, starting to think that:

my suggested fix won't work because events are accumulated as an individual struct is read
slowness is likely do to the deep stack of protocols for nested structures. For each record, testThriftOptionalFieldsWithReadProjectionUsingParquetSchema applies 24 protocols!
perhaps the way forward is to look at generating a single protocol that can apply all of the required transformations, rather than delegating through so many protocols?

Dmitriy V. Ryaboy / @dvryaboy:
That rabbit hole went deep, and undoing the protocol stacking (if indeed it's a problem) would be a huge undertaking.
In the meantime, I created a small patch to address the case of thrift objects where no fields are required.
https://github.com/apache/incubator-parquet-mr/pull/7


Update & Delete can't store to mongoDB

I have a problem, when processing update & delete can't store to mongoDB

Can you give more details?

var Schema = mongoose.Schema;
var dataTables = require('mongoose-datatables');
var mongooseHistory = require('mongoose-history');
// create a schema
var restaurantSchema = new Schema({
restoName: String,
restoPic: String,
phone: String,
address: String,
categoryID: {type: Schema.Types.ObjectId, ref: 'categoryRestaurant'},
map: { lat: Number, long: Number },
sumOfTable: Number,
ownerID: {type: Schema.Types.ObjectId, ref: 'user'},
});
restaurantSchema.plugin(dataTables);
restaurantSchema.plugin(mongooseHistory);
global.Restaurant = mongoose.model('restaurant', restaurantSchema);

The problem happens when you

@nassor I have the same problem. The plugin correctly creates an initial mongo schema and document when I call .create(), but when I call findByIdAndUpdate() it does not register the changes.

@nassor ah, I see that findByIdAndUpdate makes a call directly to the db and by design does not trigger the pre-save hook. I have updated my code to use findById and save instead to work with this code.


Tooltips!

Being able to set custom tooltips for widgets would be cool

haha it really would...

@Vermoot
https://elkowar.github.io/eww/widgets.html?highlight=tooltip#widget

I've started using :tooltip , but I'm unsure how to style this with GTK CSS ...
Mine show up as white text with no background colour, which is fine expect when the window underneath them is also white (hard to read)
Is there an example of GTK CSS that styles the tooltip?

I believe the :tooltip property is used only to set the content of the tooltip on a widget. However, what's gonna show is just a regular tooltip styled by your current gtk theme, not your eww css file.
Someone correct me if I'm wrong.

Oh, this is promising...
This setup has tooltips with no background:
* {
  all: unset;
}
.bar {
  background-color: #000000;
}

This setup has tooltips with a black background:
* {
  all: unset;
  background-color: #000000;
}
.bar {
}

I just wish I knew a more specific selector for tooltips, but this will work for now

I just wish I knew a more specific selector for tooltips, but this will work for now

Well,
tooltip {
  background-color: black;
  /* ... */
}

works (tooltip here references all GtkTooltip widgets). Not sure if you can change a specific widget's tooltip tho.
.widget tooltip {/*...*/}
.widget > tooltip {/*...*/}

both do not work

I just wish I knew a more specific selector for tooltips, but this will work for now

Well,
tooltip {
  background-color: black;
  /* ... */
}

works (tooltip here references all GtkTooltip widgets). Not sure if you can change a specific widget's tooltip tho.
.widget tooltip {/*...*/}
.widget > tooltip {/*...*/}

both do not work

Also you can use
* {
  all: unset;
}

To void the gtk theme and style from scratch if you want to.
And @Vermoot could you close this issue as it is fixed

Optimally there'd be more than just the tooltip attribute, it would be nice if you could actually have a fully custom widget rendered as a tooltip. That's definitely not implemented yet

Yeah, I don't think this issue is ready to be closed yet. My initial idea (which was critically under-explained...) was to be able to have a widget rendered as a tooltip on hover, in place of the default, text-only tooltip.
Additionally, but I don't think this is in the scope of this issue, it would be nice to be able to create a new window with a position relative to a parent window. Think calendar widget appearing next to the clock in a bar when you click it. I'd prefer not to have to hard code the calendar window's position, but have it tied to the clock widget.

Wouldn't that relative window pretty much exactly be the tooltip we want, just manual? Seems like it fits

A tooltip to me is just something that appears on hover, and disappears on un-hover.
What I'm talking about would be more akin to a network menu in a taskbar. Something that would appear when you click on a widget, and disappear when either clicking on that again, or closing it with a button, or even clicking elsewhere in a neutral zone


[FEATURE] Caching

Requirements
Research a solution for client-side caching of flagd.
The caching solution should be implemented in flagd providers. Avoiding creating any issues in the provider repositories until a solution is found.

Can you elaborate a little more? I thought that react+redux would be adequate for caching client side requests?

Can you elaborate a little more? I thought that react+redux would be adequate for caching client side requests?

This is following on from https://github.com/open-feature/flagd/issues/159. By client I don't necessarily mean a browser client, this would be useful at the provider level to avoid making superfluous calls to flagd.
e.g.

Wouldn't the caching be in the SDK then rather than flagD?
For example, in the SDK you could do something like...
	// Create a cache with a default expiration time of 5 minutes, and which
	// purges expired items every 10 minutes
	c := cache.New(5*time.Minute, 10*time.Minute)

	// Set the value of the key "foo" to "bar", with the default expiration time
	c.Set("foo", "bar", cache.DefaultExpiration)

	// Set the value of the key "baz" to 42, with no expiration time
	// (the item won't be removed until it is re-set, or removed using
	// c.Delete("baz")
	c.Set("baz", 42, cache.NoExpiration)

	// Get the string associated with the key "foo" from the cache
	foo, found := c.Get("foo")
	if found {
		fmt.Println(foo)
	}

An example from go-cache.
I won't remark much more until it's clear whether this is an SDK proposal change or flagD.
If it's in flagD there would be a number of issues around caching lifecycles across sync_providers as well as data going stale on updates ( especially with the informer based update system within k8s )

As you remarked, a caching system using expiration would result in stale data on configuration changes. I created an issue for the proposal change here rather than the provider/sdk to research whether there's a more robust solution that can bust the cache on configuration changes.

On the other hand it might be trying to solve a problem that doesn't exist.
The latency to flagD is going to be 1-2ms, and the CPU overhead can be throttled with container resource limits.
If the host process is calling flagD often you could argue that those calls might incur some small penalty, but none that would significantly impact performance.
Is there a particular use case you're thinking of here?

As todd mentioned previously in this issue 30% of vendors flag evaluations come directly from the browser, these evaluations will commonly be involved in UX / layout configurations that will likely be reevaluated on every page load. I believe its in this usecase that caching will be a powerful tool, especially considereing that we will go from 1 to n number of open connections at a time.
As for cache busting im currently looking into 2 different implementations of flag update subscriptions, one will reevaluate the given flag and return the new value, however the other will be an non specific signal to indicate that there has been a configuration change, this could be used as the indicator to bust the cache as we can be confident that until we see this signal that the evaluation result will always be the same (provided the context being passed matches). At least it should be a little cleaner than a time based implementation.

I would expect caching to be handled within the SDKs. I don't see any reason to add caching to flagD at this time.

After seeing @james-milligan's work on event subscription I think a more thorough caching mechanism should be revisited once that work is complete as it could solve the cache busting problem. In the meantime it could be worth implementing a naive expiration based cache mechanism in the provider. I'm leaving the results of my research below anyhow for reference.

This redis doc describes the problem eloquently.
flagd flag evaluation operations are pure functions. Any evaluation always produces the same result, at least until the flag configurations are changed. Therefore we can store the result of the flag evaluation in the client and keep using it until the flag configuration is changed. On mutation of the flag configuration flagd can emit an event to notify subscribers to invalidate their cache store (important to avoid stale data).
This would require changes in flagd to notify subscribers on configuration change.

Closing this as complete, notifications are now exported to the flagd provider via the event stream which will allow for cache busting in a client side caching implementation
https://github.com/open-feature/flagd/pull/187/files


Handling "stale" ability on socket connection

This might just be a documentation thing, but I thought I'd share because it was not obvious to me.
When setting up the ability as demonstrated in the docs -- attaching it to params after authentication, it seems that ability will only be updated when a new connection is established by the client.  This can lead to confusing permission errors that then disappear on a page refresh.
At least I'm pretty sure that's what's happening.
I can workaround this issue by defining service-level hooks that remove context.params.ability then create a new ability with authorize({ ability: context => createAbility( ... ) })
To make this workaround easier, I wonder if the authorize hook should prefer to use its ability parameter over context.params.ability?  That would make sense to me since more local/specific is typically how an override is done, but if you don't want to break the current behavior, maybe just a flag?  Is there another way to handle this?
Thanks!

Hey, sorry for the delay again!
I don't get it. What do you mean with the following?

it seems that ability will only be updated when a new connection is established by the client

No worries!
tl;dr:  If your ability might change due to some user interaction, the current example setup in the docs will not work nicely with the socket.io transport.

By "new connection" I meant the socket connection, but re-reading what I wrote above, I don't think that I did a very good job explaining the issue, so I'll try again with a bit of context :)
My ability factory function sometimes needs additional data to determine permissions.  For example, Users may have Teams and they might have different permissions based on their Role in that team.  Users may change or leave their Team at will.
We have a React client and use the socket.io transport for pretty much everything.
The "confusing permission errors" that I was referencing above happened when a User would leave or change a Team -- we could confirm that the change was persisted to the db, but the new data wasn't being used by the authorize hook.  The most confusing part was that refreshing the page fixed the issue since the client shouldn't be able to affect its server side permissions object!
Eventually, I realized that the reason refreshing the page "fixed" the issue is because we were re-establishing the socket.io connection and making another call to the authentication service, which would build the new ability correctly.
So, it seems that the authentication service is only called once for the socket, and the ability is only created once.  If your ability needs to change based on some user interaction with the app, then it needs to be attached to the request context somewhere else that will definitely get called per-request.   That's the thing that was not obvious to me and might be nice to make a little note about in the docs.

Sorry for the noise of stale bot. Hope I got this fixed now.
I want to support this, at least write a cookbook recipe in the docs.
@robbyphillips  How did you fix this for your application?

It's a bit of kludge, but I'm really just stripping the default ability and recalculating it for every request on affected services.
// service-with-dynamic-permissions.hooks.ts

// remove the default ability
const resetAbility = (context: HookContext) => {
  delete context.params.ability
  return context
}

// just a convenience wrapper
const makeAuthorize = () =>
  authorize({
    availableFields, // defined above somewhere for this service
    ability: getAbilityWithContext // ability factory
  })

export default {
  before: {
    all: [
      authenticate('jwt'),
      resetAbility
    ],
    find: [makeAuthorize()],
    get: [makeAuthorize()],
    create: [makeAuthorize()],
    update: [makeAuthorize()],
    patch: [makeAuthorize()],
    remove: [makeAuthorize()]
  },

  after: {
    all: [makeAuthorize()],
    find: [],
    get: [],
    create: [],
    update: [],
    patch: [],
    remove: []
  }
  // ...
}


undefined reference to __imp_F on Windows

As discussed on Zulip.

Partially fixed in 334e4e5 using moreLeanArgs in the executable package.


Typo in Examples Section

Looks like the "Examples" section contains two copies of the same paragraph and example block.  Copy and paste error?

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

ID: 4fc4b490-cde5-22d7-4f47-26c2ad2e1032
Version Independent ID: 5edcf35b-4224-e0e2-2bc4-cc599681ef7e
Content: RequestOptions.PartitionKey Property (Microsoft.Azure.Documents.Client)
Content Source: xml/Microsoft.Azure.Documents.Client/RequestOptions.xml
Service: cosmos-db
GitHub Login: @erickson-doug
Microsoft Alias: douge

Closing this out;  I'm no longer seeing duplication in the examples.   Please feel free to reopen if you believe that further discussion is needed.


Revise UnitButtons logic and themes

Cooldown indicator is now rendering correctly.
Is the PR ready for review or is are you still working on it?

Is the PR ready for review or is are you still working on it?
It is ready for review

Found a bug. Extra space appears in ItemBar every time you move an item from ItemBar. Up to you if you want to fix before or after merging.

Found a bug. Extra space appears in ItemBar every time you move an item from ItemBar. Up to you if you want to fix before or after merging.

I will fix in my next PR


Feature + Fix

Hi,
While trying out your PIDctrl and comparing it with a version I wrote myself a few years back, I noticed that integral windup would still happen and affect the PID if the output just happened to keep within the min/max range.
Generated an example showing this, if you display the integral term values during the test, you will see what I mean.
Standard fix included.
Also a feature, where we can set OutputLimits in the same line as calling NewPIDController which is really useful if you want to put a ready to use PIDctrl into a struct.

@btittelbach makes complete sense, thanks for the improvements!


Add query_map with positional parameters to documentation

The current query_map docs don't actually show positional parameters:
let mut stmt = conn.prepare("SELECT name FROM people")?; // Zero parameters here
let rows = stmt.query_map([], |row| row.get(0))?; // Parameter array is empty

It should show:
let mut stmt = conn.prepare("SELECT name FROM people where name = ?1")?;
let rows = stmt.query_map(["terry"], |row| row.get(0))?;

Or:
let mut stmt = conn.prepare("SELECT name FROM people where name = :name")?;
let rows = stmt.query_map([(":name", "terry")], |row| row.get(0))?;

Or:
let mut stmt = conn.prepare("SELECT name FROM people where name = ?1")?;
let rows = stmt.query_map(params!["terry"], |row| row.get(0))?;

Or...
This is why there is a dedicated page for Params.

Gotcha. In that case the query_map could link to that params page, instead of showing its own versions of named params, etc.

But there is already such a link to the Params page...


Our packages are running on Travis legacy infrastructure

Hi,
Some of you noticed the warnings on Travis-ci saying that our packages are running on the legacy infrastructure.
According to the documentation (http://docs.travis-ci.com/user/migrating-from-legacy/?utm_source=legacy-notice&utm_medium=banner&utm_campaign=legacy-upgrade), the sudo command is not supported anymore in the new infrastructure for the time being.
They suggest a work around for that. Let's say, if you want to download and install cmake in your build,  "just" add the following lines in the .travis.yml.
addons:
  apt:
    packages:
    - cmake

So, there is an effort to upgrade our travis.yml files.
I'm creating this issue just to keep track this activity.

Just to complement this issue,
André suggested to transfer of the deployment on pypi and the upload of the documentation to pythonhosted using this feature of travis-ci ( https://docs.travis-ci.com/user/deployment/pypi )
Using this feature we can reduce the amount of tasks that the bob_new_version does (https://github.com/bioidiap/bob.extension/blob/master/bob/extension/scripts/new_version.py) and improve the way that we manage our pypi packages.
Today if a newcomer wants to generate a new release of a package on PyPi, someone needs to grant access to him/her by hand (most of the time we need to ask him/her to create pypi account). Usually we do this for all packages (we have more than 50).
With this feature in place everyone granted in the bioidiap group can tag the package and the deployment is done automatically (after the tests on travis-ci).
It is a good idea

I am not sure that uploading packages and docs from PyPI is a very good idea. I would like to keep things under control. For me it happened some times lately that the Idiap wheel server was not responding, or similar. In this case. it would upload a documentation that might be corrupt.
For the PyPI packages, I also see that we have an issue there, and I also use to forget to grant write access to other members. However, a solution could be to have a shared "idiap" user on PyPI, and to modify the ~/.pypirc (where the actual PyPI credentials are stored -- in clear text by the way) to contain the "idiap" user and password. What do you think about this kind of approach?


fix(query): enabled reactivity fix

Status
READY/WIP
Description
Addresses the issue outlined in https://github.com/anymaniax/orval/issues/943

Thanks for this @BenGane. There is a difference with #931?

Thanks for this @BenGane. There is a difference with #931?

Yes, this one is making query enabled reactive, and #931 is making query parameters reactive. Not the same thing, and we use both patches currently.
I also wanted to give a little update that I've created a workitem for myself at work to go over all the issues PRs and make sure they are in a good shape so we can get them merged and get rid of patches that we use internally. It's in our quick&important project so it's likely I'll get to this pretty soon. Cheers!

oki thanks @Maxim-Mazurok!

Looks like conflicts need to be resolved...

@BenGane @Maxim-Mazurok where are we with this PR?

Hello, as I've mentioned in other issues I've been busy with other work, however the Orval PRs are next on my list, I'd expect to see some progress next week. Cheers!


Add support to list repos by org and user

Refer to issue #37
Added:
/orgs/:org/repos
/users/:username/repos

Org repos endpoint will return 404 if :org is not a user of type USER_TYPE_ORGANIZATION

Thanks!


Track time of last friars NCs

In each of the three level 6 zones, there's a "pity" version of each NC, that will show up 5 turns after the last one. That is, in the heart, if you encounter  "Moon Over the Dark Heart" on your 7th adventure in the zone, you'll encounter "Running the Lode" on the 12th at the latest.
This adds tracking for when we last hit a relevant NC in each of these zones.
Scripters or users can track their actual quest progress by checking the noncombatQueue of each zone (although a future PR could add some prefs for quest steps in each of these zones, and would piggyback nicely off of this), but this PR now gives them the ability to predict when their "pity" NC will show up.
Creating this as a draft because I am probably not going to write tests for this until late tomorrow, but I'd love to get some eyes on it in case this implementation is extremely silly.

@horrible-little-slime What's the situation here?

Alright this is failing tests and it seems to be that my cleanups doesn't work because AdventureSpentDatabase.setTurns fails if you don't currently have the turns set for that particular zone. I feel like we can nix that behavior and the world will be okay? But I'd also be very happy with another solution.


Rewrite of the tellstick module. It now uses a common base for all sh…

Description:
Rewrite of the tellstick module. It now uses a common base for all shared functionality.
The rewrite addresses a problem with the tellstick hardware dropping commands when too many simultaneous calls is being made from HA.
Also fixes a bug when the dim level was changed externally.
This breaks previous configurations.
Example entry for configuration.yaml
The new config for tellstick is
tellstick:
  signal_repetitions: X

Lights and Switches are detected automatically.
Sensors work like before because they do not share any functionality with the other devices and they also needs a complete other configuration.
TODO:
The telldus core support devices that take UP,DOWN and STOP commands as well, these are not mapped to any home assistant component. I don't have any of these devices so implementing them would be difficult. Also I don't know what component to map them to. Maybe we could have something similar to binary_sensor but for things that goes up and down?
Related issue (if applicable):
#422
Checklist:

[x] Local tests with tox run successfully.
[x] TravisCI does not fail. Your PR cannot be merged unless CI is green!
[x] Fork is up to date and was rebased on the dev branch before creating the PR.
[x] Commits have been squashed.

[x] New files were added to .coveragerc.

@stefan-jonasson The UP, DOWN & STOP commands are or where generally used with certain motorized projection screens.
A few where sold by Kjell & Co in Sweden under the brand Roxcore but are not sold anymore.
If memory serves me right they where mapped to UP, DOWN to roll in/out the screen with one command and STOP where only to stop in case you didn't want it to fully extend or similar.
I also heard from a colleague that they should be able to control som window blind with it but haven't seen that implemented.
How about implementing it in a smilar fashion as the MQTT Rollershutter?
One thing worth thinking about in this case is that in the case of a projection screen, DOWN is most likely equivalent to open/on, but in the case of blinds DOWN would most likely be equivalent to closed/on.

Just noticed that tellstick sensors are not part of this rewrite, is this on purpose?

After fixing the brightness comment I think this is good to go :+1:

Xz
Den sön 13 mars 2016 17:14Paulus Schoutsen<EMAIL_ADDRESS>skrev:

After fixing the brightness comment I think this is good to go [image:
:+1:]
—
Reply to this email directly or view it on GitHub
https://github.com/balloob/home-assistant/pull/1529#issuecomment-195988464
.

The None for brightness is already fixed, your comment was on the wrong line.
About sensors, as I said in the description, they are intentionally left out of this rewrite because they do not share any functionality. Do you think it would be less confusing for the user if they was merged as well?

Sorry missed that comment about sensors. Was just wondering. I'm fine with it not being part of it.

I don't think my brightness comment is on the wrong line. You're setting the brightness to a not None value which indicates to Home Assistant that people can control the brightness. This seems incorrect because the device is just turn on/off right?

No, all tellstick light devices supports dimming, otherwise they would had been registered as switches. I thought you ment that brightness should be set to None if we got an off command.

Ah I see, my bad.
You do not need to set the brightness to None when turning off because Home Assistant will not report it. The only reason you might not want to overwrite it is if the light will restore the previous brightness when being turned on.

So, I'll revert that change, seems better that it restores the previous setting!

Well it depends on if the actual tellstick light restores the previous setting when turned on. But if it does, our assumed state should do the same.

You will also want to remove the setting the brightness to 255 when receiving an on command if you want to restore previous brightness.

How about the initial value of 0, that could be a problem.
The previous implementation only had the brightness as internal state and 0 meant off. So I started with the same value. Is it better to use None and if the last command sent was ON I will assume full light = 255.
Would that be a good solution?

Haha. Was typing at the same time. Will do it your way, that's better!

This is good to merge after you've squashed the commits ! :dolphin: :dollar:

Commits squashed, also changed the turn_on behavior to use the previous value instead of setting 255 if no brightness level was set. Seemed like the right way to go. @balloob, Is that how it usually work?

Yes!
On Sun, Mar 13, 2016, 11:34 Stefan Jonasson<EMAIL_ADDRESS>wrote:

Commits squashed, also changed the turn_on behavior to use the previous
value instead of setting 255 if no brightness level was set. Seemed like
the right way to go. @balloob https://github.com/balloob, Is that how
it usually work?
—
Reply to this email directly or view it on GitHub
https://github.com/balloob/home-assistant/pull/1529#issuecomment-196016603
.


In edit view, selected item is no show by default

Drop downs in edit view is loaded with values, however, the value selected in create view is not show by default.

both edit and create templates were modified; ng-model attribute of the select elements were assigned with the control's model element. This is changed to model element's id.


v0.0.42 not start

$ ./vknplayer.js
path.existsSync is now called `fs.existsSync`.
TypeError: Uncaught, unspecified "error" event.
    at TypeError (<anonymous>)
    at emit (events.js:74:15)
    at VK._requestWrapper (/Users/oleg/projects/vknplayer/app/api/lib/vk/api/vk.js:34:8)
    at VK.getUserId (/Users/oleg/projects/vknplayer/app/api/lib/vk/api/vk.js:94:14)
    at Console.init (/Users/oleg/projects/vknplayer/app/ui/console/lib/console.js:40:4)
    at UI.init (/Users/oleg/projects/vknplayer/app/ui/index.js:30:16)
    at Vknp._initUI (/Users/oleg/projects/vknplayer/app/lib/app.js:243:10)
    at Vknp.start (/Users/oleg/projects/vknplayer/app/lib/app.js:19:7)
    at Object.<anonymous> (/Users/oleg/projects/vknplayer/vknplayer.js:17:5)
    at Module._compile (module.js:456:26)

fix in develop allready


.Net SDK

Feature Description
I find Authorizer idea really great a full self hosted auth0 alternative and open source .. Great ... But no .Net Core SDK ?
Describe the solution you'd like
A full .Net SDK packaged in a official nuget could be very cool

@Nonobis thank you for reporting it.
I don't have much experience with .net would be interested in developing one?
We can collaborate

i can try. i will check how your sdk are done :) Do you expose a swgger for the api ?

Every instance of authorizer comes with graphql playground
You can check api docs
https://docs.authorizer.dev/core/graphql-api
Also check go sdk that I recently developed
https://github.com/authorizerdev/authorizer-go


Render static resources

Static resources (css, client side js...) are not rendered anymore. The temporary trick is not working anymore. See https://github.com/adobe/petridish/blob/master/src/HelixServer.js#L106-L115

There are 2 types of static ressources that should be rendered:

web resources (JS, CSS, images, icons, fonts...) coming from the code repo
assets (like images, a pdf file...) coming from the content repo via

In both cases, Petridish must fetch the content from the proper repo and deliver it with the proper content type.
In helpx, we have a sample of each:

a css file and an image referenced by the code
some images referenced by the content like https://github.com/Adobe-Marketing-Cloud/reactor-user-docs/blob/master/.gitbook/assets/loop.png being referenced in https://github.com/Adobe-Marketing-Cloud/reactor-user-docs/tree/master/getting-started

webresources will probably be bundled via webpack/parcel and then deployed somehow :-)
images in content would need to be streamed directly from the edge server

webresources will probably be bundled via webpack/parcel and then deployed somehow :-)
We only need to think that if as a developer I store the files under ./src/static but they get magically deployed under /dist something magic, either I know how to target those files in my htl (should I put /dist or /static or /src/static...?) or the path get re-written for me.

images in content would need to be streamed directly from the edge server
In development, I think I need them to come from the git content repo because that's where they live for the moment. In production, different story certainly.

Images in content:

in production they get mapped based on the file extension, i.e. png, jpg, gif, all go to the Fastly image service, backed by GitHub
in development, I'd keep the mapping, but skip the optimization

Web Resources

let's define a base path that can get mapped to the "static asset pre-packagaging and delivery function" - I'm fine with /dist, /libs, but not /cq.clientlibs
it.staticResourcesPath is a great candidate for the context variable in pipeline
in code, let's keep the base path configurable, but we can start with /src/client

ideally the delivery layer exactly knows where the find the resources based on the URL so that it doesn't need to issue multiple requests to find them. even for development, if an image is in the content or an image is in code; how should the server distinguish?
one possibility is to prefix all content resources with /content (haha).
and to prefix code resources with /lib. eg:
<script src="/lib/main.js" />
...
<img src="/content/logo.png" />

CSS with images:
src/styles/main.css:
fancy {
   background-image: url('fancy.png'); // will reference 'src/styles/fancy.png
}

when the bundler/packager processes the css above, it will create some sort of bundle.js which then is placed in ./dist/client and would beed to be deployed as well to the CDN. for testing in development,  it should probably be available as well. so maybe via a /lib -> /dist/client resolution.

I don't think we can force all content into /content, but having a /libs, etc. directory for "static" resources should be fine.
In your CSS with images example, we can have the (another instance) packager run with hlx up. In the simplest scenario, it would just copy files into /dist and we deliver it from there (I don't like the magic of having the filesystem dist becoming an HTTP libs btw.)
In production, we would want to have things like content-hashed path names, so that we can get better client-side cache efficiency.
"Deploying to CDN" then means deploying to a service that the CDN can call (and that has reasonable caching semantics)

Implemented the following behaviour:

if the extension is .html or .md the server does the normal script processing
if the path starts with /dist/ the resource will be streamed from ${distDir}/
otherwise it tries to stream the resource from the content repository.

The default for the ${distDir} is .hlx/dist.
what's missing now is support from helix-cli. see adobe/helix-cli#49