Multiline text up/down arrow navigation doesn't work on iOS hardware keyboards

Steps to Reproduce
void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  final controller = TextEditingController(
    text: 'This\nspans\nmultiple\nlines',
  );

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Demo',
      home: Scaffold(
        body: Padding(
          padding: const EdgeInsets.all(20.0),
          child: TextField(
            maxLines: 10,
            controller: controller,
          ),
        ),
      ),
    );
  }
}

Run the above app code on iOS with hardware keyboard connected
Press up/down arrow keys to navigate the multi-line text

Expected results: Should move cursor up/down lines of text. This expected behavior can be observed in iOS apps like Notes or Safari.
Actual results: Moves cursor left/right one position (same behavior as pressing left/right arrow keys).
Flutter seems to support up/down arrow navigation for RawKeyboard (desktop/web I'm assuming) but not iOS hardware keyboards (they don't trigger RawKeyboard events).
https://github.com/flutter/flutter/blob/e481fcae528ef65de8d689213a710d567c7ab3ca/packages/flutter/lib/src/rendering/editable.dart#L510
It doesn't look like there are any ways to intercept arrow keys on iOS hardware keyboards in Flutter. Please correct me if I'm wrong.

Logs

flutter doctor -v
[✓] Flutter (Channel master, v1.15.4-pre.47, on Mac OS X 10.15.3 19D76, locale en-US)
    • Flutter version 1.15.4-pre.47 at /Users/gschier/.flutter-sdk
    • Framework revision b2b97c2a7e (3 days ago), 2020-02-12 17:18:09 -0800
    • Engine revision e0ebaea590
    • Dart version 2.8.0 (build 2.8.0-dev.9.0 e4c39721c4)

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.0)
    • Android SDK at /Users/gschier/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-29, build-tools 29.0.0
    • ANDROID_HOME = /Users/gschier/Library/Android/sdk
    • ANDROID_SDK_ROOT = /Users/gschier/Library/Android/sdk
    • Java binary at: /Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/bin/java
    • Java version Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.3.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.3.1, Build version 11C504
    • CocoaPods version 1.8.4

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

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

[✓] IntelliJ IDEA Ultimate Edition (version 2019.3.3)
    • IntelliJ at /Users/gschier/Applications/JetBrains Toolbox/IntelliJ IDEA Ultimate.app
    • Flutter plugin version 43.0.3
    • Dart plugin version 193.5731

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

[✓] Connected device (4 available)
    • Gregory Schier’s iPad • xxx • ios            • iOS 13.3.1
    • macOS                 • macOS                     • darwin-x64     • Mac OS X 10.15.3 19D76
    • Chrome                • chrome                    • web-javascript • Google Chrome 79.0.3945.130
    • Web Server            • web-server                • web-javascript • Flutter Tools

HI @gschier
just tested on ipad emulator
[✓] Flutter (Channel beta, v1.14.6, on Mac OS X 10.15.3 19D76, locale en-EE)
    • Flutter version 1.14.6 at /Users/nevercode/development/flutter
    • Framework revision fabeb2a16f (3 weeks ago), 2020-01-28 07:56:51 -0800
    • Engine revision c4229bfbba
    • Dart version 2.8.0 (build 2.8.0-dev.5.0 fc3af737c7)

C[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    • Android SDK at /Users/nevercode/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling
      support)
    • Platform android-29, build-tools 29.0.2
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_202-release-1483-b49-5587405)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.3.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.3.1, Build version 11C504
    • CocoaPods version 1.8.4

[✓] Android Studio (version 3.5)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 43.0.1
    • Dart plugin version 191.8593
    • Java version OpenJDK Runtime Environment (build
      1.8.0_202-release-1483-b49-5587405)

[✓] VS Code
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.8.1

[✓] Connected device (1 available)
    • iPad Air (3rd generation) • 609AAB06-1510-466F-82F8-1951E7EAFCD2 • ios •
      com.apple.CoreSimulator.SimRuntime.iOS-13-3 (simulator)

I can confirm that arrow_up from the keyboard moves the cursor back and not on the line above
(same for down/forward),
note that moves only once and then stops,
moves again only after another "change" has happened
Apparently uninteresting logs attached.
Thank you
ipad_textfield.txt

Thanks for taking the time to reproduce that @iapicca 🙂

CC @justinmc

Software up/down keys don't work right now either.  There is a PR open that issue that might fix this one too if we're lucky.  It listens for KEYCODE_DPAD_UP and KEYCODE_DPAD_DOWN. https://github.com/flutter/engine/pull/15560

That does seem like it could be related since iPad keyboards seem to register the same as a software keyboard.
It's strange though because other hardware keyboard navigation works. For example, skipping left/right by word boundary when holding Option.

I missed the fact that that PR is Android-only, so it won't have any effect here.  Could be a similar solution needed here, though.

cc @gspencergoog  Do you have any ideas off the top of your head?

I can reproduce the issue
When pressing Up/Down arrows (Not left/right) keys using Apple magic keyboard on XR  via Bluetooth

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

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  final controller = TextEditingController(
    text: 'This\nspans\nmultiple\nlines',
  );

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Demo',
      home: Scaffold(
        body: Padding(
          padding: const EdgeInsets.all(20.0),
          child: TextField(
            maxLines: 10,
            controller: controller,
          ),
        ),
      ),
    );
  }
}

flutter doctor -v
[✓] Flutter (Channel master, 1.22.0-10.0.pre.317, on Linux, locale en_US.UTF-8)
    • Flutter version 1.22.0-10.0.pre.317 at /home/taha/Code/flutter_master
    • Framework revision 10febea877 (6 hours ago), 2020-09-23 07:22:10 +0200
    • Engine revision 57ee3d4b32
    • Dart version 2.10.0 (build 2.10.0-156.0.dev)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
    • Android SDK at /home/taha/Code/sdk
    • Platform android-30, build-tools 30.0.2
    • ANDROID_HOME = /home/taha/Code/sdk
    • Java binary at: /home/taha/Code/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Chrome - develop for the web
    • Chrome at google-chrome

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

[✓] Android Studio (version 4.0)
    • Android Studio at /home/taha/Code/android-studio
    • Flutter plugin version 49.0.2
    • Dart plugin version 193.7547
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6222593)

[✓] VS Code (version 1.49.1)
    • VS Code at /usr/share/code
    • Flutter extension version 3.14.1

[✓] Connected device (3 available)
    • Linux (desktop)  • linux      • linux-x64      • Linux
    • Web Server (web) • web-server • web-javascript • Flutter Tools
    • Chrome (web)     • chrome     • web-javascript • Google Chrome
      85.0.4183.102

• No issues found!

I am having the same problem with my iPad pro 2018 12 inch + folio keyboard

@TahaTesser Do you still have the Apple keyboard available to test this?  If it's not too much trouble, let me know if this bug is still happening.  Lots has changed with our keyboard shortcuts and I'm hoping this issue is fixed.

@justinmc
Now I can see up/down arrow navigation works as expected (master channel)
Device information
iPhone XR (iOS 16 beta)
Apple Magic Keyboard (Bluetooth)
https://user-images.githubusercontent.com/48603081/179183204-36cf4a90-6d8d-4bc3-8b9b-bcf28d525473.MP4

Code Sample
import 'package:flutter/material.dart';

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

class MyApp extends StatelessWidget {
  const MyApp({super.key, this.dark = true, this.useMaterial3 = true});

  final bool dark;
  final bool useMaterial3;

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      debugShowCheckedModeBanner: false,
      themeMode: dark ? ThemeMode.dark : ThemeMode.light,
      theme: ThemeData(
        useMaterial3: useMaterial3,
        brightness: Brightness.light,
        colorSchemeSeed: const Color(0xff6750a4),
      ),
      darkTheme: ThemeData(
        useMaterial3: useMaterial3,
        brightness: Brightness.dark,
        colorSchemeSeed: const Color(0xff6750a4),
      ),
      home: const Example(),
    );
  }
}

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

  @override
  State<Example> createState() => _ExampleState();
}

class _ExampleState extends State<Example> {
  final TextEditingController controller = TextEditingController(
    text: 'This\nspans\nmultiple\nlines',
  );

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Demo',
      home: Scaffold(
        body: SafeArea(
          child: Padding(
            padding: const EdgeInsets.all(20.0),
            child: TextField(
              maxLines: 10,
              controller: controller,
              style: const TextStyle(
                fontSize: 40.0,
                color: Colors.black,
              ),
              decoration: const InputDecoration(
                border: OutlineInputBorder(),
                labelText: 'TextField',
              ),
            ),
          ),
        ),
      ),
    );
  }
}

flutter doctor -v
[!] Flutter (Channel master, 3.1.0-0.0.pre.1669, on macOS 12.4 21F79 darwin-arm,
    locale en-GB)
    • Flutter version 3.1.0-0.0.pre.1669 on channel master at
      /Users/tahatesser/Code/flutter
    ! Upstream repository git@github.com:NevercodeHQ/flutter.git is not a
      standard remote
    • Framework revision 30eba39bba (46 minutes ago), 2022-07-15 03:34:06 -0400
    • Engine revision 41351f4a2a
    • Dart version 2.18.0 (build 2.18.0-283.0.dev)
    • DevTools version 2.15.0

[✓] Android toolchain - develop for Android devices (Android SDK version
    32.1.0-rc1)
    • Android SDK at /Users/tahatesser/Code/android-sdk
    • Platform android-32, build-tools 32.1.0-rc1
    • ANDROID_SDK_ROOT = /Users/tahatesser/Code/android-sdk
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      11.0.12+0-b1504.28-7817840)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.0)
    • Xcode at /Applications/Xcode-beta.app/Contents/Developer
    • Build 14A5270f
    • CocoaPods version 1.11.3

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

[✓] Android Studio (version 2021.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
    • Java version OpenJDK Runtime Environment (build
      11.0.12+0-b1504.28-7817840)

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

[✓] Connected device (3 available)
    • Taha’s iPhone (mobile) • 00008020-001059882212002E • ios            • iOS
      16.0 20A5283p
    • macOS (desktop)        • macos                     • darwin-arm64   •
      macOS 12.4 21F79 darwin-arm
    • Chrome (web)           • chrome                    • web-javascript •
      Google Chrome 103.0.5060.114
    ! Error: Taha’s Apple Watch has not finished loading development services.
      Please select a different device, or wait for the device to load
      development services and try again. (code 8)

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

! Doctor found issues in 1 category.

Closing as fixed

@TahaTesser Awesome, thank you for checking!


End reddit spam by making PoliteUsersBot run on a subreddit whitelist

Reading the collection of reactions and proposals in the announcement thread for PoliteUsersBot there were two popular proposals:

Delete the bot (supported by /u/kylegetsspam, /u/Mynameisnotdoug, /u/_Averix, and others)
Use a subreddit white list (supported by  /u/svavil, /u/Spritetm and others)

This pull request implements option #2 (white list) and pre-populates the white-list with a list of subreddits that have shown interest in having this bot.

Pull request denied, blacklist implemented.


Fix a bug that does not predict the level in Level Progress Visualizer correctly

I've noticed it yesterday when I did many giveaways and I'm noticing it again today while again having many open giveaways. I'm taking screenshots to document the issue.
After all new giveaways were set up and ESGST was freshly synced, the prediction was just at about the closing parenthesis. This is how things changed from there over the last hour:
Change 1: https://i.imgur.com/mRuj0ML.jpg
Change 2: https://i.imgur.com/eHiASXo.jpg
Change 3: https://i.imgur.com/2qRGT0w.jpg
Change 4: https://i.imgur.com/v9MrYQf.jpg
I'll add new screenshots since I expect it to go down quite a lot again since that's what happened yesterday.

I can't really visualize anything with those screenshots, can you post numbers? Do you have ended giveaways that have changed status in this time?

Not sure what you mean you can't visualize anything - the light green bar is what's moving upwards although it shouldn't. That's mainly what I'm talking about (which can be seen in the screenshot).
I can't provide more than the screenshot. I can watch the predicted number from now on. Right now it's 6.49 (7.02).
Yes, during the first three screenshots I had giveaways ending - none ended after third screenshot was taken though.
I would assume that the prediction runs into problems when it adds the prediction (the length of the light green bar) to the current progress (dark green bar). It should reduce the length of the light green bar when keys are marked as received while the same amount is added to the dark green bar.
I've just checked again while writing this, now the numbers are 6.50 (7.03).
So while the dark green bar gets longer as keys get marked as received, the light green one doesn't get shorter and therefore displays a higher prediction than actually expected.
Just checked again, now the numbers are 6.52 (7.05)
I synced ESGST and the numbers are now 6.52 (7.07) - with no new giveaways added.

I mean that the bar is irrelevant, the numbers are what's important. And to visualize any changes in the bar I have to open all your screenshots and put them side by side to see anything changing. With the numbers I don't have to open anything.

But the bar visualizes everything. If it's irrelevant, it shouldn't be there.
(Neither bar has moved much.) Updated numbers:
6.57 (6.98)
So once again, the prediction went up while it shouldn't - ESGST is freshly synced.

Numbers are now 6.59 (6.97)

The bar is irrelevant because it is based off the numbers, so there's no point in posting screenshots to the bar when the numbers already have all the information.

Can you run this in the console and post the output? console.log(localStorage.esgst_lpvCache);

{"games":{"apps":{"18480":10,"63110":10,"205730":15,"260270":10,"260550":15,"266940":7,"286500":10,"302110":15,"302120":10,"308320":20,"308330":10,"320970":20,"322040":15,"328870":20,"328880":10,"343990":10,"344030":10,"344790":10,"344800":20,"344810":20,"349760":5,"356160":10,"366700":4,"372260":20,"378510":15,"392780":5,"392810":4,"397440":15,"398620":20,"398630":20,"399100":2,"413460":20,"422130":20,"422140":20,"432760":15,"432770":10,"461850":10,"465340":1,"466830":8,"484830":3,"489200":2,"502150":1,"526830":2,"574580":2,"655630":4,"656680":8,"662780":5,"676760":3,"681550":5,"683530":2,"705050":8,"707920":10,"710880":8,"711530":2,"713440":5,"718210":5,"724010":4,"725020":3,"726260":4,"729670":8,"729690":1,"731500":7,"739800":3,"745550":5,"746350":1,"759010":9,"763320":13,"764110":2,"765380":5,"775790":6,"786560":1},"subs":{}},"giveaways":["JzjqP","WfXoF","vAPE7","cfz9s","TXM01","rRqzy","iKreg","GNl9T","C0KyT","DZiE2","3PraR","Q1Rsf","lJh99","QAEwD","WCfvy","8cODH","jzLuN","iGDmP","Ic0kA","VhzmZ","PHL96"],"timestamp":1520030027352} undefined

Update: 6.63 (6.96) - again, this is after syncing ESGST.

New numbers in the morning, after syncing ESGST:
6.70 (6.83)

I can't tell, I currently have no open Giveaways.

I did some test giveaways during March 22-27 and then forgot to post the results here about it, but it was also an issue for me. Haven't done giveaways since than so I can't tell if it still exists, but definitely Eiion was not the only one affected.

Just noticed that's while my giveaways still were running/not marked as received, yet, the prediction went up to 7.09. Now that everything is actually marked as received I am at 7.07.

I'm currently running a 50 giveaways train and trying to document the Visualizer's behavior over the course of it. Once all of the giveaways are received I'll post the whole thing here ;)

Ok, my train(https://www.steamgifts.com/giveaway/8wbCc/cortex-command) finished running, so it's time for my report ;)
I don't know if the thing affects Level Progress Visualizer, but I think I should let you know that I usually don't do manual syncs of anything, but have an automatic sync syncing all of the possible stuff once a week (every Sunday afternoon). I will point out when exactly the syncs happened in relation to everything else.

Saturday evening. This is how it looked like before I created any of the giveaways.

2. This is after I scheduled all of the giveaways for the next day. There were 50 giveaways containing 66 Steam keys.

3. Sunday afternoon. All of the giveaways started running, then automatic sync happened and then I took the screenshot. I don't which one of these two things caused the bar to disappear.

4. Sunday evening the next week. The train stopped running. One of the DLC giveaways didn't get any entries, so in the end I had to deliver 49 giveaways containing 65 Steam keys. I took the screenshot after the sync, after sending 20 Steam keys and something already got received (my level increased to 6.18). For some reason the level estimate increased significantly.

5. Monday. I've sent all of the Steam keys and around 1/4th of them are marked as received.

6. Still Monday. Around 80% received.

7. Tuesday. 4 not received.

8. Wednesday. 1 not received and the bar disappeared again???

9. Monday (5 days later). Automatic sync happened on Sunday and the last giveaway has been received (not sure which of these happened first).

I've done a manual sync on Monday to see if the bar will disappear, but it didn't and it still looks the same as on the image 9. It shouldn't be like that...

So that's it for this time. Hope this data helps you to fix the Level Progress Visualizer. If you want me to make another test gathering some other stats or info just let me know since I have one more giveaway spree prepared ;)

Thanks. Your data clearly shows that the feature correctly predicts the results at the beginning. Here it predicted 6.84 and you ended up at 6.82.
The problem with the middle predictions is that it's impossible for the feature to know if a giveaway ended and was marked an received without syncing. So it continues to estimate the initial estimates until you sync. For example, you were at 6.17 and it predicted 6.84, so an increase of 0.67. On 4, since you went up to 6.18, the feature should predict 6.85 if you didn't sync and gone back to 6.84 after you synced.
I think the issue here is with the sync. Something's happening there that is both counting more giveaways than it should and not going back to the initial prediction after giveaways were marked as received.
But your data might be helpful for me to figure out where the error is coming from. I hope to work on it soon.

Well, not syncing is a problem with Pietruszek's data but opposed to him I did synchronize manually before taking any of the screenshots or writing down numbers. I always do that to make sure it's not an issue of not up to date data. So it seems that it is - if at all - only part of the problem.

Ok, I completely changed how the system works. Now instead of keeping track of the giveaways, it simply keeps track of the numbers. This could lead to some small differences between the predictions and the final results if the values change a lot during that time, but in most cases it should work well. And this new system doesn't require you to sync all the time.
The examples below illustrates how the new system works (or is supposed to work):

Your level is 5.15. The system predicts your level will be 5.50 when your giveaways end. That's a difference of 5.50 - 5.15 = 0.35.
Some of your giveaways end. Your level is now 5.20. The system sees that your level increased by 5.20 - 5.15 = 0.05 and subtracts that from the difference, which then becomes 0.35 - 0.05 = 0.30. So the system continues to predict that your level will be 5.20 + 0.30 = 5.50.
All of your giveaways end. Your level is now the predicted level 5.50. The system sees that your level increased by 5.50 - 5.20 = 0.30 and subtracts that from the difference, which then becomes 0.30 - 0.30 = 0. The system continues to predict that your level will be 5.50 + 0 = 5.50.

To reset the increase value you can sync your giveaways, so if you synced after example 2, the increase value would have gone from 0.05 to 0, which wouldn't have affected anything, because since the giveaways that amounted to that increase would have ended, the difference would have remained 0.30.
Please let me know if it's working correctly for you guys when I release the next version later today.

Ok, new version is up.

Sounds exactly the way I thought it should be. I'll create some giveaways soon to test it out.

Please post the output of this from the console: console.log(JSON.stringify(localStorage.esgst_lpvCache));

VM897:1 "{\"difference\":0,\"level\":7.07}"
undefined

Could be an issue with the rounding up because of the extremely low difference.

Seems like the issue still exists. My predicted level went down from 7.19 to 7.18 after the giveaways ended and one person marked as received.
Right now: 7.11 (7.18)

And now it's:
7:13 (7.15)

Now it just says 7.13 - without any further prediction, although there's still plenty of giveaways not marked as received, yet.

And I'm at 7.14 without further prediction though 4 games still need to be marked as received.

New giveaways: 7.15 (7.18)

after 4 already ended, 2 marked as received: 7.15 (7.16)

Now: 7.17 (7.18)

With 129 running giveaways right now it says "7.22 (7.4)". Looking forward to see what it says once everyone has marked their wins as received.

Ok, will finally look into this today. It would be helpful if @Pietruszek could tell us if the system worked correctly for them.

By the way, did you sync at any point between the predictions?

Please also make sure to post the result from console.log(JSON.stringify(localStorage.esgst_lpvCache)); whenever you post a new prediction.

After a first look, I couldn't find anything wrong with the logic in the script.
I'll need more information, because the posts you made above are unfortunately not helpful at all without the results from console.log(JSON.stringify(localStorage.esgst_lpvCache));
Also make sure that your Reduced CV Games and No CV Games lists are synced, as that has influence over the prediction levels. And if you made giveaways for games that give no CV that are not in the database, that will influence the prediction as well.
It would also be nice if you could report the level that you end up at, after all of the giveaways have ended and been marked as received, because that way we can compare how off the initial prediction was in comparison to your final level.

I think I might be able to contribute a bit here.
I have 4 ongoing GAs, three for reduced CV games (62P total) and one for a full CV game (10P). I didn't feel like grabbing the exact values in USD but the points serve as good enough approximation.
I'm level 3.63 (still sad about the drop from level 4, lol). My lower level means that any change is far more obvious. I did some quick math and apparently I'll very barely hit 4.00 (I think not even 4.01) when those GAs are all over. If all four GAs were full CV, I'd reach level 4.21. The level progress visualizer thinks I'll be level 4.23.
It seems fairly clear that the calculator is ignoring the fact that some games are reduced CV (and the same might hold for no CV), despite the fact the game categories feature is showing "Reduced CV" in my GAs page (and so the script does know that they're reduced CV).
There might something else also at play, because not even with full CV and rounding numbers up I could possibly reach 4.23 with the current GAs. The current level is correctly calculated, though (and this is probably not very important) the display on my profile is slightly off (it says "~$18.5 real CV to level 4", when it's closer to ~18.7; more precisely, the current sent CV provided by SG itself is 81.31). Whatever the case, that difference seems a lot less relevant then the full CV one and could even be caused by rounding somewhere.

Yes I've synced though the (compared to before) changed prediction didn't change afterwards.
Today the 129 giveaways have ended and with most of them still waiting for being marked as received it's currently at "7.32" without a prediction from the previous "7.22 (7.4)".
console.log(JSON.stringify(localStorage.esgst_lpvCache)); VM541:1 "{\"difference\":0.1,\"level\":7.32}"

v8.0.0 includes a detailed log of the CV calculation.

There are a bunch of zero-CV adds that I removed from the log for readability because they weren't important (I can include those as well if you want, but there's really no point). Here's the stripped-down version:
Adding 2.1 CV from :http://store.steampowered.com/app/266940
Total CV: 2.1
Adding 6 CV from :http://store.steampowered.com/app/320970
Total CV: 8.1
Adding 4.5 CV from :http://store.steampowered.com/app/344810
Total CV: 12.6
Adding 6 CV from :http://store.steampowered.com/app/422140
Total CV: 18.6
Adding 2.1 CV from :http://store.steampowered.com/app/625910
Total CV: 20.700000000000003
CV calculation ended...
Final CV calculated: 20.700000000000003
Predicted level without difference: 4.7
Difference: 0
Final predicted level: 4.7

I did make GAs for all those five games, but the first four ended almost two weeks ago and were marked received within a day or two. Only the last one is actually still pending. I've also made other GAs since then, but they're not adding extra CV there.

What results do you get if you sync your won games in the settings menu?

Same, still those same five games generating CV.

Sorry, I meant to sync your giveaways.

I sync everything every time, so same answer. :) In fact, I also sync everything daily with the automatic sync, and I also sync everything automatically any time I manually sync SG itself (which I do after receiving games, after wishlisting games, etc).

Please see if the issue still happens in v8.1.2.

It was still happening with the version I've used before (8.0.3). Now I've just updated to 8.1.3 (Dev.8).
Currently it's 7.41 (7.5) - tomorrow I have 9 giveaways ending, though I don't know if that's enough to have anything change at all. We'll see. I'll definitely be able to tell on 25th december as I have at least 73 of my giveaways end that day.

If it happens again, try re-scanning your profile with User Giveaway Data and "Clear cache." enabled. Then see if it happens after that.

I just did that and the prediction fell from 7.5 to 7.49.

Ok, let's see where you actually end up.

Currently I'm at 7.54 - prediction for new giveaways is 7.61
I'll update.

Also make sure to check the logs, as they indicate exactly how much each giveaway is adding (useful to know if any differences are related to reduced CV / no CV not being synced).

Something odd happened - I went up to 7.55. I can only assume that a once removed game got added back to the database. The prediction is still the same.
Here's the current log:
Beginning CV calculation...
esgst.js:1 Adding 1.5 CV from :http://store.steampowered.com/app/259740
esgst.js:1 Total CV: 1.5
esgst.js:1 Adding 1.5 CV from :http://store.steampowered.com/app/284730
esgst.js:1 Total CV: 3
esgst.js:1 Adding 1.05 CV from :http://store.steampowered.com/app/289260
esgst.js:1 Total CV: 4.05
esgst.js:1 Adding 0.75 CV from :http://store.steampowered.com/app/323250
esgst.js:1 Total CV: 4.8
esgst.js:1 Adding 0.75 CV from :http://store.steampowered.com/app/323270
esgst.js:1 Total CV: 5.55
esgst.js:1 Adding 0.75 CV from :http://store.steampowered.com/app/323280
esgst.js:1 Total CV: 6.3
esgst.js:1 Adding 1.05 CV from :http://store.steampowered.com/app/342630
esgst.js:1 Total CV: 7.35
esgst.js:1 Adding 1.5 CV from :http://store.steampowered.com/app/369420
esgst.js:1 Total CV: 8.85
esgst.js:1 Adding 2.25 CV from :http://store.steampowered.com/app/379960
esgst.js:1 Total CV: 11.1
esgst.js:1 Adding 0.75 CV from :http://store.steampowered.com/app/383700
esgst.js:1 Total CV: 11.85
esgst.js:1 Adding 10 CV from :http://store.steampowered.com/app/402300
esgst.js:1 Total CV: 21.85
esgst.js:1 Adding 1.5 CV from :http://store.steampowered.com/app/403510
esgst.js:1 Total CV: 23.35
esgst.js:1 Adding 1.5 CV from :http://store.steampowered.com/app/495110
esgst.js:1 Total CV: 24.85
esgst.js:1 Adding 1.05 CV from :http://store.steampowered.com/app/550390
esgst.js:1 Total CV: 25.900000000000002
esgst.js:1 Adding 1.5 CV from :http://store.steampowered.com/app/558340
esgst.js:1 Total CV: 27.400000000000002
esgst.js:1 Adding 1.5 CV from :http://store.steampowered.com/app/574260
esgst.js:1 Total CV: 28.900000000000002
esgst.js:1 Adding 1.05 CV from :http://store.steampowered.com/app/586930
esgst.js:1 Total CV: 29.950000000000003
esgst.js:1 Adding 1.05 CV from :http://store.steampowered.com/app/677220
esgst.js:1 Total CV: 31.000000000000004
esgst.js:1 Adding 0.75 CV from :http://store.steampowered.com/app/699160
esgst.js:1 Total CV: 31.750000000000004
esgst.js:1 Adding 2.25 CV from :http://store.steampowered.com/app/740090
esgst.js:1 Total CV: 34
esgst.js:1 Adding 2.25 CV from :http://store.steampowered.com/app/756500
esgst.js:1 Total CV: 36.25
esgst.js:1 Adding 2.25 CV from :http://store.steampowered.com/app/762520
esgst.js:1 Total CV: 38.5
esgst.js:1 Adding 20 CV from :http://store.steampowered.com/app/766370
esgst.js:1 Total CV: 58.5
esgst.js:1 Adding 2 CV from :http://store.steampowered.com/app/835040
esgst.js:1 Total CV: 60.5
esgst.js:1 Adding 2 CV from :http://store.steampowered.com/app/908350
esgst.js:1 Total CV: 62.5
esgst.js:1 Adding 6 CV from :http://store.steampowered.com/app/953170
esgst.js:1 Total CV: 68.5
esgst.js:1 Adding 6 CV from :http://store.steampowered.com/app/953190
esgst.js:1 Total CV: 74.5
esgst.js:1 CV calculation ended...
esgst.js:1 Final CV calculated: 74.5
esgst.js:1 Predicted level without difference: 7.62
esgst.js:1 Difference: 0.01
esgst.js:1 Final predicted level: 7.61

I had to delete 10 of the giveaways. I already re-did them - so the prediction should be the same as before... well, at least once all winners of the already ended GAs have marked them as received.
Right now I'm at 7.57 - but although there's 10 GAs open, the prediction is still 7.57 even after synching. I find that quite odd.
Here's the current log:
Beginning CV calculation...
esgst.js:1 Adding 1.5 CV from :http://store.steampowered.com/app/259740
esgst.js:1 Total CV: 1.5
esgst.js:1 Adding 1.05 CV from :http://store.steampowered.com/app/289260
esgst.js:1 Total CV: 2.55
esgst.js:1 Adding 0.75 CV from :http://store.steampowered.com/app/323250
esgst.js:1 Total CV: 3.3
esgst.js:1 Adding 0.75 CV from :http://store.steampowered.com/app/323270
esgst.js:1 Total CV: 4.05
esgst.js:1 Adding 0.75 CV from :http://store.steampowered.com/app/323280
esgst.js:1 Total CV: 4.8
esgst.js:1 Adding 1.05 CV from :http://store.steampowered.com/app/342630
esgst.js:1 Total CV: 5.85
esgst.js:1 Adding 1.5 CV from :http://store.steampowered.com/app/495110
esgst.js:1 Total CV: 7.35
esgst.js:1 Adding 1.05 CV from :http://store.steampowered.com/app/550390
esgst.js:1 Total CV: 8.4
esgst.js:1 Adding 1.05 CV from :http://store.steampowered.com/app/586930
esgst.js:1 Total CV: 9.450000000000001
esgst.js:1 CV calculation ended...
esgst.js:1 Final CV calculated: 9.450000000000001
esgst.js:1 Predicted level without difference: 7.57
esgst.js:1 Difference: 0
esgst.js:1 Final predicted level: 7.57

It appears to be calculating the CV for your 10 open giveaways correctly, but since they give very few CV it doesn't increase the prediction.
The issue seems to be that it's not retaining the calculation for the ended giveaways.

So, the previous prediction of 7.57 was wrong and the one before that of 7.61 was also wrong - after everything is marked as received I ended up at 7.60.
I guess my level is to high already to see even bigger differences in prediction and actual level.

Currently at 7.71, prediction of 7.76. Plenty of giveaways ending today and tomorrow - 29 of which multi-key ones. We'll see.

I'm still missing 39 received markers but my actual level is already up to 7.82. Because of that I'm assuming that multiple key giveaways are a problem for the level prediction.
Though that doesn't seem the be the general problem that we're trying to figure out, as typically I don't do multi-key GAs.

The small differences in the prediction is just a rounding issue. For example, when you said that the feature predicted 7.61 and you ended up at 7.60.
This is also a problem with Level Up Calculator. I've sent $1533.85 real CV. That would represent (1533.85 - 1000.01) / 1000 = 0.53384. But my SteamGifts level is 7.53. If you calculate the real CV from 7.53, you have 1000.01 + (0.53 * 1000) = 1530.01, which is not completely accurate.
I'll see if I can modify ESGST to handle these rounding issues.
As to the feature not counting multiple keys, I don't see how that could happen, but I'll look into it as well.

Can you test the latest pre-release? I made some changes to the feature.

And please report the console log as well.

I've fully moved to the extension. If there's a way to check the dev version, I'll do it. I currently only have 4 giveaways running though so that doesn't do much with seeing differences in the first place.

There doesn't seem to be a way to do that easily on Chrome. I'll try to release the next version until the weekend.

Ok

Plenty of giveaways ending today, currently at 7.92 with prediction of 8.05.

It's currently bugged, so there's no need to track it. We'll do it in the next version.

Ok, new version is up. Let's see how it goes now.

Well, after the last prediction I ended up at 7.95.
Today 4 more giveaways ended starting at 7.95 and a prediction of 7.99 - which already seems WAY off.
This is the calculation while only two giveaways (one of the new ones, one from three days ago) are not marked as received, yet:
Beginning CV calculation... esgst.js:100 Adding 1.5 CV from :http://store.steampowered.com/app/259740 esgst.js:100 Total CV: 1.5 esgst.js:100 Adding 1.05 CV from :http://store.steampowered.com/app/289260 esgst.js:100 Total CV: 2.55 esgst.js:100 Adding 0.75 CV from :http://store.steampowered.com/app/323250 esgst.js:100 Total CV: 3.3 esgst.js:100 Adding 0.75 CV from :http://store.steampowered.com/app/323270 esgst.js:100 Total CV: 4.05 esgst.js:100 Adding 3.375 CV from :http://store.steampowered.com/app/328600 esgst.js:100 Total CV: 7.425 esgst.js:100 Adding 1.05 CV from :http://store.steampowered.com/app/342630 esgst.js:100 Total CV: 8.475 esgst.js:100 Adding 6 CV from :http://store.steampowered.com/app/354160 esgst.js:100 Total CV: 14.475 esgst.js:100 Adding 1.5 CV from :http://store.steampowered.com/app/359650 esgst.js:100 Total CV: 15.975 esgst.js:100 Adding 1.5 CV from :http://store.steampowered.com/app/364800 esgst.js:100 Total CV: 17.475 esgst.js:100 Adding 2.25 CV from :http://store.steampowered.com/app/390720 esgst.js:100 Total CV: 19.725 esgst.js:100 Adding 2.025 CV from :http://store.steampowered.com/app/481190 esgst.js:100 Total CV: 21.75 esgst.js:100 Adding 2.25 CV from :http://store.steampowered.com/app/494100 esgst.js:100 Total CV: 24 esgst.js:100 Adding 1.5 CV from :http://store.steampowered.com/app/495110 esgst.js:100 Total CV: 25.5 esgst.js:100 Adding 0.3 CV from :http://store.steampowered.com/app/496530 esgst.js:100 Total CV: 25.8 esgst.js:100 Adding 0.3 CV from :http://store.steampowered.com/app/500120 esgst.js:100 Total CV: 26.1 esgst.js:100 Adding 0.44999999999999996 CV from :http://store.steampowered.com/app/522830 esgst.js:100 Total CV: 26.55 esgst.js:100 Adding 1.05 CV from :http://store.steampowered.com/app/536450 esgst.js:100 Total CV: 27.6 esgst.js:100 Adding 1.05 CV from :http://store.steampowered.com/app/550390 esgst.js:100 Total CV: 28.650000000000002 esgst.js:100 Adding 1.05 CV from :http://store.steampowered.com/app/586930 esgst.js:100 Total CV: 29.700000000000003 esgst.js:100 Adding 0.44999999999999996 CV from :http://store.steampowered.com/app/658880 esgst.js:100 Total CV: 30.150000000000002 esgst.js:100 Adding 1.2 CV from :http://store.steampowered.com/app/713180 esgst.js:100 Total CV: 31.35 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/722050 esgst.js:100 Total CV: 31.5 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/735520 esgst.js:100 Total CV: 31.65 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/735530 esgst.js:100 Total CV: 31.799999999999997 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/749670 esgst.js:100 Total CV: 31.949999999999996 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/752700 esgst.js:100 Total CV: 32.099999999999994 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/761100 esgst.js:100 Total CV: 32.24999999999999 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/761660 esgst.js:100 Total CV: 32.39999999999999 esgst.js:100 Adding 0.3 CV from :http://store.steampowered.com/app/763090 esgst.js:100 Total CV: 32.69999999999999 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/764490 esgst.js:100 Total CV: 32.84999999999999 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/770400 esgst.js:100 Total CV: 32.999999999999986 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/775720 esgst.js:100 Total CV: 33.149999999999984 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/775730 esgst.js:100 Total CV: 33.29999999999998 esgst.js:100 Adding 0.75 CV from :http://store.steampowered.com/app/776720 esgst.js:100 Total CV: 34.04999999999998 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/800320 esgst.js:100 Total CV: 34.19999999999998 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/800330 esgst.js:100 Total CV: 34.34999999999998 esgst.js:100 Adding 0.3 CV from :http://store.steampowered.com/app/810680 esgst.js:100 Total CV: 34.64999999999998 esgst.js:100 Adding 0.44999999999999996 CV from :http://store.steampowered.com/app/810720 esgst.js:100 Total CV: 35.09999999999998 esgst.js:100 Adding 0.44999999999999996 CV from :http://store.steampowered.com/app/810740 esgst.js:100 Total CV: 35.54999999999998 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/812850 esgst.js:100 Total CV: 35.69999999999998 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/812860 esgst.js:100 Total CV: 35.84999999999998 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/821860 esgst.js:100 Total CV: 35.99999999999998 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/821910 esgst.js:100 Total CV: 36.14999999999998 esgst.js:100 Adding 0.44999999999999996 CV from :http://store.steampowered.com/app/829560 esgst.js:100 Total CV: 36.59999999999998 esgst.js:100 Adding 0.75 CV from :http://store.steampowered.com/app/838840 esgst.js:100 Total CV: 37.34999999999998 esgst.js:100 Adding 0.3 CV from :http://store.steampowered.com/app/842520 esgst.js:100 Total CV: 37.64999999999998 esgst.js:100 Adding 0.44999999999999996 CV from :http://store.steampowered.com/app/842560 esgst.js:100 Total CV: 38.09999999999998 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/842590 esgst.js:100 Total CV: 38.24999999999998 esgst.js:100 Adding 0.3 CV from :http://store.steampowered.com/app/842620 esgst.js:100 Total CV: 38.549999999999976 esgst.js:100 Adding 0.3 CV from :http://store.steampowered.com/app/846370 esgst.js:100 Total CV: 38.84999999999997 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/874140 esgst.js:100 Total CV: 38.99999999999997 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/879220 esgst.js:100 Total CV: 39.14999999999997 esgst.js:100 Adding 0.15 CV from :http://store.steampowered.com/app/912360 esgst.js:100 Total CV: 39.29999999999997 esgst.js:100 CV calculation ended... esgst.js:100 Current CV: 1947.09 esgst.js:100 Final CV calculated: 39.29999999999997 esgst.js:100 CV difference: 0 esgst.js:100 Predicted level: 7.99

Did you try syncing?

Yes.

Currently at 8.04 - prediction 8.17.
(This might be edited because of more new giveaways starting and ending in the meantime.)

I think this is still not working correctly, another user reported some weird predictions.

I have zero ongoing GAs at the moment and it still thinks that my level will rise (4.77 -> 4.78) when those non-existing GAs end (whenever that might be), so it's definitely still not correct.

Yeah, I had that too (see my last comment with the calculation info from console).

Ok, v8.3.14 should work like this: when the giveaways are open, it should predict the exact level that you will end up at when they get marked as received, but when some giveaways end, the predicted level will drop, because it will no longer include those ended giveaways in the prediction. Implementing a system that is aware of ended giveaways is just too complex, as you can see by my many tries here, so I think this is the best way.
An example of how it should work:

You are at 300 CV
You create 5 giveaways, which will give you 5 + 10 + 15 + 20 + 25 = 75 CV
The feature predicts that you will end up at 300 + 75 = 375 CV (converting that value to the corresponding level)
The first 2 giveaways end
Now, unaware of the first 2 giveaways, the feature stops including the 15 CV from those giveaways in the calculation and predicts that you will end up at 300 + 60 = 360 CV
The first 2 giveaways get marked as received
You are now at 315 CV
The feature predicts that you will end up at 315 + 60 = 375 CV, back to the first prediction
All giveaways end and get marked as received
You should be at 375 CV

Let me know if it works accordingly.

Well, my prediction (currently still at 8.4) went down from 8.17 to 8.13. Considering there was some false prediction beforehand although no giveaways were open/not marked as received yet I consider this the new correct prediction.
Now that's a challenge, isn't it.

What's a challenge?

Getting it to fully work correctly.

Any news?

Not yet.

It's hard to see how it's working since you create more giveaways while the others are ending, but looks like you ended up at the 8.14 previously predicted.

No idea how you got the 8.14. That was the last starting point.
The prediction for the huge bunch of giveaways was 8.27 but I ended up at only 8.26.

But it was a previous prediction, which appears to have been correct. There are just too many variables in play here that could be resulting in the small difference between 8.27 and 8.26, it's not like it's way off, so I don't think there's anything more that I can do. These predictions are just that, predictions, they aren't an accurate representation of what you'll end up at, they're just there to give you a better idea.
It would be nice if someone could test the feature by creating giveaways and letting them all end, without creating any new giveaways in between, because then the predictions would be clear.

It's not really a small difference, it's a difference of 10$ real CV.
It also was only that batch of giveaways that ended with no others still going or not being marked as received. So the only prediction or i info that actually mattered was the last one at 8.14 -> 8.27.

$10 is a very small difference, and could very well be some reduced / no CV game that hasn't been added to the ESGST database yet. Also, the difference in actual numbers from 8.27 to 8.26 is only 0.01, which can also be the result of rounding inconsistencies between SteamGifts and ESGST.  If the feature predicted that you were going to end up at 8.27, and you ended up at 8.26, I'd say it's working fine.

I don't remember if I removed the logs, but if they're still there, you can check ESGST's calculation by calculating the CV for each giveaway manually, and then comparing the values to the ones calculated by ESGST.

For that it would be extremely helpful if the markers for 0 CV, reduced CV and full CV would show what CV for that game accruals is at mouse over. I had wanted to suggest that in past anyways.

Should I make the previous comment a separate Feature Request post?

Yes, please.

It looks like the latest changes here (a couple of months ago?) might have fixed it. At least I'm not seeing any clearly wrong behavior anymore. I was at 4.78, I had one GA running, I had a prediction for 4.79, it was marked received, I'm at 4.79. That looks fine. But I'm also not working with potential corner cases like making full CV GAs that get set reduced CV while they're still ongoing, so my test case is pretty limited.

Ok, I'm closing this. If there are still issues, please open a new issue because this one is getting too long. Maybe in the future I'll try to make the feature work in real time again, but it's just too complex right now. Perhaps cg will implement it by then. :P


Backend part added to sign up Activity

Backend part added to sign up activity.

Working on Design.....


isReady verifies resource generation and observed generation

This patch adds a condition to the isReady function so that isReady
returns true only when the observed generation is equal to the
object generation since after a resource update isReady might
return true even though the latest spec could lead to a resource
not being ready (due to misconfiguration or missing dependencies).

Changes

isReady verifies resource generation and observed generation

/kind bug

Fixes #

Release Note

isReady verifies resource generation and observed generation.

Docs

None

/cc @kvmware

/lgtm
/approve

/assign @nak3

/assign @lionelvillard @devguyio

/approve


CHEBI:145495 and other classes missing is-a parents

OLS currently looks like this for CHEBI:

CHEBI:145495 and 5 others are missing is-a parents

Thanks for letting us know. These 6 ChEBI entries have now been fixed.


Drop unhelpful CodeQL Analysis to make faster CI

It takes around 4~5x slower than other jobs. Although it did not help anything to us.
Current mobu has No server-side logics. I think it is needless for now.
@mobu-of-the-world/maintainers How do you think?

Thank you!


New blog post and removal of the old about the Vagrant based demo box.

Merging myself because the old blog links do not work


Will vision transformer models be implemented? (like MoCo v3, DINO)

And some methods for dense tasks (DenseCL, PixPro ..)
Thanks :-)

We currently do not support this line of research. We will be grateful if you would like to contribute these methods to the repo.


FileSystemException: Creation of temporary directory failed, path = '.../flutter_tools.' (OS Error: No space left on device, errno = 28)

On 3.24.0 as of 8/20: 67 reports by 20 unique clients.
Possibly shares a root cause with https://github.com/flutter/flutter/issues/142537.
Flutter CLI commands (at least from first 10 reports): flutter run, flutter test integration_test
I'm fairly certain the tool has constructs to handle out-of-storage errors in its ErrorHandling* file system abstractions, but something might be leaking here.
FileSystemException: Creation of temporary directory failed, path = '/var/folders/7j/0l_gjs0d7vx87_j12jr1zk3m0000gq/T/flutter_tools.' (OS Error: No space left on device, errno = 28)
at _Directory.createTempSync(directory_impl.dart:170)
at ForwardingDirectory.createTempSync(forwarding_directory.dart:28)
at LocalFileSystem.systemTempDirectory(file_system.dart:236)
at ForwardingFileSystem.systemTempDirectory(forwarding_file_system.dart:33)
at IOSCoreDeviceControl._listCoreDevices(core_devices.dart:65)
at IOSCoreDeviceControl.getCoreDevices(core_devices.dart:122)
at XCDevice.getAvailableIOSDevices(xcdevice.dart:487)
at <asynchronous gap>(async)
at PollingDeviceDiscovery._populateDevices(device.dart:547)
at <asynchronous gap>(async)
at Future.wait.<anonymous closure>(future.dart:524)
at <asynchronous gap>(async)
at DeviceManager.getAllDevices(device.dart:198)
at <asynchronous gap>(async)
at DeviceBasedDevelopmentArtifacts.requiredArtifacts(flutter_command.dart:1908)
at <asynchronous gap>(async)
at FlutterCommand.verifyThenRunCommand(flutter_command.dart:1692)
at <asynchronous gap>(async)
at FlutterCommand.run.<anonymous closure>(flutter_command.dart:1394)
at <asynchronous gap>(async)
at AppContext.run.<anonymous closure>(context.dart:153)
at <asynchronous gap>(async)
at CommandRunner.runCommand(command_runner.dart:212)
at <asynchronous gap>(async)
at FlutterCommandRunner.runCommand.<anonymous closure>(flutter_command_runner.dart:372)
at <asynchronous gap>(async)
at AppContext.run.<anonymous closure>(context.dart:153)
at <asynchronous gap>(async)
at FlutterCommandRunner.runCommand(flutter_command_runner.dart:308)
at <asynchronous gap>(async)
at run.<anonymous closure>.<anonymous closure>(runner.dart:130)
at <asynchronous gap>(async)
at AppContext.run.<anonymous closure>(context.dart:153)
at <asynchronous gap>(async)
at main(executable.dart:93)
at <asynchronous gap>(async)

Oh okay. I figured out what is happening here.
The filesystem called upon in IOSCoreDeviceControl._listCoreDevices should be a ErrorHandlingFileSystem. ErrorHandlingFileSystem has an override for systemTempDirectory that wraps the underlying Directory instance into a ErrorHandlingDirectory, which provides us the error handling we expect (which should catch OS Error: No space left on device, errno = 28 and throw a ToolExit—causing the tool to exit gracefully instead of crashing).
https://github.com/flutter/flutter/blob/30835d7dac4c2df11c5a8d49dc5a9c2e3cfc5dbe/packages/flutter_tools/lib/src/base/error_handling_io.dart#L126-L128
Notice delegate here. What I think is happening is that delegate is an instance of LocalFileSystem (not to be confused with the LocalFileSystem provided by package:file). LocalFileSystem's override of systemTempDirectory will actually create and return a new directory within the actual system temp directory. This is the source of the at _Directory.createTempSync(directory_impl.dart:170) at the top of the stack.
TL;DR: merely referencing FileSystem.systemTempDirectory can result in a create operation, so we need to wrap this in the error-handling logic within ErrorHandlingFileSystem.systemTempDirectory.


OpenXR Tools for Windows Mixed Reality should not be sandboxed

The sandboxing means that OpenXR Tool's information does not reflect the user's real configuration, so can be a very misleading debugging tool.
Missing API layers
OpenKneeboard by default installs an OpenXR API via HKCU, to avoid unneeded elevation. OpenXR Tools will not include it in the list of API layers - for example, in this screenshot, OpenXR Toolkit is installed via HKCU and appears in both OpenXR tools and OpenXR Explorer, however OpenKneeboard only shows up in OpenXR Explorer:

Unrepresentative ACLs
If an 'everyone'-readable/executable API layer is installed, but it is not readable by the restricted package users (which are not part of everyone), OpenXR Tools will hard-fail - for example, if OpenKneeboard is set to install OpenXR for 'all users', the layer files are in C:\ProgramData which does not have the restricted app ACLs, leading to this:

In the latter case, DbgView shows:
[22956] Error [GENERAL |  | OpenXR-Loader] : Unknown failure: exists: Access is denied.: "C:\ProgramData\OpenKneeboard\OpenKneeboard-OpenXR.json"


[SUSTAIN-663] Response code of 1xx or 204 does include Content-Length in header

http://wilson.ci.chef.co/job/chef-server-trigger-ad_hoc/6/downstreambuildview/

@srenatus Yeah, it took us a bit of time to track down yesterday.  It turns out eper which is where we get the very useful redbug tool started depending on mnesia since they also ship an mtop tool:
https://github.com/massemanet/eper/commit/2d5744cf0f269b3e79047afc3d38114e3d890c9a
Our rough plan is to open a nicely worded issue to ask if it is really necessary to include mnesia.  But for now, it was easier to update our tests.

I misunderstood @srenatus's question.  The update from webmachine/webmachine to chef/webmachine was caused by the bump to opscoderl_wm.  The plan is to move back to mainline once our PR is merged upstream: https://github.com/webmachine/webmachine/pull/285

@stevendanna thank you :)


Dockerfile fix to run on Hugging Face

hey @lucianotonet can you elaborate what is this PR for?

Objective of the Change
The existing Dockerfile needed adjustments to run on Hugging Face Spaces. This pull request introduces changes to make the Dockerfile more flexible and optimized for deployment in that specific environment.
Changes Made

Added Build Arguments: Introduced build arguments like FLOWISE_PATH, PORT, PASSPHRASE, DATABASE_PATH, APIKEY_PATH, SECRETKEY_PATH, and LOG_PATH to allow customization at build time.
Consolidated Dependency Installation: Combined the installation of dependencies like git, python3, py3-pip, make, g++, build-base, cairo-dev, pango-dev, chromium into a single RUN command.
Environment Variables Configuration: Defined environment variables using the build arguments to make the Dockerfile more dynamic.
Flowise Directories Configuration: Created and configured necessary directories for Flowise, including permissions.

Detailed Changes
+ ARG FLOWISE_PATH=/usr/local/lib/node_modules/flowise
+ ARG PORT=7860
+ ARG PASSPHRASE=
+ ARG DATABASE_PATH=/root/.flowise
+ ARG APIKEY_PATH=/root/.flowise
+ ARG SECRETKEY_PATH=/root/.flowise
+ ARG LOG_PATH=/root/.flowise/logs
+ RUN apk add --no-cache git python3 py3-pip make g++ build-base cairo-dev pango-dev chromium
+ ENV PORT=$PORT
+ ENV PASSPHRASE=$PASSPHRASE
+ ENV DATABASE_PATH=$DATABASE_PATH
+ ENV APIKEY_PATH=$APIKEY_PATH
+ ENV SECRETKEY_PATH=$SECRETKEY_PATH
+ ENV LOG_PATH=$LOG_PATH
+ RUN mkdir -p $FLOWISE_PATH && chmod -R 777 $FLOWISE_PATH
+ RUN mkdir -p $LOG_PATH && chmod -R 777 $LOG_PATH
+ RUN mkdir -p $FLOWISE_PATH/uploads && chmod -R 777 $FLOWISE_PATH/uploads
+ CMD ["npx", "flowise", "start"]
- RUN apk add --no-cache git
- RUN apk add --no-cache python3 py3-pip make g++
- RUN apk add --no-cache build-base cairo-dev pango-dev
- RUN apk add --no-cache chromium
- CMD "flowise"

Impact
These changes ensure that the project can be run on Hugging Face Spaces, expanding deployment possibilities. By optimizing the Dockerfile, users can now quickly start the application without the need to make corrections to the Dockerfile or even set any environment var. This enhances the user experience and makes the Dockerfile more maintainable and user-friendly.

@lucianotonet tried running HF space got this error:

Hi @HenryHengZJ. Thank you for pointing that out 👍
The Dockerfile has been updated.
I tested it on HF Spaces and now it works. You can see here.
But, it still needs to set PORT=7860 on Settings > Variables and Secrets. That's very important!
Also, I will make sure to update the instructions that I have made on your Docs here accordingly with this one.

thanks @lucianotonet it works now! https://huggingface.co/spaces/FlowiseAI/Flowise
Can we make another folder on Flowise like huggingface_space with the 3 files like here?
This is because the Dockerfile inside docker folder is used for docker-compose image. Modifying this file causes docker-compose up -d not working. Prefer to have separate folder just for HF Space

Hi @lucianotonet just wondering if this PR is still relevant/live or if it needs to be adjusted because of changes since last message - it's quite old and if it's been superceded by other changes perhaps it should be closed off here so that the outstanding live PR count can be kept low for better admin engagement? Thanks.

Hey @deep-pipeline
It requires review and testing, but currently, I lack the time. I will do it as soon as possible.

@deep-pipeline I tested and it seems to be working on Hugging Face as expected.

https://huggingface.co/spaces/lucianotonet/Flowise

PS how to work with authentication and private data? Where can I learn about it?


Update EntityMut's location in push_children() and insert_children()

Objective
This code would result in a crash:
use bevy::prelude::*;

fn main() {
    let mut world = World::new();
    let child = world.spawn().id();
    world.spawn().push_children(&[child]);
}

Solution
Update the EntityMut's location after inserting a component on the children entities, as it may have changed.

Actually, could you add your previously crashing code as a regression test?

Thats a pretty nasty bug. Nice catch!

bors r+


raise ConnectionError when one of cluster master node down

I run a four-node redis-cluster with config cluster-require-full-coverage=no, where one master node(<IP_ADDRESS>:7381) down,  data visit in other connected node should be normal.
However, when i  init StrictRedisCluster, ConnectionError  raised.
Traceback (most recent call last):
  File "E:/pyworkplace/reliability/script/t.py", line 54, in <module>
    client = RedisClient('<IP_ADDRESS>:6380')
  File "E:/pyworkplace/reliability/script/t.py", line 18, in __init__
    self.client = StrictRedisCluster(skip_full_coverage_check=True, host='<IP_ADDRESS>', port=6380)
  File "C:\Python27\lib\site-packages\rediscluster\client.py", line 157, in __init__
    **kwargs
  File "C:\Python27\lib\site-packages\rediscluster\connection.py", line 83, in __init__
    self.nodes.initialize()
  File "C:\Python27\lib\site-packages\rediscluster\nodemanager.py", line 190, in initialize
    need_full_slots_coverage = self.cluster_require_full_coverage(nodes_cache)
  File "C:\Python27\lib\site-packages\rediscluster\nodemanager.py", line 225, in cluster_require_full_coverage
    return any(node_require_full_coverage(node) for node in nodes.values())
  File "C:\Python27\lib\site-packages\rediscluster\nodemanager.py", line 225, in <genexpr>
    return any(node_require_full_coverage(node) for node in nodes.values())
  File "C:\Python27\lib\site-packages\rediscluster\nodemanager.py", line 222, in node_require_full_coverage
    return "yes" in r_node.config_get("cluster-require-full-coverage").values()
  File "build\bdist.win32\egg\redis\client.py", line 620, in config_get
  File "build\bdist.win32\egg\redis\client.py", line 578, in execute_command
  File "build\bdist.win32\egg\redis\connection.py", line 563, in send_command
  File "build\bdist.win32\egg\redis\connection.py", line 538, in send_packed_command
  File "build\bdist.win32\egg\redis\connection.py", line 442, in connect
redis.exceptions.ConnectionError: Error 10061 connecting to <IP_ADDRESS>:7381. .

What i know from stack trace is StrictRedisCluster send command to get config cluster-require-full-coverage when init, While failed master node is disconnected.
Also, I found no way to skip the step, get config cluster-require-full-coverage .

env
redis-cluster: 3.0.3
redis-py-cluster: 1.2.0

@wenxuanguan Have you tested to rerun this case/scneario with a later version of redis-py-cluster? 1.2.0 is kinda old and things might have changed since 1.2.0.
I am not totally sure about simply swallow the error would improve things becuase if one of your masters is down in your cluster that you probably have defined, you might want that error to propegate up to your caller of the client class.
I will put this on the backburner some and think about it some if i want to change the overall behaviour of the feature or not.


Drop completed TODO

How to categorize this PR?

/area quality
/kind cleanup
What this PR does / why we need it:
Drop completed TODO, introduced with https://github.com/gardener/gardener/pull/10003
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note:

NONE

/retest

/retest


Mobile-friendly app

For non-stream users of the app, the case can be argued that this app could be great on a mobile web browser if a user wants to "take notes" on their phone. We should look into how to make a great experience for mobile devices where the viewport is <500px wide.

Yes, I do think we want to keep non-streamer users to have an option to use mobiles so maybe after everything is working great on desktop we can fix the mobile experience.


5.7 - 17: Sửa Webhook - Sửa send actions Label link deleted

Checked Label link deleted hiển thị trạng thái on

https://onedrive.live.com/View.aspx?resid=495A9FD49F594800!152&authkey=!AIjA8V7ngGWbw7g


[SPARK-23275][SQL] hive/tests have been failing when run locally on the laptop (Mac) with OOM

What changes were proposed in this pull request?
hive tests have been failing when they are run locally (Mac Os) after a recent change in the trunk. After running the tests for some time, the test fails with OOM with Error: unable to create new native thread.
I noticed the thread count goes all the way up to 2000+ after which we start getting these OOM errors. Most of the threads seem to be related to the connection pool in hive metastore (BoneCP-xxxxx-xxxx ). This behaviour change is happening after we made the following change to HiveClientImpl.reset()
 def reset(): Unit = withHiveState {
    try {
      // code
    } finally {
      runSqlHive("USE default")  ===> this is causing the issue
    }

I am proposing to temporarily back-out part of a fix made to address SPARK-23000 to resolve this issue while we work-out the exact reason for this sudden increase in thread counts.
How was this patch tested?
Ran hive/test multiple times in different machines.
(If this patch involves UI changes, please attach a screenshot; otherwise, remove this)
Please review http://spark.apache.org/contributing.html before opening a pull request.

@gatorsmile sorry for the late reply. I think the root cause is in hive metastore. I created one pr to bypass it: https://github.com/apache/spark/pull/20562


Makers for lex, yacc, lisp

I've added some makers, mostly by porting them from Syntastic.

lex: flex : works perfectly
yacc: bison : works perfectly
lisp: clisp: has a bug, i've added it so someone can help fix it
avr-gcc: works alright, requires manual parameter changes to include headers. neomake doesn't have facilities for reading local (project) config files.

Sure, I'll fix what You requested, remove avr-gcc and make a separate pull request for it, with extra information.

Done.

@randrej
Thanks.
Please squash it: a single commit would be OK, but at least remove the adding and removal of the avr-gcc commit.
The other fixups should be moved to the commits before then - if you do not want to squash it into a single commit.
I can do the latter from the GitHub UI, so just let me know in that case.

@blueyed If You can do it in the GitHub UI, please do. Thanks!

x

Rebased it, but could not push it here (because of using "master" maybe - please create separate branches for PRs in the future!).
Follow-up: https://github.com/neomake/neomake/pull/949


Update coarse-parallel-processing-work-queue.md

Changes:

Update detailed description to match overview: each pod exits after processing one entry.

The overview says that each pod processes one entry and exits, but in the details it says each pods repeats - which is identical to the fine-grained detail.
NOTE: I think there's a larger problem with these examples. They are both examples of fine-grained parallelism. If anything, the fine-grained example is coarser than the coarse-grained example.
The Coarse vs Fine distinction deals with partition size, and in each of these examples the partition size is identical.

@joebowbeer I don't know what your appetite is for a bigger rewrite of these pages, but:

they would work better as tutorials anyway
they are out of date and miss out some newer Kubernetes features, such leases and indexed jobs
they are overall not as helpful to readers as they could be

We welcome improvements big and small. If you want to work on the bigger picture, PRs like this are still really useful. The smaller PRs are, the easier they are to review. Thanks for helping with the docs!

This PR describes parallel processing job more accurately
/approve


[Lead space]  medium variation functional specifications

User Story

As a [user role below]:
DDS developer

I need to:
have the Lead space functional specs

so that I can:
so that I can properly code the Lead space component that meets the Design functions and intent

Additional information

Overview and scope of the engineering work should be included in the linked epic (#4753 )
Design Issue (#5197) and (#5256)
Development issue (#5231 )
Visual Designs & Functional Design Specs Box folder link

Acceptance criteria

[ ] Documented Lead space functional specifications
[ ] Sent and/or presented the specs to Design and Engineering for their review and comments
[ ] Additional stories are created, if needed, for any work to be done in future sprints

Here are some updates I reviewed with design and dev yesterday, I'll be adding to functional specs, and sent over to @andysherman2121 this morning.

Add new size prop to leadspace (across all types)
New size options (see design specs for height definitions)

super
tall default
medium

Remove aspect ratios on small and left/default types.
Remove height for centered type.

more updates to come from #5347

Updated functional specs:
https://ibm.box.com/s/drihwzp3aernradc8wa3ycd2tc0t9n6k


Add Message.kind field to label message categories.

Fixes #924.

I'm not too happy with the boilerplate needed to add a new category here. Also,

the protobuf schema will quickly explode with every new message kind
the scalameta public API will grow with every new message kind

I think this issue requires more thinking.


xExchExchangeServer: Add Missing Cmdlet Parameters

The xExchExchangeServer resource is currently missing one or more parameters from the corresponding Exchange cmdlet(s). The latest list of parameters can be found at https://docs.microsoft.com/en-us/powershell/module/exchange/organization/set-exchangeserver . Missing parameters may be version specific. Exchange 2010 only or older parameters should not be included. Parameters specific to either Exchange 2013 or Exchange 2016 (but not both) should be handled using the RemoveVersionSpecificParameters helper function.

I'll take this one.

Looks like there's no way to suppress the confirmation prompt for ErrorReportingEnabled. This parameter will have to be omitted:
[PS] C:\Windows\system32>set-exchangeserver e16-3 -ErrorReportingEnabled $true -Confirm:$false

Confirm
If you enable error reporting, Exchange will automatically send error reports to Microsoft. If an error occurs, the
server sends information to Microsoft over encrypted channels using SSL. This information is used only to improve
Microsoft products. Error reporting doesn't intentionally collect any personal information such as e-mail addresses.
However, individual error reports may inadvertently contain personal information.Although such information could
potentially be used to determine the identity of Exchange users, it will not be used.

. When the error reporting feature is enabled and the issue reported has a known solution, the server will receive
feedback from Microsoft with a link to a Web page containing information that may help in resolving the problem.

. For more information about the error reporting feature, see http://oca.microsoft.com/en/dcp20.asp.

. Do you want to enable the error reporting feature?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"):


Unable to regenerate main API configure file every time

Problem statement
We are using custom templates and want to regenerate main API configure file every time. Could you make options SkipExists for this file configurable.
https://github.com/go-swagger/go-swagger/blob/3fd4a9e91d5cbaf817db8711023d05e6525018f7/generator/shared.go#L322
Environment
swagger version: version: dev commit: 442132c57cd7d1a394d596d7b8084f6a9cdb37f4
go version: go1.10.2 darwin/amd64
OS: Darwin Kernel Version 16.7.0

It is configurable:
in go-swagger main config file, you may specify skip_exists: true for any generation target.
layout:
  application:
    - name: configure
      source: asset:serverConfigureapi
      target: ...
      skip_exists: true
      skip_format: false
...

We have been discussing related improvements you might be interested in at #397

It's great! thanks


ManagementForm data is missing or has been tampered with

I've tried to install django material in our project, mainly for the admin part. Templates are really good, but it seems django-material brokes some part of the form logic. When saving any model through the admin, we get the following error: ManagementForm data is missing or has been tampered with.
Complete stack trace can be found below:
Environment:

Request Method: POST
Request URL: http://<IP_ADDRESS>:8000/en/admin/auth/user/1/

Django Version: 1.7.4
Python Version: 3.4.0
Installed Applications:
('django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'django.contrib.sites',
'material',
'material.admin',
'treebeard',
'mptt',
'djangocms_text_ckeditor',
'cms',
'menus',
'sekizai',
'djangocms_admin_style',
'django.contrib.admin',
'ourproject',
'cachalot',
'waffle',
'rest_framework',
'guardian',
'hvad',
'cities_light',
'autocomplete_light',
'allauth',
'allauth.account',
'allauth.socialaccount',
'allauth.socialaccount.providers.facebook',
'djcelery',
'rosetta',
'debug_toolbar',
'autofixture')
Installed Middleware:
('debug_toolbar.middleware.DebugToolbarMiddleware',
'ourproject.middleware.SetRemoteAddrMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
'django.middleware.doc.XViewMiddleware',
'django.middleware.locale.LocaleMiddleware',
'cms.middleware.user.CurrentUserMiddleware',
'cms.middleware.page.CurrentPageMiddleware',
'cms.middleware.toolbar.ToolbarMiddleware',
'cms.middleware.language.LanguageCookieMiddleware',)

Traceback:
File "/home/user/.local/share/virtualenvs/ourproject/lib/python3.4/site-packages/django/core/handlers/base.py" in get_response
111.                     response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/home/user/.local/share/virtualenvs/ourproject/lib/python3.4/site-packages/django/contrib/admin/options.py" in wrapper
583.                 return self.admin_site.admin_view(view)(*args, **kwargs)
File "/home/user/.local/share/virtualenvs/ourproject/lib/python3.4/site-packages/django/utils/decorators.py" in _wrapped_view
105.                     response = view_func(request, *args, **kwargs)
File "/home/user/.local/share/virtualenvs/ourproject/lib/python3.4/site-packages/django/views/decorators/cache.py" in _wrapped_view_func
52.         response = view_func(request, *args, **kwargs)
File "/home/user/.local/share/virtualenvs/ourproject/lib/python3.4/site-packages/django/contrib/admin/sites.py" in inner
206.             return view(request, *args, **kwargs)
File "/home/user/.local/share/virtualenvs/ourproject/lib/python3.4/site-packages/django/contrib/admin/options.py" in change_view
1456.         return self.changeform_view(request, object_id, form_url, extra_context)
File "/home/user/.local/share/virtualenvs/ourproject/lib/python3.4/site-packages/django/utils/decorators.py" in _wrapper
29.             return bound_func(*args, **kwargs)
File "/home/user/.local/share/virtualenvs/ourproject/lib/python3.4/site-packages/django/utils/decorators.py" in _wrapped_view
105.                     response = view_func(request, *args, **kwargs)
File "/home/user/.local/share/virtualenvs/ourproject/lib/python3.4/site-packages/django/utils/decorators.py" in bound_func
25.                 return func.__get__(self, type(self))(*args2, **kwargs2)
File "/home/user/.local/share/virtualenvs/ourproject/lib/python3.4/site-packages/django/db/transaction.py" in inner
394.                 return func(*args, **kwargs)
File "/home/user/.local/share/virtualenvs/ourproject/lib/python3.4/site-packages/django/contrib/admin/options.py" in changeform_view
1403.             if all_valid(formsets) and form_validated:
File "/home/user/.local/share/virtualenvs/ourproject/lib/python3.4/site-packages/django/forms/formsets.py" in all_valid
438.         if not formset.is_valid():
File "/home/user/.local/share/virtualenvs/ourproject/lib/python3.4/site-packages/django/forms/formsets.py" in is_valid
303.         self.errors
File "/home/user/.local/share/virtualenvs/ourproject/lib/python3.4/site-packages/django/forms/formsets.py" in errors
277.             self.full_clean()
File "/home/user/.local/share/virtualenvs/ourproject/lib/python3.4/site-packages/django/forms/formsets.py" in full_clean
324.         for i in range(0, self.total_form_count()):
File "/home/user/.local/share/virtualenvs/ourproject/lib/python3.4/site-packages/django/forms/formsets.py" in total_form_count
114.             return min(self.management_form.cleaned_data[TOTAL_FORM_COUNT], self.absolute_max)
File "/home/user/.local/share/virtualenvs/ourproject/lib/python3.4/site-packages/django/forms/formsets.py" in management_form
96.                     code='missing_management_form',

Exception Type: ValidationError at /en/admin/auth/user/1/
Exception Value: ['ManagementForm data is missing or has been tampered with']

I get the same thing!  in a clean state project as well :(

I am having a similar issue whenever models have foreign keys
impossible to use the admin with this bug

The UI is absolutely beautiful but I'm also stuck at this point, the admin seems not to be able to show any Inlines, custom inlines with pagination, filter_horizontal feature seems broken and FKs don't work so we can't use this.
Isn't there any ETA on when you guys will stop developing the admin interface since it's one of the most important parts of Django.

Also formsets support will be added to material.forms very soon, admin part itself is the low priority for viewflow project.
Pool requests are wellcome.

material admin will be awesome, so shouldn't be in less priority

Same problem with the management form error. Haven't been able to add any new thing to my models.
Good work by the way...hoping you are able to fix the bug very soon.

+1

Fixed


OutofMemoryError: Actors use too much memory

Cheers for the wonderful code! I am using it for atari game. But the worker threads use too much memory resulting in out of memory error.
RayTaskError(RayOutOfMemoryError): ray::SharedStorage (pid=2986, ip=<IP_ADDRESS>)
File "python/ray/_raylet.pyx", line 431, in ray._raylet.execute_task
File "/usr/local/lib/python3.6/dist-packages/ray/memory_monitor.py", line 120, in raise_if_low_memory
self.error_threshold))
ray.memory_monitor.RayOutOfMemoryError: More than 95% of the memory on node 8ff9db8651eb is used (12.13 / 12.72 GB). The top 10 memory consumers are:
PID	MEM	COMMAND
3039	4.53GiB	ray::SelfPlay.continuous_self_play()
3054	4.5GiB	ray::SelfPlay.continuous_self_play()
2985	1.26GiB	ray::Trainer.continuous_update_weights()
126	0.38GiB	/usr/bin/python3 -m ipykernel_launcher -f /root/.local/share/jupyter/runtime/kernel-4404f6dc-8f78-4a
2986	0.14GiB	ray::SharedStorage
3026	0.08GiB	ray::ReplayBuffer
2966	0.08GiB	/usr/bin/python3 -u /usr/local/lib/python3.6/dist-packages/ray/dashboard/dashboard.py --host=localho
26	0.07GiB	/usr/bin/python2 /usr/local/bin/jupyter-notebook --ip="<IP_ADDRESS>" --port=9000 --FileContentsManager
2960	0.04GiB	/usr/local/lib/python3.6/dist-packages/ray/core/src/ray/thirdparty/redis/src/redis-server *:44319
3048	0.04GiB	ray::IDLE
In addition, up to 0.24 GiB of shared memory is currently being used by the Ray object store. You can set the object store size with the object_store_memory parameter when starting Ray.

Hi,
Thank you
Indeed, I see that it uses more than 12 GB of Ram which is the limit of your computer.
There are two things:
First of all, compatibility with Atari games is a work in progress. You can see in the paper appendix Network Architecture that the DeepMind team is reducing the size of the observations. We haven't committed this yet. It will reduce memory usage.
In the meantime, you can on your side reduce the resolution, lower the number of actors and use networks with fewer parameters.
However, note that training RL agents on Atari generally requires very good computers.


Leading / is removed from field "Path" when creating a new destination

Leading / is removed from path input field. Workaround with //

:tada: This issue has been resolved in version 0.10.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Watched/unwatched icons are not shown

Under the course overview, where the lectures are listed, in the old version one could see the watching status with the icons next to the videos:

Currently, you can filter them- but the icons are gone:

I believe it would be really convenient to add those icons back 😊

I think the current behavior is that the blue bar at the bottom marks the watch state.
If you mark a video as watched, the bar should become fully blue, right?

That is correct, thanks for pointing it out. Still, I feel like the other way was a little bit more intuitive, it might be just me though 😅

We could add the eye symbol to the thumbnail though. 🤔


Decoders shape is changing

Im getting the below error when I try to fit the model.
ValueError: A target array with shape (73, 458, 690, 3) was passed for an output of shape (None, 460, 692, 3) while using as loss binary_crossentropy. This loss expects targets to have the same shape as the output.
The summary of the autoencoder is,
autoencoder.summary():

Layer (type)                 Output Shape              Param #
input_1 (InputLayer)         (None, 458, 690, 3)       0

conv2d (Conv2D)              (None, 458, 690, 16)      448

max_pooling2d (MaxPooling2D) (None, 229, 345, 16)      0

conv2d_1 (Conv2D)            (None, 229, 345, 8)       1160

max_pooling2d_1 (MaxPooling2 (None, 115, 173, 8)       0

conv2d_2 (Conv2D)            (None, 115, 173, 8)       584

max_pooling2d_2 (MaxPooling2 (None, 58, 87, 8)         0

conv2d_3 (Conv2D)            (None, 58, 87, 8)         584

up_sampling2d (UpSampling2D) (None, 116, 174, 8)       0

conv2d_4 (Conv2D)            (None, 116, 174, 8)       584

up_sampling2d_1 (UpSampling2 (None, 232, 348, 8)       0

conv2d_5 (Conv2D)            (None, 230, 346, 16)      1168

up_sampling2d_2 (UpSampling2 (None, 460, 692, 16)      0

conv2d_6 (Conv2D)            (None, 460, 692, 3)       435
Total params: 4,963
Trainable params: 4,963
Non-trainable params: 0

None
The decoder shape is changing at some point. Can you help me in fixing this issue.

The architecture given by the code currently gives exact matching for 100x100 images -- so for any other custom sizes you have to adjust the convolutional layer model parameters to match this (in autoencoder.py), or you could just resize your images into 100x100 images and use as is. Hope this helps.


Admin setting where the user can enable or disable hibernate for the EC2 launch in the UI

Is your feature request related to a problem? Please describe.
This is related with the bug 59. In summary, the Hibernation option is enabled only for Windows and not for other operating systems that support it.
Describe the solution you'd like
The Launch New Virtual Desktop should has the hibernation option enable for all OS by default and not only for Windows, as it is in the AWS console when we create an EC2 instance. So, the admin can choose if the manchine can hibernate or not.
Describe alternatives you've considered
A general option where you can choose if all the deployable machines can be hibernated or not.
Additional context
For more technical details please review the issue 59:
https://github.com/aws/res/issues/59

Hey there, RES development team is aware of this issue and is tracking it internally. We will get back to you with more info once we have them.

We have a backlog ticket item for this issue and are working towards including this feature in a future release.


Feature proposal: GetImplicitElements method

Proposal to add a new method to ModelParser:
public IReadOnlyDictionary<Dtmi, DTEntityInfo> GetImplicitElements()

This would be analogous to the extant method:
public IReadOnlyDictionary<Dtmi, DTSupplementalTypeInfo> GetSupplementalTypes()

The new method would provide an object model that includes all elements implicitly defined by DTDL, by the standard extensions, and by any partner or feature extension that is directly supported by the parser.  Eventually, whenever dynamic extensions are supported, the returned object model will also include elements defined by any extension that has been loaded into the ModelParser instance.

I have some observations:

I see the same results when using MaxDtdlVersion = 2 . I expected elements matching what is available in each version.
Instead of returning all implicit elements, we could split this in different methods, eg: by standard, instance and by extension.
In the same way we added break out properties, will be good to provide a better object model to navigate these results, without forcing the "query+casting" pattern.

Could not find an easy way to answer original question: fetch all the units for Acceleration in #92

I see the same results when using MaxDtdlVersion = 2 . I expected elements matching what is available in each version.

This seems to be an observation regarding the expectations of MaxDtdlVersion.  At present, the only effect of this option is to reject models that specify a DTDL context version exceeding this value.  In other words, this comment does not relate only to the proposed GetImplicitElements() method but rather to the parser's full behavior in regard to the MaxDtdlVersion option.  If you believe the parser should provide stronger semantics for this option, please open an issue to this effect.  This is a highly non-trivial change.

Instead of returning all implicit elements, we could split this in different methods, eg: by standard, instance and by extension.

Yes, this is possible.  It would be similarly possible to split the extant GetSupplementalTypes() method into multiple methods that partition the types by extension.  In the interest of parallelism between the types and the elements, it seems to me that either both methods should be split in this manner or neither should be.  Implementing the split is significant additional work because the internal data structures do not at present partition the type and element information in this way.

In the same way we added break out properties, will be good to provide a better object model to navigate these results, without forcing the "query+casting" pattern.

Are you referring to the casting to DTEnumValue in Tutorial13?

Could not find an easy way to answer original question: fetch all the units for Acceleration in #92

The additions to tutorials 12 and 13 illustrate how fetch all units for Distance (because this type was already used in the tutorial).  The answer for Acceleration is a straightforward adaptation of the tutorial code.

I'll add a new issue wrt MaxDtdlVersion behavior
Agreed, should be good to have the parallelism between types and elements.
Tutorial 13 seems complicated to me, as it requires in-depth knowledge of the underlying DTDL concepts. I was thinking of a higher API that encapsulates how to access supplemental types and units. eg, to get all units for semantic types, I have to filter by EntityKind =Enum and then cast to DTEnumInfo

var implicitElements = new ModelParser().GetImplicitElements();
foreach (var implicitElement in implicitElements
    .Where(i => i.Value.EntityKind == DTEntityKind.Enum && i.Value.Id.OriginalString.StartsWith("dtmi:dtdl:extension:quantitativeTypes"))
    .Select(t => (DTEnumInfo)t.Value))
{
    Console.WriteLine($"{ModelParser.GetTermOrUri(implicitElement.Id)} {implicitElement.Id}");
    foreach (var item in implicitElement.EnumValues)
    {
        Console.WriteLine($"  {item.Name}");
    }
}

I would rather prefer something like:
var semanticTypes= new ModelParser().GetSemanticTypes();
foreach (var st in semanticTypes)
{
  Console.WriteLine(st.Name);
  foreach (var unit in st.Units)
  {
    Console.WriteLine($"  {unit.Name}");
  }
}

2 and 3 are very related and might lead to the same solution.
I would not use the implementation effort to drive the best API design.

I did not mean to imply that I think we should avoid a good design because of the work it involves.  I agree on the value of a easy-to-use solution.

At present, there is no way whatsoever to access the unit information or any other non-type-level language or extension information via the parser API.
At present, we have a method to access supplemental type information (which could be improved at some point to make it more usable), but we have no corresponding method for accessing model-level information.

We can queue up work to both (1) add a highly usable mechanism for accessing units and (2) improve the usability of the type-accessing mechanism, but I don't know either (a) how highly we should prioritize these relative to other work or (b) how quickly we could get these done once the work is started, since this are non-trivial efforts.
In view of the above, my inclination is to provide a mechanism now that (1) provides a perhaps non-ideal mechanism for accessing all model-level information from the metamodels via the parser, to enable use cases that are currently not enabled at all, and that (2) is parallel with the currently offered mechanism for accessing supplemental type information.  If we do not do this, I expect it will be quite a while before these use cases are achievable.

Ok, let's publish GetImplicitElements
Can we add a "manual wrapper" to implement GetSemanticTypes and Units?

You mean like in a sample?  The way we did with ParseToJson?  This seems probably doable.  I'll think on it a bit.


HDXDSYS-1053 HAPI Pipelines - Melanie's requested changes to food security

This is the wrong branch!

Pull Request Test Coverage Report for Build<PHONE_NUMBER>3
Details

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.008%) to 93.345%

Totals

Change from base Build<PHONE_NUMBER>7:
0.008%

Covered Lines:
1585

Relevant Lines:
1698

💛  - Coveralls


[40171] Add VarHandleOp to set of kernels not to cache

Following the discussion with @jaingaurav on pull request #42337 , I have reimplemented the patch for the fourth memory leak from issue #40171 . This new version of the patch filters out VarHandleOp operations from the set of operations whose kernels are cached inside EagerExecutor. Excluding VarHandleOp from caching prevents saved_model.load() from leaking kernels when loading variable values. This change reduces the amount of memory leakage on my test script (which repeatedly loads a toy Keras model) substantially:

Not caching these kernels should have minimal negative impact on performance as far as I'm aware.  VarHandleOp::Compute() is a relatively lightweight operation that usually runs right before a more expensive operation.

Sorry for the delay. @jaingaurav and I discussed this a bit; the fix for tf.Variable was to always use a fixed shared_name to indicate an anonymous resource. The reason something is still leaking is this line: https://github.com/tensorflow/tensorflow/blob/6d57022510f5820cfc3c5b86ba52fe623351bc63/tensorflow/python/ops/resource_variable_ops.py#L1957
Which should be like this line instead: https://github.com/tensorflow/tensorflow/blob/6d57022510f5820cfc3c5b86ba52fe623351bc63/tensorflow/python/ops/resource_variable_ops.py#L1706
The advantage is that we can keep the VarHandleOp kernels cached. I don't have a great sense of how much difference that'd make initializing models with lots of small variables, but it seems like it's worth having for the same reason we cached kernels in the first place.
Does that sound reasonable to you? I have a fix pending just changing that line (+ adding a heap check unit test for UninitializedVariable).

@allenlavoie I suspect that change would produce some unintended sharing of buffers if the user were to load the same model twice in a single session. But maybe I'm reading the resource manager code incorrectly.

Right, that's the "to indicate an anonymous resource" bit. The branching is here: https://github.com/tensorflow/tensorflow/blob/2ab4f849127adff4d9445200cf7c518a0620f437/tensorflow/core/kernels/resource_variable_ops.cc#L226
That logic we've had for a while. The change for UninitializedVariable (which SavedModel uses, vs. ResourceVariable which does not leak for this reason) is https://github.com/tensorflow/tensorflow/commit/84ff8673dca1a9b764069e189415bf76b34623d9
At least for CPU we're running a heapchecker and it's passing after that change; previously it did identify the kernel cache as a leak. I haven't tried it on a larger SavedModel load, but presumably leaks wouldn't be VarHandleOp kernel cache related anymore.

@frreiss  Can you please check @allenlavoie's comments and keep us posted ? Thanks!

Ah, I see now. Thanks for clarifying, @allenlavoie !

@frreiss  Any update on this PR? Please. Thanks!

I think we can close this for now.


enhancement idea: redirects / reverse proxy config

It'd be great to have a simple UI to help people unfamiliar with nginx redirects & proxy rules create those.
Presumably, there's demand for this  - here's a WP plugin with like 1 million installs devoted just to setting up redirects. https://wordpress.org/plugins/redirection/
OTOH, maybe that's duplicative of https://nginxproxymanager.com/

Hello @techieshark, thank you for your suggestion for improvement. If I understand this correctly, the application should abstract the configuration by using for example a wizard? I find the idea really good and interesting. But I also think that the application has no other issues that need to be solved first. So I would put this issue aside and work on it as soon as we get to this point. You are welcome to push the development yourself and leave a PR there with the feature. :)

Maybe add some "prepared" snippets, such as 301 redirects for non https traffic etc. Or a toggle for "write this domains nginx logs into  separate file".

@schenkd hi, thanks! Yeah no huge rush but if that changes I'll submit a PR, thank you :)

If I understand this correctly, the application should abstract the configuration by using for example a wizard?

Yep, that's exactly that I was thinking.

@LucaNerlich : Maybe add some "prepared" snippets, such as 301 redirects for non https traffic etc.

That sounds like a great idea too, even if perhaps as the interim solution. Thanks for the idea, Luca!


Superfluous parameter n in Rankine/Fahrenheit conversion

Reported by beutlich on 11 Jul 2013 07:34 UTC
What is HeatTransfer.Rankine.ToKelvin.n and HeatTransfer.Rankine.FromKelvin.n needed for? Seems not needed to me.

Migrated-From: https://trac.modelica.org/Modelica/ticket/1202

Comment by beutlich on 11 Jul 2013 10:25 UTC
Also in HeatTransfer.Fahrenheit.FromKelvin.n.

Comment by otter on 11 Jul 2013 12:05 UTC
Fixed in b82b20762f1e7e117dcf927c4626360feea4ae09:
You are right, the parameter should be removed (seems to be an oversight).
For backwards compatibility the parameter cannot be removed since a user might already provide a modifier in a user model.
Instead, added an annotation (Dialg(enable=false)) to disable the parameter input field and changed the description text to point out that this variable is only supplied for backwards compatibility and will be removed in the future

Comment by dietmarw on 11 Jul 2013 12:08 UTC
Leave this ticket open until the issue is finally resolved once an MSL with conversion script will be released.

Modified by otter on 18 Jul 2013 11:57 UTC

Comment by dietmarw on 1 Aug 2015 21:36 UTC
Milestone renamed

Comment by dietmarw on 1 Aug 2015 21:39 UTC
Milestone renamed


Preview campaign

Fixes https://github.com/wagtail/wagtail-newsletter/issues/31
After some back and forth, we've changed how campaign data is saved: we require the user to save a revision, and base the campaign off of that revision's content. This way it's unambiguous what the campaign content will be; there's no room for the user to forget to save their changes on the Wagtail Page and/or have another user overwrite their work before the campaign is saved.
Therefore, I've changed the behaviour of the newsletter_recipients and newsletter_subject fields: they are no longer specially persisted regardless of revisions; they are now part of the regular revision content. The newsletter_campaign field is still persisted: it's not editable by the user, and it's not helpful to have it overwritten when restoring a previous revision.

The preview page's header is pretty basic at the moment. I wonder what it would take to make it more snazzy, maybe like the history page's header.


tests: ztest: fixed off-by-one in sys_bitfield_find_first_clear

Calling __builtin_ffsl(neg_bitmap) returns first bit set in the word,
e.g. 4 if bitmap is 11111000. As this must translate to zero-based index
3, one must be subtracted from the result.
Signed-off-by: Morten Priess<EMAIL_ADDRESS>

Codecov Report

Merging #8544 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #8544      +/-   ##
==========================================
+ Coverage   63.92%   63.93%   +0.01%
==========================================
  Files         427      427
  Lines       41100    41109       +9
  Branches     6939     6939
==========================================
+ Hits        26275    26285      +10
  Misses      11678    11678
+ Partials     3147     3146       -1

Impacted Files
Coverage Δ

tests/ztest/src/ztest_mock.c
68.36% <100%> (+1.02%)
:arrow_up:

tests/ztest/test/mock/src/main.c
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

@mtpr-ot can you split the changes to ztest_mock.c into 2 commits? one for the indexing fix, the other for the addition of the function


[BUG]

Hi, great tool, I've been looking for something like this for a while now!
Just one major question: could you please somehow implement a "start on reboot" with it automatically enable itself and minimize the window?
I tried using the CLI version by storing a shortcut at shell:startup with "-s -b" for this, but its a bit buggy and also does not support the hovering feature! Thanks in advance!
The CLI version works as intended for this until you hover over the main monitors area where the clock should be. It then appears and never goes away, but only for the main monitor. Im using 3 monitors. So either a GUI version with a "start on reboot" feature or a CLI version with hover feature support and a solution for the bug would be awesome. Thanks!

Hi:
Thanks for the idea. However this is not a bug, is simply a missing feature.
I designed the app to have an easy way to hide the clock and notification areas tempraryly

Hi:
Thanks for the idea. However this is not a bug, is simply a missing feature.
I designed the app to have an easy way to hide the clock and notification areas temporarily for recording videos (which is what I do a lot) and the like, but not as a mean to have the clock hidden by default. I'll think about a way to do it if I have the time, but I can't promise.
The CLI version works as good as possible taking into account that it's not a resident app. I mean, as soon as it hides or shows the elements it ends and has no influence in the system. Unfortunately Windows automatically re-shows the areas when specific events happen (i.e.: a new element is added to the notification area or when a new notification pops up), and the CLI version can't do a thing about it as is explained in the readme file. In fact in the readme I explain a way to prevent this (mostly) happening.
Summing up: it's not a bug, is different orientation for the app, I appreciate the idea and I'll think about it in the future.

I understand, then take it as a suggestion. An auto start on reboot, with it enabling itself and closing the window itself, would be awesome for the GUI version. Hope you'll find some time to implement it.


Debugging tips added to readme

Here's what I put into my local to keep my notes all in one place.  As you might be able to tell, I've got a situation with a router being ridiculously annoying for some of my mostly offline headless servers.

Thanks!