Headless inappwebview very slow on first use

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
I am using a headless inappwebview in my Flutterflow application. Upon the first call to the headless webview (after a new app launch for example), the process is much longer than the subsequent requests and I cannot figure out why.
Expected Behavior
I am expecting the plugin to have a more constant performance.
Steps with code example to reproduce

Steps with code example to reproduce
// Automatic FlutterFlow imports
import '/backend/backend.dart';
import '/actions/actions.dart' as action_blocks;
import '/flutter_flow/flutter_flow_theme.dart';
import '/flutter_flow/flutter_flow_util.dart';
import '/custom_code/actions/index.dart'; // Imports other custom actions
import '/flutter_flow/custom_functions.dart'; // Imports custom functions
import 'package:flutter/material.dart';
// Begin custom action code
// DO NOT REMOVE OR MODIFY THE CODE ABOVE!

import 'package:flutter_inappwebview/flutter_inappwebview.dart';
import 'dart:async';

Future<dynamic> fetchBookList(String? title, String? author) async {
  // Stop the function if both title and author are empty.
  // Normally covered by the UI through Form validation but this is to be safe.
  if ((title?.isEmpty ?? true) && (author?.isEmpty ?? true)) {
    return {
      'error': 'Empty query',
      'message': 'Please enter more specific search criteria.'
    };
  }

  // Define the target URL
  String targetUrl = "https://www.arbookfind.com/advanced.aspx";

  // For the webView to know the loop to execute since each click will generate a new onLoadStop
  bool hasClickedSubmitSearch = false;

  // Create a Completer to signal when the operations are complete
  Completer<dynamic> completer = Completer<dynamic>();

  // Create a headless webview
  var headlessWebView = HeadlessInAppWebView(
    initialUrlRequest: URLRequest(url: WebUri(targetUrl)),
    onWebViewCreated: (controller) {
      controller.addJavaScriptHandler(
        handlerName: "bookAR",
        callback: (args) {
          // List to hold book details
          List<Map<String, dynamic>> bookInfos = [];

          // Check if the argument is a Map and contains books
          if (args.isNotEmpty && args[0] is Map<String, dynamic>) {
            var books = args[0]['books'];
            if (books is List) {
              for (var book in books) {
                if (book is Map<String, dynamic>) {
                  bookInfos.add(book); // Add each book JSON to the list
                }
              }
            }
          }
          // Determine if results exist
          String result = bookInfos.isNotEmpty ? 'yes' : 'no';

          // Signal that the operations are complete with the correct structure
          completer.complete({'results': result, 'books': bookInfos});
        },
      );
    },
    onLoadStop: (controller, url) async {
      if (url != null && !url.toString().contains("usertype")) {
        if (!hasClickedSubmitSearch) {
          await controller.evaluateJavascript(
            source: """
              var searchBookTitle = document.getElementById('ctl00_ContentPlaceHolder1_txtTitle');
              if (searchBookTitle) {
                searchBookTitle.value = '$title';
              }
               var searchBookAuthor = document.getElementById('ctl00_ContentPlaceHolder1_txtAuthor');
              if (searchBookAuthor) {
                searchBookAuthor.value = '$author';
              }
              var submitSearch = document.getElementById('ctl00_ContentPlaceHolder1_btnDoIt');
              if (submitSearch) {
                submitSearch.click();
              }
            """,
          );
          hasClickedSubmitSearch = true;
        } else {
          await controller.evaluateJavascript(
            source: """
    var maxList = 20  // Set the maximum number of elements to process
    var bookInfos = [];

    // Query all elements with id="Table6"
    var tables = document.querySelectorAll('#Table6');

    // Loop through up to maxList elements
    for (var i = 0; i < Math.min(tables.length, maxList); i++) {
      var table = tables[i];

      // Retrieve the book title
      var titleElement = table.querySelector('a#book-title');
      var bookTitle = titleElement ? titleElement.innerText.trim() : '';

      // Retrieve the book URL
      var urlElement = table.querySelector('a#book-title');
      var bookPartialUrl = urlElement ? urlElement.getAttribute('href') : '';
      // Append the base URL to the partial bookUrl
      var bookUrl = 'https://www.arbookfind.com/' + bookPartialUrl;

      // Extract the bookQuizNumber (the integer after 'q=')
      var quizNumberElement = bookUrl.split('q=')[1]?.split('&')[0];
      var bookQuizNumber = quizNumberElement ? quizNumberElement : '';

      // Extract the bookQuizLanguage (the value after 'l=')
      var quizLanguageElement = bookUrl.split('l=')[1]?.split('&')[0];
      var bookQuizLanguage = quizLanguageElement ? quizLanguageElement : '';

      // Retrieve the image path
      var imgElement = table.querySelector('img.book-cover-image');
      var bookImg = imgElement ? imgElement.getAttribute('src') : '';

      // Extract book author from the first
 tag, before the

      var authorElement = table.querySelector('p');
      var bookAuthor = authorElement ? authorElement.innerHTML.split('
')[0] : '';

      // Retrieve the AR points
      var pointsElement = table.querySelectorAll('strong')[2]; // This is the third  tag
      var bookPoints = pointsElement ? pointsElement.innerText : '';

      // Retrieve the ATOS level
      var atosElement = table.querySelectorAll('strong')[1]; // This is the second  tag
      var bookAtos = atosElement ? atosElement.innerText : '';

      // Create the bookInfo object with the extracted data
      var bookInfo = {
        'book_title': bookTitle,
        'book_author': bookAuthor,
        'book_points': bookPoints,
        'book_atos': bookAtos,
        'book_img': bookImg,
        'book_url': bookUrl,
        'book_quiz_number': bookQuizNumber,
        'book_quiz_language': bookQuizLanguage
      };

      // Add the bookInfo to the bookInfos array
      bookInfos.push(bookInfo);

    }

    // Send the result to the Flutter handler
    window.flutter_inappwebview.callHandler('bookAR', {'books': bookInfos});
  """,
          );
        }
      } else {
        await controller.evaluateJavascript(
          source: """
            var radioButton = document.getElementById('radParent');
            if (radioButton) {
              radioButton.click();
            }
            var submitButton = document.getElementById('btnSubmitUserType');
            if (submitButton) {
              submitButton.click();
            }
          """,
        );
      }
    },
  );

  // Run the headless webview
  await headlessWebView.run();

  // Add timeout logic
  try {
    var result = await completer.future.timeout(
      Duration(seconds: 15),
      onTimeout: () {
        return {
          'error': 'Timeout',
          'message': 'The operation took too long to complete.',
          'book_title': '$title',
          'book_author': '$author'
        };
      },
    );

    // Dispose of the headless WebView after successful completion
    await headlessWebView.dispose(); // Clean up resources

    return result;
  } on TimeoutException catch (_) {
    // Ensure the WebView is disposed of in case of timeout
    await headlessWebView.dispose(); // Clean up resources
    return {
      'error': 'Timeout',
      'message': 'The operation took too long to complete.',
      'book_title': '$title',
      'book_author': '$author'
    };
  }
}

Stacktrace/Logs

Stacktrace/Logs
<Replace this line by pasting your stacktrace or logs here>

Flutter version
v3.22.0
Operating System, Device-specific and/or Tool
iOS
Plugin version
v6.1.5
Additional information
No response
Self grab

[X] I'm ready to work on this issue!

Probably it could be related on web caching and not related to this plugin. You can try to set the cache mode, for example on Android you can set a custom InAppWebView cache mode setting: https://pub.dev/documentation/flutter_inappwebview/latest/flutter_inappwebview/InAppWebViewSettings/cacheMode.html and for iOS you can try to set the URLRequest cache Policy parameter: https://pub.dev/documentation/flutter_inappwebview/latest/flutter_inappwebview/URLRequest/cachePolicy.html
In any case, you should use an API (REST or whatever) to do what you are doing here for best performance.
If there isn’t any API available other then doing web scraping, then you should expect possible delays as you are loading a full web page under the hood, with all assets etc.

Thanks for the quick feedback. Unfortunately, there is no API so web scraping is my only option. The performance is not bad overall, except as I said when I initiate the web view for the first time.
Sorry for my ignorance, but where am I supposed to set this cache mode?
Thanks!

On Oct 20, 2024, at 11:52 AM, Lorenzo Pichilli @.***> wrote:
Probably it could be related on web caching and not related to this plugin. You can try to set the cache mode, for example on Android you can set a custom InAppWebView cache mode setting: https://pub.dev/documentation/flutter_inappwebview/latest/flutter_inappwebview/InAppWebViewSettings/cacheMode.html and for iOS you can try to set the URLRequest cache Policy parameter: https://pub.dev/documentation/flutter_inappwebview/latest/flutter_inappwebview/URLRequest/cachePolicy.html
In any case, you should use an API (REST or whatever) to do what you are doing here for best performance.
If there isn’t any API available other then doing web scraping, then you should expect possible delays as you are loading a full web page under the hood, with all assets etc.
—
Reply to this email directly, view it on GitHub https://github.com/pichillilorenzo/flutter_inappwebview/issues/2361#issuecomment-2425059991, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWYTRFXW3CZUQFJ23OEJTVTZ4PGVJAVCNFSM6AAAAABQIT3F2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRVGA2TSOJZGE.
You are receiving this because you authored the thread.

If the issue can be produced in iOS only, it seems to relate with the this issue. (https://github.com/pichillilorenzo/flutter_inappwebview/issues/2321)


Remove corrupt visible testing annotation in function workers

Motivation
Remove corrupt visible testing annotation in function workers, make code reader confusing
Modifications

Remove corrupt visible testing annotation
fix a typo
rename a unused method since 2017

Documentation
Check the box below and label this PR (if you have committer privilege).
Need to update docs?

[x] no-need-doc
simple internal changes

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

Lgtm
What do you mean with 'corrupt'? Do you mean 'wrong ' ?

I mean, After a long time, the method annotated VisibleTesting has already been used by src code

Lgtm
What do you mean with 'corrupt'? Do you mean 'wrong ' ?

I mean, After a long time, the method annotated VisibleTesting has already been used by src code


Configparser setup: figuring out config.py, constants.py, dirs.py, CLI arguments, and more [WIP]

Ok y'all, this is a doozy. I've been working on this and there's a few things that we need to decide as an organization. I'm going to try to make my points clearly and I'll bold the points at which I need y'all's input.
Rationale
The current repo is very badly disorganized and needs a good cleanup. One of the sources of this is the fact that there are different ways of manipulating what manim does as a whole:

constants.py sets some global variables (most of which are actually constant, but some of which are not).
config.py parses the CLI arguments, uses it to set camera_config among other things. It also initializes directories.
HOWEVER, there is also a dirs.py file that allowed you to set default output directories. config.py reads that in as well as the CLI arguments.

As a result, I think it's quite the hurdle for a user to figure out where to get or set the value of a particular variable that determines how manim works.  Which has precedence over the other? If I want to change the resolution, should I do it in constants.py, by CLI argument, or in the CONFIG of my Scene objects?
The main purpose of this PR is to provide a single default source of global truth for configuring how manim works. (And, in the event that there is more than one possibility to set the value of a particular variable, the precedence between those possibilities should be very clear and documented.)
The proposal
The main way to do this is as follows. This PR makes it so that there is one single place to write/determine/set how manim works, and one single place to read/check/get those configurations once they are in place.

Write: The user can now use an optional manim.cfg file to tweak the default behavior. Note this is a file that the user can have on their machine without touching the manim codebase at all. We will also ship a default config file so the user doesn't need to have such a file, but can have one if they want it.
Read: once all configuration variables, directories, and CLI arguments have been parsed/processed, there is one single place where all of the configuration lives in for the rest of the execution: the global config dictionary that can now be imported by doing from .config import config (if within the library codebase) or by from manim import config (if importing the library as end user).

The constants.py file still exists, but as much as possible, it should not contain configuration variables, only constants. (more on this later).
How it works
I want to explain the main workflow of how this works. For this, note that there are two different ways of using manim: importing it as a library (to have access to Scene, Mobjects and so on), and as a  command line script (to actually render a video).
If being imported as a library, this is what's going to happen. The user will type from manim import * at the top of their file. This executes the contents of __init__.py, which in turn imports/executes config.py before anything else. config.py defines and exports the config dictionary by parsing the manim.cfg file. This config will now contain all configuration needed for the end user (and indeed for internal purposes as well). Finally, config.py will also setup some directories (more on this later). (Note that this is a very odd way of using manim, like for example if you open a python interpreter and type import manim. Importantly, this will also be the case during testing. In most cases, manim will be used in the other way, in the next paragraph.)
If being used from the command line, for example as python -m manim ... or as manim ... or as manimcm ..., the file that gets executed first is __main__.py. This file also imports/executes config.py as the first order of business. In this case, config.py will recognize it's being used from the command line and, after parsing manim.cfg first, it will also parse the CLI arguments. The CLI arguments will override the default settings defined in manim.cfg. At the end, the global config dictionary will contain all configuration that correctly corresponds to the defaults in the .cfg file as well as the CLI arguments.
The result
When manim is being used as a library, there is no visible change other than the fact that some imports of the type from manim.constants import SOME_VAR and then using SOME_VAR will become import manim.config as config and then using config['SOME_VAR'], because some variables (that weren't constants) have been moved from constants.py into the config dictionary. More on this later (see discussion points).
When manim is being used from the command line to actually generate scenes, the changes are as follows. All the command line arguments are still in place. BUT, now the user may set the defaults by using their own manim.cfg file. For example, the -p (or --preview) flag is turned off by default so if the user wants the movie to play after it's rendered, currently they need to always specify -p. After this PR, the user can create a new manim.cfg file with the line PREVIEW = TRUE. If they do so, running manim without the -p flag will still show the video once it's rendered. This has the advantage that if a user needs a particularly long CLI command with lots of flags to render their scenes, they can just dump all of those flags into the manim.cfg file and just run manim myfile.py. The manim.cfg file currently allows to set default values for each command line argument.
The discussion points
I'm just going to dump a bunch of issues here in no particular order. I'll do my best to be brief and to point exactly what needs to be answered/discussed/decided in bold.

The main problem here is that we are still conflating constants along with configuration variables, in the following way. The PIXEL_WIDTH (previously called DEFAULT_PIXEL_WIDTH) variable can be set in command line via the -l, -m, -e, -r flags. So it is not a constant, and it should live inside config, not in constants.py. This PR makes it so. Now, there are other values, for example FRAME_WIDTH, that directly depend on the value of PIXEL_WIDTH, thus they are also not constant. HOWEVER, the configparser library that parses .cfg files does not support arithmetic operations. So right now there is no easy way to only set PIXEL_WIDTH once and have FRAME_WIDTH and related variables update their values as well. Right now, in this PR this is being done in the constants.py file: it is loading the config dictionary, which contains PIXEL_WIDTH and defines the other variables accordingly. I very much don't think this should be merged as is, but I wanted to ask what is the best way to solve this, knowing that this cannot happen in the .cfg file? My suggestion is that this happens inside config.py, with a special function that defines those variables such as FRAME_WIDTH once PIXEL_WIDTH is set. However, this means that the user can set only the latter and the former will always be tied to it in the same hard-coded way. EDIT: I think a good example to fix this issue is to consider the question, where do we define TOP? Currently, it is defined in constants.py, with the line TOP = FRAME_Y_RADIUS * UP. Now, I think UP is a true constant and it should stay in constants.py. But FRAME_Y_RADIUS depends on FRAME_HEIGHT, which is not constant and is set by CLI argument in config.py. If we adhere to the strict view that only true constants must remain in constants.py, then TOP must go elsewhere.

Due to the above (some configuration variables are being loaded into constants.py), I converted all configs and constants to ALL_CAPS. Accordingly, the CONFIG dictionary of Scenes and Mobjects were also turned to ALL_CAPS. I think this is ugly as hell and hope this changes in the future. Fixing the issue of constants vs config variables should make this go away.

For the problem of importing config.py before anything else, see #26. I think we are in the clear here.

The current version does not work with python -m manim ... (see definition of prog in config.py). This is because it is actually very difficult to determine if the library is being imported or run from the command line (at least from the config.py file). I need suggestions for how to fix this.

This is a pretty big change so if there is anything that you can think of, please bring it up here.

Currently, all of the keys in SceneFileWriter.CONFIG are keys of the global config dict. Does SceneFileWriter really need a copy of each? Pinging @PgBiel here who is working on attrs.

Yes, this has been tested and renders scenes well. I have by no means ran an exhaustive test suite of all constants/configs/CLI flags yet.

List of changes
I'll list some of the minor changes made that are not big-picture issues. Please comment on these too if you have anything to say.

start_at_animation_number is now FROM_ANIMATION_NUMBER. Similarly, end_at_animation_number is now UPTO_ANIMATION_NUMBER. These are shorter and have the same meaning. (I don't like the ALL_CAPS, but that's a different issue touched upon above.)
dirs.py has been eliminated. Instead of dirs.video_dir, now you have to do config['VIDEO_DIR']. This will require changing from dirs import video_dir to from config import config and using config['VIDEO_DIR']. If we don't want to have to load the whole global config just for the one directory name, we can package the directories in a separate dict, also defined in config.py and load it as from config import dirs.
input_file_path has changed to INPUT_FILE, and file_name has changed to OUTPUT_FILE. The original names were just confusing.
The default configuration file is now packaged with the rest of the code, as seen in in setup.py.
DEFAULT_PIXEL_WIDTH, DEFAULT_PIXEL_HEIGHT, and DEFAULT_FRAME_RATE have been changed to PIXEL_WIDTH, PIXEL_HEIGHT, and FRAME_RATE. The reason is that once the config is read and the CLI arguments parsed, they are no longer a 'default' value, but possibly a value set by the user, so the names were misleading. The new names are also shorter.
PRODUCTION_QUALITY_CAMERA_CONFIG is now just the default config['CAMERA_CONFIG']. Also, note that config['CAMERA_CONFIG'] is changed by the *-quality flags (low-quality, medium-quality, high-quality) and by the --resolution flag.
The scene_names CLI argument is now --scene_names for easier parsing.
Changed open_video_upon_completion to PREVIEW so it has the same name as its corresponding CLI flag. It is also way shorter.
Removed the ignore_waits option which was never used and was set to the value of args.preview.
Most CLI flags have been changed to have no default value. For example, -p was by default False, but will now default to None. This is done that we can easily determine whether the user actually specified this flag by comparing it to None. If the flag is None, we read the default value from the manim.cfg file instead. Importantly, this is a subtle change in the code (see comments inside _parse_cli() in config.py if you are interested.
The way everything is setup right now, passing only the -s flag will also write a movie (since WRITE_TO_MOVIE is True by default in manim.cfg). See #41.

List of standing or future issues
While working on this, I realized there is a number of other things that I would also like to change, but I'm not sure if they should be part of this PR or a separate one.

I think there are a bunch of variables/constants that have DEFAULT_ in the name but that should not have it.
The output directories are being created during initialization (when config.py is read). I think the directories should be created at the last possible minute. If I run manim and it crashes before writing the scene, the directories will be created but empty.

PS
Mostly for my sanity: this interacts with #65, #81, #77 so I'll get back to those when this is merged.

After more thought, I have a proposal that would fix points 1, 2, and 3 under "The Discussion Points" above.
In the original code base, config.py sets a different dictionary for camera_config, file_writer_config, and the rest of configurations are put in constants.py. In the current PR, I put the camera_config and file_writer_config as sub-dictionaries of the new config dictionary. I was being a bit conservative about this, but now I'm proposing that we make full use of those.
I propose that we leave inside constants.py only those variables X such that the answer to the following question is "no": Would the user expect X to change from project to project? If the user has two entirely different projects for which they are using manim, and they would expect X to have the exact same value in both projects, then X should go in constants.py, and everything else should go in the config dict. For example, for X=PIXEL_WIDTH the answer is "yes" (as the user may be using different frame sizes for different projects), and therefore it should go in config. For DEFAULT_MOBJECT_TO_EDGE_BUFFER the answer is "no" because even if the user needs buffers of different sizes for their two projects, this variable defines the default buffer, not the buffer that the user will need every time. A true default should be the same across projects, so this goes in constants.py. This solves 1) above because both PIXEL_WIDTH and TOP could change from project to project, as they both depend on the frame size and its geometry.
Another reason why I was reluctant to put TOP inside the config dict is because it would be awkward to have to do config.top. However, this is where the camera_config comes in handy. I suggest that we put all of the parameters relating to the geometry of the frame inside a frame_config global object, or it could even be named frame, and be imported as from config import frame. Then the user can just use frame.top (or frame['top'] if it's a dict). I think frame.widthis much more pleasing than importingPIXEL_WIDTHinto the local scope, as it's currently done by the use offrom manim import *`.
So, to sum up (and I do apologize for the literal walls of text in this PR), I'm suggesting that on top of the current PR, we take out (many) more variables out of constants.py into different objects/dicts that group them semantically. Concretely, I propose that we use the existing camera_config but expand it to contain all variables relating to the geometry of the frame/scene (and perhaps rename it to just frame), and use file_writer_config to contain all of the variables relating to writing files. In particular, we should move all of TEX_USE_CTEX, VIDEO_DIR, MEDIA_DIR to the file_writer_config (as the user could expect it to change from one project to another).
Please let me know if this makes sense, as this will involve quite a bit more refactoring and it will most likely break old code.

My remarks so far before I go to sleep

HOWEVER, the configparser library that parses .cfg files does not support arithmetic operations.

Alternatives:

Allow eval() of inputs;
Have the config file be read as a .py file (and, therefore, require this format). Could be better for customizability and a few other factors, but... this idea is debatable

Due to the above (some configuration variables are being loaded into constants.py), I converted all configs and constants to ALL_CAPS. Accordingly, the CONFIG dictionary of Scenes and Mobjects were also turned to ALL_CAPS. I think this is ugly as hell and hope this changes in the future. Fixing the issue of constants vs config variables should make this go away.

Please, please, please have the config params be in lower (snake) case...

Currently, all of the keys in SceneFileWriter.CONFIG are keys of the global config dict. Does SceneFileWriter really need a copy of each? Pinging @PgBiel here who is working on attrs.

To be used with attributes yes. However, we do not need that, of course. We can just have the config dict be stored in some shape-free dictionary or something... This is, if the config types and whatnot are specified somewhere else (E.g. in some sort of Config class or w/e). Otherwise, we should use attributes in our favor, as they allow us to document each type and name.

@PgBiel

Allow eval() of inputs;

I think eval() should be our last resort.

Have the config file be read as a .py file (and, therefore, require this format). Could be better for customizability and a few other factors, but... this idea is debatable

Yes, there are libraries whose configuration files are just plain .py files. However I'm still not sure we need the full power of that yet.

Please, please, please have the config params be in lower (snake) case...

Yes! My latest comment would achieve this, but it comes with the price of breaking changes (or DeprecationWarnings).

Have the config file be read as a .py file (and, therefore, require this format). Could be better for customizability and a few other factors, but... this idea is debatable

Yes, there are libraries whose configuration files are just plain .py files. However I'm still not sure we need the full power of that yet.

I really like the idea of using .py files for custom configuration. It offers a lot of space to expand if need be and could be used by any extensions to manim as well.

Extensions/addons are actually a compelling argument.
In that case, the structure would probably look like this:

have one constants.py file (with ALL_CAPS, truly constant values),
have one master config.py which contains all the logic for default configuration,
before returning, the config.py could also load other user-defined or addon-defined configuration files to override the defafults.
before returning, the config.py could also parse CLI arguments, if called from the command line, to override the defaults.

This seems achievable. However, we still have the problem that it is very difficult to detect when manim has been called from the command line (see discussion point 4 in the OP).

I really like the idea of using .py files for custom configuration. It offers a lot of space to expand if need be and could be used by any extensions to manim as well.
IMO it makes more sense if it's a .cfg file. If we want that the user to be able to create his own config without touching the manim codebase at all, a .py is a bad idea as it will certainly confuse some people who won't understand what file to run - why - where.
I mean, put yourself in the mind of a python beginner; you would way better understand the config system with a .cfg than with a .py.

To solve the problem of the arithmetic operations,

have one master config.py which contains all the logic for default configuration,
before returning, the config.py could also load other user-defined or addon-defined configuration files to override the defaults.
before returning, the config.py could also parse CLI arguments, if called from the command line, to override the defaults.

That is the best idea. In addition, we wouldn't be too far from the actual functioning.
And a config.py will be the place to handle when arguments miss (i.e not specified in the args or in the config file, due to a user mistake)

On the problem of moving the arithmetic operations from constants.py to config.py:

It should leave constants.py not because of the arithmetic, but because it depends on the user defined value FRAME_WIDTH.
I'm more and more convinced it should just go on config.py. After all, this is currently the file that parses user input (through CLI arguments or through the .cfg file).
My initial hesitation was because the config.py is already a bit bloated as it is, and I didn't want to add even more specific logic. HOWEVER, I think the fix is to have a FrameConfig class in config.py, which processes/parses/sets all the frame and camera configurations. That way all this logic will be encapsulated in a single class. Again, only one source of truth, as opposed to this logic being strewn around the config.py file. Then, config.py can export a FrameConfig object, or just the __dict__ of it.

And a config.py will be the place to handle when arguments miss (i.e not specified in the args or in the config file, due to a user mistake)

Small clarification: this will never happen, because there will always be a .cfg file shipped with manim. If the user doesn't specify a CLI argument or a .cfg file, there will be a library-wide .cfg file to set defaults.

OK I just figured out how to solve problem 4) above. It's hacky, but it will work.
Also, a lot of the constant/config variables are only ever used by scene_file_writer.py. I'm thinking another thing we can do is group all of those into a single dict that is then just passed directly to scene_file_writer.py instead of putting them into the global dict. No need to expose them to the user since the user never really needs them.

OK I heard y'all loud and clear and just pushed some changes. Let me summarize:

After the latest commit, even more variables have been taken from constants.py and put into config.py. Now constants only contains variables that will never change. Now constants are ALL_CAPS while configuration variables (the keys in the global config dict are snake_case).

I realized that the vast majority of config variables were related to output/writing/files and only ever used internally. I can't think of a reason why the user would ever touch those variables when writing a Scene. Therefore, I split the config variables into two global dictionaries: config, meant to store stuff the user will use, and file_writer_config, meant to be used internally by manim when writing output. Both are global dicts so the user can access the latter too if required, but now the dict manim.config contains only stuff that the user is more likely to need when writing Scenes.

The file extract_scene.py has been copy-pasted onto __main__.py, since that was basically what it was. All other things that  __main__.py was doing other than execute extract_scene.main have moved to config.py.

The CONFIG dictionaries of a couple of classes have been removed, since they were only ever using the variables found in the global file_writer_config and the instances of those classes never needed their own copy. This should affect the move to attr/dataclasses @PgBiel.

This all now works when being called as manim ..., manimcm ..., or python -m manim .... The latter is a hack, but it works @eulertour.

I tested this and it seems to be working!

I think this is ready for a more thorough review, so I'm taking away the "draft" label.

The build is failing 😕. But besides that, the arguments are parsed incorrectly for me if I run it with manim ... or manimcm ... (python -m manim ... works).

I also noticed that the -l and --low_quality flags aren't working anymore. I didn't test the other quality flags, but if this one isn't working I suspect the others are broken as well.

I also noticed that the -l and --low_quality flags aren't working anymore. I didn't test the other quality flags, but if this one isn't working I suspect the others are broken as well.

Yep, I currently fixed it on my local repo, but currently struggling with the build failing...

Phew. Pretty sure I just fixed all standing issues. @eulertour now both python -m manim and manim work on my local.

OK so tests pass on linux and OSX, but not on Windows. The problem is still a ffmpeg problem, here is the relevant code:
        if file_writer_config['write_to_movie']:
>           self.writing_process.stdin.write(frame.tostring())
E           BrokenPipeError: [Errno 32] Broken pipe
manim\scene\scene_file_writer.py:315: BrokenPipeError

FAILED tests/test_sample_scenes.py::test_scenes - BrokenPipeError: [Errno 32]...

The -o flag seems to be doing something where it outputs the video relative to the resolution directory, e.g. manim example_scenes/basic.py SquareToCircle -plo ./vid.mp4 writes to  /path/to/pwd/media/videos/basic/480p15/./vid.mp4.
However, this also happens on master, so I've opened a new issue for it (#136).

Before merging this, we must make sure it's backwards compatible. This requires at least to return all those variables that were removed from constants.py...

The builds now consistently pass on linux and OSX, but consistently fail on Windows, with either a OSError: invalid argument, or a BrokenPipeError. This seems to be documented here, though I can't find a fix yet.

constants.TEX_TEMPLATE isn't an actual constant and also needs to be moved out of there. It being in there but not actually constant also seemingly causes issues with my multiprocessing attempts.
On another note, with the big tex change recently some more of the code in this PR has gone stale and there'll be more conflicts. I'd advise wrapping this up quickly since this PR is now 2 weeks old, and so is some of the stale code.

Everything here LGTM as soon as the merge conflicts are fixed.

what about my suggestions? Do you agree with them?

Yeah, your suggestions look good too.

Looks like I spoke too soon. Now all files are being written as .mp4, e.g. media/videos/basic/480p15/.mp4.

@PgBiel all your changes have been added as of the latest commit.
@eulertour I can't replicate that behavior. What is the exact command you are using?

@eulertour I was able to replicate it and fix it. Also fixed merge conflicts.

Linux builds passed, and 2/3 OSX builds passed. The one that failed was due to brew taking too long to download/install things and the build timed out. (We should probably set the timeout to a larger value since we are dealing with brew in each build, but that's a separate issue.)

Since write_to_movie and save_last_frame don't use this logic, running with -pls causes the last frame to be displayed and the video to be played immediately afterward. Additionally, the video is generated even when -s is passed, which means the flag doesn't save time anymore.

The message Ignoring --media_dir, since both --tex_dir and --video_dir were passed. is printed no matter what. I actually wouldn't mind removing the message entirely. It's technically wrong anyway since the user might have specified a --tex_dir and --video_dir which are underneath the --media_dir.

Since write_to_movie and save_last_frame don't use this logic, running with -pls causes the last frame to be displayed and the video to be played immediately afterward. Additionally, the video is generated even when -s is passed, which means the flag doesn't save time anymore.

Yes, that logic is invalidated by moving to the .cfg file, and I forgot to raise the question of whether we want -s to invalidate the default behavior of writing a movie. Is this what we want? If so, I can add this change and document it as well.

The message Ignoring --media_dir, since both --tex_dir and --video_dir were passed. is printed no matter what. I actually wouldn't mind removing the message entirely. It's technically wrong anyway since the user might have specified a --tex_dir and --video_dir which are underneath the --media_dir.

Again, I forgot to raise this for discussion. I was leaving this for discussion when resolving #66. However, I also vote for scrapping this logic as well as the message for now in this PR.

I forgot to raise the question of whether we want -s to invalidate the default behavior of writing a movie. Is this what we want?

Yes, the purpose of this option is to save time over rendering each frame of the video.

Just pushed some changes: the -s flag should now work, and the Ignoring ... message is gone.

There are a few other changes that could be made to the CLI flags. For example, the -w flag is now basically obsolete. However, I suggest that we deal with those in other issues/PRs and merge this ASAP. Many other PRs/issues are being held up by the .cfg structure specifically.

Latest travis build passes on Linux/OSX, and the Windows builds will be made optional by #133. Are we ready to merge? @eulertour @PgBiel

The -s option is still slow. 😕

The -s option is still slow.

Can you please clarify what you mean? Here I'm copying the timeing of using the -s flag at 4k resolution:
$ time manim -ks basic.py SquareToCircle
<omitted manim output>
real	0m3.138s
user	0m3.311s
sys	0m0.320s

$ time manim -k basic.py SquareToCircle
<omitted manim output>
real	0m21.378s
user	0m33.739s
sys	0m9.617s

--media_dir is also leaving an empty directory.

Yes, it does. This is point number 2 under "List of standing or future issues" all the way back on the original post of this PR. It is my impression that this was always the case in 3b1b manim (tho I may be wrong?). I think the fix here is to make the file writer lazy and create the directories only at the last possible minute. Is this something we want to implement on this PR or leave for later? Like I said, I'm trying to merge this ASAP as so many other issues are being held up. I can try to make the file writer lazy right after this is merged tho.

Could you please be more specific? I don't know how a function would help
here since __main__.py is importing config.py, and there is no way of
sending information to the imported module. If by global variable you mean
that __main__.py could export a variable that then config.py would
read: I'd hesitate to do that because in that case each module would be
importing the other one and I'm not sure that's necessary.
The current way is very hacky and ugly but it works and it doesn't involve
circular imports.
On Wed, Jun 17, 2020, 8:42 AM Pg Biel<EMAIL_ADDRESS>wrote:

@PgBiel commented on this pull request.
In manim/config.py
https://github.com/ManimCommunity/manim/pull/98#discussion_r441514010:

if filename and not os.access(filename, os.R_OK):

   # custom template not available, fallback to default

   logger.warning(

       f"Custom TeX template {filename} not found or not readable. "

       "Falling back to the default template."

   )

   filename = ""

if filename:

   # still having a filename -> use the file

   constants.TEX_TEMPLATE = TexTemplateFromFile(filename=filename)

else:

   # use the default template

   constants.TEX_TEMPLATE = TexTemplate()

+def _from_command_line():

"""Determine if manim was called from the command line."""

We can probably let the main.py module signal this by a function or
global variable or something like that. That might be the best way to go
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ManimCommunity/manim/pull/98#discussion_r441514010,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAILYAHYF3LF37UCHVISV33RXC2ZVANCNFSM4NMGRN7A
.

we could create a file in utils or something with a function called set_is_main or set_main, which sets the variable is_main that would be exported by this file

Leaving the --media_dir empty is probably fine if we open a follow-up issue. As for -s being slow I mean it's slower that it is on the master branch, which leads me to believe that it's still generating video but then only displaying the last frame.
Whatever you decide regarding the two dictionaries is probably fine by me, I just wanted you to be aware.

Thanks everyone for the comments and reviews. It seems that the core changes to the config system are not subject for debate anymore so in the interest of merging this, I'll fork the current standing discussions into separate issues on their own. Now we are just waiting for #33 to merge, after which I'll update this branch and merge it ASAP.

The problem with the slow rendering is caused because the Scenes are being initialized incorrectly.
https://github.com/ManimCommunity/manim/blob/b6603037f248c24324c6ab10b4bee95904923bb8/manim/__main__.py#L155
Compare to master:
https://github.com/ManimCommunity/manim/blob/4b6492b0e7e7e4ae7e35938662571ad765027f3c/manim/extract_scene.py#L176
The tests are still failing after the update; they aren't reading the config variables correctly. One error I got was NameError: name \'FRAME_WIDTH\' is not defined.
But you can't get that far without patching the testing code because it's currently reading the wrong path and won't tell you what path it's failing to read since the error is caught and another one is thrown in its place:
https://github.com/ManimCommunity/manim/blob/b6603037f248c24324c6ab10b4bee95904923bb8/tests/testing_utils.py#L57-L63
The scene data shouldn't be loaded this way. Instead we should just attempt to load the file and let the exception be thrown if it fails.

Actually even the tests that don't run into errors loading config variables are failing from another error: fixture 'get_config_test' not found. It seems like the tests are causing more problems than they're solving here, so if the other problems are fixed I'd be fine ignoring them.

Actually even the tests that don't run into errors loading config variables are failing from another error: fixture 'get_config_test' not found. It seems like the tests are causing more problems than they're solving here, so if the other problems are fixed I'd be fine ignoring them.

This is a very easy fix, get_config_test is a pytest fixture that is now deprecated. To me, the tests are working fine, they are just not updated yet. We can ignore them if you want, but then I don’t get the point of having tests if we ignore them every time they fail

The scene data shouldn't be loaded this way. Instead we should just attempt to load the file and let the exception be thrown if it fails.

I designed that to be used by pytest, and it appears that it is the correct way to do it when one wants to catch a custom exception (see https://docs.pytest.org/en/stable/assert.html).
If we do what you're suggesting, we won't be able to show that "x has not pre-rendered data blahblah".

I see three different comments here.

The change from SceneClass(**scene_kwargs) to SceneClass() is intentional and necessary. This is because the scene_kwargs were passing around values that can now be read through the global config. Also, I don't see why this would cause the rendering to be slower.

The constant FRAME_WIDTH has been deprecated and is now config['frame_width']. I just caught and changed two instances of the former that I missed.

The fixture get_config_test has been deprecated, as @huguesdevimeux pointed out. Similarly to **scene_kwargs, this was being used to get some test-specific config values to the scenes to be tested. These are now specified in tests/manim.cfg. I just caught and changed some instances that I missed.

** Also, importantly, I can't believe I failed to say this: the command pytest is meant to be ran from within the tests/ directory, not from the root directory. This is because of how the config files work in a cascading way, so pytest must be ran from within the appropriate directory to read the tests/manim.cfg file. ** @eulertour perhaps this interacts with point 1.?

@huguesdevimeux

To me, the tests are working fine, they are just not updated yet. We can ignore them if you want, but then I don’t get the point of having tests if we ignore them every time they fail

Since this PR has already been blocking development for weeks, we've been developing without any tests up to this point for better or for worse, and adding the tests are causing more problems to solve, I'd be fine with it in this instance. I do think all of the test-related issues should be fixed eventually.

I designed that to be used by pytest, and it appears that it is the correct way to do it when one wants to catch a custom exception (see https://docs.pytest.org/en/stable/assert.html).

The page you linked is describing how to write assertions about raised exceptions, but in load_data() we need only raise an exception if the can't be loaded. There's no need to use a custom exception and in this case it works against us since we can't see the file that's failing to load.

If we do what you're suggesting, we won't be able to show that "x has not pre-rendered data blahblah".

This is true, but we will see No such file or directory: '<attempted file>' which is more informative for debugging.
@leotrs

The change from SceneClass(**scene_kwargs) to SceneClass() is intentional and necessary. This is because the scene_kwargs were passing around values that can now be read through the global config.

Gotcha, that's fine.

Also, I don't see why this would cause the rendering to be slower.

It's basically this snippet https://github.com/ManimCommunity/manim/blob/4b6492b0e7e7e4ae7e35938662571ad765027f3c/manim/scene/scene.py#L682-L686
scene.py checks that instance variable in order to determine whether or not to skip to the end of an animation and since it wasn't being set on the instance it was no longer skipping when -s was passed.
Points 2 and 3 are fine though I don't think the config files are causing the problem with the tests, at least not from what I've seen so far.

Since this PR has already been blocking development for weeks, we've been developing without any tests up to this point for better or for worse, and adding the tests are causing more problems to solve, I'd be fine with it in this instance. I do think all of the test-related issues should be fixed eventually.

Alright, as you wish.

This is true, but we will see No such file or directory: '<attempted file>' which is more informative for debugging.

I see, you are right. thank you very much for this comment.
maybe @leotrs can quickly fix this in this PR ?

I actually wanted to add something related to the cascading config files: I don't think config files from the directory where we start manim should be considered. Instead we should only use the global config, one in the home directory, and one in the directory where the script is located.
The reasoning is that it doesn't make much sense for a Scene to render differently depending on the place where it's run.

Fully agreed with you there RE the cascading files.


sync 1.19.2 to 0.76.0

was a simple merge, all tests pass! (well, except the recipe remainder one that's been broken for a while)

not sure fixing licenses for older versions is worth it :p


Improve flexibility of leapfrog in master

This introduces the loading of post leap and pre leap steps.
Connected https://github.com/rcbops/u-suk-dev/issues/1734

This will be dropped, as we now have newton 14.1 branch, and leapfrog code should only be in newton 14.1 branch.


Does not return error code correctly to calling environment

In many cases MITgcm does not return an error code to the calling process when it crashes.
This means the process that ran MITgcm can't determine if it failed, so continues to try and run again from the last pickups, and fails as they have not been produced.
I've looked at the code in
https://github.com/MITgcm/MITgcm/blob/3d78cbf592e055ff89efdfcda46f3d4bd5447156/eesupp/src/all_proc_die.F
but:

It is not always called when there is an error condition detected
It does not call MPI_Abort(), which is what I thought should be the correct behaviour

Searching for ABNORMAL END is a good idea.
If your setup produces pickups at the end of the simulation that would also be a good test. There is a flag to always produce a (rolling) pickup at the end of the simulation, writePickupAtEnd. Otherwise, you need to make sure that pChkPtFreq is set so that your simulation produces a pickup just before it ends.

I do this:
lastline=`tail -1 STDOUT.0000`
testline=`echo $lastline  | grep 'Execution ended Normally'`

and then only continue if "testline" is not empty, that is usually quite safe.

There are 2 different things reported here:

the way the MITgcm terminates and related MPI_Abort() call ;
the way one can check if the run did reach the end to the specified integration.

I think this second aspect has been answered here above. And the first point is discussed in this specific issue #439 .
So going to close this issue.


Feat(ux):  store Collections' opened folders state (e.g. avoid resetting the opened folders state when navigating away and coming back)

Is your feature request related to a problem? Please describe.
When opening one or more collection folders and/or sub-folders, as you are currently working in some of those, sometimes you want to go check something else located somewhere else in the app, like another tab from the left nav, but then, when coming back to the Collections tab, all your opened folders have been reset and are all collapsed, which is annoying since you need to re-open them all again every time.
Describe the solution you'd like
Save/persist the state of the collections' opened folders, so that when navigating away from the "Collections" tab, for instance when viewing your Environment env vars, and then coming back to your "Collections" tab, all your 'currently under work' collections' folders/sub-folders remain opened.
Bonus point in adding some button to collapse all opened collections' folders and sub-folders, but this is much less needed than what is described above.
Describe alternatives you've considered
Well, as mentioned, currently the alternative is to always have to re-open your collections folders/sub-folders manually, which is just annoying when clicking around and using the tool extensively, but at least this is not a show-stopper, but definitely a great to have in terms of overall UX.
Additional context

@frank-duq this has been addressed in V#1.0.69 , please update to latest.

Confirmed, it's working, very niice, thanks!


Add automated tests of existing features/samples

So far we have only build tests in CI. Those work well, but they do not check if something was broken in runtime. We need to develop automated tests, which will run whenever we refactor code, add more features or want to test with newer Zephyr (or some library) release.
In the first step it makes most sense to use simulated device (e.g. QEMU, native_posix) to execute SDK samples / tests. This will cover 80-90% of the codebase already. Next step would be to use reference hardware boards officially supported by Golioth. This however requires more effort, but is the only way to increase code coverage of the samples we provide.
Originally reported by @mniestroj

Related: https://github.com/golioth/zephyr-sdk/issues/35

Already covered.


Possibilities to use ng-animate or other ways of animation

This library widely used to display different tree structures and it can be nice to have possibility to use some kind of animation. For example ng-animate lib.

+1

+1

+1

+1

+1

+1
On Wed, Sep 2, 2015 at 3:13 AM, Andrew Boni<EMAIL_ADDRESS>wrote:

+1
—
Reply to this email directly or view it on GitHub
https://github.com/wix/angular-tree-control/issues/143#issuecomment-136908178
.

will be great to get ideas how to incorporate animations into the tree without forcing animations on all users.

By writing an attribute directive with value animate="on" (or)
animate="off".
On Wed, Sep 2, 2015 at 9:48 AM, Yoav Abrahami<EMAIL_ADDRESS>wrote:

will be great to get ideas how to incorporate animations into the tree
without forcing animations on all users.
—
Reply to this email directly or view it on GitHub
https://github.com/wix/angular-tree-control/issues/143#issuecomment-136966545
.


Minecraft 1.12.2 Bug

No Chronicle of Shadows.

nope, 1.12 doesnt have it. 1.12 is not supported.


[Feature]: Add a health endpoint to all services

Describe the feature
Details
We want to eventually send a notification to users when their service goes down. But for this we need to know a service is still healthy.
Requirements

Create a /healthz endpoint on every service under /services

Have return just a status code of 200

Suggestion or Example of how the feature would be used
No response
Duplicate declaration

[X] I have searched the issues and this feature has not been requested before.

I will also be working this

The team is evaluating a new approach to this problem.

Closing this in favour of #1557


kamithanthanh

check prime number between 1-100
What does the program do ?

check prime number between 1-100
In what programming language it is written?
python

Thank you for participating  in hacktoberfest ❣ if you liked working on this repo you can share it with friends and star this project for helping others


Bug: We aren't escaping filter values properly when filters are added through UI

When I try to add Levi's through the filter UI in the composer, I can't save it:

I get these errors in the console
Error: Error(s) compiling model:
FILE: internal://internal.malloy
line 1: extraneous input 's' expecting {AGGREGATE, DECLARE, GROUP_BY, HAVING, INDEX, JOIN_CROSS, JOIN_ONE, JOIN_MANY, LIMIT, NEST, ORDER_BY, PROJECT, SAMPLE, TOP, WHERE, '}', ';'}
  | query: the_query is order_items -> { group_by: one is 1; where: inventory_items.product_brand = 'Levi's'}
  |                                                                                ^
line 1: mismatched input ''' expecting {AGGREGATE, DECLARE, GROUP_BY, HAVING, INDEX, JOIN_CROSS, JOIN_ONE, JOIN_MANY, LIMIT, NEST, ORDER_BY, PROJECT, SAMPLE, TOP, WHERE, AND, DAY, FOR, HOUR, MINUTE, MONTH, OR, '?', QUARTER, SECOND, TO, WEEK, YEAR, '&', '{', '}', '::', ':', ',', '.', '<', '>', '=', '!=', '<=', '>=', '+', '-', '*', '/', '|', ';', '!~', '~'}
  | query: the_query is order_items -> { group_by: one is 1; where: inventory_items.product_brand = 'Levi's'}
  |                                                                                ^
    at Gc.compile (app.js:1214:4987)
    at P3e (app.js:2275:743)
    at async U3e (app.js:2275:921)
    at async Hg (app.js:2275:1140)
    ```

Assigning to you @christopherswenson since you'll be touching filter stuff shortly


Delivery API: call to get all unique reports a Facility contributed to for a Receiver

Problem statement
As a Receiver, I need to be able to call the API and receive all unique facilities that have reported to me.
What you need to know
STLT Feature Ideas (Mural): https://app.mural.co/t/primedatainput6410/m/primedatainput6410/1660849046968/e257020850ab71f57b31120e27ec06203ae9c22b?sender=u67aa35711489d1496d0a7320
Stock of API functionality (Word): https://cdc.sharepoint.com/:w:/t/USDSatCDC/EXXo_HDcvhNBre9FnV_37pkBjNFwK7ZryxjpTROmxllQrg?e=VYoo3C
Acceptance criteria

[ ] ...

To do

[ ] ...

Dupe of #6845


Theme stopped updating

Version
1.1.2 on React Native
Expected Behavior
All components that use { theme } update when the theme is changed.
Actual Behavior
Most of components stopped updating the colors after migrating from v1.1.1 to v1.1.2.

That must be #253? @michalkvasnicak

@mxstbr yeah it is but I am not using react-native so I don't know how to test it.
Only difference between StyledComponent and StyledNativeComponent is this line https://github.com/styled-components/styled-components/blob/master/src/models/StyledNativeComponent.js#L31. I forgot to set this to null.
@brunolemos Are you changing theme using the ThemeProvider?

Ok I will try.

@mxstbr I couldn't get this worked. npm run ios is failing with this output.
Found Xcode project native.xcodeproj
Launching iPhone 6 (iOS 10.1)...
Building using "xcodebuild -project native.xcodeproj -scheme native -destination id=ACA806AE-5F06-45B7-ABB1-51D0E52A3F70 -derivedDataPath build"
User defaults from command line:

    IDEDerivedDataPathOverride = /Users/Michal/Work/styled-components/example/native/ios/build

=== BUILD TARGET native OF PROJECT native WITH CONFIGURATION Debug ===

Check dependencies

CompileC build/Build/Intermediates/native.build/Debug-iphonesimulator/native.build/Objects-normal/x86_64/AppDelegate.o native/AppDelegate.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler
    cd /Users/Michal/Work/styled-components/example/native/ios
    export LANG=en_US.US-ASCII
    export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/Users/Michal/.nvm/versions/node/v6.9.1/lib/node_modules/npm/bin/node-gyp-bin:/Users/Michal/Work/styled-components/example/native/node_modules/.bin:/Users/Michal/.nvm/versions/node/v6.9.1/bin:/usr/local/opt/php56/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin:/usr/local/MacGPG2/bin:/usr/local/opt/go/libexec/bin:/Users/Michal/Work/Go/bin"
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -arch x86_64 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -std=gnu99 -fobjc-arc -fmodules -gmodules -fmodules-cache-path=/Users/Michal/Work/styled-components/example/native/ios/build/ModuleCache -fmodules-prune-interval=86400 -fmodules-prune-after=345600 -fbuild-session-file=/Users/Michal/Work/styled-components/example/native/ios/build/ModuleCache/Session.modulevalidation -fmodules-validate-once-per-build-session -Wnon-modular-include-in-framework-module -Werror=non-modular-include-in-framework-module -Wno-trigraphs -fpascal-strings -O0 -Wno-missing-field-initializers -Wno-missing-prototypes -Werror=return-type -Wunreachable-code -Wno-implicit-atomic-properties -Werror=deprecated-objc-isa-usage -Werror=objc-root-class -Wno-arc-repeated-use-of-weak -Wduplicate-method-match -Wno-missing-braces -Wparentheses -Wswitch -Wunused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wempty-body -Wconditional-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wconstant-conversion -Wint-conversion -Wbool-conversion -Wenum-conversion -Wshorten-64-to-32 -Wpointer-sign -Wno-newline-eof -Wno-selector -Wno-strict-selector-match -Wundeclared-selector -Wno-deprecated-implementations -DDEBUG=1 -DOBJC_OLD_DISPATCH_PROTOTYPES=0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator10.1.sdk -fasm-blocks -fstrict-aliasing -Wprotocol -Wdeprecated-declarations -mios-simulator-version-min=8.0 -g -Wno-sign-conversion -Wno-infinite-recursion -fobjc-abi-version=2 -fobjc-legacy-dispatch -iquote /Users/Michal/Work/styled-components/example/native/ios/build/Build/Intermediates/native.build/Debug-iphonesimulator/native.build/native-generated-files.hmap -I/Users/Michal/Work/styled-components/example/native/ios/build/Build/Intermediates/native.build/Debug-iphonesimulator/native.build/native-own-target-headers.hmap -I/Users/Michal/Work/styled-components/example/native/ios/build/Build/Intermediates/native.build/Debug-iphonesimulator/native.build/native-all-target-headers.hmap -iquote /Users/Michal/Work/styled-components/example/native/ios/build/Build/Intermediates/native.build/Debug-iphonesimulator/native.build/native-project-headers.hmap -I/Users/Michal/Work/styled-components/example/native/ios/build/Build/Products/Debug-iphonesimulator/include -I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include -I/Users/Michal/Work/styled-components/example/native/ios/../node_modules/react-native/React -I/Users/Michal/Work/styled-components/example/native/ios/build/Build/Intermediates/native.build/Debug-iphonesimulator/native.build/DerivedSources/x86_64 -I/Users/Michal/Work/styled-components/example/native/ios/build/Build/Intermediates/native.build/Debug-iphonesimulator/native.build/DerivedSources -F/Users/Michal/Work/styled-components/example/native/ios/build/Build/Products/Debug-iphonesimulator -MMD -MT dependencies -MF /Users/Michal/Work/styled-components/example/native/ios/build/Build/Intermediates/native.build/Debug-iphonesimulator/native.build/Objects-normal/x86_64/AppDelegate.d --serialize-diagnostics /Users/Michal/Work/styled-components/example/native/ios/build/Build/Intermediates/native.build/Debug-iphonesimulator/native.build/Objects-normal/x86_64/AppDelegate.dia -c /Users/Michal/Work/styled-components/example/native/ios/native/AppDelegate.m -o /Users/Michal/Work/styled-components/example/native/ios/build/Build/Intermediates/native.build/Debug-iphonesimulator/native.build/Objects-normal/x86_64/AppDelegate.o

/Users/Michal/Work/styled-components/example/native/ios/native/AppDelegate.m:12:9: fatal error: 'RCTBundleURLProvider.h' file not found
#import "RCTBundleURLProvider.h"
        ^
1 error generated.

** BUILD FAILED **

The following build commands failed:
        CompileC build/Build/Intermediates/native.build/Debug-iphonesimulator/native.build/Objects-normal/x86_64/AppDelegate.o native/AppDelegate.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler
(1 failure)

Installing build/Build/Products/Debug-iphonesimulator/native.app
An error was encountered processing the command (domain=NSPOSIXErrorDomain, code=22):
Failed to install the requested application
The bundle identifier of the application could not be determined.
Ensure that the application's Info.plist contains a value for CFBundleIdentifier.
Print: Entry, ":CFBundleIdentifier", Does Not Exist

Command failed: /usr/libexec/PlistBuddy -c Print:CFBundleIdentifier build/Build/Products/Debug-iphonesimulator/native.app/Info.plist
Print: Entry, ":CFBundleIdentifier", Does Not Exist

Have the same behavior with React after upgrade from 1.0.3 version. Don't know, maybe I'm doing something wrong, but think it is important. I've tried previous versions before #253, themes work with #252 bug, but work.

Hey, that's not just a problem with React Native. It's not working with React as well.

It's not working with React as well.

@michalkvasnicak can you reproduce that?

@mxstbr I will take a look. With react-native I have problem, I can't to get build working (see above).

@mxstbr Ok I can reproduce that in test case ( current test cases are not enough because they test generated css but don't check if className is correct ).

Could someone try #262  (react and react-native too)?


[i18n | WIP] French locale

Hello,
I am currently working on a French locale for the software in my free time.
As it is a time consuming process (and I do not necessarily put all my free time in it neither), I was wondering if I should wait for it to reach a certain amount of completion or I could send it in batches.
For now I am aiming my efforts on the 1st level items without having any repo opened yet.
I still need to translate the preferences and keyboard shortcut to finish that 1st step.
Kind Regards

First of all, thank you very much for taking the time to help this project become better.

I was wondering if I should wait for it to reach a certain amount of completion or I could send it in batches.

As long as your translation have used en_US as fallback locale in this way:
<ResourceDictionary.MergedDictionaries>
  <ResourceInclude Source="avares://SourceGit/Resources/Locales/en_US.axaml"/>
</ResourceDictionary.MergedDictionaries>

you can send you PR to this project anytime.

Thanks for the answer.
It was indeed missing.
I just made the change.
I shall rather go in batches.
I will finish preferences and keyboard shortcut for this week-end and I'll pursue likely with the main window when a repo is opened for the next batch.

PR #405


HTTP 404 in teach-class when creating a new caption-this repo

Here is the output:
Running script/create-initial-repo
What would you like to name the repo? flutterint
Checking if that repo name is available... [https://github.com/ps-developers-sandbox/flutterint]
Repo name is available!
Creating repository: flutterint... Done.
Inviting wulfland as a collaborator to flutterint... Done.
What are the class dates? (e.g. May 4 – 7, 2021)
July 28 - 29, 2022
Who is teaching? (Without the @)
wulfland
Updating contents of README.md... Done.
Updating contents of _config.yml... Done.
Branch protection rules updated.
Creating issue: Add collaborators to this repo... Done.
Creating project: Caption Contest...
http: warning: HTTP 410 Gone

Done.
Creating project column: To do...
http: warning: HTTP 404 Not Found

Done.
Creating project column: In progress...
http: warning: HTTP 404 Not Found

Done.
Creating project column: Done...
http: warning: HTTP 404 Not Found

Done.
Creating project card: ...
http: warning: HTTP 404 Not Found

GitHub Pages enabled.

Project creation does not work.

I still get this error. Did you find a workaround? I guess it is because Projects are different nowadays. Should someone delete the stuff from the script and training manual? or update to use new Projects?  @gusshawstewart @ppremk  any thoughts on this?

@mericstam delete all the log files. And make sure to pull the newest version. This should do the trick.


Expose controller-manager and scheduler /metrics enpoint

Towards https://github.com/giantswarm/roadmap/issues/725

Tested, works


Compiles and runs all examples.

Cal, want to take a look and see if you have any comments or suggestions? I haven't done anything beyond running the examples.

Looks great, Brian. Thanks for providing this update to support the Adafruit HX8357 displays!
Regarding the config file: Note that (at this time) there is a default GUIslice_config.h that is common to both LINUX and Arduino targets, but that it defaults to LINUX (eg. using SDL driver). I intend to separate this out into a LINUX-specific example config and Arduino-specific example config soon, but in the meantime I may revert your customized config to match the SDL default used thus far in the GUIslice releases. Instead, I will move all of your custom settings (including your resistive values, orientation, etc.) into the GUIslice_config_guide.xlsx as Config #18.
I will keep the new DRV_DISP_ADAGFX_HX8357 that you created inside the GUIslice_config.h.
PS> We can ignore the travis build check result as I hadn't configured it properly.

 Thanks for moving the config settings, that sounds like the
way to go. I've added font scaling support and some additional debug
messages, but I'll wait a bit before posting and doing a pull request.
Incidentally, adding font scaling support was just one line of code, which
speaks to the quality of your architecture. Is the text size attribute
intended to correspond to pixels, font points, or is it device dependent?
My implementation went with device dependent, but that's not my preference.
On Aug 30, 2017 2:11 AM, "Calvin Hass"<EMAIL_ADDRESS>wrote:

Merged #11 https://github.com/ImpulseAdventure/GUIslice/pull/11.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ImpulseAdventure/GUIslice/pull/11#event-1226963458,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJ_KpwRLScqj5tUKBRUBnbJSlCKAJ6Ctks5sdP0WgaJpZM4PGI35
.


SupervisorTest: Errno::ENOENT: No such fi le or directory @ rb_sysopen - test/tmp/supervisor/log

fluentd  version:fluentd-0.14.11-x86-mingw32
Environment information:Windows 7 x64
configuration:
ruby 2.2.5 and gems required by fluentd.
problem explanation;
when run  "fluentd\test\test_supervisor.rb" , then 2 errors caused.

cd  fluentd\test
ruby test_supervisor.rb

log is there
Error: test_load_config_for_daemonize(SupervisorTest): Errno::ENOENT: No such file or directory @ rb_sysopen - test/tmp/supervisor/log
..rubystack-2.2.5-4/ruby/lib/ruby/gems/2.2.0/gems/fluentd-0.14.11-x86-mingw32/lib/fluent/supervisor.rb:329:in initialize' ..rubystack-2.2.5-4/ruby/lib/ruby/gems/2.2.0/gems/fluentd-0.14.11-x86-mingw32/lib/fluent/supervisor.rb:329:in open'
../rubystack-2.2.5-4/ruby/lib/ruby/gems/2.2.0/gems/fluentd-0.14.11-x86-mingw32/lib/fluent/supervisor.rb:329:in init' ..rubystack-2.2.5-4/ruby/lib/ruby/gems/2.2.0/gems/fluentd-0.14.11-x86-mingw32/lib/fluent/supervisor.rb:251:in load_config'
test_supervisor.rb:269:in block in test_load_config_for_daemonize'      266:     params['suppress_repeated_stacktrace'] = true      267:     params['log_level'] = Fluent::Log::LEVEL_INFO      268:     params['daemonize'] = './fluentd.pid'   => 269:     load_config_proc =  Proc.new { Fluent::Supervisor.load_config(tmp_dir, params) }      270:      271:     # first call      272:     se_config = load_config_proc.call test_supervisor.rb:272:in call'
test_supervisor.rb:272:in `test_load_config_for_daemonize'

================================================================

This doesn't happen when bundle exec rake test, right?

yes.
when "bundle exec rake test" then it cause other error.
May be Gemfile is Incorrect on Windows.

gem list
...
oj (2.18.0)

[!] There was an error parsing Gemfile:
[!] There was an error while loading fluentd.gemspec: No such file or director
y - git ls-files. Bundler cannot continue.
from I:/kibana/fluentd/fluentd.gemspec:13
-------------------------------------------
gem.add_development_dependency("oj", ["~> 2.14"])

end

require File.expand_path('../lib/fluent/version', FILE)
-------------------------------------------
. Bundler cannot continue.
from I:/kibana/fluentd/Gemfile:3
-------------------------------------------
instance_eval File.read(local_gemfile)

end

source 'https://rubygems.org/'
-------------------------------------------

I'm not sure how to setup your fluentd but tests passed on AppVeyor's windows: https://ci.appveyor.com/project/fluent/fluentd/build/2065
So if bundle exec rake test failed, your environment is something wrong.
I will check why single file test fails later.

This is low priority because the problem is test code, not fluentd itself.

I will check why single file test fails later.
I see "low priority ".
Best reguards.

I corrected the environment and made bundle exec rake test  successful.
but　The problem of   "fluentd\test\test_supervisor.rb"  has been reproduced .
--What has changed
--- Previous environment
I added git to the environment variable path after entering the DOS prompt.
then "git ls-files.split($)" outputs ”No such file or directory".
--- current environment
I added git to the environment variable path before entering the DOS prompt by Windows SYSTEMS COMPUTERS properties.
then sucess bundle exec rake test.
I also add Japanese to make up for broken English.
Rubyのバッククオート（‘‘）によるコマンド起動パスは、環境変数のPATHの設定方法によって”No such file or directory"エラーとなる。
DOSプロンプトに入ってからPATHに追加したコマンドは、バッククオート（‘‘）で起動できない。
DOSプロンプトに入る前に、Windowsシステムの詳細設定画面の”コンピュータプロパティ”の設定で、PATHに追加したコマンドは、バッククオートで起動できた。

bundle exec rake test
2144 tests, 9477 assertions, 0 failures, 0 errors, 0 pendings, 12 omissions, 0 n
otifications
100% passed

Error: test_load_config(SupervisorTest): Errno::ENOENT: No such file or director
y @ rb_sysopen - I:/kibana/fluentd/test/test/tmp/supervisor/log
/rubystack-2.2.5-4/ruby/lib/ruby/gems/2.2.0/gems/fluentd-0.14.11
-x86-mingw32/lib/fluent/supervisor.rb:329:in initialize' /rubystack-2.2.5-4/ruby/lib/ruby/gems/2.2.0/gems/fluentd-0.14.11 -x86-mingw32/lib/fluent/supervisor.rb:329:in open'
rubystack-2.2.5-4/ruby/lib/ruby/gems/2.2.0/gems/fluentd-0.14.11
-x86-mingw32/lib/fluent/supervisor.rb:329:in init' rubystack-2.2.5-4/ruby/lib/ruby/gems/2.2.0/gems/fluentd-0.14.11 -x86-mingw32/lib/fluent/supervisor.rb:251:in load_config'
test_supervisor.rb:204:in block in test_load_config'      201:     params['log_path'] = 'test/tmp/supervisor/log'      202:     params['suppress_repeated_stacktrace'] = true      203:     params['log_level'] = Fluent::Log::LEVEL_INFO   => 204:     load_config_proc =  Proc.new { Fluent::Supervisor.load_config(tmp_ dir, params) }      205:      206:     # first call      207:     se_config = load_config_proc.call test_supervisor.rb:207:in call'
test_supervisor.rb:207:in `test_load_config'
13 tests, 47 assertions, 0 failures, 2 errors, 0 pendings, 0 omissions, 0 notifi
cations
84.6154% passed

Is it a bug should be fixed?
This requirement is very common one in ruby projects, so I want to add this requirement for developers.

My original issue is about "fluentd\test\test_supervisor.rb" .
Errno::ENOENT: No such file or directory @ rb_sysopen - test/tmp/supervisor/log
..rubystack-2.2.5-4/ruby/lib/ruby/gems/2.2.0/gems/fluentd-0.14.11-x86-mingw32/lib/fluent/supervisor.rb:329:in initialize'
I want to Fixes  My original issue.
and Please show that fixes  are plenty of many other similar fixes on Windows .
I expect the ability of youres contributing to the ‘ruby projects‘.
Best reguards.

Hi, I couldn't reproduce this issue.
My environment

Windows 10 Pro
git from GitHub for Windows
Fluentd master (c7281883dcfa16aceb5ef724aba8825902fa6e59)
Ruby 2.3.1

Adding git into PATH in cmd:
set PATH=C:\Users\<account name>\AppData\Local\GitHub\PortableGit_624c8416ee51e205b3f892d1d904e06e6f3c57c8\cmd\;%PATH%

And then,
cmd> bundle exec ruby test\test_supervisor.rb
Loaded suite test/test_supervisor
Started
........O
========================================================================================================================
Windows cannot handle signals [test_main_process_signal_handlers(SupervisorTest)]
test/test_supervisor.rb:111:in `test_main_process_signal_handlers'
========================================================================================================================
.O
========================================================================================================================
Windows cannot handle signals [test_rpc_server(SupervisorTest)]
test/test_supervisor.rb:154:in `test_rpc_server'
========================================================================================================================
O
========================================================================================================================
Windows cannot handle signals [test_supervisor_signal_handler(SupervisorTest)]
test/test_supervisor.rb:133:in `test_supervisor_signal_handler'
========================================================================================================================
.

Finished in 10.070189 seconds.
------------------------------------------------------------------------------------------------------------------------
13 tests, 83 assertions, 0 failures, 0 errors, 0 pendings, 3 omissions, 0 notifications
100% passed
------------------------------------------------------------------------------------------------------------------------
1.29 tests/s, 8.24 assertions/s

I   can reproduced  by "ruby 2.3.3p222"

git
'git' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。

bundle exec ruby test/test_supervisor.rb
[!] There was an error parsing Gemfile:
[!] There was an error while loading fluentd.gemspec: No such file or director
y - git ls-files. Bundler cannot continue.
from fluentd/fluentd.gemspec:13
 gem.add_development_dependency("oj", ["~> 2.14"])

end
require File.expand_path('../lib/fluent/version', FILE)
. Bundler cannot continue.
from fluentd/Gemfile:3
instance_eval File.read(local_gemfile)
end
source 'https://rubygems.org/'

Hmm, this issue is caused by not found git in PATH.
But this issue may won't fix because there is a workaround.
GitHub for Windows provides GitShell which adds git in PATH at startup.

I added Development section for adding some basic informations: https://github.com/fluent/fluentd#development


Somewhat stabilize repository metadata format

Current changes in the idea bucket:

[ ] Remove developer-specific repodata entirely, instead pinning the app certificate in the root repodata (pending review)
[ ] Use unchanging ID for developers instead of their username (irrelevant if above change is deemed sane, otherwise accepted)
[ ] Design method for fetching split APKs from the repository
[ ] Store app display names

Closing in favor of https://github.com/accrescent/meta/issues/2


swig not available

Details
I am trying to build a project (pywbem) that has a dependency on the python package "M2Crypto". I do have a requirements.txt file that specifies that dependency, and it being attempted to be installed.
However, M2Crypto needs the "swig" utility during its install, and swig does not seem to be available on readthedocs.org.
Because swig is a fairly standard tool that is needed by a number of Python packages, may I ask for it to be installed on RTD?

Project: pywbem
Build #: 3853463

You can also mock out dependencies, see our FAQ on our docs for more information. swig can be added via it's APT package, feel free to open a PR against our docker build images here: https://github.com/rtfd/readthedocs-docker-images/blob/master/base/Dockerfile

@agjohnson I'm assuming you're referring to the mocking docs here.
So now I'm quite confused.
The pip documentation clearly implies that you need to include deps you expect to be auto-analyzed in your install_requires in order for pip install mypackage (where mypackage has some direct dep that requires SWIG or other C exts) to work.
You've suggested mocking the dependency.  Afaict your definition of mocking also implies that you do not include the dep in install_requires. This of course breaks install from pypi (since I don't believe there's any way to have pip install with a requirements.txt that was somehow packaged with the sdist).
So is it that pip install mypackage and readthedocs are not compatible when you have a C dep? The only other approach I can imagine is that RTD gives you the some kind of env variable or other to allow your setup.py to avoid inserting your dep at runtime.

For anyone else running into this it seems you can also hack around it using the 'READTHEDOCS' env var to conditionally modify install_requires in your setup.py.

@tgoodlet these are the docker files for

the latest version: https://github.com/rtfd/readthedocs-docker-images/blob/master/Dockerfile
the current one at production: https://github.com/rtfd/readthedocs-docker-images/blob/2.x-upgrade/Dockerfile

There is another person that did this: https://github.com/jhale/readthedocs-docker-images/commit/36408c6598934a4d16e70e47ede9263b20ff75f3 and I think it should be enough.


Subscription notification order question

This is maybe a naive question. But I was looking at the Subscription code and specifically thinking about this comment https://github.com/reactjs/react-redux/blob/master/src/utils/Subscription.js#L1-L3
If the goal is to ensure that children are notified after parents, could that be accomplished by an event emitter that notifies in the opposite direction? Like, if the event emitter added listeners to the beginning of the list rather than pushing them on the end? And if that was true would it eliminate the complexity of the nested subscriptions?

Reversing the order is only part of it. The more complicated part is ensuring children don't get notified until parents have finished, so that they send fresh props to the children. Otherwise you end up with the situation where a child component's mapStateToProps is running with the new state but old props.
A lot of the complexity is for avoiding calls to setState, which, as of React 15, was the biggest performance loss. I'm hoping that React 16's "Fiber" implementation has changed things, because the React Redux code could be simplified if we could move props calculation into the setState call.

@jimbolla Thanks for the reply!

As a vaguely related note: I talked with Dan some about v5 at ReactRally.  He said he doesn't particularly understand how it works, has general concerns about React-Redux's overall interaction with the React component tree in terms of trigger multiple independent re-renders, and isn't yet sure how we might need to update things for "best" interaction with React 16 and later.  I also remember Andrew making a comment at some point about wanting to convene a summit of the major state management libs sometime around 16's release to discuss possible updates.

Very interesting. I was wondering about this because I feel that a lot of the appeal of adopting redux has much less to do with redux than it has to do with how difficult it is to write the connector component in a air-tight way. Like if I could just have something to help me write a connector like this, but could handle the state with redux or a behavior subject or just a plain event emitter I would feel more empowered.

@skiano : not quite sure I follow what you're saying there.  Can you clarify?

@markerikson sure, I am just saying that the hardest part of state mgmt to wrap my mind around in react is what it means to actually connect the components to updates, especially when those components are nested, or worse, if the components care about some of the same events but not the others.
So in a way, I use redux less because of redux architecture itself, and more because react-redux provides a way to connect to redux. In other words, I find myself adopting redux structures (reducers, actions, middleware) not because I want to express my application state that way, but because if I do, I can take advantage of this connector, knowing that it already takes care of things like @jimbolla points out above.


Optionally prevent DNS configuration on the client

Is your feature request related to a problem? Please describe.
There seems to not be a way to disable the custom DNS pushed by the Netbird instance. In certain situations, the user may not want to use the DNS server provided by the VPN.
Describe the solution you'd like
Maybe an option similar to the 'Allow SSH' option on the client, maybe 'Apply DNS servers', which you can disable to prevent the DNS setup to be performed on connection from the client.
Describe alternatives you've considered
I tried configuring the 'CustomDNSAddress' option in the config.json but I don't seem to do anything related to the issue, and I didn't find documentation about it.
Additional context
N/A

this can be achieved by putting your peers in a special Group, then going to DNS->DNS-Settings->'Disable DNS management for these groups'
Once set, the netbird client dos not touch the local DNS any more.
If you want to have a specifig nameserver added then, you may add this to the 'netbird up' command as follows:
netbird up  --dns-resolver-address <your-wanted-DNS-server-to-be-injected-into-resolv.conf>:53
At least this was how I got it solving my DNS problems on a SIP server needing DNS resolving SRV records (something the integrated netbird DNS seems not to support (yet)), but that's another story.....


fix(plugin-react): apply manual runtime interop

Description
Fix https://github.com/vitejs/vite/issues/8468
Fix https://github.com/vitejs/vite/issues/5885
Supersedes https://github.com/vitejs/vite/pull/7246, though didn't implement deduping react/jsx-runtime and react/jsx-dev-runtime as I think that's a risky optimization.
Additional context
The esbuild+rollup issue arise because the old interop code depends on @rollup/plugin-commonjs to handle the CJS code. Without it, the interop failed, and without interop it caused #8468.
Interop can't be applied with importAnalysisBuild because the JSX code in question is in node_modules, and importAnalysisBuild don't handle both JSX files (es-module-lexer) and those inside node_modules.
This PR implements a virtual proxy file for the react runtime import that implements interop, working with esbuild. (I have not tested without esbuild optimization in build)
I think the issue at the start would've been better resolved with optimizeDeps.extensions. I'd love to start implementing it for plugin-vue and plugin-react, but there's one more piece I haven't implement in core.
All-in-all, this PR helps prevent the regression at the meantime.

What is the purpose of this pull request?

[x] Bug fix
[ ] New Feature
[ ] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the Pull Request Guidelines and follow the Commit Convention.
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[x] Ideally, include relevant tests that fail without this PR but pass with it.

Looks good to me. We should check how it works when tge optimizer is disabled and commonjs is used. It should still work though, no? If not we could revert to the prev code in that case

Looks like it does work with optimizeDeps.disabled: 'build'! This should be good then. Also refactored virtual handling a bit.


[KO] Update translation

Update metaprogramming
Reduce some verbose sentences
Omit trailing and
Unify words: macro

@Dalgona, @malkoG, @devleoper, @riseshia review please.

Merged! Thanks for your continued support 😄
For referencing purpose: Debugging section of Metaprogramming lesson is translated from #489.


Standardize selector fields in the API

What would you like to be added:
Label selectors are present in a few places in the API. The names are not defined as defined in upstream k8s APIs.
This issues stems from: https://github.com/kubernetes-sigs/service-apis/pull/285#discussion_r486661928
Why is this needed:
We should fix this for good user experience.

Prefer to have selector in name for fields.

/assign @hbagdi

/assign

@robscott Is there anything left to do here?

I don't think so, thanks!
/close


hide scrollbar and fix navbar

Pull Request Checklist

Final changes: hide the scrollbar and fix navbar margin height

kindly check this PR and do merge it as well
Fixes #153
I have added screenshots and videos to show the working of my code.
I have ensured that the screen size is set to 100% while capturing the screenshot.
I have synced the latest fork with my local repository and resolved any conflicts.

the screenshot isnt added


Move GetProcessStepResult to nswag client

Description

References

#0000

Codecov Report

Merging #1547 (7ee3036) into main (f2bfc64) will increase coverage by 19.14%.
The diff coverage is 96.29%.

@@             Coverage Diff             @@
##             main    #1547       +/-   ##
===========================================
+ Coverage   20.94%   40.09%   +19.14%
===========================================
  Files          60       75       +15
  Lines        1337     1751      +414
  Branches      113        0      -113
===========================================
+ Hits          280      702      +422
+ Misses       1047     1034       -13
- Partials       10       15        +5

Impacted Files
Coverage Δ

apps/dh/api-dh/source/DataHub.WebApi/Startup.cs
92.53% <94.11%> (-0.63%)
:arrow_down:

...ntegration/Controllers/WholesaleControllerTests.cs
97.82% <100.00%> (ø)

...Hub.WebApi/Controllers/WholesaleBatchController.cs
67.92% <100.00%> (+8.35%)
:arrow_up:

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


Wrangler v1 deprecation

For internal context, see https://jira.cfdata.org/browse/DEVX-80 and https://jira.cfdata.org/browse/DEVX-78.
This supersedes https://github.com/cloudflare/cloudflare-docs/pull/6934 and prepares the way for deprecating Wrangler v1 in favour of v2. Specifically:

Restructures docs to add a new top level section in the workers docs under  which all v1/migration stuff goes (called "Wrangler (legacy)")
Rename all references to Wrangler 1 or Wrangler 2 to Wrangler v1/Wrangler v2
Change GitHub repository links from wrangler -> wrangler-legacy and wrangler2 -> workers-sdk (this rename will take place this week before merging this PR)
Unify the deprecation messaging across Wrangler v1 docs pages

@mrbbot I've left the links from the tutorials the same, since I think they have wider issues that need addressing before updating to v2, but everything else should be good to go

When we published the Wrangler 2 docs, we agreed to go for a unified "Wrangler 2" wording on all things related to Wrangler 2 in the docs because that's what we called the product. We removed all "Wrangler v2/Wrangler V2/Wrangler Version 2/ Wrangler 2.0" from the docs. We did the same thing for "Wrangler 1". With this PR, I see that 'v1' and 'v2' wording has been added back.
Other developer docs use "Wrangler 2" when talking about installation needs. Can we remove all inconsistencies and update wording to "Wrangler 2"? Or are we proceeding with "Wrangler v2" from this point forward?

In the not too distant future we expect to release Wrangler 3.0.0 and then 4.0.0, etc.
The aim here is to avoid rebranding each version at each major version bump.
Therefore we should try to use just "Wrangler" wherever possible and then refer to vN when we need to call out something specific to a version.

I didn't want to add to the complexity of this PR by removing version qualifiers, but that's definitely something we want to do in the future. With the v1/v2 language we just wanted to make it clear that Wrangler 1 and 2 are both Wrangler, not too distinct things

@deadlypants1973 With that additional context, are there any further concerns with this PR?

When we published the Wrangler 2 docs, we agreed to go for a unified "Wrangler 2" wording on all things related to Wrangler 2 in the docs because that's what we called the product. We removed all "Wrangler v2/Wrangler V2/Wrangler Version 2/ Wrangler 2.0" from the docs. We did the same thing for "Wrangler 1". With this PR, I see that 'v1' and 'v2' wording has been added back.
Other developer docs use "Wrangler 2" when talking about installation needs. Can we remove all inconsistencies and update wording to "Wrangler 2"? Or are we proceeding with "Wrangler v2" from this point forward?

In the not too distant future we expect to release Wrangler 3.0.0 and then 4.0.0, etc. The aim here is to avoid rebranding each version at each major version bump. Therefore we should try to use just "Wrangler" wherever possible and then refer to vN when we need to call out something specific to a version.

thank you! this makes sense. "we should try to use just "Wrangler" wherever possible and then refer to vN when we need to call out something specific to a version." I am going to stick to this logic in future docs.


Remove paste handler

fixes #71

Released as 1.6.3 (merged as https://github.com/angular-ui/ui-mask/commit/fb8e87bd7ef80852aea2e54d97e854d1d565e148)
Next time, please don't create a release and create a PR with a single commit.


Hotkey item dupe

If you have a enchantment book in the first slot of your inventory, and an enchantable item somewhere else, swapping places in your inv by pressing the hotkey 1 will not actually swap places, it will apply the enchant to the item while duplicating the original item as well.
Can provide more info if needed, just not using a computer right now.

Could you tell me what MC version you're using because I can't seem to replicate it.

Taco 1.8.8

Nevermind, Ive found this only occurs in creative mode.

Ah, ill see if I can fix it but since its in creative it doesn't matter to much. Thanks for the report.

I agree its not a big deal at all, I only opened this in the first place because I originally thought it was in survival.


windows pc not working

I couldn't run the plugin on my windows10 computer.
I am using the latest version vscode and plugin.
I get a pint upload warning when I want to save the file.
(whereas pint is installed and I can run it with terminal)
"Pint binary not found. Do you want to install it?"
when i click "yes"
"Something went wrong while running Laravel Pint."
and
"Starting download..."
It gives a warning but doesn't offer a solution.
file save after

yes click

terminal screen

command prompt

Windows PowerShell

git-bash

thanks for pointing out, Ill look into this..
can you also give me your php version please.

composer.json
"require": {
        "php": ">=8.0",
}

I have temporarily created a solution with another plugin. Maybe the method I used can guide you.
https://marketplace.visualstudio.com/items?itemName=pucelle.run-on-save
Thanks to this plugin, I can run commands after saving the file.
my config
    "runOnSave.commands": [         {             "match": ".*\\.php$",             "runIn": "backend",             "async":true,             "command": "php vendor/bin/pint ${fileRelative}",             "runningStatusMessage": "${fileBasename} pint running",             "finishStatusMessage": "${fileBasename} pint completed"         },     ],

i tries to recreate this issue, wasn't able to recreate.
all works as expected.
i am closing this issue for now.
but ill keep an eye if this can be recreated..

thanks for reference of the issue for the permission.
i tried to recreate it on windows, was not able to.
i will close this issue for now bit will keep an eye on the same if it can be recreated.

@serdartaylan i deleted you comment regarding  https://marketplace.visualstudio.com/items?itemName=pucelle.run-on-save by mistake, please feel free to recomment.

https://github.com/msamgan/vscode-larapint/compare/v0.1.1...v0.1.2
resolved here.

did you test this?

@msamgan Had the same issue. I debugged your extension and saw the following error
Error: spawn C:\WINDOWS\system32\cmd.exe ENOENT

Realised it might be a PATH problem for some people. Anyway my path cmd was fine. I change the line 12 in /utils/methods.js to a hardcoded path to my project and it works fine now. This is the issue. Also it take the first folder from your workspace which is not always a php project with composer so maybe that line should change?

@phadaphunk thanks for pointing out.
it will be highly appreciated if you can create a PR with your proposed solution to the problem and we can take it from there.


Add public examples to all functions in std.math

Finishes everything except rndtonl which is blocked by issue 18693

@JackStouffer we can't merge this as long as it's failing on FreeBSD :/ (so removing the 72h merge label for now)
Maybe version the failing test + put a FIXME bugzilla issue like we did for std.random?

The most annoying thing about this is that the line numbers on the error messages in the auto tester are clearly wrong. So, I'm doing this manually to figure out what's going on.

just rebase your PR to master - then the line number will match ;-)

This is what happens when you have no tests https://issues.dlang.org/show_bug.cgi?id=18739