text:
🛑 volkstanz.st is down

In af74c01, volkstanz.st (https://volkstanz.st) was down:

HTTP code: 0
Response time: 0 ms

Resolved: volkstanz.st is back up in db8c879.


text:
🛑 kinderundjugendtanz.at is down

In b21284a, kinderundjugendtanz.at (https://kinderundjugendtanz.at) was down:

HTTP code: 0
Response time: 0 ms

Resolved: kinderundjugendtanz.at is back up in d07de34.

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
🛑 kinderundjugendtanz.at is down

In ecfc34a, kinderundjugendtanz.at (https://kinderundjugendtanz.at) was down:

HTTP code: 0
Response time: 0 ms

Resolved: kinderundjugendtanz.at is back up in a72f1fe.


text:
🛑 volkstanz.st is down

In 6d0ed16, volkstanz.st (https://volkstanz.st) was down:

HTTP code: 0
Response time: 0 ms

Resolved: volkstanz.st is back up in 1431818.


text:
🛑 andritz.me is down

In 8597429, andritz.me (https://andritz.me) was down:

HTTP code: 0
Response time: 0 ms

Resolved: andritz.me is back up in c937445.


text:
🛑 volkstanzwannwo.at is down

In b6e461b, volkstanzwannwo.at (https://volkstanzwannwo.at) was down:

HTTP code: 0
Response time: 0 ms

Resolved: volkstanzwannwo.at is back up in a96c7fa after 12 minutes.


text:
homebridge-enphase-envoy v4.6.15-beta.18

[3/2/2021, 9:20:42 AM] [enphaseEnvoy] Device: 192.168.2.25 Envoy-S, requesting devices info eror: TypeError: Cannot read property 'state' of undefined
    at envoyDevice.getDeviceInfo (/homebridge/node_modules/homebridge-enphase-envoy/index.js:1469:49), state: Offline trying to reconnect.

I can see in the log it connects somewaht to the Envoy-S but not completely and plugin is not working in EVE app
Here the complete log:
[3/2/2021, 9:25:57 AM] [enphaseEnvoy] Device 192.168.2.25 Envoy-S, get devices data inventory: [ [Object], [Object], [Object] ] info: <?xml version='1.0' encoding='UTF-8'?>
<envoy_info>
  <time>1614673546</time>
  <device>
    <sn>121921106049</sn>
    <pn>800-00553-r02</pn>
    <software>R4.10.35</software>
    <euaid>4c8675</euaid>
    <seqnum>0</seqnum>
    <apiver>1</apiver>
    <imeter>false</imeter>
  </device>
  <package name='rootfs'>
    <pn>500-00001-r01</pn>
    <version>02.00.00</version>
    <build>945</build>
  </package>
  <package name='kernel'>
    <pn>500-00011-r01</pn>
    <version>04.00.00</version>
    <build>5bb754</build>
  </package>
  <package name='boot'>
    <pn>590-00018-r01</pn>
    <version>02.00.01</version>
    <build>426697</build>
  </package>
  <package name='app'>
    <pn>500-00002-r01</pn>
    <version>04.10.35</version>
    <build>6ed292</build>
  </package>
  <package name='devimg'>
    <pn>500-00005-r01</pn>
    <version>01.02.186</version>
    <build>d0d70f</build>
  </package>
  <package name='geo'>
    <pn>500-00008-r01</pn>
    <version>02.01.22</version>
    <build>06e201</build>
  </package>
  <package name='backbone'>
    <pn>500-00010-r01</pn>
    <version>04.10.25</version>
    <build>7b7de5</build>
  </package>
  <package name='meter'>
    <pn>500-00013-r01</pn>
    <version>03.02.07</version>
    <build>4c9d48</build>
  </package>
  <package name='agf'>
    <pn>500-00012-r01</pn>
    <version>02.02.00</version>
    <build>c00a8f</build>
  </package>
  <package name='security'>
    <pn>500-00016-r01</pn>
    <version>02.00.00</version>
    <build>54a6dc</build>
  </package>
  <build_info>
    <build_time_gmt>1542157882</build_time_gmt>
    <build_id>release-4.10.x-103-Nov-12-18-18:25:06</build_id>
  </build_info>
</envoy_info>
 meters: []
[3/2/2021, 9:25:57 AM] [enphaseEnvoy] Device: 192.168.2.25 Envoy-S, parse info.xml successful: {
  "envoy_info": {
    "time": [
      "1614673546"
    ],
    "device": [
      {
        "sn": [
          "121921106049"
        ],
        "pn": [
          "800-00553-r02"
        ],
        "software": [
          "R4.10.35"
        ],
        "euaid": [
          "4c8675"
        ],
        "seqnum": [
          "0"
        ],
        "apiver": [
          "1"
        ],
        "imeter": [
          "false"
        ]
      }
    ],
    "package": [
      {
        "$": {
          "name": "rootfs"
        },
        "pn": [
          "500-00001-r01"
        ],
        "version": [
          "02.00.00"
        ],
        "build": [
          "945"
        ]
      },
      {
        "$": {
          "name": "kernel"
        },
        "pn": [
          "500-00011-r01"
        ],
        "version": [
          "04.00.00"
        ],
        "build": [
          "5bb754"
        ]
      },
      {
        "$": {
          "name": "boot"
        },
        "pn": [
          "590-00018-r01"
        ],
        "version": [
          "02.00.01"
        ],
        "build": [
          "426697"
        ]
      },
      {
        "$": {
          "name": "app"
        },
        "pn": [
          "500-00002-r01"
        ],
        "version": [
          "04.10.35"
        ],
        "build": [
          "6ed292"
        ]
      },
      {
        "$": {
          "name": "devimg"
        },
        "pn": [
          "500-00005-r01"
        ],
        "version": [
          "01.02.186"
        ],
        "build": [
          "d0d70f"
        ]
      },
      {
        "$": {
          "name": "geo"
        },
        "pn": [
          "500-00008-r01"
        ],
        "version": [
          "02.01.22"
        ],
        "build": [
          "06e201"
        ]
      },
      {
        "$": {
          "name": "backbone"
        },
        "pn": [
          "500-00010-r01"
        ],
        "version": [
          "04.10.25"
        ],
        "build": [
          "7b7de5"
        ]
      },
      {
        "$": {
          "name": "meter"
        },
        "pn": [
          "500-00013-r01"
        ],
        "version": [
          "03.02.07"
        ],
        "build": [
          "4c9d48"
        ]
      },
      {
        "$": {
          "name": "agf"
        },
        "pn": [
          "500-00012-r01"
        ],
        "version": [
          "02.02.00"
        ],
        "build": [
          "c00a8f"
        ]
      },
      {
        "$": {
          "name": "security"
        },
        "pn": [
          "500-00016-r01"
        ],
        "version": [
          "02.00.00"
        ],
        "build": [
          "54a6dc"
        ]
      }
    ],
    "build_info": [
      {
        "build_time_gmt": [
          "1542157882"
        ],
        "build_id": [
          "release-4.10.x-103-Nov-12-18-18:25:06"
        ]
      }
    ]
  }
}
[3/2/2021, 9:25:57 AM] [enphaseEnvoy] Device: 192.168.2.25 Envoy-S, saved Device Info successful.
[3/2/2021, 9:25:57 AM] [enphaseEnvoy] Device: 192.168.2.25 Envoy-S, requesting devices info eror: TypeError: Cannot read property 'state' of undefined
    at envoyDevice.getDeviceInfo (/homebridge/node_modules/homebridge-enphase-envoy/index.js:1469:49), state: Offline trying to reconnect.

Rolled back to 4.6.14 and no errors and EVE is working
CMD: npm install --save homebridge-enphase-envoy@4.6.14
[3/2/2021, 9:28:34 AM] [enphaseEnvoy] Device 192.168.2.25 Envoy-S, get devices data inventory: [ [Object], [Object], [Object] ] info: <?xml version='1.0' encoding='UTF-8'?>
<envoy_info>
  <time>1614673703</time>
  <device>
    <sn>121921106049</sn>
    <pn>800-00553-r02</pn>
    <software>R4.10.35</software>
    <euaid>4c8675</euaid>
    <seqnum>0</seqnum>
    <apiver>1</apiver>
    <imeter>false</imeter>
  </device>
  <package name='rootfs'>
    <pn>500-00001-r01</pn>
    <version>02.00.00</version>
    <build>945</build>
  </package>
  <package name='kernel'>
    <pn>500-00011-r01</pn>
    <version>04.00.00</version>
    <build>5bb754</build>
  </package>
  <package name='boot'>
    <pn>590-00018-r01</pn>
    <version>02.00.01</version>
    <build>426697</build>
  </package>
  <package name='app'>
    <pn>500-00002-r01</pn>
    <version>04.10.35</version>
    <build>6ed292</build>
  </package>
  <package name='devimg'>
    <pn>500-00005-r01</pn>
    <version>01.02.186</version>
    <build>d0d70f</build>
  </package>
  <package name='geo'>
    <pn>500-00008-r01</pn>
    <version>02.01.22</version>
    <build>06e201</build>
  </package>
  <package name='backbone'>
    <pn>500-00010-r01</pn>
    <version>04.10.25</version>
    <build>7b7de5</build>
  </package>
  <package name='meter'>
    <pn>500-00013-r01</pn>
    <version>03.02.07</version>
    <build>4c9d48</build>
  </package>
  <package name='agf'>
    <pn>500-00012-r01</pn>
    <version>02.02.00</version>
    <build>c00a8f</build>
  </package>
  <package name='security'>
    <pn>500-00016-r01</pn>
    <version>02.00.00</version>
    <build>54a6dc</build>
  </package>
  <build_info>
    <build_time_gmt>1542157882</build_time_gmt>
    <build_id>release-4.10.x-103-Nov-12-18-18:25:06</build_id>
  </build_info>
</envoy_info>
 meters: []
[3/2/2021, 9:28:34 AM] [enphaseEnvoy] Device: 192.168.2.25 Envoy-S, parse info.xml successful: {
  "envoy_info": {
    "time": [
      "1614673703"
    ],
    "device": [
      {
        "sn": [
          "121921106049"
        ],
        "pn": [
          "800-00553-r02"
        ],
        "software": [
          "R4.10.35"
        ],
        "euaid": [
          "4c8675"
        ],
        "seqnum": [
          "0"
        ],
        "apiver": [
          "1"
        ],
        "imeter": [
          "false"
        ]
      }
    ],
    "package": [
      {
        "$": {
          "name": "rootfs"
        },
        "pn": [
          "500-00001-r01"
        ],
        "version": [
          "02.00.00"
        ],
        "build": [
          "945"
        ]
      },
      {
        "$": {
          "name": "kernel"
        },
        "pn": [
          "500-00011-r01"
        ],
        "version": [
          "04.00.00"
        ],
        "build": [
          "5bb754"
        ]
      },
      {
        "$": {
          "name": "boot"
        },
        "pn": [
          "590-00018-r01"
        ],
        "version": [
          "02.00.01"
        ],
        "build": [
          "426697"
        ]
      },
      {
        "$": {
          "name": "app"
        },
        "pn": [
          "500-00002-r01"
        ],
        "version": [
          "04.10.35"
        ],
        "build": [
          "6ed292"
        ]
      },
      {
        "$": {
          "name": "devimg"
        },
        "pn": [
          "500-00005-r01"
        ],
        "version": [
          "01.02.186"
        ],
        "build": [
          "d0d70f"
        ]
      },
      {
        "$": {
          "name": "geo"
        },
        "pn": [
          "500-00008-r01"
        ],
        "version": [
          "02.01.22"
        ],
        "build": [
          "06e201"
        ]
      },
      {
        "$": {
          "name": "backbone"
        },
        "pn": [
          "500-00010-r01"
        ],
        "version": [
          "04.10.25"
        ],
        "build": [
          "7b7de5"
        ]
      },
      {
        "$": {
          "name": "meter"
        },
        "pn": [
          "500-00013-r01"
        ],
        "version": [
          "03.02.07"
        ],
        "build": [
          "4c9d48"
        ]
      },
      {
        "$": {
          "name": "agf"
        },
        "pn": [
          "500-00012-r01"
        ],
        "version": [
          "02.02.00"
        ],
        "build": [
          "c00a8f"
        ]
      },
      {
        "$": {
          "name": "security"
        },
        "pn": [
          "500-00016-r01"
        ],
        "version": [
          "02.00.00"
        ],
        "build": [
          "54a6dc"
        ]
      }
    ],
    "build_info": [
      {
        "build_time_gmt": [
          "1542157882"
        ],
        "build_id": [
          "release-4.10.x-103-Nov-12-18-18:25:06"
        ]
      }
    ]
  }
}
[3/2/2021, 9:28:34 AM] [enphaseEnvoy] Device: 192.168.2.25 Envoy-S, saved Device Info successful.
[3/2/2021, 9:28:34 AM] [enphaseEnvoy] -------- Envoy-S --------
[3/2/2021, 9:28:34 AM] [enphaseEnvoy] Manufacturer: Enphase
[3/2/2021, 9:28:34 AM] [enphaseEnvoy] Model: Envoy
[3/2/2021, 9:28:34 AM] [enphaseEnvoy] Meters: 0
[3/2/2021, 9:28:34 AM] [enphaseEnvoy] Q-Relays: 1
[3/2/2021, 9:28:34 AM] [enphaseEnvoy] Encharges: 0
[3/2/2021, 9:28:34 AM] [enphaseEnvoy] Inverters: 14
[3/2/2021, 9:28:34 AM] [enphaseEnvoy] Firmware: R4.10.35
[3/2/2021, 9:28:34 AM] [enphaseEnvoy] SerialNr: 121921106049
[3/2/2021, 9:28:34 AM] [enphaseEnvoy] Time: 3/2/2021, 9:28:23 AM
[3/2/2021, 9:28:34 AM] [enphaseEnvoy] ----------------------------------
[3/2/2021, 9:28:40 AM] [enphaseEnvoy] Debug home: {
  software_build_epoch: 1542074240,
  is_nonvoy: false,
  db_size: '39 MB',
  db_percent_full: '10',
  timezone: 'Europe/Brussels',
  current_date: '03/02/2021',
  current_time: '09:28',
  network: [Object],
  tariff: 'none',
  comm: [Object],
  alerts: [],
  update_status: 'satisfied'
}, inventory: [ [Object], [Object], [Object] ], meters: [], production: {
  wattHoursToday: 191,
  wattHoursSevenDays: 55876,
  wattHoursLifetime: 5035270,
  wattsNow: 187
} productionCT: { production: [Array], storage: [Array] }
[3/2/2021, 9:28:42 AM] [enphaseEnvoy] Debug pcuCommCheck: {
  '121932043894': 3,
  '121932016547': 3,
  '121932034199': 3,
  '121932033746': 4,
  '121932016549': 3,
  '121932039512': 3,
  '121932038960': 4,
  '121932043380': 4,
  '121932039459': 4,
  '121910052727': 3,
  '121932039006': 4,
  '121931158966': 3,
  '121932035604': 3,
  '121931157713': 4,
  '121932039565': 4
}
[3/2/2021, 9:28:42 AM] [enphaseEnvoy] Debug production inverters: [
  [Object], [Object],
  [Object], [Object],
  [Object], [Object],
  [Object], [Object],
  [Object], [Object],
  [Object], [Object],
  [Object], [Object]
]
[3/2/2021, 9:28:42 AM] [enphaseEnvoy] Device: 192.168.2.25 Envoy-S, savedProductionPowerMax: 3.445 kW
[3/2/2021, 9:28:42 AM] [enphaseEnvoy] Device: 192.168.2.25 Envoy-S, productionPowerMax: 3.445 kW
[3/2/2021, 9:28:42 AM] [enphaseEnvoy] prepareAccessory
[3/2/2021, 9:28:42 AM] [enphaseEnvoy] prepareInformationService
[3/2/2021, 9:28:42 AM] [enphaseEnvoy] prepareEnphaseServices
[3/2/2021, 9:28:43 AM] [enphaseEnvoy] Device: 192.168.2.25, publishExternalAccessories: Envoy-S.

Try beta 19

Try beta 19

Thanks! Fixed
[3/2/2021, 11:56:50 AM] [enphaseEnvoy] Device: 192.168.2.25 Envoy-S, saved Device Info successful.
[3/2/2021, 11:56:50 AM] [enphaseEnvoy] -------- Envoy-S --------
[3/2/2021, 11:56:50 AM] [enphaseEnvoy] Manufacturer: Enphase
[3/2/2021, 11:56:50 AM] [enphaseEnvoy] Model: Envoy
[3/2/2021, 11:56:50 AM] [enphaseEnvoy] Api ver: 1
[3/2/2021, 11:56:50 AM] [enphaseEnvoy] Firmware: R4.10.35
[3/2/2021, 11:56:50 AM] [enphaseEnvoy] SerialNr: 121921106049
[3/2/2021, 11:56:50 AM] [enphaseEnvoy] Time: 3/2/2021, 11:56:39 AM
[3/2/2021, 11:56:50 AM] [enphaseEnvoy] ------------------------------
[3/2/2021, 11:56:50 AM] [enphaseEnvoy] Meters: No
[3/2/2021, 11:56:50 AM] [enphaseEnvoy] Q-Relays: 1
[3/2/2021, 11:56:50 AM] [enphaseEnvoy] Encharges: 0
[3/2/2021, 11:56:50 AM] [enphaseEnvoy] Inverters: 14
[3/2/2021, 11:56:50 AM] [enphaseEnvoy] ------------------------------

Beta 20 will identify your envoy correct

Just as info, if U have Mac device then the Controller app is now available also for Mac.

Beta 20 will identify your envoy correct

Is this correct?
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] -------- Envoy-S --------
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Manufacturer: Enphase
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Model: ENV-S-WB-230
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Api ver: 1
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Firmware: R4.10.35
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] SerialNr: 121921106049
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Time: 3/2/2021, 12:06:45 PM
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] ------------------------------
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Meters: No
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Q-Relays: 1
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Encharges: 0
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Inverters: 14
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] ------------------------------

Just as info, if U have Mac device then the Controller app is now available also for Mac.

I have a mac. Are you pointing to the bitbar solution with homebrew?

Y do not need home brew just look in the Mac App Store for Controller app

Beta 20 will identify your envoy correct

Is this correct?
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] -------- Envoy-S --------
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Manufacturer: Enphase
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Model: ENV-S-WB-230
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Api ver: 1
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Firmware: R4.10.35
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] SerialNr: 121921106049
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Time: 3/2/2021, 12:06:45 PM
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] ------------------------------
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Meters: No
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Q-Relays: 1
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Encharges: 0
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] Inverters: 14
[3/2/2021, 12:06:56 PM] [enphaseEnvoy] ------------------------------

Yes it is correct Envoy-S Standard EU

Just as info, if U have Mac device then the Controller app is now available also for Mac.

I have a mac. Are you pointing to the bitbar solution with homebrew?

Regarding homebrew just try the command from readme in Mac console.

You do not need homebrew just look in the Mac App Store for Controller app. Since today is also available for mac

I can't find it, do you have a link?

https://apps.apple.com/us/app/controller-for-homekit/id1198176727

authors: cloudkucooland grzegorz914 hoefs


text:
Url stream

Olá amigo primeiramente muito obrigado por compartilhar seu conhecimento. Parabéns pelo script.
Ele caiu como uma luva para meu projeto Android com webservice e estou utilizando seu player como home na web.
Amigo a minha dúvida seria a seguinte mesmo usando uma url válida a capa do álbum nome do artista e música não é exibido nem mesmo a letra. Como é recepcionado o nome da música? Lembrando que já criei a chave de api do vagalume mas não mostra a letra, em qualquer url que tenha testado somente na url de stream que disponibilizou no exemplo.

Existe algum critério? Algo que deixei passar mas sempre que volto a url padrão ela funciona tudo, capa artista música e letra.

Desde já agradeço pela ajuda amigo.

Olá, @Jsaiao. Fico feliz que tenha gostado.
Ao colocar a url do seu streaming, você está colocando no formato http://url:porta sem / no final? E qual a versão do SHOUTCast está usando? Qualquer dúvida estou disponível para ajudar.

authors: Jsaiao gsavio


text:
Error: Cannot find module 'qrCode-terminal' in my project

glaucio@ ~/workspace/glaucio/redirecionarMsgsWhatsAppRodolpho (main) $ npm start

robo@1.0.0 start /home/glaucio/workspace/glaucio/redirecionarMsgsWhatsAppRodolpho
node src/index.js

internal/modules/cjs/loader.js:818
throw err;
^
Error: Cannot find module 'qrCode-terminal'
Require stack:

/home/glaucio/workspace/glaucio/redirecionarMsgsWhatsAppRodolpho/src/services/showQrCodeOnTerminal.js
/home/glaucio/workspace/glaucio/redirecionarMsgsWhatsAppRodolpho/src/services/index.js
/home/glaucio/workspace/glaucio/redirecionarMsgsWhatsAppRodolpho/src/index.js
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:815:15)
at Function.Module._load (internal/modules/cjs/loader.js:667:27)
at Module.require (internal/modules/cjs/loader.js:887:19)
at require (internal/modules/cjs/helpers.js:74:18)
at Object. (/home/glaucio/workspace/glaucio/redirecionarMsgsWhatsAppRodolpho/src/services/showQrCodeOnTerminal.js:1:16)
at Module._compile (internal/modules/cjs/loader.js:999:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14)
at Module.require (internal/modules/cjs/loader.js:887:19) {
code: 'MODULE_NOT_FOUND',
requireStack: [
'/home/glaucio/workspace/glaucio/redirecionarMsgsWhatsAppRodolpho/src/services/showQrCodeOnTerminal.js',
'/home/glaucio/workspace/glaucio/redirecionarMsgsWhatsAppRodolpho/src/services/index.js',
'/home/glaucio/workspace/glaucio/redirecionarMsgsWhatsAppRodolpho/src/index.js'
]
}
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! robo@1.0.0 start: node src/index.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the robo@1.0.0 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.****

You should post your code when asking for help. Just seeing npm start is usually not enough.
Please use code blocks for code/log output. It is much easier to read. Use triple backticks (```) to make it look like this:console.log('Hello, World.");

require and import are case-sensitive. You have 'qrCode-terminal'. You need 'qrcode-terminal'.

You should post your code when asking for help. Just seeing npm start is usually not enough.
Please use code blocks for code/log output. It is much easier to read. Use triple backticks (```) to make it look like this:console.log('Hello, World.");

require and import are case-sensitive. You have 'qrCode-terminal'. You need 'qrcode-terminal'.

module where I declared the use of lib
const qrCode = require('qrCode-terminal')

module.exports.showQrCodeOnTerminal = qr => qrCode.generate(qr, { small: true })

module where I declared the use of lib
const qrCode = require('qrCode-terminal')

module.exports.showQrCodeOnTerminal = qr => qrCode.generate(qr, { small: true })

Thank you for posting the code example. Thank you extra for using code blocks.
If you want to be extra awesome, edit your initial comment to use code blocks.
Please read my third point again to see the solution you need :)

Thank you for posting the code example. Thank you extra for using code blocks.
If you want to be extra awesome, edit your initial comment to use code blocks.
Please read my third point again to see the solution you need :)

authors: cinderblock glaucioripol

repo: gtanner/qrcode-terminal

license_source: bigquery


text:
Regen

cc @sdroege @EPashkin

I piece of art! Please merge ASAP

Thanks :heart_eyes:

source: gharchive/pull-request

authors: GuillaumeGomez sdroege

repo: gtk-rs/atk


text:
Wrong generation

I think I should open a similar issue on gir but here is what we get after we generated gdkx11 and try to build it:
$ cargo build
   Compiling gdkx11 v0.1.0 (/home/imperio/rust/gdkx11)
error[E0405]: cannot find trait `ToValue` in this scope
  --> src/auto/x11_device_xi2.rs:69:45
   |
69 |         let mut properties: Vec<(&str, &dyn ToValue)> = vec![];
   |                                             ^^^^^^^ not found in this scope
   |
help: possible candidates are found in other modules, you can import them into scope
   |
5  | use gdk::prelude::ToValue;
   |
5  | use gdk_pixbuf::prelude::ToValue;
   |
5  | use gio::prelude::ToValue;
   |
5  | use glib::ToValue;
   |
     and 3 other candidates

error[E0412]: cannot find type `GLContext` in crate `gdk`
  --> src/auto/x11gl_context.rs:11:135
   |
11 |     pub struct X11GLContext(Object<gdk_x11_sys::GdkX11GLContext, gdk_x11_sys::GdkX11GLContextClass, X11GLContextClass>) @extends gdk::GLContext;
   |                                                                                ^^^^^^^^^ not found in `gdk`

error[E0412]: cannot find type `Monitor` in crate `gdk`
  --> src/auto/x11_monitor.rs:11:127
   |
11 |     pub struct X11Monitor(Object<gdk_x11_sys::GdkX11Monitor, gdk_x11_sys::GdkX11MonitorClass, X11MonitorClass>) @extends gdk::Monitor;
   |                                                                                ^^^^^^^ not found in `gdk`

warning: unused `#[macro_use]` import
  --> src/lib.rs:20:1
   |
20 | #[macro_use]
   | ^^^^^^^^^^^^
   |
   = note: `#[warn(unused_imports)]` on by default

error: aborting due to 3 previous errors; 1 warning emitted

Some errors have detailed explanations: E0405, E0412.
For more information about an error, try `rustc --explain E0405`.
error: could not compile `gdkx11`.

To learn more, run the command again with --verbose.

Any idea @sdroege @EPashkin ?

As used types are versioned all of these module must be versioned too
#[cfg(any(feature = "v3_16", feature = "dox"))]
use glib::ToValue;
//in gdk
#[cfg(any(feature = "v3_22", feature = "dox"))]
pub use self::monitor::{Monitor, MonitorClass};
#[cfg(any(feature = "v3_16", feature = "dox"))]
pub use self::gl_context::{GLContext, GLContextClass};

error[E0405]: cannot find trait ToValue in this scope

Missing include somewhere. Otherwise what @EPashkin said :)

For the gdk types yes. However, there should have a "use glib::ToValue" at the top of the file, however there isn't!

@GuillaumeGomez You removed comment here just now? About ToValue?

Because my comment was stupid. :)

Ok, lets remove question and answer too ;)

However it's still weird that the import is behind a cfg whereas the method where it's used is not...

Yes, and fix is ready: https://github.com/gtk-rs/gir/pull/925

I guess this can be closed

authors: EPashkin GuillaumeGomez bilelmoussaoui sdroege


text:
[BUG]  gtk4::DragSource.name cause crash

System:    Host: rafalkom Kernel: 5.13.0-28-generic x86_64 bits: 64 compiler: gcc v: 11.2.0 Desktop: GNOME 40.5
           tk: GTK 3.24.30 wm: gnome-shell dm: GDM3 Distro: Ubuntu 21.10 (Impish Indri)

RUST_BACKTRACE=full RUSTFLAGS=-Zsanitizer=address RUSTDOCFLAGS=-Zsanitizer=address cargo run  -Zbuild-std --target x86_64-unknown-linux-gnu

Bug description
let object_60 = DragSource::new(); // DragSource
object_60.name();

cause crash:
thread 'main' panicked at 'assertion failed: !ptr.is_null()', /home/rafal/.cargo/git/checkouts/gtk-rs-core-7be42ca38bd6361c/3167871/glib/src/gstring.rs:361:9
stack backtrace:
   0:     0x55c2e135c935 - std::backtrace_rs::backtrace::libunwind::trace::h724e5bf51b0bdeb8
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x55c2e135c935 - std::backtrace_rs::backtrace::trace_unsynchronized::hc82c40a0376ae7d7
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x55c2e123b5fe - std::sys_common::backtrace::_print_fmt::hea603b8559ffc9b1
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:66:5
   3:     0x55c2e123ad69 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::he7d66fa55811781f
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:45:22
   4:     0x55c2e160b005 - core::fmt::write::hb0ec546ccfce83c2
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:1190:17
   5:     0x55c2e1228788 - std::io::Write::write_fmt::h3693478b33b13fd5
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/io/mod.rs:1657:15
   6:     0x55c2e123ac64 - std::sys_common::backtrace::_print::hb480943d44f9ba68
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:48:5
   7:     0x55c2e123a7ce - std::sys_common::backtrace::print::h2e68a689d2b6e66c
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:35:9
   8:     0x55c2e13ea829 - std::panicking::default_hook::{{closure}}::h883a506ba80935ac
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:295:22
   9:     0x55c2e13e9a86 - std::panicking::default_hook::he383a16fd745d86f
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:314:9
  10:     0x55c2e13efe21 - std::panicking::rust_panic_with_hook::he55532a23f201724
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:698:17
  11:     0x55c2e13ef3b2 - std::panicking::begin_panic_handler::{{closure}}::h1c9db301df3acdad
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:586:13
  12:     0x55c2e123d71d - std::sys_common::backtrace::__rust_end_short_backtrace::h36cb68a2d331b01d
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:138:18
  13:     0x55c2e13edc2f - rust_begin_unwind
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:584:5
  14:     0x55c2e15fae26 - core::panicking::panic_fmt::h4457af6eff34ee1a
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panicking.rs:143:14
  15:     0x55c2e15fa4e2 - core::panicking::panic::hf9f684f110c4f77c
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panicking.rs:48:5
  16:     0x55c2e0fe0a91 - <glib::gstring::GString as glib::translate::FromGlibPtrNone<*const u8>>::from_glib_none::h8c286ceadbd8a6fa
                               at /home/rafal/.cargo/git/checkouts/gtk-rs-core-7be42ca38bd6361c/3167871/glib/src/gstring.rs:361:9
  17:     0x55c2e107ea96 - glib::translate::from_glib_none::h41333f9023a92af0
                               at /home/rafal/.cargo/git/checkouts/gtk-rs-core-7be42ca38bd6361c/3167871/glib/src/translate.rs:1426:5
  18:     0x55c2e0fe0b67 - <glib::gstring::GString as glib::translate::FromGlibPtrNone<*const i8>>::from_glib_none::hb9e84d0792e5e8c3
                               at /home/rafal/.cargo/git/checkouts/gtk-rs-core-7be42ca38bd6361c/3167871/glib/src/gstring.rs:372:9
  19:     0x55c2e107ead6 - glib::translate::from_glib_none::h7e67841687ff1757
                               at /home/rafal/.cargo/git/checkouts/gtk-rs-core-7be42ca38bd6361c/3167871/glib/src/translate.rs:1426:5
  20:     0x55c2e0bc4db8 - <O as gtk4::auto::event_controller::EventControllerExt>::name::h2a86341e98c5d70d
                               at /home/rafal/.cargo/git/checkouts/gtk4-rs-e74ad56283dfeb5e/8f08e72/gtk4/src/auto/event_controller.rs:126:13
  21:     0x55c2e0bcbadd - crash_thing::crashes::hd10bc61ebee97362
                               at /home/rafal/Desktop/Untitled Folder/Project/src/main.rs:30:1
  22:     0x55c2e0bc5778 - crash_thing::main::{{closure}}::h99d270ea5baaa0d1
                               at /home/rafal/Desktop/Untitled Folder/Project/src/main.rs:20:9
  23:     0x55c2e0bc4ceb - <O as gio::auto::application::ApplicationExt>::connect_activate::activate_trampoline::h91258cdadfe72d33
                               at /home/rafal/.cargo/git/checkouts/gtk-rs-core-7be42ca38bd6361c/3167871/gio/src/auto/application.rs:604:13
  24:     0x7fa91678fc0f - g_closure_invoke
  25:     0x7fa9167abea6 - <unknown>
  26:     0x7fa9167ad884 - g_signal_emit_valist
  27:     0x7fa9167adad3 - g_signal_emit
  28:     0x7fa9168b29d8 - <unknown>
  29:     0x7fa9168b2bb6 - g_application_run
  30:     0x55c2e0bc61d9 - <O as gio::application::ApplicationExtManual>::run_with_args::h68786f7d87165c94
                               at /home/rafal/.cargo/git/checkouts/gtk-rs-core-7be42ca38bd6361c/3167871/gio/src/application.rs:30:13
  31:     0x55c2e0bc5bc8 - <O as gio::application::ApplicationExtManual>::run::h2fb226a192c21ca9
                               at /home/rafal/.cargo/git/checkouts/gtk-rs-core-7be42ca38bd6361c/3167871/gio/src/application.rs:23:9
  32:     0x55c2e0bcb6b7 - crash_thing::main::hc51bec7a5b8c7e89
                               at /home/rafal/Desktop/Untitled Folder/Project/src/main.rs:23:5
  33:     0x55c2e0bcd68b - core::ops::function::FnOnce::call_once::h3fd7cdd36c90b094
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227:5
  34:     0x55c2e0bca9f5 - std::sys_common::backtrace::__rust_begin_short_backtrace::h43935b03eb4cf297
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:122:18
  35:     0x55c2e0bc6de4 - std::rt::lang_start::{{closure}}::h1235bc9d4d9829c5
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:145:18
  36:     0x55c2e13deb0e - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h43e2cfacab1d39a9
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:259:13
  37:     0x55c2e13ecbff - std::panicking::try::do_call::h7cf1c45ecf74e21c
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:492:40
  38:     0x55c2e13f5dab - __rust_try
  39:     0x55c2e13eaea3 - std::panicking::try::h11786f75c5e8f92c
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:456:19
  40:     0x55c2e119d1ba - std::panic::catch_unwind::h4dd0051ef18d6daa
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:137:14
  41:     0x55c2e123a22c - std::rt::lang_start_internal::{{closure}}::h648b6b8193457c95
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:128:48
  42:     0x55c2e13ec9fe - std::panicking::try::do_call::h13596aff24f38038
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:492:40
  43:     0x55c2e13f5dab - __rust_try
  44:     0x55c2e13ebb9c - std::panicking::try::h59f157e493726e21
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:456:19
  45:     0x55c2e119d4da - std::panic::catch_unwind::hec526b79455e9b90
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:137:14
  46:     0x55c2e1239b7a - std::rt::lang_start_internal::hc671c8fded5192b3
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:128:20
  47:     0x55c2e0bc6d46 - std::rt::lang_start::h46f1fcb3dbb7346d
                               at /home/rafal/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:144:17
  48:     0x55c2e0bcbd7c - main
  49:     0x7fa91634bfd0 - __libc_start_call_main
                               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  50:     0x7fa91634c07d - __libc_start_main_impl
                               at ./csu/../csu/libc-start.c:409:3
  51:     0x55c2e0b321e5 - _start
  52:                0x0 - <unknown>

=================================================================

Issue found by fuzzer - https://github.com/qarmin/gtk-rs-fuzzer

Probably needs to be nullable, will check that one upstream

Fixed on https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4470

authors: bilelmoussaoui qarmin


text:
fix: correct base offset of field_inv

The correct offset here seems to be 324, following set_player_fake_inebriation.
Found it from AC:

I know it's slightly convoluted, but this is actually auto generated from this data. If you make the change there and then run cargo gen it will be correct.

Oh, I see

@Dantsz It seems the code did not apply correctly, so you might need to use commit https://github.com/gtker/wow_messages/commit/55c2b641b7dbd09ca1de882f5fce814e4a91c068 instead of the main right when this PR got merged.

authors: Dantsz gtker


text:
Add means to compare quantities

Background
K8s converts user input quantities to "canonical form":

Before serializing, Quantity will be put in "canonical form". This means that Exponent/suffix will be adjusted up or down (with a corresponding increase or decrease in Mantissa) such that: a. No precision is lost b. No fractional digits will be emitted c. The exponent (or suffix) is as large as possible. The sign will be omitted unless the number is negative.
Examples: 1.5 will be serialized as "1500m" 1.5Gi will be serialized as "1536Mi"

Additional examples:

User input
K8s representation

{"memory": "0.9Gi"}
{"memory": "966367641600m"}

{"cpu": "0.30000000000000004"}
{"cpu": "301m"}

Use case
When patching a statefulset's resource limits, it would be handy to be able to compare a quantity's setpoint
statefulset.spec.template.spec.containers[i].resources

to the active podspec
pod.spec.containers[i].resources

Currently, two equivalent ResourceRequirements instances could differ under == comparison and require manual interconversion.
Additional thoughts

k8s-client has a parse_quantity function, but having both lightkube and kubernetes deps is not ideal.
bitmath doesn't support millis and is awkward to "abuse" for cpu values.
Implementing comparisons for class ResourceRequirements might be ackward.

Yes, a function similar to parse_quantity could be a good addition. Would you like to contribute a PR?

authors: gtsystem sed-i

repo: gtsystem/lightkube


text:
Certifier - OSV Scanner API for batch querying

Currently, the OSV Scanner querying API is copied as an internal file. Working with upstream maintainers to determine a path forward to remove this file.
Continuation from PR comment:
https://github.com/guacsec/guac/pull/245#discussion_r1047996505
cc @oliverchang

Currently, OSV Scanner does not allow for a direct query for a package based on a purl. See: https://github.com/google/osv-scanner/blob/main/pkg/osvscanner/osvscanner.go#L261. Determine if there is an alternative method or if this can be added to upstream OSV scanner.

FYI @lumjjb

Currently our actual OSV querying code is in an internal package: https://github.com/google/osv-scanner/blob/main/internal/osv/osv.go
@another-rex would it make sense to make some of these public so other tools can call the OSV API through our client?

That can work, we can put it under v1 folder under pkgs so that it's public and if there are any breaking changes it easy to update.

Awesome thanks @another-rex!

This is now merged: https://github.com/google/osv-scanner/pull/167, so the library should now be public:

"github.com/google/osv-scanner/pkg/osv"

Thanks, @another-rex and @oliverchang!

authors: another-rex oliverchang pxp928

repo: guacsec/guac


text:
NATS component is too noisy

The log is a bit noisy since it emits a log entry even when it doesn't find anything. It probably shouldn't emit logs so often.
For example:
guac-guac-ingestor-1    | {"level":"info","ts":1676073593.6739805,"caller":"emitter/nats_emitter.go:193","msg":"[processor: 33f9b22d-9e79-46b3-8010-936519b0e598] nothing to consume, backing off for 1s: %!w(*errors.errorString=&{nats: timeout})"}
guac-guac-ingestor-1    | {"level":"info","ts":1676073599.6744463,"caller":"emitter/nats_emitter.go:193","msg":"[processor: 33f9b22d-9e79-46b3-8010-936519b0e598] nothing to consume, backing off for 1s: %!w(*errors.errorString=&{nats: timeout})"}
guac-guac-ingestor-1    | {"level":"info","ts":1676073599.6745517,"caller":"emitter/nats_emitter.go:193","msg":"[ingestor: 9d88e60b-fb66-49d0-ac5b-349efc775e09] nothing to consume, backing off for 1s: %!w(*errors.errorString=&{nats: timeout})"}
guac-guac-ingestor-1    | {"level":"info","ts":1676073605.6750836,"caller":"emitter/nats_emitter.go:193","msg":"[ingestor: 9d88e60b-fb66-49d0-ac5b-349efc775e09] nothing to consume, backing off for 1s: %!w(*errors.errorString=&{nats: timeout})"}
guac-guac-ingestor-1    | {"level":"info","ts":1676073605.6751924,"caller":"emitter/nats_emitter.go:193","msg":"[processor: 33f9b22d-9e79-46b3-8010-936519b0e598] nothing to consume, backing off for 1s: %!w(*errors.errorString=&{nats: timeout})"}
guac-guac-ingestor-1    | {"level":"info","ts":1676073611.6756551,"caller":"emitter/nats_emitter.go:193","msg":"[processor: 33f9b22d-9e79-46b3-8010-936519b0e598] nothing to consume, backing off for 1s: %!w(*errors.errorString=&{nats: timeout})"}
guac-guac-ingestor-1    | {"level":"info","ts":1676073611.6756742,"caller":"emitter/nats_emitter.go:193","msg":"[ingestor: 9d88e60b-fb66-49d0-ac5b-349efc775e09] nothing to consume, backing off for 1s: %!w(*errors.errorString=&{nats: timeout})"}
guac-guac-ingestor-1    | {"level":"info","ts":1676073617.6548517,"caller":"emitter/nats_emitter.go:193","msg":"[ingestor: 9d88e60b-fb66-49d0-ac5b-349efc775e09] nothing to consume, backing off for 1s: %!w(*errors.errorString=&{nats: timeout})"}
guac-guac-ingestor-1    | {"level":"info","ts":1676073617.654947,"caller":"emitter/nats_emitter.go:193","msg":"[processor: 33f9b22d-9e79-46b3-8010-936519b0e598] nothing to consume, backing off for 1s: %!w(*errors.errorString=&{nats: timeout})"}
guac-guac-ingestor-1    | {"level":"info","ts":1676073623.6559846,"caller":"emitter/nats_emitter.go:193","msg":"[ingestor: 9d88e60b-fb66-49d0-ac5b-349efc775e09] nothing to consume, backing off for 1s: %!w(*errors.errorString=&{nats: timeout})"}
guac-guac-ingestor-1    | {"level":"info","ts":1676073623.6560209,"caller":"emitter/nats_emitter.go:193","msg":"[processor: 33f9b22d-9e79-46b3-8010-936519b0e598] nothing to consume, backing off for 1s: %!w(*errors.errorString=&{nats: timeout})"}
guac-guac-ingestor-1    | {"level":"info","ts":1676073629.6562033,"caller":"emitter/nats_emitter.go:193","msg":"[processor: 33f9b22d-9e79-46b3-8010-936519b0e598] nothing to consume, backing off for 1s: %!w(*errors.errorString=&{nats: timeout})"}
guac-guac-ingestor-1    | {"level":"info","ts":1676073629.656252,"caller":"emitter/nats_emitter.go:193","msg":"[ingestor: 9d88e60b-fb66-49d0-ac5b-349efc775e09] nothing to consume, backing off for 1s: %!w(*errors.errorString=&{nats: timeout})"}
guac-guac-ingestor-1    | {"level":"info","ts":1676073635.6570692,"caller":"emitter/nats_emitter.go:193","msg":"[ingestor: 9d88e60b-fb66-49d0-ac5b-349efc775e09] nothing to consume, backing off for 1s: %!w(*errors.errorString=&{nats: timeout})"}

@naveensrinivasan would this be of interest to you?

@naveensrinivasan would this be of interest to you?

Sure, I can take that.

authors: lumjjb naveensrinivasan


text:
inmem - PkgEqual: Subpath query filtering

Description of the PR
Draft PR to further discuss about https://github.com/guacsec/guac/pull/1243#discussion_r1320122295:
Added both PkgEqual instance to the expected outcomes for Query on pkg algo and pkg test based on the assumption that not having provided a Subpath value in the query PkgEqualSpec should not filter by Subpath.
The "reasonable" way I found to have it working has been adding the filter.Subpath == nil in the exactPackageVersion func rather than changing the noMatchInput because changing the latter made much more tests to fail even if this brings me the doubt that maybe the filtering could be broken somewhere else.
PR Checklist

[X] All commits have a Developer Certificate of Origin (DCO) -- they are generated using -s flag to git commit.
[X] All new changes are covered by tests
[ ] If GraphQL schema is changed, make generate has been run
[ ] If collectsub protobuf has been changed, make proto has been run
[ ] All CI checks are passing (tests and formatting)
[ ] All dependent PRs have already been merged

@pxp928 @mihaimaruseac @jeffmendoza what do you think about this issue?


text:
EOVOD开源

请问EOVOD会开源吗？

会的

你好，请问https://github.com/guanxiongsun/EOVOD 这个是EOVOD的开源吗

会的

你好，请问https://github.com/guanxiongsun/EOVOD 这个是EOVOD的开源吗

authors: Weihong-Liu guanxiongsun xhnathan


text:
PyMongo 3.0 admin calls failing when run using Apache WSGI

[Sat Jun 20 12:53:00.260834 2015] [:error] [pid 19124:tid 140441230903040] 2015-06-20 12:53:00,260 - alerta.app[19124]: INFO - Starting alerta version 4.4.7 ...
[Sat Jun 20 12:53:00.322813 2015] [:error] [pid 19124:tid 140441230903040] 2015-06-20 12:53:00,322 - alerta.app[19124]: DEBUG - Connected to mongodb://localhost:27017/monitoring
[Sat Jun 20 12:53:30.368402 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204] mod_wsgi (pid=19124): Target WSGI script '/var/www/api.wsgi' cannot be loaded as Python module.
[Sat Jun 20 12:53:30.369482 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204] mod_wsgi (pid=19124): Exception occurred processing WSGI script '/var/www/api.wsgi'.
[Sat Jun 20 12:53:30.369865 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204] Traceback (most recent call last):
[Sat Jun 20 12:53:30.370266 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]   File "/var/www/api.wsgi", line 4, in <module>
[Sat Jun 20 12:53:30.370691 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]     from alerta.app import app as application
[Sat Jun 20 12:53:30.370976 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]   File "/opt/alerta/lib/python2.7/site-packages/alerta/app/__init__.py", line 49, in <module>
[Sat Jun 20 12:53:30.371371 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]     db = Mongo()
[Sat Jun 20 12:53:30.371839 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]   File "/opt/alerta/lib/python2.7/site-packages/alerta/app/database.py", line 81, in __init__
[Sat Jun 20 12:53:30.372459 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]     self.version = self.db.collection_names()
[Sat Jun 20 12:53:30.372813 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]   File "/opt/alerta/lib/python2.7/site-packages/pymongo/database.py", line 488, in collection_names
[Sat Jun 20 12:53:30.373313 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]     ReadPreference.PRIMARY) as (sock_info, slave_okay):
[Sat Jun 20 12:53:30.373520 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]   File "/usr/lib/python2.7/contextlib.py", line 17, in __enter__
[Sat Jun 20 12:53:30.373826 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]     return self.gen.next()
[Sat Jun 20 12:53:30.374027 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]   File "/opt/alerta/lib/python2.7/site-packages/pymongo/mongo_client.py", line 699, in _socket_for_reads
[Sat Jun 20 12:53:30.374501 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]     with self._get_socket(read_preference) as sock_info:
[Sat Jun 20 12:53:30.374706 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]   File "/usr/lib/python2.7/contextlib.py", line 17, in __enter__
[Sat Jun 20 12:53:30.374978 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]     return self.gen.next()
[Sat Jun 20 12:53:30.375184 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]   File "/opt/alerta/lib/python2.7/site-packages/pymongo/mongo_client.py", line 663, in _get_socket
[Sat Jun 20 12:53:30.375440 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]     server = self._get_topology().select_server(selector)
[Sat Jun 20 12:53:30.375661 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]   File "/opt/alerta/lib/python2.7/site-packages/pymongo/topology.py", line 121, in select_server
[Sat Jun 20 12:53:30.376016 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]     address))
[Sat Jun 20 12:53:30.376039 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]   File "/opt/alerta/lib/python2.7/site-packages/pymongo/topology.py", line 97, in select_servers
[Sat Jun 20 12:53:30.376062 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204]     self._error_message(selector))
[Sat Jun 20 12:53:30.376095 2015] [:error] [pid 19124:tid 140441230903040] [remote 192.168.0.1:8204] ServerSelectionTimeoutError: No servers found yet

Code causing the problems is here and here.

Bug report https://jira.mongodb.org/browse/PYTHON-961
Mailing list https://groups.google.com/d/msg/mongodb-user/7qX03P3_zKM/PP95RatZJ1sJ

repo: guardian/alerta


text:
Add example CloudFormation

What is the purpose of this change?
Add example templates that can create (almost) all the AWS resources necessary for running Janus in an AWS account.
Add links from the README to the example CloudFormation and provide guidance on how the templates can be used.
This PR also adds a section on the custom AWS profile required when running Janus locally.
What is the value of this change and how do we measure success?
Increase the number of CloudFormation templates in Open Source 🚀✨
Reduce the time investment for other organisations to adopt Janus.
Promote some good practices via example CloudFormation.
Any additional notes?
Also fixing a small spelling error found in the tests.

I have rebased this PR and fixed the conflict that due to the recent update of the libraries and dependencies.

repo: guardian/janus-app


text:
Press CursorDown on TabView doesn't move to the next view.

I'll fix this on the #3181.

I'll fix this on the #3181.

Please don't. Please wait to fix this until #3181 and #3202 are merged in to v2_develop.

Ok I'll resolving that when#3181 and #3202 are merged in to v2_develop.

Closing this as complete because it's was already merged into the v2_develop branch within the #3181 and #3202.

authors: BDisp tig


text:
Application.Init / Shutdown are confused about TopLevels created by Application.Begin and not cleaned up by Application.End

In UI Catalog, before I start a Scenario I call Application.Shutdown. You are supposed to book end every call to Applciation.Begin with Shutdown.
I just discovered that Shutdown does not actually clean up. As a result, the next time Application.Begin is called, fields like topLevels still have data. This means that the 'old' stuff interferes with the 'new' stuff.
Short-term fix is to uninitialize stuff:
		/// <summary>
		/// Shutdown an application initalized with <see cref="Init()"/>
		/// </summary>
		public static void Shutdown ()
		{
			Driver.End ();
			foreach (var t in toplevels) {
				t.Running = false;
			}
			toplevels.Clear ();
			Current = null;
			CurrentView = null;
			Top = null;
			MainLoop = null;
			_initialized = false;
		}

Crux of issue (added Nov 2, 2022 via #2162):
Init/Shutdown are supposed to clean up. But in ResetState, the loop that disposes of the topLevels does nothing because the Toplevel that was created by Init has not been added to topLevels (it gets added by Begin).
The right fix (IMO) would be to move all that state into RunState and leverage the fact that RunState is already IDisposable. However, it may not be possible to do this without a breaking change.

That was what I was referring to when I said that it was better to always build on top of the same Toplevel so as not to create too many instances that then remain in memory, spending resources, if we do not remove them. Creating new instances is always a good idea if you want to navigate between pages (this is a suggestion). So in this case you did well to create this resource to clean up resources that are no longer used.

Right.
But in the case of UI Catalog we want each Scenario to have the ability to run as though it were a 'virgin' Terminal.Gui app. So, it's a good thing I wrote it that way because it has helped uncover more bugs like this one.

Reopening for v2 - See #2162.

Digging into this, I think UI Catalog is correct.
I think the bug is actually here:

This check for multiple Mdi containers should see if MdiTop != topLevel:

With this change, and BackgroundWorkerCollection.cs changed thusly:
namespace UICatalog.Scenarios {
	[ScenarioMetadata (Name: "BackgroundWorker Collection", Description: "A persisting multi Toplevel BackgroundWorker threading")]
	[ScenarioCategory ("Threading")]
	[ScenarioCategory ("Top Level Windows")]
	[ScenarioCategory ("Dialogs")]
	[ScenarioCategory ("Controls")]
	public class BackgroundWorkerCollection : Scenario {
		public override void Init (Toplevel top, ColorScheme colorScheme)
		{
			// Do nothing as, the call to `Application.Run<MdiMain>` in `Run` implies an `Application.Init()` call.
		}

		public override void Run ()
		{
			Application.Run<MdiMain> ();
		}

Alternatively, this works too:
namespace UICatalog.Scenarios {
	[ScenarioMetadata (Name: "BackgroundWorker Collection", Description: "A persisting multi Toplevel BackgroundWorker threading")]
	[ScenarioCategory ("Threading")]
	[ScenarioCategory ("Top Level Windows")]
	[ScenarioCategory ("Dialogs")]
	[ScenarioCategory ("Controls")]
	public class BackgroundWorkerCollection : Scenario {
		public override void Init (Toplevel top, ColorScheme colorScheme)
		{
			Application.Init ();
			Application.Top.Dispose (); // We're going to be creating a new TopLevel (MdiMain) so kill this one
		}

		public override void Run ()
		{
			Application.Run<MdiMain> ();
		}

It all works correctly.
Related: (I had forgotten about this): https://github.com/gui-cs/Terminal.Gui/issues/520
The real cause of the problems here is that

Init/Shutdown are supposed to clean up. But in ResetState, the loop that disposes the topLevels does nothing because the Toplevel that was created by Inithas not been added totopLevels(it gets added byBegin`).

@BDisp what are your thoughts? Please review #2165.

I can repo. Are you sure it didn't do this before?

I don't think so.

I just reverted to before I merged the UI Catalog refactoring and this issue still exits.
Go back to your vkpacket-fix4 branch, which was merged before I did the UI Cat work and you'll see this double menu thing reproduces there.
I then went back to v1.82 and it repros there too. So this has nothing to with my UI Cat changes or THIS PR.

In the scenario.Init (Application.Top, _colorScheme); the parameter Application.Top now will be always null. I think this method shouldn't have any parameters, because if the user don't use it he can initialize a customized toplevel, by overridden the Run method without code..

I completely agree! I will do another PR to simplify this (I had considered it before but then forgot).

Doing in the scenario.Run (); is a waste of resources because we need to Dispose before recreate a new one. Because Application.Top is created by calling the Application.Init() and it's not already added to the topLevels, is more accurate to call Top.Dispose(); before set Top = null; in the ResetState method, to ensure that the Top is disposed in the case it wasn't added to the toplevels, because the foreach (var t in toplevels) will be empty.

I think this is right, but I need to look more closely. BackgroundWorker Collection is the only Scenario that uses Run(). So it's a great test case for all of this.
I suggest we close THIS PR and move the discussion to #520, which is where the root cause is. Ok?

Digging into this, I think UI Catalog is correct.
I think the bug is actually here:

This check for multiple Mdi containers should see if MdiTop != topLevel:

With this change, and BackgroundWorkerCollection.cs changed thusly:
namespace UICatalog.Scenarios {
	[ScenarioMetadata (Name: "BackgroundWorker Collection", Description: "A persisting multi Toplevel BackgroundWorker threading")]
	[ScenarioCategory ("Threading")]
	[ScenarioCategory ("Top Level Windows")]
	[ScenarioCategory ("Dialogs")]
	[ScenarioCategory ("Controls")]
	public class BackgroundWorkerCollection : Scenario {
		public override void Init (Toplevel top, ColorScheme colorScheme)
		{
			// Do nothing as, the call to `Application.Run<MdiMain>` in `Run` implies an `Application.Init()` call.
		}

		public override void Run ()
		{
			Application.Run<MdiMain> ();
		}

Alternatively, this works too:
namespace UICatalog.Scenarios {
	[ScenarioMetadata (Name: "BackgroundWorker Collection", Description: "A persisting multi Toplevel BackgroundWorker threading")]
	[ScenarioCategory ("Threading")]
	[ScenarioCategory ("Top Level Windows")]
	[ScenarioCategory ("Dialogs")]
	[ScenarioCategory ("Controls")]
	public class BackgroundWorkerCollection : Scenario {
		public override void Init (Toplevel top, ColorScheme colorScheme)
		{
			Application.Init ();
			Application.Top.Dispose (); // We're going to be creating a new TopLevel (MdiMain) so kill this one
		}

		public override void Run ()
		{
			Application.Run<MdiMain> ();
		}

It all works correctly.
Related: (I had forgotten about this): https://github.com/gui-cs/Terminal.Gui/issues/520
The real cause of the problems here is that

Init/Shutdown are supposed to clean up. But in ResetState, the loop that disposes the topLevels does nothing because the Toplevel that was created by Inithas not been added totopLevels(it gets added byBegin`).

@BDisp what are your thoughts? Please review #2165.

I can repo. Are you sure it didn't do this before?

I don't think so.

I just reverted to before I merged the UI Catalog refactoring and this issue still exits.
Go back to your vkpacket-fix4 branch, which was merged before I did the UI Cat work and you'll see this double menu thing reproduces there.
I then went back to v1.82 and it repros there too. So this has nothing to with my UI Cat changes or THIS PR.

In the scenario.Init (Application.Top, _colorScheme); the parameter Application.Top now will be always null. I think this method shouldn't have any parameters, because if the user don't use it he can initialize a customized toplevel, by overridden the Run method without code..

I completely agree! I will do another PR to simplify this (I had considered it before but then forgot).

Doing in the scenario.Run (); is a waste of resources because we need to Dispose before recreate a new one. Because Application.Top is created by calling the Application.Init() and it's not already added to the topLevels, is more accurate to call Top.Dispose(); before set Top = null; in the ResetState method, to ensure that the Top is disposed in the case it wasn't added to the toplevels, because the foreach (var t in toplevels) will be empty.

I think this is right, but I need to look more closely. BackgroundWorker Collection is the only Scenario that uses Run(). So it's a great test case for all of this.
I suggest we close THIS PR and move the discussion to #520, which is where the root cause is. Ok?

Just noted there are no unit tests that test void Run<T> (Func<Exception, bool> errorHandler = null) where T : Toplevel, new() aka Run<T>.
First step here is to write some.

Note the BUGBUGs I put here; good questions, I think, but probably not related:
		public static void Run<T> (Func<Exception, bool> errorHandler = null) where T : Toplevel, new()
		{
			if (_initialized && Driver != null) {
				var top = new T ();
				var type = top.GetType ().BaseType;
				while (type != typeof (Toplevel) && type != typeof (object)) {
					type = type.BaseType;
				}
				if (type != typeof (Toplevel)) {
					throw new ArgumentException ($"{top.GetType ().Name} must be derived from TopLevel");
				}
				// BUGBUG: Note `Top` is not set here, so `Top` will be null. Is this correct?
				Run (top, errorHandler);
			} else {
				// BUGBUG: Note in this case, we don't verify the type of the Toplevel created by new T(). Is this an issue?
				Init (() => new T ());
				Run (Top, errorHandler);
			}
		}

Note the BUGBUGs I put here; good questions, I think, but probably not related:
		public static void Run<T> (Func<Exception, bool> errorHandler = null) where T : Toplevel, new()
		{
			if (_initialized && Driver != null) {
				var top = new T ();
				var type = top.GetType ().BaseType;
				while (type != typeof (Toplevel) && type != typeof (object)) {
					type = type.BaseType;
				}
				if (type != typeof (Toplevel)) {
					throw new ArgumentException ($"{top.GetType ().Name} must be derived from TopLevel");
				}
				// BUGBUG: Note `Top` is not set here, so `Top` will be null. Is this correct?
				Run (top, errorHandler);
			} else {
				// BUGBUG: Note in this case, we don't verify the type of the Toplevel created by new T(). Is this an issue?
				Init (() => new T ());
				Run (Top, errorHandler);
			}
		}

On the 1st BUGBUG above, I've verified that Top does indeed eventually get set in this codepath (in SetCurrentTop). Call stack:

Note the BUGBUGs I put here; good questions, I think, but probably not related:
		public static void Run<T> (Func<Exception, bool> errorHandler = null) where T : Toplevel, new()
		{
			if (_initialized && Driver != null) {
				var top = new T ();
				var type = top.GetType ().BaseType;
				while (type != typeof (Toplevel) && type != typeof (object)) {
					type = type.BaseType;
				}
				if (type != typeof (Toplevel)) {
					throw new ArgumentException ($"{top.GetType ().Name} must be derived from TopLevel");
				}
				// BUGBUG: Note `Top` is not set here, so `Top` will be null. Is this correct?
				Run (top, errorHandler);
			} else {
				// BUGBUG: Note in this case, we don't verify the type of the Toplevel created by new T(). Is this an issue?
				Init (() => new T ());
				Run (Top, errorHandler);
			}
		}

// BUGBUG: Note Top is not set here, so Top will be null. Is this correct?

Yes it's null but will be initialized with the call Run (top, errorHandler);

// BUGBUG: Note in this case, we don't verify the type of the Toplevel created by new T(). Is this an issue?

No it isn't because the generic type is referencing a Toplevel on the method where T : Toplevel, new().

// BUGBUG: Note in this case, we don't verify the type of the Toplevel created by new T(). Is this an issue?

No it isn't because the generic type is referencing a Toplevel on the method where T : Toplevel, new().

But then why is the type checked in the other codepath?

But then why is the type checked in the other codepath?

The first code-path is used when the Init method was already called and the drivers are already initialized. Then it checks into the BaseType. If it isn't a Toplevel type an exception is throw.

But then why is the type checked in the other codepath?

The first code-path is used when the Init method was already called and the drivers are already initialized. Then it checks into the BaseType. If it isn't a Toplevel type an exception is throw.

var top = new T ();
var type = top.GetType ().BaseType;
while (type != typeof (Toplevel) && type != typeof (object)) {
   type = type.BaseType;
}
if (type != typeof (Toplevel)) {
  throw new ArgumentException ($"{top.GetType ().Name} must be derived from TopLevel");
 				}

Educate me please: if I do a new T() where T is type-checked at compile time because Run<T> is defined as where T : Toplevel, new(), isn't it impossible for type != typeof(Toplevel)?

Educate me please: if I do a new T() where T is type-checked at compile time because Run<T> is defined as where T : Toplevel, new(), isn't it impossible for type != typeof(Toplevel)?

Well, Toplevel is derived from View but we want only accept 'T' with an object that is derived from Toplevel and not an object that is derived from View.

Do you think NotifyNewRunState could be invoked safely even if ExitRunLoopAfterFirstIteration is false.

ExitRunLoopAfterFirstIteration as true will exit the RunLoop and it's needed to manually rerun it. That is only used for drivers that can't be blocked into the RunLoop, like the WebConsole. But perhaps is safely also to invoke the NotifyNewRunState event if it's false. I never try it but it should do not screw up anything.

Do you think NotifyNewRunState could be invoked safely even if ExitRunLoopAfterFirstIteration is false.

ExitRunLoopAfterFirstIteration as true will exit the RunLoop and it's needed to manually rerun it. That is only used for drivers that can't be blocked into the RunLoop, like the WebConsole. But perhaps is safely also to invoke the NotifyNewRunState event if it's false. I never try it but it should do not screw up anything.

I did this and wrote more unit tests to prove it works. The new docs for these actions are:
		/// <summary>
		/// Notify that a new <see cref="RunState"/> was created (<see cref="Begin(Toplevel)"/> was called). The token is created in
		/// <see cref="Begin(Toplevel)"/> and this event will be fired before that function exits.
		/// </summary>
		/// <remarks>
		///	If <see cref="ExitRunLoopAfterFirstIteration"/> is <see langword="true"/> callers to
		///	<see cref="Begin(Toplevel)"/> must also subscribe to <see cref="NotifyStopRunState"/>
		///	and manually dispose of the <see cref="RunState"/> token when the application is done.
		/// </remarks>
		public static event Action<RunState> NotifyNewRunState;

		/// <summary>
		/// Notify that a existent <see cref="RunState"/> is stopping (<see cref="End(RunState)"/> was called).
		/// </summary>
		/// <remarks>
		///	If <see cref="ExitRunLoopAfterFirstIteration"/> is <see langword="true"/> callers to
		///	<see cref="Begin(Toplevel)"/> must also subscribe to <see cref="NotifyStopRunState"/>
		///	and manually dispose of the <see cref="RunState"/> token when the application is done.
		/// </remarks>
		public static event Action<Toplevel> NotifyStopRunState;

Wow, Run<T> is massively broken. The deeper I go, the more issues I find.
The crux is that it calls (the internal) Init (Func<Toplevel> topLevelFactory) when void Init (ConsoleDriver driver = null, IMainLoopDriver mainLoopDriver = null) => Init (() => Toplevel.Create (), driver, mainLoopDriver) has not yet been called.
But Init (Func<Toplevel> topLevelFactory) relies on auto-detection of the driver & mainloop. This means, as-is, Run<T> can't be unit tested!
As an experiment, I changed the method to take a driver & mainloop, thinking this could be done in a non breaking-change way:

This almost works, but then I discovered that Init (Func<Toplevel> topLevelFactory) calls ResetState() which means there's no way to key Applicaton.Iteration set.
I think I've resolved this by changing the internal Init to:
		/// <summary>
		/// Internal function for initializing a Terminal.Gui application with a <see cref="Toplevel"/> factory object,
		/// a <see cref="ConsoleDriver"/>, and <see cref="MainLoop"/>.
		/// <para>
		/// This is a low-level function; most applications will use <see cref="Init(ConsoleDriver, IMainLoopDriver)"/> as it is simpler.</para>
		/// </summary>
		/// <param name="topLevelFactory">Specifies the <see cref="Toplevel"> factory funtion.</see>/></param>
		/// <param name="driver">The <see cref="ConsoleDriver"/> to use. If not specified the default driver for the
		/// platform will be used (see <see cref="WindowsDriver"/>, <see cref="CursesDriver"/>, and <see cref="NetDriver"/>).</param>
		/// <param name="mainLoopDriver">Specifies the <see cref="MainLoop"/> to use.</param>
		/// <param name="resetState">If <see langword="true"/> (default) all <see cref="Application"/> state will be reset.
		/// Set to <see langword="false"/> to not reset the state (for when this function is called via
		/// <see cref="Run{T}(Func{Exception, bool}, ConsoleDriver, IMainLoopDriver)"/> when <see cref="Init(ConsoleDriver, IMainLoopDriver)"/>
		/// has not already been called. f</param>
	internal static void Init (Func<Toplevel> topLevelFactory, ConsoleDriver driver = null, IMainLoopDriver mainLoopDriver = null, bool resetState = true)
		{
			if (_initialized && driver == null) return;

			if (_initialized) {
				throw new InvalidOperationException ("Init has already been called and must be bracketed by Shutdown.");
			}

			// Used only for start debugging on Unix.
			//#if DEBUG
			//			while (!System.Diagnostics.Debugger.IsAttached) {
			//				System.Threading.Thread.Sleep (100);
			//			}
			//			System.Diagnostics.Debugger.Break ();
			//#endif

			// Reset all class variables (Application is a singleton).
			if (resetState) {
				ResetState ();
			}
...

Writing more unit tests now to prove this doesn't break anything.

@tig try to press the Enter key to run some scenario and Ctrl+Q to quit. Do this continuously in the same scenario and you will observe that it take more time to run and exit more and more. I think the memory it isn't disposing and freeing safely on shutdown.

This almost works, but then I discovered that Init (Func<Toplevel> topLevelFactory) calls ResetState() which means there's no way to key Applicaton.Iteration set.

Well the Init method isn't forApplicaton.Iteration. This is only used on the RunLoop method. The Init is only to initialize the drivers and the principals variables.

I prefer this approach because is not needed to create the Window if we don't needed it as this scenario. We don't need to call Application.Shutdown() because it will be called after exit the scenario in the UICatalog.
	public class BackgroundWorkerCollection : Scenario {
		public override void Init (Toplevel top, ColorScheme colorScheme)
		{
			Application.Init ();

			Application.Run<MdiMain> ();
		}

		public override void Run ()
		{
		}

If Top was already initialized with Init method and never was called on Begin method and the current toplevel that is passed to the Begin method isn't the same as Top and isn't added in the toplevels, then that original Top must be disposed. To fix it we need to make this change.

If the Begin method was never called and Init is called again after a Shutdown then this fix is needed:

Here are some unit tests I've made in the ApplicationTests.cs. It fail without the fixes:
		[Fact]
		public void Dispose_Toplevel_Without_Begin_End ()
		{
			Application.Init (new FakeDriver (), new FakeMainLoop (() => FakeConsole.ReadKey (true)));

			Application.Shutdown ();

			Assert.Single (Responder.Instances);
			foreach (var inst in Responder.Instances) {
				Assert.True (inst.WasDisposed);
			}
		}

		[Fact]
		public void Dispose_Toplevel_IsMdiContainer_False_With_Begin_End ()
		{
			Application.Init (new FakeDriver (), new FakeMainLoop (() => FakeConsole.ReadKey (true)));

			var top = new Toplevel ();
			var rs = Application.Begin (top);
			Application.End (rs);

			Application.Shutdown ();

			Assert.Equal (2, Responder.Instances.Count);
			foreach (var inst in Responder.Instances) {
				Assert.True (inst.WasDisposed);
			}
		}

		[Fact]
		public void Dispose_Toplevel_IsMdiContainer_True_With_Begin ()
		{
			Application.Init (new FakeDriver (), new FakeMainLoop (() => FakeConsole.ReadKey (true)));

			var mdi = new Toplevel { IsMdiContainer = true };
			var rs = Application.Begin (mdi);
			Application.End (rs);

			Application.Shutdown ();

			Assert.Equal (2, Responder.Instances.Count);
			foreach (var inst in Responder.Instances) {
				Assert.True (inst.WasDisposed);
			}
		}

I prefer this approach because is not needed to create the Window if we don't needed it as this scenario. We don't need to call Application.Shutdown() because it will be called after exit the scenario in the UICatalog.

Please see PR #2167 - pull it down and use it as the basis for conversations on this topic. Feel free to submit PRs to this PR.
The fixes you suggested above are not valid as far as I can see. I implemented them and tons of other things broke.

		[Fact]
		public void Dispose_Toplevel_Without_Begin_End ()
		{
			Application.Init (new FakeDriver (), new FakeMainLoop (() => FakeConsole.ReadKey (true)));

			Application.Shutdown ();

			Assert.Single (Responder.Instances);
			foreach (var inst in Responder.Instances) {
				Assert.True (inst.WasDisposed);
			}
		}

This test already exists (effectively) in my latest PR, but with a comment noting #520 means callers must Dispose Top themselves: Init_Shutdown_Cleans_Up. The intent is to remove that line once #520 is fixed.

  [Fact]
  public void Dispose_Toplevel_IsMdiContainer_False_With_Begin_End ()
  {
  	Application.Init (new FakeDriver (), new FakeMainLoop (() => FakeConsole.ReadKey (true)));

  	var top = new Toplevel ();
  	var rs = Application.Begin (top);
  	Application.End (rs);

  	Application.Shutdown ();

  	Assert.Equal (2, Responder.Instances.Count);
  	foreach (var inst in Responder.Instances) {
  		Assert.True (inst.WasDisposed);
  	}
  }

  [Fact]
  public void Dispose_Toplevel_IsMdiContainer_True_With_Begin ()
  {
  	Application.Init (new FakeDriver (), new FakeMainLoop (() => FakeConsole.ReadKey (true)));

  	var mdi = new Toplevel { IsMdiContainer = true };
  	var rs = Application.Begin (mdi);
  	Application.End (rs);

  	Application.Shutdown ();

  	Assert.Equal (2, Responder.Instances.Count);
  	foreach (var inst in Responder.Instances) {
  		Assert.True (inst.WasDisposed);
  	}
  }

These tests are good! Added them.

If Top was already initialized with Init method and never was called on Begin method and the current toplevel that is passed to the Begin method isn't the same as Top and isn't added in the toplevels, then that original Top must be disposed. To fix it we need to make this change.

The issue with this proposed fix is: You don't set Top = null; after the calling Dispose. If you DO set it to null other things that use Top break (like MdiTop):

This does the trick, I think:

The issue with this proposed fix is: You don't set Top = null; after the calling Dispose. If you DO set it to null other things that use Top break (like MdiTop):

But I think it is not set to null. Is only to set the Responder.WasDisposed to true, but I could be wrong.

See latest update to the PR.
I have implemented your suggested fix (with tweaks). All unit tests except KeyBindings_Command_With_MdiTop pass.
No asserts from UI Catalog.
Check it out!!!!
See if you can figure out why that test broke...

I feel good about this for v1.9. I had originally tagged it as v2.0 because I was skeptical it could be fixed without breaking changes.
I need @tznind and @BDisp to take a close look at it though!


text:
🛑 Sefaz - Rio Grande do Sul is down

In af84e9f, Sefaz - Rio Grande do Sul (https://onboardapi.guichepass.com.br/sefaz?code=2) was down:

HTTP code: 500
Response time: 180 ms

Resolved: Sefaz - Rio Grande do Sul is back up in fe5929d.

repo: guichevirtual/statuspage


text:
Showing albums synced from iTunes.

Is there a way I could show the albums synced from the computer?

Sorry but as far as I know, the photo framework does not allow this. You should create your own picker with your own datasource.

repo: guillermomuntaner/GMImagePicker

license: mit


text:
chore(Blog): update “2016-12-17-making-sense-of-the-scaas-new-flavor-wheel”

Automatically generated by Netlify CMS

👷 Deploy Preview for lucileetguillaume processing.
🔨 Explore the source changes: 4126764c1bda67aaa610ec2ad6ad1092526255a9
🔍 Inspect the deploy log: https://app.netlify.com/sites/lucileetguillaume/deploys/615ea261a8c24a0007a2ea45

repo: guillim/nuxt-starter-netlify-cms


text:
Zookeeper: Liveness and Readiness Probes are Failing

When deployed in OpenShift 4.9 we're getting recurring probe failures for all Zookeeper pods:

In ss-nifi-zookeeper.yaml the probes are defined as echo "ruok" | timeout 2 nc -w 2 localhost 2181 | grep imok. By repeatedly calling echo ruok | nc localhost 2181 in a pod I'm able to reproduce the problem, and it is not due to timeouts: the ruok command is returning a blank response, but within less than a second. Since the failureThreshold for the probes is 6, there are no restarts of the pods. It's good that there are no restarts, but bad that it is frequently failing the probes.
Command to run in pod to look for empty responses:
#!/bin/bash

while true; do
    BEFORE=$(date)
    RESPONSE=$(echo ruok | nc localhost 2181)
    RETVAL=$?
    AFTER=$(date)

    if [ -z "$RESPONSE" ]; then
        echo $RETVAL $BEFORE $AFTER empty!
    elif [ $RESPONSE != imok ]; then
        echo $RETVAL $BEFORE $AFTER $RESPONSE
    fi

    # sleep 0.25
done

The output of the script looks like:
0 Tue Jul 5 15:35:01 UTC 2022 Tue Jul 5 15:35:01 UTC 2022 empty!
0 Tue Jul 5 15:38:02 UTC 2022 Tue Jul 5 15:38:02 UTC 2022 empty!
0 Tue Jul 5 15:45:08 UTC 2022 Tue Jul 5 15:45:09 UTC 2022 empty!

I also tried running nc with verbose output and it responds with Connection to localhost (::1) 2181 port [tcp/*] succeeded! even when there is no response from Zookeeper, so it's not a problem creating the connection. I also tried 127.0.0.1 instead of localhost, but the same problems happen.

Why is zookeeper not returning a response for the ruok command?
Is there something else that could be used for the probes?

In the nifi-zookeeper statefulset I set the ZOO_LOG_LEVEL environment variable from ERROR to INFO. This gives logging like:
2022-07-19 19:17:20,427 [myid:1] - INFO  [NIOWorkerThread-1:NIOServerCnxn@514] - Processing ruok command from /0:0:0:0:0:0:0:1:42920
2022-07-19 19:17:20,429 [myid:1] - INFO  [NIOWorkerThread-2:NIOServerCnxn@514] - Processing ruok command from /0:0:0:0:0:0:0:1:42922
2022-07-19 19:17:30,429 [myid:1] - INFO  [NIOWorkerThread-1:NIOServerCnxn@514] - Processing ruok command from /0:0:0:0:0:0:0:1:43622
2022-07-19 19:17:30,432 [myid:1] - INFO  [NIOWorkerThread-2:NIOServerCnxn@514] - Processing ruok command from /0:0:0:0:0:0:0:1:43626
2022-07-19 19:17:40,329 [myid:1] - INFO  [NIOWorkerThread-1:NIOServerCnxn@514] - Processing ruok command from /0:0:0:0:0:0:0:1:44294
2022-07-19 19:17:40,331 [myid:1] - INFO  [NIOWorkerThread-2:NIOServerCnxn@514] - Processing ruok command from /0:0:0:0:0:0:0:1:44298

Every 10s it is running both the liveness and readiness probes. I waited until one of the probes failed, but the logs remain the same - the server is always getting the ruok command. I tried setting the logging to DEBUG and then TRACE but no additional logging happens.
The server is always getting the ruok command and is not producing an error in the logs. Why is the response not being returned?

Hey! Sorry, I did not have much time to put into that yet.
But last week I set it up in my Dev environment and let it run for a few days. I did not have any single error.
Do you have some heavy load on the node, network, or anything that could explain this?

I appear to have found a stable configuration by using the -q 1 flag plus excessively high CPU and memory limits. So a fix is possible, but I need to figure out how low I can make the limits. In a week or so I should have a reasonable set of limits sorted out.

authors: WalterMoar guimou

repo: guimou/nifi-on-openshift


text:
Update minimatch to 3.0.2 or higher and remove deprecated lodash

After running npm install -g gulp, it displays this error.
npm WARN deprecated graceful-fs@3.0.8: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.
npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated minimatch@0.2.14: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated lodash@1.0.2: lodash@<3.0.0 is no longer maintained. Upgrade to lodash@^4.0.0.
npm WARN deprecated graceful-fs@1.2.3: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree.

No. Please do an issue search before opening issues like this.

Since this issue turns op high in google for 'gulp minimatch', I'm guessing a lot of people come here hoping to find a solution. Could you please link to the relevant issue(s), or give some form of explanation?

https://github.com/gulpjs/gulp/issues/1571
And here's why it isn't an issue: https://github.com/gulpjs/gulp/issues/1719#issuecomment-231514385

authors: callumacrae fritzdenim mrwensveen phated

repo: gulpjs/gulp


text:
CalculateAverage_gonix initial attempt

Check List:

[x] Tests pass (./test.sh <username> shows no differences between expected and actual outputs)
[x] All formatting changes by the build are committed
[x] Your launch script is named calculate_average_<username>.sh (make sure to match casing of your GH user name) and is executable
[x] Output matches that of calculate_average_baseline.sh

Execution time: ~2.5s
Execution time of reference implementation: ~145s
Machine: Intel i7-11800H @ 2.30GHz (max 4.6GHz), 8 cores (16 threads), 32GB RAM

Interesting, this one has a huge variance in terms of execution times. Are you observing the same?

Interesting. Ignoring the first run with a cold cache (which takes ~4.5s), I used to get variance between ~2.4s to ~2.9s on a consecutive runs, but I was attributing this variance to CPU boost and thermal throttling on my laptop. I assumed thermals would not be a problem on a server, so I do add sleep 10 between runs to get more stable execution times (idea being that the sleep would allow my laptop CPU to cool down a bit). With the sleep in place I get variance between ~2.4s to ~2.5s with rare dips into 2.3s territory and rare spikes into 2.6s.
Would be really interesting to hear what kind of variance you see on the server side?

It's pretty wild:
Benchmark 1: timeout -v 300 ./calculate_average_gonix.sh 2>&1
  Time (mean ± σ):      6.953 s ±  1.144 s    [User: 42.340 s, System: 0.726 s]
  Range (min … max):    5.696 s …  8.092 s    5 runs

Summary
  gonix: trimmed mean 6.993008276126667, raw times 7.12710650246,8.09195019346,5.69645367346,8.00444639346,5.84747193246

Leaderboard

| # | Result (m:s.ms) | Implementation     | JDK | Submitter     | Notes     |
|---|-----------------|--------------------|-----|---------------|-----------|
|   | 00:06.993 | [link](https://github.com/gunnarmorling/1brc/blob/main/src/main/java/dev/morling/onebrc/CalculateAverage_gonix.java)| 21.0.1-open | [gonix](https://github.com/gonix) |  |

I also don't think thermal throttling is an issue, I am not observing this for other entries. Anyways, gonna add it. Thx for participating!

Super interesting, thanks for sharing!

authors: gonix gunnarmorling


text:
greetings.corpus.json

greetings corpus in hebrew

Thank you

repo: gunthercox/chatterbot-corpus


text:
数据集ModelNet40

你好 问下在数据集ModelNet40上的正确率4如何呢

check  modelzoo
ModelNet40 Classificaiton

name
OA/mAcc (Original)
OA/mAcc (our released)
#params
FLOPs
Throughput (ins./sec.)

PointNet++
91.9 / -
93.0 / 90.7
1.5M
1.7G
1872

PointNeXt-S (C=64)
93.7±0.3 / 90.9±0.5
94.0 / 91.1
4.5M
6.5G
2033

谢谢收到

许多年以后
@.***

------------------ 原始邮件 ------------------
发件人: "Yuchen @.>;
发送时间: 2023年2月28日(星期二) 下午4:32
收件人: @.>;
抄送: @.>; @.>;
主题: Re: [guochengqian/PointNeXt] 数据集ModelNet40 (Issue #107)
check  modelzoo
ModelNet40 Classificaiton
name OA/mAcc (Original) OA/mAcc (our released) #params FLOPs Throughput (ins./sec.)
PointNet++ 91.9 / - 93.0 / 90.7 1.5M 1.7G 1872
PointNeXt-S (C=64) 93.7±0.3 / 90.9±0.5 94.0 / 91.1 4.5M 6.5G 2033
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

repo: guochengqian/PointNeXt


text:
Onde está o slide da aula 04?

Procurei o slide da aula 04 e não encontrei. Alguém poderia atualizar para mim?

A aula 04 não tem slide, é uma aula prática!

Provavelmente ela já esta disponível, pois estou fazendo seu curso de git e github 3 anos depois inclusive está excepcional

Provavelmente já está disponível agora, to fazendo o curso depois de 3 anos kkkk

authors: Laicram88 RafaelRobertoVS danilobonan eduqn

repo: gustavoguanabara/git-github


text:
Minimal instructions to get started

Currently, getting started with the project is a bit complex.
It's possible to get it up and running without setting up firebase / google maps account, by using the same one as production. More specifically, I found that setting only these two values is enough to get the app to run:
REACT_APP_FIREBASE_API_KEY=AIzaSyABre2owU3Y-giO0V8U4h4eYN32iFU_hoU
REACT_APP_FIREBASE_PROJECT_ID=one-kol

(don't worry about the firebase API key, it's not a secret).
This should be good enough for getting to the main screen, and being able to start hacking on the project without needing to set up any new cloud accounts (like the comment in #16).
The maps google maps API key from production also works in this setup. I understand that you are billed per request, so you might not want to share it, though, if it seems like 1 developer making contribution is probably worth more than the cost of the few requests they'll make. But this is totally up to you...

Also, potential contributors can use codesandbox to get up and running really fast: go to https://githubbox.com/guytepper/1km.co.il , put the values in the .env file, and then you get a VSCode in the browser ready to start hacking:

Thanks for pointing this out. I agree.
The codesandbox solution is amazing. Thank you.

On second thought, it works now because localhost is an authorized origin (forgot to disable it).
I can leave it like that, but I'm afraid that the bad guys will make hundreds of requests much more easily.
I thought about creating a firebase development project for this purpose, copy the current production database (without people emails and other private info) over there and put this as a default project. What do you think?

That sounds like a good idea. This way, contributors will also be able to submit fake/test data without affecting production.
In any case, I'd double check the access rules for that data on the production database - and if you are still unsure, you can ask people in this group to take a look and see if there are any security issues.

By the way, this also means you can connect the repo to vercel (2 minute setup and free), and get a preview URL any time somebody makes a pull request, e.g. wokwi/good-arduino-code#12 (see the comment from vercel bot there with the preview link).

@urish do you prefer Vercel over something like Netlify? I know vercel is great for next.js projects, but Netlify offers mostly the same features, and from my experience is easier to deal with.

No strong opinions here, they both do very similar things. I originally wanted to recommend Netlify (it is also free for organizations, which is not the case with Vercel). The only reason I ended up recommending Vercel is that the preview links for PRs are publicly viewable (unlike Netlify, which requires you to be a collaborator to view these links, as far as I can tell).

@urish I think you're right, and Netlify only allows one collaborator on its free plan. It sounds like Vercel will better suit our needs.

authors: daganomri guytepper urish


text:
Keep getting BadMethodCallException from EasyHandle

Hi,
All of a sudden when calling:
$client->request('post', $endpointUrl, $requestParameters);
or
$client->requestAsync('post', $endpointUrl, $requestParameters);
I get this following error and nothing else:

The website encountered an unexpected error. Please try again later.BadMethodCallException: The EasyHandle has been released in GuzzleHttp\Handler\EasyHandle->__get() (line 90 of vendor/guzzlehttp/guzzle/src/Handler/EasyHandle.php).

Expected is either returned ResponseInterface implementing object or a RequestException (inheriting) exception, I receive neither.
It may have something to do with changes on the queried server, but shouldn't there be RequestException thrown in these cases, when request response is not retrievable?
Any ideas how to resolve the issue or at least avoid everything crashing down? The behaviour is correct when I set a too small timeout, but when I set a timeout of 5 seconds, I get this error also.
Best,
Alari

Could you add the stack trace? It could help a lot to determine the reason of the exception.
Also, if it's possible, add all the details about the client. I mean all the options that you use to initialise Guzzle's Client: timeouts, etc.

Hi,
I'm using the client initialized by drupal with just 2 parameters:
$request_options = array(       'auth' => [self::$user, self::$pass],       'form_params' => $request,     );
the rest of the code is:
`try {
if (!$async) {
$response = \Drupal::httpClient()->request('post', $uri, $request_options);
return $this->encoder->decode($response->getBody()->__toString(), 'xml');
} else {
return \Drupal::httpClient()->requestAsync('post', $uri, $request_options);
}
} catch (RequestException $e) {
dpm($e);
}
return FALSE;`

But even though the Exception is being caught and the dpm() inside the exception caught is fired, the EasyHandle still throws the error somewhere.
dpm is drupal variable dump using kint (in my scenario).
The dpm() tells me that the connection timed out:
'errno' => integer28
'error' => string(66) "Operation timed out after 30000 milliseconds with 0 bytes received"
The stack trace is extremely horrifyingly long but after the dpm() is being fired in the error catching there's a lot of kintParser stuff for the dpm() and after that just 2 function calls of any relevance:
'36: ReflectionProperty->getValue()'
'37: GuzzleHttp\Handler\EasyHandle->__get()'
From which the latter already causes the error being thrown.
The ReflectionProperty get's argument GuzzleHttp\Handler\EasyHandle with following values:
→public sink -> GuzzleHttp\Psr7\Stream(7)
public headers -> array(0)
public response -> NULL
→public request -> GuzzleHttp\Psr7\Request(8)
→public options -> array(11)
public errno -> integer28
public onHeadersException -> NULL
public handle -> NULL
Unfortunately I don't have a clear way of dumping all the data in a readable way, the drupal ddebug_backtrace() is the only thing that put anything out and I had to parse it into html to read myself, running the kint script for formatting.
Best,
Alari

Okay, so in fact you receive a RequestException with the message "Operation timed out....".
Any chance that the dpm stuff calls something that it shouldn't?
What if you just var_dump the exception?

I faced a similar issue. In my case I use Sentry for PHP errors and exceptions reporting. And each time a connection via Guzzle timed out I was getting a white screen with the text:
BadMethodCallException
The EasyHandle has been released

instead of the graceful 5xx error page.
The problem in my case was caused by a serializer for vars from the errors stack trace. My user defined serializer was getting the values for every property of every var using the ReflectionClass. And when the serializer was trying to get the handle property from the GuzzleHttp\Handler\EasyHandle the next code from Guzzle was throwing exception:
https://github.com/guzzle/guzzle/blob/0773d442aa96baf19d7195f14ba6e9c2da11f8ed/src/Handler/EasyHandle.php#L85-L91
Fixing the serializer worked for me.
@Alluuu, maybe dpm was doing something similar in your case.

I'm seeing this problem with Drupal's Devel module too.
The problem seems to be that there's a warning in Guzzle somewhere, which Devel is then handling with its custom PHP error handler.
That passes the backtrace to Devel's dpm() function, which hands over to Kint, which does this:
ReflectionProperty->getValue(Object) (Line: 496)
kintParser::_parse_object(Object, Object) (Line: 115)

It looks like getValue() is crashing because the object is a resource that's been released.
Unfortunately, it looks like there there's no simple way in PHP to check that something is a released resource. The fix would be for Kint to check for that and then skip it.

Same thing here. Generating debug dump on error throws \BadMethodCallException.
Officially public properties must not generate exceptions on access.
Had to add the following code to __get method:
if (in_array($name, ['handle', 'sink', 'headers', 'response', 'request', 'options', 'errno', 'onheadersexception'])) {
    return null;
}

authors: Alluuu alexeyshockov ethernidee golubev joachim-n sagikazarmark

repo: guzzle/guzzle


text:
Send File and data with POST Method in One Request...

Hi folks,
In v4 and below, I'm using POST request to send date and file as below code
        $client = Client();
        $request = $client->request('POST', $url, ['headers' => ['Authorization' => 'auth_trusted_header')]]);

        /** @var \GuzzleHttp\Post\PostBody $body */
        $body = $request->getBody();
        $body->setField('authorId', $user->getId());
        $body->setField('context', 'avatar');
        $body->addFile(
            new PostFile(
                'file',
                fopen('data://text/plain;base64,'.$avatar, 'r'),
                $user->getId().'.png'
            )
        );
        try {
            $response = $client->send($request);
        } catch (\Exception $e) {
            $response = false;
            $this->errors[$user->getId()] = $e->getMessage();
        }

Now after upgrading to V6 i have updated the code as below;
        $client = new \GuzzleHttp\Client();
        $request = $client->post( $url, [
            ['headers' => ['Authorization' => 'auth_trusted_header')]],
            'json' => [
                'authorId' =>$user->getId(),
                'context' => 'avatar',
            ],
            'multipart' => [
                [
                    'name'     => 'file',
                    'contents' => fopen('data://text/plain;base64,'.$avatar, 'r'),
                    'filename' => $user->getId().'.png'
                ]
            ]
        ]);

Now when i post the date, i get error that No files given for upload [] []...

You cannot mix json and multipart together (and you don't need json at all, according to the first code example).
$client = new \GuzzleHttp\Client();
$request = $client->post( $url, [
    'headers' => ['Authorization' => 'auth_trusted_header'],
    'multipart' => [
        [
            'name' => 'authorId',
            'contents' => $user->getId(),
        ],
        [
            'name' => 'context',
            'contents' => 'avatar',
        ],
        [
            'name'     => 'file',
            'contents' => fopen('data://text/plain;base64,'.$avatar, 'r'),
            'filename' => $user->getId().'.png'
        ]
    ]
]);

BTW, StackOverflow is a better place for such type of questions (this tracker is more for bugs and feature requests).

@alekseykuleshov Thanks for commenting, below code also works for me..
$client = new Client(['headers' => ['Authorization' => 'auth_trusted_header']);
        $options = [
            'multipart' => [
                [
                    'Content-type' => 'multipart/form-data',
                    'name' => 'file',
                    'contents' => fopen('data://text/plain;base64,'.$avatar, 'r'),
                    'filename' => $user->getId().'.png',
                ],
                [ 'name' => 'authorId', 'contents' => $user->getId() ],
                [ 'name' => 'context', 'contents' => 'avatar', ]
            ],
        ];
$response = $client->post($url, $options);

authors: alexeyshockov muhammadtaqi


text:
Drop support for EOL Python 3.4

Python 3.4 is EOL and no longer receiving security updates (or any updates) from the core Python team.

Version
Release date
Supported until

2.7
2010-07-03
2020-01-01

3.4
2014-03-16
2019-03-16

Source: https://en.wikipedia.org/wiki/CPython#Version_history

Coverage remained the same at 94.433% when pulling 76f99be83be3076c24a91b2b7b82df430bb413c4 on hugovk:rm-3.4 into 27cebc56a0f6a900eeb897512879d545095f410b on gweis:master.

Python 2.7 and 3.5 are also EOL now, but closing this year old PR. Happy to re-open and drop those other versions, just ping!

authors: coveralls hugovk

repo: gweis/isodate