[Ecowitt] An issue occured while updating sensor values for WH40. Update on 7044:WH40 requires data

name: Bug Report
about: Create a report to help us improve
title: ''
labels: bug
assignees: ''

Describe The Bug:
WH40 - Self Emptying Water gauge does not send valid data-  Recommendation in the Error Message is to restart Homebride to reregister the Sensor, which does not resolve the issue.
Additionally, WS90 returns a Current Ambient Light level over the maximum (set somewhere) of 100,000
To Reproduce:
Restart Homebridge and the Error Messages appear every few minutes.  For the Ambient Light Level I have tried the Thresholds at botht he default blank and the current setting of 0.
Expected behavior:
During normal Operation that these Errors do not appear in he lo
Logs:
[09/12/2024, 16:04:48] [Ecowitt] Setting Rain Rate intensity to None
[09/12/2024, 16:04:48] [Ecowitt] Updating sensor - type: WH51 channel: 1
[09/12/2024, 16:04:48] [Ecowitt] Updating accessory 7044:WH51CH1
[09/12/2024, 16:04:48] [Ecowitt] Updating sensor - type: WH40
[09/12/2024, 16:04:48] [Ecowitt] An issue occured while updating sensor values for WH40. Update on 7044:WH40 requires data rainbatt,rainratein,eventrainin,hourlyrainin,dailyrainin,weeklyrainin,monthlyrainin,yearlyrainin. Please file a bug report if needed at https://bit.ly/3yklrWZ
[09/12/2024, 16:05:48] [Ecowitt] Received request for POST /data/report from ::ffff:<IP_ADDRESS>
[09/12/2024, 16:05:48] [Ecowitt] Recieved data report, if you are submitting a bug report copy and paste the full data report object
[Ecowitt] Updating accessory 7044:WS90
[09/12/2024, 16:05:49] [homebridge-ecowitt-weather-sensors] This plugin generated a warning from the characteristic 'Current Ambient Light Level': characteristic was supplied illegal value: number 113749.993 exceeded maximum of 100000. See https://homebridge.io/w/JtMGR for more info.
[09/12/2024, 16:05:49] [homebridge-ecowitt-weather-sensors] Error:
at CurrentAmbientLightLevel.Characteristic.characteristicWarning (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:3016:105)
at CurrentAmbientLightLevel.Characteristic.validateUserInput (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2932:14)
at CurrentAmbientLightLevel.Characteristic.updateValue (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2333:20)
at LightSensor.Service.updateCharacteristic (/var/lib/homebridge/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Service.ts:804:35)
at LightSensor.updateLux (/var/lib/homebridge/node_modules/homebridge-ecowitt-weather-sensors/src/sensors/LightSensor.ts:62:18)
at LightSensor.update (/var/lib/homebridge/node_modules/homebridge-ecowitt-weather-sensors/src/sensors/LightSensor.ts:54:10)
at WS90.update (/var/lib/homebridge/node_modules/homebridge-ecowitt-weather-sensors/src/devices/WS90.ts:219:26)
at EcowittPlatform.updateAccessories (/var/lib/homebridge/node_modules/homebridge-ecowitt-weather-sensors/src/EcowittPlatform.ts:719:28)
at EcowittPlatform.onDataReport (/var/lib/homebridge/node_modules/homebridge-ecowitt-weather-sensors/src/EcowittPlatform.ts:283:10)
at /var/lib/homebridge/node_modules/homebridge-ecowitt-weather-sensors/src/EcowittPlatform.ts:143:14
Data Report:

 {
  "PASSKEY": "<deleted>",
  "stationtype": "GW1200C_V1.3.3",
  "runtime": "1015983",
  "heap": "98948",
  "dateutc": "2024-12-09 05:05:47",
  "tempinf": "75.74",
  "humidityin": "40",
  "baromrelin": "28.739",
  "baromabsin": "28.739",
  "tempf": "70.52",
  "humidity": "44",
  "winddir": "107",
  "windspeedmph": "2.68",
  "windgustmph": "6.71",
  "maxdailygust": "13.42",
  "solarradiation": "897.79",
  "uv": "8",
  "rainratein": "0.000",
  "eventrainin": "0.000",
  "hourlyrainin": "0.000",
  "dailyrainin": "0.000",
  "weeklyrainin": "0.000",
  "monthlyrainin": "0.764",
  "yearlyrainin": "3.945",
  "totalrainin": "3.945",
  "rrain_piezo": "0.000",
  "erain_piezo": "0.000",
  "hrain_piezo": "0.000",
  "drain_piezo": "0.000",
  "wrain_piezo": "0.000",
  "mrain_piezo": "0.780",
  "yrain_piezo": "0.780",
  "srain_piezo": "0",
  "ws90cap_volt": "5.4",
  "ws90_ver": "144",
  "soilmoisture1": "38",
  "soilad1": "171",
  "wh40batt": "1.5",
  "soilbatt1": "1.6",
  "wh90batt": "3.12",
  "freq": "433M",
  "model": "GW1200C",
  "interval": "60"
}

Plugin Config:
"name": "Ecowitt",
"baseStation": {
"mac": "",
"port": 8085,
"path": "/data/report"
},
"additional": {
"staticNames": "false",
"validateMac": "true",
"luxFactor": 126.7,
"acceptAnyPath": "false",
"validateTimestamp": "true",
"removeStaleDevices": "true"
},
"thresholds": {
"rainRate": 0,
"rainEventTotal": 0,
"rainHourlyTotal": 0,
"rainDailyTotal": 0,
"rainWeeklyTotal": 0,
"rainMonthlyTotal": 0,
"rainYearlyTotal": 0
},
"units": {
"wind": "kph",
"rain": "mm",
"distance": "km",
"temperature": "ce"
},
"platform": "Ecowitt"
}
Screenshots:

Environment:

Plugin Version:v2.5.1
Homebridge Version: 1.8.5
Node.js Version: 20.18.1
NPM Version: 10.8.2
Operating System: Raspberry Pi Model B Plus Rev 1.2 - image_2024-11-29-Homebridge-bookworm-32bit

Thank you @AlbyZ for reporting this.  I've taken a quick look and both issues look like they are bugs in the plugin.  I'll take some time to address.  Thanks.

I am seeing the same here with the same version of the plugin and Homebridge. I am forwarding the data through FOSHKPlugin as I also use CumulusMX with my weather station.
This is therefore reporting zero or not detected values for any of the detected WS90 sensors connected to my HP2564 Gateway.
[09/12/2024, 21:42:56] [Ecowitt] Note that accessory HP2564 does not currently use and/or display the following data: baromrelin,baromabsin
[09/12/2024, 21:42:56] [Ecowitt] Restoring existing accessory from cache - type: WS90, uuid: ad2c3197-ebaf-459f-8560-1c938800b5a2
[09/12/2024, 21:42:56] [Ecowitt] Note that accessory WS90 does not currently use and/or display the following data: ws90cap_volt,ws90_ver
[09/12/2024, 21:42:56] [Ecowitt] There was unused data from data report rainratein,eventrainin,hourlyrainin,dailyrainin,weeklyrainin,monthlyrainin,yearlyrainin,gain10_piezo,gain20_piezo,gain30_piezo,gain40_piezo,gain50_piezo. This indicates that a sensor may not have been successfully discovered. Try restarting Homebridge so that the plugin re-registers devices from the data report
[09/12/2024, 21:42:56] [Ecowitt] An issue occured while updating sensor values for WS90. Update on 7936:WS90 requires data wh90batt,tempf,humidity,solarradiation,uv,winddir,windspeedmph,windgustmph,maxdailygust,rrain_piezo,erain_piezo,hrain_piezo,drain_piezo,wrain_piezo,mrain_piezo,yrain_piezo. Please file a bug report if needed at https://bit.ly/3yklrWZ
[09/12/2024, 21:43:19] [Ecowitt] An issue occured while updating sensor values for WS90. Update on 7936:WS90 requires data wh90batt,tempf,humidity,solarradiation,uv,winddir,windspeedmph,windgustmph,maxdailygust,rrain_piezo,erain_piezo,hrain_piezo,drain_piezo,wrain_piezo,mrain_piezo,yrain_piezo. Please file a bug report if needed at https://bit.ly/3yklrWZ
[09/12/2024, 21:43:42] [Ecowitt] An issue occured while updating sensor values for WS90. Update on 7936:WS90 requires data wh90batt,tempf,humidity,solarradiation,uv,winddir,windspeedmph,windgustmph,maxdailygust,rrain_piezo,erain_piezo,hrain_piezo,drain_piezo,wrain_piezo,mrain_piezo,yrain_piezo. Please file a bug report if needed at https://bit.ly/3yklrWZ
[09/12/2024, 21:44:03] [Ecowitt] An issue occured while updating sensor values for WS90. Update on 7936:WS90 requires data wh90batt,tempf,humidity,solarradiation,uv,winddir,windspeedmph,windgustmph,maxdailygust,rrain_piezo,erain_piezo,hrain_piezo,drain_piezo,wrain_piezo,mrain_piezo,yrain_piezo. Please file a bug report if needed at https://bit.ly/3yklrWZ
[09/12/2024, 21:44:24] [Ecowitt] An issue occured while updating sensor values for WS90. Update on 7936:WS90 requires data wh90batt,tempf,humidity,solarradiation,uv,winddir,windspeedmph,windgustmph,maxdailygust,rrain_piezo,erain_piezo,hrain_piezo,drain_piezo,wrain_piezo,mrain_piezo,yrain_piezo. Please file a bug report if needed at https://bit.ly/3yklrWZ
[09/12/2024, 21:44:45] [Ecowitt] An issue occured while updating sensor values for WS90. Update on 7936:WS90 requires data wh90batt,tempf,humidity,solarradiation,uv,winddir,windspeedmph,windgustmph,maxdailygust,rrain_piezo,erain_piezo,hrain_piezo,drain_piezo,wrain_piezo,mrain_piezo,yrain_piezo. Please file a bug report if needed at https://bit.ly/3yklrWZ
[09/12/2024, 21:45:10] [Ecowitt] An issue occured while updating sensor values for WS90. Update on 7936:WS90 requires data wh90batt,tempf,humidity,solarradiation,uv,winddir,windspeedmph,windgustmph,maxdailygust,rrain_piezo,erain_piezo,hrain_piezo,drain_piezo,wrain_piezo,mrain_piezo,yrain_piezo. Please file a bug report if needed at https://bit.ly/3yklrWZ
[09/12/2024, 21:45:34] [Ecowitt] An issue occured while updating sensor values for WS90. Update on 7936:WS90 requires data wh90batt,tempf,humidity,solarradiation,uv,winddir,windspeedmph,windgustmph,maxdailygust,rrain_piezo,erain_piezo,hrain_piezo,drain_piezo,wrain_piezo,mrain_piezo,yrain_piezo. Please file a bug report if needed at https://bit.ly/3yklrWZ
[09/12/2024, 21:45:55] [Ecowitt] An issue occured while updating sensor values for WS90. Update on 7936:WS90 requires data wh90batt,tempf,humidity,solarradiation,uv,winddir,windspeedmph,windgustmph,maxdailygust,rrain_piezo,erain_piezo,hrain_piezo,drain_piezo,wrain_piezo,mrain_piezo,yrain_piezo. Please file a bug report if needed at https://bit.ly/3yklrWZ
[09/12/2024, 21:46:16] [Ecowitt] An issue occured while updating sensor values for WS90. Update on 7936:WS90 requires data wh90batt,tempf,humidity,solarradiation,uv,winddir,windspeedmph,windgustmph,maxdailygust,rrain_piezo,erain_piezo,hrain_piezo,drain_piezo,wrain_piezo,mrain_piezo,yrain_piezo. Please file a bug report if needed at https://bit.ly/3yklrWZ
[09/12/2024, 21:46:38] [Ecowitt] An issue occured while updating sensor values for WS90. Update on 7936:WS90 requires data wh90batt,tempf,humidity,solarradiation,uv,winddir,windspeedmph,windgustmph,maxdailygust,rrain_piezo,erain_piezo,hrain_piezo,drain_piezo,wrain_piezo,mrain_piezo,yrain_piezo. Please file a bug report if needed at https://bit.ly/3yklrWZ
[09/12/2024, 21:46:59] [Ecowitt] An issue occured while updating sensor values for WS90. Update on 7936:WS90 requires data wh90batt,tempf,humidity,solarradiation,uv,winddir,windspeedmph,windgustmph,maxdailygust,rrain_piezo,erain_piezo,hrain_piezo,drain_piezo,wrain_piezo,mrain_piezo,yrain_piezo. Please file a bug report if needed at https://bit.ly/3yklrWZ
[09/12/2024, 21:47:20] [Ecowitt] An issue occured while updating sensor values for WS90. Update on 7936:WS90 requires data wh90batt,tempf,humidity,solarradiation,uv,winddir,windspeedmph,windgustmph,maxdailygust,rrain_piezo,erain_piezo,hrain_piezo,drain_piezo,wrain_piezo,mrain_piezo,yrain_piezo. Please file a bug report if needed at https://bit.ly/3yklrWZ

I rolled back to 2.5.1 and the issue was still present.
Then rolled back to 2.4.1 and the issue was still present.
Rolled back to 2.4.0 Beta when the WS90 support was added and the issue still occurred with the following messages:
[09/12/2024, 22:06:59] [Ecowitt] Note that accessory WS90 does not currently display the following data: ws90cap_volt,ws90_ver
[09/12/2024, 22:06:59] [Ecowitt] There was unused data from data report rainratein,eventrainin,hourlyrainin,dailyrainin,weeklyrainin,monthlyrainin,yearlyrainin,gain10_piezo,gain20_piezo,gain30_piezo,gain40_piezo,gain50_piezo. This indicates that a sensor may not have been successfully discovered. Try restarting Homebridge so that the plugin re-registers devices from the data report
[09/12/2024, 22:06:59] [Ecowitt] An issue occured while updating sensor values for WS90.

Hi @Tomhodgson.  Would you be able to provide a copy/paste of your data report?  Instructions for obtaining that can be found here.

Hi @rhockenbury sure thing here you are:
[09/12/2024, 23:50:01] [Ecowitt] Recieved data report, if you are submitting a bug report copy and paste the full data report object
{
"PASSKEY": "REMOVED",
"stationtype": "EasyWeatherPro_V5.1.7",
"runtime": "2437708",
"heap": "25328",
"dateutc": "2024-12-09 23:50:01",
"tempinf": "66.7",
"humidityin": "54",
"baromrelin": "29.976",
"baromabsin": "29.976",
"tempf": "41.4",
"humidity": "79",
"winddir": "234",
"windspeedmph": "2.68",
"windgustmph": "10.74",
"maxdailygust": "23.93",
"solarradiation": "0.00",
"uv": "0",
"rainratein": "0.000",
"eventrainin": "2.150",
"hourlyrainin": "0.000",
"dailyrainin": "0.165",
"weeklyrainin": "0.705",
"monthlyrainin": "2.441",
"yearlyrainin": "4.004",
"ws90cap_volt": "2.4",
"ws90_ver": "147",
"gain10_piezo": "1.00",
"gain20_piezo": "1.00",
"gain30_piezo": "1.00",
"gain40_piezo": "1.00",
"gain50_piezo": "1.00",
"wh90batt": "2.96",
"freq": "868M",
"model": "HP2564AE_Pro_V1.9.8",
"interval": "20",
"isintvl": "21",
"isintvl10": "22",
"dewptf": "35.3",
"windchillf": "41.4",
"feelslikef": "41.4",
"heatindexf": "39.0",
"windspdmph_avg10m": "2.9",
"winddir_avg10m": "328",
"windgustmph_max10m": "12.1",
"windrun": "10.94",
"brightness": "0.0",
"sunhours": "0.0",
"sunshine": "0",
"srsum": "0.0",
"ptrend1": "-1",
"pchange1": "-0.003"
}

@rhockenbury I did also change FOSHKPlugin to forward the data type as Ecowitt Format (EW) rather than RAWEW which it was at before and I now get the error messages as follows instead:
[09/12/2024, 23:49:19] [Ecowitt] An issue occured while updating sensor values for WS90. Update on 7936:WS90 requires data wh90batt,tempf,humidity,solarradiation,uv,winddir,windspeedmph,windgustmph,maxdailygust,rrain_piezo,erain_piezo,hrain_piezo,drain_piezo,wrain_piezo,mrain_piezo,yrain_piezo.

Hi @Tomhodgson. It looks like the data report is missing the piezo rain values - which is expected for the WS90 b/c it has the piezo rain gauge.  Here's an example of a data report with all expected WS90 values - https://github.com/rhockenbury/homebridge-ecowitt-weather-sensors/blob/master/tests/synthetic/data/hp2564_ws90.json#L18-L24.
Is it possible that the FOSHKPlugin is remapping the rain values?  Would you be able to share the data report that's coming directly from your Ecowitt base station before it's processed by the FOSHKPlugin?

@rhockenbury I pointed the Ecowitt straight at the homebridge Pi and actually that has worked just fine. Apologies I really should have thought to try that before, it looks like the FOSHKPlugin is the issue then. I will have to look for a workaround then to see what is happening but as far as I know it should be sending the data straight through just fine as RAWEW or EW type

@rhockenbury I figured it out. In the FOSHK config file I had the value WS90_CONVERT = True in the weatherstation configuration which was outputting the wrong strings. I have changed this back to False instead of True and it is working fine now

Hi @Tomhodgson, that's great to hear.  Would you be willing to share your FOSHK config file?  It might be useful for others using FOSHK with the Ecowitt plugin to have that as reference.
I'll leave this issue open as I still need to resolve the two issues that @AlbyZ brought up.  I should have the fix for those published in early January.


Mobile responsiveness

The website should be mobile resposive

Add hamburger icon, adjust screen size etc

hey i would like to work on this

hey i would like to work on this

@stahreem : someone has already opened pr for this.
Pick some other issue

I can help you with it in this.


getDescendantsTree() method missing

hi,
getDescendantsTree() is mentioned in the docs, but missing entirely in the code.
Used ->getDescendants()->toTree() instead, but if it's in the docs, it should be there.
Also sidenote: a small usage-example would be rather usefull for people using ClosureTable for the first time.

Hi, I have added two methods: getAncestorsTree and getDescendantsTree. Thanks for participation!
As for usage example: there's a separate repository called ClosureTable-demo. It uses Laravel 4 but I think that common practices would be clear.

Thank you very much!
Did not know about the demo repository. Of course that is enough.


Fetch upstream

Huh, why is the bot pinging me? Do I need to do something here? I don't even have a Vercel account.


CI failed for master

But the PR (https://github.com/maputnik/editor/pull/729) passed the tests. Looks like it's related to the selenium tests.
https://github.com/maputnik/editor/runs/1118988525?check_suite_focus=true

So it looks like the following test is flakey, only passes sometimes...
[chrome 85.0.4183.83 linux #0-0]         groups
[chrome 85.0.4183.83 linux #0-0]            ✖ simple

I've re-run the tests and they passed the second time around. I'll leave this ticket open to take a look at that test see if I can work out what's wrong with it.
I'm also interested in trying out https://github.com/microsoft/playwright at some point as a replacement for webdriver, because webdriver has generally caused me a lot of pain over the years. I've spent much time battling webdriver, also there have been cases in the past because of flakey tests I've missed actual bugs in the code, saying to myself "oh that's a flakey test, I'll disable that for now, fix it later". I've also had to add a few work arounds for genuine bugs in chromedriver/webdriver to do with text entry.
Note: The windows build is now failing, whereas it was the chrome build previously. I've seen this also on occasion also with the windows env on github actions, I think it might be an environment issue, although I'm not 100% about that.

@orangemug yeah, we had webdriver issues also here in the past.
https://github.com/microsoft/playwright looks interesting.

I'll leave this ticket open to take a look at that test see if I can work out what's wrong with it.

Maybe the reason is one of these lines:
https://github.com/maputnik/editor/blob/master/test/functional/layers/index.js#L485-L487
The test is about automatic grouping and I just did this test manually and the last added layer wasn't visible in the viewport after expanding the group (there was a need for me to scroll down to get it into the viewport).

So we could try to scroll down the layer list after https://github.com/maputnik/editor/blob/master/test/functional/layers/index.js#L483.
Note: I just manually rerun the workflow because the failing CI badge didn't look nice on https://github.com/maputnik/editor/

Or we need a little timeout after https://github.com/maputnik/editor/blob/master/test/functional/layers/index.js#L483 to be sure that the animation expanding the group has finished.

No issue anymore after #778 :-)


Add typescript-enum-array plugin

🚨 IMPORTANT: Please do not create a Pull Request without creating an issue first.
Any change needs to be discussed before proceeding. Failure to do so may result in the rejection of the pull request.
Description
Add new plugin that generates const arrays
Related #6258
Type of change
Please delete options that are not relevant.

[x] New feature (non-breaking change which adds functionality)
[x] This change requires a documentation update

Screenshots/Sandbox (if appropriate/relevant):
Adding links to sandbox or providing screenshots can help us understand more about this PR and take action on it as appropriate
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] I have generate own project with this config:

overwrite: true
schema: 'schema.graphql'
documents:
  - 'queries/*.graphql'
generates:
  generated-graphql.ts:
    plugins:
      - typescript:
          enumsAsTypes: true
  generated-const.ts:
    plugins:
      - typescript-enum-array:
          importFrom: './generated-graphql'

Test Environment:

OS: MacOS
@graphql-codegen/...:
NodeJS: v16.4.1

Checklist:

[x] I have followed the CONTRIBUTING doc and the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

@marocchino thank you, can you please create a changeset file? (Run yarn changeset and it will guide you)

I wrote some test for it. Please let me know if there is anything I need to do before merge. ✋🏽


bad eog channel

Dear MNE group
I got some problem when I process my data with a bad eog channel.
If I mark the eog channel as a bad one, does MNE will interpolate it with prefrontal sensors?
If not, what should I do for that, considering I just have some of datas with bad eog.
THX!

This appears to be a question about usage, not a bug report or a new feature request. Please use the MNE mailing list or the gitter channel for usage questions.


Mention that no one else will know the current state of permission grants

Code of Conduct

[X] I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?
https://docs.github.com/en/support/learning-about-github-support/about-github-support#granting-github-support-temporary-access-to-a-private-repository
What part(s) of the article would you like to see updated?

Granting GitHub Support temporary access to a private repository
If GitHub Support needs to access a private repository to address your support request, the owner of the repository will receive an email with a link to accept or decline temporary access. The owner will have 20 days to accept or decline the request before the request expires. If the owner accepts the request, GitHub Support will have access the repository for five days.

Should include a paragraph saying:

Note
Once granted, there is no way for any other admin (or even you) to know in the future when the grant was made. Nor is it possible for you to know when it expires. Similarly, it isn't possible for any admin to know if a request was rejected (or when). You should use some other logging system in order to record this information so that you can keep track for your organization's sake.

Additional information
No response

👋 @jsoref Thanks so much for opening an issue! I'll triage this for the team to take a look :eyes:

👋 Hey @jsoref, I spoke with the team and found out that when Support unlocks a repo, the expected behavior includes the generation of several possible audit log events, including staff.repo_lock and repo.staff_unlock to name a couple. The repo owner can see these in their security log. The same applies to organizations and Enterprise accounts as well, with this last link holding a table of these events. We are working on updating the other two (versioned) articles to include this table, but haven’t gotten there just yet.
Is there a specific case/discussion you can point us to where these events were not recorded?

Fwiw, searching for repo.staff_unlock doesn't work. Searching for action:repo.staff_unlock works.
https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/reviewing-your-security-log doesn't mention this event or any indication of how to know that this would be the event.
Completion for action: doesn't immediately show it.
In fact, the filter system shows up to five items and doesn't indicate that there may be others (the docs should explain that you can't get a complete list of things by using the completion, and instead if you want a list that you need to refer to the docs):

Note that the logged event doesn't indicate who authorized it, just "someone":
GitHub staff temporarily unlocked [{org}/{repo}](https://github.com/{org}/{repo}) with permission from a repository admin.
on {date}

The point isn't that the event isn't recorded. It's that no one would know to look for it in the first place.
And the documentation should make these things clear, as well as precisely how to find these log entries. It isn't sufficient to have to file a new ticket to ask for info, nor is it sufficient to have to file a ticket to docs, or search the docs issues to find your note about repo.staff_unlock.
https://docs.github.com/en?query=repo.staff_unlock

https://cs.github.com/?q=repo%3Agithub%2Fdocs repo.staff_unlock NOT path%3A%2F^translations\%2F%2F&scopeName=All repos&scope=
Shows that it's only documented for enterprises:
https://github.com/github/docs/blob/804f3ecc3d6f641f40f17f4dfdb8371d5885b4ca/content/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise.md#staff-category-actions
(For the 🥜 gallery, I'm not in an enterprise, but we have a log entry that corresponds to this.)

Hey @jsoref I've talked with the team about your most recent feedback on this issue, and we've decided to continue the discussion about these doc updates internally. Thanks so much for sharing your explanations and experience ✨. FWIW, the action: dropdown suggestions for the audit log keys (that are available to search) is something the team is currently improving. Since I have copied the details of this issue to an internal issue, I'll close this now, and thanks again for working to improve our docs! 💖


If result_handler throws an error, PipelineExecutorStatus should notify the query to terminate, and wait for the end of the query.

What problem does this PR solve?
Issue Number: close #7520
Problem Summary:
What is changed and how it works?
Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Documentation

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Changes MySQL compatibility

Release note

None

/run-all-tests

/run-integration-test

/merge

/run-unit-test


systemd-journald fails to restart without regenerating /etc/machine-id after first boot

Hi,
I'm provisioning a START1-S server with Fedora 28.
At first login this is the state of journald:
# ps aux | grep journald
root       292  0.0  0.6  91512 12924 ?        Ss   22:17   0:00 /usr/lib/systemd/systemd-journald
root      1049  0.0  0.0   9144  1052 pts/0    S+   22:26   0:00 grep --color=auto journald
# journalctl
No journal files were found.
-- No entries --
# systemctl status systemd-journald
● systemd-journald.service - Journal Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static; vendor preset: disabled)
   Active: active (running) since Sat 2018-06-23 22:17:46 UTC; 9min ago
     Docs: man:systemd-journald.service(8)
           man:journald.conf(5)
 Main PID: 292 (systemd-journal)
   Status: "Processing requests..."
    Tasks: 1 (limit: 2343)
   Memory: 8.8M
   CGroup: /system.slice/systemd-journald.service
           └─292 /usr/lib/systemd/systemd-journald
# systemctl restart systemd-journald
Job for systemd-journald.service failed because the control process exited with error code.
See "systemctl status systemd-journald.service" and "journalctl -xe" for details.

From now on journald is dead and can't be restarted.
To make it work I need to do this:
# systemd-machine-id-setup
Initializing machine ID from random generator.
# systemctl restart systemd-journald
# systemctl status systemd-journald
● systemd-journald.service - Journal Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static; vendor preset: disabled)
   Active: active (running) since Sat 2018-06-23 22:29:00 UTC; 4s ago
     Docs: man:systemd-journald.service(8)
           man:journald.conf(5)
 Main PID: 1071 (systemd-journal)
   Status: "Processing requests..."

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
# journalctl -n 1
-- Logs begin at Sat 2018-06-23 22:29:00 UTC, end at Sat 2018-06-23 22:29:00 UTC. --
Jun 23 22:29:00 scw-f3c8e0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:kernel_t:s0 msg='unit=systemd-journald comm="systemd" exe="/usr/lib/systemd/systemd" hostname=

At first login, the /etc/machine-id contains a UUID (formatted with the -, like 73618885-dfe7-47c9-959f-26ad21223e4b); after calling systemd-machine-id-setup the machine-id doesn't contain any -
I'm guessing systemd doesn't like the first format for some reason.
Either way, it's a little annoying having no working logs by default.

Same issue here. Thanks for the solution!

Yeah, my guess is the VMs are based on KVM. systemd-machine-id-setup says this in the man page:
2. If run inside a KVM virtual machine and a UUID is configured (via the -uuid option), this UUID is used to initialize the machine ID. The caller must ensure that the UUID passed is sufficiently
       unique and is different for every booted instance of the VM.

Why journald doesn't work after that I have no idea.

AFAIK it's because this is not according to the standard machine ID.
It shouldn't contain any dashes.

The machine ID is a single newline-terminated, hexadecimal, 32-character, lowercase ID.
...
This machine ID adheres to the same format and logic as the D-Bus machine ID.

The machine-id manual tells exactly the same.
If you enter journalctl --new-id128 it prints these IDs in different formats:
~ $ journalctl --new-id128
As string:
ba3834ef03e44fbbbc97a863d9b876ae

As UUID:
ba3834ef-03e4-4fbb-bc97-a863d9b876ae

As man:sd-id128(3) macro:
#define MESSAGE_XYZ SD_ID128_MAKE(ba,38,34,ef,03,e4,4f,bb,bc,97,a8,63,d9,b8,76,ae)

As Python constant:
>>> import uuid
>>> MESSAGE_XYZ = uuid.UUID('ba3834ef03e44fbbbc97a863d9b876ae')

Hmmm...😕 As you can see, only the first one fits the description above. So we can say that this is not a journalctl bug. It could be a systemd-machine-id-setup bug though. Or is it just this particular image, or the Scaleway setup scripts?

Okay so this UUID is generated here in the Dockerfile with scw-gen-machine-id.
Which can be found here if I'm correct.
And on line 15:
        uuidgen >/etc/machine-id
Which generates an UUID with dashes:
~ $ uuidgen
6dc8f770-54a2-4835-9411-961de2b15384

According to the machine-id manual this

is not according to the standard machine ID format
overwrites KVM UUIDs - even not setting this file up at all would be better (when it just auto-generates some UUID)
is not good practice since dbus-uuidgen should be used.

What do you think? Should we issue a bug report there at scaleway image tools?

Nice debugging. I think the script is more likely this one than the one from openrc.
However it's essentially the same so your analysis looks correct.

I quickly fixed this in https://github.com/scaleway/image-fedora/commit/931c65e37a4460a335b4f845f666c78f0640a2ab, as this is more correct in any case, but i'm currently evaluating the possibility to use systemd-machine-id-setup instead

@nlm thanks for the fix! Yes, I think in this case, systemd-machine-id-setup is safe, because it tries to read machine UUIDS using id128-read which, using sd_id128_from_string always skips dashes!  😉


Deriving AsChangeset on a structure is now unsupported

It will now panic with a meaningful message instead of throwing a syntax
error.

Meaningful advice "If you want to change the primary key of a row, you should do so with .set(table::id.eq(new_id)). AsChangeset never changes the primary key of a row."

Yeah, I can add that 👍

Can we add a test as wellL?


custom named formatter syntax

I have a custom named formatter called strbool.  Which prints Yes if value is true and prints No if value is false.
In the previous version, this works fine.
Smart.Format("{value:strbool}", new { value = true });
Now it needs a parenthesis.
Smart.Format("{value:strbool()}", new { value = true });
What it means adding a parenthesis here?  Again previous syntax felt more natural.

Currently, the Parser is responsible for determining the "named formatter".  So, this doesn't allow for flexibility.  It needs to parse {0:yyyy} the same way as it parses {0:strbool}.
So, if there are 2 colons, or parenthesis, then it's a named formatter.  Otherwise, there is no named formatter.

To improve this, do you have any suggestions?

Perhaps the named formatter can be handled during "format time", where it searches for the name, and if not found, it treats it as a format string.  This would alleviate the issue in #47 as well.
If the named formatter used a different syntax instead of the colon (as suggested in #47), then there would be no ambiguity.

I like the option 1.

Should be solved with #65

Will be closed in upcoming version 1.7.x shortly:
When the parser comes across a formatter name, this does not exist in the registered extensions, it will treat this part as a format, which will be processed by DefaultFormatter.

Updated version committed, where test with the issues mentioned have passed: https://github.com/scottrippey/SmartFormat.NET/commit/46bbae26b6c34582887b60fc0488cd134514fde7


Use component_name instead of module_name in templates

So when we create a button component, by default it contains button instead of button_component (makes more sense imho)

Pull Request Test Coverage Report for Build 408

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 379:
0.0%

Covered Lines:
120

Relevant Lines:
120

💛  - Coveralls


The seccomp policy created by the advisor is not enough to start the pod when using allowPrivEsc=true

Description
I tried using the seccomp policy advisor to create the policy for a pod in an Azure VM running Ubuntu Hirsute, using Minikube with the driver=none option.
I managed to get the seccomp policy advisor to run and generate a policy both in the "Status" mode and in the "ExternalResource" mode, using the security profiles operator.
I then edited the workload and added the seccomp policy served by the operator and restarted the pod. Which caused the pod to fail with: Error: failed to start container "hello-python": Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: close exec fds: ensure /proc/self/fd is on procfs: operation not permitted: unknown
Changing the default policy to LOG instead of ERRNO, I see a bunch of SECCOMP errors in journalctl, for different syscalls (snippet):
Sep 11 09:58:02 hirsute-demo audit[566404]: SECCOMP auid=4294967295 uid=0 gid=0 ses=4294967295 subj=unconfined pid=566404 comm="runc:[2:INIT]" exe="/" sig=0 arch=c000003e syscall=125 compat=0 ip=0x4c1b3b code=0x7ffc0000
Sep 11 09:58:02 hirsute-demo audit[566404]: SECCOMP auid=4294967295 uid=0 gid=0 ses=4294967295 subj=unconfined pid=566404 comm="runc:[2:INIT]" exe="/" sig=0 arch=c000003e syscall=126 compat=0 ip=0x4c1b3b code=0x7ffc0000
Sep 11 09:58:02 hirsute-demo audit[566404]: SECCOMP auid=4294967295 uid=0 gid=0 ses=4294967295 subj=unconfined pid=566404 comm="runc:[2:INIT]" exe="/" sig=0 arch=c000003e syscall=262 compat=0 ip=0x4c1baa code=0x7ffc0000

The syscalls logged and their meanings on 64bit:

80 chdir
93 fchown
125 capget
126 capset
262 newfstatat

I tried deleting and starting the pod a few times and capturing that with the trace, but the policies generated were always the same. In other words, it consistently generates a policy that's missing some critical syscalls needed to start the pod.
I suspect this is related to the fact that I'm using the driver=none option which means that this is running directly on the VM without another layer in between. However, I can't know for sure as I don't have any instance where this is working correctly.
Impact
The policies generated by the advisor are not enough to get the pod to run successfully.
Environment and steps to reproduce

Set-up:

Azure VM running Ubuntu Hirsute
Latest Minikube version, using --driver=none
Latest IG, compiled and deployed from source
The following files:

seccomp-operator.sh (installs the operator in the cluster):
#!/bin/bash
set -x
kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.4.1/cert-manager.yaml
kubectl --namespace cert-manager wait --for condition=ready pod -l app.kubernetes.io/instance=cert-manager
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/security-profiles-operator/master/deploy/operator.yaml

uwsgi.yaml (demo workload):
---
apiVersion: v1
kind: Namespace
metadata:
  name: seccomp-demo
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-script
  namespace: seccomp-demo
data:
  main.py: |
    from flask import Flask
    app = Flask(__name__)
    @app.route("/")
    def hello():
        return "Hello World!\n"
    if __name__ == "__main__":
        app.run(host="<IP_ADDRESS>", debug=True, port=80)
  uwsgi.ini: |
    [uwsgi]
    module=main
    callable=app
---
apiVersion: v1
kind: Service
metadata:
  name: hello-python-service
  namespace: seccomp-demo
spec:
  selector:
    app: hello-python
  ports:
  - protocol: "TCP"
    port: 6000
    targetPort: 80
  type: LoadBalancer
---
apiVersion: v1
kind: Pod
metadata:
  name: hello-python
  namespace: seccomp-demo
  labels:
    app: hello-python
spec:
  securityContext:
    #seccompProfile:
      #type: Localhost
      #localhostProfile: operator/gadget/myseccomp.json
  containers:
  - name: hello-python
    image: tiangolo/uwsgi-nginx-flask:latest
    imagePullPolicy: Always
    ports:
    - containerPort: 80
    volumeMounts:
    - name: app-script
      mountPath: /app/
  volumes:
  - name: app-script
    configMap:
      name: app-script
      items:
        - key: main.py
          path: main.py
        - key: uwsgi.ini
          path: uwsgi.ini

trace-seccomp.yaml (tracing CRD):
apiVersion: gadget.kinvolk.io/v1alpha1
kind: Trace
metadata:
  name: seccomp
  namespace: gadget
spec:
  node: hirsute-demo
  gadget: seccomp
  filter:
    namespace: seccomp-demo
    podname: hello-python
  runMode: Manual
  outputMode: ExternalResource
  output: gadget/myseccomp

Task: Generate the policies for the workload and store them with the operator
Actions:
a. Apply the CRD: kubectl apply -f trace-seccomp.yaml
b. Annotate it to start: kubectl annotate -n gadget trace/seccomp gadget.kinvolk.io/operation=start
c. Apply the workload: kubectl apply -f uwsgi.yaml
d. Get the service IP/Port and Curl it: curl $(minikube service hello-python-service -n seccomp-demo --url=true)
e. Generate the policies: kubectl annotate -n gadget trace/seccomp gadget.kinvolk.io/operation=generate
f. Verify that the profile was created: kubectl get -n gadget seccompprofile
g. Modify uwsgi.yaml, remove the # in the lines commented, then reload the workload by deleting and re-applying the file.
Error:  The pod fails to start with:

  Warning  Failed     7s (x3 over 23s)  kubelet            Error: failed to start container "hello-python": Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: close exec fds: ensure /proc/self/fd is on procfs: operation not permitted: unknown

Expected behavior
The pod should start successfully with the generated policies
Additional information
I tried this several times and the policies generated were consistent.  When I modified the policy to make it log instead of block, the pod came up successfully. I traced that one and the policy generated was still the same.

Alban found that the syscalls listed seem to be used by the function finalizeNamespace:
https://github.com/opencontainers/runc/blob/9a0419b92027040a6ea5f0b4653376f1766c3f04/libcontainer/init_linux.go#L136
And also that if the container runs as root, without a security context explicitly defined, it will default to allowPrivilegeEscalation=true according to https://github.com/kubernetes/community/pull/639/files#diff-57009be473d2288a4e0dab6fdda5b994d8e4f8468138da1b7812ae35c2290776R100
The doc mentions interactions between seccomp and allowPrivilegeEscalation.
So, I modified my workload and added a security context for the container, with the allowPrivilegeEscalation set first to true and then to false.  With true, it failed with the same error. With false, it works correctly.

Preparing the seccomp talk, I found the following statement on the man page of the seccomp() syscall:

In order to use the SECCOMP_SET_MODE_FILTER operation, either the calling thread must have the CAP_SYS_ADMIN capability in its user namespace, or the thread must already have the no_new_privs bit set.

Now, given that allowPrivilegeEscalation controls no_new_privs (Pod documentation):

securityContext.allowPrivilegeEscalation (boolean)
AllowPrivilegeEscalation controls whether a process can gain more privileges than its parent process. This bool directly controls if the no_new_privs flag will be set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged 2) has CAP_SYS_ADMIN

I think it explains why we need to set allowPrivilegeEscalation to false when we want to apply a seccomp profile to a given pod.
It would also explain why it is not possible to apply a seccomp profile to a privileged container (seccomp tutorial):

It is not possible to apply a seccomp profile to a container running with privileged: true set in the container's securityContext. Privileged containers always run as Unconfined.

@marga-kinvolk @alban What do you think?
Out of curiosity, I tried to remove the allowPrivilegeEscalation: false and added the SYS_ADMIN capability to the container but the pod failed to start with the same error Marga reported in this issue:
Error: failed to start container "hello-python": Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: close exec fds: ensure /proc/self/fd is on procfs: operation not permitted: unknown

What did I miss?

This can be reproduced also using local gadget. The missing syscalls comes for example from https://github.com/opencontainers/runc/blob/master/libcontainer/utils/utils_unix.go#L17.
You can add the syscalls below to the seccomp policy
        "fstatfs",
        "getdents64"

To get around this error and next one, which is:
docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: close exec fds: readdirent /proc/self/fd: operation not permitted: unknown.

Unfortunately, next error I get is:
docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: operation not permitted: unknown.

Which is harder to trace :disappointed:

Adding:
        "capget",
        "capset",
        "prctl"

Gets you further, I'll continue investigating, though the issue is more generic, as I guess inspektor-gadget should be able to figure it out automatically somehow and it's not.

So, in my case, with simple statically compiled Golang hello world running, I had to add the capabilities below in addition to what strace ./main 2>&1 | grep '(' | cut -d'(' -f1 | sort | uniq | sed 's/^/        "/g; s/$/",/g' generated:
        "fstatfs",
        "getdents64",

        "capget",
        "capset",
        "prctl",

        "fstat",
        "newfstatat",
        "setgroups",
        "setgid",
        "setuid",

        "chdir",

        "getppid"

Pretty much following the code from https://github.com/opencontainers/runc/blob/0c0ec3f53f92c01866449916d554b62962cda6ab/libcontainer/setns_init_linux.go#L32.
I wish more errors could be annotated there so it is easier to trace those errors...

Hi @invidian, I analysed this with @alban and we realised there is a bug in the way we collect the syscalls performed by runc. We opened a PR to fix it, it would be great to have your feedback.


编译完后导入eclipse中有几个类找不到

import org.apache.spark.sql.execution.command.Partitioner;
import org.carbondata.spark.rdd.Compactor;
以上这2个类都找不到 不知是否是哪个jar没有引进？

Both of them are Carbon own classes, not depend on other jars, could you please try to use maven to reimport the project?
Further more, the github of  carbondata has been migrated to apache: https://github.com/apache/incubator-carbondata ,  you can use jira to raise any issue: https://issues.apache.org/jira/browse/CARBONDATA . Describe in English would be better because more people can help you.
Thank you!

I download the code from https://github.com/apache/incubator-carbondata ,and compile in mvn command,after then import it to eclipse,Then the error is show.

@shijiyu
1.First, please send mail to<EMAIL_ADDRESS>for subscribing mailing list
2.Then send mail to<EMAIL_ADDRESS> to get helps for solving your errors.

3Q, I try do it.


Documentation. How to setup datasource for postgres?

Could you please add a section in the Wiki that explains how to setup datasources / configurations for different databases (postgres, mysql, ...).
I'm close to giving up advocating for requery, since it lacks that crucial examples.
I spent a full weekend trying to figure out how to get basic things done.
Therefore, I'd be glad if you could help me with this.
Thanks
/Seb

Hi this test class includes instantiating the DataSource for all major databases
https://github.com/requery/requery/blob/master/requery-test/src/test/java/io/requery/test/DatabaseType.java#L44


missing dependencies

Some users are reporting issues where dependencies that are included in a root package.json are not available at runtime.
Reference: onmodulus/modulus-cli#141

I believe this may be resolved with onmodulus/docker-build-meteor#30

working this code thru QA now, hoping to have it available before the end of day

new build image and CLI is public, please update and try deploying again if you were having issues..
npm i modulus@latest -g

See my comment in https://github.com/onmodulus/docker-build-meteor/issues/28#issuecomment-240838743

The new updates to the build image have resolved this problem. @talfco if this is still an issue please feel free to comment and reopen.


Changed the order of the face vertices to fix inside/outside rendering

It seems like we were defining the face vertices in the wrong order. Inverting this helped fix rendering issues with some viewers that do not render the insides of polygons.

Pull request is not relevant anymore. Has been changed on develop.


androidx.work.Data in toByteArray java.lang.IllegalStateException

java.lang.IllegalStateException: Data cannot occupy more than 10240KB when serialized
at androidx.work.Data.toByteArray(Data.java:325)
at androidx.work.impl.model.WorkSpecDao_Impl$1.bind(WorkSpecDao_Impl.java:79)
.bind(WorkSpecDao_Impl.java:52)
at android.arch.persistence.room.EntityInsertionAdapter.insert(EntityInsertionAdapter.java:63)
at androidx.work.impl.model.WorkSpecDao_Impl.insertWorkSpec(WorkSpecDao_Impl.java:199)
at androidx.work.impl.utils.EnqueueRunnable.enqueueWorkWithPrerequisites(EnqueueRunnable.java:266)
.enqueueContinuation(EnqueueRunnable.java:137)
.processContinuation(EnqueueRunnable.java:130)
at androidx.work.impl.utils.EnqueueRunnable.addToDatabase(EnqueueRunnable.java:95)
at androidx.work.impl.utils.EnqueueRunnable.run(EnqueueRunnable.java:79)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:762)

+1
It seems the real limit for Output/Input Data is ~12KB despite the message which mentions 10240KB.
At least I observed this behaviour in 1.0.0-alpha04

Interesting to note here is that, we dont set output data when enqueuing a request and yet, the exception indicates that the output size exceeded its limit during workrequest enqueue. How is this possible? We are only using non-chained, independent OneTimeRequests to enqueue.

Thanks for reporting this.
I'm closing this issue because this forum is for issues with the codelab.
If you think that this is a problem of the WorkManager library, please open a bug on the WorkManager public issue tracker: https://issuetracker.google.com/issues/new?component=409906&template=1094197
Please reopen if you still think this is an issue with the codelab.


Please make possible install via npm

Most JS tools, including heroku toolbelt for example, can be installed cross-platform with
npm install -g hyper
and then it just works. Please enable install via npm too, to make it simple getting started.
Thanks!

I'm sorry but I don't see how this would be possible. Hyper is a .app with a UI, Heroku Toolbelt is a CLI. I don't think there's ever been an app like Hyper installed via npm (correct me if I'm wrong).

Sorry again, but I was completely wrong! I was informed that this was possible so I'm re-opening so we can consider it!
Took me a while to understand how it would be possible. Didn't make sense to me at first. Let's see what the community thinks 😄
cc @matheuss @rauchg @leo @chabou

I believe homebrew or similar is a better place for applications -- I don't see atom in npm.

You could use Snap. https://snapcraft.io Can be used on most distros, not just Ubuntu

+1 for homebrew. npm should not be used for these kind of applications.

@afturner homebrew is already avaible trough the cask addon as you can see in the README.md

@LucaT1 I'm aware, just reiterating support

I think we've gotten what would be the majority of opinions on this matter.
Thanks for the issue and the responses, everyone. We'll make a bigger effort to be on the popular package manager made for apps like Hyper, per platform. ❤


how to set ENV in doc

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[ ] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew tests with your changes locally?
[ ] Have you successfully run brew man locally and committed any changes?

add how to set environment variables anywhere to https://docs.brew.sh/Formula-Cookbook because of https://github.com/Homebrew/brew/issues/8648

I think it would be good to document this but I don't think this addition as-is provides much clarify. Could you try a dedicated section or similar?

Sorry, this still isn't what I'm looking for; you've edited the example that brew create outputs. Consider adding some prose or a code example to https://github.com/Homebrew/brew/blob/441044932c4d475f3ca0a9b646396ee31e88dc0d/docs/Formula-Cookbook.md#using-environment-variables instead.

@MikeMcQuaid

Consider adding some prose or a code example to https://github.com/Homebrew/brew/blob/441044932c4d475f3ca0a9b646396ee31e88dc0d/docs/Formula-Cookbook.md#using-environment-variables instead.

Thank you for the advice, that’s very helpful.

Thanks again @hyuraku!


ios 10 crash - after authorizing camera - LLSimpleCamera.h xcode 8.1

it might be better to extend dependency on this https://github.com/omergul123/LLSimpleCamera/blob/master/LLSimpleCamera.podspec

I can confirm this is blowing up with sample project too.
I tried the solutions here - doesn't seem to help.
http://stackoverflow.com/questions/38267608/requestaccessformediatype-crashing-in-ios-10

Hi, thanks for the issue, can you give me more details? which IOS 10 is it? 10.1, 10.2?
And was it on which device? I'm trying to reproduce, thanks

this code fixes it.
https://github.com/mcmatan/JVTImageFilePicker/commit/4e558cbe6561f5210ffb549dfcc65bb240510aae
just need to bump pod version.

Perfect (:


Java 5.1: Arithmetic Operators

Description 📜
Add audio, documentation, and video regarding the Arithmetic Operators.

Domain of Contribution 📊

[x] Java

Location of File to be added
The files should be added inside the Arithmetic Operators  folder which is inside the Operator  folder present in the   Java  main folder.  The documentation file can be in the .md/.py/.ipynb format. Audio should be in .mp3 format and to be submitted through a Google drive link. Video can be in any format and should be submitted through a Google Drive link.
Note:

You are required to comment with \assign CONTENT_TYPE, so that other content types can be created at the same time.
Failing to comment in the above manner will lead to the removal of assignment from the issue even if the bot assigns.
You are required to do a PR within 7 days otherwise you will be unassigned and others will be assigned.
Issues will be assigned on a first come first serve basis.

/assign document

\assign document

/assign document

/assign document

/assign documentation

\assign documentation

\assign documentation

ACK: Documentation merged. Audio and Video are available to take.

\assign audio

@Shishiranjan go with the audio


[ENHANCEMENT] Improve the UX of non-migratable VMs in node maintenance mode

Is your enhancement related to a problem? Please describe.

When a node is put into maintenance, Harvester will start to live-migrate VMs on it. In some cases, VMs can't migrate to other node:

VMs have PCI passthrough devices.
VMs have NodeSelector or zone constraints, but can't find another node to schedule.

And these VMs will stay migrating until timeout happens.
Describe the solution you'd like

Improving the UX. Some ideas:

Display a non-migratable VM list and suggest those VMs will be shut down.
Once the user confirms, we shut down the VMs and perform maintenance.

Describe alternatives you've considered

Additional context

Is this just an UI issue? Currently only 2 life migration are done in parallel. And if 2 migrations are in progress (and never finish), the rest of the VMs, even if they can be migrated, will not be moved to other hypervisor nodes.

Is this just an UI issue? Currently only 2 life migration are done in parallel. And if 2 migrations are in progress (and never finish), the rest of the VMs, even if they can be migrated, will not be moved to other hypervisor nodes.

No. the require-ui label is just for indicating there is UI work involved. So one proposal in the issue is to warn the user a VM can't live-migrate if the user tries to migrate it or put a node into maintenance.

@bk201 @ibrokethecloud is there a chance that force option will shoutdown all non-migratable VMs ?

If so, we could add a tooltip to the force checkbox or a message, to inform the users that they can use force checkbox to shutdown the VMs If first try fails.
else we need a new checkbox, visible on errors, to shutdown the VMs.

What do you think ?
cc @a110605

@bk201 @ibrokethecloud is there a chance that force option will shoutdown all non-migratable VMs ?

If so, we could add a tooltip to the force checkbox or a message, to inform the users that they can use force checkbox to shutdown the VMs If first try fails.
else we need a new checkbox, visible on errors, to shutdown the VMs.

What do you think ?
cc @a110605

I think we can always display force shutdown banner message in the modal rather than get the unhealtyVMs list.
It provides clearly inform to users.

the UI looks good to me. The force option will shutdown all VM's which are not migratable irrespective of the reason for their non-migaration.

Moved back to review as https://github.com/harvester/harvester/pull/6397 not merged yet.
(tested on v1.4-1305f11-head)

@lanfon72 According to @ibrokethecloud, #6397 is a further improvement and it can be tracked in https://github.com/harvester/harvester/issues/6509

Verified this enhancement has been applied.

Test Information

Environment: bare metal DL360G9 3 nodes
Harvester Version: v1.4.0-rc3
ui-source Option: Auto

Verify Steps

Install Harvester with at least 2 nodes having PCI devices
Create an image for VM creation
Enable Addon pci-devices-controller
Create VM and start it

vm1 with PCI device attached
vm2 with Node Scheduling rules (match only one specific node, using spec.spec.affinity.nodeAffinity)
vm3 with container volume
vm4 with CD-ROM volume

Enable maintenance mode without force on the node hosting VMs
Error message displayed and VMs should NOT be shut down automatically
The node should NOT enter maintenance mode
Enable maintenance mode with force on the node hosting VMs
VMs should be shut down automatically
The node should enter maintenance mode


Patch version 2.0.1 - update 'v2.0' tag

I'm not sure what was changed in v2.0.1 (since nothing is mentioned at https://nestedtext.org/en/latest/releases.html or https://nestedtext.org/en/latest/changelog.html) but the v2.0 tag seems to still point at the old 2.0.0 commit, meaning https://nestedtext.org/en/v2.0/ still goes to v2.0.0.
Could this be updated (and perhaps something in the CI be tweaked to ensure this isn't missed in the future)?

Version 2.0.1 only involves some refactoring of the code, documentation, and tests.  The changes are small and do not affect users, and so are not mentioned in the documentation.  Instead, they are described in the commit message.
I do not change the tags to point to the latest version.  Thus, the v2.0 tag will always point to the same version.  Instead, I only tag releases, and releases always reset the patch level to 0.  Besides updating the minor and perhaps major level upon release, I also publish the code to PyPI and ReadTheDocs.   In this way, a release (a tagged version) is always consistent between GigHub, PyPI, and ReadTheDocs. Patch revisions like this one are treated as trial versions that are simply leading to the next release and are only expected to be used by developers that have cloned the git repository.  This contrasts with releases, that are expected to be adopted by users.

Sorry, I forgot that the use of version numbers is somewhat non-standard, but this sounds like it makes sense for not updating the tag. I just got confused when 'latest' was showing me something different to '2.0' which I thought was latest!


create an optional first episode on Julia syntax

could be based on what's covered in the quick reference

done in #41!


Add Neko as example

Hi Guys!
I've been working on integrating Neko into Kubernetes.
Since Neko uses WebRTC to stream a desktop inside the container to a browser, I figured I should use STUNner to set up the proper connection.
This example shows a basic version of my solution.
Feel free to try it, and please add comments to the README.

Hi!
Thanks for the great demo you made. One quick observation about deploying into a GKE cluster. The native GKE Ingress does not support ClusterIP typed services; however, Nginx's ingress does. To use the Nginx provided Ingress instead of the native one you must annotate the Ingress resource with the following:
kubernetes.io/ingress.class: nginx
This signals that other cloud providers could use different technics to implement Ingress. It might be worth looking into.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 68.72%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
725

Relevant Lines:
1055

💛  - Coveralls

This is fantastic, thanks a lot!


⚠ Jenkins Plugins Artifactory has degraded performance

In f598828, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1208 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 60cda9f after 2 hours, 56 minutes.


docs: add documentation for writing plugins using Maven JAR

The documentation currently references my Maven coordinates (io.github.ericluoliu). Once the official Maven coordinate is released, I will change this.
Related PR: https://github.com/apache/apisix-java-plugin-runner/pull/155

From the user's perspective, I can now run the java-plugin-runner and package my filters in a JAR without having to copy the java-plugin-runner repo. However, apisix cannot find the filter when I run both processes, still working on resolving this...

LGTM

We can wait to merge this PR and I will merge it when I release this project to maven center.

hi @ericluoliu ,
        <dependency>
            <groupId>org.apache.apisix</groupId>
            <artifactId>apisix-runner-starter</artifactId>
            <version>0.3.0-SNAPSHOT</version>
        </dependency>

has been pushed, so we can replace all io.github.ericluoliu in this document with org.apache.apisix.


Proper unit and newtype_variant support

As of now, the library does not properly serialize or deserialize unit structs, unit variants, new type structs or new type variants:
fn serialize_unit_struct(
    self,
    _: &'static str,
) -> Result<Self::Ok, Self::Error> {
    Ok(())
}

fn serialize_unit_variant(
    self,
    _: &'static str,
    _: u32,
    _: &'static str,
) -> Result<Self::Ok, Self::Error> {
    Ok(())
}

fn serialize_newtype_struct<T: ?Sized>(
    self,
    _: &'static str,
    _: &T,
) -> Result<Self::Ok, Self::Error>
where
    T: serde::Serialize,
{
    Ok(())
}

fn serialize_newtype_variant<T: ?Sized>(
    self,
    _: &'static str,
    _: u32,
    _: &'static str,
    _: &T,
) -> Result<Self::Ok, Self::Error>
where
    T: serde::Serialize,
{
    Ok(())
}

This is considered a bug and should be fixed accordingly.

#4 Fixes both serialize_unit_struct and serialize_newtype_struct but the other two will be fixed when we have enum support, so I'm keeping this issue open.


remove global antlr plugin as this tries to install antlr 2.7 if no a…

…ntlr dependency is defined in subprojects

Just for doc: Antlr is a gradle core plugin. So no need to specify it explicitly


Public Key Failure for apt.postgresql.org on 9.1 Image

In postgres:9.1 image:
apt-get -qq update && apt-get -qq install build-essential postgresql-server-dev-$PG_MAJOR
There is no public key available for the following key IDs:
AA8E81B4331F7F50
GPG error: http://apt.postgresql.org jessie-pgdg InRelease: The following signatures were invalid: KEYEXPIRED<PHONE_NUMBER>
WARNING: The following packages cannot be authenticated!
  libpq5 libpq-dev postgresql-server-dev-9.1
here are problems and -y was used without --force-yes

Can the key be updated in older version images?
As seen in this workflow

Also true of the 8.4 images (as seen in this workflow.

Postgres 9.1 was deprecated October 2016 , which was also when we deprecated that version of the image. And Debian Jessie loses LTS in a month, so without something of extreme security importance there isn't a sufficiently good reason to try and resurrect/refresh that version
https://github.com/docker-library/faq#what-do-you-mean-by-supported
https://www.debian.org/releases/jessie/

Jessie also benefits from Long Term Support (LTS) until the end of June 2020.

Still useful for testing extensions that continue to support older versions, though. Note that this isn't an issue for 9.0, just 8.4 and 9.1 (at the moment anyway).

Unfortunately there isn't anything we can do for these old unsupported images.  You can just tell apt to ignore gpg signatures (https://askubuntu.com/a/74389). Alternatively, you can see if upstream postgres would push an update to the key, but that seems unlikely since they are no longer supported by them (and you'd be responsible for getting the updated key into your own image).

Thanks.

Hi,
I've recently published updated PostgreSQL packages for all older major versions down to 8.4, so you can install these on any modern distribution release like buster.
No need to stick with wheezy (8.4) or jessie (9.1). Perhaps the Docker images can just switch to that.
Regarding the actual issue, the expired key has been updated in pgdg-keyring I believe. Is that image perhaps using an outdated version of that package?
Christoph

Thanks for commenting @df7cb. Yeah the images in question were dropped a while back, so they definitely have old keys in them.

Should those docker images be deleted, then?

We don't delete old images from the Docker Hub; they are left for historical purposes.  The Hub readme always lists the currently supported set (i.e. tags that get updates or rebuilt on new base images to incorporate security updates).

Yeah, it's just a shame that it means that there are outdated images available and no one can tell at a glance that they won't work. Thinking I'll update my GitHub Workflow to use a plain old Linux docker container and apt-get (or yum install) the versions of Postgres I need.


Revert "alert dialog without template tag"

Reverts ruby-ui/ruby_ui#178
@SethHorsley , this PR broke the AlertDialog here. May I revert it?

good yes this needed to be reverted


chore: rename the new client config file name

Problem
Current amplify-outputs.json doesn't work with android as the character - is not allowed in the resource names
Changes

This PR changes the name of the file to amplify_outputs for all platforms.
Add this file to the gitignore as well.

Checklist

[ ] If this PR includes a functional change to the runtime behavior of the code, I have added or updated automated test coverage for this change.
[ ] If this PR requires a change to the Project Architecture README, I have included that update in this PR.
[ ] If this PR requires a docs update, I have linked to that docs PR above.
[ ] If this PR modifies E2E tests, makes changes to resource provisioning, or makes SDK calls, I have run the PR checks with the run-e2e label set.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Just wondering, when would we add the new client config to our docs site?

As soon as the libraries are ready and we make the new config default. This new config is still behind a flag


Current version crashes with unrecognized selector on iOS

Building current iOS version via get_webrtc & build_webrtc succeeds, but I get uncaught exception when running the application:

state changed RTCSignalingState(rawValue: 0): RTCSignalingStable
ice connection changed RTCICEConnectionState(rawValue: 1)
2016-04-11 16:18:22.480 DemoApp[4089:981708] -[RTCAudioSession isConfiguredForWebRTC]: unrecognized selector sent to instance 0x16848090
2016-04-11 16:18:22.481 DemoApp[4089:981708] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[RTCAudioSession isConfiguredForWebRTC]: unrecognized selector sent to instance 0x16848090'
*** First throw call stack:
(0x24b7010b 0x24316e17 0x24b75925 0x24b73559 0x24aa3c08 0x19c885 0x1954d7 0x1952d1 0x39dff5 0x39df93 0x2ec5eb 0x2ed6e3 0x326d5f 0x32804f 0x32ee3b 0x2c8db1 0x2ba695 0x2c8bb1 0x2c8a9f 0x248a985b 0x248a97cf 0x248a7724)
libc++abi.dylib: terminating with uncaught exception of type NSException

This sounds like a WebRTC issue and not a build scripts issue. See if this helps

@deanrock did you get any further with this ?

@ianmorty no, I gave up on trying to fix it.

Check if you have the Microphone access permission before setting up an RTC call on iOS

I have a same issue:
-[RTCAudioTrack setEnabled:forSegmentAtIndex:]: unrecognized selector sent to instance 0x15de3a60
2017-08-17 19:58:15.477321+0530 AppRTC[306:41898] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[RTCAudioTrack setEnabled:forSegmentAtIndex:]: unrecognized selector sent to instance 0x15de3a60'
*** First throw call stack:
(0x1dbc7b3d 0x1ce4f067 0x1dbccfd1 0x1dbcb0c3 0x1daf3dc8 0x33d41 0x2bdb5 0x22e27785 0x22e27719 0x22e11d49 0x22e27055 0x2337933b 0x23375c53 0x1db83803 0x1db81a55 0x1db82017 0x1dad51af 0x1dad4fd1 0x1f27fb41 0x22e56e13 0x2ea6f 0x1d2c24eb)
libc++abi.dylib: terminating with uncaught exception of type NSException
Any help?


Add support for method_attribute()

As we know, prost_build::Config supports field_attribute() and type_attribute(). Since tower-grpc provides implementation of the trait prost_build::ServiceGenerator, it'd be really good to have method_attribute() on the generator, so that the generated methods can do things like initiating distributed tracing (zipkin):
#[zipkin_span]
pub fn client_api(&mut self, foo) -> bar {
}

And then the users of tower-grpc can implement their own zipkin_span or whatever they want for their cross-cutting concerns.
If the idea is good, then I can implement this feature and create the PR. Please review and let me know your thoughts.

I don't quite follow. What would the user code look like?

I don't quite follow. What would the user code look like?

By user code if you mean how would the generated method would eventually look like?
Let's consider this proto definition (taken from the examples):
// The greeting service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

and from it, the client's method generated by tower-grpc would look something like this:
[zipkin_span]      // assume we add support for method_attribute
[arguments(info)]  // and this
fn say_hello(&mut self, req: Request<HelloRequest>) -> Response<HelloReply> {

     //body
}

which, depending on the implementation of zipkin_span and arguments, may eventually be converted into
fn say_hello(&mut self, req: Request<HelloRequest>) -> Response<HelloReply> {
     start_zipkin_span_for(req, etc);         // added this my macro!
     info("say_hello() called with: ", req);  // and this too

     //body
}

Does that make sense?
Also, the support for method_attribute() can be added in the similar way as field_attribute() and type_attribute() exist in prost_build.

And what's the proposed API here? What would a user write in their build.rs? (This seems fine so far!)

And what's the proposed API here? What would a user write in their build.rs? (This seems fine so far!)

Here is what I think:

tower_grpc_build::Config

It will contain a new field: method_attributes: HashMap<Path, Attribute>; pretty much like prost_build::Config does. The difference would be that Path could be an enum instead of String, to make it more expressive.
and a new method:  pub fn method_attribute(&mut self, path: Path, attribute: Attribute) -> &mut Self

tower_grpc_build::client::ServiceGenerator

It would use the method_attributes to generate the attributes for methods. Any conflict or redefinition would result in error (it'd be easier to detect the such error at this stage).

And the same can be done for tower_grpc_build::server:: ServiceGenerator as well.
As for how would users build.rs may look like, here is one example,
  let mut tower_config = tower_grpc_build::Config::from_prost(prost_config);
  tower_config.enable_client(true);

  tower_config.method_attribute(Path::MethodName("SayHello"), Attribute::new("zipkin_span"));
  tower_config.method_attribute(Path::All, Attribute::new("arguments(info)"));
  tower_config.method_attribute(Path::MethodName("SayBye"), Attribute::new("latency"));

  //use tower_config as usual.

Path can be made more expressive, like applying certain attributes to certain Service only, and not to others.  It's more like selector.

Would love to hear from @carllerche and/or @per-gron as well.

I think the general idea is good. I have not considered the details yet.
One question worth exploring is what functionality can be added via this strategy vs. modifying the tower Service that the client dispatches into. Obviously, using attributes on methods allows avoiding a conditional on each request to check the gRPC method, but is that useful in practice? I would think so... what are some specific examples of method specific transformations?

@carllerche

One question worth exploring is what functionality can be added via this strategy vs. modifying the tower Service that the client dispatches into.

I think modifying the tower service wouldn't be flexible enough, as it doesn't probably allow plugging arbitrary behavior to the generated code. Also, think of cross-cutting concerns using the attribute-approach such distributing tracing, regular loggings, measuring various kinds of latency, call-counts, success-counts, failure-counts, other metrics generations, etc.

Obviously, using attributes on methods allows avoiding a conditional on each request to check the gRPC method, but is that useful in practice? I would think so... what are some specific examples of method specific transformations?

I've given few examples in the posts directed at @seanmonstar. Please have a look at them.
I'd also like to add that adding this feature doesn't harm tower-grpc-build in any way, as it'd not generate any attribute unless the users ask it to generate by specifying what to generate usingmethod_attribute().

@snawaz i saw the examples, I just wasn't sure how common it would be to apply those annotations to only specific methods. Why not track latency and use zipkin for all methods?
Anyway, I'm generally fine w/ the proposed strategy.

@carllerche

@snawaz i saw the examples, I just wasn't sure how common it would be to apply those annotations to only specific methods. Why not track latency and use zipkin for all methods?
Anyway, I'm generally fine w/ the proposed strategy.

I understand that most annotations would probably apply to all methods. However, since annotations allow arbitrary code to be plugged-in and it is not only about things which we can imagine like latency or zipkin. Maybe, users wouldn't want to use logging annotation (i.e arguments(info)) for methods which does authentication for security reasons? Or maybe, they want it differently logged?
I feel I shouldn't prevent users from using it for specific methods just because I cannot imagine such a scenario — especially when it's kinda opt-in feature. And at the same time, I don't want to make the implementation too complex, so I'll use the following selectors:
enum Path {
       MethodName(&'static str, &'static str),  // specific method of a specific service
       ServiceName(&'static str),               // all methods of a specific service
       All,                                     // all methods of al services
}

to keep things relatively simple.
If you like the idea, please assign this to me (I don't have the permission). I'll plan and start working on it.

I think this seems like a cool idea. One question I have is if it isn't a bit too low level? This proposal seems to add two distinct features:

The ability to add middleware-like things to specific methods.
The ability to add Rust macros that can modify the actual implementation of methods.

My thoughts:

It seems like (1) is a good thing to have for sure.
I'm not so sure about the value of the attribute macro aspect of it. I agree that it will be able to change the code arbitrarily but what extra things will be possible to do in practice? Do you have an example of something that can not be implemented as tower middleware but that can be done with an attribute macro?
With this API tower-grpc would end up with two separate kinds of middleware-like things: Tower middleware and attribute macros. Instead of doing it like this, would it be possible to add a build.rs level API that applies Tower middleware to specific methods? That seems like it would make a more unified API.

If there is value in the attribute macro aspect of this, is it possible to avoid the attribute vs middleware incompatibility by making something that can convert an attribute into a tower middleware, or is that impossible by definition?
Separate comment re your proposed Path enum: It seems like it could be made more type safe by replacing the &'static strs with generated enums.

One possibly large benefit of applying middleware for individual methods vs how Tower middleware is currently used in tower-grpc is that it would allow the middleware function to be instantiated for the specific request and response types of a given method rather than some generic "prost message"/"blob of bytes" type.
It seems like this improvement is on its own nearly enough to implement the [zipkin_span] and [attribute(info)] examples above (the middleware would have to be given the grpc method name too). I like this because it fits nicely with the overall Tower is like Finagle narrative and seems to encourage more reusable, easier to write and easier to understand middleware code.

Another piece of feedback that is orthogonal to the other comments I've made:
I would personally prefer to keep this out of build.rs if possible, because

On a philosophical level, I think this kind of logic does not belong in the build system.
On a more practical level, I think this functionality would be more practical to use and more flexible if the method attributes were not locked in at build time. For example, what if you want to have a special implementation of a service for testing and you don't want zipkin there? Then you'd need to build the service definition twice which seems awkward.
Also: Because this functionality is so closely related to middleware I would prefer if the code to set it up was placed close to where middleware is set up.

So I think it's worth exploring if it would be possible to make it so that the API for using this is used where the services and middleware are set up. Not sure how to best do this... If it's not possible to do this with normal Rust generics this seems to me like a reasonable place to use a macro. Let me know if you want me to come up with a concrete example for how this could be done.

A use case to consider:
Middleware/attribute methods that need to be instantiated with run-time state. For example:

Lookaside load balancing/logging/tracing which needs to talk to an external service.
Request quota enforcement which needs some kind of per RPC method or per service or per server state and possibly something to be reconfigurable at run-time.

I'm not sure that it is required to support this*, but to me it seems like this could be easier to implement in a middleware (because they are closures that can naturally contain state)/non-build.rs (because then the middleware can be instantiated in Rust code along with the other middleware and service instantiation code) style approach.
*: It's possible to make the per-method attributes add metadata to the request and have some global middleware do the stateful things but it seems like an awkward approach to me.


multiselect

https://github.com/CuppaLabs/angular2-multiselect-dropdown

@agamem if you'd like this added to the list, please feel free to make a PR.


Remove paragraph style from default link attributes.

Any time the attributed text is modified with link attributes, the individual attributes in linkAttributes, inactiveLinkAttributes, and addedLinkAttributes are added or removed.  As such, there's no need to include paragraph styling as it will be inherited from the owning attributed string and doing so would actually clobber the much more complex styling provided by NSAttributedStringAttributesFromLabel or the passed attributed string.
The problem is apparent in Espressos.app if you tap into a drink and then tap on the link you will see all the text move when the link is active.  It becomes even more apparent if you set a label property like firstLineIndent because the link starts at index 0 and tapping the link sends the whole line left.

Thanks!


Costs for Azure in PowerBI

Hi,
I've tried the new version (v2.0.02242.55). This environment has 559 servers and in Power BI it shows that these will have an enormous annual cost in Azure (see bitmap). I've selected the Express workflow, currency in Euro Zone and Migrate to all IaaS. I guess (and would hope) something is not quite correct.

May be this issue is related to issue #21?

Hello @gjongeneel can you please look at the corresponding costs in Core-Report? A picture of the small set of costs and how they appear in excel should be helpful.
Thanks.

Also @gjongeneel, it would be helpful, if you could tell, what language is setup for your MS Office, is it not English?
Basically does that language have a decimal comma [,] instead of decimal point [.]?

Hello @gjongeneel, if the locale for your device is set to Dutch, that may cause, such an issue. In that locale, the thousand separator is a point [.] while decimal separator is a [,].
When you check the Core-Report excel, and see that costs are displayed with a decimal point [.] please look at the PowerBI regional settings in
Options -> Current File -> Regional Settings -> Locale.
If this value is set to Dutch, please set that to English (United States)
Images of the Core-Report and Regional settings in PowerBI would be helpful.

Thank you very much @gjongeneel, as we can see, that in the core-report excel the values are using decimal comma, so “three hundred and eighty point eight-four-one” is treated as “three hundred and eighty thousand eight hundred and forty one”.
Can I please know if you modified the decimal separator in MS Office to comma?
you can check if your system uses, decimal comma for your excel and change the same to use a decimal point here
https://support.microsoft.com/en-us/office/change-the-character-used-to-separate-thousands-or-decimals-c093b545-71cb-4903-b205-aebb9837bd1e

Thank you very much @gjongeneel, this may be an issue with the code base not handling devices that have a non-US regional setting.
I will be looking into this

Hello @gjongeneel , thank you very much for raising this issue. It showed that there is always room for improvement.
Can you please test this hotfix. I will be providing a zip file AzMigExport_Hotfix_InvariantCulture.zip; please download, extract and please run it as you run the deployed release build.
Please look at the Core-Report and see if the cost/numeric columns still contain a comma instead of Decimal point.
An image of the Core-Report as you observer would be really helpful.
AzMigExport_Hotfix_InvariantCulture.zip
Adding @kalrashradha , for FYI.

Hello @gjongeneel , I tried to fix this in code, however, System Presets are taking priority over presets I set in code.
PowerBI can only handle English (United States) for region settings.
To resolve this issue, please follow the
steps below and please let me know:

Please open Control Panel, by typing Control Panel in the start search bar.

In the search bar please type "Region"

Click on "Change date, time or number formats"

Click on "Additional Settings"

Please select the "Decimal Symbol" as '.'

Click on "Apply" for changes to take effect

Click on "Ok" on the "Customize Format" box

Click on "Ok" again on the "Region" box

Now when you open the Excel reports it would contain, Decimal as point, and this should also load in PBIT

After changing the decimal symbol, it looks much better:

However, as I actually live in the Netherlands, we need the decimal symbol to be a ',' for everyday work. It doesn't sound like a very 'global' solution that we are required to use the US format.

Thank you very much @gjongeneel , I really appreciate all the help from you today.
I appreciate the situation, of currently using the US format. However, this problem was seated a little deeper, even if I wrote decimal point, in excel, Power BI was still parsing it as decimal comma, because of system presets.
I have taken this as a work item, and am looking into the best possible way for a global resolution.
Until then, I request you to please use Decimal point instead of decimal comma.

Hello @gjongeneel , we have released a new version of Power BI template, v2.0.02249.58, this should resolve the issue you were having. Please let us know, and we can close this issue.
Thank you very much for bringing this up.


Tracking: Support TPC-H Queries (in Rust Frontend)

Currently, our new frontend in Rust can work for basic queries. Let's start to port TPC-H queries to it! See also #110 for the support of Java frontend.
A query is marked as supported if it has been added to the end-to-end test.
SQL Features in Queries

Query
Group-by (Aggregation)
Order-by (Sort/TopN)
Join
Subquery in from
Non-Correlated Subquery
Correlated Subquery
CTE / View

Q1
✔
✔

Q2

✔
✔

✔ (value in filter)

Q3
✔
✔
✔

Q4
✔
✔

✔ (exists)

Q5
✔
✔
✔

Q6
✔ (simple)

Q7
✔
✔
✔
✔ (table)

Q8
✔
✔
✔
✔ (table)

Q9
✔
✔
✔
✔ (table)

Q10
✔
✔
✔

Q11
✔
✔
✔

✔ (value in filter)

Q12
✔
✔
✔

Q13
✔
✔
✔ (outer)
✔ (table)

Q14
✔ (simple)

✔

Q15
✔
✔
✔

✔ (value in filter)

✔

Q16
✔
✔
✔

✔ (not in)

Q17
✔ (simple)

✔

✔ (value in filter)

Q18
✔
✔
✔

✔ (in)

Q19
✔ (simple)

✔

Q20
✔
✔
✔

✔ (in)
✔ (value in filter)

Q21
✔
✔
✔

✔ (exists)

Q22
✔
✔

✔ (table)
✔ (value in filter)
✔ (not exists)

Batch

[x] Batch: TPC-H Q1
[ ] Batch: TPC-H Q2
[x] Batch: TPC-H Q3
[x] Batch: TPC-H Q4
[x] Batch: TPC-H Q5
[x] Batch: TPC-H Q6
[x] Batch: TPC-H Q7
[ ] Batch: TPC-H Q8
[ ] Batch: TPC-H Q9
[x] Batch: TPC-H Q10
[ ] #2152
[ ] Batch: TPC-H Q12
[x] Batch: TPC-H Q13
[ ] Batch: TPC-H Q14
[ ] Batch: TPC-H Q15
[ ] Batch: TPC-H Q16
[ ] #1865
[ ] Batch: TPC-H Q18
[x] Batch: TPC-H Q19
[ ] Batch: TPC-H Q20
[ ] Batch: TPC-H Q21
[ ] Batch: TPC-H Q22

Streaming

[x] #1456
[ ] #1851
[x] #1457
[ ] #1852
[x] #1411
[x] Streaming: TPC-H Q6 https://github.com/singularity-data/risingwave/pull/1404
[x] Streaming: TPC-H Q7
[ ] #1853
[ ] #1854
[x] #1458
[ ] #1855
[x] #1872
[x] Streaming: TPC-H Q13
[x] #2019
[ ] Streaming: TPC-H Q15
[ ] Streaming: TPC-H Q16
[x] Streaming: TPC-H Q17
[ ] Streaming: TPC-H Q18
[x] Streaming: TPC-H Q19
[ ] Streaming: TPC-H Q20
[ ] Streaming: TPC-H Q21
[ ] Streaming: TPC-H Q22

For streaming TPC-H, the last two blocking issues on generating plan are

https://github.com/singularity-data/risingwave/issues/1866
https://github.com/singularity-data/risingwave/issues/2027

After that, we can see if executors would work correctly, and finish migrating to the Rust frontend.

Update: Today, here are the related on-going works:

Support unnesting correlated NOT IN subquery to anti-semi join @likg227
Support semi join in join executor (both batch and streaming) @yuhao-su
#1866

We have to support Substring for tpch q22.

According to our e2e tests we should be able to close everything on the streaming side except q16 and q21 (once #3681 is merged).

Thanks for this info. Update some issue status.
It seems we indeed do not includes q16 and q21, but what about q15?
https://github.com/singularity-data/risingwave/blob/093addfaf4cf6c728cc8c20c15a7aa2616617794/e2e_test/streaming/tpch_snapshot.slt#L45-L46


Week 11 : Create github pages from project

Explain project with documetation on a github page

Github pages created here https://tcd-ibm.github.io/Multiuser-Kanban-Board/


Update minimal config example

I'm not the first person to forget this import https://github.com/webpack/webpack-dev-server/issues/823 from this page.

@byzyk Shouldn't ESLint caught there errors?

@montogeek it's disabled in the config here since we're missing require statements in a lot of places, not only path but also some plugins etc.
Do you think like we should address that to make examples more complete?


Added new cairo6.moe.edu.eg school domain

Added new cairo6.moe.edu.eg school domain

@mostafa-shaker0 Regrettably, the domain cairo6.moe.edu.eg is widely known for having a lot of hacked accounts. They are all easy to google. Thus, we cannot trust this domain at all.
Please use an alternative method to get the free license: enroll to GitHub Student Developer Program at https://education.github.com/discount_requests/application. Then apply for JetBrains educational subscription with your GitHub account (GitHub tab at https://www.jetbrains.com/shop/eform/students).
I have to close this request without merging.
Thank you for your understanding!


[SUGGESTION] Bulk-minting NFTs on Ethereum

Create a tutorial sharing tips and tricks on how to mint massive (or just many) numbers of NFTs on Ethereum coupled with how to upload those images and assets to nft.storage, as well as how to structure the project and query the data after the bulk- upload/mint.
Seel also: #130

First draft is currently here on Notion


Return cached post-dated L1 closing transaction on newBid to Frontend CLI

Full requirements are in spec
Blocked by #158

I missed that to do that we need use private Hydra API to construct tx. That is out of scope of our project. Will ask Hydra for that feature and block issue until that.

Hydra team said that implement time on L2 would be simpler and they already planned that. So we should use time API, but this will be probably implemented only after delivery of current project.


State Manager approach suggested

NOTE: THIS PR WILL NEVER BE MERGED AS IS
Framework-based examples
Following examples are aimed to prove framework-agnosticism of state management logic - for each examples only the logic that 'connects' state to framework is changing. Note that for all examples content of stateManager and popupStateManager was just copy-pasted from this PR.

Plain vanilla HTML project: https://codesandbox.io/s/n1rl4jyrkm
VueJS project: https://codesandbox.io/s/885mz3r548

Why
This PR introduces alternative implementation approach to the idea expressed in original branch devoted to state manager functionality (https://github.com/stardust-ui/react/tree/feat/state) - while being inspired by the same set of principles and ideas.
Benefits
Please, note that intent of this PR is not to introduce a clean code, but rather to deliver an idea that should introduce the following benefits over original implementation approach:

there is a single source of truth for component's state provided by state manager's state <-> in the original approach state may be consumed from two sources: either from React's state, or from stateManager's state

thus, with single source of state data, there is no need to struggle with syncing state manager's state - it is always guaranteed to be up-to-date

less verbose, less error-prone and more intuitive manager's integration logic with React - the one that client will be responsible for

no (?) => (??) => ... functions exposed to client's API

clear separation of framework-agnostic code and React-specific one

API example (with React bindings only)
class Popup extends UIComponent {
 ...
  private stateManager = popupStateManager.withBindings({
    getState: () => {
        // AUTOCONTROLLED state logic
        return { ...this.state, ...this.props }
    },

    setState: ({ stateDiff, prevState, newState, actionName, userArgs }) => {
      const { eventArgs } = userArgs

      this.setState(
        stateDiff,
        () =>  _.invoke(this.props, 'onOpenChange', eventArgs, newState))
    },
  })
}

API example (full)
const stateManager = StateManager.create({
    // ----------------------------------
    // FRAMEWORK-AGNOSTIC actions
    // ----------------------------------
    actions: {
      open: it => {
        it.setState({ open: true })
      },
      ...
      toggle: it => {
        const state = it.getState()

        if (state.open) {
          it.close()
        } else {
          it.open()
        }
      },
    },

    // ----------------------------------
    // BINDINGS TO REACT
    // ----------------------------------
    bindings: {
      /* returns component's state */
      getState: () => {
        return { ...this.state, ...this.props }    // AUTOCONTROLLED state logic
      },

      setState: ({ stateDiff, prevState, newState, actionName, userArgs }) => {
        const { eventArgs } = userArgs
        ...
      },
    },
  })

Extensibility points
Please, note that both action's middleware, as well as hook/sideEffects (willOpen, didOpen) concepts could be introduced as part of suggested implementation in case if necessary. Currently willSetState filter method (that may act like a filter for updated state) is introduced as an example.
Please, feel free to test Popup component that will run on top of the proposed approach - while some edge cases are not handled (like setting null or undefined prop values explicitly), the examples still should be able to serve as proof of concept.
Disclaimer
Please, note that this code is not polished and may have sloppy implementations at non-critical places (for example, there is no code that will map component's prop names to state manager's ones). However, this code will never get to the Stardust repo in the state it is now - its main goal is just to deliver an essence of the idea. Please, use pragmatic judgement while estimating exact implementation strategy chosen - at some places where it is not critical I've deliberately chosen sloppy approaches. At the same time, in case if some code snippet is seen as a critical issue, please, feel free to let me know about that, to open related discussion.
Thank you :)
https://codesandbox.io/s/7m8vw1pro0

needs couple of changes to simplify abstractions exposed to client - at the same time, the idea will stay the same

To conclude, I see that your comment is rather focused on what React connector should look like - I totally agree with the points expressed there. At the same time, another (and, probably, main one) goal of the PR is to introduce state management implementation that would be 'connectable' to any library that is JS-based, so that client will be able to consume state management logic from different app's stack - and to me it clearly seems that provided low-level API is able to address all your concerns by just introducing another approach to React connector.

Yes, you're right. I'm claiming about React bindings, they should be implemented in another way and use React's patterns. The current implementation doesn't look well for me.
I'm afraid that in pursuit of the framework agnostic implementation we will not do a really good API neither for React. nor for Vue and others.

As I see, RFC for Hooks was merged https://github.com/reactjs/rfcs/pull/68, we can discuss this today on sync meeting 👍
We also should check that hooks will work with our createComponent():

Only call Hooks at the top level. Don’t call Hooks inside loops, conditions, or nested functions.

@layershifter

It couples a component's state and a state of its manager, both of these states can be accessed by a user

Lets be specific here - its not coupling, but, essentially, making state manager being responsible for making all the necessary adjustment's to component's state when action is invoked.
So, essentially, your objection is not about 'coupling', but about the fact that state could be read from different places by the client. However, here I would object with the following arguments:

this necessity for reading from state manager (instead of component's state directly) is relevant for autocontrolled components only

similar to AutoControlled component, where it is also necessary for client to remember about trySetState() function (instead of setState())
more than that, with proposed approach it is easily possible to introduce connector for AutoControlled components, so that the following invariants will always hold - and this will eliminate your concerns about 'where state should be consumed from', as it might be consumed from any source then:

// code of Foo which extends AutoControlledComponent
this.stateManager = connect(popupStateManager).toAutoControlled(this)

// and this will ensure the following conditions are always true:

// first
if (this.props.open !== undefined) {
 this.state.open === this.props.open
}

// second
this.stateManager.getState().open === this.state.open

the problem is that we are not going to rely on AutoControlled component, as it was previously discussed, because of its componentWillUpdate hook - and this was the reason I've not introduced it yet

Use HOC as a connector
If I would summarise your comments, those, in their essence, reduce to the fact that HOC-based approach is suggested for state management in React (or Hooks-based, will leave this for now) - and given that there is no objections about framework-agnostic part of the PR, this suggests me that here we have an agreement there, right?
Moving to HOC-based connector - I can introduce this as well, to provide an idea of what it will look like (essentially it is about hoisting the logic of current connector to this HOC component) - key thing is that I do not see any limitations for that. Actually, let me introduce that, to conclude this topic.

Hooks-based connector
Might introduce this as well. The reason I've not done that and have intentionally used older React API is because to me it seems like a good test for introduced state management functionality, in terms of whether it is really agnostic of the web technology or not: if it wouldn't be possible to introduce any approach for connecting it with 'older' React, then this test is failed.
Thus, I may decide to skip this moment for now, as if we will resolve ongoing concerns, we will be absolutely assured that Hooks-based connector logic also can be implemented.

Looks much simpler, let's merge this into /state/... in the repo.  Add HTML, customElement, Vue, and React examples.  We'll iterate on it there. 👍


Cannot find rules when npm linked

When you're developing on lambda-cfn or related, and you npm link lambda-cfn into a patrol stack, rules paths cannot be resolved because the wrong application root is used.
@zmully I believe the start of the problem is here https://github.com/mapbox/lambda-cfn/blob/7e278324d7fe52973f4315b5c9fa65e91f5f0310/lib/lambda-cfn.js#L59 which uses app-root-path here https://github.com/mapbox/lambda-cfn/blob/7e278324d7fe52973f4315b5c9fa65e91f5f0310/lib/lambda-cfn.js#L5 to resolve the root of the application.
There are a few places in lambda-cfn.js that rely on app-root-path.  There should be tests to ensure all these cases are handled properly, in addition to properly handling the case around an npm linked copy of lambda-cfn.

Looks like export LAMBDA_TASK_ROOT=/patrol/service/root fixes the app root path.

Updated the patrol docs to reflect this setting. While this works for deploying a patrol stack with a dev lambda-cfn, it breaks lambda-cfn tests. I don't think this is a deal breaker ATM, so it's left as an exercise for the reader to unset it before running any tests.