COP > 10 reported as 0

** Versions **

Home Assistant version: 2023.10.3
This integration version: 1.3.0

COP > 10 reported as 0. Related to https://github.com/kamaradclimber/heishamon-homeassistant/blob/eb6c2ecb5fc02f3a7aaac0ab47a5208a055484bc/custom_components/aquarea/sensor.py#L130
We started the heat cycle on our unit for the first time this year. Outside temp was 15C. According to the heatpump itself max COP reached 14 so I think 10 limit on the COP is too low.
To Reproduce
Make the heatpump go brrrrr ;)
Expected behavior
Report correct COP.

It's impossible to get that high of cop :D something is really wrong here

OK i just verified and I have no idea where i got 14 from but it definitely was 10.5 :D

OK i just verified and I have no idea where i got 14 from but it definitely was 10.5 :D

Is it K/L series pump? Never seen so high cop :D 7-8 is top

It's a KIT-WXC09H3E8 so 3 phase T-CAP H series. It was also the highest COP we've seen but it was first time it heated anything other than hot water. And to be clear, it was momentary COP, average was definitely closer to 7-8

It's a KIT-WXC09H3E8 so 3 phase T-CAP H series. It was also the highest COP we've seen but it was first time it heated anything other than hot water. And to be clear, it was momentary COP, average was definitely closer to 7-8

:O something really strange. If you had data for exact time. Could you manual calculate it?
((Outlet_temp - inlet_temp) * 4.187 * (flow_rate/60)/1000)/consumed_electricity

Sorry I don't know what units you are looking for and result I'm getting from your formula does not make any scence for me.
But I'm willing to share:
Outlet: 29,97C
Inlet: 24C
flow: 16,6L/min
was reporting 600W power consumption (6400W of production)

I'm of course ready to consider increase the threshold if it makes sense.
The reason I put one is to avoid outlier values that exist, according to me, because measuring electricity consumption and "produced" heat is not necessarily reliable, especially during transition phases (just an intuition, I don't have anything to back this).

I'm of course ready to consider increase the threshold if it makes sense.
The reason I put one is to avoid outlier values that exist, according to me, because measuring electricity consumption and "produced" heat is not necessarily reliable, especially during transition phases (just an intuition, I don't have anything to back this).

I completely agree. I'm not proposing removing it but increasing it to like 15 maybe since heatpump itself reported COP > 10.

Sorry I don't know what units you are looking for and result I'm getting from your formula does not make any scence for me. But I'm willing to share: Outlet: 29,97C Inlet: 24C flow: 16,6L/min was reporting 600W power consumption (6400W of production)

Indeed 11.56 :)

For what it's worth: My own COP calculation based on S0 and heat energy meter I limited at 12 -> that is usually covering all cases of my Aquarea I ever whitnessed (including cooling)

I've put the limit at 15 and we'll see. At worse we are not filtering enough but apart from value reading by a human, I don't think there is much utility to COP.

Just to add to this discussion and what it's worth: I checked my fairly recent H model 9kW T-CAP, and it reports the COP just by production/ consumption relatio. Not by ((Outlet_temp - inlet_temp) * 4.187 * (flow_rate/60) * 1000)/consumed_electricity  which might be termophysically more correct?

Truly no one knows which sensors and how accrue uses Panasonic to calculate it's heat production.. also no one knows exactly where power consumption is measured.. so there is place to debate :)  also there is very well known that t-cap series power consumption measures more accurate than other's.

According to unit's Energy monitoring/ present situation where there are consumption, generation and COP presented in the same page, it is easy to note that that at least current COP is a result of straightforward mathematical division. Where the consumption/ generation values come from, is more or less unknown, but the point is, that at present there are 2 different COP values  depending on which device reports them.

Yes and cop is division of production/consumption. True point is from where and how consumption and production is calculated.. in user perspective it should be inlet/outlet water temperature difference with flow rate.. in panasonic it can messured near hex (heat exchanger) or maybe in gas pipes.. also what point should calculate consumption? Whole unit or compressor? How about CPU, and circulation pumps. By fact that pump is only reports current for compressor.. it could be that it's just calculates it's power consumption by adding some constants..

Yes, we know this, but from normal user's perspective, I think the question is, should Heishamon and Aquarea give the same value and the readings be unified, regardless of the calculation methods?

:D it's depends..
I think yes it's should be same as pump reports.. and just for those who don't trust that value and want to see difference should use custom calculation.

Just to add to this discussion and what it's worth: I checked my fairly recent H model 9kW T-CAP, and it reports the COP just by production/ consumption ratio. Not by ((Outlet_temp - inlet_temp) * 4.187 * (flow_rate/60) * 1000)/consumed_electricity  which might be termophysically more correct?

This is what the Aquarea is doing. The "production" value reported by Aquarea is calculated internally following the formula you stated (excl. the consumption decision). The sometimes high error on reported COP results from poor/partial consumtion measurement and low resolution of Temp Sensors

I feel you are talking from different positions? To my knowledge, Heishamon - and the HA integration - do show exactly the same COP as the Aquarea Control unit, right? Both do the simple "production devided by consumption = COP"
@MEKadan Where do you see the conflict?

Hmm... After recents updates to both Heishamon integration and Heishamon board firmware, I see sensor.aquarea_cop reporting different values than Aquarea

E.g: this:

Picture reports COP to be 2.19, maths give 2.6?

Not in my case - it's just plain calculation. 5KW J Series

I feel you are talking from different positions? To my knowledge, Heishamon - and the HA integration - do show exactly the same COP as the Aquarea Control unit, right? Both do the simple "production devided by consumption = COP"
@MEKadan Where do you see the conflict?

Hmm... After recents updates to both Heishamon integration and Heishamon board firmware, I see sensor.aquarea_cop reporting different values than Aquarea

It can't be same.. average for longer period will be in near..
And no, integration don't use that formula.

That is not what I mean. The COP in the integration is straight forward, production divided by consumption as reported by heishamon. My graph shows that, e.g. 2800W / 400Watt = 7.
But MEKadan shows a view where 5200/2000 yields 2.19 instead of 2,6. That should not be possible

I feel you are talking from different positions? To my knowledge, Heishamon - and the HA integration - do show exactly the same COP as the Aquarea Control unit, right? Both do the simple "production devided by consumption = COP"
@MEKadan Where do you see the conflict?

Hmm... After recents updates to both Heishamon integration and Heishamon board firmware, I see sensor.aquarea_cop reporting different values than Aquarea

It can't be same.. average for longer period will be in near..
And no, integration don't use that formula.

So. is it so that what comes to current COP, the integration and heat pump shows different values?

at the same time, the integration reports
consumption 1.4kW
production 4.6 kW
COP 2.39

I feel you are talking from different positions? To my knowledge, Heishamon - and the HA integration - do show exactly the same COP as the Aquarea Control unit, right? Both do the simple "production devided by consumption = COP"
@MEKadan Where do you see the conflict?

Hmm... After recents updates to both Heishamon integration and Heishamon board firmware, I see sensor.aquarea_cop reporting different values than Aquarea

It can't be same.. average for longer period will be in near..
And no, integration don't use that formula.

So. is it so that what comes to current COP, the integration and heat pump shows different values?

at the same time, the integration reports consumption 1.4kW production 4.6 kW COP 2.39

I suspect what's wrong on your side... Your MQTT broker still holds an old power / consumption value, the name has changed. Restart / reset your MQTT broker and it should be fine again.
The integration does the same as you with your calculator. Only it finds two consumption or power (formerly energy) values and adds them

I suspect what's wrong on your side... Your MQTT broker still holds an old power / consumption value, the name has changed. Restart / reset your MQTT broker and it should be fine again.

Hmm... I have restarted HA at least half a dozen times since installation of the latest updates, should it do the same? I also both reloaded the integration and restarted the addon, to no avail.
The production/ consumption values were updating just fine even before these actions. Only COP does not update correctly. It is calculated in the integration, and thus can not find a relevant MQTT topic.
On thing needs to be clarified also. It was said in the firmware release notes, that:
Rename 'Energy' to 'Power' for the heat/cool/dhw consumption and production topics. Remember to change this into your home automation tools
I must have misunderstood this somehow.
Some background:
MQTT Explorer shows the new topics:
Heat_Power_Production = 0
Heat_Power_Consumption = 0
Cool_Power_Production = 0
Cool_Power_Consumption = 0
DHW_Power_Production = 5200
DHW_Power_Consumption = 1400

...and they are updating. The old 'energy' ones are still visible there, but do not update, of course.
Heat_Energy_Production = 0
Heat_Energy_Consumption = 0
Cool_Energy_Production = 0
Cool_Energy_Consumption = 0
DHW_Energy_Production = 4000
DHW_Energy_Consumption = 2200

HOWEVER, the HA entities did not change after the update. They are still the "old style" energy ones, like e.g. sensor.panasonic_aquarea_main_dhw_energy_production
Still, they do get updated values from MQTT. And I cannot find any "new style" entities like sensor.panasonic_aquarea_main_dhw_power_production. Should there be such?
Have I missed something?

The thing is, that for the name change on heishamon side the integration needed to react to the change to still work. What has been coded by @kamaradclimber is that it looks for old and new topic and adds the values. Find a way to set the old energy values back to 0 and you are fine

The thing is, that for the name change on heishamon side the integration needed to react to the change to still work. What has been coded by @kamaradclimber is that it looks for old and new topic and adds the values. Entities on HA side are kept.
Find a way to set the old energy values in MQTT broker back to 0 and you are fine

OK, that did it. Sorry about all the hassle. Thanks. guys :)

Just in case others bump into same problem (and I can't see, why some wouldn't...), setting old energy values in MQTT broker (Mosquitto in my case)  to 0 was not enough, because they kept on coming back after restarts etc.
Old retained MQTT topics needs to deleted.  I don't know if there is a good way to do that e.g. in HA, but for example in MQTT Explorer it is easy.

In HA you can just send a message (from MQTT integration "configure" page) with retained flag set and empty payload (delete the default 0) to the topic. Sending retained message with 0 would also work but you would forever have phantom data laying around.


自定义甘特图样式,修复官方的ganttChart任务过多时不显示的Bug

自定义甘特图样式,修复官方的ganttChart任务过多时不显示的Bug

Purpose of the pull request

Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

(or)
If your pull request contain incompatible change, you should also add it to docs/docs/en/guide/upgrede/incompatible.md

Can't these three be combined into one PR?
https://github.com/apache/dolphinscheduler/pull/15033
https://github.com/apache/dolphinscheduler/pull/15034
https://github.com/apache/dolphinscheduler/pull/15035

Codecov Report

Merging #15033 (af8202c) into dev (154e167) will increase coverage by 0.00%.
The diff coverage is n/a.

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

@@            Coverage Diff            @@
##                dev   #15033   +/-   ##
=========================================
  Coverage     38.95%   38.95%
+ Complexity     4600     4598    -2
=========================================
  Files          1231     1231
  Lines         43354    43320   -34
  Branches       4795     4779   -16
=========================================
- Hits          16889    16876   -13
+ Misses        24591    24571   -20
+ Partials       1874     1873    -1

see 25 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Closing due to inactive.


Fix deprecation warning re: sqlite representing boolean as integer.

Run tests in the default configuration. Deprecation warning should not show.
fixes #1178

@carlthuringer Thanks!


make this project pip installable

Love the idea behind this package, would like to leverage to do some analysis. I think I could help here if you're comfortable with my contributing.
With a few tweaks leveraging guidance from python.org you could take care of the requirements for the project and empower analysts to import the package, regardless of its relative path.
Let me know if you'd be open to a contribution and I can submit a PR.

Hey @duncancfraser ! Yes, of course I am open contributions, in fact, I encourage them. Making this project pip installable is on my to-do list, but unfortunately I have no experience on this, so any information you have is welcome. Also, there are still some features I'd like to add but I've been busy lately and I haven't had the time to keep working on PandasBasketball.

Awesome. I have something working on a forked version of this, once I get it tightened up I'll open a PR for the pip installation!

Great! I'm looking forward to it.

Project is now pip-installable!

You can cross this out at the bottom of your README.md now! :smile:


Sign In With Apple - CompletionHandler

Hello, I'm being forced to introduce a "Sign In With Apple" feature on a new app update.  Since this is legacy still, I need a solution.
I've been able to implement the Sign In With Apple so far.  But after Apple authenticates, it hits the redirect URL where we are suppose to handle the authentication data for handoff back to the app.
Problem is, Apple basically just loads the response from our API into the View.  I've provided basic HTML response that I can format easily enough.  I put in a "Close Window" button for Javascript, but tapping that, doesn't work.  Safari View still remains open.
The only way that I can see is tapping "Done".  That works if I instruct the user that yes, sign in is complete, you can now tap Done.  Works, but would be better to be able to close the View after this redirect is called.
From what I can see, the events fired do not cover the final step of the navigation to the redirect url.
Any ideas to accomplish this? Anyone still around? :)

For future visitors, this is basic pseudo code flow that I used:

create a guid
start a new persistent sign in session on your server
pass guid as state value in apple ID authorize url
open safari view to apple ID authorize url
user does sign in flow
in background, poll server for status on session guid
depending on status of session guid on server (apple called your redirect URL), close View
continue create account or sign in user in client/app side


When I used the path_provider plugin for my flutter application, I encountered some problems

When I imported the path_provider plugin in the pubspec.yaml file, my flutter application failed to compile and threw the following error.
Launching lib\main.dart on Xiaomi in debug mode...
FAILURE: Build failed with an exception.

What went wrong:
A problem occurred configuring project ':path_provider_macos'.

Could not resolve all dependencies for configuration ':path_provider_macos:classpath'.
Could not load module metadata from C:\Users\37950.DESKTOP-SM4KBUP.gradle\caches\modules-2\metadata-2.71\descriptors\com.android.tools.analytics-library\shared\26.2.1\fc7e8eef251519086b6ee9788cba4dd2\descriptor.bin
Could not get unknown property 'android' for project ':path_provider_macos' of type org.gradle.api.Project.

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
Get more help at https://help.gradle.org
BUILD FAILED in 4s
Gradle task assembleDebug failed with exit code 1
Exited (sigterm)

And my environment configuration information is as follows.
[√] Flutter (Channel stable, v1.12.13+hotfix.9, on Microsoft Windows [Version 10.0.18362.720], locale zh-CN)
• Flutter version 1.12.13+hotfix.9 at F:\flutter
• Framework revision f139b11009 (4 days ago), 2020-03-30 13:57:30 -0700
• Engine revision af51afceb8
• Dart version 2.7.2
[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
• Android SDK at F:\sdk
• Android NDK location not configured (optional; useful for native profiling support)
• Platform android-28, build-tools 28.0.3
• ANDROID_HOME = F:\flutter
• Java binary at: F:\AndroidStudio\jre\bin\java
• Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)
• All Android licenses accepted.
[√] Android Studio (version 3.4)
• Android Studio at F:\AndroidStudio
• Flutter plugin version 39.0.1
• Dart plugin version 183.6270
• Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)
[√] Connected device (1 available)
• Xiaomi • <IP_ADDRESS>:5555 • android-x86 • Android 9 (API 28)
Can you help me solve this problem?thank you!!!

I have the same issues, no fixes yet?

I have the same issues, no fixes yet?

Has not been solved, and i do not know why there is such a mistake.

Hi @lxjmaster
thanks for your flutter doctor -v ;
can you please provide your full flutter run --verbose,
your pubspec.yaml and a reproducible minimal code sample.
Thank you

I have found a solution for this.

I have found a solution.

Thank you
@iapicca Of Course.

Running the flutter run --verbose command gives the following results

[  +33 ms] executing: [F:\flutter] git -c log.showSignature=false log -n 1 --pretty=format:%H
[ +105 ms] Exit code 0 from: git -c log.showSignature=false log -n 1 --pretty=format:%H
[   +4 ms] f139b11009aeb8ed2a3a3aa8b0066e482709dde3
[   +1 ms] executing: [F:\flutter] git describe --match v*.. --first-parent --long --tags
[  +54 ms] Exit code 0 from: git describe --match v*.. --first-parent --long --tags
[        ] v1.12.13+hotfix.9-0-gf139b1100
[   +6 ms] executing: [F:\flutter] git rev-parse --abbrev-ref --symbolic @{u}
[  +65 ms] Exit code 0 from: git rev-parse --abbrev-ref --symbolic @{u}
[        ] origin/stable
[        ] executing: [F:\flutter] git ls-remote --get-url origin
[  +56 ms] Exit code 0 from: git ls-remote --get-url origin
[        ] https://github.com/flutter/flutter.git
[ +103 ms] executing: [F:\flutter] git rev-parse --abbrev-ref HEAD
[  +62 ms] Exit code 0 from: git rev-parse --abbrev-ref HEAD
[        ] stable
[ +444 ms] executing: F:\sdk\platform-tools\adb.exe devices -l
[  +41 ms] Exit code 0 from: F:\sdk\platform-tools\adb.exe devices -l
[        ] List of devices attached
<IP_ADDRESS>:5555    device product:vbox86p model:Xiaomi device:vbox86p transport_id:3
[  +19 ms] F:\sdk\platform-tools\adb.exe -s <IP_ADDRESS>:5555 shell getprop
[ +107 ms] Artifact Instance of 'AndroidMavenArtifacts' is not required, skipping update.
[   +7 ms] Artifact Instance of 'AndroidInternalBuildArtifacts' is not required, skipping update.
[   +1 ms] Artifact Instance of 'IOSEngineArtifacts' is not required, skipping update.
[   +1 ms] Artifact Instance of 'FlutterWebSdk' is not required, skipping update.
[   +7 ms] Artifact Instance of 'WindowsEngineArtifacts' is not required, skipping update.
[   +3 ms] Artifact Instance of 'MacOSEngineArtifacts' is not required, skipping update.
[   +1 ms] Artifact Instance of 'LinuxEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'LinuxFuchsiaSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'MacOSFuchsiaSDKArtifacts' is not required, skipping update.
[   +1 ms] Artifact Instance of 'FlutterRunnerSDKArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FlutterRunnerDebugSymbols' is not required, skipping update.
[  +62 ms] Found plugin connectivity at F:\flutter.pub-cache\hosted\pub.flutter-io.cn\connectivity-0.4.8+2
[  +10 ms] Found plugin connectivity_macos at F:\flutter.pub-cache\hosted\pub.flutter-io.cn\connectivity_macos-0.1.0+2
[  +41 ms] Found plugin path_provider at F:\flutter.pub-cache\hosted\pub.flutter-io.cn\path_provider-1.6.5
[   +2 ms] Found plugin path_provider_macos at F:\flutter.pub-cache\hosted\pub.flutter-io.cn\path_provider_macos-0.0.4
[ +164 ms] Found plugin connectivity at F:\flutter.pub-cache\hosted\pub.flutter-io.cn\connectivity-0.4.8+2
[   +4 ms] Found plugin connectivity_macos at F:\flutter.pub-cache\hosted\pub.flutter-io.cn\connectivity_macos-0.1.0+2
[  +35 ms] Found plugin path_provider at F:\flutter.pub-cache\hosted\pub.flutter-io.cn\path_provider-1.6.5
[   +6 ms] Found plugin path_provider_macos at F:\flutter.pub-cache\hosted\pub.flutter-io.cn\path_provider_macos-0.0.4
[ +119 ms] Generating F:\FlutterApps\ssc\android\app\src\main\java\io\flutter\plugins\GeneratedPluginRegistrant.java
[  +69 ms] ro.hardware = vbox86
[   +1 ms] ro.build.characteristics = nosdcard
[ +165 ms] Launching lib\main.dart on Xiaomi in debug mode...
[  +44 ms] executing: F:\sdk\build-tools\28.0.3\aapt dump xmltree F:\FlutterApps\ssc\build\app\outputs\apk\app.apk
AndroidManifest.xml
[  +62 ms] Exit code 0 from: F:\sdk\build-tools\28.0.3\aapt dump xmltree F:\FlutterApps\ssc\build\app\outputs\apk\app.apk
AndroidManifest.xml
[   +2 ms] N: android=http://schemas.android.com/apk/res/android
E: manifest (line=2)
A: android:versionCode(0x0101021b)=(type 0x10)0x1
A: android:versionName(0x0101021c)="1.0.0" (Raw: "1.0.0")
A: android:compileSdkVersion(0x01010572)=(type 0x10)0x1c
A: android:compileSdkVersionCodename(0x01010573)="9" (Raw: "9")
A: package="com.example.ssc" (Raw: "com.example.ssc")
A: platformBuildVersionCode=(type 0x10)0x1c
A: platformBuildVersionName=(type 0x10)0x9
E: uses-sdk (line=7)
A: android:minSdkVersion(0x0101020c)=(type 0x10)0x10
A: android:targetSdkVersion(0x01010270)=(type 0x10)0x1c
E: uses-permission (line=14)
A: android:name(0x01010003)="android.permission.INTERNET" (Raw: "android.permission.INTERNET")
E: uses-permission (line=15)
A: android:name(0x01010003)="android.permission.ACCESS_NETWORK_STATE" (Raw:
"android.permission.ACCESS_NETWORK_STATE")
E: uses-permission (line=16)
A: android:name(0x01010003)="android.permission.ACCESS_WIFI_STATE" (Raw: "android.permission.ACCESS_WIFI_STATE")
E: application (line=24)
A: android:label(0x01010001)="ssc" (Raw: "ssc")
A: android:icon(0x01010002)=@0x7f080000
A: android:name(0x01010003)="io.flutter.app.FlutterApplication" (Raw: "io.flutter.app.FlutterApplication")
A: android:debuggable(0x0101000f)=(type 0x12)0xffffffff
A: android:appComponentFactory(0x0101057a)="androidx.core.app.CoreComponentFactory" (Raw:
"androidx.core.app.CoreComponentFactory")
E: activity (line=30)
A: android:theme(0x01010000)=@0x7f0a0000
A: android:name(0x01010003)="com.example.ssc.MainActivity" (Raw: "com.example.ssc.MainActivity")
A: android:launchMode(0x0101001d)=(type 0x10)0x1
A: android:configChanges(0x0101001f)=(type 0x11)0x40003fb4
A: android:windowSoftInputMode(0x0101022b)=(type 0x11)0x10
A: android:hardwareAccelerated(0x010102d3)=(type 0x12)0xffffffff
E: intent-filter (line=37)
E: action (line=38)
A: android:name(0x01010003)="android.intent.action.MAIN" (Raw: "android.intent.action.MAIN")
E: category (line=40)
A: android:name(0x01010003)="android.intent.category.LAUNCHER" (Raw: "android.intent.category.LAUNCHER")
E: meta-data (line=47)
A: android:name(0x01010003)="flutterEmbedding" (Raw: "flutterEmbedding")
A: android:value(0x01010024)=(type 0x10)0x2
[  +49 ms] executing: F:\sdk\platform-tools\adb.exe -s <IP_ADDRESS>:5555 shell -x logcat -v time -t 1
[  +83 ms] Exit code 0 from: F:\sdk\platform-tools\adb.exe -s <IP_ADDRESS>:5555 shell -x logcat -v time -t 1
[   +1 ms] --------- beginning of main
04-06 05:40:40.256 I/system_server(  346): The ClassLoaderContext is a special shared library.
[  +15 ms] executing: F:\sdk\platform-tools\adb.exe version
[   +2 ms] executing: F:\sdk\platform-tools\adb.exe -s <IP_ADDRESS>:5555 logcat -v time -T 04-06 05:40:40.256
[  +69 ms] Android Debug Bridge version 1.0.41
Version 28.0.3-5475833
Installed as F:\sdk\platform-tools\adb.exe
[   +5 ms] executing: F:\sdk\platform-tools\adb.exe start-server
[ +108 ms] Building APK
[  +38 ms] Running Gradle task 'assembleDebug'...
[   +5 ms] gradle.properties already sets android.enableR8
[   +5 ms] Using gradle from F:\FlutterApps\ssc\android\gradlew.bat.
[  +18 ms] executing: F:\AndroidStudio\jre\bin\java -version
[ +311 ms] Exit code 0 from: F:\AndroidStudio\jre\bin\java -version
[   +3 ms] openjdk version "1.8.0_152-release"
OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)
OpenJDK 64-Bit Server VM (build 25.152-b01, mixed mode)
[   +8 ms] executing: [F:\FlutterApps\ssc\android] F:\FlutterApps\ssc\android\gradlew.bat -Pverbose=true
-Ptarget=F:\FlutterApps\ssc\lib\main.dart -Ptrack-widget-creation=true -Pfilesystem-scheme=org-dartlang-root
-Ptarget-platform=android-x86 assembleDebug
[+4603 ms] FAILURE: Build failed with an exception.
[   +5 ms] * What went wrong:
[   +1 ms] A problem occurred configuring project ':path_provider_macos'.
[  +33 ms] > Could not resolve all dependencies for configuration ':path_provider_macos:classpath'.
[  +15 ms]    > Could not load module metadata from
C:\Users\37950.DESKTOP-SM4KBUP.gradle\caches\modules-2\metadata-2.71\descriptors\com.android.tools\annotations\26.2.1\fc7e8eef251519086b6ee9788cba4dd2\descriptor.bin
[  +49 ms] > Could not get unknown property 'android' for project ':path_provider_macos' of type org.gradle.api.Project.
[   +9 ms] * Try:
[  +38 ms] Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with
--scan to get full insights.
[   +2 ms] * Get more help at https://help.gradle.org
[   +2 ms] BUILD FAILED in 4s
[ +221 ms] Running Gradle task 'assembleDebug'... (completed in 5.3s)
[  +11 ms] "flutter run" took 7,226ms.
Gradle task assembleDebug failed with exit code 1
#0      throwToolExit (package:flutter_tools/src/base/common.dart:28:3)
#1      buildGradleApp (package:flutter_tools/src/android/gradle.dart:387:7)
#2      _asyncThenWrapperHelper. (dart:async-patch/async_patch.dart:73:64)
#3      _rootRunUnary (dart:async/zone.dart:1134:38)
#4      _CustomZone.runUnary (dart:async/zone.dart:1031:19)
#5      _FutureListener.handleValue (dart:async/future_impl.dart:139:18)
#6      Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:680:45)
#7      Future._propagateToListeners (dart:async/future_impl.dart:709:32)
#8      Future._completeWithValue (dart:async/future_impl.dart:524:5)
#9      _AsyncAwaitCompleter.complete (dart:async-patch/async_patch.dart:32:15)
#10     _completeOnAsyncReturn (dart:async-patch/async_patch.dart:290:13)
#11     _DefaultProcessUtils.stream (package:flutter_tools/src/base/process.dart)
#12     _asyncThenWrapperHelper. (dart:async-patch/async_patch.dart:73:64)
#13     _rootRunUnary (dart:async/zone.dart:1134:38)
#14     _CustomZone.runUnary (dart:async/zone.dart:1031:19)
#15     _FutureListener.handleValue (dart:async/future_impl.dart:139:18)
#16     Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:680:45)
#17     Future._propagateToListeners (dart:async/future_impl.dart:709:32)
#18     Future._completeWithValue (dart:async/future_impl.dart:524:5)
#19     Future._asyncComplete. (dart:async/future_impl.dart:554:7)
#20     _rootRun (dart:async/zone.dart:1126:13)
#21     _CustomZone.run (dart:async/zone.dart:1023:19)
#22     _CustomZone.runGuarded (dart:async/zone.dart:925:7)
#23     _CustomZone.bindCallbackGuarded. (dart:async/zone.dart:965:23)
#24     _microtaskLoop (dart:async/schedule_microtask.dart:43:21)
#25     _startMicrotaskLoop (dart:async/schedule_microtask.dart:52:5)
#26     _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:118:13)
#27     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:175:5)
And my pubspec.yaml file looks like this.
name: ssc
description: A new Flutter project.
The following defines the version and build number for your application.
A version number is three numbers separated by dots, like 1.2.43
followed by an optional build number separated by a +.
Both the version and the builder number may be overridden in flutter
build by specifying --build-name and --build-number, respectively.
In Android, build-name is used as versionName while build-number used as versionCode.
Read more about Android versioning at https://developer.android.com/studio/publish/versioning
In iOS, build-name is used as CFBundleShortVersionString while build-number used as CFBundleVersion.
Read more about iOS versioning at
https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html
version: 1.0.0+1
environment:
sdk: ">=2.1.0 <3.0.0"
dependencies:
flutter:
sdk: flutter
The following adds the Cupertino Icons font to your application.
Use with the CupertinoIcons class for iOS style icons.
cupertino_icons: ^0.1.2
path_provider: ^1.4.5
path: ^1.6.4
connectivity: ^0.4.8+2
http: ^0.12.0+4
dev_dependencies:
flutter_test:
sdk: flutter
For information on the generic Dart part of this file, see the
following page: https://dart.dev/tools/pub/pubspec
The following section is specific to Flutter.
flutter:
The following line ensures that the Material Icons font is
included with your application, so that you can use the icons in
the material Icons class.
uses-material-design: true
To add assets to your application, add an assets section, like this:
assets:
- images/a_dot_burr.jpeg
- images/a_dot_ham.jpeg
An image asset can refer to one or more resolution-specific "variants", see
https://flutter.dev/assets-and-images/#resolution-aware.
For details regarding adding assets from package dependencies, see
https://flutter.dev/assets-and-images/#from-packages
To add custom fonts to your application, add a fonts section here,
in this "flutter" section. Each entry in this list should have a
"family" key with the font family name, and a "fonts" key with a
list giving the asset and other descriptors for the font. For
example:
fonts:
- family: Schyler
fonts:
- asset: fonts/Schyler-Regular.ttf
- asset: fonts/Schyler-Italic.ttf
style: italic
- family: Trajan Pro
fonts:
- asset: fonts/TrajanPro.ttf
- asset: fonts/TrajanPro_Bold.ttf
weight: 700

For details regarding fonts from package dependencies,
see https://flutter.dev/custom-fonts/#from-packages

My main.dart is as follows
import 'package:flutter/material.dart';
// import 'package:ssc/utils.dart';
import 'dart:io';
void main() => runApp(MyApp());
class MyApp extends StatelessWidget {
@override
Widget build(BuildContext context) {
// TODO: implement build
return MaterialApp(
debugShowCheckedModeBanner: false,
title: "ssc",
home: HomePage(),
);
}
}
class HomePage extends StatefulWidget {
_HomePageState createState() => _HomePageState();
}
class _HomePageState extends State {
List data = List();
FocusNode _horizontalFocusNode;
FocusNode _verticalFocusNode;
TextEditingController _horizontalController;
TextEditingController _verticalController;
@override
void initState() {
// TODO: implement initState
super.initState();
_horizontalFocusNode = FocusNode();
_verticalFocusNode = FocusNode();
_horizontalController = TextEditingController();
_verticalController = TextEditingController();
// 初始化
// myinit();
// readfile();
}
@override
Widget build(BuildContext context) {
// TODO: implement build
return Scaffold(
appBar: AppBar(
title: Text("ssc")
),
body: Container(
padding: EdgeInsets.only(top: 20.0),
child: Column(
children: [
Row(
children: [
Column(
children: [
ConstrainedBox(
constraints: BoxConstraints(
maxHeight: 25,
maxWidth: 200
),
child: TextField(
focusNode: _horizontalFocusNode,
controller: _horizontalController,
decoration: InputDecoration(
border: OutlineInputBorder(),
icon: Text("搜索横："),
),
),
),
ConstrainedBox(
constraints: BoxConstraints(
maxHeight: 25,
maxWidth: 200
),
child: TextField(
focusNode: _verticalFocusNode,
controller: _verticalController,
decoration: InputDecoration(
border: OutlineInputBorder(),
icon: Text("搜索纵："),
),
),
),
]
),
Container(
child: OutlineButton(
child: Text("搜索"),
onPressed: (){},
)
)
],
),
Expanded(
child: ListView.builder(
itemCount: 1,
itemBuilder: (BuildContext context, int index) {
return Row(
children: [
Text("234"),
Text("345")
],
);
}
)
)
],
),
)
);
}
// readfile() async {
//   File file = await getLocalFile();
//   List text = await file.readAsLines();
//   data = text;
// }
}

I have found a solution.

This fixed the problem for me

@arashAndroid
I tried this method, but I don't have the path_provider_macos folder

I have found a solution.

This fixed the problem for me

@arashAndroid
I tried this method, but I don't have the path_provider_macos folder

@arashAndroid @iapicca
Surprisingly, this method works but my path_provider_macos document is not in the directory \.pub-cache\hosted\pub.dartlang.org\
Instead, it is in the directory \.pub-cache\hosted\pub.flutter-io.cn\
So the effective solution is to remove the path_provider_macos-0.0.4 folder.
Thank you very much.

Hi @lxjmaster
I'm glad that you solved the issue
thank you for letting me know


issue FightLightDungeon { name: dungeon, use_mushroom: false }) uses mushrooms

when i called Command::FightLightDungeon { name: dungeon, use_mushroom: false }), and have timer it still results in fighting and using mushroom for it

Thats bad, mby in next release delete the option and make it always true but that will cass problems in backcompatability,
or at least warning in comment of the function will be helpfull


pythonPackages.ecos: init at 2.0.7.post1

Motivation for this change
Add dependency for upcoming qiskit package #78772
Split from #78772 per request
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Depends on #79187

please address conflicts

conflicts should be resolved.

@GrahamcOfBorg build python37Packages.ecos python38Packages.ecos


Please update NPM

The 1.0.0 version is not available on NPM, please update it ;)

https://github.com/osdnk/react-native-reanimated-bottom-sheet/commit/bc295b17dbd91e1082963ac10cf0a4cf6671e6ce

it's available on npm as<EMAIL_ADDRESS>

thank's @osdnk


Text hierarchy in questions can lead to confusion

User’s natural reaction to answering the veteran question was “yes” until they read it more closely. Might be good to make sure we have bolded words in our questions to make it obvious what it is about.
“Are you a veteran of the United States?”
Or potentially prefacing questions with the keyword:
“Veteran Status. Are you a veteran of the United States?”

I think both of these changes are an improvement.

This is a little awkward, because the labels are already bolded. The default fonts don't seem to have fine gradations of font-weight available, which would allow us to use a "black" typeface that is even heavier than bold (for example, using 800 vs 600). In order to make it <strong> tags stand out, we would need to de-emphasize form labels in some way. This could be done with color or with font-weight. Given the lack of font-weight options, I'd tend towards color for now.
label { color: #666; }
label strong { color: #000; }

Color shift for strong tags in labels

label { font-weight: 500; }
label strong { font-weight: 900; }

label { font-weight: 300; }
label strong { font-weight: 900; }

I like the last option, personally. Presumably if we move away from bootstrap we won't have to override any of these pre-existing styles.

I like it in isolation. Combined with the rest of the form it looks weird. But I'll just go with it for now.

I don't think we actually have to implement this by itself. This is a larger issue of how the forms are designed (or not designed). Just posted this issue to make sure we are aware once we go through a design phase.

@svmatthews Totally agree that it should be ongoing consideration. do you mind if I actually close this though, now that we have a record and memory of it? Should we tag for future review?

Nah, closing it is good with me!


DROOLS-733 - Fixing parent pom definition of kie-server and kie-serve…

…r-distribution

merged into execution server unification branch (https://github.com/droolsjbpm/droolsjbpm-integration/commit/b7319c97455f52442b2c5d20697bbe623ad66f88) thanks @sutaakar


GH-35503: [CI][Packaging][C++] Snappy patch fails to apply on arm64 windows wheel builds

Rationale for this change
Nightly Windows wheels have been failing for the last days.
What changes are included in this PR?
Update patch with latest snappy
Are these changes tested?
Will be tested via crossbow
Are there any user-facing changes?
No

Closes: #35503

@github-actions crossbow submit wheel-windows-*

@github-actions crossbow submit wheel-windows-cp310-amd64

@github-actions crossbow submit wheel-windows-cp310-amd64

@github-actions crossbow submit wheel-windows-cp310-amd64

@github-actions crossbow submit wheel-windows-cp310-amd64

@github-actions crossbow submit wheel-windows-*

@raulcd Thanks for fixing this and apologies for introducing it here https://github.com/apache/arrow/pull/35430/files#r1184737729

@raulcd Thanks for fixing this and apologies for introducing it here https://github.com/apache/arrow/pull/35430/files#r1184737729

No worries at all, it took me more tries than expected :)

OK, I felt a bit bad because I'd forgotten I'd changed the patch (context switching), and ended up creating the issue based on kou's investigation.


[Bug]: Not supporting OrbStack

Is there an existing issue for the same bug?

[X] I have checked the existing issues.

Describe the bug and reproduction steps
Orbstack is one of the beat methods to run docker on MacOs: https://orbstack.dev/
OpenHands fails to work in OrbStack:
11:50:01 - openhands:ERROR: eventstream_runtime.py:382 - [runtime 2c72873c-723c-41c2-906f-ef8a99fe3b0b] Error: Instance openhands-runtime-2c72873c-723c-41c2-906f-ef8a99fe3b0b FAILED to start container!

11:50:01 - openhands:INFO: eventstream_runtime.py:237 - [runtime 2c72873c-723c-41c2-906f-ef8a99fe3b0b] Container started: openhands-runtime-2c72873c-723c-41c2-906f-ef8a99fe3b0b. VSCode URL: None
ERROR:asyncio:Future exception was never retrieved
future: <Future finished exception=AttributeError("'NoneType' object has no attribute 'logs'")>
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/openhands/server/session/agent_session.py", line 92, in _start_thread
    asyncio.run(self._start(*args), debug=True)
  File "/usr/local/lib/python3.12/asyncio/runners.py", line 194, in run
    return runner.run(main)
           ^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 687, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/app/openhands/server/session/agent_session.py", line 108, in _start
    await self._create_runtime(
  File "/app/openhands/server/session/agent_session.py", line 196, in _create_runtime
    await self.runtime.connect()
  File "/app/openhands/runtime/impl/eventstream/eventstream_runtime.py", line 242, in connect
    self.log_buffer = LogBuffer(self.container, self.log)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/openhands/runtime/impl/eventstream/eventstream_runtime.py", line 75, in __init__
    self.log_generator = container.logs(stream=True, follow=True)
                         ^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'logs'

OpenHands Installation
Docker command in README
OpenHands Version
0.14.3
Operating System
MacOS
Logs, Errors, Screenshots, and Additional Context
No response

Going to change this to an "enhancement" rather than a bug because this is adding new functionality.


Gray-scale colors

Is there a way to prevent gray-scale colors?
For binance https://belkalab.github.io/material-color-hash/ gives 10 shades of gray, I wish it could be more colorful 😉

Hello amio,
there is currently no way of doing that, since the generation uses the whole palette of the material colors. You could use a hack to achieve that, by appending a space (or any other character really) to the string you are passing in, if the color is gray:
function getMaterialColorExcludeGrey(string) {
    let color = toMaterialStyle(string);
    if (color.materialColorName === 'Grey') {
        color = toMaterialStyle(string + ' ');
    }
    return color;
}

or maybe even with a while loop, in case you are really unlucky and string + space is still grey ;)
function getMaterialColorExcludeGrey(string) {
    let hashString = string;
    let color = toMaterialStyle(hashString);
    while (color.materialColorName === 'Grey') {
        hashString += ' ';
        color = toMaterialStyle(hashString);
    }
    return color;
}

that should be sufficient to avoid gray colors in your case.

Yep, nice workaround @GiovanniFrigo
Thanks for this awesome package!


[EB]Add Unittest for EB

Codecov Report
Attention: 8 lines in your changes are missing coverage. Please review.

Comparison is base (413d307) 69.58% compared to head (4199a2f) 70.60%.

Files
Patch %
Lines

...t-agent/src/erniebot_agent/chat_models/erniebot.py
42.85%
8 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #247      +/-   ##
===========================================
+ Coverage    69.58%   70.60%   +1.01%
===========================================
  Files           62       62
  Lines         3104     3106       +2
===========================================
+ Hits          2160     2193      +33
+ Misses         944      913      -31

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


Update EGW status only if it has changed.

Description
Update the EGW status only when it has changed. When creating multiple EGWs (around 50 EGW CRs), operator is stuck in a reconcile loop and this results in a lot of API calls.
For PR author

[ ] Tests for change.
[ ] If changing pkg/apis/, run make gen-files
[ ] If changing versions, run make gen-versions

For PR reviewers
A note for code reviewers - all pull requests must have the following:

[ ] Milestone set according to targeted release.
[ ] Appropriate labels:

kind/bug if this is a bugfix.
kind/enhancement if this is a a new feature.
enterprise if this PR applies to Calico Enterprise only.

https://tigera.atlassian.net/browse/CI-1646


Prevent cache busting by the UUID of Dispatcher

First steps towards fixing #6264.
This PR changes the cache key to explicitly include the bytecode of python functions captured in closures, and also their transitive dependencies. Before, the whole Dispatcher object was pickled and included in the key, which changes for each "run" (i.e. each time a new python interpreter is started) because of the UUID.
I'm not sure if this is enough, or if other attributes of the Dispatcher objects also need to be included in the key.
As @sklam noted in the issue, the referenced functions may also need to be cached (except if they are inlined?), but I'm not sure what the best approach would be, or if the user should be required to explicitly mark them to be cached.
Please let me know if this goes into the right direction, thanks!

@sk1p thank you for submitting this enhancement to the Numba issue tracker! We appreciate your efforts to improve Numba and I have now added this PR to the review queue.

Thanks for the patch, I think this is going to need similar https://github.com/numba/numba/pull/6406


Propogate PVC access modes

When creating a PersistentVolumeClaim, propagate the accessModes. Without it, we try to use modes other than ReadWriteOnce it will stuck with improper accessMode, failing the completion of the volume populator.
Signed-off-by: Liran Rotenberg<EMAIL_ADDRESS>/kind bug
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #63
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
NONE
PersistentVolumeClaim will now get a propagated accessModes.

/lgtm
cc @bswartz  for approval


export default config

Hi CodingButter,
For Docker users, I think the commands should be documented and that may be the reason of this issue.
AWS EC2 Linux and latest Directus with Postgres Database
$ npx directus-migrator -init
.npm/_npx/2f9ed6e235e43e28/node_modules/command-line-args/dist/index.js:1202
        throw err
        ^

ALREADY_SET: Singular option already set [init=true]
    at FlagOption._set (/.npm/_npx/2f9ed6e235e43e28/node_modules/command-line-args/dist/index.js:1198:21)
    at FlagOption.set (/.npm/_npx/2f9ed6e235e43e28/node_modules/command-line-args/dist/index.js:1182:10)
    at FlagOption.set (/.npm/_npx/2f9ed6e235e43e28/node_modules/command-line-args/dist/index.js:1245:11)
    at commandLineArgs (/.npm/_npx/2f9ed6e235e43e28/node_modules/command-line-args/dist/index.js:1392:14)
    at Object.<anonymous> (/.npm/_npx/2f9ed6e235e43e28/node_modules/directus-migrator/bin/commands.config.js:95:14)
    at Module._compile (node:internal/modules/cjs/loader:1159:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1213:10)
    at Module.load (node:internal/modules/cjs/loader:1037:32)
    at Module._load (node:internal/modules/cjs/loader:878:12)
    at Module.require (node:internal/modules/cjs/loader:1061:19) {
  value: true,
  optionName: 'init'
}

$ npx directus-migrator -s development -t staging -p
/home/ec2-user/api/directus-migrator.config.js:15
export default config
^^^^^^
SyntaxError: Unexpected token 'export'
    at Object.compileFunction (node:vm:360:18)
    at wrapSafe (node:internal/modules/cjs/loader:1088:15)
    at Module._compile (node:internal/modules/cjs/loader:1123:27)
    at Module._extensions..js (node:internal/modules/cjs/loader:1213:10)
    at Module.load (node:internal/modules/cjs/loader:1037:32)
    at Module._load (node:internal/modules/cjs/loader:878:12)
    at Module.require (node:internal/modules/cjs/loader:1061:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.<anonymous> (/.npm/_npx/2f9ed6e235e43e28/node_modules/directus-migrator/bin/cli.js:9:58)
    at Module._compile (node:internal/modules/cjs/loader:1159:14)

$ node -v
v18.12.1

I went ahead and changed export default config into module.exports = config; and then it crashed on:
$ npx directus-migrator --permissions -s development -t staging
...
2023-06-14 [unknown] info: Migrating Roles
(node:44744) ExperimentalWarning: The Fetch API is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
2023-06-14 [unknown] info: Retrieved Roles from development
2023-06-14 [unknown] info: Retrieved Roles from staging
2023-06-14 [unknown] info: Created: 7, Deleted: 6
2023-06-14 [unknown] info:
2023-06-14 [unknown] info: Created 7 Role/s
2023-06-14 [unknown] info:
2023-06-14 [unknown] info:
2023-06-14 [unknown] info:
2023-06-14 [unknown] info:
2023-06-14 [unknown] info:
2023-06-14 [unknown] info:
2023-06-14 [unknown] info: Migrating Roles Complete
2023-06-14 [unknown] info: Migrating Permissions
2023-06-14 [unknown] info: Created: 457, Updated: 0, Deleted: 395
/home/jorge/.npm/_npx/2f9ed6e235e43e28/node_modules/directus-migrator/dist/migrators/role-migration.js:121
            throw new Error(failMessage(roleResponse));
                  ^

Error: Failed to Delete roles
 false
    at /home/jorge/.npm/_npx/2f9ed6e235e43e28/node_modules/directus-migrator/dist/migrators/role-migration.js:121:19
    at Generator.next (<anonymous>)
    at fulfilled (/home/jorge/.npm/_npx/2f9ed6e235e43e28/node_modules/directus-migrator/dist/migrators/role-migration.js:28:58)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Node.js v18.12.1

Users got suspended exept me as Admin

Users lost association with their Role

I wasn't aware it would sync their RoleID's ( thanks!)

Tested with Directus 10.13.0 (Docker)

Should you require more information, I'll be happy to assist you.

It worked n a fresh database but I still have to change export default config  for module.exports = config;


Model builder improvements , Image classification scenario .

Great job guys !!! some suggestions ...
Add the chance to do all model builder steps , including code generation , by using GPU.
Add the chance to made  multiple test classification ( as example by  loading images from a folder).
Add the chance to made test classification by loading an existing model.
Add the chance to load images from SQL database from varbinary field.

Thank you for your feedback, Great suggestions! We will take it into consideration.

@JakeRadMSFT To break up this issue into correct epics.

@mauryflag - I'm splitting up this issue so that we can triage/prioritize each suggestion separately.
"Add the chance to do all model builder steps , including code generation , by using GPU."
For this do you mean having the generated code use GPU (like just update the NuGet reference to be the GPU tensorflow)?
Add the chance to made multiple test classification. Semi related - #60 #1588

"Add the chance to made multiple test classification." Semi related - #60 #1588

"Add the chance to made test classification by loading an existing model"
@mauryflag Can you expand on this one a bit? We added the ability to save and re-open mbconfig ... does that work for this?

Thanks for the suggestions! These are being tracked in the linked issues. Thanks!


(PUP-7293) Ensure that Hiera 3 interpolated options are evaluated

Only the datadir option in a Hiera 3 backend specific options entry was evaluated. This PR ensures that all keys and values in the options hash gets interpolations evaluated.

ok to merge when tests go green

I retarget this to stable


error on sharp.tile

env: virtual box  centos 7
sharp('file')
          .tile()
          .toFile(outputFilePath + 'output.dzi', function(err, info) {
            console.log(err);
            console.log(info);
          });

jpg filesize (139 MB), 21250px * 7950px
vips warning: vips_mapfile: map failed (Invalid argument), running very low on system resources, expect a crash soon
vips warning: vips_mapfile: map failed (Invalid argument), running very low on system resources, expect a crash soon
Error: vips_mapfile: unable to mmap
unix error: Invalid argument
vips_mapfile: unable to mmap
unix error: Invalid argument

Hello, the error suggests libvips is failing to mmap enough memory for an operation at mapfile.c#L176. The flags used for the mmap call include MAP_SHARED.
http://stackoverflow.com/a/18421071/4625124 suggests VirtualBox (sensibly) prevents memory sharing outside the hypervisor's boundary. Ensuring all file system operations use the guest drive should allow you to work within the security constraints of VirtualBox.


sudoku-backend API doc doesn't build

And therefore doesn't upload so it's not available under the specified link.
This is due to https://github.com/rust-lang/rust/issues/51661 and will be fixed automatically when that lands.

After discussion and a diesel issue, this is the new tracking target.
(However, docs do build now, except I'm livepatching the diesel source on CI.)


Markdown preview

Type: Bug
When I open a .md file in split view (with preview), the preview display is not in vertical alighment with the raw source code pane.
The preview pane would have scrolled down entirely and we only get to see the last one line of the preview.  This is a very unpleasant experience, as we don't get to see the full context of the preview.

If it does, please share the markdown source as text

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


added methods to get screen resolution of any devices

Added methods to get the screen resolution of any devices.

HI Team,
Could you please review my request as the tests are failing for no reason.
Thanks


[IRGen+Runtime] Fix tag bit mask handling for objc, unknown objects a…

…nd blocks
rdar://138487964
On platforms that don't have reserved bits in objc (including unknown) pointers, we use the spare bits for Swift enums, so they have to be masked out. Blocks don't have reserved bits on any platform.

@swift-ci test


High latency for Amplify hosted site

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

Describe the bug
We're hosting a SPA site stored in S3 using Amplify and Cloudfront. Our TTFB is routinely 300ms-500ms even when getting CloudFront hits and we have performance mode enabled. Why is this delay so high and is there anything we can do about it?

Expected behavior
Ideally, TTFB below 300ms
Reproduction steps
Go to site https://www.essentialclinic.ca, open dev tools, inspect network requests.
Build Settings
No response
Additional information
No response

Just to add another data point, I refreshed the page today and see that TTFB was a whopping 1.43 seconds! The x-cache even says 'Hit from cloudfront'. TTFB should be under 100ms if it's a CDN cache hit no?

yes, this is painful, @chriskinzel do you have found how to solve this problem ?

Hi there, we are experiencing this same problem with a SSR Next.js app. TTFB is regularly 300ms+ on all resources. We are testing using the provided amplify domain, not a custom domain, so the domain shouldn’t be a factor. Can anyone help with this?

Hi there, we are experiencing this same problem with a SSR Next.js app too. Can anyone help with this?


fix keywords description

fix #1286
Check List
Please read and check followings before submitting a PR.

[ ] I want to publish my theme on Hexo official website.

[ ] I have read the theme publishing doc.
[ ] name is unique.
[ ] link URL is correct.
[ ] preview URL is correct.
[ ] preview URL web site is rendered correctly.
[ ] Add a screenshot to source/themes/screenshots.
[ ] Screenshot filename is same as value of name.
[ ] Screenshot size is 800 * 500.
[ ] Screenshot file format is png.

[ ] I want to publish my plugin on Hexo official website.

[ ] I have read the plugin publishing doc.
[ ] name is unique.
[ ] link URL is correct.

[ ] Others (Update, fix, translation, etc...)

Languages:
[x] en English
[x] ko Korean
[x] pt-br Brazilian Portuguese
[x] ru Russian
[x] th Thai
[x] zh-cn simplified Chinese
[x] zh-tw traditional Chinese

I want to join hexo org.

As I commented https://github.com/hexojs/site/issues/1286#issuecomment-590023650, "keywords" can be a string. Since open_graph supports both string and array, you could say "Separate multiple keywords with commas , or specify them in an array`.
Examples are not required since user is expected to know how to use array in yaml.

LGTM. Note that future behavior could change hexojs/hexo#4174.

@curbengh A breaking change for Hexo 5.0.0? By the way reading https://github.com/hexojs/hexo/pull/4174 I learned the true behavior of keywords. I thought it was only for HTML meta tag:
 <head>
  <meta charset="UTF-8">
  <meta name="description" content="Free Web tutorials">
  <meta name="keywords" content="HTML, CSS, JavaScript">
  <meta name="author" content="John Doe">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>

The current behavior is a duplicate and miss-leading so it's a good thing to remove it, but maybe instead it can be turned in injecting keywords in <meta name="keywords" content="HTML, CSS, JavaScript"> or tags of each posts are already injected in there?

https://github.com/hexojs/site/pull/1478


Is the project still being maintained?

Hello,
This is really incredible! I want to use it for my project.
Just curious if this code is still being maintained ?
Best regards

Hi, thanks.
The current bottleneck of the project is the testLod method which is done on the cpu and scales with the number of individual meshlets on the scene, the algorithm can be ported to the gpu but it would benefit a lot from drawIndirect (webgpu) but threejs does not support it yet (https://github.com/mrdoob/three.js/issues/28389). To make it work with webgl quite some hacks are needed and i dont think we can get away from at least one gpu->cpu->gpu trip which is expensive. Some type of broad and narrow phase test can also be experimented with to increase its performance.
Other than that the code can be cleaned:

Integrate the meshlet generation simplification etc into one MeshletMesh class to make it more streamline with the threejs api.
Port the wasm code (meshoptimizer/metis) to typescript in order to be dependency free.
Relevant to the point above, ideally, get rid of metis since meshoptimizer has a meshlet generation method, albeit not as good.

Specifically in terms of code maintenance the above can be done but having the testLod bottleneck kinda makes the cleanup a bit pointless, PR's are welcomed though.
I may revisit the project in the future since it seems to be getting some attention.

I think meshoptimizer recent release now has a good meshlet generation. I will love to contribute, also I can't wait for Mesh shader to be supported on webgpu; this will enable us to draw triangles directly and make culling easier! I'm hoping other three.js developers will love to contribute to this amazing project.
Cheers!

You could also use compute shaders for that, right? I use these very extensively in my Ocean2 repo.
I recalculate the wave spectrum of the ocean at every interval using computer shaders. The data saves my compute shader in f32 textures. Vertex shader and fragment shader can access these directly. The performance with the huge amounts of data is impressive.
I've long wanted to make the ocean transparent with scattering so that you can authentically see underwater objects, but I just don't have the time. I'm very busy with my new mars project.
I trimmed your repo to WebGPU because I only work with WebGPU in three.js.
I don't want to make any promises that I can't keep due to time constraints, but I'm very familiar with WebGPU in three.js and I'd like to help if I can.


Can anyone else iterate on a Google_Service_Storage_Objects?

Hey,
I'm trying to foreach on a Google_Service_Storage_Objects returned by Google_Service_Storage->objects->listObjects(). var_dumping the returned Google_Service_Storage_Objects clearly shows the objects in the bucket. However, attempting to iterate on the Google_Service_Storage_Objects seems to fail. I thought this would've worked:
$bucket = $gcs_service->objects->listObjects("my_bucket");
foreach($bucket as $object){
  var_dump($object);
}

In addition count($bucket) always returns int(0). I'm using compose require google/apiclient="^1.1" which is currently 1.1.4.
Any help is greatly appreciated. Thanks!

p.s the foreach does not throw any errors, it just does nothing. I think its because $bucket->valid() returns false all the time.

Doesnt seem at all possible. Ended up doing something like
        $nextPageToken = NULL;
        do {
          $objs = $client->objects->listObjects($bucket, [
            "pageToken"  => $nextPageToken
          ]);

          $nextPageToken = $objs->getNextPageToken();

          foreach($objs->getItems() as $item)
          {
            ...
          }
        } while ( $nextPageToken );


Add directions to README for Windows Users

For example, if someone is using Git Bash for Windows, they will not have the ability to run the make command.
This command could be replaced by a few mkdir and a cp.
I was personally able to figure it out on my own, but it would be nice if the commands were simply in the README.

I have run into the same issue, however have not been able to fix it...

@RoryMiley you can do it something like this-
Make a new directory like ~/.local/bin
cp the bashmarks.sh file into that directory
Add the code source ~/.local/bin/bashmarks.sh into your bash profile. So that script will get run every time you open your shell.


Tracing support

I'd like to re-suggest adding tracing support. My current workaround whenever I write a cli is to add clap-verbosity-flag, tracing-log, and add a method which calls level_filter().as_trace() to the parser. This seems like code which should just be part of the verbosity flag and feature flagged in.
Previously:

https://github.com/clap-rs/clap-verbosity-flag/pull/87 was closed suggested opening an issue.
https://github.com/clap-rs/clap-verbosity-flag/pull/44 was closed suggesting opening an issue.

suggests feature flags

https://github.com/clap-rs/clap-verbosity-flag/pull/37 was closed as another PR had a demo of manually working around the problem

Questions previously raised (paraphrased):

How mature is tracing?
Tracing 0.1 has the same order of magnitude daily / all time downloads as log / clap (200M vs 340M / 300M). While this is not a perfect indication of stability / maturity, it implies that making a breaking change would have large impact on a large portion of the rust ecosystem. Development of tracing happens on its master branch which tracks a long running yet to be released 0.2.x, with changes that are backwards compatible are backported to 0.1.x. The core LevelFilter and Level types are unchanged between the versions. Also, the tracing-core crate (where level and levelfilter ultimately live) contains the following in its readme:

Application authors will typically not use this crate directly. Instead, they will use the tracing crate, which provides a much more fully-featured API. However, this crate’s API will change very infrequently, so it may be used when dependencies must be very stable.

How should this support tracing 0.1, 0.2, .... Does doing so require this library to go to 2.0 to support the next version etc.
It's fairly common for libs that want to support multiple versions of libs to have versioned feature flags. E.g. here that would be tracing / tracing-0.1 / tracing-0.2 etc. The same question applies to log though. What happens when log 0.5 comes out? I'd recommend adding a tracing feature, and having that be mean the latest version of tracing, while adding a tracing-0.1 feature when tracing-0.2 comes out. You could pre-create a -01 feature and only use that. @epage you likely have much more insight into the right choice here than most people. Perhaps pick an approach that makes sense, or accept one that is good enough?
How do tracing users generally feel about still requiring log? If a breaking change is involved in the future, should we allow disabling it?
IMO, it should be in a feature flag enabled by default for backwards compatibility
For tracing, is it more appropriate to return Level or LevelFilter?
LevelFilter is struct LevelFilter(Option<Level>), and LevelFilter::OFF is LevelFilter(None). It makes some sense to have both as there are two possible use cases for these settings - directly using the value to filter logs, or using the Level to perform further config from other sources (e.g. environment vars, config files, etc). The former is simplest with LevelFilter, the latter is simplest with Option. Having just one loses symmetry with the existing log crate Level/LevelFilter values. I'd recommend keeping both.

So:

add a tracing feature flag
add a log feature flag
make log default
add fn tracing_level() -> Option<tracing_core::metadata::Level>
add fn tracing_level_filter() -> tracing_core::metadata::LevelFilter()
update CI to test these and examples to test both.

I'm going to open another PR that aligns with the recommendations above as the code to do this is much more concise / less ambiguous than the narrative above.

IMO, it should be in a feature flag enabled by default for backwards compatibility

Moving built-in functionality into a default feature is not backwards compatible.

Thank you for taking the time for stepping through and evaluating the different sides to this that need to be addressed for being able to move this forward as well as including a recommendation.

How mature / stable is tracing for being a 0.1 crate? We just went 1.0 and I don't want to repeatedly bump by taking on a potentially volatile dependency

When I said that, I hadn't accounted for clap's API stability which seems to be less than log and tracing.  I was also a lot less familiar with tracing as I don't use it myself (and I still barely use it).
However, the compounding affect of more crates in a stable API is not ideal.  If log becomes optional, its also annoying that we would need to dual-implement all of the logic (though it is relatively small though there is still care to be taken as shown in #115).  Having versioned features is an option for addressing this.
It didn't help that it came months within a breaking release as I'm getting pressure from people on other projects to not issue breaking releases too often.  Its likely been sufficient time since the last breaking release that we could consider one (for making log optional). I keep hoping to get to clap v5 "soon" though its likely not too soon.
So the main question is whether to make a breaking release with log or tracing breaking releases or to version the feature flags.  Is there a reason you went with unversioned feature flags?

Yes but here that only breaks those that are actively using default-features = false, but this crate has no default features that that would affect, so crates doing that are in a weird state already.

I know people who always set default-features = false and then opt-in to features on an individual basis, rather than accepting what features a crate author chooses for defaults.

In taking a look at this though, the main problem with making log optional is that the LogLevel trait's default function, which returns Optionlog::Level, that's then used to calculate the verbosity number. To me this suggests just dropping that, implementing the verbosity value as a number and adding levels for Debug/Trace/Off makes sense. That might be a breaking change though.

Something I regret is focusing on Level rather than LevelFilter.  Looks like there is a log::LevelFilter::from_usize, so they have a stable mapping of number to log level.
This is not true for tracing but if we say that the number corresponds to the log API, then it would be ok to have Verbosity to handle the translation for tracing.
So my current thought

This is a breaking change
Change LogLevel::default to return a usize
Move log behavior behind a log default feature gate (I'd prefer this to be explicit in Cargo.toml, rather than just making the dependency optional)
Add a tracing feature and the corresponding functionality
Add or update tests to ensure the two levels always come out the same

Nothing should need to be changed in our CI workflows because we use cargo hack to test all feature combinations.  Yes, there are no features today but I maintain a consistent project template, regardless of the needs of a single project (https://github.com/epage/_rust).

That all sounds about right to me. The other thing I'd add is notifying the various repos that implement LogLevel of the replacements (and the related change for the added log levels. It's not a huge number (24, 32 if you include forks), and the users may appreciate the heads up.

Hmm, wasn't thinking of that part of this  LogLevel::default requires them to emit an arbitrary number.
sigh maybe we need a u8 newtype so people can set the default without knowing numbers and without tying to log?

That makes more sense

Thinking more on this. If a breaking change is an option, then we can do better than using a number to indicate the verbosity and make LogLevel generic over the type of level filter instead. This would be breaking for any implementations of LogLevel, but mostly code compatible with apps that don't implement this manually. Taking a look over the 24 repos that do implement the trait, most are just implementing Debug, Trace, Off etc. 2 or 3 implement feature flag / config -> default log level, and 4 or 5 implement custom help messages, so any transition effort should be fairly small (at least in public code).
This is working prototype code that demonstrates making the LogLevel trait into LogLevel { type = LevelFilter }, with the existing implementations of this being named as-is (could easily type alias these for consistency too), and the new Tracing types named e.g. TracingErrorLevel, TracingInfoLevel etc. (could easily move these into a tracing module too).
Note that this changes the default function to instead deal with the LevelFilter as the primary trait method, rather than Option<Level>, which is generally what interactions with log/tracing need to perform filtering.
#![allow(unused)]
use clap::{ArgAction, Args, Parser};
use log::LevelFilter as LogLevelFilter;
use tracing::{level_filters::LevelFilter as TracingLevelFilter, Level as TracingLevel};

fn main() {
    let args = DefaultCli::parse();
    dbg!(args.verbosity.log_level_filter());
    let args = LogCli::parse();
    dbg!(args.verbosity.log_level_filter());
    let args = TracingCli::parse();
    dbg!(args.verbosity.tracing_level_filter());
}

#[derive(Debug, Parser)]
struct DefaultCli {
    #[command(flatten)]
    verbosity: Verbosity,
}

#[derive(Debug, Parser)]
struct LogCli {
    #[command(flatten)]
    verbosity: Verbosity<ErrorLevel>,
}

#[derive(Debug, Parser)]
struct TracingCli {
    #[command(flatten)]
    verbosity: Verbosity<TracingErrorLevel>,
}

#[derive(Debug, Clone, Default, Args)]
#[command(about = None, long_about = None)]
struct Verbosity<L: LogLevel = ErrorLevel> {
    #[arg(
        long,
        short = 'v',
        action = ArgAction::Count,
        global = true,
    )]
    verbose: u8,

    #[arg(
        long,
        short = 'q',
        action = ArgAction::Count,
        global = true,
        conflicts_with = "verbose",
    )]
    quiet: u8,

    #[arg(skip)]
    phantom: std::marker::PhantomData<L>,
}

impl<L: LogLevel<LevelFilter = LogLevelFilter>> Verbosity<L> {
    pub fn log_level(&self) -> Option<log::Level> {
        self.log_level_filter().to_level()
    }

    pub fn log_level_filter(&self) -> LogLevelFilter {
        let verbosity = Self::verbosity() as i16 - self.quiet as i16 + self.verbose as i16;
        let verbosity = verbosity.clamp(0, 5);
        match verbosity {
            0 => LogLevelFilter::Off,
            1 => LogLevelFilter::Error,
            2 => LogLevelFilter::Warn,
            3 => LogLevelFilter::Info,
            4 => LogLevelFilter::Debug,
            5 => LogLevelFilter::Trace,
            _ => unreachable!(),
        }
    }

    fn verbosity() -> u8 {
        match L::default_level_filter() {
            LogLevelFilter::Off => 0,
            LogLevelFilter::Error => 1,
            LogLevelFilter::Warn => 2,
            LogLevelFilter::Info => 3,
            LogLevelFilter::Debug => 4,
            LogLevelFilter::Trace => 5,
        }
    }
}

impl<L: LogLevel<LevelFilter = TracingLevelFilter>> Verbosity<L> {
    pub fn tracing_level(&self) -> Option<TracingLevel> {
        self.tracing_level_filter().into_level()
    }

    pub fn tracing_level_filter(&self) -> TracingLevelFilter {
        let verbosity = Self::tracing_verbosity() as i16 - self.quiet as i16 + self.verbose as i16;
        let verbosity = verbosity.clamp(0, 5);
        match verbosity {
            0 => TracingLevelFilter::OFF,
            1 => TracingLevelFilter::ERROR,
            2 => TracingLevelFilter::WARN,
            3 => TracingLevelFilter::INFO,
            4 => TracingLevelFilter::DEBUG,
            5 => TracingLevelFilter::TRACE,
            _ => unreachable!(),
        }
    }

    fn tracing_verbosity() -> u8 {
        match L::default_level_filter() {
            TracingLevelFilter::OFF => 0,
            TracingLevelFilter::ERROR => 1,
            TracingLevelFilter::WARN => 2,
            TracingLevelFilter::INFO => 3,
            TracingLevelFilter::DEBUG => 4,
            TracingLevelFilter::TRACE => 5,
        }
    }
}

trait LogLevel {
    type LevelFilter;
    fn default_level_filter() -> Self::LevelFilter;
}

#[derive(Debug, Clone, Default)]
struct ErrorLevel;

impl LogLevel for ErrorLevel {
    type LevelFilter = LogLevelFilter;
    fn default_level_filter() -> Self::LevelFilter {
        Self::LevelFilter::Error
    }
}

#[derive(Debug, Clone, Default)]
struct TracingErrorLevel;

impl LogLevel for TracingErrorLevel {
    type LevelFilter = TracingLevelFilter;
    fn default_level_filter() -> Self::LevelFilter {
        Self::LevelFilter::ERROR
    }
}

Ah, looks like I looked at things out of order.
If we're including tracing, we should not be bifurcating the entire code base to do so.  We should have one type for each level and one type for clap.

If we're including tracing, we should not be bifurcating the entire code base to do so. We should have one type for each level and one type for clap.

Yep, I think the dual types / associated Level/LevelFilter types definitely complicates things a bit too much. I changed this to instead be a few methods that are log specific and a few that are tracing specific.
If there was an open ended number of logging crates to support, this be the wrong decision, but this number should always be fairly small.

Hi all, thank you @joshka for the new feature, I've just started using clap-verbosity-flag and wondered if the tracing support was possible and then stumble upon your issue. I've followed the development a bit, and was happy that the new version came out with this feature.
But I still have an error trying to use it in my code, simply rustc doesn't seem to find the function in the lib:
no method named `tracing_level` found for struct `Verbosity` in the current scope

And here's what I did to try to use this feature:

I've added inside the Cargo.toml this line: clap-verbosity-flag = {version = "3.0.0", feature = ["tracing"]}
I've configure it like the tracing example https://github.com/clap-rs/clap-verbosity-flag/blob/master/examples/tracing.rs . More precisely:

use clap::{Parser, ValueEnum};
use clap_verbosity_flag::Verbosity;

#[derive(Parser, Debug)]
#[command(author, version, about, long_about = None)]
struct Args {
    //...
    #[command(flatten)]
    verbose: Verbosity,
}

fn main() -> anyhow::Result<()> {
    let args = Args::parse();

    let file_appender = tracing_appender::rolling::RollingFileAppender::builder()
        .rotation(Rotation::NEVER)
        .filename_prefix(Utc::now().format("%+").to_string())
        .filename_suffix("test.log")
        .build("logs/")
        .context("Initializing rolling file appender failed")?;

    let (non_blocking, _guard) = tracing_appender::non_blocking(file_appender);

    let stdout = std::io::stdout.with_max_level(&args.verbose.tracing_level()); <--- error here
    tracing_subscriber::fmt()
        .with_ansi(false)
        .with_writer(stdout.and(non_blocking))
        .init();

    //...
}

I've also done a cargo clean and made sure it downloaded the 3.0.0, version of the crate.
Any guidance would be appreciated!
Thanks again for the awesome feature :)

I tried to reproduce the error you get but wasn't able to
#!/usr/bin/env nargo
---
[dependencies]
clap = { version = "4", features = ["derive"] }
clap-verbosity-flag = { version = "3", default-features = false, features = ["tracing"] }
tracing-subscriber = "*"
tracing = "*"
anyhow = "1"
---

use clap::Parser;
use clap_verbosity_flag::Verbosity;
use tracing_subscriber::fmt::writer::MakeWriterExt;

#[derive(Parser, Debug)]
#[command(author, version, about, long_about = None)]
struct Args {
    //...
    #[command(flatten)]
    verbose: Verbosity,
}

fn main() -> anyhow::Result<()> {
    let args = Args::parse();

    let stdout = std::io::stdout.with_max_level(args.verbose.tracing_level().unwrap_or(tracing::Level::ERROR));
    tracing_subscriber::fmt()
        .with_ansi(false)
        .init();
    Ok(())
}

Note: with_max_level doesn't seem to support, through its parameter, being able to turn off logging

Any guidance would be appreciated!

To understand what features are enabled for your app and why, run:
cargo tree --edges features -i clap-verbosity-flag

Note: with_max_level doesn't seem to support, through its parameter, being able to turn off logging

Generally speaking, it makes sense to use the filter and not the Option<Level> (i.e. call tracing_level_filter instead of tracing_level, but None should be the same as turning off the logging. Are you seeing something different?
    let stdout = std::io::stdout.with_max_level(args.verbose.tracing_level().unwrap_or(tracing::Level::ERROR));
    tracing_subscriber::fmt()
        .with_ansi(false)
        .init();

The stdout var is unused by the tracing code there. It's creating a function that creates a writer with a specific level, but never actually using that. The subscriber builder also has a with_max_level method, so you can skip stdout from the code altogether.
Given that the with_max_level function accepts Into, it could be worthwhile implementing From<Verbosity> for LevelFilter, which would simplify that example to something like:
fn main() -> anyhow::Result<()> {
    let args = Args::parse();

    tracing_subscriber::fmt()
		.with_max_level(args.verbose)
        .with_ansi(false)
        .init();
    Ok(())
}


Powershell version relation to .Net Standard, Core and/or framework versions

I have spend quite a lot of time looking for answer to this question but could not find it. While this might not be the correct forum for this type of question but I couldn't find any other forum to ask this. I really need some help here since I couldn't even find an answer on reading Microsoft Powershell docs.
I want to know the relation between Powershell versions (windows powershell and powershell core) and .Net Standard (Core and Framework) versions.
As a concrete example, If I have a powershell cmdlet built for target framework .Net Standard 2.0, how do I find which powershell versions (both windows powershell and powershell core), will it work on?
My understanding was as long as .Net Standard 2.0 or higher based implementation of .Net Core or .Net framework is installed on users machine, it doesn't matter which powershell version the user uses. The cmdlet should work. But then, users don't explicitly install these .NET versions on their machines. They are installed by default on Windows or as part of powershell core(?) on cross platform OSes. Can someone please help understand this relation and answer my question?

They are installed by default on Windows or as part of powershell core(?) on cross platform OSes.

First look about "self-contained" and " runtime-dependent" .Net Core applications
https://docs.microsoft.com/en-us/dotnet/core/deploying/

In addition to what @iSazonov mentioned, Windows PowerShell is always runtime dependent.  For a netstandard2.0 library to work within Windows PowerShell, the user will need at least net framework 4.7.1 installed (or I think 4.6.2 if you ship the netfx version of the netstandard.dll shim with your library)
More simply put, if you target netstandard2.0 it will work:

In Windows PowerShell if net framework 4.7.1 is installed on the machine
In PowerShell Core/PowerShell 7+.  Core can be runtime dependent too but any version should be compatible with netstandard2.0 iirc

Also see https://github.com/PowerShell/PowerShell/issues/6475#issuecomment-375798893
https://docs.microsoft.com/en-us/powershell/scripting/learn/writing-portable-modules?view=powershell-7

The doc that @iSazonov linked to is expected to answer this question.  If there's anything unclear or missing, please open as a doc bug in https://github.com/MicrosoftDocs/PowerShell-Docs

Thanks folks. I do have some follow on questions but first will read the docs pointed by you and see if they get answered there. Will respond back after that.

@viralmodi If you have an interest please document and share you experience.

@iSazonov @SeeminglyScience @SteveL-MSFT
I read the links and while they were useful; they couldn't answer all my questions. Here are my follow-on questions. Let's say I have a powershell cmdlet with target framework of .NET Standard 2.0 (run-time dependent and not self-contained)

Will it work with Windows powershell 2.0, 3.0, 4.0, 5.0, 5.1?
Will it work with Powershell core versions 5.0, 6.0 and 7.0?
If I have powershell 3.0 installed which as per this link (https://docs.microsoft.com/en-us/powershell/scripting/install/windows-powershell-system-requirements?view=powershell-7) requires .NET framework 4, will my cmdlet work on it?
Same condition as #3 question above but let's say if I externally install .NET framework 4.6.1 (or 4.7.x) from MSFT website on my machine, will it work with powershell 3.0 now?

Let's say I have a powershell cmdlet with target framework of .NET Standard 2.0 (run-time dependent and not self-contained)

The choice of run time dependent vs self contained is up to the host application, which in this case is PowerShell. This would only be your decision if you were running outside of PowerShell, or if you were hosting it.  I'm being a little pedantic here admittedly, but it can be an important distinction.

Will it work with Windows powershell 2.0, 3.0, 4.0, 5.0, 5.1?

Not 2.0, that specifically requires a much older CLR version which is only supported by net framework 3.5 and below.  Everything else, depends on if netfx 4.7.1 (or 4.6.2 if you ship the shim) is installed on the target machine. That said the version of PowerShellStandard.Library built for 3.0 hasn't seen a lot of love (or adoption).  YMMV for anything under 5.1.

Will it work with Powershell core versions 5.0, 6.0 and 7.0?

Definitely 6.0 and 7.0.  If by 5.0 you mean the version of PS core that was in nano I'm not sure, but probably not. iirc that had a really early build of .NET core which almost definitely wasn't netstandard2.0 compliant.  Is that still available through something? cc @SteveL-MSFT

If I have powershell 3.0 installed which as per this link (https://docs.microsoft.com/en-us/powershell/scripting/install/windows-powershell-system-requirements?view=powershell-7) requires .NET framework 4, will my cmdlet work on it?
Same condition as #3 question above but let's say if I externally install .NET framework 4.6.1 (or 4.7.x) from MSFT website on my machine, will it work with powershell 3.0 now?
#4 question above is to understand that if it even matters what version of powershell I have to run my cmdlet. Does the only thing that matters is if I have a .NET Core or .Net Framework corresponding to .NET standard 2.0 installed on my client machine?

See response to #1 for answers to above.

Thanks @SeeminglyScience That answers a bunch of my questions. While you have mentioned that answers to my other questions is same as what you mentioned in #1.
I want an explicit answer to these ones:

Powershell cmdlet targetted for .NET Standard 2.0 being run in Windows Powershell 5.0 (or 4.0) - will it work? I read your answer to this as YMMV but why is it YMMV is what I don't understand.
Powershell cmdlet targetted for .NET Standard 2.0 being run in Windows Powershell 5.0 (or 4.0) and let's say I have .NET Framework 4.7.1 separately installed (I don't know if this scenario makes sense or is possible) - will it work?
The above questions only reinforce some confusion in my understanding about relation between Powershell version, Cmdlet target framework and .NET version installed on my client machine. Perhaps, a re-take on my 5th question above which I don't see an answer to or may be, I couldn't infer from your answers, might better help my understanding. Repeating again:
if it even matters what version of powershell I am running my cmdlet on. Does the only thing that matters is if I have a .NET Core or .Net Framework corresponding to .NET standard 2.0 installed on my client machine? i.e. can I direct my host application for my cmdlet, Powershell in this case, to use any installed .Net Framework on my client machine?
Thanks for patiently answering all my questions and that too pretty fast.

will my cmdlet work on it?

"Will" says that you plan new project. Strategic recommendations from .Net Core team is to start new project only on .Net Core.
You can find .Net Standard compatibility table in docs https://docs.microsoft.com/en-us/dotnet/standard/net-standard#net-implementation-support

@iSazonov  Yes that is correct. It's a new project I am working on.
Based on MSFT and Azure doc reading, I realized that its better to target .NET Standard compared to .NET framework or .NET Core if the product is targeted towards Windows and other OSes.
I had referred that table earlier as well. It had helped me understand the relation between .NET standard, .NET Core and .NET framework.
I am still looking to get answers to my questions above. This is to get better grasp on relation between Powershell version, .NET version/s installed on the machine and my product's target framework. Can you please answer my questions above?

MSFT supports only Windows PowerShell 5.1 (maybe still 5.0) and it is only servicing support (critical and security fixes). The same is true for .Net Framework - 4.7 and 4.8 has only servicing support.
If you do not have to support old versions like Windows 7 you have no need to invest in compatibility with .Net Framework.
Also PowerShell Core has not compatibility with Windows PowerShell 2.0 and 3.0 at all.

In that case, what is the latest version of Powershell that can be used on Windows? Can we use Powershell 6.0/7.0 based on .NET Core implementation on windows as well?

Current PowerShell version is 7.0. It is LTS (supported as .Net Core 3.1).
(6.2 is still supported some months)
So if your project is targeted to .Net Standard 2.0 and reference PowerShell Standard library your application will works on all supported systems (Windows and Unix-s) and Windows PowerShell 5 too.

@iSazonov Thanks.
At this point, I do not have information on whether we need to support old versions. But I am going to go with support for Windows Powershell 5.1 (with .NET Framework 4.7.2 installed), Powershell Core 6.0+ which based on this thread will work with target framework .NET Standard 2.0 for my project.

@viralmodi On top of the GitHub page you can find "Used by" button - this helps you to find sample projects.

Sure. Thanks. This discussion was very helpful


module 'time' has no attribute 'clock'

在Python 3.8中，time.clock()已经被移除了。但是切割句子时仍然使用了这个。

Simply change start = time.clock() to start = time.perf_counter() in the file: thulac/character/CBTaggingDecoder.py, the program will run well

我也有这个问题，但是在2.7版本可以运行。你可以尝试改成2.7，也可以把相应的函数替换为3.8版本的
use time.perf_counter or time.process_time instead time.clock()
改完以后，我这边3.8版本，运行成功。

Modifying the source code isn't a good practice, since that means you cannot migrate your code to a another device. Try this instead(before the official fix this):
import time
if not hasattr(time, 'clock'):
        setattr(time,'clock',time.perf_counter)

Then your code will run well no matter on a Python<3.8 or a Python>=3.8.

Simply change start = time.clock() to start = time.perf_counter() in the file: thulac/character/CBTaggingDecoder.py, the program will run well

Modifying the source code isn't a good practice, since that means you cannot migrate your code to a another device. Try this instead(before the official fix this):
import time
if not hasattr(time, 'clock'):
    setattr(time,'clock',time.perf_counter)

Then your code will run well no matter on a Python<3.8 or a Python>=3.8.

It works. Thank you.