PaginatedDataTable horizontal scroll bar not showing

Steps to reproduce
run the code below on a desktop (I tried web from a pc and windows) and make the window small to make it horizontally scrollable
hold shift + scroll wheel (to scroll horizontally)
and notice that the horizontal bar doesn't appear even tho thumbVisibility: MaterialStateProperty.all<bool>(true) is set in the theme. On the other hand, the vertical bar is shown correctly.
In an older app I built this wasn't an issue (don't the version of flutter used for it since I don't have the source code).
So now it is impossible to scroll on a PC without using shift+scroll wheel or making it dragable. But nobody drags to scroll on a PC so this is creates a bad experience.
Expected results
Visible horizontal scrollbar
Actual results
Horizontal scrollbar never shows
Code sample
Code sample
import 'package:flutter/material.dart';

/// Flutter code sample for [PaginatedDataTable].

class MyDataSource extends DataTableSource {
  @override
  int get rowCount => 3;

  @override
  DataRow? getRow(int index) {
    switch (index) {
      case 0:
        return const DataRow(
          cells: <DataCell>[
            DataCell(Text('Janine')),
            DataCell(Text('Janine')),
            DataCell(Text('Janine')),
            DataCell(Text('Sarah')),
            DataCell(Text('19')),
            DataCell(Text('Student')),
          ],
        );
      case 1:
        return const DataRow(
          cells: <DataCell>[
            DataCell(Text('Janine')),
            DataCell(Text('Janine')),
            DataCell(Text('Janine')),
            DataCell(Text('Janine')),
            DataCell(Text('43')),
            DataCell(Text('Professor')),
          ],
        );
      case 2:
        return const DataRow(
          cells: <DataCell>[
            DataCell(Text('Janine')),
            DataCell(Text('William')),
            DataCell(Text('William')),
            DataCell(Text('William')),
            DataCell(Text('27')),
            DataCell(Text('Associate Professor')),
          ],
        );
      default:
        return null;
    }
  }

  @override
  bool get isRowCountApproximate => false;

  @override
  int get selectedRowCount => 0;
}

final DataTableSource dataSource = MyDataSource();

void main() => runApp(const DataTableExampleApp());

class DataTableExampleApp extends StatelessWidget {
  const DataTableExampleApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData(
        scrollbarTheme: ScrollbarThemeData(
          thumbColor: MaterialStatePropertyAll(Colors.red),
          thumbVisibility: MaterialStateProperty.all<bool>(true),
        ),
      ),
      home: SingleChildScrollView(
        padding: EdgeInsets.all(12.0),
        child: DataTableExample(),
      ),
    );
  }
}

class DataTableExample extends StatelessWidget {
  const DataTableExample({super.key});

  @override
  Widget build(BuildContext context) {
    return PaginatedDataTable(
      columns: const <DataColumn>[
        DataColumn(
          label: Text('Name1'),
        ),
        DataColumn(
          label: Text('Name1'),
        ),
        DataColumn(
          label: Text('Name1'),
        ),
        DataColumn(
          label: Text('Name2'),
        ),
        DataColumn(
          label: Text('Age'),
        ),
        DataColumn(
          label: Text('Role'),
        ),
      ],
      source: dataSource,
    );
  }
}

Screenshots or Video
No response
Logs
No response
Flutter Doctor output
Doctor output
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 3.19.4, on Microsoft Windows [Version 10.0.22631.3374], locale el-GR)
[√] Windows Version (Installed version of Windows is version 10 or higher)
[√] Android toolchain - develop for Android devices (Android SDK version 34.0.0-rc2)
[√] Chrome - develop for the web
[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.6.4)
[√] Android Studio (version 2023.2)
[√] Connected device (3 available)
[√] Network resources

• No issues found!

Thanks for the report. I also can reproduce the issue. Tried wrapping a Scrollbar for SingleChildScrollView but it still does not appear.

flutter doctor -v (stable and master)
[✓] Flutter (Channel stable, 3.19.5, on macOS 14.1 23B74 darwin-x64, locale en-VN)
    • Flutter version 3.19.5 on channel stable at /Users/huynq/Documents/GitHub/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 300451adae (25 hours ago), 2024-03-27 21:54:07 -0500
    • Engine revision e76c956498
    • Dart version 3.3.3
    • DevTools version 2.31.1

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/huynq/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = /Users/huynq/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.9+0-17.0.9b1087.7-11185874)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.2)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15C500b
    • CocoaPods version 1.15.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2023.2)
    • 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
    • android-studio-dir = /Applications/Android Studio.app/
    • Java version OpenJDK Runtime Environment (build 17.0.9+0-17.0.9b1087.7-11185874)

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

[✓] Connected device (3 available)
    • Pixel 7 (mobile) • 2B171FDH20084L • android-arm64  • Android 14 (API 34)
    • macOS (desktop)  • macos          • darwin-x64     • macOS 14.1 23B74 darwin-x64
    • Chrome (web)     • chrome         • web-javascript • Google Chrome 123.0.6312.86

[✓] Network resources
    • All expected network resources are available.

• No issues found!

[!] Flutter (Channel master, 3.22.0-1.0.pre.37, on macOS 14.1 23B74 darwin-x64, locale en-VN)
    • Flutter version 3.22.0-1.0.pre.37 on channel master at /Users/huynq/Documents/GitHub/flutter_master
    ! Warning: `flutter` on your path resolves to /Users/huynq/Documents/GitHub/flutter/bin/flutter, which is not inside your current Flutter SDK checkout at /Users/huynq/Documents/GitHub/flutter_master. Consider adding /Users/huynq/Documents/GitHub/flutter_master/bin to the front of your path.
    ! Warning: `dart` on your path resolves to /Users/huynq/Documents/GitHub/flutter/bin/dart, which is not inside your current Flutter SDK checkout at /Users/huynq/Documents/GitHub/flutter_master. Consider adding /Users/huynq/Documents/GitHub/flutter_master/bin to the front of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision fd8561a917 (6 hours ago), 2024-03-31 17:12:24 -0400
    • Engine revision 4f6b832c8e
    • Dart version 3.5.0 (build 3.5.0-5.0.dev)
    • DevTools version 2.34.1
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/huynq/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = /Users/huynq/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.9+0-17.0.9b1087.7-11185874)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.2)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15C500b
    • CocoaPods version 1.15.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2023.2)
    • 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
    • android-studio-dir = /Applications/Android Studio.app/
    • Java version OpenJDK Runtime Environment (build 17.0.9+0-17.0.9b1087.7-11185874)

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

[✓] Connected device (3 available)
    • iPad (mobile)   • 00008103-000A1464346A201E • ios            • iOS 17.2 21C62
    • macOS (desktop) • macos                     • darwin-x64     • macOS 14.1 23B74 darwin-x64
    • Chrome (web)    • chrome                    • web-javascript • Google Chrome 123.0.6312.87

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 1 category.

This is working as expected. The MaterialScrollBehavior does not apply scrollbars to horizontal scroll views.
https://github.com/flutter/flutter/blob/5705881f6314eba62daafa2ef6af4cdfe1f015a3/packages/flutter/lib/src/material/app.dart#L836

Tried wrapping a Scrollbar for SingleChildScrollView but it still does not appear.

This would not work because the scrollbar would then respond to the SingleChildScrollView, not the PaginatedDataTable, since it is driven by the scroll notifications of the nearest scroll view. Wrapping the table in a scrollbar, or providing the same scroll controller to both the table and the scrollbar to explicitly link them would lead to the desired result. Alternatively, you could override the buildScrollbar method of MaterialScrollBehavior.

Ah yes, thanks for clarifying this, Kate. Both solutions are working like a charm :)
@BananaMasterz Below is the achieved result after applying buildScrollbar solution:

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

/// Flutter code sample for [PaginatedDataTable].

class MyDataSource extends DataTableSource {
  @override
  int get rowCount => 3;

  @override
  DataRow? getRow(int index) {
    switch (index) {
      case 0:
        return const DataRow(
          cells: <DataCell>[
            DataCell(Text('Janine')),
            DataCell(Text('Janine')),
            DataCell(Text('Janine')),
            DataCell(Text('Sarah')),
            DataCell(Text('19')),
            DataCell(Text('Student')),
          ],
        );
      case 1:
        return const DataRow(
          cells: <DataCell>[
            DataCell(Text('Janine')),
            DataCell(Text('Janine')),
            DataCell(Text('Janine')),
            DataCell(Text('Janine')),
            DataCell(Text('43')),
            DataCell(Text('Professor')),
          ],
        );
      case 2:
        return const DataRow(
          cells: <DataCell>[
            DataCell(Text('Janine')),
            DataCell(Text('William')),
            DataCell(Text('William')),
            DataCell(Text('William')),
            DataCell(Text('27')),
            DataCell(Text('Associate Professor')),
          ],
        );
      default:
        return null;
    }
  }

  @override
  bool get isRowCountApproximate => false;

  @override
  int get selectedRowCount => 0;
}

final DataTableSource dataSource = MyDataSource();

void main() => runApp(const DataTableExampleApp());

class DataTableExampleApp extends StatefulWidget {
  const DataTableExampleApp({super.key});

  @override
  State<DataTableExampleApp> createState() => _DataTableExampleAppState();
}

class _DataTableExampleAppState extends State<DataTableExampleApp> {

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData(
        scrollbarTheme: ScrollbarThemeData(
          thumbColor: MaterialStatePropertyAll(Colors.red),
          thumbVisibility: MaterialStateProperty.all<bool>(true),
        ),
      ),
      scrollBehavior: MyMaterialScrollBehavior(),
      home: SingleChildScrollView(
        padding: EdgeInsets.all(12.0),
        child: DataTableExample(),
      ),
    );
  }
}

class MyMaterialScrollBehavior extends MaterialScrollBehavior {
  @override
  Widget buildScrollbar(BuildContext context, Widget child, ScrollableDetails details) {
    return Scrollbar(
      controller: details.controller,
      child: child,
    );
  }
}

class DataTableExample extends StatelessWidget {
  DataTableExample({super.key});

  @override
  Widget build(BuildContext context) {
    return PaginatedDataTable(
      columns: const <DataColumn>[
        DataColumn(
          label: Text('Name1'),
        ),
        DataColumn(
          label: Text('Name1'),
        ),
        DataColumn(
          label: Text('Name1'),
        ),
        DataColumn(
          label: Text('Name2'),
        ),
        DataColumn(
          label: Text('Age'),
        ),
        DataColumn(
          label: Text('Role'),
        ),
      ],
      source: dataSource,
    );
  }
}


Fixed /validate endpoint's request body format

That's the same issue I noticed. Does it also get repaired if you just delete the - before sv and adjust the indentation?

Yes that is correct.


Change unknown/private repo handling in [GitlabPipeline]

Resolves #5282 via option 3 described in that thread

Messages

:book:
:sparkles: Thanks for your contribution to Shields, @calebcartwright!

  Generated by :no_entry_sign: dangerJS against c4817199f83f542ec4312d416078c54a5ee2fde9

Closing in favor of #5538


TypeScript type declarations

Hi,
I have just been noticed that you are adding TypeScript definitions to Mithril once again.
I should have probably told you, but I also wrote some TypeScript definitions for Mithril, and all of it has been part of a PR to DefinitelyTyped for some weeks now. See: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/14513
The reason I bring this up is that the mithril.d.ts that is in the repo currently, does not pass the tests I have in the PR, and I could not easily modify the tests to make them pass. This makes me think that the type defs in the Mithril repo are inferior to mine. I do not claim mine is perfect, but I think it is further along the way.
I have put a fair amount of research & testing into my type defs. Here are some of the advantages:

Can use mithril without an import statement.
Component state, vnode.state, and this are all the same and refactoring just works.
Component attrs, vnode.attrs are the same, and m(Component, Attrs) enforces type safety.
It is not a complete rewrite, but an evolution of the Mithril 0.2 type defs' latest version from the repo.
It is documented with tests. Code has been taken directly from http://mithril.js.org/ code examples.
I have migrated a fairly large Mithril 0.2 project to 1.0 using these type defs, and it works fine.

I would like to ask you to evaluate my Mithril type defs, and consider using them in place of what you've currently got.
Actually, I think that type definitions belong on DefinitelyTyped, and not in the Mithril repo. The reason I think so is that it's easier to decouple type defs from the project, and everyone gets to install and use what they prefer. Also, @lhorie made the point once that he does not work with TypeScript, so he'd prefer the community to maintain the defs. If this is still the case, then it may be an option to support my PR to DefinitelyTyped, and remove mithril.d.ts from the Mithril repo.
Can we have a conversation about all this before you go live with the new mithril.d.ts?
@lhorie @spacejack @pixelmike and other project members can you please comment?

My tests can be found here:
https://github.com/andraaspar/DefinitelyTyped/blob/master/mithril/mithril-tests.ts

A PR to the definition file here would be strongly preferred, although I'd consult with @spacejack over this (he's more into this than I am).

That is acceptable to me – although it may take a while to process. Would you wait with the release until it's done? Or more like, how long can you wait?
To make it simpler to discuss & demonstrate issues, I'd like to also add the tests file mentioned above to the PR. Where would be a good location to place it? Name suggestions?

@lhorie is who controls releases, not me.

@andraaspar

To make it simpler to discuss & demonstrate issues, I'd like to also add the tests file mentioned above to the PR. Where would be a good location to place it? Name suggestions?

I'd defer to @lhorie on that, since I really don't know where that would go.

@andraaspar I agree we should join forces...
I'm a TypeScript n00b, and I don't have the perspective to judge wether it is better to have the typings here or at DefinitelyTyped. An advantage of having them here is that we can better coordinate the typings developments (and avoid the current situation). There are other typescript users that follow Mithril.
If the typings were to stay here, the tests would probably go in tests/test-typings.js (for the ospec-based JS file that loads the typescript compiler then the TS sample) and tests/test-typings.ts for your tests (or a more descriptive name if you can think of one).
At a glance I see a few issues with your typings:

It looks like your typings don't support class and closure components (or I've missed them)

You have the stream<T> setter return void, it should return T

We're already using @spacejack's typings in projects, and your typings are incompatible (Component<Attrs, State> vs. Component<State, Attrs>, maybe other points; full disclosure, I'm currently working under @spacejack's supervision on a Mitrhril + TS-based app)

@pygy Thank you for testing it.

It looks like your typings don't support class and closure components (or I've missed them)

export declare namespace Foo {
	interface State {}
	interface Attrs {}
}
type Vnode = Mithril.Vnode<Foo.State, Foo.Attrs>

export class Foo implements Mithril.ComponentMethods<Foo.State, Foo.Attrs> {
	// oninit(v: Vnode) { }
	// onbeforeupdate(v: Vnode, old: Vnode) { }
	view(v: Vnode): Mithril.Children {
		return m('div')
	}
	// oncreate(v: Vnode) { }
	// onupdate(v: Vnode) { }
	// onbeforeremove(v: Vnode) { }
	// onremove(v: Vnode) { }
}

This is how you'd do it. Although it is currently discouraged by the docs, and to tell you the truth, I've migrated to a plain object based solution, which is a lot easier to type (State == const Foo == this == v.state) and is closer to the docs:
export declare namespace Foo {
	interface State {
		bar: string // Same
	}
	interface Attrs {}
}
type Vnode = Mithril.Vnode<Foo.State, Foo.Attrs>

export const Foo: Mithril.Component<Foo.State, Foo.Attrs> = {
	bar: '', // Same

	// oninit(v) { },
	// onbeforeupdate(v, old) { },
	view(v) {
		v.state.bar // Same
		this.bar // Same
		return m('div')
	},
	// oncreate(v) { },
	// onupdate(v) { },
	// onbeforeremove(v) { },
	// onremove(v) { }
}

Refactoring bar above means it gets renamed in all four cases.
This is only achievable by declaring Mithril.Component as a type. Mithril.ComponentMethods is the interface that declares the view method and inherits the lifecycle methods.
type Component<State, Attrs> = ComponentMethods<State, Attrs> & State;

You have the stream setter return void, it should return T

Thanks for pointing out! I should fix that for the PR.

We're already using @spacejack's typings in projects, and your typings are incompatible (Component<Attrs, State> vs. Component<State, Attrs>, maybe other points; full disclosure, I'm currently working under @spacejack's supervision on a Mitrhril + TS-based app)

That is why I'd need some time to refactor my stuff to make it more compatible with yours. I'm hoping to meet you at some middle ground where it's not too much work for neither you people nor us.
With components written like the above, it would be fairly easy on my side to swap the two generic parameters.
On the other hand, it'd be great if you could provide a piece of sample code that demonstrates your use.

@andraaspar My repo has tests, can you try your types there and see if they all pass? I'm going to be tied up for most of the day so I won't be able to look at it right away.

Just took a quick look - ignoring the component style incompatibilities for the moment, you are missing types for parts of the API, and in general are not using types as much as my definitions do, so the user does not benefit from inference as much (request, route.) Some types are incorrect or incomplete (mount, render, Children, stream, etc.) Some stream functions are missing.
I'll look at component style differences later.

Another problem I notice - your own tests fail if you turn on TypeScript's strictNullChecks. I think most people have that flag enabled on their projects and it looks like it would be very inconvenient to use your types with this flag.

@spacejack Thanks for your feedback. I have resolved all of those issues. I am tidying up to ensure a minimal impact on merge, and once I'm happy, I'll create a PR that you can offer further feedback on.

Your Component type is declared like this:
type Component<State, Attrs> = ComponentMethods<State, Attrs> & State;

I debated using that definition when I wrote mine, however it precludes component definitions that use oninit to add state properties (i.e., a component style that does not use this.) I felt it was better to allow a user to declare their own shorthand type Component = Mithril.Component<Attrs,State> & State if they predominantly use that style.
Otherwise, the main incompatibility is the ordering of State and Attrs. I chose Attrs first because most often components are stateless, so it seemed the more common case. A number of people have starred my types and have been using them and we've been directing people to them in issues and on gitter here, so I wouldn't want to change that ordering at this point.
Forgive me for asking, but are your types not a forked version from mine a while back? It would've been nice to get some feedback and collaborate earlier on.

@spacejack No, it's completely from scratch, later adapted to fit Mithril 0.2 for merge, and now being adapted to fit yours for merge.
Don't worry, my intent is to not break any of your existing code, as much as possible. Still, the exact part you're mentioning is a must have for proper type safety in the classic component examples on the site.
How does that Component declaration preclude oninit initialization? I think it should work just fine:
export const Foo: Mithril.Component<{}, {
		bar?: string
		baz?: number
	}> = {
	oninit(v) {
		this.bar = ''
		this.baz = 5
	},
	view(v) {
		return m('div')
	}
}

For a typed, stateful component, you'd write:
interface State {bar: string}
const Foo: Mithril.Component<{},State> & State = {
    bar: '',
    oninit() {
        this.bar = 'A'
    },
    view() {
        return m('p', this.bar)
    }
}

Stateful or "fat" components are the exception not the norm, so I feel the additional type annotation work is ok in this case since your component will likely be more complex anyway.
I'll agree that making state properties optional would allow that style, however then you'll be forced to add null checks whenever you use those properties. Deferred initialization is problematic in general with non-nullables (the typescript compiler currently cannot check that non-nullables are initialized in class constructors.) So I felt that not making components intersection types by default followed the spirit of "class-like" convenience vs correctness.
The most frequent usage of state I've seen in the community is by vnode.state rather than this or by properties on the component object. I thought it best to prioritize design for that.
And as I mentioned, it's easy to add your own type: type Component<A,S> = Mithril.Component<A,S> & S if you prefer.
Maybe we could add another definition with that type for convenience?
Apologies, I thought I remembered your username from  a list of people who had starred/forked my repo.

OK, how about Mithril.Comp? Then legacy code will not break, and if you know what you're doing, you can type the extra 5 letters.
I've personally found TypeScript's explicit null & undefined checks to be excessive, but I guess I'm just not hardcore enough.

Removed pull request in favour of https://github.com/lhorie/mithril.js/pull/1696.


ERROR Failed to read file: ".tmp/extracted/avb_pkmd.bin"

On Fedora, not sure I put my keys in the right place, probably not relevant to this error though?
Building bramble stable.
10.384s  INFO Successfully extracted OTA
 10.384s  INFO Verifying partition hashes
 11.584s  INFO Checking ramdisk's otacerts.zip
 11.729s  INFO Verifying AVB signatures
 11.926s ERROR Failed to read file: ".tmp/extracted/avb_pkmd.bin"

Caused by:
    No such file or directory (os error 2)
Traceback (most recent call last):
  File "/home/user/PixeneOS/.tmp/my-avbroot-setup/patch.py", line 1009, in <module>
    main()
  File "/home/user/PixeneOS/.tmp/my-avbroot-setup/patch.py", line 1000, in main
    run(args, Path(temp_dir))
  File "/home/user/PixeneOS/.tmp/my-avbroot-setup/patch.py", line 882, in run
    verify_ota(args.input, args.verify_public_key_avb, args.verify_cert_ota)
  File "/home/user/PixeneOS/.tmp/my-avbroot-setup/patch.py", line 40, in verify_ota
    subprocess.check_call([
  File "/usr/lib64/python3.12/subprocess.py", line 413, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['avbroot', 'ota', 'verify', '--input', PosixPath('.tmp/bramble-ota_update-2024080600.zip'), '--public-key-avb', PosixPath('.tmp/extracted/avb_pkmd.bin'), '--cert-ota', PosixPath('.tmp/extracted/ota/META-INF/com/android/otacert')]' returned non-zero exit status 1.
Cleaning up...
Cleanup complete.
Cleaning up...
Cleanup complete.

Ah, ok, basically '--public-key-avb', PosixPath('.tmp/extracted/avb_pkmd.bin'), should be looking in .tmp/extracted/extracts/avb_pkmd.bin.  Not sure the best way to patch that but I might symlink to make it work for now.


Scripting: Can I overlap DuslShockStates executions?

Is there a way to make these function to execute simultaneously? I need to make a character run. Is there another way to do this?
Press(new DualShockState() { LY = 0x0 }, 4000);
Press(new DualShockState() { Cross = true }, 4000)

Hey there, I know you asked this a while ago. I'm not Komefai sadly, but trying to help those who find this project. The following will do what you're looking for:
Press(new DualShockState() { LY= 0x0, Cross = true }, 4000)

Hey there, I know you asked this a while ago. I'm not Komefai sadly, but trying to help those who find this project. The following will do what you're looking for:
Press(new DualShockState() { LY= 0x0, Cross = true }, 4000)


Stencila R package fails to load due to missing libicui18n.so.55

On the current nix branch, the Stencila R package fails to load due to missing libicui18n.so.55.
[nix-shell:~/stencila/source/images/core]$ R

R version 3.4.1 (2017-06-30) -- "Single Candle"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library(stencila)
Error: package or namespace load failed for ‘stencila’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/home/nokome/R/x86_64-pc-linux-gnu-library/3.4/stringi/libs/stringi.so':
  libicui18n.so.55: cannot open shared object file: No such file or directory

My initial attempt to fix this by adding icu to stencila-r buildInputs in core/default.nix failed.

Fix. Thanks!


fix fix that be may core dump when the predicates are all false

Proposed changes
Issue Number: close #15334
Problem summary
Describe your changes.
Checklist(Required)

Does it affect the original behavior:

[ ] Yes
[x] No
[ ] I don't know

Has unit tests been added:

[ ] Yes
[x] No
[ ] No Need

Has document been added or modified:

[ ] Yes
[ ] No
[x] No Need

Does it need to update dependencies:

[ ] Yes
[x] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[x] No

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

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 35.19 seconds
load time: 637 seconds
storage size:<PHONE_NUMBER>0 Bytes
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20221223154806_clickbench_pr_68132.html


Mobile menu toggle problem solved

Hi,
I'm not sure about the solution. I'm a bigginer in frontend area.
I'm buildinng worpress site on your great FoundationPress framework and I found some problem with toggling navi menu while resizing from desktop to mobile. Mobile menu button didn't work at all.
So digged thought the code and have only

moved php function displaying mobile navigation generating ... element
out of the  element (it was inside)
... and it works fine.

Refgards
Christopher

@kristoferek both of the mobile menus (top bar and off-canvas) are working for me on the latest version of FoundationPress. Are you on the latest version?

OK, than sorry for bothering you :-)
It didn't work for me, so I solved the issue :-)
Dokument bez tytułu
W dniu 2017-06-02 o 15:34, Eric Rihlmann pisze:

@kristoferek https://github.com/kristoferek both of the mobile menus
(top bar and off-canvas) are working for me on the latest version of
FoundationPress. Are you on the latest version?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/olefredrik/FoundationPress/pull/996#issuecomment-305788577,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AXkpHdmaojnEjLscnu6KF3UX413grcBjks5sAA9sgaJpZM4NtIw2.

No bother, but did you experience this on the latest version of FoundationPress? It would be nice to know if it's broken for other users.

That's right. Take a look at header.php
Krzysztof Michał Nowak
www.excellentcoach.eu

wysłano z telefonu -

02.06.2017 21:43 "Eric Rihlmann"<EMAIL_ADDRESS>napisał(a):
No bother, but did you experience this on the latest version of
FoundationPress? It would be nice to know if it's broken for other users.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/olefredrik/FoundationPress/pull/996#issuecomment-305891269,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AXkpHRR-9eKAfH23aPbG1Cq0Zskt7rJFks5sAGXfgaJpZM4NtIw2
.


Pushing a single tag does not work

The tag dashboard has 2 commands [p] push to remote and [P] push all tags to remote.
I assume the first command is intended to push a specified tag; however invoking it seems to perform git push origin and this fails (unless we had the tag checked out).
"Branch interface" has a similar behavior, but I think it uses the branch from the line the cursor is currently on, and "Tag interface" should attempt to do the same.

Fixed, thanks for the report!


XMonad/Layout/Groups/Helpers.hs: drop broken ImpredicativeTypes extension (fixes #123)

ImpredicativeTypes is practically unsupported extension
on it's way to be removed from GHC:
https://mail.haskell.org/pipermail/ghc-devs/2016-September/012826.html
GHC-8.0.2-rc1 already fails to build xmonad-contrib as:
XMonad/Layout/Groups/Helpers.hs:181:22: error:
• Couldn't match type ‘G.WithID l0 Window
-> XMonad.Util.Stack.Zipper (G.Group l0 Window)
-> XMonad.Util.Stack.Zipper (G.Group l0 Window)’
with ‘G.ModifySpec’
Expected type: (G.WithID l0 Window
-> XMonad.Util.Stack.Zipper (G.Group l0 Window)
-> XMonad.Util.Stack.Zipper (G.Group l0 Window))
-> G.GroupsMessage
Actual type: G.ModifySpec -> G.GroupsMessage
• In the second argument of ‘(.)’, namely ‘G.Modify’
In the expression: sendMessage . G.Modify
In an equation for ‘wrap’: wrap = sendMessage . G.Modify
The workaround is simple: add explicit types to applications
or open-code direct application (this change).
Bug: https://github.com/xmonad/xmonad-contrib/issues/123
Signed-off-by: Sergei Trofimovich<EMAIL_ADDRESS>

Thanks, @trofi.


Pass through Powerwall Web interface and customize for iframe displays

Hello,
This PR adds support to the proxy feature of pypowerwall to proxy access to the Powerwall web interface and customize it's appearance.
This lets you run the proxy on a local network and create iframe widgets for displays like Dakboard.

Thank you, @danisla!  This is a great addition!  A few things in my testing:

I had to update the content-type for the json payloads for Chrome and Brave browsers.  I noticed you had it comment out and I changed the logic to dynamically set content-type.  I need to verify that this doesn't negatively impact telegraf or other polling tools (which it shouldn't)
I am not able to get this to work in Safari browser.  I haven't had time to explore why, but it is going to the login screen which of course the proxy is not set to support (POST).  Let me know if you have any suggestions.
I am going to soak test the proxy.  Many people have this running 24x7 so I need to ensure it doesn't have a memory/resource leak with the addition of the great new features.

Great job on this!  Thanks for the PR.

Update:   Another issue I found is that the pass through would not work if you used a hostname or IP address.  Using localhost worked on Chrome and Brave browsers.  I was able to get it to work for all hostnames and on Safari.  I had to remove the send_header() attributes "path=/;SameSite=None;Secure;" From what I can tell, that is only proper if you use HTTPS but since the proxy is HTTP, they were causing the browser to ignore the auth cookies.  I added the ability to make the proxy serve HTTPS via an environmental setting.  I need to run more tests and build an iframe demo to ensure all cases and all browsers work (http and https).  I suspect there are still issues with iframes.
Can you see if the changes still work with your Dakboard?

@jasonacox thanks for the feedback!
I run the pypowerwall proxy in http mode behind an https proxy and I missed the localhost and IP cases, thanks for catching those.
For ideal iframe support, the proxy would need to run in https mode with a valid cert and have the SameSite=None; and Secure; cookie suffixes.
I tested this with PW_HTTPS=yes on my Dakboard and it wouldn't load with the self-signed certificate, there isn't really a way to bypass the cert exception on the iframe without modifying the root certs.
Maybe if the pypowerwall proxy had an option to set the https mode cookiesuffix, while running in http mode, that would fix it for my case where my ssl termination is done upstream. I'm open to other solutions too.
Another thing I noticed is that the cookie should be set with the path=/; prefix in all cases, otherwise you get multiple cookies set for the /api paths too:
if(https_mode == "yes"):
    cookiesuffix = "path=/;SameSite=None;Secure;"
    httptype = "HTTPS"
else:
    cookiesuffix = "path=/;"
    httptype = "HTTP"

Also FYI, the web app has an indexedDB requirement which means the web app doesn't work in some browsers or in incognito  where indexedDB is blocked. (I was running my dakboard on an RPI with Chromium in incogntio and the web app iframe wouldn't load, but disabling incognito fixed it)

Thanks @danisla!  I think we could have a PW_HTTPS=http mode that adds the SameSite suffix without adding another env:
if https_mode == "yes":
    # run https mode with self-signed cert
    cookiesuffix = "path=/;SameSite=None;Secure;"
    httptype = "HTTPS"
elif https_mode == "http":
    # run http mode but simulate https for proxy behind https proxy
    cookiesuffix = "path=/;SameSite=None;Secure;"
    httptype = "HTTP"
else:
    # run in http mode
    cookiesuffix = "path=/;"
    httptype = "HTTP"

Is there a way to detect if indexedDB is blocked?  If so, we could have it send a message to the user to disable incognito.

Hi @danisla  - I made some updates:

Proxy can now run in HTTP mode but will send SameSite data (simulating https).  Hopefully this works for your use case where pypowerwall is behind an https proxy. You would add -e PW_HTTPS='http' to your docker run or equivalent to set the environmental variable.
Fixed the missing 'path=/' suffix.  Thank you!
Added pass through feature notes to the README.md
Added a iFrame example to the proxy web root - example.html to make it easier for others to see how to embed in their projects.
Fixed several bugs (!!!) that I discovered doing all of the above.

I'm now soak testing the latest build to ensure no memory leaks or other issues.
Again, THANK YOU for all your help and the great contribution!

Awesome, glad to be of help.
Thank you for creating and maintaining this project!

One update in case you pull, I changed the js injection to use clear.js which uses 'transparent' background to make it easier to place on multiple projects.  I made this a configurable option via PW_STYLE="clear" environmental variable that pulls in the corresponding js file.  Options are: clear (default), black, white, grafana gray, and dakboard black (your original). It is not an elegant solution but does work.
FYI - I also released an updated Grafana dashboard thanks to your help: https://github.com/jasonacox/Powerwall-Dashboard/discussions/26
Thanks again, Dan!


refactor: Change to copy function in read_region

Motivation
Due to wasmer's memory type patch, dynamic memory type was changed to static memory type, resulting in high performance improvement. https://github.com/wasmerio/wasmer/pull/1299
As a result, there are fewer bound check assemblies for dynamic memory types, which reduces code size and improves performance. It works for all backends.
However, after applied, when measured with erc20 in cosmwasm, the improved performance range was not consistently recorded.
(at least 30% to up to 200%. i.e: when singlepass, 418txs -> 532 ~ 870txs)
So, I had to find out where the difference occurred.
The log below is the measurement result when a JIT compiled function is called from wasmer.
For each transfer, A difference of about 50us occurs irregularly.

address 3608BA37 is handle

debug: func "deallocate" | func:360B5DE8 | elapsed:4.838µs
debug: func "allocate" | func:360B5709 | elapsed:15.843µs
debug: func "allocate" | func:360B5709 | elapsed:4.115µs
debug: func "handle" | func:360B5709 | elapsed:5.189µs
func:3608BA37 | elapsed:199.764µs
debug: func "deallocate" | func:360B5DE8 | elapsed:4.826µs
debug: func "allocate" | func:360B5709 | elapsed:18.979µs
debug: func "allocate" | func:360B5709 | elapsed:3.872µs
debug: func "handle" | func:360B5709 | elapsed:5.222µs
func:3608BA37 | elapsed:207.639µs
debug: func "deallocate" | func:360B5DE8 | elapsed:4.667µs
debug: func "allocate" | func:360B5709 | elapsed:21.81µs
debug: func "allocate" | func:360B5709 | elapsed:4.543µs
debug: func "handle" | func:360B5709 | elapsed:5.699µs
func:3608BA37 | elapsed:236.879µs
debug: func "deallocate" | func:360B5DE8 | elapsed:5.159µs
debug: func "allocate" | func:360B5709 | elapsed:21.678µs
debug: func "allocate" | func:360B5709 | elapsed:4.599µs
debug: func "handle" | func:360B5709 | elapsed:6.005µs
func:3608BA37 | elapsed:297.624µs
debug: func "deallocate" | func:360B5DE8 | elapsed:6.274µs
debug: func "allocate" | func:360B5709 | elapsed:19.402µs
debug: func "allocate" | func:360B5709 | elapsed:4.457µs
debug: func "handle" | func:360B5709 | elapsed:5.347µs
func:3608BA37 | elapsed:213.839µs
debug: func "deallocate" | func:360B5DE8 | elapsed:5.012µs
debug: func "allocate" | func:360B5709 | elapsed:15.524µs
debug: func "allocate" | func:360B5709 | elapsed:4.157µs
debug: func "handle" | func:360B5709 | elapsed:5.215µs
func:3608BA37 | elapsed:197.728µs
debug: func "deallocate" | func:360B5DE8 | elapsed:4.924µs
debug: func "allocate" | func:360B5709 | elapsed:28.02µs
debug: func "allocate" | func:360B5709 | elapsed:5.18µs
debug: func "handle" | func:360B5709 | elapsed:8.691µs
func:3608BA37 | elapsed:360.173µs
debug: func "deallocate" | func:360B5DE8 | elapsed:7.916µs
debug: func "allocate" | func:360B5709 | elapsed:20.315µs
debug: func "allocate" | func:360B5709 | elapsed:4.221µs
debug: func "handle" | func:360B5709 | elapsed:5.81µs
func:3608BA37 | elapsed:244.343µs
debug: func "deallocate" | func:360B5DE8 | elapsed:5.193µs
debug: func "allocate" | func:360B5709 | elapsed:21.005µs
debug: func "allocate" | func:360B5709 | elapsed:4.536µs
debug: func "handle" | func:360B5709 | elapsed:5.448µs
func:3608BA37 | elapsed:236.151µs
debug: func "deallocate" | func:360B5DE8 | elapsed:5.057µs
debug: func "allocate" | func:360B5709 | elapsed:21.288µs
debug: func "allocate" | func:360B5709 | elapsed:4.263µs
debug: func "handle" | func:360B5709 | elapsed:5.594µs
func:3608BA37 | elapsed:238.434µs
debug: func "deallocate" | func:360B5DE8 | elapsed:5.078µs

This is by no means small compared to the total execution time.
However, it is difficult to know from this information alone which part of the handle function is causing the cause.
As a result of analyzing using the profiler tool, I found that every time the execution was slow, read_region took up time.
due to the low resolution of the profiler, read_region was only captured when it was slow and not when it was fast.
(I'd like to write more details about the profiling process, but it will take a long time, so I skip it.)

Proposed Solution
As you know well, optimization is difficult if you copy it repeatedly with a for statement.
Using a method like memcpy, you can lead to optimizations such as SIMD copying.
It is effective even if the memory size is not necessarily large.
As a result of patching the read_region,

recorded stable performance
and maximum performance improvement 10%
(when singlepass, 532 ~ 870txs -> 876 ~ 913txs)

In the comment, I found that already had this kind of issue.
So, for some reason, I'd like to hear your opinion on the change back to the for statement method.

@maurolacy could you look into this proposal and let us know what you think? Also check the latest Wasmer code how they implment the raw copy in WASI. If we want to use this or a similar implementation, we should be heavily testing read_region (don't know to what degree this is done at the moment).

@maurolacy could you look into this proposal and let us know what you think? Also check the latest Wasmer code how they implment the raw copy in WASI. If we want to use this or a similar implementation, we should be heavily testing read_region (don't know to what degree this is done at the moment).

Will look into it in more detail during the day, but (except for the formatting issues) this looks good to me.
The for loop seems to be there just because of the Cell encapsulation, i. e. cautiously avoiding premature optimization.

Will look into it in more detail during the day, but (except for the formatting issues) this looks good to me.
The for loop seems to be there just because of the Cell encapsulation, i. e. cautiously avoiding premature optimization.

Yeah, this was marked as posssibly inefficient, but safe.
Good to revisit what wasmer has done, and maybe ask them what they recommend. (The PR may open up to panics/UB when getting an overly large region size for which no memory was allocated (malicious creation of Region in the contract side).
There is an equivalent call in write_region, which I would think to be safer to optimize (the bounds of the region we copy come from trusted go/vm code, not untrusted contracts). We still need to sanity check if there is enough memory available for this (eg. contract implements a lying allocate function)

Yeah, this was marked as posssibly inefficient, but safe.
Good to revisit what wasmer has done, and maybe ask them what they recommend. (The PR may open up to panics/UB when getting an overly large region size for which no memory was allocated (malicious creation of Region in the contract side).
There is an equivalent call in write_region, which I would think to be safer to optimize (the bounds of the region we copy come from trusted go/vm code, not untrusted contracts). We still need to sanity check if there is enough memory available for this (eg. contract implements a lying allocate function)

The PR may open up to panics/UB when getting an overly large region size for which no memory was allocated (malicious creation of Region in the contract side).

Thanks for comments!
However, I have one question.
First, Cell::get() in the previous code is implemented as follows.
This is the same as the unsafe type cast. However, race condition safety is guaranteed due to Cell's !sync macro.
https://doc.rust-lang.org/src/core/cell.rs.html#429-433
https://doc.rust-lang.org/src/core/cell.rs.html#1711
So, I think if the mentioned unallocated or large sized problem can occur, the approach using Cell seems the same as cast. Because It makes sense as a problem that has nothing to do with race condition.
Is there any example that happened before?

The PR may open up to panics/UB when getting an overly large region size for which no memory was allocated (malicious creation of Region in the contract side).

Thanks for comments!
However, I have one question.
First, Cell::get() in the previous code is implemented as follows.
This is the same as the unsafe type cast. However, race condition safety is guaranteed due to Cell's !sync macro.
https://doc.rust-lang.org/src/core/cell.rs.html#429-433
https://doc.rust-lang.org/src/core/cell.rs.html#1711
So, I think if the mentioned unallocated or large sized problem can occur, the approach using Cell seems the same as cast. Because It makes sense as a problem that has nothing to do with race condition.
Is there any example that happened before?

So, I think if the mentioned unallocated or large sized problem can occur, the approach using Cell seems the same problem can occur as directly cast.

Yes, I agree.
I was taking a look yesterday, and the issues @ethanfrey mentions are related to potential attacks to the memory.
I think it would be very interesting to perform an analysis of wasm / wasmer memory model from a security / safety standpoint, but that that is clearly beyond the changes that this PR is suggesting.
As you say, these changes are equivalent, as far as I see, to the original version in terms of security / safety.

So, I think if the mentioned unallocated or large sized problem can occur, the approach using Cell seems the same problem can occur as directly cast.

Yes, I agree.
I was taking a look yesterday, and the issues @ethanfrey mentions are related to potential attacks to the memory.
I think it would be very interesting to perform an analysis of wasm / wasmer memory model from a security / safety standpoint, but that that is clearly beyond the changes that this PR is suggesting.
As you say, these changes are equivalent, as far as I see, to the original version in terms of security / safety.

@slave5vw can you please fix the format (cargo fmt), and generally make the CI happy?

@slave5vw can you please fix the format (cargo fmt), and generally make the CI happy?

@slave5vw can you please fix the format (cargo fmt), and generally make the CI happy?
Oh, I forgot. Thanks!

@slave5vw can you please fix the format (cargo fmt), and generally make the CI happy?
Oh, I forgot. Thanks!

One more comment. Are the benchmarking scripts used to show the performance gain in the repo already? Or part of this PR?
It would be good to start tracking that. And maybe we can improve as well further (with the write_memory section for example)

One more comment. Are the benchmarking scripts used to show the performance gain in the repo already? Or part of this PR?
It would be good to start tracking that. And maybe we can improve as well further (with the write_memory section for example)

Oh, unfortunately, the company's current policy makes it difficult to disclose the Benchmark tool. Sorry.
However, the operation is simple. After creating multiple accounts, execute erc20 transfer to try repeatedly.
And the profiler tool I used is instruments on mac. You can use the counter library.
With this tool, you can view profiling results for only the desired time interval through the timeline. It will be helpful in identifying this issue. (Other profilers usually only see the aggregate results from start to finish, which was not helpful in identifying this issue.)

Oh, unfortunately, the company's current policy makes it difficult to disclose the Benchmark tool. Sorry.
However, the operation is simple. After creating multiple accounts, execute erc20 transfer to try repeatedly.
And the profiler tool I used is instruments on mac. You can use the counter library.
With this tool, you can view profiling results for only the desired time interval through the timeline. It will be helpful in identifying this issue. (Other profilers usually only see the aggregate results from start to finish, which was not helpful in identifying this issue.)

Weell, we can add benchmarks to measure read/write_region directly, and we should be able to the see the performance gain of this change.
@slave5vw if you want to do it, go ahead. Otherwise, I'll take it.

Weell, we can add benchmarks to measure read/write_region directly, and we should be able to the see the performance gain of this change.
@slave5vw if you want to do it, go ahead. Otherwise, I'll take it.

@maurolacy  I would appreciate it if you take works for benchmarks.
and write_region has little change. So I didn't include it in pr. But It was a limited test in the case of the erc20, so it may make sense for other samples.

@maurolacy  I would appreciate it if you take works for benchmarks.
and write_region has little change. So I didn't include it in pr. But It was a limited test in the case of the erc20, so it may make sense for other samples.

We have higher level benchmarks that can benchmark all public interfaces of cosmwasm-vm. Those include contract executions. I would not go into microbenchmarking at this point because what does it help if the call gets 20x faster but that speedup is not relevant in the bigger picture?

We have higher level benchmarks that can benchmark all public interfaces of cosmwasm-vm. Those include contract executions. I would not go into microbenchmarking at this point because what does it help if the call gets 20x faster but that speedup is not relevant in the bigger picture?

We have higher level benchmarks that can benchmark all public interfaces of cosmwasm-vm.

@slave5vw or @maurolacy maybe someone can run those benchmarks on main and then on this branch and post the results here (or do we track performance inside the repo in an md?)
It would be nice to demo the speedup of call_handle (1%? 20%?).

We have higher level benchmarks that can benchmark all public interfaces of cosmwasm-vm.

@slave5vw or @maurolacy maybe someone can run those benchmarks on main and then on this branch and post the results here (or do we track performance inside the repo in an md?)
It would be nice to demo the speedup of call_handle (1%? 20%?).

can someone run those benchmarks on main and then on this branch

I'll do it.

can someone run those benchmarks on main and then on this branch

I'll do it.

@webmaster128 It's hard to know what it means,
The exact purpose of this pr is to stabilize the irregular performance that occurs after wasmer static bound patch.
https://github.com/wasmerio/wasmer/pull/1299
If you want to independently check the irregular performance without side-effects, I recommend try applying the patch above PR to cosmwasm 0.10.1 and wasmer 0.17.0.

@webmaster128 It's hard to know what it means,
The exact purpose of this pr is to stabilize the irregular performance that occurs after wasmer static bound patch.
https://github.com/wasmerio/wasmer/pull/1299
If you want to independently check the irregular performance without side-effects, I recommend try applying the patch above PR to cosmwasm 0.10.1 and wasmer 0.17.0.

Here are some results:
"execute handle" (calls call_handle) in main:
singlepass: [47.191 us 48.384 us 50.100 us]
cranelift: [44.035 us 45.701 us 47.007 us]
"execute handle" (calls call_handle) in read_region-copy (branch I created for this):
singlepass: [56.238 us 57.568 us 59.715 us]
cranelift: [43.016 us 45.889 us 49.848 us]
So, this is in fact worse for singlepass (!) and irrelevant for cranelift. I'm assuming these benchmarks are comparable. I'll force again locally, to see if there is an spurious factor or so here.
References:
main latest benchs: https://app.circleci.com/pipelines/github/CosmWasm/cosmwasm/2172/workflows/38460158-6bb6-4d6f-87ab-75b6a0bd3d6b/jobs/21182
read_region-copy benchs: https://app.circleci.com/pipelines/github/CosmWasm/cosmwasm/2174/workflows/59a2fb13-860d-4e5e-9d69-11fec9e158d3/jobs/21209

Here are some results:
"execute handle" (calls call_handle) in main:
singlepass: [47.191 us 48.384 us 50.100 us]
cranelift: [44.035 us 45.701 us 47.007 us]
"execute handle" (calls call_handle) in read_region-copy (branch I created for this):
singlepass: [56.238 us 57.568 us 59.715 us]
cranelift: [43.016 us 45.889 us 49.848 us]
So, this is in fact worse for singlepass (!) and irrelevant for cranelift. I'm assuming these benchmarks are comparable. I'll force again locally, to see if there is an spurious factor or so here.
References:
main latest benchs: https://app.circleci.com/pipelines/github/CosmWasm/cosmwasm/2172/workflows/38460158-6bb6-4d6f-87ab-75b6a0bd3d6b/jobs/21182
read_region-copy benchs: https://app.circleci.com/pipelines/github/CosmWasm/cosmwasm/2174/workflows/59a2fb13-860d-4e5e-9d69-11fec9e158d3/jobs/21209

emm, CI test result is strange. The benchmark result as Tendermint log, will be left as a comment tomorrow. I'm already off work.

emm, CI test result is strange. The benchmark result as Tendermint log, will be left as a comment tomorrow. I'm already off work.

OK, I've run benchmarks again in both branches, and now results make more sense.
"execute handle" (calls call_handle) in main:
singlepass: [49.432 us 51.169 us 52.996 us]
cranelift: [42.637 us 43.724 us 44.907 us]
"execute handle" (calls call_handle) in read_region-copy (branch I created for this):
singlepass: [47.547 us 48.810 us 50.255 us]
cranelift: [41.843 us 42.505 us 42.989 us]
That's an improvement of ~5% for read_region with copy. So, regarding these benchmarks / use cases, this change is not that relevant.
My opinion is that it wouldn't hurt either. wasmer's read_region does something similar (using casts over an array of regions).
References:
main benchs: https://app.circleci.com/pipelines/github/CosmWasm/cosmwasm/2172/workflows/1820727a-8858-4ebc-b176-8988c0ea1ec0/jobs/21223
read_region-copy benchs: https://app.circleci.com/pipelines/github/CosmWasm/cosmwasm/2174/workflows/4107fb3b-8821-4666-a584-20d840a82df4/jobs/21237

OK, I've run benchmarks again in both branches, and now results make more sense.
"execute handle" (calls call_handle) in main:
singlepass: [49.432 us 51.169 us 52.996 us]
cranelift: [42.637 us 43.724 us 44.907 us]
"execute handle" (calls call_handle) in read_region-copy (branch I created for this):
singlepass: [47.547 us 48.810 us 50.255 us]
cranelift: [41.843 us 42.505 us 42.989 us]
That's an improvement of ~5% for read_region with copy. So, regarding these benchmarks / use cases, this change is not that relevant.
My opinion is that it wouldn't hurt either. wasmer's read_region does something similar (using casts over an array of regions).
References:
main benchs: https://app.circleci.com/pipelines/github/CosmWasm/cosmwasm/2172/workflows/1820727a-8858-4ebc-b176-8988c0ea1ec0/jobs/21223
read_region-copy benchs: https://app.circleci.com/pipelines/github/CosmWasm/cosmwasm/2174/workflows/4107fb3b-8821-4666-a584-20d840a82df4/jobs/21237

And could you tell me which contract was used in the test? It looks a lot shorter than the erc20's execution.

You can take a look at these benchmarks here: https://github.com/CosmWasm/cosmwasm/blob/main/packages/vm/benches/main.rs#L56

And could you tell me which contract was used in the test? It looks a lot shorter than the erc20's execution.

You can take a look at these benchmarks here: https://github.com/CosmWasm/cosmwasm/blob/main/packages/vm/benches/main.rs#L56

My opinion is that it wouldn't hurt either.

Fine with me

wasmer's read_bytes does something similar (using casts over an array of regions).

Can we please add a reference comment to the latest version of that code to the place where we do unsafe operatrions? Wasmer changed a lot between 0.13.1 and 1.0.

My opinion is that it wouldn't hurt either.

Fine with me

wasmer's read_bytes does something similar (using casts over an array of regions).

Can we please add a reference comment to the latest version of that code to the place where we do unsafe operatrions? Wasmer changed a lot between 0.13.1 and 1.0.

Can we please add a reference comment to the latest version of that code to the place where we do unsafe operation? Wasmer changed a lot between 0.13.1 and 1.0.

Good point. There you go: https://github.com/wasmerio/wasmer/blob/1.0.0/lib/wasi/src/syscalls/mod.rs#L82-L84

Can we please add a reference comment to the latest version of that code to the place where we do unsafe operation? Wasmer changed a lot between 0.13.1 and 1.0.

Good point. There you go: https://github.com/wasmerio/wasmer/blob/1.0.0/lib/wasi/src/syscalls/mod.rs#L82-L84

Thank you for bringing this up and proposing a solution. After carful consideration we decided this should really be implemented in Wasmer, not here. I opened https://github.com/wasmerio/wasmer/issues/2035. The reason is that if we put so much effort into reasoning wether or not this is a safe operation, it should be available to all users of Wasmer, not just us. In the unlikely case that the feature request is rejected by Wasmer, we'll come back to it here.

Thank you for bringing this up and proposing a solution. After carful consideration we decided this should really be implemented in Wasmer, not here. I opened https://github.com/wasmerio/wasmer/issues/2035. The reason is that if we put so much effort into reasoning wether or not this is a safe operation, it should be available to all users of Wasmer, not just us. In the unlikely case that the feature request is rejected by Wasmer, we'll come back to it here.

That's a good decision. If necessary, I will comment in the wasmer issue.

That's a good decision. If necessary, I will comment in the wasmer issue.

That's a good decision. If necessary, I will comment in the wasmer issue.

If you can support the motivation with benchmarkes from Wasmer 1.0, that is definitly helpful. Otherwise just subscribe. We will probably start working on it next week.

That's a good decision. If necessary, I will comment in the wasmer issue.

If you can support the motivation with benchmarkes from Wasmer 1.0, that is definitly helpful. Otherwise just subscribe. We will probably start working on it next week.


Timeout not working on Pipeline run

When I checked pipelinerun I found TaskRunTimeOut

I also checked the manifest of this pipeline run and I have specified timeout to 3hrs

@AlanGreene Can you help me with this?

👋🏼 @ritesh-makerble , thanks for the issue. According to the doc (and the code), this is expected.

tasks: specifies the timeout for the cumulative time taken by non-finally Tasks specified in pipeline.spec.tasks.
To specify a timeout for an individual Task, use pipeline.spec.tasks[].timeout.
When timeouts.tasks has elapsed, any running child TaskRuns will be canceled, finally Tasks will run if timeouts.finally is specified,
and the PipelineRun will fail.

Each Task will have a the default 1h timeout (or what is configured in the config-defaults configmap) if not specified otherwise. timeouts.tasks is for "all" Task to execute (not for "each").
There is a bunch of issues about this (that kind-of show it can be confusing):

https://github.com/tektoncd/pipeline/issues/6520
https://github.com/tektoncd/pipeline/issues/6137

@vdemeester In my issue, you can see I have specified timouts.task to 3h. But my pipeline run fails after 1 hr with an Error TaskRunTimeOut even though the timeout.pipeline is 4h.

Yes, my guess is that there is a Task that timed out at 1h, making the pipelinerun fail. With what you specified, all task need to complete in 3h, but each task has its own 1h timeout. So if one task takes more than 1h it will timeout.


Wakatime extension error

Prerequisites

[x] Is this Brackets-Electron specific problem (did you test it with latest brackets build)?

Description
On first launch after Wakatime install, Wakatime prompts for wakatime API key. In console it throwss this error message C:/Users/Martin/AppData/Roaming/Brackets-Electron/extensions/user/brackets-wakatime - Error: prompt() is and will not be supported.
Versions
1.8 Win7 64bit
Steps to Reproduce

Install wakatime extension
Restart Brackets-Electron
No Wakatime key prompt

Expected behavior: Prompt or other possibility to enter wakatime key
Actual behavior: extension error

https://github.com/electron/electron/issues/472

Closed by wakatime/brackets-wakatime#4


Remove Carrenza VPN

We still have one side of these VPN tunnels running in AWS (staging and production), but we no longer have any infrastructure running in Carrenza, so the tunnels can't be doing anyone any good.
Occasionally AWS email me about these tunnels having issues, and I think to myself "why do we still have VPN tunnels in Carrenza?". That is thinking time I could be spending on other, more relevant or interesting things, so let's remove the tunnels.
Roll out plan:

I'll do a terraform plan -destroy for staging and production
I'll get this reviewed along with the plan
I'll also get a review for https://github.com/alphagov/govuk-aws-data/pull/1146 for the config behind this project
Once approved, I'll destroy this project in staging and then production, and then merge the PRs

So, the applications situation with this terraform is different in all of the environments:

Environment
Situation

Integration
No statefile for this project, no VPN resources in AWS

Staging
No statefile for this project, but there are VPN resources in the account, which appear to be left over from the infra-vpc project which used to own them

Production
Statefile and resources exist, plan-destroy says 0 to add, 0 to change, 4 to destroy (which sounds sensible)

Full production plan-destroy on Jenkins - https://deploy.integration.publishing.service.gov.uk/job/Deploy_Terraform_GOVUK_AWS/5361/console

Terraform destroy ran successfully in production, going to have a look at staging to see if it can be cleaned up.

Staging cleaned up manually (I created a temporary terraform project based on an old version of infra-vpc, imported the resources, and then destroyed them). infra-vpc is applying cleanly from main now - https://deploy.integration.publishing.service.gov.uk/job/Deploy_Terraform_GOVUK_AWS/5365/console
VPN gone from all environments! 🚀


Publish arm64 images

For use with AWS Graviton instances and Raspberry Pis
I double checked and the project compiles and tests properly, so this should just be a matter of rigging up a pipeline to publish the image.

Hi @jpcoenen,
This issue was prematurely closed. The 1password/connect-api and 1password/connect-sync images still don't have ARM64 variants.

Hi Brandon :wave:
I am sorry the confusion. I did not realize that there was no separate issue for the Connect images when linking the PR to the issue. A separate place for issues with Connect api and sync is in the making. Until that is ready, I'll re-open this issue as a reminder.
Regarding the ARM images themselves: we are working on it.

Heey @DWSR,
ARM images for both the API and the sync are available with Connect 1.5.0+.
Therefore, now both the operator and Connect should be supported on ARM.
I hope this solves your issue. Feel free to reopen it if you encounter any issues.


403 profile picture error

Hello. A lot of profile pictures started to return a 403 error. Can you tell me what is the reason for this?

hi, does this also happen on https://tiktok-chat-reader.zerody.one/ ?
Also check that you are using the latest version of the library.

Yes, we use latest version of the library. On your site all ok, but on my server i have so many errors

https://p58-sign-va.tiktokcdn.com/tos-maliva-avt-0068/f80fe9d7e6ece8c1b651ef526fe44dd0~c5_100x100.webp?x-expires=1655658000&x-signature=AfOKszWxrDWfAAhLSrnt8O+FdUM=
Example of url with error

Have fixed the URL:
https://p58-sign-va.tiktokcdn.com/tos-maliva-avt-0068/f80fe9d7e6ece8c1b651ef526fe44dd0~c5_100x100.webp?x-expires=1655658000&x-signature=AfOKszWxrDWfAAhLSrnt8O%2BFdUM%3D
+ => %2B
= => %3D
Special characters must be urlencoded. But this is the case by default. Do you use a decode function like decodeURIComponent()? If so, remove the decode function and use the original URL without any changes.

Oy, really. Thank you so much


Union-Find data structure implementation

I have only to write an explanation. I think it will be ready tomorrow.

What does the DS stand for?

It's abbreviation for DataStructure. Do you think that it's redundant?

Yeah, I don't think "DS" adds anything so I would leave it out.
Have you considered making it a struct instead of a class? In Swift most collection types are structs.

I haven't thought of it as collection type. But I've taken into consideration your сomment and now changed my mind so I suppose to make it a struct.

I want to refactor this very unsafe line of code let indexOfElement = index[element]!. But I don't know what would be better: calling fatalError() or throwing exception? @hollance What are your thoughts?

I would solve this by returning nil if the element cannot be found:
public mutating func findSetOfElement(element: T) -> Int? {
  if let indexOfElement = index[element] {
    return findSetByIndexOfElement(indexOfElement)
  } else {
    return nil
  }
}

By the way, can you rename the directory to Union-Find?

Also I'm thinking about helper method like
public mutating func isInTheSameSet(firstElement: T, secondElement: T) -> Bool {
  if let firstSet = findSetOfElement(firstElement), secondSet = findSetOfElement(secondElement) {
    return firstSet == secondSet
  } else {
    return false
  }
}

I have some suggestions for name changes. Not that your names are bad, but they could be simplified a little.

isInTheSameSet() could just be inSameSet()
findSetOfElement() could be setOfElement() or even just setOf()
addSetWithElement() could just be add()
unionSetsWithElement(andSecondElement:) could be unionSetsContaining(and:)

I also notice you used ( ) with some if-statements and even some semicolons! :scream: ;-)

I still write some ObjC but I'm honestly trying to get rid of this habit :flushed:
I have some doubts about renaming addSetWithElement() to add() because it becomes a bit not clear what we actually add. In my opinion, the best solution is addSetWith()

The idea is that each element you add is given its own set containing just that element, right? I agree that just add() may not make that very clear.

I think I've done. Do you have any remarks?

Looking good. :-) I'll probably merge it tomorrow.

Very nice! I tweaked the description a little for grammar etc.

Thank you for your work. Now it looks much better!


feat(cli): warn on unknown commands

codeceptjs junkcmd
Unknown command junkcmd

Usage: codeceptjs [options] [command]

Options:
  -h, --help                                      output usage information

Commands:
  init [path]                                     Creates dummy config in current dir or [path]
  migrate [path]                                  Migrate json config to js config in current dir or [path]
  shell|sh [options] [path]                       Interactive shell
  list|l [path]                                   List all actions for I.
  def [options] [path]                            Generates TypeScript definitions for all I actions.
  gherkin:init|bdd:init [options] [path]          Prepare CodeceptJS to run feature files.
  gherkin:steps|bdd:steps [options] [path]        Prints all defined gherkin steps.
  gherkin:snippets|bdd:snippets [options] [path]  Generate step definitions from steps.
  generate:test|gt [path]                         Generates an empty test
  generate:pageobject|gpo [path]                  Generates an empty page object
  generate:object|go [options] [path]             Generates an empty support object (page/step/fragment)
  generate:helper|gh [path]                       Generates a new helper
  run [options] [test]                            Executes tests
  run-multiple [options] [suites...]              Executes tests multiple

cc @pablopaul

Great!


Is IE11 still supported in V3?

I am testing the samples of version 3 of master and going to the vertical bar sample, I have got the following error, by IE11:
SCRIPT438: Object doesn't support property or method 'values'
chart.min.js (13,60262)

Maybe I'm wrong but it seems IE11 is not supported anymore.

It should still be supported, because the support has not been dropped.
Object.values is used here: https://github.com/chartjs/Chart.js/blob/7718d5fd56e14ac26af14f8c74aaeb5cbfcd32ee/src/core/core.controller.js#L1076
It comes from #7843

Legacy browser support gets dropped in V3 right with this pr #8009 ?

If we can drop IE11 support now, I am onboard.

If we can drop IE11 support now, I am onboard.

I could agree but you must be aware that in the enterprise world IE11 is still hugely used, therefore, for me, to drop IE11 is not a good decision

https://www.google.com/amp/s/cisomag.eccouncil.org/no-security-updates-to-ie-browser/amp/

https://www.google.com/amp/s/cisomag.eccouncil.org/no-security-updates-to-ie-browser/amp/

Yes @kurkle, I'm aware. I'm not sure that all companies will jump on Edge but nevertheless they can use FF or Chrome :).
Let me highlight that I'm not against to drop IE11 but I know companies where there still using IE11. Dropping IE11 I could also think to remove polyfilling...

@stockiNail interesting point but if they want to keep using IE11 they can still use charts 2.9.4.
With a major upgrade like this it's the best time in my eyes to drop support for outdated browsers so that you can use new js features in your code whenn they come out.
Otherwise you will need to wait till version 4 because I think it'd weird to say it's only supported till v3.4 for example

Guys, you have convinced me! it's right time to do it, I agree!
Let's drop it!
Just mentioning in the migration guide.

Updated #8009 to mention the removal of IE11 support (and also remove the really old version numbers of other browsers)

I agree with @LeeLenaleee if large companies can't update the browser, they probably won't update the code either. They can continue to work with chart.js version 2.

tl;dr: 1. dropping IE11 is fine if providing ES5 build targets. 2. IE11-support mandate is modern and current reality for many markets inc. larger orgs/governments (i.e. even a brand new startup using the hottest dev stack and doing CI deploys 50 times a day may still need IE11-support when servicing these markets)

... if large companies can't update the browser, they probably won't update the code either.

For the record, as a counterpoint, this is flat out wrong.
"Let them eat the old version" is a common refrain, but it's misplaced. To add a datapoint from the context you're talking about (large org finance, markets, and now government) it's actually more like the devs in those spaces have to seriously push the envelope by hunting for performant, cross-platform solutions (so things like the performance upgrades in Chart.js 3 are absolutely reason to upgrade).
Governments and large orgs often have requirements if not outright obligations to support much broader userbase needs (and often much larger audiences) than startups or individual developers and the IE11 requirement is usually an external/environmental/legislative constraint that complicates QA and build/test/CI pipelines, not an indication that they don't or wont "update the code".

I'm not sure that all companies will jump on Edge

Yep, 100% correct. And the bigger the company the less likely the jump. But for governments it's also about supporting their end-users in "accessible" ways and that means supporting "supported" browsers.

Also IE support from ms will end in less then a year

Sadly, nope. IE11 is supported until at least Oct 2024 😢  (the EOL support for Win10) -- I do expect large orgs and governments to painfully migrate as we approach that date, but i'm not holding my breath. MS is winding down support for their webapps for IE11 from this year, but that's not the same thing.
Nonetheless, dropping IE11 support from the codebase is actually fine.
It's common practice these days to have to conditionally polyfill back for IE11 in order to support "the new shiny". However lib authors can enable this process by providing ES5 transpiled targets as part of package deploys.
Just 5c from the other side.

tl;dr: 1. dropping IE11 is fine if providing ES5 build targets. 2. IE11-support mandate is modern and current reality for many markets inc. larger orgs/governments (i.e. even a brand new startup using the hottest dev stack and doing CI deploys 50 times a day may still need IE11-support when servicing these markets)

... if large companies can't update the browser, they probably won't update the code either.

For the record, as a counterpoint, this is flat out wrong.
"Let them eat the old version" is a common refrain, but it's misplaced. To add a datapoint from the context you're talking about (large org finance, markets, and now government) it's actually more like the devs in those spaces have to seriously push the envelope by hunting for performant, cross-platform solutions (so things like the performance upgrades in Chart.js 3 are absolutely reason to upgrade).
Governments and large orgs often have requirements if not outright obligations to support much broader userbase needs (and often much larger audiences) than startups or individual developers and the IE11 requirement is usually an external/environmental/legislative constraint that complicates QA and build/test/CI pipelines, not an indication that they don't or wont "update the code".

I'm not sure that all companies will jump on Edge

Yep, 100% correct. And the bigger the company the less likely the jump. But for governments it's also about supporting their end-users in "accessible" ways and that means supporting "supported" browsers.

Also IE support from ms will end in less then a year

Sadly, nope. IE11 is supported until at least Oct 2024 😢  (the EOL support for Win10) -- I do expect large orgs and governments to painfully migrate as we approach that date, but i'm not holding my breath. MS is winding down support for their webapps for IE11 from this year, but that's not the same thing.
Nonetheless, dropping IE11 support from the codebase is actually fine.
It's common practice these days to have to conditionally polyfill back for IE11 in order to support "the new shiny". However lib authors can enable this process by providing ES5 transpiled targets as part of package deploys.
Just 5c from the other side.

I just can't agree.
How many of your target customers are using IE11 that you are so worried about supporting it? If this is not more than a couple of percent, I recommend that you invite them to switch to modern technologies. It will be much easier for you to create and support your own project, and for them it will also increase security.
ES5 will add weight to the library, few people need this support, but everyone will suffer. These people can continue to work with version 2, if they need to support IE11.

Beginning November 30, 2020, the Microsoft Teams web app will no longer support IE 11.
Update: The Microsoft Teams web app no longer supports IE 11 as of November 30, 2020. To access Microsoft Teams, use the desktop app or a supported modern browser like the new Microsoft Edge.
Beginning August 17, 2021, the remaining Microsoft 365 apps and services will no longer support IE 11.

source

I just can't agree.
How many of your target customers are using IE11 that you are so worried about supporting it? If this is not more than a couple of percent, I recommend that you invite them to switch to modern technologies. It will be much easier for you to create and support your own project, and for them it will also increase security.
ES5 will add weight to the library, few people need this support, but everyone will suffer. These people can continue to work with version 2, if they need to support IE11.

Beginning November 30, 2020, the Microsoft Teams web app will no longer support IE 11.
Update: The Microsoft Teams web app no longer supports IE 11 as of November 30, 2020. To access Microsoft Teams, use the desktop app or a supported modern browser like the new Microsoft Edge.
Beginning August 17, 2021, the remaining Microsoft 365 apps and services will no longer support IE 11.

source

I just can't agree.

I get that. This is why I posted. Because unless you work with large (non-tech) orgs or in government, IE11 support seems insane. But outside the "tech world", IE11 support comes up way more than you'd expect (or ever want).

How many of your target customers are using IE11 that you are so worried about supporting it?

Case in point: for us, comfortably 80% of our clients either use IE11 or require us to support it, including every Federal government agency we deal with and most State level too. It's only at local government levels that IE11 is a nice-to-have. Governments in many countries have accessibility legislation (real laws, with real consequences) that in some cases more or less require them to support "supported" browsers. In most cases, these requirements are flat out non-negotiable.

If this is not more than a couple of percent, I recommend that you invite them to switch to modern technologies. It will be much easier for you to create and support your own project, and for them it will also increase security.

You're not wrong, but I'm not sure you've dealt with large orgs or government before? It's not that this conversation can't happen, but in many cases their fundamental requirements preclude this. It's a non-starter.
Which means it remains a "sun rises in the morning" fact that there are locked-in-stone requirements to support IE11 that are not going away until late 2024 and probably beyond that. I don't like it either.

Beginning August 17, 2021, the remaining Microsoft 365 apps and services will no longer support IE 11.

Yep, that's exactly what I said earlier. But as I also said, it's irrelevant. MS is sun-setting their own internal web-app support for IE11, but that's not the same thing as sun-setting support for the browser, so doesn't change large-org/gov requirement sheets. IE11 itself is supported until EOL Win 10 which is currently Oct 2024, and large orgs and gov (and therefore apps built for userbases of millions) will also have to support it. Yeah it's a total sh1t sandwich.

These people can continue to work with version 2, if they need to support IE11.

Except that's not how it works in practice.
Depending on the project, you can be talking about userbases of hundreds of thousands of people that don't show up on the open internet (internal agency or inter-gov apps). In other cases, IE11 support is mandated for public apps that serve millions of users. Which means if you cripple your codebase to comply with the "sorry, you must just eat the old versions of dependencies", you cripple it for everyone.
So that's just not how it plays out. We don't cripple anything. We write modern code that is transpiled to ES5 and conditionally polyfilled for legacy build targets. That's more or less what most projects (and packaged modules) are doing these days. Yes it means you increase package heft because you don't tree-shake nicely.  It's more people than you think. And often with much bigger audiences than you imagine precisely because it is large-orgs and government, which is precisely why it sits in the blind spot of so many devs.
As may be the case here if it goes that way, for reference, for the few dependencies we use that don't provide ES5 bundled deps (and to be clear, a very large number DO provide this), we end up vendoring the code into custom build pipelines that end up going through our own transpile processes to ensure they are broadly accessible. It's a pain but c'est la vie.
TL;DR remains: dropping IE11 support is fine. IE11 is officially around until Oct 2024. And it's a really nice move to provide an ES5 build.

I just can't agree.

I get that. This is why I posted. Because unless you work with large (non-tech) orgs or in government, IE11 support seems insane. But outside the "tech world", IE11 support comes up way more than you'd expect (or ever want).

How many of your target customers are using IE11 that you are so worried about supporting it?

Case in point: for us, comfortably 80% of our clients either use IE11 or require us to support it, including every Federal government agency we deal with and most State level too. It's only at local government levels that IE11 is a nice-to-have. Governments in many countries have accessibility legislation (real laws, with real consequences) that in some cases more or less require them to support "supported" browsers. In most cases, these requirements are flat out non-negotiable.

If this is not more than a couple of percent, I recommend that you invite them to switch to modern technologies. It will be much easier for you to create and support your own project, and for them it will also increase security.

You're not wrong, but I'm not sure you've dealt with large orgs or government before? It's not that this conversation can't happen, but in many cases their fundamental requirements preclude this. It's a non-starter.
Which means it remains a "sun rises in the morning" fact that there are locked-in-stone requirements to support IE11 that are not going away until late 2024 and probably beyond that. I don't like it either.

Beginning August 17, 2021, the remaining Microsoft 365 apps and services will no longer support IE 11.

Yep, that's exactly what I said earlier. But as I also said, it's irrelevant. MS is sun-setting their own internal web-app support for IE11, but that's not the same thing as sun-setting support for the browser, so doesn't change large-org/gov requirement sheets. IE11 itself is supported until EOL Win 10 which is currently Oct 2024, and large orgs and gov (and therefore apps built for userbases of millions) will also have to support it. Yeah it's a total sh1t sandwich.

These people can continue to work with version 2, if they need to support IE11.

Except that's not how it works in practice.
Depending on the project, you can be talking about userbases of hundreds of thousands of people that don't show up on the open internet (internal agency or inter-gov apps). In other cases, IE11 support is mandated for public apps that serve millions of users. Which means if you cripple your codebase to comply with the "sorry, you must just eat the old versions of dependencies", you cripple it for everyone.
So that's just not how it plays out. We don't cripple anything. We write modern code that is transpiled to ES5 and conditionally polyfilled for legacy build targets. That's more or less what most projects (and packaged modules) are doing these days. Yes it means you increase package heft because you don't tree-shake nicely.  It's more people than you think. And often with much bigger audiences than you imagine precisely because it is large-orgs and government, which is precisely why it sits in the blind spot of so many devs.
As may be the case here if it goes that way, for reference, for the few dependencies we use that don't provide ES5 bundled deps (and to be clear, a very large number DO provide this), we end up vendoring the code into custom build pipelines that end up going through our own transpile processes to ensure they are broadly accessible. It's a pain but c'est la vie.
TL;DR remains: dropping IE11 support is fine. IE11 is officially around until Oct 2024. And it's a really nice move to provide an ES5 build.

So that's just not how it plays out. We don't cripple anything. We write modern code that is transpiled to ES5 and conditionally polyfilled for legacy build targets. That's more or less what most projects (and packaged modules) are doing these days. Yes it means you increase package heft because you don't tree-shake nicely.

That how I'd do it. Write a modern thing (with modern libs) and transpile to ES5, all of it. Means you need to build a new version to update dependencies, but that is probably a requirement too anyway, right?

So that's just not how it plays out. We don't cripple anything. We write modern code that is transpiled to ES5 and conditionally polyfilled for legacy build targets. That's more or less what most projects (and packaged modules) are doing these days. Yes it means you increase package heft because you don't tree-shake nicely.

That how I'd do it. Write a modern thing (with modern libs) and transpile to ES5, all of it. Means you need to build a new version to update dependencies, but that is probably a requirement too anyway, right?

Means you need to build a new version to update dependencies, but that is probably a requirement too anyway, right?

Exactly correct.

Means you need to build a new version to update dependencies, but that is probably a requirement too anyway, right?

Exactly correct.

For anyone finding this down the line, Chart.js officially breaks up with IE11 permanently as of PR #8374 (included as part of the v3.0.0 gold release) due to the use of proxy Reflect calls in ways that cannot be polyfilled to work in Internet Explorer. End of the road.

It looks like this isn't mentioned in the migration guide. It seems like it should be somewehere very prominent.


Private github modules not supported

Whenever I have a private github dependency such as:
"something"<EMAIL_ADDRESS>I get the following error:
Response code 404 (Not Found)
Notice it's a private repository on Github, which makes ssh authentication
mandatory.
This plugin apparently doesn't work with it.

Can agree. Same issue with git+https:// protocol.

@thalesmello I published ssh support to @zkochan/pnpm
Could you please check if it works for you? If yes, I'll merge and publish to pnpm.
@yunasc private modules can be accessed via https? Where are the tokens taken from?

@zkochan Worked perfectly! Great implementation, by the way 👍

I've stolen it from ied :-)
Landed in v0.35.0
@yunasc, for the https one lets create a new issue


QMC6310_GetDataExample compile on Arduino Nano

Following error occurs when trying to compile on an arduino nano
Where is ?
and how can I compile it with only the QMC6310 driver.
Arduino: 1.8.19 (Linux), Board: "Arduino Nano, ATmega328P (Old Bootloader)"
In file included from /home/ross/Arduino/libraries/SensorLib/src/bosch/BoschParse.cpp:30:0:
/home/ross/Arduino/libraries/SensorLib/src/bosch/BoschParse.h:36:10: fatal error: vector: No such file or directory
#include
^~~~~~~~
compilation terminated.
exit status 1
Error compiling for board Arduino Nano.

https://github.com/lewisxhe/SensorLib/blob/master/library.json#L30

As mentioned above


[⭐FEATURE] Add a Visitor Counter feature ✨

I want to add a Visitor Counter feature properly.
@ANSHIKA-26  PA please assign me this task.

@ANSHIKA-26

we tried this , didnt like it , it stood out from the whole website in a weird manner , so we dont want it anymore , thanks


Add a keyword macro arguments for triggering options

Rather than have a whole host of different macros for slightly different situations, we should use optional keyword arguments before the type declaration.  That is more extensible and permits us to export only one macro.
Some of the possible options:

cached=true - to compute the hash code at construction time and cache it in a "hidden" field.
althashname=MuttsDicts.mutts_hash - the name of the hash function to be implemented.
fields=(x, y) - define the set of fields that should participate in equality and hash.
reference=true - make the type a reference type, but make all of its fields const.  Requires Julia 1.8 or above.
nohash=true - to skip defining a hash code altogether Mutually exclusive with the althashname option.
noequals=true - to skip defining == altogether.  Mutually exclusive with the nohash option.

For example
@auto_hash_equals althashname=MuttsDicts.mutts_hash reference=true cached=true struct Pair
    x
    y
end

FYI: we've so far more or less been follow https://github.com/invenia/BlueStyle at RAI (though there's been discussion to switch to https://github.com/jrevels/YASGuide), and one of the things that it suggests, which I like, is to mostly avoid smooshedcase outside of Base. I think it's a particularly odd decision that Julia made, and that it's fine to leave it like that in Base, but that package code and application code should mostly prefer snake_case.
althashname triggered my 👀 as something that should probably be alt_hash_name 😊

For the other no* ones, i think it could be up to you.. i'd probably put an underscore there too, but i think reasonable people could disagree there :)

This seems like a good idea overall though, yeah!

Another option could be to have some sub-macros that users put on individual fields which your top-level struct macro could pick up. Like @nohash on a specific field or something. I think it's a matter of syntactic preference at that point.


Better handle 'pickle data was truncated' unpickling failures.

Solar Flare died unexpectedly today with an unpickling error regarding pickle data being truncated.  The only way to recover from this failure was to remove the offending pickle file, and restart the SmokeDetector instance.
We already restart Smokey on an unhandled exception such as this unpickling error, but because this issue persisted until we removed the file in the Solar Flare instance, and it caused a constant crashing problem/loop because a specific pickle had data truncated, it's better to capture this error and handle the pickle as we would an EOFError, which would remove the file and raise the error, triggering another restart without causing a constant crash loop like Solar Flare was having.

Coverage decreased (-0.1%) to 65.88% when pulling 49d0d15b51b995346a84482cc8ebf9cc3b2f5e74 on handle_unpickling_truncated_data into 06034afdc43ad314aa14d0acfecac3857479fffd on master.


[tool_crash] SocketException: Send failed, OS Error: No route to host, errno = 65

Command
flutter run

Steps to Reproduce

...
...
...

Logs
SocketException: Send failed, OS Error: No route to host, errno = 65
#0      _NativeSocket.send (dart:io-patch/socket_patch.dart:1275:34)
#1      _RawDatagramSocket.send (dart:io-patch/socket_patch.dart:2590:15)
#2      MDnsClient.lookup (package:multicast_dns/multicast_dns.dart:219:22)
#3      MDnsVmServiceDiscovery._pollingVmService (package:flutter_tools/src/mdns_discovery.dart:236:36)
<asynchronous suspension>
#4      MDnsVmServiceDiscovery.firstMatchingVmService (package:flutter_tools/src/mdns_discovery.dart:189:56)
<asynchronous suspension>
#5      MDnsVmServiceDiscovery.getVMServiceUriForLaunch (package:flutter_tools/src/mdns_discovery.dart:452:50)
<asynchronous suspension>
#6      Future.any.onValue (dart:async/future.dart:614:5)
<asynchronous suspension>

[✓] Flutter (Channel stable, 3.27.1, on macOS 15.2 24C101 darwin-arm64, locale en-US)
    • Flutter version 3.27.1 on channel stable at /Volumes/SANDISK/Development/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 17025dd882 (10 days ago), 2024-12-17 03:23:09 +0900
    • Engine revision cb4b5fff73
    • Dart version 3.6.0
    • DevTools version 2.40.2

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/zisuzlabs/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.11+0-17.0.11b1207.24-11852314)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 16.0)
    • Xcode at /Volumes/SANDISK/Xcode.app/Contents/Developer
    • Build 16A242d
    • CocoaPods version 1.15.2

[✗] Chrome - develop for the web (Cannot find Chrome executable at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome)
    ! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.

[✓] Android Studio (version 2024.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 17.0.11+0-17.0.11b1207.24-11852314)

[✓] Android Studio (version 2022.2)
    • Android Studio at /Users/zisuzlabs/Library/Application Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/222.4459.24.2221.10121639/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https:

Closing this as a duplicate of https://github.com/flutter/flutter/issues/150131


How to use world edit

Ik how to select blocks but how do i place those blocks that i have selected?

Skill issue

middle click and it will do the action using your held item, for example, holding dirt and changing tile action to place and then middle clicking will place dirt


⚠ Bofrost.at has degraded performance

In 8304563, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 5753 ms

Resolved: Bofrost.at performance has improved in 5b6327a after 6 minutes.


SW-17574 - Get customer scope from parent shop and limit to it

Questions
Answers

BC breaks?
no

Tests pass?
-

Related tickets?
SW-17574

How to test?
Setup shops as described in issue and register in language shops for both sub shops.

Thanks for your contribution @sobyte
I've scheduled your PR as it will take some time to test this issue in detail.

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/SW-17623.
Please use this issue to track the state of your pull request.

Hi @janbuecker, any updates on this issue?

Hi @sobyte,
Thanks for your pull request.
The changes will be available in version 5.3.5.


bug: compound conditions in where clause referencing same column name only register the last condition

$db->debug()->select("tablename", [ "id", "status" ],
[ "AND" => [ "OR" => [ "status" => "STATUS1" , "status" => "STATUS2" ],  "ID" => "7"]]);
produces:
SELECT "id","status" FROM "tablename"
WHERE ("status" = 'STATUS2') AND "ID" = '7'
The first OR condition ( "status" => "STATUS1"  ) gets lost.  I assume it's because the OR statement is referencing the same column name ("status") more than once and it's only remembering the last one it saw.   Probably an associative array key issue when building the where clause.

You cannot use the same key twice in PHP Associated-Array.
Try this
$db->debug()->select("tablename", [ "id", "status" ], [
         "AND" => [
            "status" => ["STATUS1" , "STATUS2" ],
            "ID" => "7"
        ]
    ]
);

perfect!  thanks