text:
HmIP-MIO16-PCB

This pull request:

adds support for HomeMatic device: HmIP-MIO16-PCB

New class: IPMultiIOPCB
Home Assistant platform: DISCOVER_SWITCHES, DISCOVER_SENSORS, DISCOVER_BINARY_SENSORS

does the following: This PR adds support for HmIP-MIO16-PCB. Please have a look if everything seems to be ok as I am not experienced in python and copied everything together.
Notes: One thing that I couldn't figure out during my tests is (how) to receive press events of an input configured as button ("Taster"). Configured as contact the input updates its value immediately. As normal switch it doesn't (I guess the CCU gets the update with the next periodic update of the device OR when a contact input changes).
Device and paramset description

Try using HelperEventRemote instead of HMEvent and report back if it solves the issue.

I think it doesn't solve the issue.
Just to rule it out: will the event always pop up in the logs, even if I misconfigured the event in my automations?
Here is the log after doing a "short press" on channel 15:
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic._hm] RPCFunctions.event: interface_id = homeassistant-ip, address = 00251A499B2FD4:0, value_key = CONFIG_PENDING, value = False
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 INFO (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: address=00251A499B2FD4:0, interface_id=homeassistant-ip, key=CONFIG_PENDING, value=False
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback functools.partial(<function _hm_event_handler at 0x7f626c013550>, <homeassistant.core.HomeAssistant object at 0x7f6287f1f220>, 'ip')
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 18: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 22: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 13 STATE: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 26: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 14 STATE: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 30: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 34: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 38: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 16 STATE: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 42: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 46: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 1 VOLTAGE: 0.0>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 4 VOLTAGE: 0.0>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 7 VOLTAGE: 0.0>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 10 VOLTAGE: 5.22>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic._hm] RPCFunctions.event: interface_id = homeassistant-ip, address = 00251A499B2FD4:0, value_key = UNREACH, value = False
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 INFO (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: address=00251A499B2FD4:0, interface_id=homeassistant-ip, key=UNREACH, value=False
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback functools.partial(<function _hm_event_handler at 0x7f626c013550>, <homeassistant.core.HomeAssistant object at 0x7f6287f1f220>, 'ip')
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 18: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 22: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 13 STATE: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 26: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 14 STATE: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 30: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 34: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 38: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 16 STATE: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 42: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 46: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 1 VOLTAGE: 0.0>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 4 VOLTAGE: 0.0>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 7 VOLTAGE: 0.0>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 10 VOLTAGE: 5.22>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic._hm] RPCFunctions.event: interface_id = homeassistant-ip, address = 00251A499B2FD4:0, value_key = RSSI_DEVICE, value = -76
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 INFO (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: address=00251A499B2FD4:0, interface_id=homeassistant-ip, key=RSSI_DEVICE, value=-76
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback functools.partial(<function _hm_event_handler at 0x7f626c013550>, <homeassistant.core.HomeAssistant object at 0x7f6287f1f220>, 'ip')
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 18: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 22: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 13 STATE: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 26: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 14 STATE: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 30: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 34: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 38: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 16 STATE: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 42: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 46: off>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 1 VOLTAGE: 0.0>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 4 VOLTAGE: 0.0>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 7 VOLTAGE: 0.0>>
Apr 15 20:12:23 pyhomematic hass[396]: 2021-04-15 20:12:23 DEBUG (Thread-3) [pyhomematic.devicetypes.generic] HMGeneric.event: Using callback <bound method HMDevice._hm_event_callback of <Entity Rasensprinkler 10 VOLTAGE: 5.22>>

Uhm, try adding something like self.EVENTNODE.update({"PRESS_SHORT": self.ELEMENT}). Replace the self.ELEMENT with the list of appropriate channels.

hmm... unfortunately this makes no difference :confused:
Is it possible to merge without the button event working? I could remove the button related code first and test it again...
Thank you for your support on this!

Is it possible to merge without the button event working? I could remove the button related code first and test it again...

Sure, go ahead. There are other devices that don't have 100% functionality. That's the problem with pyhomematic. It's not as flexible as it should be. With hahomematic that should change.

Ok thanks, here's the updated code 🎉

Thanks. May I ask for a favour? As you might know I'm currently working on hahomematic. The way it works is by looking at all the paramsets and automatically creating the correct entity-types based on what the paramset description says about the channel.
Now I don't know how your device was configured at the time you have created the paramset description file you have posted above. What I would like to see is how the paramset descriptions (pd) change when you configure a channel to a different behavior. Ideally if there are f.ex. 3 configurable channels and 3 modes are available for these, I's like to see a pd where each channel is configured to one of the modes. That way it would include every possibility in regards to the configuration. So if I could make a wish you'd say "in this pd channel 5 is a button, channel 6 is an analog input and channel 7 is a digital input". 😇

Yes of course I can provide you the pd (and test hahomematic with my devices at some point).
Do you also need "defined" pd of other devices with configurable channels?
I have HmIPW-DRI32 (digital inputs) and HmIPW-DRBL4(blind/shutter, which has a separated config channel for each output channel, see #398).
If this is a bigger thing you could open an issue at hahomematic like #28 to collect those kinds of devices.

Here are the updated files for HmIP-MIO16-PCB.
Input Channels

Channel
Type
Configuration

CH01
analog input
no other type configurable

CH04
analog input
no other type configurable

CH07
analog input
no other type configurable

CH10
analog input
no other type configurable

CH13
digital input
not active/disabled

CH14
digital input
button

CH15
digital input
switch

CH16
digital input
contact sensor

PS:
As I see it in the gist revisions, there are not really differences to the first version 🤔

I'm actually collecting them here: https://github.com/danielperna84/pydevccu
So feel free to contribute the files for every device I don't yet have there. Currently I don't have IP-wired ones. So the 2 you have would be great.
I think for the MIO16 it's ok this way, as it has both the press-parameters and the state. So when creating the entities automatically via hahomematic, it would create entities which are not functional, but also none would be missing. That would be ok I guess.
But maybe that's different for the wired devices. So it would still be interesting to see if in those cases paramsets change when the configuration has been modified. It could also be, that for these devices simply all parameters are present. I just though inactive parameters would be hidden. But that was just a guess. After all all the matters is, that all parameters that are required for operation will be available. If there are stale ones that don't do anything they can just be hidden in Home Assistant.


text:
Vitest hangs at [RUN] v0.33.0 with no debug output or error

When I had been running tests using the @nuxt/test-utils library I could get results like:
 Test Files  1 failed | 1 passed (2)
      Tests  1 failed | 1 passed (2)
   Start at  14:49:45
   Duration  2.13s (transform 696ms, setup 0ms, collect 1.49s, tests 14ms, environment 434ms, prepare 381ms)

But because I was having trouble with Nuxt imports like ReferenceError: useRuntimeConfig is not defined, I've made changes to switch over to using this library. Unfortunately, I cannot figure out how to get the tests to actually run or at least error out. Instead, I just get this:
$ npm run test

> project@1.0.0 test
> vitest --config ./vitest.config.ts run

 RUN  v0.33.0 .../project/test

Here are some relevant file contents...
package.json
{
  "name": "project",
  "version": "1.0.0",
  "description": "",
  "private": true,
  "type": "module",
  "engines": {
    "node": "18"
  },
  "scripts": {
    "dev": "nuxt dev",
    "generate": "nuxt generate",
    "preview": "nuxt preview",
    "prepare": "nuxt prepare",
    "build": "NITRO_PRESET=aws-lambda nuxt build",
    "deploy": "DEPLOY=true TIER=$TIER NITRO_PRESET=aws-lambda nuxt build && sls deploy --stage $TIER",
    "offline": "npm run build && sls offline start",
    "debug": "SLS_DEBUG=* node --inspect node_modules/serverless/bin/serverless offline",
    "test": "vitest --config ./vitest.config.ts run",
    "test:watch": "vitest --config ./vitest.config.ts watch",
    "lint:js": "eslint --ext \".ts,.vue\" --ignore-path .gitignore .",
    "lint:prettier": "prettier --check .",
    "lint": "npm run lint:js && npm run lint:prettier",
    "lintfix": "prettier --write --list-different . && eslint --ext \".ts,.vue\" --ignore-path .gitignore . --fix",
    "coverage": "vitest run --coverage --config ./vitest.config.ts",
    "postinstall": "patch-package"
  },
  "devDependencies": {
    "@babel/cli": "^7.23.0",
    "@babel/core": "^7.23.2",
    "@nuxt/test-utils": "^3.8.0",
    "@nuxtjs/eslint-config-typescript": "^12.1.0",
    "@nuxtjs/eslint-module": "^4.1.0",
    "@nuxtjs/partytown": "^1.3.0",
    "@pinia-plugin-persistedstate/nuxt": "^1.1.2",
    "@serverless/typescript": "^3.30.1",
    "@types/aws-lambda": "^8.10.125",
    "@types/crypto-js": "^4.1.3",
    "@types/eslint": "^8.44.6",
    "@types/node": "^20.8.10",
    "@types/papaparse": "^5.3.10",
    "@types/pdfmake": "^0.2.7",
    "@types/uuid": "^9.0.6",
    "@typescript-eslint/parser": "^6.9.1",
    "@vitejs/plugin-vue": "^4.4.0",
    "@vitest/coverage-v8": "^0.33.0",
    "@vue/compiler-sfc": "^3.3.4",
    "@vue/test-utils": "^2.4.1",
    "@vueuse/nuxt": "^10.5.0",
    "eslint": "^8.52.0",
    "eslint-config-prettier": "^9.0.0",
    "eslint-plugin-nuxt": "^4.0.0",
    "eslint-plugin-prettier": "^5.0.1",
    "eslint-plugin-vitest": "^0.3.9",
    "happy-dom": "^12.10.3",
    "jsdom": "^22.1.0",
    "naive-ui": "^2.35.0",
    "nuxt": "^3.8.0",
    "nuxt-icon": "^0.6.1",
    "nuxt-lodash": "^2.5.3",
    "nuxt-viewport": "^2.0.6",
    "nuxt-vitest": "^0.11.2",
    "patch-package": "^8.0.0",
    "prettier": "^3.0.3",
    "sass": "^1.69.5",
    "sass-loader": "^13.3.2",
    "serverless-offline": "^13.2.0",
    "serverless-s3-sync": "^3.2.0",
    "typescript": "^5.2.2",
    "unplugin-auto-import": "^0.16.7",
    "unplugin-vue-components": "^0.25.2",
    "vitest": "^0.33.0",
    "vue": "^3.3.7",
    "vue-tsc": "^1.8.22"
  },
  "dependencies": {
    "@css-render/vue3-ssr": "^0.15.12",
    "@pinia/nuxt": "^0.5.1",
    "buffer": "^6.0.3",
    "crypto-js": "^4.2.0",
    "dayjs": "^1.11.10",
    "deep-object-diff": "^1.1.9",
    "deepdash-es": "^5.3.9",
    "jszip": "^3.10.1",
    "marked": "^9.1.5",
    "mitt": "^3.0.1",
    "papaparse": "^5.4.1",
    "pdfmake": "^0.2.7",
    "pinia": "^2.1.7",
    "slugify": "^1.6.6",
    "uuid": "^9.0.1"
  },
  "overrides": {}
}

nuxt.config.ts
  modules: [
    "nuxt-vitest",
   ...
  ],

vitest.config.ts
import { defineVitestConfig } from "nuxt-vitest/config";

export default defineVitestConfig({
  plugins: [],
  test: {
    globals: true,
    environment: "jsdom",
    environmentOptions: {
      nuxt: {
        overrides: {},
      },
    },
  },
  root: "./test",
});

project/test/example.nuxt.test.ts
import { test, expect } from "vitest";

test("1 + 1", () => {
  expect(1 + 1).toEqual(2);
});

Is there a chance you have any asynchronous code in your Nuxt runtime that might not be resolving in the test environment? An app I work on, for example, was hanging like yours when we had an unresolved Promise in some of our plugin code.

Before your tests run, a global Nuxt app will be initialized (including, for example, running any plugins or code you've defined in your app.vue).
—nuxt-vitest#important-notes

source: gharchive/issue

authors: adam-gipril beunerd

repo: danielroe/nuxt-vitest

license: MIT

license_type: permissive

license_source: github-api


text:
Add navbar links

Is your feature request related to a problem? Please describe.
Add links on the top navbar to the main tracket pages and
Describe the solution you'd like
All links should open on a new page.

Get Tracket - text link to https://tracket.info/sensor/
Noise Map - text link to https://dashboard.tracket.info/locations
About - text link to https://tracket.info/
Donate - text link to https://opencollective.com/tRacket
Log In - white button linked to TBD. Styling through CSS.

Additional context

Navbar https://github.com/danieltsoukup/noise-dashboard/blob/97584a6e4a3bc2484563efc0b2b31d7feb0bae54/app/src/app_components.py#L341
Docs https://dash-bootstrap-components.opensource.faculty.ai/docs/components/navbar/

Login links for the tRacket Sensor manager should point to:
https://manage.tracket.info/

Hi @danieltsoukup , I have created a pull request https://github.com/danieltsoukup/noise-dashboard/pull/29 for this feature. Please let me know if there are any changes to be made?

Awesome! Added some comments on the PR.

I have opened a new pull request with the updated changes - https://github.com/danieltsoukup/noise-dashboard/pull/33

Thank you, will be live soon!

repo: danieltsoukup/noise-dashboard


text:
Crash in Editor [Windows 10]

Not sure why this happened but here's the crash log:
2024-05-24_20-06-15.log

Doesn't seem like it's caused by Globed, looks rather random. Is there any way to reproduce the crash or did it happen just once?

Admittedly just happened once - it's just that out of all the crashes I've ever had, I've never seen Globed in the stack trace until now.

Judging by the stack trace, the crash happened in GD code, the reason Globed is in the stack trace is because it hooks that specific function that caused the crash. But the specific part of the code that caused the crash is unrelated to Globed and the crash is likely not caused by it (to be honest I've never seen a crash like this so I'm not sure what even could be the cause)
Closing the issue unless this happens again (in that case you could reopen it)


text:
error decoding

for this string of base64 data:  Y2UAAm9yQEPHkNtqWzCE9FswvTQ=
this library decodes to 19 bytes, while base64-js, node's Buffer class, and browsers' atob implementation all give me 20 bytes.

Hi, monteslu.
Perhaps, original source data of the base64 data is binary data string?
decode() of this library restores the data as utf8 string,
Some data was converted to utf8 character, and the total length became shorter.
Use atob() instead of decode() for binary data.
But, in Node.js, atob() of current version library may have a bug.
It seems that sometimes unnecessary null bytes are added to the end of restored data.

(in Japanese)
こんにちは、monteslu。
そのbase64データは、おそらく、バイナリデータ文字列をエンコードしたものではないでしょうか？
このライブラリのdecode()は、データをutf8文字列として復元するので、
一部のデータがutf8文字に変換されて、長さが短くなったのでしょう。
バイナリデータを扱う場合は、Base64.decode()の代わりにBase64.atob()を使ってください。
.decode() vs .atob
しかし、Node.js環境でこのライブラリを使う場合、もしかすると現在のバージョンのatob()にはバグがあるかもしれません。
復元データの末尾に不要なnullが追加される場合があるようです。

authors: htaketani monteslu

license_source: bigquery


text:
English grammar fixes

Thank you for curating some of the research on this topic!
I considered rewriting to pluralise "author" (a sort of defensive programming against future editors), although decided that would go too far.

Thanks!

source: gharchive/pull-request


text:
Speech-to-text evaluation

Hi,
I successfully run the experiments and I am trying to evaluate the CAAT system with various values of latency. I started your agent for SimulEval but it is taking more than 2 days for the result, is it normal?
Thank you again

Hi, I am testing on MuST-C tst-COMMON and it is taking a long time compared to you. I do not know why. I am using only one GPU K80 for inference, how many GPUs have you used for testing?
I also added the tag --gpu to the SimulEval inference script to ensure the use of the GPU.
It is strange because the standard Fairseq SimulST model takes less than 1 hour in the same setting.

I use one V100 GPU for inference, but there shouldn't be too much difference in speed. the tag "--gpu" is not defined in my code and I will ignore it. I used "--cpu" to indicate model runs on CPU, or it will runs on GPU by nn.Module.cuda().
Infering speed of my CAAT should be comparable to wait-k or MMA, I don't know the detail of your standard fairseq simulST. Maybe you need to debug a little bit more, log out the cost of some special function, to find the bug reason


text:
No donation button

A bit on a funny issue side, but really, where can I donate a few coffees to you?

😄 Issue fixed in latest readme.md

repo: dannerph/homeassistant-keba


text:
Authorization rejected

When plugging in the cable (P30) charging starts and then stops right away with Status: authorization rejected. No RFID installed or activated. All firmware and software with latest versions as of today. Did already a P30 factory reset to no avail and also tried with disabled integration. No automations running.
Diagnostic: AuthON: Off, Session en reason: 5, State: 5
Tried with a granny charger which works fine.
P30 v 3.10.36
Anyone here with a solution? Thanks!

Still struggling with this, but making some progress, I think.

In the integration configuration settings I have set now an 8 number UID for the RFID tag for default authentication.
Then I have added a RFID Card to the Keba whitelist with the same UID (go whitelist.php on your local Keba URL).

In the Keba Device configuration I have set:

Authorization: On
Online Authorization Mode: OnlyLocal
Offline Authorization Mode: OfflineNoAuthorization

The Keba timeout now is faster, when sending Enable, resulting in a faster updated Logbook, so the Keba is actually checking something locally now and not timing out against the OCPP. However KEBA P30 Status  changed to authorization rejected is still the result.
Using SolarEdge EV Charger (Keba P30 x-series), Firmware (SolarEdge): 1.14, Keba Integration v2.4.0.
Any tips would be appreciated.

Got the 4.19.36 update today https://www.solaredge.com/en/support/setapp-inverters-firmware#Released32111.
Did some testing and was able to charge now, but don't see that the RFID Card actually is used in the session; the RFID number is not in the logged session. Charging could be stopped too but then started again after a few seconds. Had to remove the cable from the car to stop charging.

@dannerph
When debug logging I see:
"RFID tag": "0000000000000000",
"RFID class": "00000000000000000000"
Where do these zero's come from? call.data / entry.options?
These are always in the debug data, also when I add an RFID card to the charger or add an RFID tag for default authentication in the Options eg. using 00845500.
BTW: once RFID tag/class configured in the Options I can remove and then submit these options but the once set values persist.

@dannerph When debug logging I see: "RFID tag": "0000000000000000", "RFID class": "00000000000000000000"
Where do these zero's come from? call.data / entry.options? These are always in the debug data, also when I add an RFID card to the charger or add an RFID tag for default authentication in the Options eg. using 00845500.
BTW: once RFID tag/class configured in the Options I can remove and then submit these options but the once set values persist.

Those balues in debug should be just what the charging station sent an what the integration received. Not sure if those RFID values are handled consistantly among all types of boxes

authors: dannerph deqw


text:
Custom phone field with country dialing code

Hi,
I needed a phone field that would also accept a country code. So, I pieced together a solution using flutter_country_picker and this package. Sharing it here in case (a) someone finds it useful and/or (b) it can be incorporated into this package itself
Upon form submission, you will see the following 3 attributes in form.value

phone : the actual number (minus country code)
country_code
country: ISO code for the country (like IN for India, US for USA etc.)

The fully qualified phone # will be +<country_code><phone>
I am sure the implementation can be improved / generalized by Danvick. I am only sharing what I could cook up for my limited needs
Selecting country
class _Country extends StatefulWidget {
  _Country();

  _CountryState createState() => _CountryState();
}

class _CountryState extends State<_Country> {
  Country _country;

  @override
  Widget build(BuildContext context) {
    return CountryPicker(
      dense: true,
      onChanged: (Country country) {
        setState(() {
          _country = country;
          FormBuilderState form = FormBuilder.of(context);

          form.setAttributeValue("country_code", country.dialingCode);
          form.setAttributeValue("country", country.isoCode);
          print("${country.name} -> ${country.isoCode} -> ${country.dialingCode}");
        });
      },
      selectedCountry: _country,
    );
  }
}

... then  using it to build a custom phone field
// phone w/ country code
class FormPhone extends FormBuilderCustomField<void> {
  FormPhone({
              @required String attribute,
              @required String purpose,
              String label,
              IconData icon = Icons.phone_android,
              bool mandatory = false,
            }) : super(
    attribute: attribute,
    formField: FormField(
      enabled: true,
      builder: (FormFieldState<void> field) {
        return InputDecorator(
          decoration: InputDecoration(
            labelText: label?.toUpperCase(),
            icon: Icon(icon),
            helperText: purpose?.toUpperCase(),
            contentPadding: EdgeInsets.only(top: 15),
          ),

          child: Row(
            mainAxisSize: MainAxisSize.min,
            children: <Widget>[
              _Country(),
              Container(
                width: 200,
                child: FormBuilderTextField(
                  attribute: "phone",
                  keyboardType: TextInputType.phone,
                  decoration: InputDecoration(
                    enabledBorder: InputBorder.none,
                  ),
                  validators: [FormBuilderValidators.numeric(errorText: "Only digits (1-9) "
                      "allowed")
                  ] + (mandatory ? [
                    FormBuilderValidators.required(),
                    FormBuilderValidators.minLength(5, errorText: "Seems too short!"),
                  ] : []),
                ),
              ),
            ],
          ),
        );
      },
    ),
  );
}

Hi @abhinavc,
This is a cool Widget which people might find useful. I'll consider adding it to the package.
Cheers!

This feature has been implemented in v3.10.0 of the package. Let's get feedback on that.

authors: abhinavc danvick


text:
about road_elevation

Has the "road_elevation" been converted?where is the transformed result in the apollo map(.txt)?

Actually road elevation is not supported in apollo map.
I parse it to ensure the integrity of the parsing, and a potential use, such as the roll of the road

This issue is closed due to not being active, please feel free to open it again if you have any questions


text:
Add mysql conformance test

Expected Behavior
I am wondering if mysql can pass state conformance test, need to add and verify, and fix if necessary.
Actual Behavior

Steps to Reproduce the Problem

Release Note

RELEASE NOTE:

/assign

repo: dapr/components-contrib


text:
Propagating context in actor calls

Description
This PR is in continuation of earlier PR in 0.6.0 milestone #1332. Due to various changes over the code path, to avoid fixing merge conflicts resolutions, created this PR on latest code.
This PR is in conjunction with #1373 to address remaining propagation of context in actor calls.
This PR was not checked in 0.6.0 release as the context was not populated with correlation id.
Now with issue #1373 , context is built correctly , so checking in this change now.

[x] Call(ctx context.Context, req *CallRequest) (*CallResponse, error)
[x] 	GetState(ctx context.Context, req *GetStateRequest) (*StateResponse, error)
[x] 	SaveState(ctx context.Context, req *SaveStateRequest) error
[x] 	DeleteState(ctx context.Context, req *DeleteStateRequest) error
[x] 	TransactionalStateOperation(ctx context.Context, req *TransactionalRequest) error
[x] 	GetReminder(ctx context.Context, req *GetReminderRequest) (*Reminder, error)
[x] 	CreateReminder(ctx context.Context, req *CreateReminderRequest) error
[x] 	DeleteReminder(ctx context.Context, req *DeleteReminderRequest) error
[x] 	CreateTimer(ctx context.Context, req *CreateTimerRequest) error
[x] 	DeleteTimer(ctx context.Context, req *DeleteTimerRequest) error
[x] 	IsActorHosted(ctx context.Context, req *ActorHostedRequest) bool
[x] 	GetActiveActorsCount(ctx context.Context) []ActiveActorsCount

Issue reference
#292
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[x] Created/updated tests
[x] Unit tests passing
[ ] End-to-end tests passing
[ ] Extended the documentation
[ ] Specification has been updated
[ ] Provided sample for the feature

/ok-to-test

@shalabhms Can you validate DemoActor sample in dotnet-sdk with this change ?

authors: shalabhms youngbupark

repo: dapr/dapr


text:
Moves public daprd metadata server to new authorized port

Currently, daprd is exposing the public port which exposes the healthz and metadata endpoints. This is exposed publicly on the network. This server has no authentication and is serving requests in plaintext.
The metadata endpoint returns information like actors, subscriptions, components etc.
This represents a massive privacy exposure. This port must be disabled on any multi-tenant deployment of Dapr, however this is not documented anywhere and the daprd logs don't explain that this is happening either. Users are currently exposing this information without knowledge.
This PR moves the public metadata endpoint to a new port, and adds authentication and authorization to the endpoint. If mTLS is enabled, the endpoint will serve using the same TLS as the internal API server. The server will only serve requests to SPIFFE peers that present in the --dapr-metadata-authorized-ids CLI flag. If mTLS is disabled, this flag is ignored.
PR extends the mTLS Configuration API with a new metadataAuthorizedIDs fields which takes a slice of SPIFFE IDs. This slice is appended to the authorized list when consumed by daprd. When set on the global dapr-system configuration, the sidecar-injector sets this value on the sidecar container. This allows users to configure the authorized IDs globally, or on a per-pod basis.
Closes https://github.com/dapr/dapr/issues/7397

Although I appreciate that this is done the "right way" and requires mTLS, we should consider how the metadata API is likely being used, which is that apps may call it to get information on the sidecar, or possibly even external monitoring/cataloging services.
Adding the requirement of using mTLS, fetching certs from Sentry, in this case is IMHO very burdensome given the kind of consumers.
I would rather add a more simple IP-based allowlisting. Or just trust that users will not expose the port in the K8s service.

I agree with @ItalyPaleAle. At least, offer a way for people to keep the existing behavior. We should do that anyway because it is a breaking change.

The project should always strive to do things the right way, especially so for security. I don't think we should follow the deprecation policy in this instance as this is an undocumented privacy vulnerability in multi tenant deployments.
Applications that currently consume the metadata API can continue to do so via the localhost endpoints. Communication between Dapr hosts must always be mTLS by default in Kubernetes. Any system which is currently consuming this API should have enough knowledge of Dapr already to be able to request an identity certificate from sentry using the gRPC protos. We must have a mechanism to authorize this endpoint- IP allowlists are not appropriate in cloud native environments as IP addresses are ephemeral.

The project should always strive to do things the right way, especially so for security. I don't think we should follow the deprecation policy in this instance as this is an undocumented privacy vulnerability in multi tenant deployments.
Applications that currently consume the metadata API can continue to do so via the localhost endpoints. Communication between Dapr hosts must always be mTLS by default in Kubernetes. Any system which is currently consuming this API should have enough knowledge of Dapr already to be able to request an identity certificate from sentry using the gRPC protos. We must have a mechanism to authorize this endpoint- IP allowlists are not appropriate in cloud native environments as IP addresses are ephemeral.

I understand your rationale. On the other hand, an OSS project have to be careful on forcing a migration on a minor version upgrade. It can lead to the opposite result, where users stick to an older version of Dapr to plan ahead their migration in order to upgrade to a version that requires a significant change of their environment - there can be internal tools depending on this behavior that only the user knows.

(Please also note that this metadata API is not enabled by default, so users must enable it explicitly)
Before we make decisions here we should really inquire on how users are using this API. My feeling is that it used by external services for cataloging or other purposes, for whom requesting a certificate from Sentry would not be feasible and would make the API unusable. (Also, we do not have public-facing SDKs for Sentry)
Agree IP allowlisting isn't great, but this leaves us with 2 options:

Let users figure it out. We can add a warning when the metadata endpoint is enabled that it can expose sensitive information and users should be careful when exposing that.
Shared key authentication, combined with TLS (not mTLS). Not great but better than nothing.

@ItalyPaleAle it is enabled by default in Kubernetes.

@ItalyPaleAle it is enabled by default in Kubernetes.

Ok that's a different problem then. I thought the PR that implemented that made it optional

authors: ItalyPaleAle JoshVanL artursouza


text:
Add bulk pub/sub examples to Python SDK client doc

Add bulk pub/sub examples to python client doc
Should be implemented in 1.12

Code doesn't exist for this yet, so unable to work on docs at the moment.

repo: dapr/docs


text:
Add Dapr Docs contributor video

https://www.youtube.com/watch?v=60cda2U3GKc

/assign

Closing. Merged

authors: marcduiker msfussell


text:
How to throw error correctly in actor method?

I have an actor within following method
func (t *TestActor) Invoke(ctx context.Context, req string) (string, error) {
	return "", errors.New("Custom Message")
}

And I invoke the actor like this
	ctx, _ = context.WithTimeout(ctx, time.Second*15)
	rsp, err := myActor.Invoke(ctx, "laurence")
	if err != nil {
		panic(err)
	}
	fmt.Println("get invoke result = ", rsp)

It should always go panic(err), but the error shown is always "panic: error invoking binding testActorType/ActorImplID5121f5e3-bb26-4362-a199-e20ec9ebd5d5: rpc error: code = Internal desc = error invoke actor method: rpc error: code = Internal desc = error invoke actor method: error from actor service: "
Please advise..., also how to customize the grpc error code? now its always "Internal".

// InvokeMethod to invoke local function by @actorID, @methodName and @request request param.
func (m *DefaultActorManagerContext) InvokeMethod(ctx context.Context, actorID, methodName string, request []byte) ([]byte, actorErr.ActorErr) {
	if m.factory == nil {
		return nil, actorErr.ErrActorFactoryNotSet
	}

	actorContainer, aerr := m.getAndCreateActorContainerIfNotExist(ctx, actorID)
	if aerr != actorErr.Success {
		return nil, aerr
	}
	returnValue, aerr := actorContainer.Invoke(ctx, methodName, request)
	if aerr != actorErr.Success {
		return nil, aerr
	}
	if len(returnValue) == 1 {
		return nil, actorErr.Success
	}

	var (
		retErr interface{}
		replyv reflect.Value
	)

	if len(returnValue) == 2 {
		replyv = returnValue[0]
		retErr = returnValue[1].Interface()
	}

	if retErr != nil {
		return nil, actorErr.ErrActorInvokeFailed
	}
	rspData, err := m.serializer.Marshal(replyv.Interface())
	if err != nil {
		return nil, actorErr.ErrActorMethodSerializeFailed
	}
	if err := actorContainer.GetActor().SaveState(ctx); err != nil {
		return nil, actorErr.ErrSaveStateFailed
	}
	return rspData, actorErr.Success
}

While investigating your problem, I also find that error is ignored when len(returnValue) == 1 and SaveState(ctx) is not invoked.
Any response from the contributer?
@LaurenceLiZhixin

authors: qazwsxedckll raymondsze

repo: dapr/go-sdk


text:
Correct dapr folder name after dapr init is executed

Description
After you run dapr init, the dapr fold should be $HOME/.dapr/config.yaml.
Issue reference
#440
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[x] The quickstart code compiles correctly
[x] You've tested new builds of the quickstart if you changed quickstart code
[x] You've updated the quickstart's README if necessary

Nice catch! Thanks!

repo: dapr/quickstarts


text:
Automatic experimental relevant time signal extraction and automated metrics

Relevant for common plotting and analysis of SignalTimeData
Also would be nice for:

[ ] Extracting the right pulse start and end
[ ] Clearer visualization of propagation delays
[ ] Fourier transformation implementation

It'd be nice to have an algorithm that takes in a waveform, and is able to calculate the metrics of a given transition or delay between corresponding waveforms digitally in a similar fashion to how an oscilloscope computes this internally. Accordingly, it'd be useful if we can do fourier transforms on the signal analysis accordingly for a given rise time or fall time as such.

repo: daquintero/piel


text:
Assertion `!inParallelMode || this == curEventQueue()' fails for atomic cpu

When no_kvm option is enabled, linux boot fails for atomic cpu since memory mode should be atomic but even when I fix that Assertion `!inParallelMode || this == curEventQueue()' fails during the linux boot.
Here is the related line: https://github.com/darchr/gem5art/blob/07584fd60d7f3de176a5f4f2c9bdd5bf4e51b2bf/docs/gem5-configs/configs-npb-tests/system/system.py#L121

Hi @mabdullahsoyturk: the condition on line 106 (which should be true by default) is leading to the error message you are seeing. Basically, multiple host cores can only be used if your cpu is kvm


text:
Add new cookies group

Describe the feature
There is two types of cookies:
necessary and optional.
Please allow add new group custom cookies.
In a lot of websites, the cookies are grouped like "necesary", "ads", "analytics", "geo", etc... not only 2 "static" group of cookies
Additional information

[ ] Would you be willing to help implement this feature?

Final checks

[X] Check existing discussions and issues.

PRs welcome!

here you are an example of other consent banner cookies with custom categories
https://cookieconsent.orestbida.com/reference/configuration-reference.html#categories

Or maybe extend, not only optional and necessary.
Extend to

Necessary
Functionality
Analytics
Marketing

Extend in this enum to :
export declare enum CookieType {
NECESSARY = "necessary",
FUNCTIONALITY = "functionality",
ANALYTICS = "analytics",
MARKETING = "marketing"
}

I think the categories should be configurable eventually, as configurability is a goal of this project.

I think the categories should be configurable eventually, as configurability is a goal of this project.

@dargmuesli
Do you know when you will implement this configurability?

Yes, I won't implement this feature myself, that's why I wrote "PR welcome" and tagged this issue with the "help wanted" label.

@dargmuesli
I create new pull request to fix this issue

authors: agracia-foticos dargmuesli

repo: dargmuesli/nuxt-cookie-control


text:
Typo in german translation, "L" missing in Warteschlange (queue)

It reads "Warteschange", it should say "Warteschlange" (queue). Occurs 3 times:
./src/qt/locale/dash_de.ts:
<message>
    <location filename="../overviewpage.cpp" line="414"/>
    <source>Submitted to masternode, waiting in queue .</source>
    <translation>An Masternode übermittelt, wartet in Warteschange .</translation>
</message>
<message>
    <location filename="../overviewpage.cpp" line="415"/>
    <source>Submitted to masternode, waiting in queue ..</source>
    <translation>An Masternode übermittelt, wartet in Warteschange ..</translation>
</message>
<message>
    <location filename="../overviewpage.cpp" line="416"/>
    <source>Submitted to masternode, waiting in queue ...</source>
    <translation>An Masternode übermittelt, wartet in Warteschange ...</translation>
</message>

Good find, thanks a lot :thumbsup:
@schinzelh , I've already fixed it over at Transifex.

authors: Sleekesst crowning-

repo: darkcoin/darkcoin


text:
New-SFTPSession : Not able to connect for Password and Key authentication

Hello,
I am trying to create new SFTPSession = New-SFTPSession -ComputerName "Abc.com" -Credential Get-Credential  -KeyFile $key -ConnectionTimeout 60  -AcceptKey
Where authentication type is Password and Public Key but it seems like it not allowing to connect and getting error : New-SSHSession : Reached authentication attempt limit for method (publickey).
I think the password here it is accepting is only for KeyPhrase password.
Is there any alternate solution to create Session for Password and key Authentication?

I have the same need. As almost of the University staff works from home, the infrastructure team decided to force to use a bastion (a unique server to connect ssh using JumpProxy option to go on the other server) and that one requires to use a key and a password to establish the connection. I have a lot of PowerShell scripts running on my computer that I can't use anymore because of th limitation.

Same here. I need to be able to use username, password, and private keyfile. I need password to not be the keyfile passphrase. :/ Guess I'll stick with WinSCP for now.

There is also the situation to handle where the key file does not have a password.  When using PSCredentials and SecureString to create them (in an automation scenario) you cannot pass an empty string to any of the creation methods for these objects.

authors: PJohnsonTrimble Szeraax VisheshTR chrisptree

repo: darkoperator/Posh-SSH


text:
pgcluu_collectd : defunct child process in Incremental mode

In incremental mode (--rotate-daily & --rotate-hourly) all child processes "pgcluu_collectd" are not stopped by the parent process.
Step to reproduce :
$ pgcluu_collectd -i 60 --rotate-hourly -p 1520 /tmp/pgcluu --compress --pid-file=/tmp/pgcluu_collectd.1.pid

*** pgcluu_collectd v2.9 (pid:25580) started at Tue May 28 14:12:18 2019
Type Ctrl+c to quit.

LOG: compressing directory 2019/05/28/14 using /bin/gzip.
LOG: compressing directory 2019/05/28/15 using /bin/gzip.

Wait an hour and run ps :
$ ps -ef | grep pgcluu
postgres 25580  3621  0 14:12 pts/0    00:00:00 pgcluu_collectd
postgres 27558 25580  0 16:55 pts/0    00:00:00 [pgcluu_collectd] <defunct>
postgres 28116 25580  0 16:56 pts/0    00:00:00 [pgcluu_collectd] <defunct>
root     28656  9423  0 16:56 pts/1    00:00:00 grep --color=auto pgcluu

Hello @darold  :)
We can't reproduce the problem with version 3.0.  You can consider this issue as fixed and close it.
Thanks again and see you soon !

Hi, thanks @daamien ! I will close it in few days, I will reopen it if @OrioQuezac can still reproduce the issue with v3.0.

Hello @darold  !
@OrioQuezac is part of dalibo, I let you guess who he is :-)
Anyway we closed this issue internally, so  we won't react further on this one.
See you soon

Ok so I guess it can be closed.

authors: OrioQuezac daamien darold

repo: darold/pgcluu

license: PostgreSQL


text:
Use standard urls with {x} instead of 'tileX'  + deprecate old format

Closes https://github.com/darribas/contextily/issues/60

Coverage increased (+0.2%) to 91.188% when pulling 4f67541beff4e295763ca484db04f0ba29dcc58e on jorisvandenbossche:deprecate-old-url-format into d7db0ef2d13a242182fbd872c62aa75028f11d9a on darribas:master.

@darribas Does this look OK? I think it is ready to be merged (the failure on travis is the existing failure on py 3.5 that should be solve separately)

authors: coveralls jorisvandenbossche

repo: darribas/contextily


text:
An asset whose path is a prefix of another should cause a collision

 Issue by munificent
Originally opened as dart-lang/sdk#17150

Since barback doesn't have a concept of directories, it's possible to emit two assets like:
foo/bar // a file "bar" with no extension
foo/bar/baz.txt
That will fail horribly with something like pub build when it tries to output those two files. Instead of allowing this, barback should probably treat that like a collision.

 Comment by lrhn

Added Area-Pkg label.

repo: dart-lang/barback


text:
Code Summarization Thoughts

@sethladd @lukechurch @devoncarew
Currently working on creating a summary for users.  Ideally, these summaries will provide useful information and help developers to share insightful snippets of code. I am thinking of providing feedback for:

Code size
Whether code compiles
Number of warnings or errors
Unique libraries/imports used

For an example input from the tutorial:
import 'dart:html';
import 'dart:math' show Random;
import 'dart:convert' show JSON;

final String TREASURE_KEY = 'pirateName';

ButtonElement genButton;
SpanElement badgeNameElement;

main() async {
  InputElement inputField = querySelector('#inputName');
  inputField.onInput.listen(updateBadge);
  genButton = querySelector('#generateButton');
  genButton.onClick.listen(generateBadge);

  badgeNameElement = querySelector('#badgeName');

  try {
    await PirateName.readyThePirates();
    inputField.disabled = false; //enable
    genButton.disabled = false;  //enable
    setBadgeName(getBadgeNameFromStorage());
  } catch(arrr) {
    print('Error initializing pirate names: $arrr');
    badgeNameElement.text = 'Arrr! No names.';
  }
}

void updateBadge(Event e) {
  String inputName = (e.target as InputElement).value;

  setBadgeName(new PirateName(firstName: inputName));
  if (inputName.trim().isEmpty) {
    genButton..disabled = false
             ..text = 'Aye! Gimme a name!';
  } else {
    genButton..disabled = true
             ..text = 'Arrr! Write yer name!';
  }
}

void generateBadge(Event e) {
  setBadgeName(new PirateName());
}

void setBadgeName(PirateName newName) {
  if (newName == null) {
    return;
  }
  badgeNameElement.text = newName.pirateName;
  window.localStorage[TREASURE_KEY] = newName.jsonString;
}

PirateName getBadgeNameFromStorage() {
  String storedName = window.localStorage[TREASURE_KEY];
  if (storedName != null) {
    return new PirateName.fromJSON(storedName);
  } else {
    return null;
  }
}

class PirateName {

  static final Random indexGen = new Random();

  static List<String> names = [];
  static List<String> appellations = [];

  String _firstName;
  String _appellation;

  PirateName({String firstName, String appellation}) {

    if (firstName == null) {
      _firstName = names[indexGen.nextInt(names.length)];
    } else {
      _firstName = firstName;
    }
    if (appellation == null) {
      _appellation = appellations[indexGen.nextInt(appellations.length)];
    } else {
      _appellation = appellation;
    }
  }

  PirateName.fromJSON(String jsonString) {
    Map storedName = JSON.decode(jsonString);
    _firstName = storedName['f'];
    _appellation = storedName['a'];
  }

  String toString() => pirateName;

  String get jsonString => JSON.encode({"f": _firstName, "a": _appellation});

  String get pirateName => _firstName.isEmpty ? '' : '$_firstName the $_appellation';

  static readyThePirates() async {
    String path = 'piratenames.json';
    String jsonString = await HttpRequest.getString(path);
    _parsePirateNamesFromJSON(jsonString);
  }

  static _parsePirateNamesFromJSON(String jsonString) {
    Map pirateNames = JSON.decode(jsonString);
    names = pirateNames['names'];
    appellations = pirateNames['appellations'];
  }
}

Should ideally output a summary similar to:

This immense pad contains a void of errors and warnings. It makes use of 'dart:html', 'dart:math', and 'dart:convert' packages.

More metadata and raw data can be attached to these summaries to make them more useful for searching and concise breakdown, but we should get the basic summary done first.
Let me know your thoughts about any additions/changes to the summaries that could help users.

Sounds good, have you thought about letting the user be also add some (custom) summary ?
Not sure how that would look UI wise though...

You could also key off the presence of html and css code: ...and has associated html and css code.
You might omit talking about errors and warnings if there are none - hopefully most pads will analyze cleanly.
Another phrase that might help:
... demonstrates the use of async / await

Detect very specific keywords? Like: Also, mentions pirates.

If the objective is to help the SEO for snippets, we might want to add "human" words to the description. Instead of just "dart:convert", maybe "JSON parsing".
I can imagine someone saying "how do I parse JSON and add it to a web page?" and I would imagine they should find this snippet somehow.

Try not to use words that have one meaning in a context of another. E.g. a void of errors and warnings will cause confusion between void, the big empty space and void the type.
I like @sethladd's suggest of mapping package names to English equivalents.
I like the idea of putting in a few easter egg surprises based on specific keywords. Pirates, hummingbirds and cute but deadly frogs?
Could we also put the date and time when it was created? Possibly in Shakesperian English style?

Excel spreadsheet for anyone who has suggestions for keywords you would like to see.

I added a few items and notes to the spreadsheet.

Closing this as the code summarization feature is about to go live :)

authors: Georgehe4 devoncarew kasperpeulen kwalrath lukechurch sethladd

repo: dart-lang/dart-pad


text:
Initialize most Playground fields at declaration

The only reference to playground.dart's top-level playground was in AnalysisResultsController. I've refactored the snackbar to remove that singular usage.
playground.dart's top-level init function is replaced by a static function on Playground.
Change Future.then to async/await with try/catch.
Initialize simple fields with a simple initializer and make the field final.
Initialize complex fields with a function and make the field late final. In this way, the function is allowed to be an instance function.

Ping @johnpryan


text:
The readme still mentions google/dart-appengine

but what I have seen it was removed. Is it gone for good?

Fixed in https://github.com/dart-lang/dart_docker/commit/dfd7568643f61c83c427935096eb4c848f8af99d

authors: kevmoo zoechi


text:
Add generics support for queries and lookups

This is a breaking change that supports generics which makes it easier to be used with dart 2.0
// Before
db.query(Person).run(); // -> Stream<Model>
// After
db.query<Person>().run(); // -> Stream<Person>

// Before
db.lookup([key]); // -> Future<Model>
// After
db.lookup<Person>([key]); // -> Future<Person>

Closes #54

Great. I’ll make the changes and additional cleanups on Monday.

I think before merging this PR, we should ensure that the rest of the code is Dart 2.0 compliant (no upper case UTF8/...). If there's something missing we would need to fix those first and publish a new version before merging this PR.

I haven't seen any of these, nor were there any warnings.
But I now added implicit-casts: false to the strong-mode settings, and there are lots of issues. I will take care of them.

@mkustermann I've now added implicit-casts: false and fixed all >200 errors. They have been added as two separate commits, one for the library itself, and one for all the tests.

Oh,... I just realised that you wanted to merge the fixes for dart 2.0 first separately before making the changes. Do you still want to do this?
In that case, I would need to split this merge request. Not too big of an issue.

@mkustermann do you want me to split the PR into two separate ones? One that is a simple dart 2.0 upgrade, and the other one with the breaking generics changes?

@enyo Apologies for the delay, I will try to take a look at this soon.

Hope it's okay that I squash it into 1 commit :)

Sure :)
Have you given the generics Key problematic some thought? I have an implementation ready, with generic keys that we already started using in our app, and it works quite well, except for parents keys.

authors: enyo mkustermann

repo: dart-lang/gcloud


text:
Correctly escape comments that may contain tags

Fixes https://github.com/dart-lang/native/issues/1408

Thanks for your contribution! Please replace this text with a description of what this PR is changing or adding and why, list any relevant issues, and review the contribution guidelines below.

[x] I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

See our contributor guide for general expectations for PRs.
Larger or significant changes should be discussed in an issue before creating a PR.
Contributions to our repos should follow the Dart style guide and use dart format.
Most changes should add an entry to the changelog and may need to rev the pubspec package version.
Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

Thanks @brianquinlan!
I believe auto publishing doesn't work for packages that require the Flutter SDK. So this requires a manual merge (with red publish bot), and subsequently a manual flutter pub publish.
Hossein is on holiday this week. If this is important for you @brianquinlan, I can publish a new version with this change. Otherwise, it'll happen next week.

I suspect that the test_jnigen failures are unrelated to my changes since the same tests pass on macOS and Windows:
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
Note: javadoc: Loading source file example/in_app_java/android/app/src/main/java/com/example/in_app_java/AndroidUtils.java...
Note: javadoc: Loading source file /home/runner/.gradle/caches/modules-2/files-2.1/androidx.emoji2/emoji2/1.3.0/788179fcab96cd6ec9a3e284e2a509545dc0fb8d/emoji2-1.3.0-sources.jar/androidx/emoji2/text/EmojiCompat.java...
Note: javadoc: Loading source file /home/runner/.gradle/caches/modules-2/files-2.1/androidx.emoji2/emoji2/1.3.0/788179fcab96cd6ec9a3e284e2a509545dc0fb8d/emoji2-1.3.0-sources.jar/androidx/emoji2/text/DefaultEmojiCompatConfig.java...
/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlinx/kotlinx-coroutines-android/1.7.1/d43e33a7c7ee4bdb6fb3210bfdffee23f275e3dc/kotlinx-coroutines-android-1.7.1-sources.jar(/module-info.java):5: error: module not found: kotlin.stdlib
    requires kotlin.stdlib;
                   ^
/home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlinx/kotlinx-coroutines-android/1.7.1/d43e33a7c7ee4bdb6fb3210bfdffee23f275e3dc/kotlinx-coroutines-android-1.7.1-sources.jar(/module-info.java):6: error: module not found: kotlinx.coroutines.core
    requires kotlinx.coroutines.core;
                               ^
error: cannot access kotlinx.coroutines.android.module-info
  cannot resolve modules
Note: javadoc: 3 errors
Exception in thread "main" java.lang.NullPointerException
	at java.base/java.util.HashMap.putMapEntries(HashMap.java:497)
	at java.base/java.util.HashMap.putAll(HashMap.java:781)
	at com.github.dart_lang.jnigen.apisummarizer.Main.main(Main.java:132)

Fatal: Cannot generate summary: FormatException: Unexpected end of input (at character 1)

^

Error: Process completed with exit code 1.

Hossein is on holiday this week. If this is important for you @brianquinlan, I can publish a new version with this change. Otherwise, it'll happen next week.

@dcharkes The CI for package:http is currently broken because the jnigened sources are not compatible with the unintended_html_in_doc_comment lint. Regenerating the sources would be the easiest path to a fix for us.
If doing a release is easy and low-risk, could you do one please?

@dcharkes The CI for package:http is currently broken because the jnigened sources are not compatible with the unintended_html_in_doc_comment lint. Regenerating the sources would be the easiest path to a fix for us.

Maybe you can ignore the lint in the generated file for now?

If doing a release is easy and low-risk, could you do one please?

I believe this knowledge is in @HosseinYousefi's brain. (We should document this @HosseinYousefi!)

There is nothing worth documenting.
You can safely release it if the CI is failing even without your change. I don't know why the CI fails, I'll investigate when I get back.

There is nothing worth documenting.
You can safely release it if the CI is failing even without your change. I don't know why the CI fails, I'll investigate when I get back.

So we just have to flutter pub publish? On a clean master?

Maybe it is still worth waiting for https://github.com/dart-lang/native/issues/1430 to be fixed

There is nothing worth documenting.

You can safely release it if the CI is failing even without your change. I don't know why the CI fails, I'll investigate when I get back.

So we just have to flutter pub publish? On a clean master?

Yes. We don't have a separate "stable" branch.

authors: HosseinYousefi brianquinlan dcharkes

repo: dart-lang/native


text:
allow dart2js compile multiple source files at once

This issue was originally filed by email...@daniel-zwicker.de

We have a about 84 dart files in our project with out the libs inside the package folders. There from we have to use dart2js for 15 of them. As a compile to js takes about 10 sec we have tried to speed up this.
We edit the dart2js.dart and changed the 'api.compile(uri....' call to a hard coded URI and double it. So one call to dart2js compile 2 files at once (Yes the out.js will be overwritten).
We mesure the following times (disabled snapshot use of utils_wrapper.dart.snapshot):
file1:  0m8.869s
file2:  0m8.299s
together: 0m12.732s
So there is a speed up of around 50% for the second file. We believe this is because the compiler is loaded.
So wouldn't it be possible to allow to define a directory which dart2js compile all *.dart recursive? This would speed up our builds extreme.

We require a build system now

authors: DartBot matanlurey

repo: dart-lang/sdk


text:
Strong mode can be extremely slow on some large projects

A couple of large projects have observed extremely slow (orders of magnitude) slowdown running strong mode.  This bug is to track and diagnose this.
I've done some instrumentation of the batch mode analyzer, and what I see is that the individual tasks are not taking longer, but that we are re-resolving dramatically more compilation units.  So this might be a bad interaction with analyzer caching?  Not sure yet.  What I see is as follows.
I've instrumented the BuildCompilationUnit task to log whenever it either builds a fresh compilation unit from source, or else pulls a compilation unit out of the cache and re-resolves it.  For a non-strong mode run, I see the following:
Compilation unit elements built: 2492
Compilation unit elements re-resolved: 9533
Unique compilation elements re-resolved: 2378
So there are 2492 compilation units, of which 2378 get re-resolved at some point, on average about 4 times each.
In strong mode, letting the process run for a couple of minutes and then killing it, I see:
Compilation unit elements built: 2492
Compilation unit elements re-resolved: 48811
Unique compilation elements re-resolved: 2378
So there are 2492 compilation units, of which 2378 get re-resolved on some point, on average about 20 times each.
I don't understand entirely what I'm seeing yet - at least all of the same compilation unit elements are being built and then re-resolved, but for some reason a huge number of compilation units are being repeatedly re-resolved.  This looks like it could be a bad cache interaction, but not sure yet.  I'm going to add instrumentation to see how many units are being completed.
@bwilkerson I don't totally understand what it means for a compilation unit element to be in the cache but need to be re-resolved.  Why does this happen?  Does this mean that something got evicted from the task model cache but not the analyzer cache?  There should be no invalidation happening, I don't think, since we are in batch mode.
cc @dgrove @skybrian

Wild guess: there's a hard-coded parameter in driver.dart:
/// The maximum number of sources for which AST structures should be kept in the
/// cache.
const int _maxCacheSize = 512;
I don't know if that relates directly to resolved elements, but would bumping that up make a difference?

I don't totally understand what it means for a compilation unit element to be in the cache but need to be re-resolved. Why does this happen?

I'm not totally sure what you mean by "re-resolved", but that doesn't make sense to me either. If the compilation unit was flushed from the cache then it would also need to be re-parsed before being re-resolved. Could you send me a patch (or something) with the changes you've made in order to gather these numbers?

Does this mean that something got evicted from the task model cache but not the analyzer cache?

If by "task model cache" you mean the results being stored by the work items, no, that isn't really a cache; nothing ever gets flushed, although the work item will be discarded if some result in the analyzer cache is invalidated.

There should be no invalidation happening, I don't think, since we are in batch mode.

Agreed. It might be worth putting in a breakpoint (or something) where the cache state gets invalidated (in cache.dart on lines 352, 414, and 566) to verify that assumption.

... there's a hard-coded parameter in driver.dart ... I don't know if that relates directly to resolved elements, but would bumping that up make a difference?

I believe that that's dead code now. The new task model changed the way caching works. The number of AST's in the cache is now controlled by the AST_CACHING_POLICY. If it's working as expected, the max is currently set at about 630 AST's, which might well be too few.
@leafpetersen You could try changing the cache size by changing the AST_CACHING_POLICY. Pick the number of AST's you want and multiply by 13 to get the number to use in the constructor.

I'll send you a patch by email.  The BuildCompilationUnitElement task (line 759 of dart.dart) either builds a new compilation unit (and does some level of resolution on it), or else pulls one out of cache, and calls the DeclarationResolver to re-associate some of the element model with the AST (I believe that this only re-creates the state that buildCompilationUnit leaves things in, and that subsequent re-resolution will happen as usual, but I'm not sure).  I'm calling the case where a new compilation unit gets built "Compilation unit elements built", and the case where the declaration resolver gets called on something pulled out of cache "Compilation unit elements re-resolved".
I added something to log when resolution is finished, and in the strong mode case nothing is reaching completion.  This suggests that we're doing a fairly breadth-first traversal of the project, which would definitely have bad cache behavior.  If this is the case, the question is whether this is because of something intrinsic to the project (e.g. everything is one massive library cycle), or if the tasks are just not getting scheduled in a cache friendly way.
I'll look at mucking with the AST_CACHING_POLICY when I get a chance to get back to this.

I believe that this only re-creates the state that buildCompilationUnit leaves things in, and that subsequent re-resolution will happen as usual, but I'm not sure

Correct.

Compilation unit elements re-resolved

So yes, that would be the case where we've flushed the AST for a compilation unit and then determined that we still need it.

This suggests that we're doing a fairly breadth-first traversal of the project ...

That's definitely possible. It would be interesting to know which tasks are causing us to have to recreate the resolved AST. We ought to be able to figure that out from the stack of work items currently being worked on.
Increasing the cache size will almost certainly help with this. It would also be interesting to know (a) how large the cache needs to be to avoid needing to recreate flushed ASTs, and (b) the largest cycle in this code base.

One thought that I had last night:  we use code in the task model like the following to express a dependency requirement that certain tasks be run before certain others:
  // Require that full inference be complete for all dependencies of the
  // current library cycle.
  'orderLibraryCycles': LIBRARY_CYCLE_DEPENDENCIES.of(unit).toList(
      (CompilationUnitElementImpl unit) => RESOLVED_UNIT9
          .of(new LibrarySpecificUnit(unit.librarySource, unit.source)))

I believe that this will require the actual RESOLVED_UNIT9 AST to be present, and that this will force it to be re-computed if it is not in cache.  But my understanding is that the element model is never evicted, and in most cases I believe that all we care about is that the task has been run for the dependencies and the element model computed.  So re-resolving the unit itself would be wasted work.  If my understanding here is correct, then we might want to just track whether the unit has been computed, e.g. some sort of RESOLVED_UNIT9_COMPLETE target that doesn't get evicted very easily?
There are a few tasks which I think actually might need the RESOLVED_UNITs themselves, e.g. InferInstanceMembersInUnitsTask, but I'm not sure that this is a good idea in any case.  My sense is that at least that task should be re-structured to avoid traversing outside of the target unit.

Excellent observation! I think you're absolutely right. We should perform a complete audit of the current tasks to make sure that they have the right dependencies. One way to empirically prioritize that task would be to get a list of the tasks that we are gathering resolved ASTs for at the point at which we have to re-create the ASTs.

... my understanding is that the element model is never evicted ...

That's true today, but I expect that to change when the summaries support is added (because it will be less expensive to recreate the element models when we need them).

My sense is that at least [the InferInstanceMembersInUnitsTask] should be re-structured to avoid traversing outside of the target unit.

I don't know that it's necessary to be quite that restrictive, but we should definitely explore the possibility. There's a trade-off we need to be aware of: one way to remove the need for the AST is to store more data in the element model, but that increases the size of the element model, which is a problem at least until we can flush element models. We made that trade-off for evaluation of constants, and I'm OK with making it again, but we have to weigh the cost and benefit.

There are a few tasks which I think actually might need the RESOLVED_UNITs themselves, e.g. InferInstanceMembersInUnitsTask, but I'm not sure that this is a good idea in any case. My sense is that at least that task should be re-structured to avoid traversing outside of the target unit.

FWIW, it looks like the AST is completely unused in InstanceMemberInferrer--it works entirely off the Element model.
(it does jump across libraries though, because it will infer supertypes--the task model doesn't understand that dependency, hence the "hasBeenInferred" flag we need to clear in TypeResolverVisitor)

There actually seem to be some "READY_RESOLVED_UNITX" flags already there.  I did a quick experiment on the plane with replacing uses of RESOLVED_UNIT9 in the various 'orderLibraryCycles' dependency inputs with READY_RESOLVED_UNIT10 and the strong mode time dropped to within a few seconds of the normal analyzer time.  I didn't carefully verify that this exact flag captures all the right dependencies yet, but I think something like this ought to do the trick.
I'd forgotten that the InstanceMemberInferrer just works off the element model, that addresses that concern.

Strong mode analysis for this app now takes 43 seconds on my laptop, vs 24 seconds for regular analysis.

authors: bwilkerson jmesserly leafpetersen skybrian


text:
Better optimization for short-lived Map and List literals

If I want to create a new List, implementation, say LinkedList, that's straightforward enough.
The interesting part is supporting a .from factory constructor and using a list literal, for example:
abstract class LinkedList<T> implements List<T> {
  factory LinkedList.from(List<T> list) {
    var l = new LinkedList._();
    l.addAll(list);
  }
}

So today, in user code, one may write:
new LinkedList.from([
  1,
  2,
  3,
  ...
])

See the problem? We're allocating a new list... Just to throw it away and use it to create a new structure.
This problem is also evident with the map-literal, for example:
abstract class DomElement {
  void setStyle(String name, String value);

  void setStyles(Map<String, String> map) {
    map.forEach(setStyle);
  }
}

domElement.setStyles({
  'color': 'red',
  'height': '50px',
  ...,
})

So on the one-hand we have the nice (JS-land) experience of Map and List literals, but on the other hand we allocate objects just to use their structures, and then they get GCd. Could the dart2js backend (and others?) optimize this away?
For the List example (strawman dart2js):
var l = new LinkedList();
l.add(1);
l.add(2);
l.add(3);
...

For the Map example:
domElement.setStyle('color', 'red');
domElement.setStyle('height', '50px');

I realize it would not always be safe to make these sort of "advanced" inline changes, but in cases where it is safe (i.e. the List or Map literal is created prior to a constructor or method invocation where it is directly used), it would be real nice.

I had a related (and perhaps complementary) feature idea around read-only literals.
Something like
var foo = r[a, b, c];
var bar = r{'a': a};

Where I'm stealing the notion of the r prefix from raw String – although in this case it means readonly.
This would allow folks to create such literals without requiring constant values – and could allow the compiler/VM to make the optimizations your suggest with less fear...

I'm hesitant to add too many optimizations like the ones suggested. The payoff has to be worth the investment.
We do recognize some special cases, e.g. for-in on lists.
Clever optimizations tend to work only some of the time, and it is hard to predict the code you will get.
It is hard to do automatically, e.g. since errors will give you a different call stack, and it is hard to tell there would be no errors. It is usually the job of the compiler to preserve the behaviour of the program :-)
Doing special optimizations can be a big maintenance problem - there is all this code in the compiler that is in effect a second much more complex (partial) implementation of the library and needs to be kept in sync.
Currently dart2js has no special knowledge of LinkedList - it is just code.
If you really care about having the compiled code be a certain way, then you should probably write the source that way. I'd rather invest in language level features that help. For example, cascades help somewhat:
... = new LinkedList()..add(1)..add(2)..add(3)

domElement
  ..setStyle('color', 'red')
  ..setStyle('height', '50px');

Are there other constructs we should be adding to the language that make it easy to express what we want and simpler for the implementation to compile well reliably?
Perhaps new LinkedList<int>[1, 2, 3]
could mean new LinkedList<int>()..add(1)..add(2)..add(3).
This could work for any class with a zero-argument constructor and a add method that allows one argument (Set, Queue etc).
Perhaps we should have list/iterable comprehensions in the language instead of in the library.

I like your suggestion more @rakudrama but I was trying to make it easier for y'all :)
/cc @yjbanov who has also talked about wanting what you suggested.

I'm guessing this is unlikely to be addressed outside of new language features.

I agree. This is too specific in the form provided here (applies to collections with add only).
If we get some notion of var-args, it should be possible to make functions like this work in general, and if the compiler inlines the constructor, it might even be possible to avoid all the intermediate allocations, perhaps reading values directly off the stack instead of allocating a list object.

authors: kevmoo lrhn matanlurey rakudrama


text:
Remove support for @checked once code has been migrated to use covariant

Once major code bases (e.g. Flutter) have migrated to covariant from @checked, we should deprecate and then remove support for @checked.
cc @sethladd

Flutter has migrated via flutter/flutter#8300

I think this can now be done at any point that is convenient.

dart2js doesn't seem to support covariant yet

@zoechi can you elaborate?  It was marked as implemented here: https://github.com/dart-lang/sdk/issues/28165 , so if there's something missing we should follow up on it.  Note though that dart2js just implements the Dart 1.0 semantics, which is just to ignore it (since Dart 1.0 functions are covariant already).

authors: a14n leafpetersen zoechi


text:
Overriding a private property is possible without any warning

I think it is quite dangerous that you can override a private property and there are no warnings or errors or lints. Imagine if you are extending or mixing in a class from a library and happen to use a name that exists in the base class.
https://dartpad.dartlang.org/7f44022aeb0ab5b31958eb23131951af
class StupidA {
  String _value = "Eh";

  // lexically this should always be "Eh", right? but it's really a shortcut for this._value
  // and since StupidB inherits this method, "this" ends up being the instance of StupidB
  // and thus ends up getting "Bee" instead
  String get value => _value;
}

class StupidB extends StupidA {
  // silently overwrites _value in the base class, possibly by accident because we didn't
  // actually know that the base class has a _value field
  String _value = "Bee";
}

void main() {
  var b = new StupidB();
  print(b.value); // prints Bee
}

Here's another example with mixins:
https://dartpad.dartlang.org/498a0539d60b237314661adeabb54b9d
class ClassA {
  String _value = "Eh";

  String get value => _value;
}

class ClassB extends ClassA {
  String _value = "Bee";
}

class ClassC {
  String _value = "Sea";
}

class ClassD extends ClassA with ClassC { }

void main() {
  var b = new ClassB();
  print(b.value); // prints Bee

  var d = new ClassD();
  print(d.value); // prints Sea
}

I'm not sure exactly what it SHOULD do but it feels really dangerous that if you happen to have a private property that has the same name as a base class or mixin that it stomps it without warning.

For the class case (StupidA, StupidB), this is working as intended. The 'private' access level in Dart is scoped to the library (as opposed to, say, Java, where private is scoped to the class and the default access level is scoped to the package). This means that StupidB is able to see and override _value, but only as long as it is in the same library. If a class C in a library L1 defines a member named _value and a subclass D of C in a different library also defines a _value, those two members are simply different, and no overriding takes place. You can think about this as if each library consistently renames all its private members to fresh names. This works as intended, even though it may cause some confusion that 'private' means different things in different languages.
The mixin case is more tricky, because it would be possible for two distinct private members with the same name to be brought together by a third party who uses both of them as mixins:
// In 'foo.dart'.
class M1 { int _value; ... }
class M2 { void _value() {} ... }

// In 'bar.dart'.
import 'foo.dart';
class C extends Whatever with M1, M2 { ... }

The class C brings together two unrelated declarations of _value. That matters even though C does not have access to any of the _value members. That mixin application would create a class C where _value-from-'foo.dart' has two conflicting declarations, and the implementations of methods inherited from M1 and M2 may require "their own declaration" of _value in order to work correctly. So that kind of conflict should be prevented. The Dart specification and tools have known problems in this area, and they are currently being fixed, e.g., #28809, #29751.

authors: eernstg robbecker-wf


text:
Forwarding stubs do not handle default parameter values correctly

Consider the following code (which I'll be submitting as a test case shortly):
class B {
  Object _x;
  void f([num x = 10]) {
    _x = x;
  }
  void g({num x = 20}) {
    _x = x;
  }
  void check(Object expectedValue) {
    if (_x != expectedValue) {
      throw 'Expected _x == $expectedValue; got $_x';
    }
  }
}
abstract class I<T> {
  void f([T x]);
  void g({T x});
}
class C extends B implements I<num> {}
main() {
  C c = new C();
  c.f();
  c.check(10);
  c.g();
  c.check(20);
}

This test fails with the current front end, because when the front end generates forwarding stubs for the class C, it doesn't preserve the default values from B::f and B::g.  The front end is adding these methods to the kernel representation of class C:
forwarding-stub method f([generic-covariant-impl core::num x]) → void
  return super.{self::B::f}(x);
forwarding-stub method g({generic-covariant-impl core::num x}) → void
  return super.{self::B::g}(x: x);

(Note the absence of default values for the x parameters).  We could fix the bug by copying over the default values from class B, but that would lead to problems with modular compilation, since we don't want to have to preserve default parameter values in summaries.  It would be much nicer if we could fix this bug my having a special representation of forwarding stubs in kernel, and let the back end take care of doing the right thing with default parameter values.
@kmillikin I understand you're thinking of making a similar change to how redirecting constructors are represented, for similar reasons.  What do you think?

@stereotype441 Is this required for Dart2Stable?

@dgrove I don't really know the status of this bug.  @sjindel-google, is it possible that this bug has been fixed?

I'm addressing this in CL 64540 by cloning the default values from the procedure the forwarder was generated for.

Note that CL 64540 doesn't address the modular compilation issue described in the original bug description--that issue is now being tracked in #33820.

authors: dgrove stefantsov stereotype441


text:
Dart pad and dartanalyzer bug, -i instead of --i does not produce a warning.

The following code freezes dartpad and does not produce a warning:

void main() {
for(int i=5;i>0;-i){
print('hi');
};
}

Running a similar code offline:
dartanalyzer detects +i and produce the following warning:
error • Expected an identifier at test.dart:14:35 • missing_identifier
But ignores -i.
Dart VM version: 1.24.2 (Thu Jun 22 15:42:21 2017) on "linux_x64"
dartanalyzer --version   dartanalyzer version 1.24.2

Analyzer doesn't produce an error because -i is a valid expression. The value of that expression is to apply the unary operator - to the value of i, which in the case of integers will return an integer with an equal magnitude and opposite sign. It produces an error for +i because the language does not support a unary + operator.
While it would be nice if analyzer could detect which expressions have a side-effect, that kind of analysis is not currently supported.

Thanks for explaining, it all makes sense now.
-i is a valid expression,  I get what you mean and you are right but -i in ,for(int i=10;i>=0;-i) is also not a valid expression in the context...
Since GCC throws the following for a similar input:
 warning: statement with no effect [-Wunused-value]
     for(int tes=50;tes>0;-tes){
     ^

I have a feeling the dart analyzer surprises some users.
Not a high priority matter that I agree though.

authors: TastyCatFood bwilkerson


text:
rxvt-unicode not recognized as supporting ANSI escapes

When TERM=rxvt-unicode, Stdout.supportsAnsiEscapes returns false, but should return true.

Duplicate of https://github.com/dart-lang/sdk/issues/31606

authors: Hixie natebosch


text:
All backends crash on recursive const expressions

The test co19_2/Language/Expressions/Constants/depending_on_itself_t03 contains the code:
class A {
  const A();
  final m = const A();
}

Since Fasta does not perform constant evaluation (see #32517) this code is passed on to the backends.
Both dart2js and the VM crash with a stack overflow (a native one in the case of the VM, resulting in a segmentation fault), and dartdevk gives a spurious error which looks more like a failure to report the actual error:
Invalid argument(s): Uri org-dartlang-app:/tests/co19_2/src/Language/Expressions/Constants/depending_on_itself_t03.dart must have scheme 'file:'.

A cyclic constant expression dependency with no constant variables involved. Very clever. Very, very clever.
The spec says that it's a compile-time error if the value of a compile-time expression depends on itself, so this should be a compile-time error. I'm not sure we had considered this way of getting the error before.

This seems like a duplicate of https://github.com/dart-lang/sdk/issues/34204.
The front end team has plans to implement constant evaluation in the front end this quarter and so we will not work on this issue in the VM backend.

(reopened because we temporarily disabled the constant-update-2018 experiment)

Closing because there is no more work to do on this except flipping the flag. This will give us a better overview of remaining issues.

authors: a-siva askeksa-google lrhn sigmundch


text:
"Internal problem: Unhandled DartType in push"

I started the analyzer while I was in the middle of dealing with a large number of conflicts, and it crashed:
Crash when compiling package:flutter_tools/src/base/io.dart,
at character offset null:
packages/flutter_tools/lib/src/base/io.dart:1: Internal problem: Unhandled DartType in push.
#0      internalProblem (package:front_end/src/fasta/problems.dart:32:3)
#1      unhandled (package:front_end/src/fasta/problems.dart:45:10)
#2      BodyBuilder.push (package:front_end/src/fasta/kernel/body_builder.dart:273:7)
#3      BodyBuilder.handleType (package:front_end/src/fasta/kernel/body_builder.dart:2297:9)
#4      PrefixedType.parseType (package:front_end/src/fasta/parser/type_info_impl.dart:148:14)
#5      Parser.parseFields (package:front_end/src/fasta/parser/parser.dart:2220:28)
#6      Parser.parseClassOrMixinMemberImpl (package:front_end/src/fasta/parser/parser.dart:2899:15)
#7      Parser.parseClassOrMixinMember (package:front_end/src/fasta/parser/parser.dart:2710:12)
#8      DietListener.parseFields (package:front_end/src/fasta/source/diet_listener.dart:846:22)
#9      DietListener.buildFields (package:front_end/src/fasta/source/diet_listener.dart:653:5)
#10     DietListener.endFields (package:front_end/src/fasta/source/diet_listener.dart:281:5)
#11     Parser.parseFields (package:front_end/src/fasta/parser/parser.dart:2240:16)
#12     Parser.parseClassOrMixinMemberImpl (package:front_end/src/fasta/parser/parser.dart:2899:15)
#13     Parser.parseClassOrMixinBody (package:front_end/src/fasta/parser/parser.dart:2689:15)
#14     Parser.parseClass (package:front_end/src/fasta/parser/parser.dart:1708:13)
#15     Parser.parseClassOrNamedMixinApplication (package:front_end/src/fasta/parser/parser.dart:1668:14)
#16     Parser.parseTopLevelKeywordDeclaration (package:front_end/src/fasta/parser/parser.dart:563:14)
#17     Parser.parseTopLevelDeclarationImpl (package:front_end/src/fasta/parser/parser.dart:455:14)
#18     Parser.parseUnit (package:front_end/src/fasta/parser/parser.dart:334:15)
#19     SourceLoader.buildBody (package:front_end/src/fasta/source/source_loader.dart:253:14)
<asynchronous suspension>
#20     Loader.buildBodies (package:front_end/src/fasta/loader.dart:181:15)
<asynchronous suspension>
#21     KernelTarget.buildComponent.<anonymous closure> (package:front_end/src/fasta/kernel/kernel_target.dart:298:24)
<asynchronous suspension>
#22     withCrashReporting (package:front_end/src/fasta/deprecated_problems.dart:69:24)
<asynchronous suspension>
#23     KernelTarget.buildComponent (package:front_end/src/fasta/kernel/kernel_target.dart:295:12)
<asynchronous suspension>
#24     generateKernelInternal.<anonymous closure> (package:front_end/src/kernel_generator_impl.dart:150:42)
<asynchronous suspension>
#25     withCrashReporting (package:front_end/src/fasta/deprecated_problems.dart:69:24)
<asynchronous suspension>
#26     generateKernelInternal (package:front_end/src/kernel_generator_impl.dart:57:10)
<asynchronous suspension>
#27     generateKernel.<anonymous closure> (package:front_end/src/kernel_generator_impl.dart:42:18)
<asynchronous suspension>
#28     CompilerContext.runWithOptions.<anonymous closure> (package:front_end/src/fasta/compiler_context.dart:130:20)
<asynchronous suspension>
#29     CompilerContext.runInContext.<anonymous closure>.<anonymous closure> (package:front_end/src/fasta/compiler_context.dart:118:46)
#30     new Future.sync (dart:async/future.dart:224:31)
#31     CompilerContext.runInContext.<anonymous closure> (package:front_end/src/fasta/compiler_context.dart:118:19)
#32     _rootRun (dart:async/zone.dart:1124:13)
#33     _CustomZone.run (dart:async/zone.dart:1021:19)
#34     _runZoned (dart:async/zone.dart:1516:10)
#35     runZoned (dart:async/zone.dart:1463:12)
#36     CompilerContext.runInContext (package:front_end/src/fasta/compiler_context.dart:117:12)
#37     CompilerContext.runWithOptions (package:front_end/src/fasta/compiler_context.dart:128:10)
#38     generateKernel (package:front_end/src/kernel_generator_impl.dart:41:32)
<asynchronous suspension>
#39     kernelForComponent (package:front_end/src/api_prototype/kernel_generator.dart:83:17)
<asynchronous suspension>
#40     SingleShotCompilerWrapper.compileInternal (file:///b/build/slave/Linux_Engine/build/src/third_party/dart/pkg/vm/bin/kernel_service.dart:186:11)
<asynchronous suspension>
#41     Compiler.compile.<anonymous closure> (file:///b/build/slave/Linux_Engine/build/src/third_party/dart/pkg/vm/bin/kernel_service.dart:134:39)
#42     new Future.<anonymous closure> (dart:async/future.dart:176:37)
#43     _rootRun (dart:async/zone.dart:1120:38)
#44     _CustomZone.run (dart:async/zone.dart:1021:19)
#45     _CustomZone.runGuarded (dart:async/zone.dart:923:7)
#46     _CustomZone.bindCallbackGuarded.<anonymous closure> (dart:async/zone.dart:963:23)
#47     _rootRun (dart:async/zone.dart:1124:13)
#48     _CustomZone.run (dart:async/zone.dart:1021:19)
#49     _CustomZone.bindCallback.<anonymous closure> (dart:async/zone.dart:947:23)
#50     Timer._createTimer.<anonymous closure> (dart:async/runtime/libtimer_patch.dart:21:15)
#51     _Timer._runTimers (dart:isolate/runtime/libtimer_impl.dart:382:19)
#52     _Timer._handleMessage (dart:isolate/runtime/libtimer_impl.dart:416:5)
#53     _RawReceivePortImpl._handleMessage (dart:isolate/runtime/libisolate_patch.dart:171:12)

I don't have a good way to give you the actual state of my branch since I'm literally mid-merge, but I guess try adding a bunch of merge markers everywhere...

Hmm, this will be hard to reproduce exactly.  But looking at the code there does seem to be a problem.  https://github.com/dart-lang/sdk/commit/00ceb8e3592f125b5627df4341e95dedbb4c05f6 made it so the body builder's stack didn't contain Dart types, but https://github.com/dart-lang/sdk/blob/master/pkg/front_end/lib/src/fasta/kernel/body_builder.dart#L2335 seems like it needs to be updated.  @peter-ahe-google can you take a look?

Sorry about that. I'll get right on it.

Repro:
class Dupe {}

class Dupe {}

class C {
  Dupe.a b;
}

Proposed fix: https://dart-review.googlesource.com/c/sdk/+/77802

authors: Hixie kmillikin peter-ahe-google


text:
[vm/mirrors] Out of bounds memory read using private dart:core functionality

Program below demonstrates an out-of-bounds memory read primitive. In particular, I'm able to read memory relative to any string object's char data.
import "dart:mirrors";

main() {
  var libs = currentMirrorSystem().libraries;
  var core = libs[Uri(scheme: "dart", path: "core")];

  var rx = RegExp("(bar)");
  rx.firstMatch("foobar"); // dummy match to compute _groupCount

  ClassMirror mirrorRegExpMatch;
  for (var d in core.declarations.entries) {
    if (d.key.toString() == Symbol("_RegExpMatch").toString()) {
      mirrorRegExpMatch = d.value as ClassMirror;
    }
  }

  var match = mirrorRegExpMatch.newInstance(Symbol(""), [rx, "foo", [1024, 1088]]).reflectee as RegExpMatch;
  var z = match.group(0);
  print(z.codeUnits); // prints 64 random bytes of heap memory
}

The underlying issue here is that _RegExpMatch.group uses String._substringUnchecked to slice the matched string into substrings. It assumes that _RegExpMatch objects will only be created by _RegExp itself and thus indices will be in bounds.
There's some VM logic to prevent dart:mirrors from accessing private declarations within dart: packages, but this doesn't prevent accessing either private top-level classes or their default constructors.
/cc @crelier @rmacnak-google

@rmacnak-google Thanks for the quick CL.
Relatedly, I notice that dart:mirrors can be used to access and mutate private global variables within libraries. Is that by design or an oversight? Script below identifies 20 such variables.
I couldn't immediately find any ways to take advantage of this, but I was able to trigger crashes through things like manipulating _stdinFD.
import 'dart:mirrors';

main() {
  var libs = currentMirrorSystem().libraries;
  for (var e in libs.entries) {
    if (e.key.scheme != "dart") {
      continue;
    }
    print("# ${e.key.path}");

    for (var d in e.value.declarations.entries) {
      if (!d.key.toString().startsWith('Symbol("_') ||
          !(d.value is VariableMirror)) {
        continue;
      }
      VariableMirror m = d.value as VariableMirror;
      if (m.isConst || m.isFinal) {
        continue;
      }
      print("${d.key} -> ${e.value.getField(d.key).reflectee}");
    }
    print("");
  }
}

Test script below creates more private Dart core library classes using default factories:
import "dart:mirrors";

V getPrivate<V>(Map<Symbol, V> m, String name) {
  String mangled = Symbol(name).toString();
  for (var e in m.entries) {
    if (e.key.toString() == mangled) {
      return e.value;
    }
  }
  return null;
}

tryMake(Map<Symbol, DeclarationMirror> decls, String name) {
  try {
    var cls = getPrivate(decls, name) as ClassMirror;
    return cls.newInstance(Symbol(""), []).reflectee;
  } catch (e) {
    return e;
  }
}

main() {
  var libs = currentMirrorSystem().libraries;
  var core = libs[Uri(scheme: "dart", path: "isolate")];

  print(tryMake(core.declarations, "_CapabilityImpl"));
  print(tryMake(core.declarations, "_ReceivePortImpl"));
  print(tryMake(core.declarations, "_SendPortImpl"));
}

Notably creating ReceivePortImpl prevents the Dart VM from shutting down normally. I'm guessing because the Isolate is waiting for all of its Ports to shutdown first.
Being able to create SendPortImpl seems scary too. It appears to be reading a bogus Dart_Port value out of the heap, so there's a risk it could allow sending messages to arbitrary receivers. However, this seems mitigated that (1) it appears to always read the same Dart_Port value (so you can't keep retrying until you get a useful one), and (2) PortMap::AllocatePort only allocates 30-bit Dart_Port values, whereas the garbage Dart_Port values read from the heap always seem to be much larger. Maybe an attacker can indirectly control those 64-bits of memory though.

@rmacnak-google will send a CL addressing this.
However, dart:mirrors are not available in security critical deployments. The team is actually more worried by possible vulnerabilities in dart:io.

The constructors for _CapabilityImpl and _ReceiverPortImpl are harness; they are publicly available as Capability and ReceivePort. The _SendPortImpl constructor is dangerous because it allows reinterpreting the address of null as a port id.

authors: crelier mdempsky rmacnak-google