Androidmanifest.xml problem and emulator problem..

Hello everyone, I have this problem that I don't know how to fix. Could someone please help me, i have this androidmanifest.xml problem, and also when I run something on my emulator, it shows this.
TypeError: Cannot read property 'app' of undefined
at Object.app$ [as app] (http://localhost:57556/packages/firebase_core_web/src/interop/core.dart.lib.js:31:101)
at new cloud_firestore_web.FirebaseFirestoreWeb.new (http://localhost:57556/packages/cloud_firestore_web/src/write_batch_web.dart.lib.js:773:64)
at Function.registerWith (http://localhost:57556/packages/cloud_firestore_web/src/write_batch_web.dart.lib.js:692:73)
at Object.registerPlugins (http://localhost:57556/packages/first_flutter_app/generated_plugin_registrant.dart.lib.js:16:46)
at main (http://localhost:57556/web_entrypoint.dart.lib.js:31:35)
at main.next ()
at runBody (http://localhost:57556/dart_sdk.js:37422:34)
at Object._async [as async] (http://localhost:57556/dart_sdk.js:37453:7)
at main$ (http://localhost:57556/web_entrypoint.dart.lib.js:30:18)
at http://localhost:57556/main_module.bootstrap.js:19:10
at Array.forEach ()
at window.$dartRunMain (http://localhost:57556/main_module.bootstrap.js:18:32)
at :1:8
at Object.runMain (http://localhost:57556/dwds/src/injected/client.js:8825:21)
at http://localhost:57556/dwds/src/injected/client.js:22713:19
at _wrapJsFunctionForAsync_closure.$protected (http://localhost:57556/dwds/src/injected/client.js:3851:15)
at _wrapJsFunctionForAsync_closure.call$2 (http://localhost:57556/dwds/src/injected/client.js:11063:12)
at Object._asyncStartSync (http://localhost:57556/dwds/src/injected/client.js:3815:20)
at main__closure1.$call$body$main__closure (http://localhost:57556/dwds/src/injected/client.js:22725:16)
at main__closure1.call$1 (http://localhost:57556/dwds/src/injected/client.js:22652:19)
at StaticClosure._rootRunUnary [as call$2$5] (http://localhost:57556/dwds/src/injected/client.js:4185:16)
at _CustomZone.runUnary$2$2 (http://localhost:57556/dwds/src/injected/client.js:12436:39)
at _CustomZone.runUnaryGuarded$1$2 (http://localhost:57556/dwds/src/injected/client.js:12383:14)
at _ControllerSubscription._sendData$1 (http://localhost:57556/dwds/src/injected/client.js:11959:19)
at _DelayedData.perform$1 (http://localhost:57556/dwds/src/injected/client.js:12148:59)
at _PendingEvents_schedule_closure.call$0 (http://localhost:57556/dwds/src/injected/client.js:12197:14)
at Object._microtaskLoop (http://localhost:57556/dwds/src/injected/client.js:4023:24)
at StaticClosure._startMicrotaskLoop (http://localhost:57556/dwds/src/injected/client.js:4029:11)
at _AsyncRun__initializeScheduleImmediate_internalCallback.call$1 (http://localhost:57556/dwds/src/injected/client.js:10932:9)
at invokeClosure (http://localhost:57556/dwds/src/injected/client.js:1259:26)
at MutationObserver. (http://localhost:57556/dwds/src/injected/client.js:1278:18)
 This screenshot is of my androidmanifest.xml... It says Attribute android:icon is not allowed here...

@coja99
The error is pointing to TypeError: Cannot read property 'app' of undefined at Object.app$ [as app] (http://localhost:57556/packages/firebase_core_web/src/interop/core.dart.lib.js:31:101) at new cloud_firestore_web.FirebaseFirestoreWeb.new
Are you using cloud_firestore or any other firebase plugins ?
Can you provide flutter doctor -v and pubspec.yaml ?

flutter doctor -v
[✓] Flutter (Channel stable, 2.2.2, on macOS 11.4 20F71 darwin-x64, locale
en-GB)
• Flutter version 2.2.2 at /Users/vladajovanovic/Desktop/FlutterSDK/flutter
• Framework revision d79295af24 (5 days ago), 2021-06-11 08:56:01 -0700
• Engine revision 91c9fc8fe0
• Dart version 2.13.3
[!] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
• Android SDK at /Users/vladajovanovic/Library/Android/sdk
• Platform android-30, build-tools 30.0.3
• Java binary at: /Library/Internet
Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 16.0.1+9-24)
✗ Android license status unknown.
Run flutter doctor --android-licenses to accept the SDK licenses.
See https://flutter.dev/docs/get-started/install/macos#android-setup for
more details.
[✗] Xcode - develop for iOS and macOS
✗ Xcode installation is incomplete; a full installation is necessary for iOS
development.
Download at: https://developer.apple.com/xcode/download/
Or install Xcode via the App Store.
Once installed, run:
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
sudo xcodebuild -runFirstLaunch
✗ CocoaPods not installed.
CocoaPods is used to retrieve the iOS and macOS platform side's plugin
code that responds to your plugin usage on the Dart side.
Without CocoaPods, plugins will not work on iOS or macOS.
For more info, see https://flutter.dev/platform-plugins
To install see
https://guides.cocoapods.org/using/getting-started.html#installation for
instructions.
[✓] Chrome - develop for the web
• Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
[!] Android Studio
• Android Studio at
/Users/vladajovanovic/Desktop/FlutterSDK/flutter/Contents
• Flutter plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/6351-dart
✗ Unable to find bundled Java version.
• Try updating or re-installing Android Studio.
[✓] Connected device (2 available)
• sdk gphone x86 (mobile) • emulator-5554 • android-x86    • Android 11 (API
30) (emulator)
• Chrome (web)            • chrome        • web-javascript • Google Chrome
91.0.4472.106
! Doctor found issues in 3 categories.
And this is my pubspec:
name: first_flutter_app
description: A new Flutter project.
The following line prevents the package from being accidentally published to
pub.dev using pub publish. This is preferred for private packages.
publish_to: 'none' # Remove this line if you wish to publish to pub.dev
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.12.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: ^1.0.2
cloud_firestore: ^2.2.2
firebase_auth: ^1.4.1
firebase_storage: ^8.1.3
firebase_core: ^1.3.0
cloud_firestore_web: ^2.1.2
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/prijava.png
- images/registracija.png
- 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

@coja99
If you remove the firebase plugins and try again, does the error persist ?
cloud_firestore: ^2.2.2
firebase_auth: ^1.4.1
firebase_storage: ^8.1.3
firebase_core: ^1.3.0
cloud_firestore_web: ^2.1.2

@darshankawar
Well, if i delete that, I will have to edit my whole code...

@coja99
This seems to be an issue with Firebase. See below similar reported issues:
https://stackoverflow.com/questions/61716199/flutter-web-and-firebase-authentication-typeerror-cannot-read-property-app-of
https://github.com/FirebaseExtended/flutterfire/issues/2455
https://github.com/FirebaseExtended/flutterfire/issues/3073
Also see this issue comment / workaround / solution and check if it helps to resolve your issue.
Closing from here. If issue still persists using firebase plugins, please open this in dedicated repo: https://github.com/FirebaseExtended/flutterfire/issues


Setting update

Hi,
Just wondering if the settings around Endpoint detection and response (MDM) in step 5. It references settings that are no longer present.
Cheers
John

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: e4a20ccd-c954-e4f7-07ca-eba122d01340
Version Independent ID: ee4176d5-3fe6-f65b-6a78-a06f94ae73c0
Content: Onboarding using Microsoft Endpoint Manager - Windows security
Content Source: windows/security/threat-protection/microsoft-defender-atp/onboarding-endpoint-manager.md
Product: w10
GitHub Login: @mjcaparas
Microsoft Alias: macapara

Just to point out visually which section this is:

https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/onboarding-endpoint-manager#endpoint-detection-and-response

Select settings as required, then select  Next.

[!NOTE]
In this instance, this has been auto populated as Microsoft Defender ATP has already been integrated with Intune. For more information on the integration, see Enable Microsoft Defender ATP in Intune.

@Jlouden9 I've tested and the interface looks the same for me as in the article. What exactly are you seeing that's different? Could you share a printscreen of that?


Authorization

In this branch, we were able to achieve the following:
✅ install CanCanCan gem .
✅ Add role column to users table using a migration.
✅ Add a delete button for posts and implement functionality.
✅ Implement authorization such that the delete post button is only accessible to its author and users with admin role.
✅ Add a delete button for comments listed in a post and implement functionality.
✅ Implement authorization such that the delete comment button is only accessible to its author and users with admin role.

Thank you.


Serf reconnect

When using goiardi with serf for shovey/shob, goiardi does not reconnect to serf when the connection gets dropped (e.g. serf instance restarts).
Log:
2017/07/28 16:38:57 [ERR] agent.client: Failed to decode response header: EOF

Thanks for the heads up. Also-also, I must say I'm a bit surprised (pleased, but surprised) that someone's actually doing something with shovey -- after I went through the effort to get it all up and going I found to my disappointment and mild annoyance that no one (including myself) had much of a use case for it. Incidentally, I've been told that state of events also applies to Chef Push.

Well… I'm a bit in a hate-love relationship with Chef since 2010 so I could tell a loooong story ;-)
But to cut it short:
The only push-job use case is IMHO to force a chef-client run (which then deploys a new app release or whatever).
Some people use consul but I though why not give shovey a try. And it works nice and Serf seems to be a lot less heavy in operations as Consul.

Take a look at https://github.com/ctdk/goiardi/tree/serf-reconnecting and let me know whether or not that clears up the serf reconnecting issue.

Looks good, thank you!
Here is the log when using the branch. I killed and restarted serf:
2017/08/11 17:23:40 [DEBUG] [main] (goiardi.go:runEventMonitor:715) Got an event: map[LTime:655150 Name:node_status Payload:[...] Event:query ID:39] nil? false
2017/08/11 17:23:40 [ERR] agent.client: Failed to decode response header: EOF
2017/08/11 17:23:40 [ERR] agent.client: Failed to decode response header: EOF
2017/08/11 17:23:40 [DEBUG] [main] (goiardi.go:runEventMonitor:715) Got an event: map[] nil? true
2017/08/11 17:23:40 [DEBUG] [main] (goiardi.go:runEventMonitor:718) Serf client has been closed, returning from runEventMonitor in hopes of being able to reconnect
2017/08/11 17:23:40 [ERROR] [main] Error from event monitor: serf client closed
2017/08/11 17:23:40 [ERROR] [main] Error recreating serf client, waiting 5 seconds before recreating: dial tcp <IP_ADDRESS>:7373: getsockopt: connection refused
2017/08/11 17:23:46 [DEBUG] [main] (goiardi.go:runEventMonitor:715) Got an event: map[Event:query ID:1 LTime:655154 Name:node_status Payload:[...]] nil? false

A nitpick: Maybe you can print a message once the reconnect worked. I assume it is before the "Got an event" message.


-r -o (etc.) options

The original Franz lisp had options -r, -o (amongst others). It would be nice if PC-LISP supported those too. A -h option (with the usual semantics) would help too.

This system is not a complete clone of Franz Lisp.  It is close enough in most instances, however.  May I suggest the following.  The complete (mostly C) source to the real Franz Lisp is available.  See https://en.wikipedia.org/wiki/Franz_Lisp for many pointers.  I especially suggest http://www.aiai.ed.ac.uk/~jeff/franz-for-386.html  That last pointer is a system that did run on an early BSD environment.  I've long wanted to get it running again but just haven't had the time.


MINOR: Fix thread leak in AuthorizerIntegrationTest

Producers and consumers could be leaked in the AuthorizerIntegrationTest. In the teardown logic, removeAllClientAcls() is called before calling the super teardown method. If  removeAllClientAcls() fails, the super method does not have a change to close the producers and consumers. Example of such failure here.
As a new cluster is created for each test anyway, calling removeAllClientAcls() does not seem necessary. This patch removes it.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Failed tests are not related. Merging to trunk and 3.7.


Clean up the new Wallet design and integrate it into the wireframe

[x] Create proper components for the combined balance, transaction history, ...
[x] Replace the old flow with the new one, where Wallet and Home Screen are combined into one view
[x] Re-design the FAB to be Send and Receive only

Related tickets needed to complete for plugging the prototype togeher:

https://github.com/get10101/10101/issues/52
https://github.com/get10101/10101/issues/53

Done


Use Mermaid to document photos publication process

https://traveling-coderman.net/code/eleventy-mermaid/


McLighting V3 "Exception (3)" error

Hey, I got a error and i don't get it... I'm using a Wemos D1 mini Pro with McLighting v3, i did everything like in the tutorials and after uploading i'm getting this error:
22:19:39.750 -> --------------- CUT HERE FOR EXCEPTION DECODER ---------------
22:19:39.785 ->
22:19:39.785 -> Exception (3):
22:19:39.785 -> epc1=0x40100941 epc2=0x00000000 epc3=0x00000000 excvaddr=0x40069368 depc=0x00000000
22:19:39.785 ->
22:19:39.785 -> >>>stack>>>
22:19:39.785 ->
22:19:39.785 -> ctx: cont
22:19:39.785 -> sp: 3ffffaa0 end: 3fffffc0 offset: 0190
22:19:39.785 -> 3ffffc30:  00000000 00000027 3ffe8548 402080c0
22:19:39.785 -> 3ffffc40:  0000dc80 00001b90 00001b90 40100a43
22:19:39.785 -> 3ffffc50:  3ffe9729 00000000 5357000a 3ffffed8
22:19:39.785 -> 3ffffc60:  3fff0e1c 3ffe8665 00000020 40100cc7
22:19:39.818 -> 3ffffc70:  3ffe982b 00000000 00000000 3ffffed8
22:19:39.818 -> 3ffffc80:  4021fd74 3fff0c54 3fffff20 40236085
22:19:39.818 -> 3ffffc90:  4021fd74 3fff0c54 3ffe9727 40236070
22:19:39.818 -> 3ffffca0:  3fff0e1c 00000023 3fff0c54 40211cf6
22:19:39.818 -> 3ffffcb0:  3fff0e1c 3fff0c54 3ffe8665 40211d45
22:19:39.818 -> 3ffffcc0:  3fff0e1c 3fff0c54 3ffffec0 4020b95d
22:19:39.818 -> 3ffffcd0:  00d42c02 000003ec 00002000 00000100
22:19:39.818 -> 3ffffce0:  00000005 00000020 feefeffe feefeffe
22:19:39.852 -> 3ffffcf0:  feefeffe feefeffe feefeffe feefeffe
22:19:39.852 -> 3ffffd00:  feefeffe feefeffe feefeffe feefeffe
22:19:39.852 -> 3ffffd10:  feefeffe feefeffe feefeffe feefeffe
22:19:39.852 -> 3ffffd20:  feefeffe feefeffe feefeffe feefeffe
22:19:39.852 -> 3ffffd30:  feefeffe feefeffe feefeffe feefeffe
22:19:39.852 -> 3ffffd40:  feefeffe feefeffe feefeffe feefeffe
22:19:39.852 -> 3ffffd50:  feefeffe feefeffe feefeffe feefeffe
22:19:39.885 -> 3ffffd60:  feefeffe feefeffe feefeffe feefeffe
22:19:39.885 -> 3ffffd70:  feefeffe feefeffe feefeffe feefeffe
22:19:39.885 -> 3ffffd80:  feefeffe feefeffe feefeffe feefeffe
22:19:39.885 -> 3ffffd90:  feefeffe feefeffe feefeffe feefeffe
22:19:39.885 -> 3ffffda0:  feefeffe feefeffe feefeffe feefeffe
22:19:39.885 -> 3ffffdb0:  feefeffe feefeffe feefeffe feefeffe
22:19:39.885 -> 3ffffdc0:  feefeffe feefeffe feefeffe feefeffe
22:19:39.918 -> 3ffffdd0:  feefeffe feefeffe feefeffe feefeffe
22:19:39.918 -> 3ffffde0:  feefeffe feefeffe feefeffe feefeffe
22:19:39.918 -> 3ffffdf0:  feefeffe feefeffe feefeffe feefeffe
22:19:39.918 -> 3ffffe00:  feefeffe feefeffe feefeffe feefeffe
22:19:39.918 -> 3ffffe10:  feefeffe feefeffe feefeffe feefeffe
22:19:39.918 -> 3ffffe20:  feefeffe feefeffe feefeffe feefeffe
22:19:39.918 -> 3ffffe30:  feefeffe feefeffe feefeffe feefeffe
22:19:39.952 -> 3ffffe40:  feefeffe feefeffe feefeffe feefeffe
22:19:39.952 -> 3ffffe50:  feefeffe feefeffe feefeffe feefeffe
22:19:39.952 -> 3ffffe60:  feefeffe feefeffe feefeffe feefeffe
22:19:39.952 -> 3ffffe70:  feefeffe feefeffe feefeffe feefeffe
22:19:39.952 -> 3ffffe80:  feefeffe feefeffe feefeffe feefeffe
22:19:39.952 -> 3ffffe90:  feefeffe feefeffe feefeffe feefeffe
22:19:39.952 -> 3ffffea0:  feefeffe feefeffe feefeffe feefeffe
22:19:39.987 -> 3ffffeb0:  feefeffe feefeffe feefeffe feefeffe
22:19:39.987 -> 3ffffec0:  3fff2534 3fff259c 3fff0e1c 40223968
22:19:39.987 -> 3ffffed0:  feefeffe feefeffe 3fff2500 0010001f
22:19:39.987 -> 3ffffee0:  80efeffe feefeffe feefeffe feefeffe
22:19:39.987 -> 3ffffef0:  feefeffe feefeffe feefeffe feefeffe
22:19:39.987 -> 3fffff00:  feefeffe feefeffe feefeffe feefeffe
22:19:39.987 -> 3fffff10:  feefeffe feefeffe feefeffe feefeffe
22:19:39.987 -> 3fffff20:  3ffe8df4 3ffe9850 feefeffe 00000040
22:19:40.021 -> 3fffff30:  00000001 3ffe9859 feefeffe feefeffe
22:19:40.021 -> 3fffff40:  feefeffe feefeffe feefeffe feefeffe
22:19:40.021 -> 3fffff50:  feefeffe feefeffe feefeffe feefeffe
22:19:40.021 -> 3fffff60:  feefeffe feefeffe feefeffe feefeffe
22:19:40.021 -> 3fffff70:  feefeffe feefeffe feefeffe feefeffe
22:19:40.021 -> 3fffff80:  3fff25b4 feefeffe feefeffe feefeffe
22:19:40.021 -> 3fffff90:  feefeffe feefeffe feefeffe 3fff0da0
22:19:40.054 -> 3fffffa0:  3fffdad0 00000000 3fff0d60 402228e8
22:19:40.054 -> 3fffffb0:  feefeffe feefeffe 3ffe87cc 40100f81
22:19:40.054 -> <<<stack<<<
22:19:40.054 ->

After pasting in ExceptionDecoder:
Exception 3: LoadStoreError: Processor internal physical address or data error during load or store
PC: 0x40100941: umm_assimilate_up(uint16_t) at C:\Users\Johannes\Documents\ArduinoData\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266\umm_malloc\umm_malloc.cpp line 207
EXCVADDR: 0x40069368

Decoding stack results
0x402080c0: readStateFS() at C:\Users\Johannes\AppData\Local\Temp\arduino_build_429874\sketch/filesystem_functions.h line 158
0x40100a43: umm_free_core(void*) at C:\Users\Johannes\Documents\ArduinoData\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266\umm_malloc\umm_malloc.cpp line 351
0x40100cc7: free(void*) at C:\Users\Johannes\Documents\ArduinoData\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266\umm_malloc\umm_malloc.cpp line 398
0x4021fd74: HardwareSerial::write(unsigned char const*, unsigned int) at C:\Users\Johannes\Documents\ArduinoData\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266/HardwareSerial.h line 164
0x40236085: operator delete(void*) at /workdir/repo/gcc/libstdc++-v3/libsupc++/del_op.cc line 48
0x4021fd74: HardwareSerial::write(unsigned char const*, unsigned int) at C:\Users\Johannes\Documents\ArduinoData\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266/HardwareSerial.h line 164
0x40236070: operator delete[](void*) at /workdir/repo/gcc/libstdc++-v3/libsupc++/del_opv.cc line 33
0x40211cf6: WiFiManagerParameter::setValue(char const*, int) at C:\Users\Johannes\Documents\Arduino\libraries\WiFiManager-master\WiFiManager.cpp line 93
0x40211d45: WiFiManagerParameter::WiFiManagerParameter(char const*, char const*, char const*, int, char const*) at C:\Users\Johannes\Documents\Arduino\libraries\WiFiManager-master\WiFiManager.cpp line 50
0x4020b95d: setup() at C:\Users\Johannes\Documents\Arduino\McLighting/McLighting.ino line 379
0x40223968: fs::FS::_defaultTimeCB() at C:\Users\Johannes\Documents\ArduinoData\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266/FS.h line 243
0x402228e8: loop_wrapper() at C:\Users\Johannes\Documents\ArduinoData\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266\core_esp8266_main.cpp line 194

Maybe you guys can help me? Thanks!

Please reupload the sketch and select to erase all data.

I just fixed it by just clean installing all again. Now it works. :D


Copper fraction of Bi2212 strand

In GitLab by @rkemp on Jul 26, 2016, 16:30
The parameterisation for HTS BI2212 (isumattf = 2) says in the code
"N.B. jcrit returned by bi2212 is the critical current density
!  in the strand, not just the superconducting portion.
!  The parameterization for jcritstr assumes a particular strand
!  composition that does not require a user-defined copper fraction,
!  so this is irrelevant in this model"
However it then has
jcritsc = jcritstr / (1.0D0-fcu)
If fcutfsu is a variable and is allowed to 1.0 this will allow the current density jcritsc to reach infinity and push the SC fraction down to zero... if the parameterisation is for a strand, it must impose appropriate values on fcu for the parameterisation.

Bi2212 is a type of BSCCO, a first generation high-temperature superconductor.  Although it is still the only type of HTS available in round wire, no-one seems very interested in it these days.  Issue closed.


Busola but fetchQueue

Description
Changes proposed in this pull request:

...
...
...

Related issue(s)

/test all

/test all

/test all

/test all


Update CODEOWNERS

Overview/Summary
Removing Senthuran and adding Courtney as a code owner
This PR fixes/adds/changes/removes
N/A
Breaking Changes
N/A
Testing Evidence
N/A
As part of this Pull Request I have

[X] Checked for duplicate Pull Requests
[X] Associated it with relevant GitHub Issues
[X] Ensured my code/branch is up-to-date with the latest changes in the main branch
[X] Performed testing and provided evidence.
[X] Updated relevant and associated documentation.

Approved


Initialize repotoolset so source-build can supply a built version.

For source-build 2.1 RC this was a patch for msbuild to enable source-build to supply the version of repotoolset that was source-built.  This moves the changes into msbuild so the patch can be removed.
cc @cdmihai

@rainersigwald wrote at https://github.com/Microsoft/msbuild/pull/3287#discussion_r187116715
So the logic is "if repotools appears to have already been restored (has a path written to a text file) then just return that path, otherwise write a project and have it write the path, "restoring" the SDK automatically during that"?
Appears so. This will make it different from how the windows build gets repotoolset, but since the windows version is simpler, I'd keep them separate for now.


feat: add issue credential v2

Signed-off-by: Mike Richardson<EMAIL_ADDRESS>

Codecov Report

Merging #745 (d7a76f0) into main (2da845d) will increase coverage by 0.43%.
The diff coverage is 90.19%.

@@            Coverage Diff             @@
##             main     #745      +/-   ##
==========================================
+ Coverage   86.27%   86.71%   +0.43%
==========================================
  Files         369      393      +24
  Lines        8014     9205    +1191
  Branches     1358     1621     +263
==========================================
+ Hits         6914     7982    +1068
- Misses       1041     1161     +120
- Partials       59       62       +3

Impacted Files
Coverage Δ

packages/core/src/logger/ConsoleLogger.ts
41.17% <ø> (ø)

...connections/errors/ConnectionProblemReportError.ts
100.00% <ø> (ø)

.../modules/connections/services/ConnectionService.ts
88.78% <ø> (ø)

...s/core/src/modules/credentials/CredentialEvents.ts
100.00% <ø> (ø)

...s/credentials/protocol/v1/models/CredentialInfo.ts
100.00% <ø> (ø)

...edentials/protocol/v1/models/RevocationInterval.ts
75.00% <ø> (ø)

.../credentials/repository/CredentialMetadataTypes.ts
100.00% <ø> (ø)

...src/modules/indy/services/IndyRevocationService.ts
58.90% <ø> (ø)

...e/src/modules/ledger/services/IndyLedgerService.ts
63.97% <ø> (ø)

...e/src/decorators/attachment/AttachmentExtension.ts
50.00% <14.28%> (ø)

... and 69 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 2da845d...d7a76f0. Read the comment docs.


Add update_resource action to metricstransform

Upstream already merged a feature which obsoletes this PR: https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/9719


Add command line arguments to Xcode build scheme on vapor xcode executed

Add command line arguments to Xcode build scheme on vapor xcode executed

Author(s): NathanFlurry

Introduction
This feature would allow for the correct port and workDir to be set when generating Xcode projects.
Motivation
When running a Vapor application from Xcode, the wording directory is not the same as if running it from the command line. Because of this, the app can't find files properly using the default working directory in Xcode.
Proposed solution
To fix this, I propose that when vapor xcode is executed, it automatically updates the build scheme to add the flags --config:app.port=8080 --workDir=$(SRCROOT).
Code snippets
I don't know too much about how .xcodeproj files are structured, but from what I can tell, the CLI would have to edit the file VaporApp.xcodeproj/xcuserdata/<username>.xcuserdatad/xcschemes/App.xcscheme and add this under the proper launch action:
<CommandLineArguments>
   <CommandLineArgument
      argument = "--config:app.port=8080"
      isEnabled = "YES">
   </CommandLineArgument>
   <CommandLineArgument
      argument = "--workDir=$(SRCROOT)"
      isEnabled = "YES">
   </CommandLineArgument>
</CommandLineArguments>

Impact
This will simply make it easier for people to get up and running with new projects without any errors.
Alternatives considered
Not adding it at all, but it saves a lot of time by doing this.

I think this is a great idea. I'd love to see it implemented.

Definitely want this, would need to see what it takes to edit those files safely.

This is approved.

I’ve a quick look at the file structure.
This might be easier to do once we’ve split up the CLI into bits and use SPM to build it, because then we can pull in an XML lib or at least avoid piling XML parsing into the main file as well.
Unless we just do a “brute force” insertion between </BuildableProductRunnable>\n<CommandLineArguments>, which works I guess but is brittle in case the input changes order etc.

We know the exact version of Xcode and that it's a new project being generated by this command, so I think we could make a hack that would work for now without XML parsing.

Actually, it might be better to simply put this in a config file. To do that, we should also add custom variables to values defined in the config files, e.g. the default config file would be { "work-dir": "{{SRCROOT}}" } (assuming that workDir will eventually become a config variable).

@NathanFlurry the one weird thing about workDir in the config is that we need the workDir to know where to look for the Config/ directory, so you get into a weird situation of where to look for it.
On the {{SRCROOT}}, we could maybe look at the file, but that's often different than the source root, depending if the file is nested in subdirectories. The xcode project's env var $(SRCROOT) is a convenient way to get the root directory of the project.
I like the idea about not needing to mess w/ XcodeProj files.
Maybe looking into the file location is good enough. We could even make it smart enough to search around the directories of the file location to see if we can get other info.

Was this fixed at some point already? Or does swift package generate-xcodeproj solve this problem? I am using Xcode with Vapor 0.17 and seems to find all config files properly.

I don't feel there is a need for this because of the method being used right now to analyze the working directory from the #file value. If users want to add a --workDir flag manually, they are welcome to.


 Need to check the race condition here:
  1) test CSV encoder test Items are stored in CSV after csv pipeline (DataStorageWorkerTest)
     test/data_storage_worker_test.exs:149
     ** (MatchError) no match of right hand side value: {:error, :already_started}
     stacktrace:
       test/data_storage_worker_test.exs:6: DataStorageWorkerTest.__ex_unit_setup_0/1
       test/data_storage_worker_test.exs:1: DataStorageWorkerTest.__ex_unit__/2

As it fails the CI pipeline for master.

I'll handle standardizing the pipeline tests


Fix "undefined method `spec'.." on 1.9.3 build

Forces the use of travis containers which have a newer version of
bundler that do not have this bug.
See bundler/bundler#3558
(I'm not 100% sure this will fix the issue until travis has run.)

I've set up a travis build on my fork, I'll open another pull request when I'm a littler closer :)


feat: type annotations for @properties

Thanks for all your work on this project!
Per a review comment in Ibis: https://github.com/ibis-project/ibis/pull/7279#discussion_r1344065799
A @property of a class is rendered without the type hint:

It would be nice if it WAS rendered with a type hint. IDK if this is already a feature of non-property attributes...

Thanks for raising, it seems like the renderer has everything it needs to render annotation types, but it's a bit tricky to figure out these aspects of generating attributes:

Attributes can be documented individually, or via the numpydoc Attributes section.
Some doc sites summarize attributes in tables, while others like to document them individually (like methods).

i.e. a property's docstring can be a full fledged numpydoc docstring, with sections, etc..

As a result, quartodoc handles attributes using these behaviors:

If there is a attributes section in the class docstring, render it like a parameter table (including types)
otherwise, render the attributes table like the methods summary table (no types)

Minimal reproducible example
Does this look like I'm reproducing the situation?
test_func.py
class Table:
    @property
    def x(self) -> int:
        """The x attribute"""
        return 1

rendering doc
from quartodoc import Auto, blueprint, MdRenderer

bp = blueprint(Auto(name = "test_func.Table"))
print(MdRenderer().render(bp))

# test_func.Table { #test_func.Table }

`Table()`

## Attributes

| Name | Description |
| --- | --- |
| [x](#test_func.Table.x) | The x attribute |

Fixing this particular issue in ibis
Option 1: add attributes section
WDYT of adding an attributes section to your docstring for now? It currently, requires repeating the description (will open issue upstream in griffe), but does fetch the type info automatically from the property.
Here's an example
class Table:
    """
    Attributes
    ----------
    x
        The x attribute
    """

    @property
    def x(self) -> int:
        """The x attribute"""
        return 1

Option 2: document attributes more like they're methods
In this case, we'd have the attributes summary link to a fully rendered docstring for each attribute, as if they're methods. If this seems like a better option, let me know. I think we'd need to add an option to enable this style of documentation on classes / modules.

Thanks for the detailed explanation!

Does this look like I'm reproducing the situation?

Yes I think you have it.
Whatever the rendered output, I want it to come from the logic of

look through the class's Attributes section for names, types, and descriptions
look through all @propertys for names types and descriptions
Whenever something is found in both, error.
Union these two sets together.
I think ideally we should support both sources: Some attributes are dynamically generated, so we need the Attributes section for these. The rest of the time, I want the documentation to live next to the implementation in a docstring.

Then, once we have the list of annotations, we need to choose how to render them. My ideal would be

have a config option for rendering each attribute in a full section, similar to methods. In simple cases like this example, I wouldn't want this, I'd just want the summary table. Maybe the default depends on if each attribute just has a oneliner docstring then you can just have the table. If ANY docstring is multiline then each attribute renders individually.
In the summary table, add a column for the type. Possibly add a config option for this in case the type is really long and would look ugly, but I would probably say just always render it.

CC @cpcloud @lostmygithubaccount @jcrist @gforsyth if they have any opinions

Thanks for weighing in, this is super helpful. The suggestion on rendering makes a lot of sense.
Just to recap, it sounds like the option to render like methods (let's say expand_attributes for now) might look like:

True: summary table looks like methods now (name, short description), and links to longer attribute doc
False: summary table looks like parameters table (name, type, short description)

WDYT of that approach? (I'd lean on punting on any automated toggling between behaviors for now, but it seems useful to implement down the road, based on whether attribute docs are one-liners).
Minor detail on documenting attributes

Some attributes are dynamically generated, so we need the Attributes section for these. The rest of the time, I want the documentation to live next to the implementation in a docstring.

You should be able to document any class attribute, even a dynamically created one, using this syntax:
class SomeClass:
    x: int
    """The x value-less variable, whose value might be set on instantiation"""

That sounds good! Instead of a true/false though for the option, I would name it something like attributes and have the options be table_and_sections or table_only. This feels more interpretable to me, and leaves the door open to add more options later.
Honestly if you really want to kick the ball down the road, if you just implemented the table_only version and made that the default then that would solve the problem that motivated this issue. In Ibis we haven't yet needed a full section for documenting attributes. Then you could hold off on exposing this as config until someone else files another feature request, and then you'll have even more experience/knowledge so the solution then could be even more refined. Either way though this discussion was useful!
I agree that automated choosing can happen later.

Minor detail on documenting attributes

Oh yeah, that's great, thanks for pointing that out!

My recommendation (which is not documented anywhere yet) is to always document each attribute and property separately. Attributes sections in the parent docstring shouldn't be preferred, as they can just be generated automatically by iterating over the attributes to pick up their summary and type. Since each attribute has a full docstring, it can have its own heading+permalink+toc entry, and generated tables can link to it.
As stated by @machow, even dynamic attributes can be given a docstring thanks to this syntax:
class A:
    attr_a: int
    """Docstring."""

    # or even in the __init__ method
    def __init__(self):
        self.attr_b: float
        """Docstring."""


Animate StateFull and Stateless widget without Animate Widget

Added support for Stateless and Statefull widget extensions for quick usage of animations

I'm not sure what this is doing that the existing AnimateWidgetExtensions isn't? Closing, but please do reopen with more information.


Parameterised Instruction

Parameterise Instruction such that it can be in different forms (e.g. labelled, concrete, etc).
Question) Can we exploit Rusts type system to make certain instructions invalid in certain cases?  For example, to make them uninstantiatable under certain forks, etc?

According to the Rust Nomicon:
enum Void {} // No variants = EMPTY

This type cannot be instantiated.


ci: add code coverage for codacy

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#17
#16  👈
#15
#14
#13
#12
next

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @AliSajid and the rest of your teammates on  Graphite

Merge activity

Nov 9, 10:27 PM EST: A user started a stack merge that includes this pull request via Graphite.


Adding protocol select menu in portBinding during container creation

During the creation of one container, I needed to bind an UDP port and I saw that DockerUI hadn't got the option to select the desired protocol in the portBinding field, so I added it during the startContainer flow.
I'm not sure if this is the proper way to add this feature (first time writting Javascript and doing a pull request).
I hope it helps.

Looks good, thanks for contributing. :+1:


"catkin_make" error

Hello, thanks your project. I git clone your code and catkin_make, but it has some errors as follow:
-- Could not find the required component 'moveit_core'. The following CMake error indicates that you either need to install the package with the same name or change your environment so that it can be found.
CMake Error at /opt/ros/kinetic/share/catkin/cmake/catkinConfig.cmake:83 (find_package):
Could not find a package configuration file provided by "moveit_core" with
any of the following names:
moveit_coreConfig.cmake
moveit_core-config.cmake

Add the installation prefix of "moveit_core" to CMAKE_PREFIX_PATH or set
"moveit_core_DIR" to a directory containing one of the above files.  If
"moveit_core" provides a separate development package or SDK, be sure it
has been installed.
Call Stack (most recent call first):
hector_moveit_exploration/CMakeLists.txt:5 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/felicx/hector-moveit/build/CMakeFiles/CMakeOutput.log".
See also "/home/felicx/hector-moveit/build/CMakeFiles/CMakeError.log".
Invoking "cmake" failed
Could you help me, thanks.

Sorry for not adding it as dependency. You should do sudo apt-get install ros-kinetic-moveit* before  catkin_make. This project depends on MoveIt! framework and it should be installed beforehand.

Thanks for your help, I have solved that problem, but I got another one when I catkin_make:
/home/felicx/hector-moveit/src/hector_moveit_gazebo_plugins/src/fruit_generator.cc: In member function ‘virtual void gazebo::FruitGenerator::Load(gazebo::physics::WorldPtr, sdf::ElementPtr)’:
/home/felicx/hector-moveit/src/hector_moveit_gazebo_plugins/src/fruit_generator.cc:23:32: error: ‘class gazebo::physics::World’ has no member named ‘Models’
auto models = _parent->Models();
^
/home/felicx/hector-moveit/src/hector_moveit_gazebo_plugins/src/fruit_generator.cc:25:22: error: unable to deduce ‘auto&&’ from ‘models’
for(auto m : models){
^
hector_moveit_gazebo_plugins/CMakeFiles/fruit_generator.dir/build.make:62: recipe for target 'hector_moveit_gazebo_plugins/CMakeFiles/fruit_generator.dir/src/fruit_generator.cc.o' failed
make[2]: *** [hector_moveit_gazebo_plugins/CMakeFiles/fruit_generator.dir/src/fruit_generator.cc.o] Error 1
CMakeFiles/Makefile2:4369: recipe for target 'hector_moveit_gazebo_plugins/CMakeFiles/fruit_generator.dir/all' failed
make[1]: *** [hector_moveit_gazebo_plugins/CMakeFiles/fruit_generator.dir/all] Error 2
make[1]: *** 正在等待未完成的任务....
[  0%] Linking CXX shared library /home/felicx/hector-moveit/devel/lib/libhector_gazebo_reset_plugin.so
[  0%] Built target hector_gazebo_reset_plugin
[  0%] Linking CXX shared library /home/felicx/hector-moveit/devel/lib/libdiffdrive_plugin_6w.so
[  0%] Linking CXX shared library /home/felicx/hector-moveit/devel/lib/libhector_servo_plugin.so
[  0%] Built target diffdrive_plugin_6w
[  0%] Built target hector_servo_plugin
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2
Invoking "make -j4 -l4" failed
Could you help me? thanks

Closing to isolate problems. New issue is at here.

sudo apt-get install ros-kinetic-moveit worked for me. Thanks @tahsinkose


[BUG] disagreement metadata is int instead of bool

e.g.

Both should be false
Issue is in the Pydantic model defining it as int.

Is this as simple as changing the type hinting in LatencyCalibrationWarnings class?
https://github.com/sdatkinson/neural-amp-modeler/blob/d55ab734a640ca67c8e28451f6d56a359873e9ef/nam/train/metadata.py#L53
Because the all the places where disagreement_too_high is referenced it's treated as a bool.
https://github.com/sdatkinson/neural-amp-modeler/blob/d55ab734a640ca67c8e28451f6d56a359873e9ef/nam/train/core.py#L398
https://github.com/sdatkinson/neural-amp-modeler/blob/d55ab734a640ca67c8e28451f6d56a359873e9ef/tests/test_nam/test_models/test_exportable.py#L114
...etc

@Rodolfo-S I believe that's correct, unless I'm missing something deeper wrt pydantic


Show only answer boxes related to relevant questions on slide 4.2

@thomwithoutanh isn't this working as expected?

@IronRunes Ah, sorry, what I meant was:
only show sidebar boxes that relate to the answer boxes that are shown (currently all of them are shown regardless). It's not a big issue right now though. Moving it to Icebox.


Move istio.io tests to operator

@howardjohn: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

pilot-multicluster-e2e_istio
853c19e2a95a35803a1f9880da7596439ff1190e
link
/test pilot-multicluster-e2e_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

pilot-multicluster-e2e_istio
853c19e2a95a35803a1f9880da7596439ff1190e
link
/test pilot-multicluster-e2e_istio

integ-istioio-k8s-tests_istio
853c19e2a95a35803a1f9880da7596439ff1190e
link
/test integ-istioio-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

pilot-multicluster-e2e_istio
853c19e2a95a35803a1f9880da7596439ff1190e
link
/test pilot-multicluster-e2e_istio

integ-istioio-k8s-tests_istio
853c19e2a95a35803a1f9880da7596439ff1190e
link
/test integ-istioio-k8s-tests_istio

e2e-bookInfoTests-envoyv2-v1alpha3_istio
853c19e2a95a35803a1f9880da7596439ff1190e
link
/test e2e-bookInfoTests-envoyv2-v1alpha3_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

For https://github.com/istio/istio/issues/20441
I am surprised this was so easy..


Refactor System.Private.CoreLib interop to match coding guidelines

Localization
TimeZone
CommandLine
CoCreateGuid

@tarekgh @AlexGhiondea This is next batch of my changes to refactor Interop.manual.cs

@dotnet-bot test this please


Feature Request: Compilation as a (shared) library

Now that there is a .cc file involved, would you consider providing a system for making a shared library (autotools, make, whatever), along with instructions on how to use it? Perhaps just instructions would be fine since there is only a single source file. I will fiddle with a simple setup for gcc in the next couple of days if you are interested in that.
This issue stems from the fact that someone requested a shared library option in the Arch User Repository, where I maintain the easyloggingpp package: https://aur.archlinux.org/pkgbase/easyloggingpp/flag-comment/

The link to https://aur.archlinux.org/pkgbase/easyloggingpp/flag-comment/ is now out of date because I updated the package to version 9.92. The original comment read:

Your package easyloggingpp has been flagged out-of-date by targodan:
Current version is 9.92, note that since 9.90 there was a .cc file added, so any project that uses easyloggingpp needs to copy-paste that file into their project. Maybe the install can be modified so that it creates a shared library?

We can consider that but I have a question and this question is for whole community who love Easylogging++
Do you prefer compilable (that can be included in your project) or with compiled shared object where you use linker instead. The reason why I ask is because we are planning a new design of Easylogging++ that is:

Keeping all the existing features especially format and configuration etc. except only few will be removed that are hardly used, like vmodules unless developers want it
Super faster in dispatching logs
Support asynchronous logging for applications who want to support it
Contain even more features like sending logs to socket (or even secure)
Much more thread-safe

So we planning to separate files for easy pull requests and having a single entry point for user (easylogging++.h) (keeping as much backward-compatibility as possible)
@madphysicist @aparajita @adah1972

We can consider that but can you check #485 first

As I mentioned in #485, the shared library approach does not sound good to me, if the compile-time macros affect the object code generated from the .cc file. It may also be a nightmare to make the shared library way to work on Windows. The bottom line is we may want to support both approaches, if the compile-time macro problem can be solved.

In terms of using a shared lib that must match compile-time macros, I think this is no different than boost. The user must choose the shared lib build that matches the compile-time macros, and on Windows that matches the version of the C++ lib as well.

Unless we have less than three options that affect the .cc file, the number of combinations will be unmanageable...

My mention of Windows was because we would have to add a lot of macros to control the export of symbols, which would not be necessary on other platforms.

Out of curiosity, I'm not a cmake expert, how would shared lib be added to FindEASYLOGGINGPP.cmake?

Just to give my 2 cents here, since I filed the out-of-date flag that @madphysicist quoted.
The split into a header and a .cc file while not having a shared library is a problem if you want easylogging to be installed as a package on linux. Until that split it was no problem because you just copy the the header file into the distros appropriate folder (say /usr/include/) and are done. Since that split there is (at least to my knowledge) no standard way of doing it.
Because there is no standard way of doing it the package maintainer has to come up with something. @madphysicist just copied the .cc file to the same location as the header file which is propably the most reasonable way, but because it is no standard, or at least no widely known standard, anyone who wants to use the package has to take a look inside to find out what is happening to the .cc file, which completely contradicts the purpouse of a package.
Now there is the problem of how to incorporate that .cc file into your project. Do you copy it? That breaks on updates. Do you include the .cc file in a single .cc file of your project? Maybe not. Do you create a symlink of the .cc file to your project? Propably. Then again what if a package maintainer of a different distro decides to do something else? You quickly get into trouble with version controlling your project.
I guess what I'm saying is that the standard linux approach of installing this as a package is not feasable while we both have a .cc file and no shared library.
Since a shared library does not seem to be feasable either I personally would prefere a pure header approach again and just sit through the compile time.

@targodan How about a Makefile snippet that could be included in a project with some well documented targets like make-easylogging and build-easylogging? I could run sed on that during install and edit in the installation path for the cc file that way. There could be corresponding snippets (possibly user-contributed) for every major build system this library is used with.

@targodan
Currently cmake does it for u. Please see INSTALL in README.md
To include it in your cmake project please see cmake/FindEASYLOGGINGPP.cmake like we have done in other projects

See https://github.com/muflihun/ripe/blob/master/CMakeLists.txt and look for two instances, one find and include second linking the cc file

@mkhan3189 As I have no cmake projects, only pure make projects, that wouldn't work for me.
@madphysicist That does sound good to me. So snippets for different buildsystems (make, cmake etc.) would be included in the easylogging repo and the releases. Did I understand your idea correctly?
I think that would make using this project easier in general, since anyone who uses it doesn't have to worry about major non-api changes anymore (I for one completely missed the added cc file in the beginning as it was no major version bump). :+1:

Is easylogging++ currently shipped in a package for Linux distros? It does not seem to me quite useful. I feel developers will normally include such files directly in a project. It is simple and avoid all kinds of version/compatibility problems.

In archlinux it is as part of the AUR (archlinux user repo). I personally like it and with versioning systems like semantic versioning you wouldn't or at least shouldn't run into any compatibility problems. However it seems easylogging does not follow semantic versioning.

However it seems easylogging does not follow semantic versioning.

Indeed, and it really should follow semantic versioning. I'll make this an issue.

Semantic version is fixed and easylogging++ is now following it


Add neotest-golang to README

I've made another adapter for Go, in fredrikaverpil/neotest-golang, as I was having a lot of issues with the one listed in the README. My adapter outlines those problems here.
I figured it could be helpful for others to list my adapter as an alternative, for others who might also have issues with the currently listed Go adapter. 😄

@fredrikaverpil great adapter! Thanks, added to my nvim config.
Hope your PR will be merged soon

Great thank you! I do intend to look at replacing the original if yours covers the same functionality, also good to hear others find it better :raised_hands:


Add puppet-lint into our linting tool chain.

In this PR we add puppet-lint to our linting tool chain. It has a series of commits which first add the puppet-lint module to the environment by adding installing it during provisioning. We do this carefully so that the no-op optimisations of the provisioning process we did don't lose their touch. We then fix some lint errors by either adding exceptions for it on a per line basis, excluding the rule from the checks entirely or fixing the error. Finally we hook up puppet-lint to run as part of tools/lint.
Fixes: #9185

Can we install puppet-lint via apt instead of gems?

(Also FYI I merged a few of the preparatory cleanup commits that looked good)

@timabbott Updated this :)

Merged, after fixing the version merge conflict.  Thanks @adnrs96!


patch[Community] Optimize methods in several ChatLoaders

There are some static methods in ChatLoaders, try to add @staticmethod decorator for them.

@ccurme Please help to review this pr.


EasyCLA Approval Request for contributor email should have link for Corporate Console.

Pre-Condition: Have a project where CCLA is signed and the contributor is not added in approval list.
Steps:

Login to github and create a PR.
The contributor is gated, click on the 'Not Covered' button.
Select Organization, Select CLA Manager and submit for approval.
The CLA Manager receives an email with Subject line 'EasyCLA: Approval Request for contributor: '. Check the email content.

Actual Result: The email doesn't have link to Corporate Console. PFA the email.
Expected Result: The email should have link to Corporate Console. This is already discussed on Stand-up call with Pranab.

@makkalot can you review this one. Pretty easy. Not sure if the system email is generated from Python or Golan. Search for the email content to find where it is generated from the code.
We can do something like this which determines which version we are using (v1 vs v2) and grabs the console link we need and add a link to the email. Get @pranab-bajpai or @WillsonHG to confirm the email content/text.

@dealako so for this case email was generated from golang end in the v2 package. So just included the v2 link to the corporate console

Verified for V2 today and found working fine now and user is able to see the corporate console link on the email. Please refer the screencast as below for reference:


Add Methods section to streamlit_app.py

The Methods section of your paper explains how you conducted your research or project. It provides enough detail so that someone else could replicate your work. Here’s how to write it effectively:

Purpose: Begin by stating the purpose of your Methods section. Explain what your research question or objective was and how your methods helped you answer it.

Description of Methods:

Participants or Materials: Describe who or what was involved in your study. Include details like age, gender (if relevant), and any characteristics that are important to your study.
Procedure: Outline the steps you took to conduct your research. Include the sequence of events, any measurements taken, and how data was collected.

Tools and Instruments: Mention any tools, instruments, software, or equipment you used during your research. Provide enough detail so that others could understand how you collected and analyzed data.

Data Analysis: Briefly explain how you analyzed the data you collected. Mention any statistical methods or software used to interpret your findings.

Ethical Considerations: If your research involved human participants or animals, mention any ethical considerations you followed. This could include obtaining consent, protecting privacy, or following guidelines for animal welfare.

Clarity and Detail: Be clear and specific in your descriptions. Avoid unnecessary details, but include enough information so that someone else could replicate your study.

Review and Revise: After writing your Methods section, review it to ensure all necessary details are included and that it flows logically. Revise for clarity and accuracy.

Formatting: Typically, the Methods section comes after the Introduction and before the Results sections in your paper.

By following these steps, you can write a clear and informative Methods section that demonstrates how you conducted your research or project.

@MoFishy any updates on this task? If you have finished please create a pull request. Please use the outline on Google Drive if it helps.

@MoFishy and @alphawandrew what happened with this ticket?

@MoFishy take care of this after tomorrow


add randomseed

if you don't use a different randomseed every time you generate random numbers they won't actually be random
you should add a math.randomseed(os.clock()) here https://github.com/alanfortlink/blackjack.nvim/blob/0968a1998d0bb1793561fe491d20eaa73e63812a/lua/blackjack/match.lua#L96
you can test this out by doing a few :lua =math.random(52) and then restarting neovim and doing it again
the numbers will be the same

That should address the issue. I'm setting the seed for every new card deck. Thanks for the tip!


Fixed a couple of translations

Translated a couple of strings.
And a quick fix for non-centralized error message in login page.

Thank you for great work

Happy to help.


Add support for non-accented option key combinations on mac

Partially fixes https://github.com/ppy/osu/issues/3125, accented keys (like option-e) will print the key without option down instead (so e in that case), non-accented keys (like option-a) will print the correct letter (if the font supports, it prints å in that case).

[ ] https://github.com/ppy/opentk/pull/26

Superseded by https://github.com/ppy/osu-framework/pull/4985


Code to Reproduce System-Level Metrics

Thanks for generously sharing the annotation data and the evaluation routines!
Our research team is trying to iterate on the results and add more metrics to the evaluation suite. Meanwhile, we're trying to understand how to produce the system-level metrics reported in the paper, so we can ensure fair comparison.
Is there any plan to release the process to compute the system-level model scores reported on page 11 of the paper? It'll be great if there was any code, descriptions or metric parameters.
Thank you again, and I look forward to hearing from you.

Hi,
Thank you for your interest in the work! You can find a link to the code for computing the scores here. I will add this to the main page to ensure this is visible.
Best,
Alex

Hi,
Thank you for the interest in our work! The scores were primarily computed using the calc_scores script, and we provide a sample config file here. If you have questions about a specific model/metric or trouble reproducing certain scores, I'm happy to assist!
Best,
Alex

Hi Alex,
Thanks for the fast reply! I downloaded and checked the code, and it seems very helpful for comparing metric correlations.
In addition to this, we're curious about the process to compute these system-level metrics, because the code seems to assume that metrics are already computed.
I asked this question because I had some difficulties reproducing the automatic metrics on page 11 of the paper. Below is a screenshot of the table

For a sanity check, I ran system-level stats metrics with n_gram=3, case=False and tokenize=False on the human annotated data, and below are the metrics I got

Take Length metric as an example, the numbers for Length and summary_length columns are inconsistent across the two tables.
We're positive that the human annotations are consistent with the paper, but we're curious about the process to create the automatic metrics that can be used to compute correlations.
Thank you,
Mingkai

Hi Mingkai,
Thank you for the follow-up question! If I understand what you wrote correctly, you are trying to compare the results from Table 4 to the results you obtained on the human-annotated data. However, these are two different subsets - one is on the full dataset and the other is on the set of 100 articles chosen for human evaluation, so these naturally produce different results. Can you please correct me if I misunderstood something?

That's exactly right, thanks for the clarification! I computed BLEU on the full dataset instead, using the same parameters as provided in /evaluation/examples/basic.config. The results are closer to the paper, but there were still small inconsistencies.
The below code uses M0 as an illustration. For diagnosis, I directly called the sacreBLEU API.
The corpus-level score was 12.59 on 11490 samples, each using 1 reference, which is 1.17 higher than reported.
Computing and averaging sentence-level scores led to 11.32, which is 0.1 lower than reported.
I know this is a small difference... However, I'll really appreciate any advice and/or pointers on how to reproduce the scores, because it'll be great if we could control all routines that can lead to inconsistent comparisons down the road.
Below is a screenshot of the routine and results on Jupyter notebook. Let me know if you have any questions or if I did anything wrong.

I will try to run this again on my end. I will likely only get to it in a few days. In the meantime, can you try running both of those with lowercase=True?

Thanks for agreeing to look into it! I tried lowercase=True for both of these, but the BLEU scores stayed the same :/

BTW the stats metrics are consistent for model M0, so I think the dataset is fine

Hi Fabbri,
Some updates - I managed to produce the system-level Kendall-tau correlations between Data Stats metrics and human judgments, the table shown below. The general trends are similar, but the exact numbers were inconsistent.
Could you confirm the systems included in the correlation evaluation? From the annotation data, there appears to be no data from M23 - Pegasus - (dynamic mix), which was included in Table 3 of the paper. Could this have affected the correlation results?
Here's the correlation table I computed:

Let me know if you have any questions. Thank you!

Hi Mingkai,
For the bleu scores, I repeated the calculations for M0 and am getting the same 11.4270 that I reported in the table. Could you please provide your paired jsonl file (I know you said you checked the dataset statistics, but I just want to confirm it matches exactly) and the result of running pip freeze?
Yes that would affect the correlations. I just uploaded the file with all annotations, included Pegasus dynamic mix, and metric scores here.

Hi Fabbri,
Thanks for sending the annotations. My paired jsonl file for M0 is here.
I can confirm that the system-level expert scores are consistent with the paper, and when I correlated the metrics in metric_scores_11 with the scores, I could reproduce the Kendall Tau coefficients in Table 2. How did you produce the metrics in this dictionary?

Hi Mingkai,
Sorry for the delay. I see there is a difference in the files. In order to do the evaluation more uniformly, we used the same reference for each (rather than the reference provided by the authors, which is what is given in each of the zipped folders), which was from M20, as that seemed to not have any post-processing. We should have made this clearer. I'm attaching a file with references and ids for convenience.
For producing the metrics in the dictionary, we used the calc-scores script. I'm attaching a version with an extra flag to account for multiple references.
refs+code.zip

Hi Alex,
Thanks for clarifying! The script and .jsonl file are very helpful.
One more question - in the full annotation file, are metrics in metric_scores_11 calculated with 11 references, metric_scores_6 with 6 references and metric_scores_1 with 1 reference? Can we assume that the first reference is the official reference?

Hi Mingkai,
Yes, that is correct, and you can assume that the first reference is the official/original reference. I'll close this issue for now, but please open it again if you have any additional questions!


[Bug, Report] Table  cell missing when the content was created by vue.createElement

Element UI version
1.4.3
OS/Browsers version
deepin/Chrome
Vue version
2.4.2
Reproduction Link
https://jsfiddle.net/uL3Lvak1/
Steps to reproduce
open the link, no other operation needed.
What is Expected?
All rows in column "姓名" should have value.
What is actually happening?
Two rows have content while others are empty.

Why are you trying to assign the name field to a VNode?

@Leopoldthecoder  I want to set the field different colors by font tag  amd make it clickable. This is the way that I found that could do that. Is there any way suggested that can make it with different color and clickable?

https://jsfiddle.net/uL3Lvak1/1/

@Leopoldthecoder Thanks for your code, but I want to add the tag dynamically in a function. if I just use string concatenation of the tag and my content, the tag will be converted into normal string and cannot work.

https://jsfiddle.net/uL3Lvak1/2/


Keptn as CNCF Sandbox project

https://github.com/cncf/toc/pull/237
https://docs.google.com/presentation/d/1k1QcjeTmb1ZeYtwMntLw1IVTbJXGerGnGExow9oa7i4/

Is there a document around SIG-Review available for this project?

+1 to Amye's comment

Review document is available here: https://docs.google.com/document/d/12Uhkv5aMnvM_HFvpYDuDTN2Zzc83qKOLYmp-k_RGWB8/edit#heading=h.kd4eg2uz3lt0


Docs versioning

Figure out how to provide docs for multiple versions of CockroachDB

Since I didn't see an existing proposal, I figured I'd submit a strawman RFC for docs versioning here.

Create a branch for each released major version of CockroachDB: 1.0, 1.1, 1.2, 2.0, etc. For consistency with cockroachdb/cockroach, name these branches release-x.x, as in release-1.0. Right now, we'd only need release-1.0.

Auto-deploy each release branch to https://cockroachlabs.com/docs/x.x/. 1.0 documentation would live at https://cockroachlabs.com/docs/1.0, for example.

Auto-deploy the latest-stable documentation to https://cockroachlabs.com/docs/ so that existing URLs continue to work.

Auto-deploy the tip of gh-pages to https://cockroachlabs.com/docs/edge.

Don't handle pre-release/unstable versions specially; users on the unstable channel can use the edge docs.

When deploying, inject <link rel="canonical" href="https://cockroachlabs.com/docs/FOO.html"> into non-default versions of the page with the same filename. So https://cockroachlabs.com/docs/1.0/FOO.html and https://cockroachlabs.com/docs/edge/FOO.html would indicate their canonical URLs as https://cockroachlabs.com/docs/FOO.html. This should prevent Google from linking to non-default of pages, unless those old versions are legitimately far more relevant to the search query. (PostgreSQL documentation suffers tremendously from this problem, for example.) Pages that do not yet exist in the default version (e.g. https://cockroachlabs.com/docs/edge/NEW-FEATURE.html) would not list a canonical URL.

Backport commits on gh-pages to release branches as necessary.

Consult with design to build a version switcher.

The downside of this approach is that nearly every commit on gh-pages in the next few weeks will need to be backported to release-1.0. I don't see a great way around that, considering we've already started landing 1.1 features to master that will need documentation but won't make it into the 1.0.x series.
/cc @bdarnell @sploiselle

Your proposal looks very good to me, @benesch! Thanks for writing it up. Adding @mjibson since I've discussed basic approaches with him, too.
In terms of "backporting commits" from gh-pages to a release branch, that's what we would do for any patch releases that need to be reflected in that version's docs as well as for any doc bugs we decided need to be fixed, is that right? And how would it work exactly? It's something I haven't yet done in git.

Also, just to make sure we're on the same page, my feeling is that docs versioning doesn't need to be in place for the 1.0 release date. Instead, it needs to be in place for 1.1, at the latest. @benesch, do you agree?

Overall that proposal looks good. One change I'd make regarding the canonical links is to instead make the non-canonical versions include a noindex meta tag, which will prevent google from indexing them, but also continue to work if we delete, create, or rename pages, which would break the canonical links. Although maybe it's ok if the canonical links are broken? I'm not sure how google handles that.

Really thoughtful and considerate sketch here. A few more considerations (questions, not answers):

Can we easily control backporting/moving content forward with some kind of front-matter tagging? i.e. something like "Version Support: 1.0+" or "1.0, 1.2".
Do we want to attempt smart redirections when visitors try to load pages that exist in other versions, but not in this one? e.g. if /docs/deprecated.html got killed in the 1.2 release, do we want to try and serve them the content we know they're looking for? Alternatively, we can keep every page that ever existed in the current repo with a link to the last version it lived in, but that feels tedious.
Kind of the converse of the prior point, what if you try to go to 1.0/newfeature.html, which exists only in the 1.1 and forward repos?

@mjibson, my concern with marking old versions as noindex is that sometimes you might actually want that old version. Perhaps the old version includes a note like "you'll see error foobazle if you try to frobulate the bargoon" and you're searching for "foobazle when frobulating bargoon in cockroachdb". If those old versions aren't indexed, you're out of luck.
Re deletions/renames: I figured we could write a quick script to insert <link rel="canonical" ...> into the generated files iff a file with the same name exists in the current stable version.
@jseldess, yup! We need to have this set up when you want to publish documentation that only applies to the latest unstable version. That'll be sooner than 1.1, I think, but definitely after 1.0.

Ok. Having a thing that can make sure the canonical links work seems fine to me.

@sploiselle, answers inline:

Can we easily control backporting/moving content forward with some kind of front-matter tagging? i.e. something like "Version Support: 1.0+" or "1.0, 1.2".

Not easily, I don't think. (Perhaps someone else has a solution?) The trouble stems from small changes to existing features: e.g., when we add/remove a flag to cockroach start, there's a small section of the "Start a Node" documentation that needs to change from version to version.

Do we want to attempt smart redirections when visitors try to load pages that exist in other versions, but not in this one? e.g. if /docs/deprecated.html got killed in the 1.2 release, do we want to try and serve them the content we know they're looking for? Alternatively, we can keep every page that ever existed in the current repo with a link to the last version it lived in, but that feels tedious.

That's a good point! We'll be breaking bookmarks when we publish docs for a new version if we've removed/renamed pages. Should be possible to auto-generate these "feature deprecated" pages using whatever pipeline we set up for automatically generating canonical links.

Kind of the converse of the prior point, what if you try to go to 1.0/newfeature.html, which exists only in the 1.1 and forward repos?

I'm less worried about this case, because you'll have to manually hack the URL to end up there. We should definitely make sure the version switcher excludes pages that don't exist in that version, though.
@jseldess, to answer your question about backporting, in the easy case, it's quite simple. You essentially open the PR twice: once against the gh-pages branch and once against the release-x.x branch. Here's an example of Marc backporting a fix from master onto release-1.0.
Where it gets tricky is when you've completely rewritten a doc for the new version. Say, hypothetically, we completely rewrite the install instructions page for version 1.1. If we later decide we want to document that both 1.0 and 1.1 require macOS 10.9 and newer, you'd likely have to make the change separately on the 1.0 and 1.1 branches. When the versions have diverged significantly, Git won't be able to automatically determine where to apply the change.

Thanks again for thinking this through, @benesch. I'll set up a meeting early next week for us to nail down the approach. I'll make it @sploiselle, @benesch, @mjibson, and me.
@bdarnell, @mberhault, @petermattis, let me know if you'd like to be there as well.

Attached is the favored design for versioning:

When you click on the button, the dropdown opens like the rest of the nav:

Thanks, @kuanluo! Looks great. I'm wondering if we're overloading the drop-down feature, though. Would you be willing to mock a hover feature as well, similar to what Django does, but in the same spot on the left?

Most recent versioning thoughts are in Docs Versioning.
@benesch, any updates on the plan to try out the single branch with multiple subdirectories approach we discussed a few weeks ago?
@sploiselle, you mentioned being willing to map out all the edge scenarios between versions and how the site should behave. Do you want a separate issue to track that work?

Created #1474

@jseldess I'm not sure if Django's versioning is better for us. My thinking stemmed mostly from these two reasons:

Consistency: Dropdown is a known interaction on docs, and if possible, I'd like to minimize the different interactions we have, especially when we don't quite know how people will interact with this feature yet.
Ability to go back to much older versions of docs past 2.4. Django only allows one to go back so far. And dropdown seems to be a common behavior for versioning.

What do you think? Thanks!

Sorry for my delay, @kuanluo. Your assessment makes sense. I'm good with the drop-down recommendation.
@benesch, what do you think we should have in the drop-down initially? Stable 1.0 and Edge, with the former pointing to https://cockroachlabs.com/docs/stable and the latter pointing to https://cockroachlabs.com/docs/edge?

@benesch, the only work remaining now is https://github.com/cockroachdb/docs/issues/1546 (moving the sql generator to the cockroach repo), is that right? If so, I'll close this issue and focus on that other one.

From the eng end, yep! I know @kuanluo wanted Division Of to tweak the mobile styles, though.

Nice. I know DO is already working on the mobile styles.


pc.Light refactor

Reduce unnecessary function calls in update loops and other places referencing pc.Light where it can simply access internal property.
As well rid off get/setWhatever and mostly use properties. Unfortunately setColor is overloaded to accept 1 or 3 arguments, this although can be changed too, so all fields are properties.

Space base and sponza seem to work


Should this work on 8.1.15??

For some reason my gateway is showing this module in Trial mode., and when I try and write a tag, under quality I am getting name: "Bad_AccessDenied".  Have re done the API token about 4 times now with no change.

Are you running on Ignition Edge or standard Ignition?

Standard.

The module ignores the license state so it will stay in trial mode but be fully active. Are you getting any logs in the Ignition status page?

The only log for the last hour and a half is a couple of hsqlDataStore errors, Error thrown while attempting to cleanup stale schema records... Nothing related to the tag access denied errors:
3/22/2022, 4:38:59 PM[node: d9241d39475bcf65](http://<IP_ADDRESS>:1880/#) pi/40 : msg.payload : Object object ignitionResult: object tagPath: "[default]PCM/PI/pi10000000c429446c/Cycle TimeMS" value: "11757" quality: object isGood: false intValue: -2147483134 name: "Bad_AccessDenied" errorMessage: "" statusCode: 1

Ok, do you have tag permissions on that tag or the tag provider?

Looks like this tag provider is a remote tag provider.  I think that's causing it, let me setup to point to the local realtime tag provider on the other server.

Yep that was the problem. Our tags are setup backwards, this server should be the Realtime tag provider and the other one should be the remote provider. Sorry for clogging up the works, but thanks for the quick replies as always!!

No problem.


Use load balanced API to eliminate CORS pre-flight requests DEV-217

@dsarfati and @thedigitaldesign, are there any other configuration values (or hardcoded constants) that need to get updated?
With the new network topology, all traffic to https://app.salad.io will get routed to the load balancer. The load balancer will then route traffic as follows (in order):

https://app.salad.io/api/* -> API
https://app.salad.io/* -> Application

The app-api.salad.io subdomain will be retired.

There is one more place in the .env file. https://github.com/SaladTechnologies/salad-applications/blob/9d0168331d9c5c21cd68cd0804490c9b267b75b8/packages/web-app/.env#L5
We will be cleaning up/consolidating these files soon


fixed boost scren couple bug & fixed profile post ug

What does this PR?
Where should the reviewer start?
Steps to reproduce
Issue number
Screenshots/Video

@ue conflict


Empty "Transaction ID" field in PiHole Query Log dashboard.

I recently installed this app from splunkbase and noticed an issue in one of the dahshboards.
In the PiHole Query Log dashboard in the Query Log panel, the "Transaction ID" field is empty.  This appears to be caused by a mismatch in the line:
rename query as Query, transaction_id as "Transaction_ID"
and later in the panel's query
fields _time, Query, Host, "Forwarded Destination", "Message Type", "Query Type", Answer, "Reply Code", "Transaction ID"
In the former line, there is an underscore between Transaction and ID, in the latter, that underscore is missing.  Making these two fields match corrects the issue.  The mismatch is between line 102 and 105 in:
https://github.com/ZachChristensen28/pihole_dns_app/blob/master/default/data/ui/views/pihole_query_log.xml

Thanks for pointing this out. I will include the fix in the next update.


Enhancment of the cards

(Label: Enhancment)
Hey there! I really love this project! (Even tough its dying sadly) can there be maybe... A bit more?
I know this what you did is already insane but why cant you add the objects from the sidebar? Isn´t the sidebar usually the option that only is needed if you want to show permanent things like for example the clock or navigation? It would be super duper n9ice and cool if we could see all of the current widgets from the sidebar also in the main part as i really need tamplates for example because othere types dont really work for me. Thanks: Charged! @matt8707

@matt8707 Wdym whit duplicate? Can you mention the other issue and what happend?


[INSTALL]: openmpi support on nautilus

Package name
spack-stack 1.6 on nautilus
Package version/tag
1.6
Build options
current
Installation timeframe
Before openmpi 4.1.5rc2 is removed "near future"
Other information
From nautilus admins:
It looks like you're using the 4.1.5rc2 (release candidate 2) OpenMPI.  I
would recommend moving to the full release 4.1.5 or 4.1.6.  That rc2 version
was a stepping stone / test install.  We will likely remove it in the near
future.
WCOSS2

[ ] Check this box if and only if your package should be installed on WCOSS2 Cactus and Dogwood (all spack-stack packages will be installed on Acorn). If not, you may disregard the rest of the items below and submit this request.

WCOSS2: General questions
No response
WCOSS2: Installation and testing
No response
WCOSS2: Technical & security review list

[ ] The code is mature, stable, and production ready
[ ] The code is does not and cannot use the internet, and does not contain URLs (http, https, ftp, etc.) except in comments
[ ] The package does not contain prebuilt binary files that have not been approved by NCO security review
[ ] The code has no publicly disclosed cybersecurity vulnerabilities and exposures (search https://cve.mitre.org/cve/)
[ ] The code is not prohibited by DHS, DOC, NOAA, or NWS
[ ] The code comes from a trusted source. Trusted sources include other NWS, NOAA, or DOC, agencies, or other Federal agencies that operate at a FISMA high or equivalent level. Additionally, trusted sources could be third-party agencies through which there is an existing SLA on file (such as RedHat).
[ ] The code is actively maintained and supported (it continues to get updates, patches, etc.)
[ ] The code is not maintained by a private entity operating in a foreign country (if it is, make a note below)
[ ] There is sufficient documentation to support maintenance
[ ] There are no known security vulnerabilities or weaknesses
[ ] Installing and running the code does not require privileged processes/users
[ ] There are no software dependencies that are unapproved or have security concerns (if there are, make a note below)
[ ] There are no concerns related to SA, SI, and SC NIST control families

WCOSS2: Additional comments
No response

Thanks for the heads-up @areinecke. I'll look at this in the next two weeks.

@areinecke @sking112 I built the current spack-stack develop successfully on Nautilus with<EMAIL_ADDRESS>In addition to submitting the update site config, do you want me to rebuild a particular version or several versions of spack-stack on the system with that OpenMPI version (I am going built separate environments of course, leaving the existing<EMAIL_ADDRESS>installs in place)?

@areinecke I installed an openmpi-4.1.6 environment for the spack-stack-1.6.0 release and made the same modifications as for the existng unified-env environment (https://github.com/JCSDA/spack-stack/issues/941: netlib, fftw, sp link).
The PR with the site config and documentation changes for spack-stack is: https://github.com/JCSDA/spack-stack/pull/1014


Unable to override a variable defined in binding.gyp

Node Version:
Platform:
Compiler:
Module:

Verbose output (from npm or node-gyp):
tveronezi:node-gyp-help-sample$ npm install

><EMAIL_ADDRESS>install /home/tveronezi/Documents/sources/trend_vpn/node-gyp-help-sample
> node-gyp rebuild

make: Entering directory '/home/tveronezi/Documents/sources/trend_vpn/node-gyp-help-sample/build'
  CXX(target) Release/obj.target/mycode/src/mycode.o
  SOLINK_MODULE(target) Release/obj.target/mycode.node
g++: error: /home/tveronezi/Documents/sources/trend_vpn/node-gyp-help-sample/wrong_dir/external.so: No such file or directory
mycode.target.mk:138: recipe for target 'Release/obj.target/mycode.node' failed
make: *** [Release/obj.target/mycode.node] Error 1
make: Leaving directory '/home/tveronezi/Documents/sources/trend_vpn/node-gyp-help-sample/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/home/tveronezi/.nvm/versions/node/v14.4.0/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:194:23)
gyp ERR! stack     at ChildProcess.emit (events.js:315:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:276:12)
gyp ERR! System Linux 4.15.0-132-generic
gyp ERR! command "/home/tveronezi/.nvm/versions/node/v14.4.0/bin/node" "/home/tveronezi/.nvm/versions/node/v14.4.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/tveronezi/Documents/sources/trend_vpn/node-gyp-help-sample
gyp ERR! node -v v14.4.0
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/tveronezi/.npm/_logs/2021-01-29T14_04_23_614Z-debug.log
tveronezi:node-gyp-help-sample$

Hi community, I need help finding out what's going on here.
I'm looking for a way to override a variable defined by my binding.gyp file. The trick with
export GYP_DEFINES="so_dir=good_directory_here" does not seem to work when the variable is defined in that file.
# overriding the value of the "so_dir" variable
export GYP_DEFINES="so_dir=good_directory_here"
npm install
...
g++: error: /home/tveronezi/Documents/sources/trend_vpn/node-gyp-help-sample/wrong_dir/external.so: No such file or directory
...

Note that the variable so_dir still points to the value defined in the binding.gyp file.
If I remove the variable definition out of the binding.gyp file and try it again, the so_dir will have the value
from the GYP_DEFINES environment variable.
binding.gyp without variables:
{
  "targets": [
    {
      "target_name": "mycode",
      "sources": [
        "src/mycode.cc",
      ],
      "libraries": [
        "<(so_dir)/external.so",
      ]
    }
  ]
}

export GYP_DEFINES="so_dir=good_directory_here"
npm install
...
g++: error: good_directory_here/external.so: No such file or directory
...

Can you help?
Companion project to reproduce the issue: https://github.com/tveronezi/node-gyp-help-sample

gyp ERR! node-gyp -v v5.1.0

Current is v7.1.2 so please update and try again.

gyp ERR! node-gyp -v v5.1.0

Current is v7.1.2 so please update and try again.

In your binding.gyp you should declare the variable with a % suffix.
https://gyp.gsrc.io/docs/InputFormatReference.md#Providing-Default-Values-for-Variables

In your binding.gyp you should declare the variable with a % suffix.
https://gyp.gsrc.io/docs/InputFormatReference.md#Providing-Default-Values-for-Variables

Thanks @cclauss and @richardlau . The suffix did the trick. Tx!


Change logo to SVG for better resolution

Per issue #212, the logo pulled in from Cloudinary looked really
pixelated. I changed it to an SVG, implemented through the Logo
component found at src/components/SVG/Logo.js.
Fixes #212
Pages/Interfaces that will change
Will apply to all pages that contain the PrimaryNav component
Before

After

Steps to test

Ran npm run test and all tests passed
Did a check in the inspector on different sizes

Additional notes
This is my first PR, so feel free to discard if not useful/helpful.

 Blurry Logo in Nav


Improve element not found

Closes https://github.com/lmmentel/mendeleev/issues/141

Thanks for the fix. I enables CI and noticed that there are a few formatting issues, would you mind running ruff or pre-commit on the changed files?
On a more general note, what do you think about making the comparison case insensitive?

Thanks @Vi-L :raised_hands:


TST: fix period tests for numpy 1.9.3 (GH14183)

Partly addresses #14183

Current coverage is 85.26% (diff: 100%)

Merging #14331 into master will not change coverage

@@             master     #14331   diff @@
==========================================
  Files           140        140
  Lines         50630      50630
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits          43169      43169
  Misses         7461       7461
  Partials          0          0

Powered by Codecov. Last update 6dcc238...e39754e


process_request_headers doesn't have access to options

We would like to inject additional headers depending on options. In particular we have the following extract from here
def process_request_headers(headers, options) do
    case Keyword.get(options, :cookie) do
      nil ->
        headers
      cookie ->
        Keyword.put(headers, :Cookie, cookie)
    end
end

Unfortunately in order to achieve that we have to override process_arguments/3 function. Which is quite complex.
I've noticed that recently the https://github.com/myfreeweb/httpotion/pull/128 was merged. Which modifies the signature of process_request_headers to support passing body.
Would it be possible to use similar approach and implement
def process_request_headers(headers, _body, _options), do: process_request_headers(headers)

@@ -146,7 +148,7 @@ defmodule HTTPotion.Base do
        headers    = Application.get_env(:httpotion, :default_headers, [])
                     |> Keyword.merge(Keyword.get(options, :headers, [])
                       |> Enum.map(fn ({k, v}) -> { (if is_atom(k), do: k, else: String.to_atom(to_string(k))), to_string(v) } end))
-                     |> process_request_headers(body)
+                     |> process_request_headers(body, options)

of course, would you like to send a PR?
// wow, couchdb test suite :)


[Bug]: in the home page the buttons are not working properly(home,features,team,contact)

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
the buttons are not working properly .they are leading to the same page.
Add Screenshots

What browsers are you seeing the problem on?
No response
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC contributor
[ ] I want to work on this issue
[X] I'm willing to provide further clarification or assistance if needed.

I would like to solve this issue. Plz assign to me.

already assigned this issue.


Allow to set badge to icon.

Allow to set badge on a tab item.  Similar to https://facebook.github.io/react-native/docs/tabbarios-item.html#badge

PR is welcome.


Make it so that MixedRealityRaycastHit doesn't throw an exception every frame.

https://github.com/microsoft/MixedRealityToolkit-Unity/issues/4966
When the default raycaster goes through a physics hit and doesn't hit anything, the generated RaycastHit isn't usable. The raycaster returns true when a hit is successful (the only time when the out parameter should be accessed) but otherwise the out parameter shouldn't be used (and it should be null instead)
lightmapCoord itself is kinda funky when the physics hit doesn't hit anything (if you see the stuff here https://github.com/Unity-Technologies/UnityCsReference/blob/master/Modules/Physics/ScriptBindings/Dynamics.bindings.cs you'll find that it actually tries to do stuff, but the object basically isn't valid to do stuff.) Since RaycastHit is a struct it's not a nullable type, but those objects really aren't safe to use in the case where the physics hit failed.
Also adds a test to show how this all works end to end (that it doesn't throw, and that it's null in that case).

/azp run mrtk_pr

/azp run mrtk_docs

Test failure I think is related to the way I didn't comment out the tests for UWP, will do that shortly.

/azp run mrtk_pr

/azp run mrtk_pr

/azp run mrtk_pr

Awesome work. Thanks @wiwei !


Remove atomic64 feature and use crossbeam::atomic::AtomicCell<u64> for all targets?

In order to support target platforms without AtomicU64, we added a Cargo feature called atomic64 to Moka v0.5.3 and put it into the default feature list (#38, #39).

If the feature is enabled, Moka keeps the old behavior (by using AtomicU64 as timestamps of cache entries).
Otherwise, it uses RwLock<Instant> so that it will compile for such targets.

The feature also controls whether quanta crate is used or not by Moka, because quanta v0.9.2 or earlier do not compile for such targets.
We might want to replace above with crossbeam::atomic::AtomicCell<u64> because it provides a similar functionality to AtomicU64 (when it is supported by the target) and RwLock<u64> (when AtomicU64 is not supported).
https://docs.rs/crossbeam/0.8.1/crossbeam/atomic/struct.AtomicCell.html

Operations on AtomicCells use atomic instructions whenever possible, and synchronize using global locks otherwise.

It will be more convenient as it switches implementations without having a Cargo feature like atomic64. It combines auto-generated Rust source and the build script to achieve auto-switching.
Also, the next version of quanta will support these targets (https://github.com/metrics-rs/quanta/pull/55/), so once it is released, we can always enable quanta.

Before switching to AtomicCell<T>, we need to check its implementation to see if it as efficient as our current implementation.

Also, the next version of quanta will support these targets (metrics-rs/quanta#55), so once it is released, we can always enable quanta.

quanta v0.9.3 has been released and Moka v0.5.4 (next version) and newer will always enable quanta (#42).

Started to use AtomicCell<u64> for wight based eviction: https://github.com/moka-rs/moka/pull/24/commits/4404e6fd1cca5d41aa59688b7b67c842425c7be3


Make routerify::Error as enum or as Box type

We should design the routerify::Error as enum type or as Box<dyn StdError + Send + Sync + 'static> and routerify::Result as pub type Result<T> = std::result::Result<T, Error>;

@rousan If I understand you correctly, we already have
/// The error type used by the error handlers.
pub type RouteError = Box<dyn StdError + Send + Sync + 'static>;

I decided to keep the old string-based Error for compatibility reason, the whole discussion is here https://github.com/routerify/routerify/pull/55

We have two error types right now, routerify::Error and routerify::RouteError and the routerify::Result is based on routerify::RouteError and it is very confusing. So, I was thinking to implement error type based on enum just like this.
use std::fmt::{self, Debug, Display, Formatter};

use derive_more::Display;

#[derive(Display)]
#[non_exhaustive]
pub enum Error {
    #[display(fmt = "unknown field received: {}", "field_name.as_deref().unwrap_or(\"<unknown>\")")]
    UnknownField { field_name: Option<String> },

    /// Failed to decode the field data as `JSON` in
    /// [`field.json()`](crate::Field::json) method.
    #[cfg(feature = "json")]
    #[cfg_attr(nightly, doc(cfg(feature = "json")))]
    #[display(fmt = "failed to decode field data as JSON: {}", _0)]
    DecodeJson(serde_json::Error),
}

impl Debug for Error {
    fn fmt(&self, f: &mut Formatter<'_>) -> fmt::Result {
        Display::fmt(self, f)
    }
}

impl std::error::Error for Error {}

impl PartialEq for Error {
    fn eq(&self, other: &Self) -> bool {
        self.to_string().eq(&other.to_string())
    }
}

impl Eq for Error {}

We have two error types right now, routerify::Error and routerify::RouteError and the routerify::Result is based on routerify::RouteError and it is very confusing.

I agree. In retrospect, I should have made a breaking change for v2 and fixed routerify::Error without introducing routerify::RouteError.
Regarding the enum vs boxed error, I strongly prefer the maximum flexibility of boxed error. I think that in the context of an http router, the error type should be a kind of a container, capable of storing any error-like value. By not imposing any structure (like with enum and its fixed set of variants), we can give the users maximum freedom to define their own custom error enums representing their application needs (one simple example https://github.com/routerify/routerify/issues/42#issuecomment-780140506), with routerify::Error, being a boxed error, simply carrying it between middleware and handlers.
Forcing users to define their own error type can definitely be an inconvenience and extra work in simple cases, but for more complex services they will have to do that anyway. Alternatively, something like anyhow::Error can be used as a quick and simple error type.
So, if you feel that compatibility with v1 is not an issue and you are ok with boxed error, then I think we can get rid of routerify::RouteError, and change routerify::Error to be
pub type Error = Box<dyn StdError + Send + Sync + 'static>;

This will of course be a breaking change and will force us to bump the major version to v3. And this could be a great opportunity to fix another issue with our error handling - drop the E generic parameter from Handler and friends and use routerify::Error as a concrete error type everywhere in Routerify. In addition to simplifying the codebase, this will allow us to decouple different middleware. https://github.com/routerify/routerify/pull/56#issuecomment-798799855 is a good example. There's no reason to force exactly the same concrete error type everywhere.

In general, If the library can provide the specific error types through enum values, the consumer can easily take appropriate action based on Error kind. If we look into hyper::Error or  std::io::Error, they are using some sort of enum to define different types of possible errors.

Hyper uses a combination of both https://docs.rs/hyper/0.14.10/src/hyper/error.rs.html#11-13. There's still a way to get to the original boxed error.
In general, I am not against a more structured error via enum. I'm just not sure how to pick a range of variants that is both sufficient and flexible. Should we approach it from the point of http status codes and create a variant per status? Or the other way around, trying to predict any possible cause, like the aforementioned DecodeJson, DatabaseError, etc.
I think tide's Error type is a nice middle ground https://docs.rs/http-types/2.11.1/src/http_types/error.rs.html#16-20

The difficulty in choosing variants for the public error type is real :)
Take a look at the bottom of this comment in #13, I describe some helper methods used in an existing Routerify application and the associated error type definition. enum HandlerError contains variants which broadly cover common HTTP endpoint handling issues, and which are roughly grouped by applicable status code. Personally, relating closely with HTTP status codes seems like the predictable behavior for an HTTP router's publicly exported error type, but I'm probably biased.
We should consider either creating a similarly broad error-type definition, or take the safe route with boxed error. This would be a good opportunity to add documentation for defining a good error type for one's application.


Construct3?

Any possibility of using this addon in Construct3?

Yes it should work, once converted to C3 addon format
Did you tried this converter ? It's a pretty basic addon, maybe the conversion should work.
https://www.construct.net/fr/forum/construct-3/plugin-sdk-10/plugin-converter-123855


GPC signal is sent despite being disabled on Firefox

It looks like if I disable the GPC signal sending for an individual domain, it is still being sent on Firefox. I saw this behavior on citi.com on the most recent version of Firefox. Do you have the same issue, @kalicki1? If so, could you look into it?

@SebastianZimmeck, I took a cursory look at this and did not see an issue with how the signals are sent. I'm using the most recent version of Firefox and the most recent main branch commit. I ran tests on our GPC test server and citi.com. Whenever I disabled the extension or the individual domain, the signal would be turned off. Let me know if you are still having this issue.
I'm not sure if this is what you did when you tested, but in this version the logic is setup such that if you disable a signal, the domainlist mode is turned on. However, if you then disable the extension and then re-enable it, the mode switches to enable instead of back to domainlist. This then overrides the individual domain off switch. Let me know if this is what you did. I think I mentioned briefly in some old issue we should include a 3-way switch or an indicator denoting whether individual domains are being selected at some point in the future.

OK, as @kalicki1 just clarified in a call we had, the issue was likely that I had the domain list disabled and sending GPC signals to all domains enabled. If that is the case, obviously the signal will be sent. This is resolved.