Long list variable slowing performance

When I try to use a list of 14216 maps, this widget freezes for a few seconds during initialization:
class Slow extends StatefulWidget {
  Slow({Key key}) : super(key: key);

  @override
  _SlowState createState() => _SlowState();
}

class _SlowState extends State<Slow> {
List _list = [
  {
    "code": "110000000",
    "region": "11",
    "district": "0",
    "locality_center": "0",
    "locality": "0",
    "ru_name": "Акмолинская область",
    "kk_name": "Ақмола облысы"
  },
// 14215 maps
];

@override
Widget build(BuildContext context) {
    print('it takes a few seconds before this message is printed in terminal');
    print(_list.length);
    return Container();
}
}

Is there a better way of storing and using huge lists in flutter?

Вы желаете пользователю показывать такие длинные списки? если нет, то используйте SQLITE или HIVE

Hi @nausharipov
Can you please provide your flutter doctor -v, your flutter run --verbose and a minimal complete reproducible code sample?
Thank you
See: Work with long lists

@hamdikahloun
I do not experience the behavior @nausharipov is reporting [ +477 ms] I/flutter ( 9193): 15000
but if you try to animate to bottom (press the fab) the app indeed freezes

code sample
import 'package:flutter/material.dart';

final _manyMaps = [
  for (var i = 0; i < 15000; ++i)
    {
      'code': 'code $i',
      'region': 'region $i',
      'district': 'district $i',
      'locality_center': 'locality_center $i',
      'locality': 'locality $i',
      'ru_name': 'ru_name $i',
      'kk_name': 'kk_name $i',
    }
];

class Foo {
  final String code, region, district, center, locality, ru, kk;
  Foo._({
    required this.center,
    required this.code,
    required this.district,
    required this.kk,
    required this.locality,
    required this.region,
    required this.ru,
  });
  factory Foo(Map<String, Object?> json) {
    return Foo._(
        center: json['locality_center'] as String,
        code: json['code'] as String,
        district: json['district'] as String,
        kk: json['kk_name'] as String,
        locality: json['locality'] as String,
        region: json['region'] as String,
        ru: json['ru_name'] as String);
  }
}

void main() {
  runApp(
    const MaterialApp(
      showPerformanceOverlay: true,
      home: MyHomePage(),
    ),
  );
}

class MyHomePage extends StatefulWidget {
  const MyHomePage() : super(key: const ValueKey('MyHomePage'));

  @override
  _MyHomePageState createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  late final ScrollController _controller;

  @override
  void initState() {
    super.initState();
    _controller = ScrollController();
  }

  @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    print('${_manyMaps.length}');
    return Scaffold(
      body: ListView.builder(
        controller: _controller,
        itemCount: _manyMaps.length,
        itemBuilder: (context, index) {
          final foo = Foo(_manyMaps[index]);
          print('${foo.code}');
          return Row(
            children: [
              Text(foo.center),
              const SizedBox(width: 20),
              Text(foo.code),
              const SizedBox(width: 20),
              Text(foo.district),
              const SizedBox(width: 20),
              Text(foo.kk),
              const SizedBox(width: 20),
              Text(foo.locality),
              const SizedBox(width: 20),
              Text(foo.region),
              const SizedBox(width: 20),
              Text(foo.ru),
            ],
          );
        },
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: () => _controller.animateTo(
          _controller.position.maxScrollExtent,
          duration: const Duration(seconds: 5),
          curve: Curves.easeOut,
        ),
        child: const Icon(Icons.arrow_downward),
      ),
    );
  }
}

flutter run --release -v
[ +112 ms] ✓  Built build/app/outputs/flutter-apk/app-release.apk (6.0MB).
[   +4 ms] executing: /home/francesco/Android/Sdk/build-tools/30.0.2/aapt dump
xmltree /home/francesco/projects/issue/build/app/outputs/flutter-apk/app.apk
AndroidManifest.xml
[   +7 ms] Exit code 0 from: /home/francesco/Android/Sdk/build-tools/30.0.2/aapt
dump xmltree
/home/francesco/projects/issue/build/app/outputs/flutter-apk/app.apk
AndroidManifest.xml
[        ] N: android=http://schemas.android.com/apk/res/android
             E: manifest (line=2)
               A: android:versionCode(0x0101021b)=(type 0x10)0x1
               A: android:versionName(0x0101021c)="1.0.0" (Raw: "1.0.0")
               A: android:compileSdkVersion(0x01010572)=(type 0x10)0x1e
               A: android:compileSdkVersionCodename(0x01010573)="11" (Raw: "11")
               A: package="com.example.issue" (Raw: "com.example.issue")
               A: platformBuildVersionCode=(type 0x10)0x1e
               A: platformBuildVersionName=(type 0x10)0xb
               E: uses-sdk (line=7)
                 A: android:minSdkVersion(0x0101020c)=(type 0x10)0x10
                 A: android:targetSdkVersion(0x01010270)=(type 0x10)0x1e
               E: application (line=11)
                 A: android:label(0x01010001)="issue" (Raw: "issue")
                 A: android:icon(0x01010002)=@0x7f080000
                 A:
                 android:appComponentFactory(0x0101057a)="androidx.core.app.Core
                 ComponentFactory" (Raw:
                 "androidx.core.app.CoreComponentFactory")
                 E: activity (line=15)
                   A: android:theme(0x01010000)=@0x7f0a0000
                   A: android:name(0x01010003)="com.example.issue.MainActivity"
                   (Raw: "com.example.issue.MainActivity")
                   A: android:launchMode(0x0101001d)=(type 0x10)0x1
                   A: android:configChanges(0x0101001f)=(type 0x11)0x40003fb4
                   A: android:windowSoftInputMode(0x0101022b)=(type 0x11)0x10
                   A: android:hardwareAccelerated(0x010102d3)=(type
                   0x12)0xffffffff
                   E: meta-data (line=29)
                     A:
                     android:name(0x01010003)="io.flutter.embedding.android.Norm
                     alTheme" (Raw: "io.flutter.embedding.android.NormalTheme")
                     A: android:resource(0x01010025)=@0x7f0a0001
                   E: meta-data (line=39)
                     A:
                     android:name(0x01010003)="io.flutter.embedding.android.Spla
                     shScreenDrawable" (Raw:
                     "io.flutter.embedding.android.SplashScreenDrawable")
                     A: android:resource(0x01010025)=@0x7f040000
                   E: intent-filter (line=43)
                     E: action (line=44)
                       A: android:name(0x01010003)="android.intent.action.MAIN"
                       (Raw: "android.intent.action.MAIN")
                     E: category (line=46)
                       A:
                       android:name(0x01010003)="android.intent.category.LAUNCHE
                       R" (Raw: "android.intent.category.LAUNCHER")
                 E: meta-data (line=53)
                   A: android:name(0x01010003)="flutterEmbedding" (Raw:
                   "flutterEmbedding")
                   A: android:value(0x01010024)=(type 0x10)0x2
[   +3 ms] Stopping app 'app.apk' on Pixel 3a.
[        ] executing: /home/francesco/Android/Sdk/platform-tools/adb -s
965AY0WP5C shell am force-stop com.example.issue
[ +125 ms] executing: /home/francesco/Android/Sdk/platform-tools/adb -s
965AY0WP5C shell pm list packages com.example.issue
[ +104 ms] package:com.example.issue
[   +5 ms] executing: /home/francesco/Android/Sdk/platform-tools/adb -s
965AY0WP5C shell cat /data/local/tmp/sky.com.example.issue.sha1
[  +94 ms] 900c5ff46a5986d2339e084e00a4e03d07ccedf6
[   +2 ms] Latest build already installed.
[   +2 ms] executing: /home/francesco/Android/Sdk/platform-tools/adb -s
965AY0WP5C shell am start -a android.intent.action.RUN -f 0x20000000 --ez
enable-background-compilation true --ez enable-dart-profiling true
com.example.issue/com.example.issue.MainActivity
[ +109 ms] Starting: Intent { act=android.intent.action.RUN flg=0x20000000
cmp=com.example.issue/.MainActivity (has extras) }
[   +6 ms] Application running.
[   +9 ms] Flutter run key commands.
[   +5 ms] h Repeat this help message.
[   +1 ms] c Clear the screen
[   +1 ms] q Quit (terminate the application on the device).
[ +477 ms] I/flutter ( 9193): 15000
[   +1 ms] I/flutter ( 9193): code 0
[   +4 ms] I/flutter ( 9193): code 1
[        ] I/flutter ( 9193): code 2
[   +1 ms] I/flutter ( 9193): code 3
[   +2 ms] I/flutter ( 9193): code 4
[        ] I/flutter ( 9193): code 5
[   +1 ms] I/flutter ( 9193): code 6
[   +1 ms] I/flutter ( 9193): code 7
[   +1 ms] I/flutter ( 9193): code 8
[   +1 ms] I/flutter ( 9193): code 9
[   +1 ms] I/flutter ( 9193): code 10
[   +1 ms] I/flutter ( 9193): code 11
[        ] I/flutter ( 9193): code 12
[   +1 ms] I/flutter ( 9193): code 13
[   +1 ms] I/flutter ( 9193): code 14
[   +1 ms] I/flutter ( 9193): code 15
[   +1 ms] I/flutter ( 9193): code 16
[        ] I/flutter ( 9193): code 17
[   +2 ms] I/flutter ( 9193): code 18
[        ] I/flutter ( 9193): code 19
[   +2 ms] I/flutter ( 9193): code 20
[        ] I/flutter ( 9193): code 21
[        ] I/flutter ( 9193): code 22
[   +1 ms] I/flutter ( 9193): code 23
[        ] I/flutter ( 9193): code 24
[   +2 ms] I/flutter ( 9193): code 25
[   +1 ms] I/flutter ( 9193): code 26
[   +1 ms] I/flutter ( 9193): code 27
[        ] I/flutter ( 9193): code 28
[   +1 ms] I/flutter ( 9193): code 29
[   +1 ms] I/flutter ( 9193): code 30
[   +1 ms] I/flutter ( 9193): code 31
[   +1 ms] I/flutter ( 9193): code 32
[   +2 ms] I/flutter ( 9193): code 33
[        ] I/flutter ( 9193): code 34
[        ] I/flutter ( 9193): code 35
[        ] I/flutter ( 9193): code 36
[   +1 ms] I/flutter ( 9193): code 37
[   +1 ms] I/flutter ( 9193): code 38
[   +1 ms] I/flutter ( 9193): code 39
[        ] I/flutter ( 9193): code 40
[        ] I/flutter ( 9193): code 41
[        ] I/flutter ( 9193): code 42
[        ] I/flutter ( 9193): code 43
[   +1 ms] I/flutter ( 9193): code 44
[   +1 ms] I/flutter ( 9193): code 45
[   +2 ms] I/flutter ( 9193): code 46
[   +1 ms] I/flutter ( 9193): code 47
[   +1 ms] I/flutter ( 9193): code 48
[        ] I/flutter ( 9193): code 49
[        ] I/flutter ( 9193): code 50
[        ] I/flutter ( 9193): code 51
[        ] I/flutter ( 9193): code 52
[   +1 ms] I/flutter ( 9193): code 53
[   +1 ms] I/flutter ( 9193): code 54
[   +1 ms] I/flutter ( 9193): code 55
[        ] I/flutter ( 9193): code 56
[   +1 ms] I/flutter ( 9193): code 57
[   +1 ms] I/flutter ( 9193): code 58
[   +1 ms] I/flutter ( 9193): code 59
[   +1 ms] I/flutter ( 9193): code 60
[   +1 ms] I/flutter ( 9193): code 61

doctor
[✓] Flutter (Channel master, 2.1.0-13.0.pre.574, on Linux, locale en_US.UTF-8)
    • Flutter version 2.1.0-13.0.pre.574 at
      /home/francesco/snap/flutter/common/flutter
    • Framework revision 02efffc134 (26 hours ago), 2021-04-10 03:49:01 -0400
    • Engine revision 8863afff16
    • Dart version 2.13.0 (build 2.13.0-222.0.dev)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
    • Android SDK at /home/francesco/Android/Sdk
    • Platform android-30, build-tools 30.0.2
    • ANDROID_SDK_ROOT = /home/francesco/Android/Sdk
    • Java binary at: /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_282-8u282-b08-0ubuntu1~20.04-b08)
    • All Android licenses accepted.

[✓] Chrome - develop for the web
    • CHROME_EXECUTABLE = /snap/bin/chromium

[✓] Linux toolchain - develop for Linux desktop
    • clang version 10.0.0-4ubuntu1
    • cmake version 3.16.3
    • ninja version 1.10.0
    • pkg-config version 0.29.1

[!] Android Studio (not installed)
    • Android Studio not found; download from
      https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/linux#android-setup
      for detailed instructions).

[✓] Connected device (3 available)
    • Pixel 3a (mobile) • 965AY0WP5C • android-arm64  • Android 11 (API 30)
    • Linux (desktop)   • linux      • linux-x64      • Linux
    • Chrome (web)      • chrome     • web-javascript • Chromium 89.0.4389.114
      snap

! Doctor found issues in 1 category.

@hamdikahloun
I do not experience the behavior @nausharipov is reporting [ +477 ms] I/flutter ( 9193): 15000
but if you try to animate to bottom (press the fab) the app indeed freezes
just watch the gif until the end
code sample
flutter run --release -v
doctor

@ta9ki

Вы желаете пользователю показывать такие длинные списки? если нет, то используйте SQLITE или HIVE
Do you want the user to show such long lists? if not then use SQLITE or HIVE

in some case it might be useful to cache a big chunk of data rather query every single element of the list,

@hamdikahloun the code sample @iapicca sent is accurate. Here's my flutter doctor:
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 2.0.4, on macOS 11.2.3 20D91 darwin-arm, locale en)
[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
[✓] Xcode - develop for iOS and macOS
[✓] Chrome - develop for the web
[✓] Android Studio (version 4.1)
[✓] VS Code (version 1.55.1)
[✓] Connected device (2 available)
• No issues found!

3
On Sat, Apr 10, 2021, 12:39 AM nausharipov @.***> wrote:

When I try to use a list of 14216 maps, this widget freezes for a few
seconds during initialization:
List _list = [
{
"code": "110000000",

"region": "11",

"district": "0",

"locality_center": "0",

"locality": "0",

"ru_name": "Акмолинская область",

"kk_name": "Ақмола облысы"

},...];
@override
Widget build(BuildContext context) {
print('it takes a few seconds before this message is printed in terminal');

print(_list.length);

return Container();

}
Is there a better way of storing and using huge lists in flutter?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/80176, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARNI3VTJ2WHHGSHTKKOC4T3TH7QBXANCNFSM42WELOSA
.

flutter doctor -v
[✓] Flutter (Channel stable, 2.0.4, on Mac OS X 10.15.4 19E2269 darwin-x64,
    locale en-GB)
    • Flutter version 2.0.4 at /Users/dhs/documents/fluttersdk/flutter
    • Framework revision b1395592de (7 days ago), 2021-04-01 14:25:01 -0700
    • Engine revision 2dce47073a
    • Dart version 2.12.2

[!] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.3, Build version 12C33
    ! CocoaPods 1.9.3 out of date (1.10.0 is recommended).
        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 upgrade 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 (version 4.1)
    • Android Studio at /Applications/Android Studio.app/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
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.55.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.20.0

[✓] Connected device (3 available)
    • SM A260G (mobile)            • 5200763ebcfa861f • android-arm    • Android
      8.1.0 (API 27)
    • Darshan's iphone (mobile) • 21150b119064aecc249dfcfe05e259197461ce23 • ios
      • iOS 14.4.1
    • macOS (desktop)           • macos                                    •
      darwin-x64     • Mac OS X 10.15.4 19E2269 darwin-x64
    • Chrome (web)              • chrome                                   •
      web-javascript • Google Chrome 89.0.4389.114

! Doctor found issues in 1 category.

This issue still persists on stable and master as of writing this. Refer to @iapicca's comment here for the code samples I used for this test. The outcome is the same
flutter doctor -v
[✓] Flutter (Channel master, 2.13.0-0.0.pre.1026, on macOS 12.3.1 21E258 darwin-arm, locale en-US)
    • Flutter version 2.13.0-0.0.pre.1026 at /Users/nabeelparkar/fvm/versions/master
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision c1b909e3fc (5 hours ago), 2022-05-10 22:49:08 -0700
    • Engine revision 70c5bdfa3b
    • Dart version 2.18.0 (build 2.18.0-103.0.dev)
    • DevTools version 2.13.1

[✓] Android toolchain - develop for Android devices (Android SDK version 32.0.0-rc1)
    • Android SDK at /Users/nabeelparkar/Library/Android/sdk/
    • Platform android-32, build-tools 32.0.0-rc1
    • ANDROID_SDK_ROOT = /Users/nabeelparkar/Library/Android/sdk/
    • Java binary at: /opt/homebrew/opt/openjdk@11/bin/java
    • Java version OpenJDK Runtime Environment Homebrew (build 11.0.15+0)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 13.3.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • CHROME_EXECUTABLE = /Applications/Brave Browser.app/Contents/MacOS/Brave Browser

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/macos#android-setup for detailed instructions).

[✓] IntelliJ IDEA Ultimate Edition (version 2022.1)
    • IntelliJ at /Applications/IntelliJ IDEA.app
    • Flutter plugin version 67.0.4
    • Dart plugin version 221.5588

[✓] VS Code (version 1.67.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.40.0

[✓] Connected device (3 available)
    • V2050 (mobile)  •<PHONE_NUMBER>000NM • android-arm64  • Android 12 (API 31)
    • macOS (desktop) • macos           • darwin-arm64   • macOS 12.3.1 21E258 darwin-arm
    • Chrome (web)    • chrome          • web-javascript • Brave Browser <IP_ADDRESS>

[✓] HTTP Host Availability
    • All required HTTP hosts are available

! Doctor found issues in 1 category.

I still some strange behavior from ScrollController
opening an issue to investigate

https://github.com/flutter/flutter/issues/153085


Add Chatbot for User Assistance and Transaction Support on DecenTrade

Add Chatbot for User Assistance and Transaction Support on DecenTrade   close #94
https://github.com/user-attachments/assets/ec16e5cc-0536-4cc3-8c4c-e2924b0d931f

@4darsh-Dev pls merge this pr and guve level 3

@4darsh-Dev sorry sir pls sir can you merge  this because my mid sem start from Tomorrow so i don't have time

@4darsh-Dev  I can fix after my exam is over

@4darsh-Dev  cursor component is added pls check

@4darsh-Dev  pls check

u can see deployment link : https://decentrade-ehma9k3bq-adarsh-mauryas-projects.vercel.app/

@4darsh-Dev custmor cursor added pls check

@4darsh-Dev check this pr

@4darsh-Dev  pls check

Gentle Reminder 🚨🚨
GSSoC-Ext 24 is going to complete in 2 Days. '
Complete your assigned Issues and PR reviews before time to get Points on Leaderboard. '
It was a great experience working with you all, Don't forget to ⭐ star the Repo (only 12 with 62 forks 💔) .
Thanks💗 for your valuable contributions!


Fixing test after netMHCpan 2.8 -> 3.0 update.

Fixes #63

This change is

Coverage remained the same at 91.525% when pulling 877c808b7d205ecd5f53ceec278d9f218d2b7c00 on fix-test-after-netmhcpan-update into 07873614eb87a6a459082e27b2e66ce00e2d5376 on master.


[iOS][0.30.0][0.29.2][PushNotificationIOS] getInitialNotification() returns empty object

componentWillMount() {
  PushNotificationIOS.getInitialNotification()
  .then((notification) => {
    alert('coldLaunchPush: ' + JSON.stringify(notification));
  });
}

(V0.30.0, V0.29.2) (IOS, MAC)
Cold app launch from remote push returns empty object {} It was working on V0.28.0 with popInitialNotification() which got deprecated.
Is this a bug or I'm missing something? Asked on stackoverflow didn't received any response.

The bug has been fixed in v0.31.0

Thanks for the info but I just read the release notes for V0.31.0 and I didn't find any related commit to this issue?

Yes, It does not. But it has been fixed

Here's similar question -> http://stackoverflow.com/questions/38645181/how-to-work-with-react-natives-pushnotificationios-getinitialnotification that I've answered earlier today.
Going to close it for now as @ymmuse reports it to be fixed. @antihate in case you encounter this issue on 0.31-rc, please let me know and we will reopen.

I'll report back after 0.31 release, Thanks!

@AntiHate I had this issue on 0.30, and can confirm everything is working as expected with 0.31.0-rc.1.

Yes, its fixed, Thankyou everybody!


xteve.m3u produces tons of duplicates/wrong channels

Hi,
I created a m3u from enigma and imported this in xteve. I mapped an EPG XML. Everything is fine. A few days later however I notice that in Plex I choose channel A it display video of channel B.
When I look into the xteve GUI I see that the channel name is correct (A) but directly below it shows the name of the wrong channel (B). xteve.m3u also shows this. While the first line is correct
#EXTINF:0 channelID="x-ID.8" tvg-chno="1008" tvg-name="VOX HD" tvg-id="1008" tvg-logo="" group-title="enigma",VOX HD
the second line reflects the stream ID of the wrong channel. After time this wrong channel (the last one in my channel list) is duplicating itself on top of other channels and it seems to get worse day after day.
When I delete the M3U, reenter it and redo the mapping all is well for a certain period. But this is a PITA for 60+ channels every few days. Any idea where to look?
xteve 2.2.0.

Just happened once more. Strangely enough the duplicates are always duplicates to the last channel of the m3u list I have (which is N24 DOKU). Any idea where to look?  This is terribly annoying.

I'm having the exact same issue.
I use two lists one is from enigma2 receiver and the other one is regular IPTV list.

Sounds like a issue coming from the Provider, but we will look into it.

I think this is the same issue as https://github.com/xteve-project/xTeVe/issues/230
I tried the beta version and it seams it is fixed in beta.

Beta and Release are the same Build now for over a year.

I don't know what to tell you. With regular release I have the issue, but with beta I don't.

I'm just now running into this issue. Has any progress on this occurred? Does running the beta branch still resolve this?

There is no Beta branch. All releases are the same.

There is no Beta branch. All releases are the same.

How do we overcome it then? I still seem to be getting this issue.


docs(Ng1StateHooks): Corrected interface and docs

Updated interfaces and documentation to fix #3072
Not sure if documentation looks correct, since I wasn't able to build it correctly.

With this change, at least typings/Typescript won't throw errors with dependency injection in Angular 1.

Did you mean to close this?

No, I messed up with my master branch and it closed automatically. I could not open it :)
I was looking into the travis build failures. I found out why it's messed up. But maybe this is not the right place to discuss it, or you might already know how to fix it.

The failed check in travis can be solved by upgrading npm above v3 (found it here). I tried this on my fork, and it made that particular error go away.
The next error that pops up is due to the cloning and installing of ui-router/core from travis. When npm install ./ui-router-core is run, it will trigger the prepublish hook in ui-router/core (which will be deprecated in npm@4). This would be fine, except that the npm test script fails miserably due to no node_modules being installed.
So a possible solution would be to cd ui-router-core && npm i && cd .. to install node_modules in the cloned core repo, but that would add alot of time to the build. Since I could not find an easy solution to the failing Travis build, I'll just add my findings here for now.


adding To-Do list

Pull Request Type
What kind of change does this PR introduce?
[ x] Solved an issue/task
[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:
Issue Number: [#1109]
What is the new behavior?
Other information
adding todo application

Merged

This is an automated message from Fork, Commit, Merge [BOT].

Thank you for your contribution! Your pull request has been merged. The files have been reset for the next contributor.
What's next?
If you're looking for more ways to contribute, I invite you to check out my other projects. Just click here to find more. These projects contain real issues that you can help resolve. You can also check out the Influences section in the README to find more projects similar to this one.
Also please leave a star to this project if you feel it helped you, i would really appreciate it.
I look forward to seeing your contributions!


Blocking and Reposting Epic (work required to fully remove filters app side)

[x] figure out what resolve should show when content is blocked / filtered. There should be some indication on resolve that the content was filtered.

[x] figure out how we are differentiating between blocking / filter lists. We could go with tags or blocking channel name + tag (or some other way to designate blocking vs filtering). Right now we have 2 params, but besides the name (lbry-blocked, and lbry-filtered), there's no indication of which is which. Also, when doing a claim search, only one high level blocked summary is shown.

Not sure if separate channels alone will work for distinguishing for this- since the output in claim search/resolve will vary by the type. i.e. a filtered claim will still resolve and show why it was filtered, whereas a blocked one won't fully resolve. Filtered would be removed from claim search though. A third type would be web-only filtered, but that should work with lbry.tv + additional filtered channel.
The other downstream work, like on reflector, will also need to make a decision on what to do based on the type (i.e. don't delete blobs for filtered, but delete for blocked). Also, for https://github.com/lbryio/lbry-sdk/issues/2740 to work, it would need to know which (at least a count) are filtered

[x] Should/could we do something about claims being reposted to a new channel if channel level blocking is used?

[x] Add additional metadata options to repost api https://github.com/lbryio/lbry-sdk/issues/2679

[x] Add / support APIs for updating reposts https://github.com/lbryio/lbry-sdk/issues/2678

[x] support blocked channel ids - all claims signed by this channel should be blocked.

[x] support filtering (only block from claim searches, don't block from resolve).

My notes from recent testing:

[x] blocking stops it from being resolved currently - is that what we decided? How would we know something doesn't exist vs is blocked?

[x] Channel fails to return when referenced by name, but shows blocked if queried by id:

C:\Users\SoloDolo\Desktop>lbrynet claim search --channel=@FransNFNRoses
{
  "blocked": {
    "total": 0
  },
  "items": [],
  "page": 1,
  "page_size": 20,
  "total_items": 0,
  "total_pages": 0
}
C:\Users\SoloDolo\Desktop>lbrynet claim search --claim_ids=1ff8b739ba27392d025f7fb58f94e7ea802c6ab3
{
  "blocked": {
    "reposted_in_channel": {
      "ccd46c266d0ef9f4cbcd383ab29408c26073dc44": 1
    },
    "total": 1
  },
  "items": [],
  "page": 1,
  "page_size": 20,
  "total_items": 1,
  "total_pages": 1
}

@tzarebczan lex's notes say this is "fixed from last time". can i close it?

This is an epic that needs more follow on work. Hopefully in the next week or two we can fully close out.


Custom Domain + SSL

Is it possible to use a custom domain with SSL?
I didn't find in the documentation.

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

ID: 190b1ed3-0712-2f19-4e8f-a2a8519d136e
Version Independent ID: b02adbf4-d2a8-6c84-e70a-ff59fb3cbb7b
Content: Setup a custom domain in Azure Static Web Apps
Content Source: articles/static-web-apps/custom-domain.md
Service: static-web-apps
GitHub Login: @burkeholland
Microsoft Alias: buhollan

@epomatti Thanks for the feedback! We are currently investigating and will update you shortly.

@epomatti Thanks for asking question! You may want to know custom domains are natively supported in Static Web Apps including Microsoft’s free SSL certificate offer.  To add to this there is no ‘certificates’ concept in SWA but as I mentioned it is implicit in the offering.

@SnehaAgrawal-MSFT I read that, but I assumed that it was the default generated domain.
What is Microsoft's free SSL certificate offer?

@epomatti Thanks for reply! As its mentioned in this document free SSL certificates means these are automatically renewed and one of the key feature of Azure Static Web App Preview. You may also refer to this blog might be helpful.

@epomatti We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion.

@SnehaAgrawal-MSFT the document that you have linked describes a very cumbersome process to adding SSL via Let's Encrypt & says that we need to use this method while Static Web Apps is in Preview. However, you say that SSL certs are automatically renewed as a key feature of the web app preview.
As it stands, I have added a custom domain and I don't see any options for adding a free SSL certificate, and I get a certificate error when I try to visit the site using a CNAME record.

This is not resolved. I have the same issue. The free SSL only works for *.staticsites-prod-westus2.p.azurewebsites.net but does not support the custom domain

This is not resolved. I have the same issue. The free SSL only works for *.staticsites-prod-westus2.p.azurewebsites.net but does not support the custom domain


Why use unsafe_pcall/unsafe_xpcall instead of  pcall/xpcall

Why use unsafe_pcall/unsafe_xpcall instead of  pcall/xpcall

 They are only safe to be called from Lua code that never calls back to Go ,
why?

Because:

Lua's exceptions are incompatible with Go, golua works around this incompatibility by setting up protected execution environments in lua.State.DoString, lua.State.DoFile and lua.State.Call and turning every exception into a Go panic.

Because:

Lua's exceptions are incompatible with Go, golua works around this incompatibility by setting up protected execution environments in lua.State.DoString, lua.State.DoFile and lua.State.Call and turning every exception into a Go panic.

Thank you very much

A third-party library is called in Lua, such as protoc.lua. If pcall is used in this library, golua will report an error and cannot find pcall. How to solve this?

example:
pcall=unsafe_pcall
Will there be any problems or risks in such use?

Will there be any problems or risks in such use?

No.

Does that mean that I cannot call any third-party libraries with pcall and xpcall?

Does that mean that I cannot call any third-party libraries with pcall and xpcall?

You can but only if there is never any Go frame on the stack between the point where an error is raised and the point where pcall is used.

If the third-party library used uses pcall/xpcall, the program will not start. Is there a solution for this?

Comment out the code that hides pcall, xpcall?

Does that mean that I cannot call any third-party libraries with pcall and xpcall?

You can but only if there is never any Go frame on the stack between the point where an error is raised and the point where pcall is used.

If the third-party library used uses pcall/xpcall, the program will not start. Is there a solution for this?

Comment out the code that hides pcall, xpcall?

Is there any risk in commenting out pcall/xpcall?

Is there any risk in commenting out pcall/xpcall?

Do you mean commenting out the code that hides pcall and xpcall? Yes, all the lua code will have to be audited to make sure that it doesn't use errors + pcall/xpcall in a way that can crash the go runtime.


implement MultiWriteNorFlash for the nrf9160

per the product specification section 4.4 there can be n_write writes, where t_write = 2 source. Unless I'm missing something, that means that the contract of MultiWriteNorFlash is satisfied.

Using this in an application gives
warning: Linking globals named 'DEVICE_PERIPHERALS': symbol multiply defined!

error: failed to load bc of "nrf9160_pac-a62a87be05e92ef9.nrf9160_pac.20f4e1dd-cgu.4.rcgu.o":

warning: `connected-pallet-firmware` (bin "connected-pallet-firmware") generated 1 warning
The following warnings were emitted during compilation:

warning: head: 75d48ef, tag-version: b1ad42b, dirty: true, production: false

Not sure what this means, but I guess another feature flag needs to be added/removed somewhere?

Indeed, this looks correct. Thanks!
bors r+


Option to couple zero line in multi-axis charts

Feature Proposal
Would be possible to add an option to couple the zero line in multi-axis charts? I think it is confusing when the zero is in different positions.

Feature Use Case
A developer wants that all y-axis starts at the same position. It adds a configuration property CommonZeroLine: true.
Possible Implementation
I would be happy to help if someone points me in the right direction

Maybe you could call getPixelForValue(0) on each to see which is closer to the center. Then on the other you could recalculate min and max appropriately. You can probably do it without touching the library code at all, so I'd start with that

Hi @benmccann, thanks for your answer. When you refer to min and max, you mean this ones?
let options = {
    scale: {
        ticks: {
            max: 5,
            min: 0,
        }
    }
};

Following your idea of min and max and using the rule of three:
this.chart.options.scales.yAxes[1].ticks.max = this.chart.scales['y-axis-1'].end * this.chart.scales['y-axis-2'].end / this.chart.scales['y-axis-1'].end
this.chart.options.scales.yAxes[1].ticks.min = this.chart.scales['y-axis-1'].start * this.chart.scales['y-axis-2'].end / this.chart.scales['y-axis-1'].end

I think I'm closer :), now I need to figure out how to update the other axis values

I'm gonna copy the snipped I did. I'm tacking the left y-axis as a reference and adapting the right y-axis with the same holes and the same zero line but with a different scale. The result is exactly what I need so I'll close the issue, thanks!
export default function alignZeroLineRightAxis(chart) {
    const leftAxisStart = chart.scales['y-axis-1'].start,
        leftAxisEnd = chart.scales['y-axis-1'].end,
        rightAxisEnd = chart.scales['y-axis-2'].end,
        rightAxisMin = leftAxisEnd * rightAxisEnd / leftAxisEnd,
        rightAxisMax =  leftAxisStart * rightAxisEnd / leftAxisEnd,
        holes = chart.scales['y-axis-1'].ticks.length - 1,
        space = Math.abs(rightAxisMin) + Math.abs(rightAxisMax),
        spacePerHole =  space / holes

    chart.options.scales.yAxes[1].ticks.max = rightAxisMin
    chart.options.scales.yAxes[1].ticks.min = rightAxisMax
    chart.options.scales.yAxes[1].ticks.stepSize = spacePerHole
    chart.update()
}


Repos for each specialty certificate

Requesting repos so we can separate the CC Certifications for each specialty:

cc-cert-gov
cc-cert-lib
cc-cert-edu

Who should be admins on these? Yourself and Paul?

Yes, that will do. Thanks
On Thu, Jan 12, 2017 at 9:55 AM, Rob Myers<EMAIL_ADDRESS>wrote:

Who should be admins on these? Yourself and Paul?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/creativecommons/cc-cert-map/issues/20#issuecomment-272218171,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAcQvqG95_gPHk2MAc-PVMf-31Mze0Mhks5rRlsAgaJpZM4Lh4Vw
.

--
----------------------------------------------------------------------------------------------------
Alan Levine
info: cog.dog  • blog: cogdogblog.com  • tweets: @cogdog
http://twitter.com/cogdog
photos: flickr http://flickr.com/photos/cogdog & Barking Dog
http://barkingdog.me • code: github.com/cogdog
------------------------------------------------------------------------------------
----------------

OK those now exist.
I've given write access to the CC Cert team which is yourself, Paul and me. If we need to add more people I can make you admins rather than add people to the team - it also controls the map, the theme, and opened16.

Yes, I need to add our other project members to the new repos, can I have
admin access to the new ones? Thanks
On Thu, Jan 12, 2017 at 9:19 PM, Rob Myers<EMAIL_ADDRESS>wrote:

OK those now exist.
I've given write access to the CC Cert team which is yourself, Paul and
me. If we need to add more people I can make you admins rather than add
people to the team - it also controls the map, the theme, and opened16.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/creativecommons/cc-cert-map/issues/20#issuecomment-272343520,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAcQvnxXhJkCErAoMF_3o8h-MVSCi5mRks5rRt8WgaJpZM4Lh4Vw
.

--
----------------------------------------------------------------------------------------------------
Alan Levine
info: cog.dog  • blog: cogdogblog.com  • tweets: @cogdog
http://twitter.com/cogdog
photos: flickr http://flickr.com/photos/cogdog & Barking Dog
http://barkingdog.me • code: github.com/cogdog
------------------------------------------------------------------------------------
----------------

Certainly. The Cert team are now admins on those repos (this includes you and Paul).


Interactive transactions not working with $queryRaw and $executeRaw in 2.29.0

Bug description
The transactionId cannot get passed down from the proxied client to $queryRaw and $executeRaw's custom promises.
How to reproduce

Expected behavior
No response
Prisma information

Environment & setup

OS:
Database:
Node.js version:

Prisma Version
2.29.0

Fix now available in the 2.29.1 patch just released a minute ago.


Generate QueryInterface-like helper function for callbacks

Not sure if this is warranted.  I longed to use the same neat pattern that landed just today with DXC's DxcCreateInstance function, which is simply a callback on a native function.  There's quite a bit of duplication with the implementation in function.rs, too.  Curious to hear your thoughts!

Neat, do you know of a Win32 callback that uses this pattern that we could use for a test?

Unfortunately I don't, I was testing around with https://github.com/microsoft/win32metadata/pull/450 if that's helpful.

If something's coming down the road, we can wait on this until the metadata is available.

@kennykerr I might as well paste what this generates to:
pub type DxcCreateInstance2Proc = unsafe extern "system" fn(
    pmalloc: ::windows::RawPtr,
    rclsid: *const ::windows::Guid,
    riid: *const ::windows::Guid,
    ppv: *mut *mut ::std::ffi::c_void,
) -> ::windows::HRESULT;
pub unsafe fn DxcCreateInstance2Proc<'a, T: ::windows::Interface>(
    func: &DxcCreateInstance2Proc,
    pmalloc: impl ::windows::IntoParam<'a, super::super::Windows::Win32::System::Com::IMalloc>,
    rclsid: *const ::windows::Guid,
) -> ::windows::Result<T> {
    let mut result__ = ::std::option::Option::None;
    (func)(
        pmalloc.into_param().abi(),
        ::std::mem::transmute(rclsid),
        &<T as ::windows::Interface>::IID,
        ::windows::Abi::set_abi(&mut result__),
    )
    .and_some(result__)
}
pub type DxcCreateInstanceProc = unsafe extern "system" fn(
    rclsid: *const ::windows::Guid,
    riid: *const ::windows::Guid,
    ppv: *mut *mut ::std::ffi::c_void,
) -> ::windows::HRESULT;
pub unsafe fn DxcCreateInstanceProc<T: ::windows::Interface>(
    func: &DxcCreateInstanceProc,
    rclsid: *const ::windows::Guid,
) -> ::windows::Result<T> {
    let mut result__ = ::std::option::Option::None;
    (func)(
        ::std::mem::transmute(rclsid),
        &<T as ::windows::Interface>::IID,
        ::windows::Abi::set_abi(&mut result__),
    )
    .and_some(result__)
}

It is allowed to have identical names because the type alias is part of the "type" namespace and the function part of the "value" namespace (https://doc.rust-lang.org/nightly/reference/names/namespaces.html).

If something's coming down the road, we can wait on this until the metadata is available.

It's here now, see #802 😄

Closing for now as there is no tests to support it. I plan to make it easier to write tests for APIs like this at which point we can revisit this.

You could have given me some time to come up with another test or example after closing #802, instead of closing this outright too.

https://docs.microsoft.com/en-us/windows/win32/api/d3d12/nf-d3d12-d3d12createdevice D3D12 has some function pointers that could use this, for example:
pub type PFN_D3D12_CREATE_DEVICE = unsafe extern "system" fn(
    param0: ::windows::RawPtr,
    param1: super::Direct3D11::D3D_FEATURE_LEVEL,
    param2: *const ::windows::Guid,
    param3: *mut *mut ::std::ffi::c_void,
)
    -> ::windows::HRESULT;
pub unsafe fn PFN_D3D12_CREATE_DEVICE<'a, T: ::windows::Interface>(
    func: &PFN_D3D12_CREATE_DEVICE,
    param0: impl ::windows::IntoParam<'a, ::windows::IUnknown>,
    param1: super::Direct3D11::D3D_FEATURE_LEVEL,
) -> ::windows::Result<T> {
    let mut result__ = ::std::option::Option::None;
    (func)(
        param0.into_param().abi(),
        ::std::mem::transmute(param1),
        &<T as ::windows::Interface>::IID,
        ::windows::Abi::set_abi(&mut result__),
    )
    .and_some(result__)
}
pub type PFN_D3D12_CREATE_ROOT_SIGNATURE_DESERIALIZER =
    unsafe extern "system" fn(
        psrcdata: *const ::std::ffi::c_void,
        srcdatasizeinbytes: usize,
        prootsignaturedeserializerinterface: *const ::windows::Guid,
        pprootsignaturedeserializer: *mut *mut ::std::ffi::c_void,
    ) -> ::windows::HRESULT;
pub unsafe fn PFN_D3D12_CREATE_ROOT_SIGNATURE_DESERIALIZER<
    T: ::windows::Interface,
>(
    func: &PFN_D3D12_CREATE_ROOT_SIGNATURE_DESERIALIZER,
    psrcdata: *const ::std::ffi::c_void,
    srcdatasizeinbytes: usize,
) -> ::windows::Result<T> {
    let mut result__ = ::std::option::Option::None;
    (func)(
        ::std::mem::transmute(psrcdata),
        ::std::mem::transmute(srcdatasizeinbytes),
        &<T as ::windows::Interface>::IID,
        ::windows::Abi::set_abi(&mut result__),
    )
    .and_some(result__)
}
pub type PFN_D3D12_CREATE_VERSIONED_ROOT_SIGNATURE_DESERIALIZER =
    unsafe extern "system" fn(
        psrcdata: *const ::std::ffi::c_void,
        srcdatasizeinbytes: usize,
        prootsignaturedeserializerinterface: *const ::windows::Guid,
        pprootsignaturedeserializer: *mut *mut ::std::ffi::c_void,
    ) -> ::windows::HRESULT;
pub unsafe fn PFN_D3D12_CREATE_VERSIONED_ROOT_SIGNATURE_DESERIALIZER<
    T: ::windows::Interface,
>(
    func: &PFN_D3D12_CREATE_VERSIONED_ROOT_SIGNATURE_DESERIALIZER,
    psrcdata: *const ::std::ffi::c_void,
    srcdatasizeinbytes: usize,
) -> ::windows::Result<T> {
    let mut result__ = ::std::option::Option::None;
    (func)(
        ::std::mem::transmute(psrcdata),
        ::std::mem::transmute(srcdatasizeinbytes),
        &<T as ::windows::Interface>::IID,
        ::windows::Abi::set_abi(&mut result__),
    )
    .and_some(result__)
}
pub type PFN_D3D12_GET_DEBUG_INTERFACE =
    unsafe extern "system" fn(
        param0: *const ::windows::Guid,
        param1: *mut *mut ::std::ffi::c_void,
    ) -> ::windows::HRESULT;
pub unsafe fn PFN_D3D12_GET_DEBUG_INTERFACE<T: ::windows::Interface>(
    func: &PFN_D3D12_GET_DEBUG_INTERFACE,
) -> ::windows::Result<T> {
    let mut result__ = ::std::option::Option::None;
    (func)(
        &<T as ::windows::Interface>::IID,
        ::windows::Abi::set_abi(&mut result__),
    )
    .and_some(result__)
}

Too obscure?

We can always reopen PRs if needed. 😊 I closed this PR as its not made any progress in a few weeks and seemed to be dependent on another closed PR. It lacks an issue that it "fixes" - in future please create issues so we can explore problems and solutions before investing time with implementations and code reviews. PFN_D3D12_GET_DEBUG_INTERFACE seems like a reasonable test case - perhaps open an issue to discuss and illustrate how this might be generally helpful. I don't recall how/why this is beneficial for callbacks vs calls.

We can always reopen PRs if needed.  I closed this PR as its not made any progress in a few weeks and seemed to be dependent on another closed PR.

It took some time to get the rest sorted out, hence remaining stale for a while. For the record, it's always better to discuss how to move forward with the PR from a contributor instead of just closing it and assuming they stopped caring about their contribution too.

It lacks an issue that it "fixes" - in future please create issues so we can explore problems and solutions before investing time with implementations and code reviews.

Unfortunately the hypothetical "Provide an example for DirectXShaderCompiler" issue has already been closed as something not wanted.
There's not really a problem anyway, it's just applying the same neat return-type helper for QueryInterface to callbacks.

PFN_D3D12_GET_DEBUG_INTERFACE seems like a reasonable test case - perhaps open an issue to discuss and illustrate how this might be generally helpful. I don't recall how/why this is beneficial for callbacks vs calls.

I doubt anyone would find that helpful, as the static-linked D3D12GetDebugInterface is available too and probably preferred. Retrieving this function with GetProcAddress and calling it by this PR would be for demonstration purposes only.
If you think demonstrating GetProcAddress, a cast to a callback function signature, and as added bonus this PR to improve the function signature is worth it, I'll reconsider opening an issue about it.

Hi @kennykerr, I'm back at this after the recent official deprecation of com-rs, and would like to know if we can respin this?
To re-state my case, with this PR I could write:
let lib = unsafe { Library::new(dxcompiler_lib_name()) }.unwrap();
let create: Symbol<DxcCreateInstanceProc> = unsafe { lib.get(b"DxcCreateInstance\0") }.unwrap();

let compiler: IDxcCompiler2 = unsafe { DxcCreateInstanceProc(&create, &CLSID_DxcCompiler) }?;
let library: IDxcLibrary = unsafe { DxcCreateInstanceProc(&create, &CLSID_DxcLibrary) }?;

Without it, I have to replace the last two lines with this atrocity (using transmute for lack of a non-verbose way to put together all the pointer casts):
let mut compiler = None::<IDxcCompiler2>;
let mut library = None::<IDxcLibrary>;

unsafe { (create.unwrap())(&CLSID_DxcCompiler, &IDxcCompiler2::IID, std::mem::transmute(&mut compiler)).ok()? };
unsafe { (create.unwrap())(&CLSID_DxcLibrary, &IDxcLibrary::IID, std::mem::transmute(&mut library)).ok()? };

let compiler = compiler.unwrap();
let library = library.unwrap();

There are currently 517 hits for pub type PFN_ and there must be some that behave like QueryInterface (i.e. D3D10/11/12 CREATE_DEVICE). If you point out one that you think is understandable for you, I'll see if I can write a test around it while respinning this to adhere to your earlier request. Please reopen in that case and I'll update the branch accordingly.
If there's still a hard feeling for discussing this in a (new) issue rather than PR thread I'll click "reference in new issue" too :wink:

Happy to discuss this anywhere, but the value of a new (open) issue is that I'll not likely forget about it. I try to regularly review open issues but there's too much going on for me to remember to check the comments on closed issues. 😜


Add minified js to bower.json

Fixes https://github.com/coolaj86/TextEncoderLite/issues/4

@coolaj86 This PR is for aligning the filename (index.js -> text-encoder-lite.js) and references to it, add the minified version to Bower and updating the version number. Please review


Permit duplicates in pre and following measure

Change check output to permit duplicate measure numbers in previous_measure_number and following_measure_number

Done.


How do we make the thing future-proof?

Imagine a breaking change like #1 happening at a time when we have a hatching ecosystem of plugins.
There must be either:

a way for plugins to determine if it’s compatible with the data it gets
a way for the core to determine if a plugin is compatible with the current major version of it

I’m definitely into option 1.

In the spirit of #1 we can attach a version property. Like
doxie([])(myData);

//» {
//»   chunks:  […],
//»   error: null,
//»   version: '1',
//» }

CC: @stoeffel

In the spirit of #1 we can attach a version property.

:+1: to that. We have a similar case in a project at work and just attach a version prop.

Closed through #4


TcpProxy improperly sets :protocol=bytestream for HTTP2

TcpProxy improperly sets :protocol=bytestream for HTTP2:  When using TunnelingConfig for an HTTP/2 tunnel, it send an out-of-spec psuedo header.
Description:
https://github.com/envoyproxy/envoy/blob/main/source/common/tcp_proxy/upstream.cc#L282-L285
Envoy will always set :protocol, but it's not part of the HTTP/2 spec:

https://datatracker.ietf.org/doc/html/rfc7540#section-<IP_ADDRESS>

An extended CONNECT spec does mention it however:

https://datatracker.ietf.org/doc/html/rfc8441#section-3

This becomes a problem for picky implementations, like Go/Golang's net/http:

https://github.com/golang/go/issues/32763
https://github.com/golang/go/blob/81d3c25c6cf39a76b17ab4eda97e8ad7b92a21e9/src/net/http/h2_bundle.go#L2808-L2833

Repro steps:

Run. a Go HTTP/2 server with GODEBUG="http2debug=2"
Create a listener with TunnelingConfig (UsePost=false)
Send traffic from the listener to a cluster with Http2ProtocolOptions AllowConnect and a static endpoint which is a Golang HTTP2 server.
You will see http2: invalid pseudo headers: invalid pseudo-header ":protocol"

cc @lambdai

cc @alyssawilk

Thank @stevenctl for drafting this.
@alyssawilk
I would propose tcp_proxy tunnel doesn't set :protocol by default because tcp_proxy unlikely to proxy websocket
Also, if any protocol override is needed we can relax headers_to_add here.
This relax aligns with other requirements of setting host headers in tunnel. I have some code implementing the relaxation without impacting the HCM router

Additional issue:
For HTTP 2 CONNECT rfc7540 8.3:
o  The ":scheme" and ":path" pseudo-header fields MUST be omitted.

I don't believe that your assesment is correct. The :protocol pseudo-header is what differentiates "extended" CONNECT from the "classic" version. Envoy is using the "extended" CONNECT method for proxying TCP over HTTP/2, so it's correctly using it in this context.
It looks that Go doesn't support the "extended" version, and since it's an extension of the HTTP/2 protocol, it should be negotiated using SETTINGS_ENABLE_CONNECT_PROTOCOL between HTTP/2 endpoints (here: Envoy & Go), but it sounds that Envoy might be using it without proper negotiation.
However, you cannot really proxy TCP over HTTP/2 without it (or without reinventing a custom framing or another method for that purpose), and what should be the fallback.

I believe there is an option to use POST ( for 'legacy' servers ) - and it may be safer to default to it, unless it is explicitly known that the other side supports extended connect.  POST will work with almost all http/2 servers, and has equivalent behavior (connect_config:   allow_post: true)

Right, bytes can be sent using POST (or even GET) method, but that requires prior knowledge.

The upstream headers are prepared after the connection is established. Theoretically we can relies on the negotiated settings.
I am wondering if peeking the negotiated result is overkill.

I don't know if 'POST requires prior knowledge' - it is the most boring POST request, all servers and clients are supposed to support this without any other special handshake. Using extended CONNECT does require knowing that the other side support the extension - POST doesn't since it's universally supported.
No doubt extended CONNECT is more fancy and likely better matching the use case - but why take the extra complexity when a much simpler option exists that works with all existing infrastructure ?

It's not resolved:
I think we have two approach to connect to a server that is not catching up with the extended CONNECT (https://datatracker.ietf.org/doc/html/rfc8441#section-3)

extend the connpool to support subset LB to consume the peer capability
Assuming we pre-know the upstream http server doesn't support the extended CONNECT, add option to use rfc7540 CONNECT, as well as a better error message to the downstream client. For example. an error code other than 200

We did some investigation of the RFCs and I believe this is not the expected protocol to use in this case (or, at least how we want to use CONNECT).
There are a few relevant RFCs here:

https://datatracker.ietf.org/doc/html/rfc844 defines a variant of CONNECT, "Extended CONNECT". This is meant for websockets, and the RFC specifically calls out that this is a protocol to be used directly by WS client -> WS server; proxies should not use this: https://datatracker.ietf.org/doc/html/rfc8441#section-7.
https://tools.ietf.org/html/draft-kinnear-httpbis-http2-transport-02 builds on rfc844 and adds a new :protocol=bytestream". This is not an approved RFC, it is a draft that expired in 2019 (https://datatracker.ietf.org/doc/draft-kinnear-httpbis-http2-transport/). The only public reference to this RFC or :protocol=bytestream` I could find is in Envoy itself: https://cs.github.com/?scopeName=All+repos&scope=&q=%2F%3Aprotocol.%2B%3F%3D.%2B%3Fbytestream%2F. This RFC also has the same mention as 844 that this should not be used by proxy servers: https://datatracker.ietf.org/doc/html/draft-kinnear-httpbis-http2-transport-02#section-4.

In both of these protocols, negotiation is supposed to be done via SETTINGS_ENABLE_CONNECT_PROTOCOL.

cc @wrowe @DavidSchinazi for thoughts

Also was the first link supposed to be https://datatracker.ietf.org/doc/html/rfc8441 ?

Setting :protocol=bytestream is incorrect here. If we proxy TCP, then we're using regular CONNECT and not Extended CONNECT. Extended CONNECT exists to support cases that are explicitly not TCP proxying such as WebSocket, see the full list of defined protocols here. The "bytestream" protocol was written up by Apple for an internal use-case they have that does not involve TCP proxying, and they've abandoned that draft since.

Setting :protocol=bytestream is incorrect here. If we proxy TCP, then we're using regular CONNECT and not Extended CONNECT.

The regular CONNECT method cannot be used for proxying TCP over HTTP/2, since it requires server to open a TCP connection to the destination, and not to layer it on top of HTTP/2.

Extended CONNECT exists to support cases that are explicitly not TCP proxying such as WebSocket, see the full list of defined protocols here. The "bytestream" protocol was written up by Apple for an internal use-case they have that does not involve TCP proxying, and they've abandoned that draft since.

This is missing quite a bit of context.
RFC8441 supports only WebSockets because that was the use case that needed immediate solution at the time. Before it was finalized, I approached Patrick about adding bytestream to support TCP over HTTP/2, and he agreed that it was a good idea, but said that adding it to the draft would delay the standardization process for WebSockets, for which browsers needed solution ASAP. My plan was to write a separate RFC for it, but I stopped that work after Apple presented their draft, which also registered bytestream protocol. Little did I know that they'd later pivot to WebTransport and abandon the original draft.
As such, I believe that using the extended CONNECT method with :protocol=bytestream is the correct solution here, we "only" need to register the bytestream.

I am not sure I understand this. Its in the HTTP/2 spec https://datatracker.ietf.org/doc/html/rfc7540#section-8.3. I have written multiple HTTP2 CONNECT servers/clients in multiple different languages - all seems fine and well supported. Go and rust's hyper library both have code explicitly to handle HTTP/2 CONNECT. AFAIK Chrome also supports this.

Yes, regular CONNECT is well supported, but it requires server to establish a TCP connection to the destination, i.e.
[ client ] --- TCP over HTTP/2 --> [ proxy ] --- TCP --> [ backend ]

whereas we want to proxy TCP over HTTP/2 across multiple hops, i.e.
[ client ] --- TCP over HTTP/2 --> [ proxy ] --- TCP over HTTP/2 --> [ proxy ] --- TCP over HTTP/2 --> (...)

That is, regular CONNECT is terminating HTTP/2, whereas extended CONNECT is not.

As far as I know Envoy is the only software that uses this protocol, and there is no standard for this. Is CONNECT support in Envoy intended to be an Envoy specific protocol not interoperable with other softwares?

It is meant to be interoperable, but the bytestream standardization got lost in the process and it should be revived (although, it might be harder to sell now, since they're working on the WebTransport).

@DavidSchinazi ^ Piotr has a valid point for a HTTP2 tunneling proxy. Regular connect implies termination so we can't chain them without violating RFC.

Thanks, I think I finally get why the bytestream stuff was added, I didn't fully understand until now.
That being said, it still seems like regular CONNECT is useful.
First, isn't this case perfectly valid for Envoy: [ client ] --- TCP over HTTP/2 --> [ proxy ] --- TCP --> [ backend ]
Second, what we want is TCP over HTTP/2 across multiple hops, but not all hops. It seems like the concern is the RFC says

A proxy that supports CONNECT establishes a TCP connection [TCP] to
the server identified in the ":authority" pseudo-header field.

And we are not establishing a raw TCP connection but rather another TCP-over-HTTP/2 connection?
But in practice, what we want is
[ client ] --- TCP  --> [ proxy ] --- TCP over HTTP/2 --> [ proxy ] --- TCP over HTTP/2 --> [ proxy ]   --- TCP --> [ server ]

Which you could interpret still as violating that part of the RFC. However, I think you could also view it as perfectly fine. The fact we have multiple hops is an implementation detail; the RFC doesn't say that a "proxy" must be a single process or cannot other than establish a raw TCP connection (most do a lot more than this, authz, etc).
So really our diagram could look like this:
[ client ] --- TCP  --> [ proxy ] --- TCP over HTTP/2 --> [ "proxy" consisting of multiple Envoy hops of TCP over HTTP/2 ]   --- TCP --> [ server ]

Which seems perfectly fine.
Even if this were to not be 110% RFC compliant (not convinced it isn't, but if), in practice this is supported by a ton of systems. The bytestream is not a standard at all and is not supported by anyone. Using an Envoy specific protocol would not be viable for us.

What is important is that any non-istio proxy can understand the protocol in question. So regular connect is fine at the edges of the mesh for termination, but within the mesh, if the expectation is to expect another hop. Any other proxy would behave correctly at the edge, but would not do the right thing within the mesh, like Piotr described.

within the mesh, the expectation is to anticipate another hop

At any hop we can make any decision, so I don't think we always know the next hop is HTTP/2 or raw TCP.
Also I don't even agree the spec says the next hop cannot be TCP over HTTP/2:

The
payload of any DATA frames sent by the client is transmitted by the
proxy to the TCP server; data received from the TCP server is
assembled into DATA frames by the proxy

All it says is the payload must be transmitted over a TCP connection, it doesn't say how. TCP over HTTP/2 is "transmitting the payload over a TCP connection".
Also, my understand of Envoy philosophy is that downstream and upstream decoupled. It seems the concern is about receiving CONNECT downstream and then sending CONNECT upstream as well -- isn't that not really Envoy's choice to make? If we chose to configure that and it violates some RFC, that doesn't seem like Envoy's concern.

All it says is the payload must be transmitted over a TCP connection, it doesn't say how. TCP over HTTP/2 is "transmitting the payload over a TCP connection".

It's pretty clear what the intent here is, though.

If we chose to configure that and it violates some RFC, that doesn't seem like Envoy's concern.

So the plan is to move away from the extended CONNECT with :protocol=bytestream (because it's not standardized and hence not interoperable) to a regular CONNECT for which we plan to violate RFC (so it won't be interoperable at all)?

I am not sure I am following how regular CONNECT can be not interoperable? I can definitely see arguments that it doesn't follow the RFC - but the issue here is we are doing HTTP2 on downstream and upstream.
From a downstream client perspective, they send the CONNECT and their TCP payload eventually makes it to where they requests; whether the intermediate steps are regular CONNECT or extended CONNECT or plain TCP or FooBarProtocol is invisible to them. From the upstream server perspective, they just receive a standard CONNECT request - they don't know/care that its the first hop or Nth hop this TCP payload has traversed.

whether the intermediate steps are regular CONNECT or extended CONNECT or plain TCP or FooBarProtocol is invisible to them.

So why exactly do you want to replace extended CONNECT with :protocol=bytestream in those intermediate steps with something that's even less standardized (or purely wrong from RFC point of view)?

So why exactly do you want to replace extended CONNECT with :protocol=bytestream in those intermediate steps with something that's even less standardized (or purely wrong from RFC point of view)?

A few reasons...

I don't agree with your interpretation of the RFC; IMO its perfectly legal to do what we are expecting.
If its not, it seems a much more straightforward path forward would be to amend the spec to change the wording to allow this, rather than invent a new protocol which would need support propagated everywhere. AFAIK there is no technical concerns with using standard CONNECT in this way other than the RFC language may say its wrong?
We still need regular CONNECT for regular CONNECT use cases where we are not doing multi-hops.
If its not meeting the spec exactly, its a violation that is 100% invisible to both upstream and downstream (https://github.com/envoyproxy/envoy/issues/20378#issuecomment-1139782620).

Our requirements are to use CONNECT for each hop and to interoperate with non-Envoy clients/servers (Java, Go, etc). These other clients do support :protocol=bytestream, because its not a standard, but do support regular CONNECT (because it is a standard, and even if our usage is 'wrong', it is invisible to the clients). Our options seem to be to use regular CONNECT or wait many years for a new protocol to be approved and supported added to clients we care about?

I don't agree with your interpretation of the RFC; IMO its perfectly legal to do what we are expecting.

It's not. Can you point me to a single widely used software that does something else than raw TCP for regular CONNECT?

If its not, it seems a much more straightforward path forward would be to amend the spec to change the wording to allow this, rather than invent a new protocol which would need support propagated everywhere. AFAIK there is no technical concerns with using standard CONNECT in this way other than the RFC language may say its wrong?

I can guarantee you that it would not be easier, and considering that the core HTTP RFCs just went through a multi-year rewrite, I don't see amending regular CONNECT as a valid option. Also, adding bytestream to the extended CONNECT method would be pretty trivial as far as writting RFCs goes.

We still need regular CONNECT for regular CONNECT use cases where we are not doing multi-hops.

Agreed. But adding regular CONNECT in addition to extended CONNECT is not what this bug or @alyssawilk's PR (https://github.com/envoyproxy/envoy/pull/21440) is doing. Both are about replacing extended CONNECT with regular CONNECT.

If its not meeting the spec exactly, its a violation that is 100% invisible to both upstream and downstream (TcpProxy improperly sets :protocol=bytestream for HTTP2 #20378 (comment)).

If we don't care about true interoperability, and only what's visible at the edges, then again, why is it a problem that Envoy uses extended CONNECT with :protocol=bytestream that's not fully standardized inside the service mesh?

Our requirements are to use CONNECT for each hop and to interoperate with non-Envoy clients/servers (Java, Go, etc). These other clients do support :protocol=bytestream, because its not a standard, but do support regular CONNECT (because it is a standard, and even if our usage is 'wrong', it is invisible to the clients). Our options seem to be to use regular CONNECT or wait many years for a new protocol to be approved and supported added to clients we care about?

If we're only talking about client/servers, then why are you even using CONNECT and not raw TCP?

Agreed. But adding regular CONNECT in addition to extended CONNECT is not what this bug or @alyssawilk's PR (https://github.com/envoyproxy/envoy/pull/21440) is doing. Both are about replacing extended CONNECT with regular CONNECT.

I am perfectly fine with supporting both with some flag.

If we don't care about true interoperability, and only what's visible at the edges, then again, why is it a problem that Envoy uses extended CONNECT with :protocol=bytestream that's not fully standardized inside the service mesh?

Say we have C -> P1 -> P2 -> P3 -> P4 -> S. At each hop, proxy can chose to send CONNECT or raw TCP. Our Envoy hops would send CONNECT in most cases, but non-envoy hops are not required to if they refuse to send CONNECT requests in response to downstream CONNECT requests. Each proxy is 100% independent - they can recieve TCP or CONNECT and send TCP or CONNECT - they don't care what other hops do.

If we're only talking about client/servers, then why are you even using CONNECT and not raw TCP?

We have more than just Envoy's in our mesh, we want to support arbitrary non-Envoy components of the mesh which can use our protocol.

We have more than just Envoy's in our mesh, we want to support arbitrary non-Envoy components of the mesh which can use our protocol.

How exactly is invalid usage of regular CONNECT better than proper usage of the extended CONNECT with not-standardized :protocol=bytestream for "your protocol" if you want to be interoperable?

I think we're going in circles

Yep, I think so. Probably best to let @DavidSchinazi weigh in - I think we have both expressed our opinions here.

Can you point me to a single widely used software that does something else than raw TCP for regular CONNECT?

global
 log stdout format raw local0
 log stdout format raw local1 notice
 daemon
 maxconn 256

defaults
 mode http
 timeout connect 5000ms
 timeout client 50000ms
 timeout server 50000ms

frontend proxy_in
 bind <IP_ADDRESS>:8888
 option http_proxy
 use_backend proxies_out

backend proxies_out
 mode http
 option forwardfor
 #option http_proxy
 server ip-1 <IP_ADDRESS>:15008 proto h2

HaProxy config. I then have another proxy on <IP_ADDRESS>:15008 (Go)
$ curl https://<IP_ADDRESS>:443/get --proxy localhost:8888 -k
{
  "url": "https://<IP_ADDRESS>/get"
}

So HAProxy is accepting a CONNECT request and sending a CONNECT request in response; this is what we want Envoy to do.

any workaround to apply?
the websocket Request Envoy send to a golang upstream http server always be rejected now with below:
"2022/05/31 21:18:40 http2: invalid pseudo headers: invalid pseudo-header ":protocol""

Sorry for the delay, I was on vacation last week. My apologies, but @PiotrSikora your understanding of CONNECT is incorrect. Here is the relevant text from the latest spec:

CONNECT is intended for use in requests to a proxy.  The recipient
can establish a tunnel either by directly connecting to the server
identified by the request target or, if configured to use another
proxy, by forwarding the CONNECT request to the next inbound proxy.
An origin server MAY accept a CONNECT request, but most origin
servers do not implement CONNECT.

The only correct and standardized way to tunnel TCP in HTTP is regular CONNECT. The is no Extended CONNECT :protocol that is defined for proxying TCP.

Or from a different perspective: "extended CONNECT" extends the normal
CONNECT, which is intended for proxying HTTPS/TCP
with extra functionality, like WS or UDP. It is not deprecating or
replacing the original CONNECT, just extends it.
On Tue, May 31, 2022 at 8:21 AM David Schinazi @.***>
wrote:

Sorry for the delay, I was on vacation last week. My apologies, but
@PiotrSikora https://github.com/PiotrSikora your understanding of
CONNECT is incorrect. Here is the relevant text from the latest spec
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-19#section-9.3.6
:
CONNECT is intended for use in requests to a proxy. The recipient
can establish a tunnel either by directly connecting to the server
identified by the request target or, if configured to use another
proxy, by forwarding the CONNECT request to the next inbound proxy.
An origin server MAY accept a CONNECT request, but most origin
servers do not implement CONNECT.
The only correct and standardized way to tunnel TCP in HTTP is regular
CONNECT. The is no Extended CONNECT :protocol that is defined for
proxying TCP.
—
Reply to this email directly, view it on GitHub
https://github.com/envoyproxy/envoy/issues/20378#issuecomment-1142277475,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAUR2VOSQPLLUKH2MKAEODVMYU5ZANCNFSM5Q42HXRA
.
You are receiving this because you commented.Message ID:
@.***>

any workaround to apply?
the websocket Request Envoy send to a golang upstream http server always be rejected now with below:
"2022/05/31 21:18:40 http2: invalid pseudo headers: invalid pseudo-header ":protocol""

This is specifically about non-websocket CONNECT usage. For websockets, Envoy is correct - :protocol must be used for HTTP2 WS. Go doesn't support this, so you should use HTTP1.

any workaround to apply?
the websocket Request Envoy send to a golang upstream http server always be rejected now with below:
"2022/05/31 21:18:40 http2: invalid pseudo headers: invalid pseudo-header ":protocol""

This is specifically about non-websocket CONNECT usage. For websockets, Envoy is correct - :protocol must be used for HTTP2 WS. Go doesn't support this, so you should use HTTP1.

Thanks Howard! very clear now.

RFC 7540 obseleted by 9113. CONNECT now covered in Section 8.5 https://datatracker.ietf.org/doc/html/rfc9113#section-8.5

@moderation RFC9113 still refers to "TCP streams", so it doesn't clarify things. The draft RFC that David mentioned is an updated HTTP semantics which is decoupled from the underlying transport. I think the concern is that this new HTTP semantics may not be universally supported, but same can be said about Extended CONNECT.

https://github.com/envoyproxy/envoy/pull/21613 thanks!


unrecognized response format: nil

Playing around with a simple example yields this error:
Uncaught Error: ["unrecognized response format: " nil]

ajax$core$throw_error
ajax$core$get_response_forma
ajax$core$normalize_request
...

I strongly suspect that cljs-ajax.core/ajax-request needs a :response-format key as seen in the example. Looking at the relevant lines in core.cljc it seems that there is no default response-format onto which it could fall back; it therefore always throws an error when not response-format is provided.
Possible fixes could be:
a) Providing the key in the map passed to :http-xhrio. However, my Clojure-Fu is not yet good enough to think of a way without clumsily including cljs.ajax.core in my re-frame handlers to access the various response-format-types..
b) Set some sort of default format and add it to the map.
Hope that helps! If you need anything further, let me know!

Hey, I've added specs and docs here to catch this, and opened #4 to discuss default response formats.


File Count and Quota amount used are not showing

Expected behavior
On  https://tigerdata-staging.princeton.edu/projects/34184/contents the file count and Quota amount used are not showing.  Amount of Quota is showing.
The asset was created by Chuck with the script below (or something similar).

Additionally the file count should be showing, but is not

Looks like we are expecting ther to be a size accumulator, but we should be able to get the size out of the quota.  And Chuck is not creating a size accumulator.

Turns out the user had no access to the accumulators.  But it did surface that we have two numbers that currently exist in the system for Storage used, the active data (Current files) and residual data (Old versions, items that are soft deleted, ect.)
We want to show the user both numbers inthe format Storage Usage   30 MB / 10 GB  active data: 5.29 MB residual data: 24.71 MB
This means the page will change from showing only active data to showing quota usage (active & residual from the quota), active data (from the size accumulator), and residual data (quota - size accululator)
See slack conversation


Problem on href in each slide

HELP!
Can't get it work.. Only the last slide href is clickable. I've tried changing 'pointer-events' state but still not work.
Please check this link
http://www.imaginali.com/slide-test/

I don't make any changes in pointer-events and the first link i put are over all of links. This bug occurs when slider is set to autoplay! When you dont have autoplay all goes perfectly because you are in /#item, when its auto play, just first or sometimes last link work in all slides!
I have the following code :

				  <?php $postsdst= new WP_query("cat=5&posts_per_page=1"); while($postsdst->have_posts()) : $postsdst->the_post();?>

<?php the_post_thumbnail();?>

<a href="<?php the_permalink();?>"><?php the_title();?>

                  <?php endwhile; wp_reset_query();?>

				  <?php $postsdst= new WP_query("cat=6&posts_per_page=1"); while($postsdst->have_posts()) : $postsdst->the_post();?>

<?php the_post_thumbnail();?>

<a href="<?php the_permalink();?>"><?php the_title();?>

                  <?php endwhile; wp_reset_query();?>

				  <?php $postsdst= new WP_query("cat=7&posts_per_page=1"); while($postsdst->have_posts()) : $postsdst->the_post();?>

<?php the_post_thumbnail();?>

<a href="<?php the_permalink();?>"><?php the_title();?>

                  <?php endwhile; wp_reset_query();?>

				  <?php $postsdst= new WP_query("cat=8&posts_per_page=1"); while($postsdst->have_posts()) : $postsdst->the_post();?>

<?php the_post_thumbnail();?>

<a href="<?php the_permalink();?>"><?php the_title();?>

                  <?php endwhile; wp_reset_query();?>

              1
              2
              3
              4

What type of changes i need to make in pointer-events? I really need solve this problem as soon as possible!
Thanks!

So you're saying that when the gallery autoplays, that the links on your slides aren't clickable?
That might be a real problem — because many properties (like pointer-events are not 'animatable'), and the way that gallery works means that the "items" are stacked over the top of each other, and the opacity is change animated (for autoplay).
tldr; If you want clickable links inside the slide items, don't use autoplay.

Cool!
Thanks for sharing, love to see where you get on this

Just studying the gallery, nice work. Given I need it to slide, would this just involve changing automation or is it way more complex...I would think, at least now, animation:autoplay sec linear infinite sec;  -- or something like that may work?

Is there an easy way to make it slide instead of fade in/out?

Is there an easy way to make it slide instead of fade in/out?

Nope.


Allow for Declarative Pipelines

I want to be able to easily create declarative pipelines.  It should be as easy as:
<EMAIL_ADDRESS>_

Pipeline.withDeclarativeSyntax(true)

def validate = new TerraformValidateStage()
def deployQa = new TerraformEnvironmentStage('qa')
def deployUat = new TerraformEnvironmentStage('uat')
def deployProd = new TerraformEnvironmentStage('prod')

validate.then(deployQa)
        .then(deployUat)
        .then(deployProd)
        .build()

If I want to customize the Declarative Pipeline, I should be able to do so.
<EMAIL_ADDRESS>_

Pipeline.withDeclarativeSyntax(true)
        .withTemplate(this.CustomPipelineTemplate)

def validate = new TerraformValidateStage()
def deployQa = new TerraformEnvironmentStage('qa')
def deployUat = new TerraformEnvironmentStage('uat')
def deployProd = new TerraformEnvironmentStage('prod')

validate.then(deployQa)
        .then(deployUat)
        .then(deployProd)
        .build()

Additional context
Add any other context or screenshots about the feature request here.

Replaced by Issue #61


rauc: update build system to use meson

Description of changes
Adjust the build system to use meson instead of autotools.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 219935 run on x86_64-linux 1

@SuperSandro2000 comments should be resolved.


find a way to make docker images distinguish between web and sidekiq so they can be scaled separately

biggest challenge: the way we test whether a wallet is running currently depends on everything being on one machine (does a PID check). this somehow needs to be able to happen across machines.

also need to separate out sidekiq queues so that sidekiq nodes can be scaled properly

sidekiq scaling unfortunately cannot be done with the current design, where the RPC is expected to be available only on localhost where the monero-wallet-rpc proc is running


Solve conflict symbols of DB::ParquetBlockInputFormat and add some benchmark of optimized parquet reading

Changelog category (leave one):

Improvement

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
Solve conflict symbols of DB::ParquetBlockInputFormat and add some benchmark of optimized parquet reading
Benchmark result shows that parquet reading string is speeded up by 2x.
---------------------------------------------------------------------------------------
Benchmark                                             Time             CPU   Iterations
---------------------------------------------------------------------------------------
BM_ParquetReadString/iterations:10                 39.9 ms         39.9 ms           10
BM_ParquetReadDate32/iterations:10                 14.3 ms         14.3 ms           10
BM_OptimizedParquetReadString/iterations:10        24.2 ms         24.2 ms           10
BM_OptimizedParquetReadDate32/iterations:200       13.4 ms         13.4 ms          200

Can one of the admins verify this patch?

Can we start reviewing now? Thanks!

test this please

retest this please


Also package as R htmlwidgets?

PeterK asks:

When you have a moment, can you take a look at the htmlwidgets (https://www.htmlwidgets.org/develop_intro.html) to assess whether it would be straightforward for us to formulate individual modules as htmlwidgets … this way we could use them directly from R as well. Just want to get a sense for how much overhead that would add to our efforts.

I think we could do it one-by-one, but I don't see it as something that is automatic.

How much binding code is necessary? A good way to judge this is to look at the source for examples in the gallery:

A D3 scatterplot: A significant proportion of the code is just the parameters list... but if our underlying JS is not stable, that would need to be kept in sync.
SGratzl has wrapped lineup

htmlwidgets by itself does not support interactions between widgets: That is provided by crosstalk, which lists a number of caveats:

HTML widgets must be specifically modified by their authors to support Crosstalk. Crosstalk cannot magically provide cross-widget interactivity with generic HTML widgets.
Crosstalk currently only works for linked brushing and filtering of views that show individual data points, not aggregate or summary views (where “observations” is defined as a single row in a data frame). For example, histograms are not supported since each bar represents multiple data points; but scatter plot points each represent a single data point, so they are supported.
Because all data must be loaded into the browser, Crosstalk is not appropriate for large data sets. (There’s no hard limit, since HTML widgets require varying amounts of CPU cycles and memory for each data point.)

htmlwidgets is about wrapping JS libraries... My sense is that we should focus on making sure what we create is in a place where it's worth wrapping. Is the JS API documented, and are the examples good? I've done a little work here, but have not gotten a sense from you that it's a higher priority than other features. The stand-alone demos have not been part of our presentation, so I have felt that they are not where effort should be invested.

@ngehlenborg or @pkharchenko : Let me know if you'd like me to follow up... I could wrap one to see how it goes, but I don't think it would really be sustainable.

I think this has been answered, but reopen if follow-up is required.

Had a conversation about how to get results out of Vitessce in an analysis scenario with someone earlier today, and the idea to send subsets of cell or gene ids to an R session via htmlwidgets was discussed. Reopening until we can clarify if this is indeed not worth pursuing at the moment.

Started here https://github.com/vitessce/vitessce-r


Install detects version

Automatically detect the db2 version and install 9.7 or post 9.7

Db2 9.7 was dropped from the log4db2 support. Thus, this is no longer necessary.


MosaicConfig Integration with Mosaic Chains

Currently, MosaicConfig class is duplicated in facilitator repo.
It should refer MosaicChain npm for MosaicConfig.
Note ⏰ 🎶
In package.json mosaic-chains npm points to a github branch.
It needs to switch to latest npm version after mosaic chains is published.
Test will pass after latest npm of mosaic chain is updated in package.json.
Fixes #97

Changed version of mosaic-chains npm to 0.1.0-alpha.2


Added print button

Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):
Fix #25
Test URLs:

Before: https://main--fonterra-fernleaf--hlxsites.hlx.page/
After: https://25-print--fonterra-fernleaf--hlxsites.hlx.page/en/stories-and-tips/5-fun-recipes-to-make-with-dairy-products

@sselvara Two small issues I noticed

The print text has underlining on hover, while it's not there on the live site
alignment issue
Franklin

@mkbansal1 removed the underline style for hover, but the space different is negligible and it is looking different as the print text is center aligned in our site as it will not look good if bottom aligned.
Original:

new:

@sselvara Two small issues I noticed

The print text has underlining on hover, while it's not there on the live site
alignment issue
Franklin


504 Gateway Timeout on conduit.productionready.io/api

The https://conduit.productionready.io/api is down!

THIS IS PRETTY URGENT, since the 504 on all api calls breaks all your frontend examples. Please, look into it asap!!!

It is running again. So far the reason for the incident is unknown.


Clean-up for some packages in haskell-modules/configuration-common.nix.

Motivation for this change
Clean-ups and more informative docs to: {haddock-library, haddock-library_1_9_0, pandoc (1.2.7), hnix, generic-lens, dhall, dhall-json, dhall-nix}
Things done

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

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

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

Other than the request for hnix below, this looks good. I'll merge this in when the hnix things have been addressed.
Thanks for taking them time to fix this sort of stuff up!

Very good honest and effective responce to contributers, thank you 8)


Attempting to change URL Slug on account setting retuns "Validation error"

All attempts made to change my URL slug has caused the message "Validation error" when I click save.  Is anyone else having problems like this?

@MrControl No, it's not common, can you give a link to your collective?

Duplicate with https://github.com/opencollective/opencollective/issues/3325


Gitlens sidebar icon differs when opening vscode with a workspace

GitLens Version: 11.1.3
Git Version: 2.29.2.windows.3

VSCode Version: 1.52.1
OS Version: Windows 10 19042.685

Steps to Reproduce:

Open vscode without opening a workspace.
Open a workspace. This should be the sidebar icon now:
Close vscode and reopen it so it loads the last workspace. The icon now looks like this:

I searched through the existing issues and could not find any related issue like this. Is this a bug or is this intended?

I'm having the exact same problem
I realized that  is the commit icon
If you drag the commit tab to the side bar, the commit icon should appear in it

The same applies to the other tabs. Each one of them has its own icon
A temporary solution to this is closing the workspace (Ctrl + K F) and reopening the repository folder

I'm having the exact same problem
I realized that  is the commit icon
If you drag the commit tab to the side bar, the commit icon should appear in it

The same applies to the other tabs. Each one of them has its own icon
A temporary solution to this is closing the workspace (Ctrl + K F) and reopening the repository folder

@mentofa123 Did you drag the views around? If so then this is somewhat expected behavior -- since as @LeonardoKojimaCMD says, each view has its own icon, so if you drag them into their own "group" on the activity bar they are unique.
In VS Code you can right-click on the activity bar icon (or the view header itself) and select Reset Location which will reset that view back to its original location. Although if you just want to switch to (or between) having all the GitLens views under the SCM activity or under a GitLens activity, you can use the GitLens: Set Views Layout and then choose the layout you want.

@mentofa123 Did you drag the views around? If so then this is somewhat expected behavior -- since as @LeonardoKojimaCMD says, each view has its own icon, so if you drag them into their own "group" on the activity bar they are unique.
In VS Code you can right-click on the activity bar icon (or the view header itself) and select Reset Location which will reset that view back to its original location. Although if you just want to switch to (or between) having all the GitLens views under the SCM activity or under a GitLens activity, you can use the GitLens: Set Views Layout and then choose the layout you want.

It's not the commit tab dragged to the sidebar. My view is the view you set with GitLens: Set Views Layout
I know that i could drag any any view to the activity bar but my problem was that the icon of the complete gitlens view changes to the commit icon after reopening vscode with the last opened workspace

It's not the commit tab dragged to the sidebar. My view is the view you set with GitLens: Set Views Layout
I know that i could drag any any view to the activity bar but my problem was that the icon of the complete gitlens view changes to the commit icon after reopening vscode with the last opened workspace

Once you set GitLens: Set Views Layout to GitLens Layout for the first time, the original Gitlens icon should appear in the side bar.
As @mentofa123 said, if you then close and reopen VSCode, it will reopen the last used workspace. In this case, the Commit icon appears instead of the Gitlens icon because it is the first tab in GitLens Layout. If you change the order of the tabs, VSCode will then reopen with the first tab icon.
A quick way to make the original Gitlens icon appear is closing the workspace (Ctrl + K F) and reopening the repository folder. Then again, this is not the ideal solution, but a temporary one.
I apologize for causing confusion earlier.

Once you set GitLens: Set Views Layout to GitLens Layout for the first time, the original Gitlens icon should appear in the side bar.
As @mentofa123 said, if you then close and reopen VSCode, it will reopen the last used workspace. In this case, the Commit icon appears instead of the Gitlens icon because it is the first tab in GitLens Layout. If you change the order of the tabs, VSCode will then reopen with the first tab icon.
A quick way to make the original Gitlens icon appear is closing the workspace (Ctrl + K F) and reopening the repository folder. Then again, this is not the ideal solution, but a temporary one.
I apologize for causing confusion earlier.

"Problem" is gone since the last update.


Port mock-service to use kuksa-client lib

Currently Mock is not very maintainable as it uses its homespun GRPC wrappers. This is a lot of code dupblication, instead it should use the well/better tested kuksa-client lib
Potential issue: It might rely on pending "discoverability" issue in the val.v1 API. In any case, I suggest we start moving as mich calls as possible over to the API now, and follow up with the rest once upstream updated kuksa-client and databroker API

Done in #88


Separate LOAD and LOADREGISTER instructions

This does not make it very RISC type instruction set. Merge them to a single LOAD. Ideas will be followed in the comments. Also rename the LOADLABEL instruction to simply LABEL.
Related issue in YamASM
#19

All LOAD instructions will be followed by an offset in the assembler. This will help the virtual machine distinguish between the stack and the registers.


Fork upgrade always does a fresh install, destroying workspace and application settings

https://github.com/microsoft/winget-pkgs/blob/14625cd566e579092da9855e9e49e02374679f8b/manifests/f/Fork/Fork/1.71.0/Fork.Fork.installer.yaml#L23

Followed repository issue instructions. #55611


⚠ Adacta-fintech.com has degraded performance

In 47393cb, Adacta-fintech.com (https://www.adacta-fintech.com) experienced degraded performance:

HTTP code: 200
Response time: 978 ms

Resolved: Adacta-fintech.com performance has improved in ab5046f.


clean up tiltfile by replacing get_username() func w/ username var

Hello @jazzdan, @dbentley,
Please review the following commits I made in branch maiamcc/username_var:
63ce7219275b12970ae7be8b1b97790471b88845 (2019-02-21 12:40:44 -0500)
clean up tiltfile by replacing get_username() func w/ username var
Code review reminders, by giving a LGTM you attest that:

Commits are adequately tested
Code is easy to understand and conforms to style guides
Incomplete code is marked with TODOs
Code is suitably instrumented with logging and metrics

bump!


Statuscode 400: Bad request

Hi,
I tested your plugin in a new VR Unity project and started up the test scene. When I try to complete my input, I get a Bad request HTTP response. I did make an auth.json file containing my private key so I'm not sure what I'm doing wrong. I also tested to make an Auth args object with the key and that also didn't work.

The weird thing is, I have also have a separate Python project where I call the OpenAI API directly, and there it manages to successfully execute a completion, so my key does not seem to be the problem.
EDIT: I tried to supply a wrong key to the request and this is seen as an unauthorized request, so my key does not seem to be the problem. After this, I tested the "complete in editor window" and this did work., so I'm not sure what the difference is between the runtime and editor version?
EDIT2: Seems to be something with the "stop" string or array object in the request. Changing this to just a string solves the bad request.
Thanks in advance

Look up his yt Vieren in his comment he said that the api has updated and you should look into the main Script where the api calls are made to fix it

Didn't know this was the case. Managed to fix it eventually but thanks for the info!

How did you fix it I didn’t found the file I have to change

Hey @Jxlle , sadly I don't have time to maintain this code atm. So much time has passed since last update that the API may have changed as mentioned above.
If you have a fix for this issue, I'd encourage you to make a PR! That way we can distribute the fix to everyone.

Hey @Jxlle , sadly I don't have time to maintain this code atm. So much time has passed since last update that the API may have changed as mentioned above.
If you have a fix for this issue, I'd encourage you to make a PR! That way we can distribute the fix to everyone.

 The fix was described in my post above but I can give more info if needed :)
@hexthedev Thanks for the reply. Maybe I'll make a PR once I have the time and made an actual fix instead of a fast hardcoded one.

Hi Jxlle, which script did you change it to just string? thanks

Hi Jxlle, could you possibly post the code snippet for the fix with the request? Not sure what you mean about the stop string or array object

@erinrrobinson No problem!
I hardcoded a stopsymbol in the "SOCompletionArgsV1.cs" file.

ah brilliant, thank you!


Client Allocation Request for: Denis

Client Allocation Questions
Core Information

Name: Denis
Website / Social Media: https://github.com/Araquiel
Region: Asia excl. Greater China
DataCap Requested: 1TiB
Addresses to be Notarized: f01163272
Notary Requested: dannyob

@Araquiel Please subscribe to notifications for this Issue to be aware of updates. Notaries may request additional information on the Issue.

Closed as duplicate of #862


api: use weak imports for plugin protobufs

Because of a side-effect import, we have the possibility of pulling in
several unnecessary packages that are used by the plugin and not at
runtime to implement protobuf structures. Setting these imports to
weak prevents this from happening, reducing the total import set,
reducing memory usage and binary size.
Signed-off-by: Stephen J Day<EMAIL_ADDRESS>

Codecov Report

Merging #1778 into master will increase coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #1778      +/-   ##
=========================================
+ Coverage   49.14%   49.2%   +0.05%
=========================================
  Files          77      77
  Lines        7705    7705
=========================================
+ Hits         3787    3791       +4
+ Misses       3275    3271       -4
  Partials      643     643

Flag
Coverage Δ

#linux
49.22% <ø> (ø)
:arrow_up:

#windows
45.01% <ø> (+0.06%)
:arrow_up:

Impacted Files
Coverage Δ

metadata/content.go
32% <0%> (+0.94%)
:arrow_up:

Continue to review full report at Codecov.

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

LGTM


OGRID: Add -i option to load image into ogrid

This adds the ability to do some... interesting.. things

Nice! Time to do "interesting" things.