Issue with USA KIA implementation

Getting an error upon installation (Region = USA and  Brand = KIA.  Log error below.  I looked at the vehicle object and it seems to be expecting the attribute self.model to be populated with the vehicle model attribute on the token which does not exist on the UsaToken.   I believe it can be pulled out of the json response with  vehicle_model = vehicle_summary[0]['modelName'].
vehicle: Vehicle = Vehicle(
File "/config/custom_components/kia_uvo/Vehicle.py", line 40, in init
self.model = token.vehicle_model
AttributeError: 'Token' object has no attribute 'vehicle_model'

Same issue here.

I have the same issue, but I think this is a duplicate of https://github.com/fuatakgun/kia_uvo/issues/88

Yes it is covered in that as well if anyone has a chance to try fix it please try and create a PR.

Added the vehicle model to the USA token as a short term fix.  It is located here.  Could someone test and let me know: https://github.com/fuatakgun/kia_uvo/tree/USAKia

using USAKia I got this log (new error)
2021-11-07 12:58:52 DEBUG (SyncWorker_1) [custom_components.kia_uvo.KiaUvoAPIUSA] kia_uvo - Sign In Response {"status":{"statusCode":0,"errorType":0,"errorCode":0,"errorMessage":"Success with response body"}}
2021-11-07 12:58:52 DEBUG (SyncWorker_1) [custom_components.kia_uvo.KiaUvoAPIUSA] got session id 284
2021-11-07 12:58:53 DEBUG (SyncWorker_1) [custom_components.kia_uvo.KiaUvoAPIUSA] kia_uvo - Get Vehicles Response {"status":{"statusCode":0,"errorType":0,"errorCode":0,"errorMessage":"Success with response body"},"payload":{"vehicleSummary":[{"vin":"vvv","vehicleIdentifier":"000","modelName":"NIRO EV","modelYear":"2019","nickName":"Niro EV","generation":2,"extColorCode":"C3S","trim":"EX PREMIUM","imagePath":{"imageName":"2019-niro_ev-ex_premium-c3s.png","imagePath":"/content/dam/kia/us/owners/image/vehicle/2019/niro_ev/ex_premium/","imageType":"1","imageSize":{"length":"100","width":"100","uom":0}},"enrollmentStatus":1,"fatcAvailable":1,"telematicsUnit":1,"fuelType":4,"colorName":"ALUMINUM SILVER","activationType":2,"mileage":"12089.4","dealerCode":"MD047","mobileStore":[{"osType":0,"downloadURL":"https://itunes.apple.com/us/app/kia-access-with-uvo-link/id1280548773?mt=8","image":{"imageName":"iosImage.png","imagePath":"/content/dam/kia/us/owners/image/common/app/","imageType":"2","imageSize":{"length":"100","width":"100","uom":0}}},{"osType":1,"downloadURL":"https://play.google.com/store/apps/details?id=com.myuvo.link","image":{"imageName":"androidImage.png","imagePath":"/content/dam/kia/us/owners/image/common/app/","imageType":"2","imageSize":{"length":"100","width":"100","uom":0}}}],"supportedApp":{"appType":"5","appImage":{"imageName":"uvo-app.png","imagePath":"/content/dam/kia/us/owners/image/common/app/access/","imageType":"2","imageSize":{"length":"100","width":"100","uom":0}}},"supportAdditionalDriver":0,"customerType":0,"projectCode":"DEEV","headUnitDesc":"AVN5.0","provStatus":"4","enrollmentSuppressionType":0,"vehicleKey":"kkk"}]}}
2021-11-07 12:58:53 DEBUG (MainThread) [custom_components.kia_uvo] kia_uvo - async_setup_entry started - <homeassistant.config_entries.ConfigEntry object at 0x7f8efc950ca0>
2021-11-07 12:58:53 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry email for kia_uvo
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 304, in async_setup
    result = await component.async_setup_entry(hass, self)  # type: ignore
  File "/config/custom_components/kia_uvo/__init__.py", line 134, in async_setup_entry
    vehicle: Vehicle = Vehicle(
  File "/config/custom_components/kia_uvo/Vehicle.py", line 42, in __init__
    self.registration_date = token.vehicle_registration_date
AttributeError: 'Token' object has no attribute 'vehicle_registration_date'

I'm new to this code base but very excited at the idea of a more reliable interface for controlling my car.  Please let me know if I can provide any other logs, or if I striped some information that would've been useful.

it looks like that next error is about an attribute that doesn't exist in USA and is only used for entity 'sw_version' so this seems a quick fix, though a better fix might be to just log that and not throw it in device_info for KiaUvoEntity.py as it isn't really a sw_version anyway
diff --git a/custom_components/kia_uvo/Token.py b/custom_components/kia_uvo/Token.py
index 5c06534..03acc47 100644
--- a/custom_components/kia_uvo/Token.py
+++ b/custom_components/kia_uvo/Token.py
@@ -33,6 +33,7 @@ class UsaToken(Token):
         self.vehicle_name = vehicle_name
         self.vehicle_key = vehicle_key
         self.vehicle_model = vehicle_model
+        self.vehicle_registration_date = 'unknown'

     def expire(self):
         pass

next error was about token refreshing, I'm likely missing something but from what I saw in the logs I didn't see any expiration so this might be a valid fix
diff --git a/custom_components/kia_uvo/Token.py b/custom_components/kia_uvo/Token.py
index 5c06534..c194ef7 100644
--- a/custom_components/kia_uvo/Token.py
+++ b/custom_components/kia_uvo/Token.py
@@ -33,6 +33,8 @@ class UsaToken(Token):
         self.vehicle_name = vehicle_name
         self.vehicle_key = vehicle_key
         self.vehicle_model = vehicle_model
+        self.vehicle_registration_date = 'unknown'
+        self.valid_until = datetime.max.strftime(DATE_FORMAT)

     def expire(self):
         pass

sorry for the noise but I'm going to have to go soon so I'm going to post my lastest logs using KiaUSA with above additions
2021-11-07 13:39:42 DEBUG (SyncWorker_0) [custom_components.kia_uvo.KiaUvoAPIUSA] got response {"status":{"statusCode":0,"errorType":0,"errorCode":0,"errorMessage":"Success with response body"},"payload":{"vehicleInfoList":[{"vinKey":"kkk","vehicleConfig":{"vehicleDetail":{"vehicle":{"vin":"vvv","trim":{"modelYear":"2019","salesModelCode":"V1262","optionGroupCode":"015","modelName":"NIRO EV","factoryCode":"DQ","projectCode":"DEEV","trimName":"EX PREMIUM","driveType":"0","transmissionType":"1","ivrCategory":"6","btSeriesCode":"N"},"telematics":1,"mileage":"12089.4","mileageSyncDate":"20211107011820","exteriorColor":"ALUMINUM SILVER","exteriorColorCode":"C3S","fuelType":4,"invDealerCode":"MD047","testVehicle":"0","supportedApps":[{"appType":"0"},{"appType":"5","appImage":{"imageName":"uvo-app.png","imagePath":"/content/dam/kia/us/owners/image/common/app/access/","imageType":"2","imageSize":{"length":"100","width":"100","uom":0}}}],"activationType":2},"images":[{"imageName":"2019-niro_ev-ex_premium-c3s.png","imagePath":"/content/dam/kia/us/owners/image/vehicle/2019/niro_ev/ex_premium/","imageType":"1","imageSize":{"length":"100","width":"100","uom":0}}],"device":{"launchType":"0","swVersion":"DEEV.USA.SOP.V105.190503.STD_H","telematics":{"generation":"3","platform":"1","tmsCenter":"1","billing":true},"versionNum":"ECO","headUnitType":"0","hdRadio":"X40HA","ampType":"NA","modem":{"meid":"meidd","mdn":"mdnn","iccid":"idid"},"headUnitName":"avn40ev_np","bluetoothRef":"10","headUnitDesc":"AVN5.0"}},"billingPeriod":{"freeTrial":{"value":12,"unit":0},"freeTrialExtension":{"value":12,"unit":1},"servicePeriod":{"value":60,"unit":1}}},"lastVehicleInfo":{"vehicleNickName":"Niro EV","preferredDealer":"MD047","customerType":0,"enrollment":{"provStatus":"4","enrollmentStatus":"1","enrollmentType":"0","registrationDate":"20191123","expirationDate":"20201122","expirationMileage":"100000","freeServiceDate":{"startDate":"20191122","endDate":"20201122"}},"activeDTC":{"dtcActiveCount":"0"},"vehicleStatusRpt":{"statusType":"2","reportDate":{"utc":"20211107183941","offset":-8},"vehicleStatus":{"climate":{"airCtrl":false,"defrost":false,"airTemp":{"value":"72","unit":1},"heatingAccessory":{"steeringWheel":0,"sideMirror":0,"rearWindow":0}},"engine":false,"doorLock":false,"doorStatus":{"frontLeft":0,"frontRight":0,"backLeft":0,"backRight":0,"trunk":0,"hood":0},"lowFuelLight":false,"evStatus":{"batteryCharge":false,"batteryStatus":75,"batteryPlugin":0,"remainChargeTime":[{"remainChargeType":1,"timeInterval":{"value":0,"unit":4}},{"remainChargeType":2,"timeInterval":{"value":0,"unit":4}},{"remainChargeType":3,"timeInterval":{"value":140,"unit":4}}],"drvDistance":[{"type":2,"rangeByFuel":{"evModeRange":{"value":212,"unit":3},"totalAvailableRange":{"value":212,"unit":3}}}],"syncDate":{"utc":"20211107151819","offset":-8},"targetSOC":[{"plugType":0,"targetSOClevel":127,"dte":{"type":2,"rangeByFuel":{"gasModeRange":{"value":0,"unit":3},"evModeRange":{"value":212,"unit":3},"totalAvailableRange":{"value":212,"unit":3}}}},{"plugType":1,"targetSOClevel":127,"dte":{"type":2,"rangeByFuel":{"gasModeRange":{"value":0,"unit":3},"evModeRange":{"value":212,"unit":3},"totalAvailableRange":{"value":212,"unit":3}}}}]},"ign3":false,"transCond":true,"tirePressure":{"all":0},"dateTime":{"utc":"20211107183941","offset":-8},"syncDate":{"utc":"20211107151819","offset":-8},"batteryStatus":{"stateOfCharge":86,"sensorStatus":0},"sleepMode":true,"lampWireStatus":{"headLamp":{},"stopLamp":{},"turnSignalLamp":{}},"windowStatus":{},"engineRuntime":{},"valetParkingMode":0}},"location":{"coord":{"lat":30,"lon":-30,"alt":108,"type":0,"altdo":0},"head":342,"speed":{"value":0,"unit":1},"accuracy":{"hdop":6,"pdop":10},"syncDate":{"utc":"20211107151819","offset":-8}},"financed":true,"financeRegistered":true,"linkStatus":0}}]}}
2021-11-07 13:39:42 ERROR (MainThread) [custom_components.kia_uvo.Vehicle] kia_uvo - Exception in update : 'vehicleStatus' - traceback: Traceback (most recent call last):
  File "/config/custom_components/kia_uvo/Vehicle.py", line 55, in update
    self.set_last_updated()
  File "/config/custom_components/kia_uvo/Vehicle.py", line 176, in set_last_updated
    self.vehicle_data["vehicleStatus"]["time"],
KeyError: 'vehicleStatus'

2021-11-07 13:39:42 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry username for kia_uvo
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 304, in async_setup
    result = await component.async_setup_entry(hass, self)  # type: ignore
  File "/config/custom_components/kia_uvo/__init__.py", line 174, in async_setup_entry
    await update(dt_util.utcnow())
  File "/config/custom_components/kia_uvo/__init__.py", line 165, in update
    if (datetime.now(local_timezone) - vehicle.last_updated > force_scan_interval):
TypeError: can't subtract offset-naive and offset-aware datetimes

I'm still new to python so I'll look into this error later but I'm less able to fix it with my existing knowledge.  But great to see real car details in the latest logs.

This is great!  I do think that using a separate token for this is causing us pain.  May of the fields align with something in the normal token just with a different name.  As such I have refactored it to return using the same token as all other regions.  Are you able to retest?  That last error you have it because the time stamp is empty.
@fuatakgun and I have been chatting on a few challenges like this since with multiple regions they each have unique issues like this.

this diff fixes the next couple errors and I'm not explicitly getting anymore errors
diff --git a/custom_components/kia_uvo/KiaUvoAPIUSA.py b/custom_components/kia_uvo/KiaUvoAPIUSA.py
index ec44d30..3733d17 100644
--- a/custom_components/kia_uvo/KiaUvoAPIUSA.py
+++ b/custom_components/kia_uvo/KiaUvoAPIUSA.py
@@ -116,8 +116,20 @@ class KiaUvoAPIUSA(KiaUvoApiImpl):
         #using vehicle_VIN as device ID
         #using vehicle_key as vehicle_regid

-
-        token = Token(session_id, None, vehicle_vin, vehicle_name, vehicle_id, vehicle_key, "Unknown", vehicle_registration_date, valid_until, "NoStamp")
+
+        token = Token({})
+        token.set(
+            session_id,
+            None,
+            vehicle_vin,
+            vehicle_name,
+            vehicle_id,
+            vehicle_key,
+            "Unknown",
+            vehicle_registration_date,
+            valid_until,
+            "NoStamp",
+        )

         return token

@@ -148,11 +160,16 @@ class KiaUvoAPIUSA(KiaUvoApiImpl):
                     token.vehicle_regid
                 ]
             }
-        _LOGGER.debug(f"sending get vehicle info request ${body} with session id ${token.sid}")
+        _LOGGER.debug(f"sending get vehicle info request ${body} with session id ${token.access_token}")
         response = requests.post(url, json=body, headers=headers)
         _LOGGER.debug(f"got response {response.text}")
         response_body = response.json()
-        return response_body
+        vehicle_data = {
+          "vehicleStatus": response_body["payload"]["vehicleInfoList"][0]["lastVehicleInfo"]["vehicleStatusRpt"]["vehicleStatus"]
+        }
+        vehicle_data["vehicleStatus"]["time"] = vehicle_data["vehicleStatus"]["dateTime"]["utc"]
+        return vehicle_data
+
     def get_location(self, token: Token):
         pass
     def get_pin_token(self, token: Token):

though I noticed the engine type is set incorrectly as PHEV even though this is an EV
my vehicle info response for reference is
vehicleConfig/vehicleDetail/trim(driveType or transmissionType) might better define EV vs others but I don't know what the other region responses look like
{"status":{"statusCode":0,"errorType":0,"errorCode":0,"errorMessage":"Success with response body"},"payload":{"vehicleInfoList":[{"vinKey":"kkk","vehicleConfig":{"vehicleDetail":{"vehicle":{"vin":"vvv","trim":{"modelYear":"2019","salesModelCode":"V1262","optionGroupCode":"015","modelName":"NIRO EV","factoryCode":"DQ","projectCode":"DEEV","trimName":"EX PREMIUM","driveType":"0","transmissionType":"1","ivrCategory":"6","btSeriesCode":"N"},"telematics":1,"mileage":"12110.8","mileageSyncDate":"20211107095846","exteriorColor":"ALUMINUM SILVER","exteriorColorCode":"C3S","fuelType":4,"invDealerCode":"MD047","testVehicle":"0","supportedApps":[{"appType":"0"},{"appType":"5","appImage":{"imageName":"uvo-app.png","imagePath":"/content/dam/kia/us/owners/image/common/app/access/","imageType":"2","imageSize":{"length":"100","width":"100","uom":0}}}],"activationType":2},"images":[{"imageName":"2019-niro_ev-ex_premium-c3s.png","imagePath":"/content/dam/kia/us/owners/image/vehicle/2019/niro_ev/ex_premium/","imageType":"1","imageSize":{"length":"100","width":"100","uom":0}}],"device":{"launchType":"0","swVersion":"DEEV.USA.SOP.V105.190503.STD_H","telematics":{"generation":"3","platform":"1","tmsCenter":"1","billing":true},"versionNum":"ECO","headUnitType":"0","hdRadio":"X40HA","ampType":"NA","modem":{"meid":"300","mdn":"400","iccid":"500"},"headUnitName":"avn40ev_np","bluetoothRef":"10","headUnitDesc":"AVN5.0"}},"billingPeriod":{"freeTrial":{"value":12,"unit":0},"freeTrialExtension":{"value":12,"unit":1},"servicePeriod":{"value":60,"unit":1}}},"lastVehicleInfo":{"vehicleNickName":"Niro EV","preferredDealer":"MD047","customerType":0,"enrollment":{"provStatus":"4","enrollmentStatus":"1","enrollmentType":"0","registrationDate":"20191123","expirationDate":"20201122","expirationMileage":"100000","freeServiceDate":{"startDate":"20191122","endDate":"20201122"}},"activeDTC":{"dtcActiveCount":"0"},"vehicleStatusRpt":{"statusType":"2","reportDate":{"utc":"20211108010648","offset":-8},"vehicleStatus":{"climate":{"airCtrl":false,"defrost":false,"airTemp":{"value":"72","unit":1},"heatingAccessory":{"steeringWheel":0,"sideMirror":0,"rearWindow":0}},"engine":false,"doorLock":true,"doorStatus":{"frontLeft":0,"frontRight":0,"backLeft":0,"backRight":0,"trunk":0,"hood":0},"lowFuelLight":false,"evStatus":{"batteryCharge":true,"batteryStatus":80,"batteryPlugin":2,"remainChargeTime":[{"remainChargeType":3,"timeInterval":{"value":95,"unit":4}}],"drvDistance":[{"type":2,"rangeByFuel":{"evModeRange":{"value":227,"unit":3},"totalAvailableRange":{"value":227,"unit":3}}}],"syncDate":{"utc":"20211108005846","offset":-8},"targetSOC":[{"plugType":0,"targetSOClevel":90,"dte":{"type":2,"rangeByFuel":{"gasModeRange":{"value":0,"unit":3},"evModeRange":{"value":227,"unit":3},"totalAvailableRange":{"value":227,"unit":3}}}},{"plugType":1,"targetSOClevel":90,"dte":{"type":2,"rangeByFuel":{"gasModeRange":{"value":0,"unit":3},"evModeRange":{"value":227,"unit":3},"totalAvailableRange":{"value":227,"unit":3}}}}]},"ign3":true,"transCond":true,"tirePressure":{"all":0},"dateTime":{"utc":"20211108010648","offset":-8},"syncDate":{"utc":"20211108005846","offset":-8},"batteryStatus":{"stateOfCharge":87,"sensorStatus":0},"sleepMode":false,"lampWireStatus":{"headLamp":{},"stopLamp":{},"turnSignalLamp":{}},"windowStatus":{},"engineRuntime":{},"valetParkingMode":0}},"location":{"coord":{"lat":10,"lon":-30,"alt":40,"type":0,"altdo":0},"head":345,"speed":{"value":0,"unit":1},"accuracy":{"hdop":7,"pdop":13},"syncDate":{"utc":"20211108005846","offset":-8}},"financed":true,"financeRegistered":true,"linkStatus":0}}]}}

I got an error about session expiring when exploring entities try to verify things and reloaded the integration.  I'm not aware of best practices to intercept that response and re-authenticate before retrying.
2021-11-07 20:24:59 DEBUG (SyncWorker_5) [custom_components.kia_uvo.KiaUvoAPIUSA] got response {"status":{"statusCode":1,"errorType":1,"errorCode":1003,"errorMessage":"Session Key is either invalid or expired"}}
2021-11-07 20:24:59 ERROR (MainThread) [custom_components.kia_uvo.Vehicle] kia_uvo - Exception in update : 'payload' - traceback: Traceback (most recent call last):
  File "/config/custom_components/kia_uvo/Vehicle.py", line 54, in update
    self.vehicle_data = await self.hass.async_add_executor_job(self.kia_uvo_api.get_cached_vehicle_status, self.token)
  File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 52, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/kia_uvo/KiaUvoAPIUSA.py", line 168, in get_cached_vehicle_status
    "vehicleStatus": response_body["payload"]["vehicleInfoList"][0]["lastVehicleInfo"]["vehicleStatusRpt"]["vehicleStatus"]

Just did a commit against the USAKia branch.  Give it a shot to see if I corrected as per your above comments.  Feel free to create a PR to that branch as well.
As for the session. I just left the session as being 24 hour expiry.  We don't know how log it actually lasts.   In the commit I just did I dropped that to 1 hour since it sounds like it expired pretty quickly.

Are any data points showing in HA now? or just error free and blank?

I haven't checked the engine on/off yet
also haven't figured out how to verify location yet as I think I have to enable a preference though I've seen it in the response I've been sanitizing
both ranges say 365.3 km, but should be 197 mi (I haven't set the unit preference as I just keep recreating)
all other showing in shot above seem to be populating correctly.
I think the session expires based on idle time between requests based on prior app usage, and based on when it appeared earlier in testing it might be incredible short like 5 minutes range

reverted to KiaUSA and verified same results as above, thanks :) looking great. I'll try to put any future changes into a pr for convenience.  I can only check in twice a day and am about to head to sleep, please let me know what to look into next.

That is a great start.  We may need to shorten the token window to something in the 5 minute range and see if that resolves it.   I think this is the first implementation for Kia USA so learning as we go!
Glad to see data is starting to work.   I am thinking we continue this conversation over at #88.

@dahlb as for next steps it is really up to the USA Kia users on what they see.  I am running blind on this without access.  Closing this issue in favor of 88.


Profiles not loading on BT connection

I've found profiles often (if not always) do not load when connected through Bluetooth. The controller is connected definately connected through bluetooth, the controller light is white, no features function and games don't recognise it.
I have to stop and start DS4 Windows manually to get the profiles to load.

I should note:
I'm on Windows 7 64bit. Let me know if any other details are needed.

Does DS4Windows actually show the controller being assigned to a profile. Also can you tell me what bluetooth adapter you are using?
Does the same thing ever happen using USB?


uses-sdk:minSdkVersion 23 cannot be smaller than version 26 declared in library [androidx.health.connect...]

Describe the bug
Error is:
> Task :app:processDebugMainManifest FAILED
/Users/***/Projects/***/android/app/src/debug/AndroidManifest.xml Error:
        uses-sdk:minSdkVersion 23 cannot be smaller than version 26 declared in library [androidx.health.connect:connect-client:1.1.0-alpha06] /Users/***/.gradle/caches/transforms-4/ae4421fd35b079acbae3c31383d9ea69/transformed/jetified-connect-client-1.1.0-alpha06/AndroidManifest.xml as the library might be using APIs not available in 23
        Suggestion: use a compatible library with a minSdk of at most 23,
                or increase this project's minSdk version to at least 26,
                or use tools:overrideLibrary="androidx.health.connect.client" to force usage (may lead to runtime failures)

See https://developer.android.com/r/studio-ui/build/manifest-merger for more information about the manifest merger.

To Reproduce
Not sure. I just followed the installation instructions and got this error.
Expected behavior
Ideally, my Android build should've built successfully.
Environment:

Health Connect Version: "expo-health-connect": "^0.1.0",
React Native Version:  "0.74.3"
New architecture enabled: Yes
Using Expo: Prebuild (Dev Client)

I'm getting issues with the Expo installation. Is there a step missing in the Expo installation guide or is it an issue with my project? Any help would be appreciated greatly. Thank you!

I think in expo-health-connect, there's this line minSdkVersion safeExtGet("minSdkVersion", 21) which needs to be updated to minSdkVersion safeExtGet("minSdkVersion", 26).

Nvm. I just had to update my build.gradle to minSdkVersion = Integer.parseInt(findProperty('android.minSdkVersion') ?: '26').
Sorry! Simple fix haha.


dataStorage vs persistence value

The very common convention is to have a persistence flag for dealing with volumes. This chart is using dataStorage instead. We should probably consider changing this flag before 1.0.

We are naming the things as they are named on the Spire side. So dataStorage is named because of the dataStorage config option in the spire config.

Its a helm chart though and the convention that most helm users expect is persistence rather then dataStore. Which way will be less confusing to users?

We talked it over during the last meeting and decided to go with persistence.


I got this error. I followed all the steps

File "app.py", line 32
print(f"{username}:{password} | {colorama.Fore.RED} DEAD ACC")
^
SyntaxError: invalid syntax

What version of Python are you using? If it is below 3.6 perhaps the issue is that the f-strings are not working.

What version of Python are you using? If it is below 3.6 perhaps the issue is that the f-strings are not working.

I’m using version 3.7

Ok I got it working


android not working tab

<TapGestureHandler
                {...Platform.select({
                  ios: {
                    maxDeltaY: 0,
                    maxDeltaX: 0,
                  },
                  android: {
                    maxDeltaY: 0,
                    maxDeltaX: 0,
                  },
                })}
                onHandlerStateChange={e => this._onSingleTap(e, 0)}>

Thank you for the issue
Hope will be fixed soon

Thank's you. let me try again!

@isthaison, I can't understand you.
I suppose this issue has been fixed so I decided to close it.
If you still face the problem, reopen the issue or write here.


[OnCall] Don't error when estimating price for zero amounts

We are getting a lot of alerts like https://gnosisinc.slack.com/archives/CQZBU9T5J/p1633190571003100. I assume that these queries are coming from our trading bot (in particular when doing the reverse checked added in https://github.com/gnosis/gp-v2-trading-bot/pull/31
Since we don't control what clients request from us, we should probably not error when a clients wants to get an estimate for a zero amount.
Arguably we could also filter these kind of requests at a higher layer and not even forward them into the price estimator (happy to change to that if that's preferred).
Test Plan
Existing unit tests (should I add one for this branch?)

Codecov Report

Merging #1183 (367aad8) into main (0bcce38) will decrease coverage by 0.02%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main    #1183      +/-   ##
==========================================
- Coverage   66.71%   66.69%   -0.03%
==========================================
  Files         135      135
  Lines       27042    27027      -15
==========================================
- Hits        18042    18025      -17
- Misses       9000     9002       +2

Gave this scenario a dedicated error type. This way it doesn't get log as an unknown error anymore which should also fix the alert (adjusted test plan). @vkgnosis can you give it another glimpse please?

Looks like the same change was actually already done in #1188 making this PR quite trivial again.


Add state library - Vuex

Here you got some examples:
https://github.com/coachy-software/coachy-frontend/tree/master/src/store
/cc @rrye

We are not using Vue anymore.


feat: adds project level properties to project object

Adds databaseId and other project level properties to the GitHubProject object.
Closes #66

We need a separate method to get project data, using getters that return undefined until a certain internal state is not a good API. The new API should always behave the same to the consumer, no matter the internal state.

 I'll rework this. I had something more akin to that originally, but ultimately went with the 'simpler' option here.

Start with the the README update to show the new API, once we agree on that, the rest will be easy.

Start with the the README update to show the new API, once we agree on that, the rest will be easy.

Will do, my plan is to start this tomorrow, but I may not get to it until Monday.

@gr2m Here is the updated readme adding references for the potential new API.
Another path we can consider is making this available during initialization. This might also lend itself to some issues we're trying to solve internally. For example, instantiating with an non-existent project number provides no immediate feedback:
const project = new GitHubProject({
  token: "<token>",
  org: "<org>",
  number: 9999,
});

It's not until we attempt to list items that we realize an issue exists:
await project.items.list()

file:///github-project/api/lib/get-state-with-project-items.js:33
    projectNext.fields.nodes
                ^

TypeError: Cannot read properties of null (reading 'fields')
    at getStateWithProjectItems (file:///github-project/api/lib/get-state-with-project-items.js:33:17)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async listItems (file:///github-project/api/items.list.js:13:26)
    at async file:///github-project/.test/scratchpad.js:12:13

Node.js v18.2.0

I'd suggest to merge https://github.com/gr2m/github-project/pull/72 first, then create a 2.x branch, and update this PR head from main to 2.x. I'd add the change to #72.
If we merge it first then I fear it'd add a lot merge conflicts

Here is the updated readme adding references for the potential new API.

looks good 👍🏼

Another path we can consider is making this available during initialization

We could offer a factory method (e.g. a static class method such as Project.get(options)) as an alternative which would internally instantiate the project instance and run project.get().
We should definitely improve error messages either way. For a better debugging experience, we could call project.get() before using any other methods.
Removing the synchronous instantiation altogether will make it harder to test & mock.

Should we go with Project.get() and project.get()? I fear that might be confusing, as Project.get() would resolve with a project instance, and project.get() would resolve with with an object of project properties.
Maybe Project.getInstance() and project.getProperties()?

Should we go with Project.get() and project.get()? I fear that might be confusing, as Project.get() would resolve with a project instance, and project.get() would resolve with with an object of project properties.
Maybe Project.getInstance() and project.getProperties()?

Definitely agree, that Project.get() and project.get() would be too confusing. Project.getInstance() and project.getProperties are perfect! I have been referring to the latter as data, but properties seems clearer and wouldn't imply that it also included items.

Let me know if you plan on working on it. If not I can try to work on it myself, but can't make promises when I'll find the time right now

Let me know if you plan on working on it. If not I can try to work on it myself, but can't make promises when I'll find the time right now

Yes! I plan to, but I'm working through some higher priority items atm.


Check witchcraft family with dialyzer and fix all the warnings.

Why does it have to be done?
algae has dialyzer errors. For instance:
ElixirLS Dialyzer: Invalid type specification for function 'Elixir.Algae.Internal':call_type/2. The success typing is
          ({'defdata', _, [{'::', _, [any()]}, ...]}, _) ->
             {{'.', [], ['t' | {_, _, _}, ...]}, [], []}
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

There is no guarantee other libraries from witchcraft family don't.
How do you think does it have to be done?

[x] Walk the library family, library by library, and fix all the dialyzer warnings.
[x] Witchraft
[x] Algae
[x] Type_class
[x] Quark

What do you think needs to be figured out for it to be done?
No response

All of this (except for a trivial fix in operator library) is done in library-goo library family. For example:
Algae Goo


fix arrow detection

Codecov Report

Merging #111 into master will increase coverage by 0.18%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #111      +/-   ##
==========================================
+ Coverage   72.73%   72.92%   +0.18%
==========================================
  Files          39       39
  Lines        3206     3210       +4
  Branches       51       51
==========================================
+ Hits         2332     2341       +9
+ Misses        840      835       -5
  Partials       34       34

Impacted Files
Coverage Δ

src/tokentree/utils/TokenTreeCheckUtils.hx
51.26% <100%> (+0.26%)
:arrow_up:

src/tokentree/walk/WalkStatement.hx
89.62% <0%> (+1.85%)
:arrow_up:

Continue to review full report at Codecov.

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


Handle glyph with single point

Fixes #41

For some reason, the Travis CI results aren't showing up here, but it does pass.


Weekly auto releases

It may be a nice idea to cut a new pypi release every week if there are changes to the .textproto files.

Same could be done for gflanguages

I agree that we should release frequently. But I'd rather do it manually. I can add this to my weekly TO-DO list. Likely to be done on Thursdays prior to our weekly onboarding video call. Or even better, on Friday afternoons right after the call, so that there's a chance of collectively approving the update.

For instance, I think the recent "Wonky" axis name change discussed at #8 may be incorrect. So I may revert this before cutting a release. It seems reasonable to me that we humans should discuss these subtle things instead of delegating releases to automation bots ;-)


Сonfigure user authentication and authorization

Description
As a User, I would like to log in Taxopark application as either Admin or Dispatcher or Operator, so that I can perform actions appropriate for my role in the application.
As a User, I would like to log out from Taxopark application, so that I can log out of my account.
Acceptance Criteria

Administrator would like to:

create a new user account;
assign a user role to user account or change this assignment

Registered user would like to log in Taxopark application as either Admin or Dispatcher or Operator.
Registered user has ability to log out from Taxopark application.
Registered user cannot log in the application until he fills in the login form with valid data.

Hi Nataliia,
See my comments below:

AC1: User doesn't have ability to sign up in the system. The administrator can only create a new user account. This AC can be removed.
AC2: this AC can be removed as well because user doesn't have ability to sign up.
AC3: the administrator can:

create a new user account;
assign a user role to user account or change this assignment;

AC4: depends on his/here user role. The user role defines what set of functionality are available for this user.
AC5 and AC6 don't have sense because administrator creates a new user account and assign user role.

Let me know if you have any questions. Thank you
BR,
Roman

Hi Roman,

AC1, AC2 were removed.
AC3 became as AC1 and was changed according to your comment.
AC4 was changed according to your comment and split into two AC - AC2 and AC3.
AC5 was removed.
Description was changed according to new ACs.

AC4 was removed.
In AC2 words "would like" were changed to "has ability".
Stories related to this epic were added in the section "List of linked Stories".

Let me know if you have any questions. Thank you
BR,
Nataliia


Increase timeout for deleting RC in e2e tests.

Ref #7561
I wasn't able to reproduce the the timeout - for me it takes 2m30s - 3m30s. However, I'm increasing a limit with additional logging on how long did it take - we will be able to look into its results on Jenkins thanks to it.

LGTM
@gmarek - please merge.


Feat: Add missing metrics for Coingecko

Task split off from https://github.com/interlay/interbtc-ui/issues/1520
Implement missing metrics needed to provide data to Coingecko.
Coingecko requirements: https://docs.google.com/document/d/1v27QFoQq1SKT3Priq3aqPgB70Xd_PnDzbOCiuoCyixw

Closing this issue. No further work on Squid expected following the completion of interlay/interbtc-ui#1596


Command Buffer's primary buffer object isnt being reset in reset function

m_primaryCommandBuffer should be reset with everything else

Thanks for your help!


Publication citation and author list in project catalogue

[ ] Replace the Author list expandable link with a down arrow -  in Project Catalogue
At the moment, we have an arrow which we put temporarily, but is more like navigating externally, instead of allowing to collapse the info on authors
Can we use a drop arrow like these in the Visual Framework?
https://stable.visual-framework.dev/components/vf-link-list/#vf-link-list--easyist/

[x] Ensure no wranglers are listed as authors

[ ] If no publication is available, there should be a "pre-publication or citation missing" in place of the publication link

[x] If no publication available then use the contributor list to populate the author list

Removing wranglers from contributors is related to this PR. We can just use that script (after editing it) to update contributors. However, we need to fix the issue discussed there.

@gabsie I'm not really sure what you mean with the link list. You mean just to change the arrow to the same one there or something more?

We already use contributors to populate the list of authors not the authors of the publication

hi, @jacobwindsor
in this covid portal page, in the cross references tab, you can see how they use that down arrow.
for the Publication link, can we also use the external link icon they use, please?
let me know if questions..
https://www.covid19dataportal.org/sequences?crossReferencesOption=all
thanks!
Gabs


Can't launch Kitematic app after downloading (on Mac)

Hi...
I've been having this problem trying to download the last two releases (v0.10.1 and v0.10.2).
Has anyone had the same problem? Or would anyone know what the problem might be?
I've tried had the same problem on two different computers.
Expected behavior
Double-click Kitematic (Beta).app launches Kitematic application
Actual behavior
Error message: “Kitematic (Beta).app” is damaged and can’t be opened. You should move it to the Trash.
Information about the Issue

Steps to reproduce the behavior

Download:
https://github.com/docker/kitematic/releases/download/v0.10.2/Kitematic-0.10.2-Mac.zip

Unzip

Double-click Kitematic (Beta).app

If you put Kitematic (Beta) in your applications folder, can you try opening a terminal, and running;
xattr -rc /Applications/Kitematic\ \(Beta\).app

That solved it for me
ping @FrenchBen ^^ same issue I ran into on one computer

That did the trick! Thanks a lot!

For clarity:
-r: act recursively
-c: deletes (clears) all xattrs

Seems like some invalid xattrs were added along the way.

That should be perfectly fine in this case but you might want to limit the command to target nothing but the quarantine setting running xattr:
xattr -rc com.apple.quarantine /Applications/Kitematic\ (Beta).app

Any idea why this is happening?  I'm not sure the issue should be closed as it is still doing this out of the box on my (fully up to date) Mac.  I've never seen this with any other app, including ones downloaded from the Internet.
Typically Mac apps are distributed on .dmg files rather than in .zip files; I wonder if this is why there are problems.

The application triggers the security system in OS X that is there to protect your computer from trojans. It happens because the application is not wrapped with a certificate that can testify the institution of the author.

I think there may be something more subtle going on... I have installed unsigned apps before on OS X, and the security warning is quite different; here's an example:

This article on the Apple website suggests that the Kitematic app is signed, but is somehow later being modified, which invalidates the signature and causes the "app is damaged" dialog.  That's why I suspected it had something to do with the zip file distribution:
https://support.apple.com/en-us/HT202491

unzipping with Keka I've never had this issue - Can you download the latest release and see if the issue is still happening?
https://github.com/docker/kitematic/releases/tag/v0.10.4

The release you linked seems to be OK.  Thanks!

You can not compare how an installer handle such event compared to what happens if you download an executable binary and try to execute it.
The quarantine flag is only set by quarantine-aware programs so I would not recommend anyone to use programs like that. It's better to get the trap and lift it with the command, because then you've got the heads-up.

I'm still getting an error. It's reported as:
Application Specific Information:
dyld: launch, loading dependent libraries
Dyld Error Message:
Library not loaded: @rpath/Electron Framework.framework/Electron Framework
Referenced from: /Users/USER/Downloads/Kitematic (Beta).app/Contents/MacOS/Electron
Reason: image not found

The linked release, along with 10.0.5 both throw that same "Damaged and cant be opened error for me". I don't think this was resolved. The workaround posted above
xattr -rc /Applications/Kitematic\ \(Beta\).app
Did however

The Docker for Mac Beta still exhibits the quarantine problem. If you don't have Kitematic installed, it propts with a link to download
45562719 Kitematic-Mac.zip
# shasum -a 256
161d702e25cfda4337c5f9b1315ad1487b287cd581e8951caee7ff529595370c  Kitematic-Mac.zip

I agree, this issue should not be closed as I ran on the same problem today.

I also had this issue, and @thaJeztah 's xattr deletion solved it for me.

+1 still having this issue with the version of Kitematic that the latest Docker for Mac downloads. The xattr workaround was needed to move forward.

Having this issue too

For those having the issue, can you provide a few details:

OSX version
Disk encryption
AntiVirus installed
Proxy/VPN

OSX 10.10.5
No
No
No
On Thu, Jun 30, 2016 at 6:06 PM, French Ben<EMAIL_ADDRESS>wrote:

For those having the issue, can you provide a few details:

OSX version
Disk encryption
AntiVirus installed
Proxy/VPN

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/docker/kitematic/issues/1637#issuecomment-229829806,
or mute the thread
https://github.com/notifications/unsubscribe/ACEnUdcGknOaZAr07qr-8SmwFgkemtVgks5qRGgLgaJpZM4IJBhl
.

OSX version - 10.11.3
Disk encryption - Yes, FileVault
AntiVirus installed - McAfee Endpoint Protection 2.3.0 (1791)
Proxy/VPN - GlobalProtect 2.3.3-5 (it was not enabled at the time)

NOTE: I had to run the xattr command twice:

When initially trying to launch Kitematic from the Applications folder
When trying to use the "Open Kitematic" menu item from Docker for Mac.

We are still having this issue.  The workaround above and the one presented here:
https://forums.docker.com/t/kitematic-mac-download-corrupt/9256/4
Allow it to work

OSX version 10:11:3
No
No
No

I just had this happen to me, the attribute fix above solved the problem. But the issue seems to still be occurring.

To put things in perspective, this isn't just a Kitematic issue, as it's been seen in other apps:
http://apple.stackexchange.com/a/215372
The built-in Archiver utility is usually the culprit - I've never had this pop-up when using something like Keka

@FrenchBen I would not really recommend using that setting. Would it be possible to ship Kitematic as a .dmg? It's more "native", and would work around the issue with archiver

@thaJeztah The reason it's not a DMG is due to the current Packaging with Docker Toolbox.
With the release of Docker for Mac/Windows there may be a need to create an actual installer though for all versions.

The app is signed
$ codesign -dv /Applications/Kitematic\ \(Beta\).app
Executable=/Applications/Kitematic (Beta).app/Contents/MacOS/Electron
Identifier=com.electron.kitematic_(beta)
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=233 flags=0x0(none) hashes=3+4 location=embedded
Signature size=8907
Timestamp=Jun 13, 2016, 23:40:33
Info.plist entries=20
TeamIdentifier=9BNSXJN65R
Sealed Resources version=2 rules=12 files=11
Internal requirements count=1 size=192

I would recommend putting in a .dmg and delivering it over https and see if the problem goes away. I am wagering it will.

OSX version: 10.11.3
Disk encryption: Yes
AntiVirus installed: No
Proxy/VPN: No

it works!


Workspace disable extensions

How to disable some extensions in some Workspace by config file in .vscode ?
im my case，I have installed many extensions，and some of them may cause conflict，I want to disable some extensions in some peoject。

AFAIK it is not possible to do this with config files in .vscode. But the Settings Profiles feature which arrived as a preview in 1.69 may help you.
Alternatively you can disable individual extensions only for the current workspace. But be aware that these settings are stored locally and not in the workspace itself, so when another person clones the workspace from Git they won't get your settings about which extensions should be enabled.

Effectively duplicate of #18386.
As mentioned above - Settings Profiles will be closes feature to control this with files.

/duplicate

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!


Use "k8s-app=kube-controller-manager" instead of "k8s-app=kube-controller"

Some tools such as Prometheus Operator rely on k8s-app labels values.
k8s-app=kube-controller-manager label is used at least by bootkube, kops and as far as @brancz can tell the manifests in kubernetes/kubernetes.
I suggest to switch to using k8s-app=kube-controller-manager label.
/cc: @brancz

I just opened an issue on standardizing this as this is not the first time a tool as slightly inconsistent about this.
For the reference: https://github.com/kubernetes/kubernetes/issues/42887

@brancz Do you think you can switch on using the labels format proposed on https://github.com/kubernetes/community/issues/300 in prom-controller and validate it as a long term/official label.
Then we can sync with community (kops/bootkube) to perform the switch.

Any update on this? kops seems to use k8s-app: kube-controller-manager as well.
It would be good to standardize on these labels.

Keep in mind how these changes affects upgrade of existing Kubespray installations. A similar change of labels and names was done for kube-dns in #1372 which broke upgrades.

The issue with kube-dns was related to changing the resource name. This is just a label and should be harmless


fix(apps/prod/tekton/configs/pipelines): use checkout result as commit sha to downstream tasks

Signed-off-by: wuhuizuo<EMAIL_ADDRESS>

/approve


BUGFIX - Apply missing documentation updates

Looks like the last merged PR was missing some documentation.  These changes were generated by pulling down upstream master, running rake generate_cops_documentation, and committing the diff.

Before submitting the PR make sure the following are checked:

[x] Wrote good commit messages.
[ ] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Used the same coding conventions as the rest of the project.
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[ ] Added tests.
[ ] Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
[x] All tests(rake spec) are passing.
[x] The new code doesn't generate RuboCop offenses that are checked by rake internal_investigation.
[x] The PR relates to only one subject with a clear title
and description in grammatically correct, complete sentences.
[x] Updated cop documentation with rake generate_cops_documentation (required only when you've added a new cop or changed the configuration/documentation of an existing cop).

Ah, this has been an issue with every older PR recently.

I guess I should start paying those closer attention. Thanks!


Tabs:  Disabled behavior

It would be nice to be able to mark a tab as disabled
Example would be a registration page using tabbed navigation where you need to restrict later sections until requirements/forms on earlier sections are completed.

Added in 9cbedf1c766cfac9f410c08be4291c7a16717f0c


feat(config): add Shelly Wave 1, Wave 2PM, update Wave 1PM association labels

fix: Wave 1 added zwavealliance id
feat: config new device Wave 2PM
fix: Wave 1PM association text

Thank you I will review the recommendations you're pointing out. Will add a new device next week.


State store: make BulkSet/BulkDelete not transactional

This is a follow-up from #6186 that addresses the requested change of making BulkSet/BulkDelete operations in state stores not use transactions, and instead revert to perform operations one-by-one.
It is needed also to make sure that the correct HTTP status codes are returned to users when state operations fail with etag errors in bulk operations, per: https://github.com/dapr/dapr/pull/6186#issuecomment-1539262923 (which is currently a P0 blocker  for #6301 )
The main concern behind changing to using transactions in #6186 was that the previous way of running bulk operations did not play well with resiliency. For example, assume that the user wanted to set 3 keys: A, B, and C; all of them have an etag. Previously, operations were executed in sequence and errors would have caused to abort the sequence. If, for example, B failed with an etag error and resiliency was enabled, Dapr would have retried all operations, including A which would have now failed with an etag failure (because A was updated).
This PR changes how the bulk operations are performed:

Operations are now performed in parallel and not in sequence. There is support for limiting concurrency, although that's not exposed to end users right now as it requires changes to user-facing APIs which I thought not appropriate this late in the endgame. However, exposing this should be relatively easy.
When an operation fails, resiliency will retry only failed operations that are retriable. Operations that fail because of an etag error are not retried.

It fixes the error reported in https://github.com/dapr/dapr/pull/6186#issuecomment-1539262923 so the correct status codes are returned. New (unit) tests have been added to make sure that status codes will not change again, even for bulk operations, for both HTTP and GRPC.
Changes are to both bulk set and bulk delete operations.
Future plans
There are a few things that are not included in this PR which could (should?) be done in the future:

When a bulk set/delete operation fails, we should probably return details on what operation failed specifically. Right now we just return an internal error if at least one operation failed with any error that's not an etag error. Otherwise, we return a conflict error if at least one operation failed with an etag error. However, users have no way to know which operation failed.
It also occurred to me that Dapr doesn't implement a Bulk Delete API in HTTP. It does exist in GRPC, but not in HTTP.
As mentioned, bulk set operations at the moment are all executed in parallel. The internal APIs have an option to limit concurrency, but that's not exposed to end users at the moment.

Added E2E tests (had to be created ex-novo because there were no E2E tests for state store etags). PR should be ready.
Contrib PR will need to be merged before this however.

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

Sorry I pushed a bad contrib tag. I will repush as rc4 and update this PR

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

/test-sdk-all

/ok-to-perf

/ok-to-test

/ok-to-perf

/test-sdk-all

SDK tests are still expected to fail until the updated workflows are merged into master.
I have confirmed the Python SDK examples pass on my machine against this PR.

/ok-to-test

/test-sdk-all

/ok-to-test


form opened when input is invalid

flow extremely change. this feature is not to be required anymore.


Release/0.8.1

Codecov Report

Merging #205 (0a240c9) into main (1904018) will not change coverage.
The diff coverage is 100.00%.

:exclamation: Current head 0a240c9 differs from pull request most recent head e3c147a. Consider uploading reports for the commit e3c147a to get more accurate results

@@            Coverage Diff            @@
##              main      #205   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           41        41
  Lines         1203      1236   +33
=========================================
+ Hits          1203      1236   +33

Impacted Files
Coverage Δ

pfhedge/stochastic/heston.py
100.00% <ø> (ø)

pfhedge/features/_getter.py
100.00% <100.00%> (ø)

pfhedge/features/features.py
100.00% <100.00%> (ø)

pfhedge/features/functional.py
100.00% <100.00%> (ø)

pfhedge/instruments/base.py
100.00% <100.00%> (ø)

pfhedge/instruments/derivative/american_binary.py
100.00% <100.00%> (ø)

pfhedge/instruments/derivative/base.py
100.00% <100.00%> (ø)

pfhedge/instruments/derivative/european.py
100.00% <100.00%> (ø)

pfhedge/instruments/derivative/european_binary.py
100.00% <100.00%> (ø)

pfhedge/instruments/derivative/lookback.py
100.00% <100.00%> (ø)

... and 14 more

Continue to review full report at Codecov.

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


Add support for go 1.7 with backward compat

The build failures are unrelated to the go1.7 changes. Looks like there was a breaking change in the prometheus client: https://github.com/prometheus/client_golang/releases/tag/v0.8.0.
Otherwise, the tests related to the go1.7 changes are passing for both 1.5 and 1.7 in CI. I believe I've made the changes in the same way you did for the other x libs.


--extract-env flag for ng build

🚀 Feature request
Command (mark with an x)

new
build
[ ] serve
[ ] test
[ ] e2e
[ ] generate
[ ] add
[ ] update
[ ] lint
[ ] xi18n
[ ] run
[ ] config
[ ] help
[ ] version
[ ] doc

Description
Environment.ts files are useful. In my workflow I use a few of them (dev, test, pre-prod, prod). But recently the client requested some changes in environment file after the app was set to production. Also he wanted to have full control over the environment file for potential future changes. So the solution I came up with was not new : I've created a json file, added it to assets, and tied all the properties in the environment.ts file to that json file via http call at the start of the app.
The whole process is trivial, but cumbersome
Describe the solution you'd like
So what I propose is to add a flag for ng build or ng new, something like --extract-env, which would do exactly that: extract the environment.prod.ts file as a json file where I could make all the changes I wanted after building the app for production, like changing api endpoints, regexes etc.
Describe alternatives you've considered
Again, the alternative I'm going with right now is I create a special service for this operation, create a json file and add it to assets, create a special "init" function (APP_INITIALIZER) that fires before the app launches, makes an http call to that json file in assets and ties all the properties there to the environment.ts file.

The environments file should be kept for pre-build flags and should not be mixed with run-time configuration that you might want to change after the build.
In our projects we've added the "post build" environment specific configuration to a JS file that that defines a global "APP_ENVIRONMENT_CONFIGURATION" variable defined as readonly in the coresponding app-environment-configuration.d.ts. And this file is loaded using a simple <script src="/environment/configuration.js"></script> added to index.html.
And to further improve this, we've also renamed the old environment.production" flag to "ENVIRONMENT.devMode". This way we avoid the confusion between the app specific "production" configuration defined in  angular.jsonand the production flag verified when callingenableProdMode()` and it's using SNAKE_CASE, since it's a constant.

Hi @rip222, as @SchnWalter, mentioned those options shouldn't be part of the build environments file, but have a runtime configuration.
In the above mentioned issue, there are some good approaches, example: https://github.com/angular/angular-cli/issues/7506#issuecomment-324981817


[Feature] - Add logs from transaction and scripts

Issue To Be Solved
Since logs calls are not preserved on blockchain they are excluded from Access API, but they are crucial for debugging, testing and development process.
Suggest A Solution

Call for transaction result shall have Logs field
Script execution result shall have Logs field

Context
Testing library is trying to extract and parse log statement from stdout stream, which is subpar and prone to errors.

I think this is a good idea. @MaxStalker do you need more help with implementing that PR? I can help you on it.

Sure thing! :)
There was some issue with tests in #224.
If you can help me figure out what's happening there - then we can enable this feature right away 😁

@MaxStalker you need to make another endpoint and call it like ExecuteScriptWithLog I guess

I think we could also take a different approach, by having multiple streams for logs, and so, you could add a stream for log that would be a JSON which can then be served by an API. I think the fact the logs don't indicate which transaction they are from is a problem we need to solve also when showing logs on stdout. I don't think we need to add a special way of storing logs in a different structure to serve them.

@sideninja how one would connect to those?
If I am building my toolkit around CLI, for example. 🤔

If I am building my toolkit around CLI, for example. 🤔

Do you mean you are writing a program that executes CLI commands (I'm guessing not in Go)?
In that case you would just access the logs via an API on the emulator. In any case you need an emulator right?

For transaction distinctions - logs can have txHash as one of the fields

Exactly.

scripts doesn't expose this (even though on the inside they have one)

we can add an identifier of the script as well as the location to the logs (on the first thought, would have to look into the code a bit to see).
I can help you work on this part no worries.

I think getting logs of transaction ( as we have them in storage ) via API by tx id is pretty good. ( as sender knows the txid ), maybe we can make it not only logs but we can add there some other info ( like detailed gas usage ). So I propose GetTransactionResult(txid)
Getting script logs, I think better managed with something like, GetLastExecutedScriptResult() API call.
Streaming log is good in one sense, but then later people depending on logs ( and their structure ) in other applications scare me little.

So I propose GetTransactionResult(txid)

This is the perfect solution. We should append logs to the result.

GetLastExecutedScriptResult() API call

This one I don't like as much. It would be nice to be deterministic too and look more similar to the above function but for scripts. We should look into getting the script IDs, I remember they are used.

For first one problem is access api spec doesn’t have logs, so it has to be another endpoint. But not a bug deal.
Second one is more tricky, as script id is just hash of script code, if you run same script twice it has same id.

For first one problem is access api spec doesn’t have logs, so it has to be another endpoint

Yeah I mean as part of another endpoint.

if you run the same script twice it has the same id.

Right. We could include block but then the issue is knowing which it was. Hmm

@MaxStalker do you still need this feature?

@sideninja if there is no better solution now - yap :)
It would be so much better to simply read it from some endpoint or results than building elaborate solution to extract them from logs...

I believe this work is related https://github.com/onflow/flow-emulator/pull/351 and can be used for this.


Debugging panel disables the Run button if Q# program throws exception

Describe the bug
If I get an exception in the output to debug console (for example, qubits released not in zero state), the debugging panel pops up, and the run button doesn't work any longer. At the same time, the debugging panel is not really visible (it's placed over the tabs with different files, so it blends in really well). This can make rerunning the code after fixing the bug very confusing.
Expected behavior
Keep the run button enabled in addition to the debugging panel. I don't think there's any state of the program the debugging tool captures at this point that needs to be preserved (debugging the program needs to start from scratch). And I can often fix the exception without going through debugging, so making the panel mandatory is not necessary.
System information

QDK 1.0.33
Ubuntu

Seems reasonable that when running without debugging, we shouldn't end up in a debug session if an error occurs (but running under the debugger should).


Installing instructions

Could you add recommended installing instructions?
python setup.py install ?
Really nice GUI btw!

Thanks! Yes, you can just install using python setup.py install or pip install -e .. I have added some instructions to the readme.


Merge multiple exercise data in different language codes.

This fixes the merge of exercise data in the different language codes.

@cpauya I tested this pr with swahili content pack and it's working.

Thanks @mrpau-richard!  Merging this now then we can build on Dungeon.


duplicate value for resource 'attr/placeholder' with config ''.

Hey!
I get this error at compile time:

/Users/myUser/.gradle/caches/transforms-2/files-2.1/a4437a932490e83b8af1eb320ceab6c6/jetified-formatt-edit-text-0.7/res/values/values.xml:5:5-143: AAPT: error: duplicate value for resource 'attr/placeholder' with config ''.

Maybe conflicting modules or incorrect gradle configuration.


Flowbroker was broken

A flow with a geo node was created. If a data is published to the device without the geo attribute, the flowbroker breaks.
log flowbroker:

[ingestor] got new device event: { metadata: { deviceid: '7db27e', tenant: 'admin', timestamp:<PHONE_NUMBER>573 },
attrs: { int: 60 } }
[executor] will handle node geofence
debug: Executing geo node...
debug: ... geo node was not successfully executed.
error: Message has no geographic position attached.
[executor] Node execution failed. Error: Message has no geographic position attached. Aborting flow 7619b591-b718-4d92-9c8c-362ae2f02c00.
events.js:183
throw er; // Unhandled 'error' event
^
TypeError: Cannot read property 'hasOwnProperty' of null
at /opt/flowbroker/orchestrator/node_modules/geolib/dist/geolib.js:119:34
at Array.every ()
at getKey (/opt/flowbroker/orchestrator/node_modules/geolib/dist/geolib.js:114:32)
at Geolib.getKeys (/opt/flowbroker/orchestrator/node_modules/geolib/dist/geolib.js:126:29)
at Geolib.getLon (/opt/flowbroker/orchestrator/node_modules/geolib/dist/geolib.js:159:101)
at Geolib.longitude (/opt/flowbroker/orchestrator/node_modules/geolib/dist/geolib.js:164:32)
at Geolib.isPointInside (/opt/flowbroker/orchestrator/node_modules/geolib/dist/geolib.js:632:60)
at DataHandler.handleMessage (/opt/flowbroker/orchestrator/src/nodes/geo/index.js:86:28)
at Executor.hop (/opt/flowbroker/orchestrator/src/executor.js:49:21)
at channel.consume (/opt/flowbroker/orchestrator/src/amqp.js:106:9)
at Channel.BaseChannel.dispatchMessage (/opt/flowbroker/orchestrator/node_modules/amqplib/lib/channel.js:466:12)
at Channel.BaseChannel.handleDelivery (/opt/flowbroker/orchestrator/node_modules/amqplib/lib/channel.js:475:15)
at emitOne (events.js:116:13)
at Channel.emit (events.js:211:7)
at /opt/flowbroker/orchestrator/node_modules/amqplib/lib/channel.js:263:10
at Channel.content [as handleMessage] (/opt/flowbroker/orchestrator/node_modules/amqplib/lib/channel.js:316:9)

Affected Version: 0.3.0-nightly_20180912

Test OK.

[ingestor] got new device event: { metadata: { deviceid: '97d9bb', tenant: 'admin', timestamp:<PHONE_NUMBER>995 },
attrs: { int: 8 } }
[executor] will handle node geofence
[executor] will handle node geofence
[executor] will handle node switch
[executor] hop (switch) result: [null,{"payload":{"int":8}}]
debug: Executing geo node...
debug: ... geo node was not successfully executed.
error: Message has no geographic position attached.
[executor] Node execution failed. Error: Message has no geographic position attached. Aborting flow 6a9b969d-1f66-422e-a39c-ca709b5315be.
debug: Executing geo node...
debug: ... geo node was not successfully executed.
error: Message has no geographic position attached.
[executor] Node execution failed. Error: Message has no geographic position attached. Aborting flow 6a9b969d-1f66-422e-a39c-ca709b5315be.
debug: Executing switch node...


LRC-6 (Block Reward Interim Restructure)

Continuing on the lengthy discussion in #10, Pulse (PoS) will require a restrucutre of the Loki block reward system.
The Loki Foundation is set up to ensure the continued development of the Loki project, including Session, Lokinet, and the Loki blockchain. It is a registered charity in Australia, and its members are comprised of trusted community members and prominent individuals in the decentralised technology space (see https://loki.foundation/about-loki-foundation/).
Over the last two years, we’ve committed to being as transparent, productive and pragmatic as possible. I believe that the majority of the Loki community sees this, and understands that running Loki at this scale and speed is a costly exercise. With almost 30 full time staff, Loki is a substantial operation, achieving incredible results in delivering truly private secure communications and transaction tools, and educating the public on the importance of privacy and the benefits of using our free, open source technology.
The Loki Foundation is looking to the future, and we believe that in order to improve our likelihood of medium to long term success, we need to propose a change the the block reward structure to allow the foundation to retain its ability to raise more funds. The Foundation can easily sustain itself with its current liquid assets for over 2 years, and the Loki it currently has can be sold in a private investor round to significantly extend the runway, but without that being replenished over a reasonable amount of time, it is going to be more difficult in the following years for the Foundation to sustain itself off grants and donations alone, even with a very large user base.
Further to this, the miners of Loki are sucking up a large percentage of the block reward whilst providing very little security (due to checkpointing). With Pulse (PoS) on the horizon, it makes sense to me that we should cut down the miners rewards while we’re here as well.
In LRC 3, I proposed to drop the overall block reward to 20 Loki per block, and have a 95/5% split between SNs and LF once miners are out of the picture.
Today I wish to present an idea which has been debated by the LF board. In summary, the board is presenting:
At the upcoming fork in approximately 4 weeks, we change the block reward to 25.00 down from 28.00 (just a fixed amount, no longer dropping over time), with block reward allocations of:

66% for Service Nodes
10% for Loki Foundation
24% for Mining

At the fork that implements Pulse (which will likely be the following one), we switch to block rewards of 21.00 with allocations of:

90% for Service Nodes
10% for Loki Foundation

which will then be fixed indefinitely (i.e. forever, or until a future SN vote to change them). This means that for each of these two changes, the SNs receive an additional 2.25 and 2.4 Loki per block respectively. Increasing the final reward from 20 to 21 per block will allow the previous modelling around Service Node rewards in LRC-3 to remain in tact if a 10% LF reward is agreed upon and implemented.
Changes like this are not to be taken lightly so we would love to hear the thoughts of the community before moving ahead. This does somewhat change the social contract around the Loki ecosystem, although the community has come to a consensus on sensible changes to the block reward before, so I remain hopeful that this is something users, stakers, and supporters of Loki can get behind.
NOTE: This topic is seperate to #18 - I think some points have been raised there that may require some creative thinking and design in regards to exit incentivisiation, so I would encourage those interested in that particular issue to participate in that discussion there.

Would it be possible to take a portion of the 90 percent and dedicate it to exit nodes?
For example if 80 percent go to all of the super nodes.. but then 10 percent gets rotateed every block to exit nodes incentivizing service nodes to want to be an exit node.. while also retaining 90 percent toward service nodes.
For example roughly using a small number for
If you have 1000 service nodes  and 300 of them are exit nodes.
Then 1000 share the 80 percent of emission and the other 10 percent goes to the 300 exit nodes  and the foundation gets 10 percent.
This will create incentive to run an exit node where there isnt one at no extra cost.

Can you provide the community with some figures that substantiate your claim? Some questions that will help alleviate some concerns are:

How much Loki does the foundation currently have?
Considering the current expenditure rate, what must the price of Loki be to sustain the foundation based on the existing 5% reward.

If the 10% figure was derived from the current Loki price then an assumption is made that Loki at double the price will be enough to sustain the foundation at 5% block reward.
With over 2 years worth of seed funding plus the $loki the foundation currently own, the chances are very high that Loki will achieve the price needed to attain sustainability when those funds are due to expire. I understand that is speculation but considering the scope of what Session and the other products aim to achieve, I believe this to be a fair assumption to make.
I propose that this block reward increase is premature based on the amount of reserve funds and what can be achieved during that time. I believe implementing this increase introduces the potential for the foundation excessively funded.

I'm fine with the short term proposal. wrt the secondary Pulse implementation split I'd like to see more analysis on exits and any other potential requirements for node specialization that may require a different reward model prior to finalizing this aspect.

It's also important to consider that the implementation of Pulse will significantly increase the rewards the foundation receive from the service nodes they operate, which is always close to 10% of all service nodes on the network. In essence the foundation will receive close to 19% of the block reward after the implementation of pulse.

I agree with @necro-nemesis

It's also important to consider that the implementation of Pulse will significantly increase the rewards the foundation receive from the service nodes they operate, which is always close to 10% of all service nodes on the network. In essence the foundation will receive close to 19% of the block reward after the implementation of pulse.

It's worth noting that the foundation has never hit the 10% self-imposed network limit to date. And with the ambitions of future funding rounds and the continual growth of the network, it may be some time until it does.

PoW becomes redundant with checkpointing, and Pulse cannot arrive too soon. Why drop to 24%? Why not drop to 5%, or even 1%, or some other arbitrarily low value right now and start mimic'ing Pulse? All mining does right now is consume electricity and sell pressure on the market, most from Chinese datacenters with virtually no running costs. Long are the days of altruistic or HOLD mining. The intention here is to create more favourable market conditions, so lets not be shy about this.
Regarding Foundation funds, given the current Loki team track record for transparency, diligence, and accountability, I have no issues with 10%, even if spot price quadruples. The Foundation is not so public facing in daily ops as the core Loki team, but of course they go hand in hand. A healthy cashflow flow will benefit all Loki holders with a solid Foundation that doesn't suffer from funding anxiety.
Finally, and as mentioned by others, exit nodes need some thought, however since there are more unknowns than certainties at this point, regarding specs and ISP acceptance, I think we should debate this when we get there. % for exist would come out of global SN fee IMHO

I would be okay with temporarily increasing the foundation percentage to 15% or 20% and reducing the mining reward by a larger amount as long as it goes back down to 10% at the hardfork that implements pulse.

I like it.  I think with all the development going on with the various platforms it's time the LF gets a boost like this.  I think 10% of the block reward is more than fair.

I strongly disagree with raising the reward for the foundation. For a start, the foundation already run service nodes with the Loki that they already have. @Prophet-26 suggested they own close to 10% of the current service nodes - This means even under a 95/5% split proposal for Pulse they would earn 9.5% more rewards on top of the 5% governance which they are already getting.
They have enough runway for two years without evening touching their Loki stack (private sale to investors). After those two years they'll have even more Loki than they have now (5% governance + service node payments) and they should have been working on increasing the scope and success of Loki (e.g. the value of that Loki they are holding will have gone up).
Asking for another 5% block reward on top of getting almost 15% is at best completely unncessary at this moment in time (they have two years runway still) and at worst looks like a complete cash grab.
FWIW - I've been in Loki since the private sale, run a small number of service nodes and was made a "Community God" back in the early days of the project.

The Foundation is required by law to act on the best interest of the project.
Without the development team, all of our investments will be worth next to nothing. Although two years of runway seems like a lot, not many want to invest in a project that is on life support with it's funds running low.  I think making this move now will put Loki in a position of strength moving forward with any future potential investors.

What's the difference between 2 years of run way and having 10% Loki per block (+ however much from service nodes) or 2 years of run way and having 5% per block (+ however much from service nodes)?
If service nodes are already providing the foundation with roughly another 10% of each block (as they own 10% of all nodes and the reward will change towards 95/5 split) then the difference between the foundation getting 15% or 20% of each block is 33%. You think that the this extra 33% more Loki they'll get will be the difference between the project dying or not in the future? I think if they'd run out of money at 5% reward, then they'll run out of money at 10% reward.
Not to mention the fact that a lot of other crypto projects would be flabergasted at the fact that an organisation is taking 15% of their block reward already, we now want to increase it to near 20%.
You say the foundation should act in the best interest of the project. So how about we demand from them an economic proposal / writeup that categorically shows that this increase in block reward is necessary rather than just allow them to take it for fear of rocking the boat.

What's the difference between 2 years of run way and having 10% Loki per block (+ however much from service nodes) or 2 years of run way and having 5% per block (+ however much from service nodes)?

Good Question. More details would be good to have.

If service nodes are already providing the foundation with roughly another 10% of each block (as they own 10% of all nodes and the reward will change towards 95/5 split) then the difference between the foundation getting 15% or 20% of each block is 33%. You think that the this extra 33% more Loki they'll get will be the difference between the project dying or not in the future? I think if they'd run out of money at 5% reward, then they'll run out of money at 10% reward.

The extra 33% could make the difference between getting a large investor or not. Impossible to know, one way, or the other.

Not to mention the fact that a lot of other crypto projects would be flabergasted at the fact that an organisation is taking 15% of their block reward already, we now want to increase it to near 20%.

Some projects raised 30-100 million but have no dev fee, this one raised 9 million and will have one. Not sure we should care what other Crypto projects/organizations think about the way the project was funded.

You say the foundation should act in the best interest of the project. So how about we demand from them an economic proposal / writeup that categorically shows that this increase in block reward is necessary rather than just allow them to take it for fear of rocking the boat.

The Foundation is Required (by AU Law )to act in the best interest of the Loki Project. I agree a more detailed write up about what the difference in the fee structure will provide would be beneficial to the discussion.
--Nothing that I have seen in my 2 years of following this projects makes me feel like this is a cash grab. The team has proven ethical and dedicated to producing their vision, this request doesn't change my view.

exit nodes need some thought

See LRC-5 for some discussion on that.  @necro-nemesis is pushing for (and I agree with) a market-based approach rather than a block reward approach to funding exits.

Decreased emissions benefits every holder.
Increased Service Node reward from ~14 to ~16 per block.
Increased Foundation funding.
Decreased miner reward as they are not contributing much now that checkpointing has been implemented.
Looks like everyone wins except miners who are leaving soon anyway.
I would also like to quote Kraig from Telegram "Without the LF and the team, this project would be worth didlely squat. I don't think the community squabbling over 5% is worth it. I would rather the LF have it then miners.."

I generally agree with the proposal.
I particularly like the reduced emission to miners. This should drive the price upwards and reduce everyone's fears for a while.
Some other ideas, Selling on the open market drives price down. If the LF is selling to VC to raise money off the market, then I completely agree to the proposal. If the LF is selling on the market, it will drive the price down.  If the project is strong then this is not a problem and the market will absorb the tokens, if the market is weak, this will continue to drive the market into a failure spiral. No funds and low price means the LF has to sell more LOKI to make the monthly rent, continuing to drive down the price.
If the LF sells the increased LOKI immediately, the market will absorb the coins and the foundation could build a reserve of funding outside of LOKI and even crypto. They could begin to purchase other assets, like cash, stock, or their building, in an effort to reduce future expenses and potential reducing the market.
To completely agree with the proposal, I would like the LF to announce how they plan on spending the increased reward. I would much prefer selling on the open market immediately, or reserving the reward for VC then just saving the reward for a rainy day. If you spending LOKI after the coin shows signs of weakness, you are further destroying the remaining value of the project.

I would not change the block reward twice, as we have so many moving parameters that drive the earnings for a node.
Total No. of nodes, What happens to other nodes like Deregs, Decomm, IP changes, Loki's price in USD... and changing % for block split. So suggest to reduce the block rewards 25 Loki right away without any curve and keep it at 25.00.
My Suggestion is
At the upcoming fork in approximately 4 weeks, change the block reward to 25.00:
70% for Service Nodes
10% for Loki Foundation
20% for Mining* + Txn Fees (As aim is to remove mining off the next fork anyways)

Miners also get Txn fees right now, so dropping another 4% would give a bit more for the node ops and drive up our node count even more. We should be 50% lock-up with higher rewards.

At the fork that implements Pulse keep block reward as 25.00 **:
80% for Service Nodes + Txn Fees
10% for Loki Foundation
10% Build Bucket of Funds to support launch of Exits or other SNApps
At fork when Exits go Live
90% Shared by Service Nodes / Exits + Txn Fees
10% for Loki Foundation
** Do not change the emission as we'll need enough Loki in the blocks to keep for Exit Nodes or some other major launch. Also that 10% from Pulse launch onwards, would help build some funds to support exits launch. This 10% fund should not be used by LF, but given out as initial incentives for Exits in a decentralized & objective way and a portion could also be spent on marketing, exchange deposits etc, to sync with when we go live with exits.

Is the LF currently maximizing the Loki rewards at their disposal right now?
It’s mentioned above that the LF isn’t at the 10% limit right now.  Why not?
The LF could, and IMO should operate this bank of Loki responsibly and maximize their returns utilizing every opportunity before asking for more.
My suggestion is:

Always operate max nodes (10%)
Open partial nodes at market value fees (as the market allows, full nodes if this doesn’t work) to capture more rewards
Unlock monthly and capture the “extra” from decreasing requirements

Maximize the rewards before asking for more.
If there’s a reason this isn’t happening, or this is already happening, then I fully support 10% going to the LF before some miners.
But I would like an expiration on the 10%.  How about 4 hard forks then it’s mandatory 5%?

I've already posted above but I just want to mention something else that I remember someone saying a couple of months ago that I think has relevance here.
For most cryptocurrency projects it is difficult to change the emissions schedule because the most important thing is the social contract because the goal is to get people using the Cryptocurrency as money.
However, for Loki while the social contract is still important the health and usage of the network is more important. The value of loki comes from the network and the premium service.
I personally think keeping the network healthy means keeping it decentralised, not screwing over the operators that run the network and making sure the foundation has enough funding to continue development at a pace that continues to provide value.

I can't support the proposal. First my disclaimer: I am both a miner and staker of Loki, though I get most of my rewards from staking.
For the short term issue of bumping foundation rewards to 10% from 5% (which BTW you should make more clear in the proposal), you should provide a more detailed financial breakdown of the foundation. For example clearly you have a lot of Loki coins from the premine and ongoing block rewards which are presumably being staked. How exactly is that doing, and why isn't it enough? I might be open to the proposal but not without a lot more detail.
Regarding the longer term proposal of completely abandoning PoW, I don't feel PoS has been sufficiently proven out in practice. I see Loki's choice of roughly 50/50 split between PoW and PoS as a safe and pragmatic choice it shouldn't abandon in the near future. Let some other big coin demonstrate that pure PoS is a safe choice (such as Ethereum). Until then, Loki shouldn't be the trailblazer. Too much risk for a coin that's ostensibly about providing privacy-preserving services to the masses.

Sorry for the delay in response, I was offline over the weekend (probably not going to drop an LRC 12 hours before I go out of phone range again haha)
To clear up the details of why we're proposing an increase from 10% from 5%, the maths say that if we sell all of our current holdings at the end of the year in our planned second VC round, it will take years to build up enough funds from the governance reward to be able to continue staking at a decent level again. If we are granted 10% by the network, we will be able to re-stake much more quickly (as the effect is compounding) and prepare for future rounds.
There are no absolute figures here, as the ability for us to raise enough funds to justify selling any Loki at all is price dependent. I have no attitude to sell any Loki to anyone at a price below 1 USD. Further, I wish to reiterate the Loki Foundation's position that we have not and will not liquidate our Loki assets on market. We only plan on selling Loki in VC deals. The difference of 5% to 10% is quite substantial for the Foundation if we choose to sell the majority of our Loki assets to VCs within the next 12-14 months. It means we can maintain our ability to earn Loki over time through staking much more rapidly then would otherwise be the case.
At this moment, we have about 4.6 million Loki, (only ~10% of the circulating supply), and we will need to hold a minimum for 800k Loki to maintain our market liquidity service for the project and to keep some staking alive so we can use those service nodes to do our own network analytics and testing, as well as retaining some income. Going from 5% to 10% makes this much less difficult, as we will have an extra 250k Loki to use by that time from the extra boost, and means we can go from a balance of 800k Loki back to ~4m Loki in mid 2023 instead of 2025, which postures us for further funding much more quickly if it is required.
In terms of the discussion here, I particularity like Lucifer's summary.

Decreased emissions benefits every holder.
Increased Service Node reward from ~14 to ~16 per block.
Increased Foundation funding.
Decreased miner reward as they are not contributing much now that checkpointing has been implemented.
Looks like everyone wins except miners who are leaving soon anyway.

Yidakee said something about funding anxiety. Funding anxiety is a problem that will never go away, this request is an attempt to mitigate some of that concern, and it would really help us manage this project for the community in the best way that we can. In submitting this proposal, I do so because I believe it serves the interest of every person that owns Loki or cares about our mission. Some of you think I'm wrong, and that is criticism I'm willing to accept. I stand behind this request and I hope you can see how it will serve all of us in the long run.
If this proposal is rejected, it will not be the end of Loki, this certainly doesn't change our short-term or mid-term standing to a large degree. I don't buy the argument that you can't change the social contract because people won't use it as money. We all collectively decide what the social contract is, and what I think matters more than an immutable emissions scheme (which, if you recall, has already been changed several times, all of which with less emission) is that the community behind the currency is strong, and that the team that ultimately facilitates its existence and its use is perceived to be competent, well resourced, and successful.
Regarding PoS/PoW, the decision to move to PoS is now well behind this community, its something that was discussed and has been agreed upon. Even now, miners provide almost no security to this network thanks to check-pointing. Service Nodes make Loki what it is, and they form a fundamental part of our security model, so transitioning to PoS is the obvious next step.

Ultimately, it boils down to this.
Will your current and future holdings of Loki be worth more or less with the Foundation getting a bigger block reward?
Will the health and longevity of the project improve with the Foundation getting a bigger block reward?

I support the changes.

We still need to consider the desire/requirement to restructure block reward to cover exits. That or look at an open market model or some blended funding approach to launch them before being able to apportion the future split. At present I see a correlation between funding them and the ability to have greater direction on exits; but the juice may not be worth the squeeze to control this external facing portion of the Lokinet. It may also prove to be impossible to scale to meet demands using internal funding. A free market model may be a more suitable option while appreciating that this requires relinquishing a fair degree of control over the distribution of exits. Regardless if they are to be funded that funding should be considered in this discussion when it comes to future reward split.

Haafingar, thank you for your detailed response. I fully agree with the proposal.

I disagree
There is still funds to develop for two years.
Selling to VC does not guarantee that the LOKI price will rise.
There is not enough evidence to increase the Foundation's compensation per block to 10%.
Q1. What is the price of LOKI for sale on VC?
Q2.What is the benefit to holders when selling to VC?

@kimjangsoo  selling to VC is no a strategy to make the price rise it's to continue guaranteed funding for development.
A1. @Haafingar said there wouldn't be sold for less than $1 per loki.
A2. A VC sale benefits holders because the projet continues to be funded. What more directly benefits holders is the block reward restructure, decreased coin inflation and less coins going to miners who probably have to sell them to pay for electricity. Going ahead with this proposal will reduce the mining reward from ~12.6 to 6 meaning less selling pressure which should translate into higher price.

VC also establishes potential great developments in the social backend, lets not forget that.

If the foundation commits to not selling bellow 1 usd and promise to decrease the dev tax back to 5% once target amount is raised then I have no issues with this proposal.

I would prefer to keep foundation at 10%.
An extra 5% for service nodes isn't going to make much difference but I think it would make a big difference towards development and marketing.
Maybe at a later date it could be split 7.5% Foundation, 2.5% Loki Funding System, 90% service nodes.

I appreciate the discussion and I agree with the proposal. I expect to have many more discussions about shifting the reward structure and other changes that are necessary for the success of the project. I recognize that currently, we are still a new project and that we are overcoming many problems that were foreseen and we kinda have to act rather quickly to overcome those obstacles.  Furthermore, right now, pretty much everyone is positive and willing to work together. We are not suffering from political infighting. As this project grows and rises in price, we may not be able to simply work together for the good of the project.
Hopefully we can learn from this discussion and begin to formalize a way to make a changes to the reward structure.
Developing this system would be a decent sized project in itself. I can only begin to imagine how many working parts there are to the LOKI project and how they each would be appropriately valued. I do think that beginning to develop a formal system for reward changes now would help solve problems much easier, many years form now.

@Haafingar I understand but rather than leaving it in the realm of unfunded by block reward yet undetermined I'd rather forge ahead with structuring exits on an internally unfunded basis. I'm going under the assumption that Exits are a strategic benefit to the platform which in my personal view is an assumption based on what they collectively bring to the platform. Without internal funding I see the requirement for concessions to the current concept of full SN carrying out this task. At present I believe it's looking at the EN structure as a separate entity from the SN otherwise there's limited (no) appeal to operate one. How this shift effects interest based on Sybil attack to Exits has to be judged but it seems we are at a point of compromise if we aren't posturing to ensure the existing nodes are compensated and regulated internally to cover this capability.

I agree with @William-E-Coyote "I do think that beginning to develop a formal system for reward changes now would help solve problems much easier, many years form now".

if you have 5 percent of the nodes now and Node emission doubles dont you get double the emission from your nodes to begin with?  basicly you get 4x the emssion once you go from 5 pecent at 55 percent to 10 percent at 90 percent etc.
So your going from x to 4x amounts from 5 percent to 10 percent. ... why not 7.5 percent insstead of 10 percent?

@SomethingGettingWrong
I just want to point out that the node emissions isn't going to double under this proposal. If it passes the service node reward will first go from ~14 to 16 (a ~14% increase from current reward) and then go 18.9 (a 35% increase from current reward)

@necro-nemesis I don't see regular SNs running exits. It just won't work, as you've identified. They will be separate machines that may or may not be tied to an existing SN, but the uptime of the exit wont affect the base SN reward of the main node or node network.
After opening this discussion 11 days ago, the discussion has been good, some questions have been asked, many of which have been addressed, and some ancillary issues have been raised and discussed. I asses the majority consensus to be moving in support of this proposal. This will be taken to the LF board for a final sign off before the developers implement it's effects for the next hard fork!


nodes with status failed not visible

The nodes with status failed are not visible, see picture.

And: where can I see the version of PuppetBoard?

How are they not visible? I'm seeing one node with a failed resource.

Oh wait, the static assets. Are you using apache by any chance?

Above the 15 it should be shown, but it isn't.
Yes, Apache:
Server Version: Apache/2.4.7 (Ubuntu) Phusion_Passenger/4.0.37 OpenSSL/1.0.1f
mod_wsgi/3.4 Python/2.7.6

Do you have this stanza in your vhost?
    Alias /static /usr/local/lib/pythonX.Y/dist-packages/puppetboard/static
    <Directory /usr/lib/python2.X/dist-packages/puppetboard/static>
        Satisfy Any
        Allow from all
    </Directory>

Great! This was my fault. I had:
<Directory /usr/local/lib/python2.7/dist-packages/puppetboard>
WSGIProcessGroup puppetboard
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all

That doesn't work!
Thanx!


discuss refactoring to reduce boilerplate

Discuss possible refactorings of the clojure resources to reduce the boilerplate involved in creating new resources.

As part of this discussion, I think that it would be worthwhile to look at the yada clojure library for building ring handlers.  It would offer a more concise, data-driven specification of the API and provides Swagger support for documenting the API automatically.  The potential downside is that it is in a 1.0 beta and may not be as mature as the currently used libraries. In addition, it appears to require the use of the Aleph, which (currently) appears to perform better than the http-kit library we're currently using.


Create documentation for WMT20 code release

This will be tackled as part of our wmt22 release, ETA 10/31.


Streaming support from kafka ?

Hi,
I have an use case where my spark code has to read streaming data from kafka and perform some business logic and write it to HDFS. My entire business logic is currently in node.js. Does this repo supports this use case ?  I also see that the examples described are in interactive mode with spark-node, on similar lines how can i run my java script code via spark-submit ?

Hi. Any luck with your Node.js Spark project and Kafka?
I am applying for a job and I think they are doing something similar, so trying to learn up coming from the Node.js side (with small bit of Spark/MapReduce experience).


[feature] how to reuse epoch_1.pth in xtuner?

When I finish llama2-7b fine-tuning, I need to reuse it's checkpoint.

You can use --resume YOUR_PTH for xtuner train.
But, we find there is a bug for resume PagedAdamW32bit or  DeepSpeed PTH, we will fix it in future version. So, if you want to resume one PTH, please use torch.optim.AdamW instead of PagedAdamW32bit  and do not use DeepSpeed

You can use --resume YOUR_PTH for xtuner train.
But.. we find there is a bug for resume PagedAdamW32bit or DeepSpeed PTH, we will fix it in future version. So, if you want to resume one PTH, please use torch.optim.AdamW instead of PagedAdamW32bit and do not use DeepSpeed

Thanks, It's helpful.I'll try it.

Has this bug been fixed?
i still can't resume from deepspeed pth，even i convert it to fp32 pth.

Hi! @amulil @lllsy12138
We've developed a solution that lets users resume from a DeepSpeed checkpoint, although it may seem a bit complicated.
The resume is made possible through these two PRs (https://github.com/open-mmlab/mmengine/pull/1424, https://github.com/microsoft/DeepSpeed/pull/4587), and setting exclude_frozen_parameters=True for DeepSpeedStrategy in xtuner/tools/train.py.
The most straightforward way to implement these steps is installing the related libraries from my forked repos (as these two PRs have yet to be merged)
pip install 'git+https://github.com/LZHgrla/mmengine.git@lzh/fix_ds_resume'
pip install 'git+https://github.com/LZHgrla/DeepSpeed@lzh/enhance'

and manually modifying the xtuner/tools/train.py as depicted here:
https://github.com/InternLM/xtuner/blob/0a9e4800354c78a6779323f3327921bb2a783846/xtuner/tools/train.py#L227-L233
Once these two PRs are merged, we'll incorporate support for the resume into the main branch.
I will update on any news regarding the resume feature in this issue!

Now all these PRs have been merged.
We can install latest xtuner (>=0.1.9), mmengine (>=0.10.0), deepspeed (>=0.12.3) to access the resume feature!
pip install 'xtuner>=0.1.9' 'mmengine>=0.10.0' 'deepspeed>=0.12.3'


Allow users to search in mobile browsers and also use emojis.

@timabbott here's the final result:

@2208Abhinav thanks for working on this.  It's a reasonable possible implementation, but I was hoping we could do something more clean (e.g. having resizes or even most popovers.hide_all() calls not trigger hiding of those sidebars, in general) -- did you try solutions of that form?

@timabbott the very first thing I did was I commented out popovers.hide_all() and that didn't work. So I guess there is something more to this issue rather than just hide all. We are actually thinking in the wrong direction. The issue is not caused by hide_all() but the main cause is that input field loses focus due to whole resize event caused by the virtual keyboard. I researched on the internet and found that the solution to this problem is to suppress the whole resize event. The problem of resizing due to virtual keyboard in mobile is quite old and annoying.

OK, great.  I fixed the above minor code issue, renamed the function to should_skip_mobile_resize, and merged this as 99df926ef38fb56405d2ccb17211805aba753bf9.  Thanks for debugging this @2208Abhinav!


Add Plot Wizard inside "Visualizing Plots" User Guide

updates /doc/user-guide/experiment-management/visualizing-plots#defining-plots with a section for the VSCode Extension's Plot Wizard

Demo

Fixes #4885

Thanks @julieg18! Let's move it to the top of Defining Plots to make it more prominent and save people time from having to read all the other info only to find out at the end they could just use the plots wizard. I think we can drop the VSCode Extension Plots Wizard header if we do that.

Thanks @julieg18! Let's move it to the top of Defining Plots to make it more prominent and save people time from having to read all the other info only to find out at the end they could just use the plots wizard. I think we can drop the VSCode Extension Plots Wizard header if we do that.

Makes sense, moved to the top!

Sorry @julieg18, I meant let's move it to the top of the Defining Plots section, not the whole page.

Sorry @julieg18, I meant let's move it to the top of the Defining Plots section, not the whole page.

Whoops, apologies, I misread Defining Plots as Visualizing Plots 😅.  Moved to the top of Defining Plots!

Thanks @julieg18! After reading it, I moved a bit of the intro text above it to give some more context.