OpenAlex API support

As discussed in issues #84 & #133, Semantic Scholar replies error code 429 and the program completely hangs if you do not have Semantic Scholar API Key (I could not get any request to success even if I wait more than 1 hour) while it takes long time to get proper API Key even if you request through the Semantic Scholar form.
This PR adds OpenAlex API support as an alternative literature search. pyalex library is used for the simple implementation.
Since OpenAlex does not require API Key, this PR will allow broader people to run the AI Scientist code by setting --engine openalex.
Please note that I have not compared the search result between Semantic Scholar and OpenAlex (since I have no Semantic Scholar API Key), and citation may not work as expected. I just confirmed the below command will run until the end to produce
a pdf paper.
OPENALEX_MAIL_ADDRESS="MY EMAIL ADDRESS" python launch_scientist.py --model "gpt-4o-2024-05-13" --experiment nanoGPT_lite --num-ideas 2 --engine openalex
Additionally, this PR supports --skip_novelty_check option to work. The option was already implemented in argparse but does not work now.

**I tried to merge your PR locally, but after generating ideas, the result was still like this , is this restults true? or what can i fix ? **
(ai_scientist) (.venv) PS C:\Users\Administrator\PycharmProjects\AI-Scientist> python launch_scientist.py --model "gpt-4o-2024-05-13" --experiment nanoGPT_lite --num-ideas 2 --engine openalex
Using GPUs: []
Using OpenAI API with model gpt-4o-2024-05-13.

Generating idea 1/2
Iteration 1/3
Failed to generate idea: Connection error.

Generating idea 2/2
Iteration 1/3
{'Name': 'adaptive_dropout', 'Title': 'Adaptive Dropout: Dynamic Regularization for Enhanced Model Training', 'Experiment': 'Modify the model to allow dynamic adjustment of dro
pout rates during training. Implement a mechanism to update the dropout rate based on the current epoch or validation loss. Compare the training dynamics, convergence speed, and final performance with the baseline model with a static dropout rate.', 'Interestingness': 7, 'Feasibility': 5, 'Novelty': 5}
Iteration 2/3
{'Name': 'adaptive_dropout', 'Title': 'Adaptive Dropout: Dynamic Regularization for Enhanced Model Training', 'Experiment': 'Modify the model to allow dynamic adjustment of dro
pout rates during training. Implement a mechanism to linearly decrease the dropout rate from an initial higher value to a lower value over the training epochs. Compare the trai
ning dynamics, convergence speed, and final performance with the baseline model with a static dropout rate. Log the dropout rate changes and analyze their impact on performance.', 'Interestingness': 7, 'Feasibility': 6, 'Novelty': 5}
Iteration 3/3
{'Name': 'adaptive_dropout', 'Title': 'Adaptive Dropout: Dynamic Regularization for Enhanced Model Training', 'Experiment': 'Modify the model to allow dynamic adjustment of dro
pout rates during training. Implement a mechanism to linearly decrease the dropout rate from an initial higher value to a lower value over the training epochs. Compare the trai
ning dynamics, convergence speed, and final performance with the baseline model with a static dropout rate. Log the dropout rate changes and analyze their impact on performance.', 'Interestingness': 7, 'Feasibility': 6, 'Novelty': 5}
Idea generation converged after 3 iterations.

Checking novelty of idea 0: adaptive_block_size
[WARNING] title='Gradient-based learning applied to document recognition': len(abstract)=1510 is too long! Use first 1000 chars.
[WARNING] title='Non-Parametric Estimation of a Multivariate Probability Density': len(abstract)=29825 is too long! Use first 1000 chars.
[WARNING] title='QUANTUM ESPRESSO: a modular and open-source software project for quantum simulations of materials': len(abstract)=1268 is too long! Use first 1000 chars.
[WARNING] title='GROMACS: A message-passing parallel molecular dynamics implementation': len(abstract)=1832 is too long! Use first 1000 chars.
[WARNING] title='Eigenfaces for Recognition': len(abstract)=1462 is too long! Use first 1000 chars.
[WARNING] title='An introduction to cybernetics': len(abstract)=2464 is too long! Use first 1000 chars.
[WARNING] title='CHARMM: The biomolecular simulation program': len(abstract)=1381 is too long! Use first 1000 chars.
[WARNING] title="User's guide to PHREEQC (Version 2): A computer program for speciation, batch-reaction, one-dimensional transport, and inverse geochemical calculations": len(abstract)=1985 is too long! Use first 1000 chars.
Error: HTTPSConnectionPool(host='api.openalex.org', port=443): Max retries exceeded with url: /works?search=adaptive+sequence+length+training+neural+networks&per-page=10 (Caused by SSLError(SSLEOFError(8, '[SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1000)')))
[WARNING] title='Gradient-based learning applied to document recognition': len(abstract)=1510 is too long! Use first 1000 chars.
[WARNING] title='Informer: Beyond Efficient Transformer for Long Sequence Time-Series Forecasting': len(abstract)=1521 is too long! Use first 1000 chars.
[WARNING] title='SuperGlue: Learning Feature Matching With Graph Neural Networks': len(abstract)=1058 is too long! Use first 1000 chars.
[WARNING] title='A Metaverse: Taxonomy, Components, Applications, and Open Challenges': len(abstract)=1284 is too long! Use first 1000 chars.
Error: HTTPSConnectionPool(host='api.openalex.org', port=443): Max retries exceeded with url: /works?search=adaptive+block+size+transformer&per-page=10 (Caused by SSLError(SSLEOFError(8, '[SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1000)')))
Error: HTTPSConnectionPool(host='api.openalex.org', port=443): Max retries exceeded with url: /works?search=variable+context+window+training+transformers&per-page=10 (Caused by SSLError(SSLEOFError(8, '[SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1000)')))
Error: Connection error.
[WARNING] title='Long Short-Term Memory': len(abstract)=1205 is too long! Use first 1000 chars.
[WARNING] title='Gradient-based learning applied to document recognition': len(abstract)=1510 is too long! Use first 1000 chars.
[WARNING] title='Universal Transformers': len(abstract)=1762 is too long! Use first 1000 chars.
[WARNING] title='Identification of coding regions in genomic DNA sequences: an application of dynamic programming and neural networks': len(abstract)=1381 is too long! Use first 1000 chars.
[WARNING] title='Detecting Falls with Wearable Sensors Using Machine Learning Techniques': len(abstract)=1647 is too long! Use first 1000 chars.
[WARNING] title='Conversion of artificial recurrent neural networks to spiking neural networks for low-power neuromorphic hardware': len(abstract)=2322 is too long! Use first 1000 chars.
[WARNING] title='Eigenfaces for Recognition': len(abstract)=1462 is too long! Use first 1000 chars.
Decision made: novel after round 7

Checking novelty of idea 1: layerwise_learning_rates
[WARNING] title='Gradient-based learning applied to document recognition': len(abstract)=1510 is too long! Use first 1000 chars.
[WARNING] title='Highly accurate protein structure prediction with AlphaFold': len(abstract)=1701 is too long! Use first 1000 chars.
[WARNING] title='Deformable Convolutional Networks': len(abstract)=1023 is too long! Use first 1000 chars.
[WARNING] title='Dynamic Graph CNN for Learning on Point Clouds': len(abstract)=1413 is too long! Use first 1000 chars.
[WARNING] title='Explainable Artificial Intelligence (XAI): Concepts, taxonomies, opportunities and challenges toward responsible AI': len(abstract)=2238 is too long! Use first 1000 chars.
[WARNING] title='Image Segmentation Using Deep Learning: A Survey': len(abstract)=1021 is too long! Use first 1000 chars.
[WARNING] title='Geometric Deep Learning: Going beyond Euclidean data': len(abstract)=1303 is too long! Use first 1000 chars.
[WARNING] title='Gradient-based learning applied to document recognition': len(abstract)=1510 is too long! Use first 1000 chars.
[WARNING] title='Deep neural network for traffic sign recognition systems: An analysis of spatial transformers and stochastic optimisation methods': len(abstract)=1054 is too long! Use first 1000 chars.
[WARNING] title='Understanding the Difficulty of Training Transformers': len(abstract)=1194 is too long! Use first 1000 chars.
[WARNING] title='Deformable Convolutional Networks': len(abstract)=1023 is too long! Use first 1000 chars.
[WARNING] title='BioBERT: a pre-trained biomedical language representation model for biomedical text mining': len(abstract)=1800 is too long! Use first 1000 chars.
[WARNING] title='Dynamic Graph CNN for Learning on Point Clouds': len(abstract)=1413 is too long! Use first 1000 chars.
[WARNING] title='Residual Attention Network for Image Classification': len(abstract)=1326 is too long! Use first 1000 chars.
[WARNING] title='Gradient-based learning applied to document recognition': len(abstract)=1510 is too long! Use first 1000 chars.
[WARNING] title='Dynamic Graph CNN for Learning on Point Clouds': len(abstract)=1413 is too long! Use first 1000 chars.
[WARNING] title='Explainable Artificial Intelligence (XAI): Concepts, taxonomies, opportunities and challenges toward responsible AI': len(abstract)=2238 is too long! Use first 1000 chars.
[WARNING] title='Image Segmentation Using Deep Learning: A Survey': len(abstract)=1021 is too long! Use first 1000 chars.
[WARNING] title='A Survey on Vision Transformer': len(abstract)=1254 is too long! Use first 1000 chars.
[WARNING] title='Applications of machine learning to machine fault diagnosis: A review and roadmap': len(abstract)=1611 is too long! Use first 1000 chars.
[WARNING] title='Deep Learning in Mobile and Wireless Networking: A Survey': len(abstract)=1554 is too long! Use first 1000 chars.
[WARNING] title='WavLM: Large-Scale Self-Supervised Pre-Training for Full Stack Speech Processing': len(abstract)=1185 is too long! Use first 1000 chars.
Decision made: novel after round 3

Checking novelty of idea 2: adaptive_dropout
[WARNING] title='Effectiveness of Psychotherapy for Personality Disorders': len(abstract)=29995 is too long! Use first 1000 chars.
[WARNING] title='Squaring the circle of selection and allocation in liver transplantation for HCC: An adaptive approach': len(abstract)=36011 is too long! Use first 1000 chars.
[WARNING] title='Withdrawing From School': len(abstract)=1302 is too long! Use first 1000 chars.
[WARNING] title='Assessing “Neighborhood Effects”: Social Processes and New Directions in Research': len(abstract)=1236 is too long! Use first 1000 chars.
[WARNING] title='Hepatocellular carcinoma': len(abstract)=1820 is too long! Use first 1000 chars.
[WARNING] title='Deep Learning‐Based Crack Damage Detection Using Convolutional Neural Networks': len(abstract)=1615 is too long! Use first 1000 chars.
[WARNING] title='A Multistep, Consensus-Based Approach to Organ Allocation in Liver Transplantation: Toward a “Blended Principle Model”': len(abstract)=29633 is too long! Use first 1000 chars.
[WARNING] title='A survey of the recent architectures of deep convolutional neural networks': len(abstract)=1818 is too long! Use first 1000 chars.
[WARNING] title='Event-Triggering in Distributed Networked Control Systems': len(abstract)=1495 is too long! Use first 1000 chars.
[WARNING] title='Automatic myocardial segmentation in dynamic contrast enhanced perfusion MRI using Monte Carlo dropout in an encoder-decoder convolutional neural network': len(abstract)=1981 is too long! Use first 1000 chars.
[WARNING] title='Neuroscience-Inspired Artificial Intelligence': len(abstract)=29895 is too long! Use first 1000 chars.
[WARNING] title='The dropout learning algorithm': len(abstract)=1820 is too long! Use first 1000 chars.
[WARNING] title='A Fast Dense Spectral–Spatial Convolution Network Framework for Hyperspectral Images Classification': len(abstract)=1331 is too long! Use first 1000 chars.
[WARNING] title='Effective Approaches to Attention-based Neural Machine Translation': len(abstract)=1020 is too long! Use first 1000 chars.
[WARNING] title='Deep Tracking: Seeing Beyond Seeing Using Recurrent Neural Networks': len(abstract)=1148 is too long! Use first 1000 chars.
[WARNING] title='Probabilistic Sequential Network for Deep Learning of Complex Process Data and Soft Sensor Application': len(abstract)=1170 is too long! Use first 1000 chars.
[WARNING] title='Deep nets vs expert designed features in medical physics: An IMRT QA case study': len(abstract)=1915 is too long! Use first 1000 chars.
[WARNING] title='Dropout: a simple way to prevent neural networks from overfitting': len(abstract)=1130 is too long! Use first 1000 chars.
[WARNING] title='Adaptive dropout for training deep neural networks': len(abstract)=1297 is too long! Use first 1000 chars.
[WARNING] title='Deep Convolutional Neural Networks for Large-scale Speech Tasks': len(abstract)=1265 is too long! Use first 1000 chars.
[WARNING] title='Long Short-Term Memory Recurrent Neural Network for Remaining Useful Life Prediction of Lithium-Ion Batteries': len(abstract)=1455 is too long! Use first 1000 chars.
[WARNING] title='An Empirical Investigation of Catastrophic Forgetting in Gradient-Based Neural Networks': len(abstract)=1054 is too long! Use first 1000 chars.
[WARNING] title='EfficientNetV2: Smaller Models and Faster Training': len(abstract)=1329 is too long! Use first 1000 chars.
[WARNING] title='You Only Look Once: Unified, Real-Time Object Detection': len(abstract)=1118 is too long! Use first 1000 chars.
[WARNING] title='The dropout learning algorithm': len(abstract)=1820 is too long! Use first 1000 chars.
[WARNING] title='An Empirical Investigation of Catastrophic Forgetting in Gradient-Based Neural Networks': len(abstract)=1062 is too long! Use first 1000 chars.
Decision made: not novel after round 3
Processing idea: adaptive_block_size
Failed to evaluate idea adaptive_block_size: [Errno 2] No such file or directory: 'templates\\nanoGPT_lite\\run_0\\final_info.json'
Traceback (most recent call last):
  File "C:\Users\Administrator\PycharmProjects\AI-Scientist\launch_scientist.py", line 437, in <module>
    success = do_idea(
              ^^^^^^^^
  File "C:\Users\Administrator\PycharmProjects\AI-Scientist\launch_scientist.py", line 164, in do_idea
    with open(osp.join(base_dir, "run_0", "final_info.json"), "r") as f:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: 'templates\\nanoGPT_lite\\run_0\\final_info.json'

Processing idea: layerwise_learning_rates
Failed to evaluate idea layerwise_learning_rates: [Errno 2] No such file or directory: 'templates\\nanoGPT_lite\\run_0\\final_info.json'
Traceback (most recent call last):
  File "C:\Users\Administrator\PycharmProjects\AI-Scientist\launch_scientist.py", line 437, in <module>
    success = do_idea(
              ^^^^^^^^
  File "C:\Users\Administrator\PycharmProjects\AI-Scientist\launch_scientist.py", line 164, in do_idea
    with open(osp.join(base_dir, "run_0", "final_info.json"), "r") as f:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: 'templates\\nanoGPT_lite\\run_0\\final_info.json'

I guess the last No such file or directory error is not related to this PR, but you need to run the baseline code in advance to have run_0 directory.
https://github.com/SakanaAI/AI-Scientist?tab=readme-ov-file#create-nanogpt_lite-baseline-run-we-use-this-for-sanity-checking

###i did following running:
windows环境下
conda create -n ai_scientist python=3.11
conda activate ai_scientist
Install pypi requirements 安装依赖包
pip install -r requirements.txt
OPENALEX执行
$env:OPENALEX_MAIL_ADDRESS =<EMAIL_ADDRESS>gpt的key
env:OPENAI_API_KEY="sk-proj-Z6IpUgbbcK6a1l5h。。。。。。“
python launch_scientist.py --model "gpt-4o-2024-05-13" --experiment nanoGPT_lite --num-ideas 2 --engine openalex
###but i got following errors:

#####i think that this can be due to following reasons:

###and i think that this step should be correct

########Can anyone help me?
best wishes
Jiang

Thanks for the contribution, have you tested this out on a few papers?

sure, i will test it! best wishes!:)

@corochann what can be done if people want to add other open APIs? What are the intended structured output? There are only 6 currently (paper title, authors, venue, year of publication, citation count, paper abstract), but should there be more?
Regarding future edits, search_for_papers (direct API calls) is the only place that needs to be changed in core, while get_citation_aider_prompt, perform_writeup, and check_idea_novelty just need an engine parameter.


Updating, adding, and deprecating tokens for text field and text area

Updated, added, and deprecated tokens for text field and text area.

Updated and added new tokens for field width, updated side label tokens, and deprecated tokens due to design change of not supporting quiet text fields.

n/a

n/a

 [ ] Patch (bug fixes, typos, mistakes; non-breaking change which fixes an issue)
 [x] Minor (add a new token, changing a value; non-breaking change which adds functionality)
 [x] Major (deleting a token, changing token value type; fix or feature that would cause existing functionality to change)
Checklist:

 [ ] I have signed the [Adobe Open Source CLA](https://opensource.adobe.com/cla.html).
 [ ] I updated the token in all applicable sets. This applies if updating, adding, or deleting a token that has data across different sets (for example, if the value differs across color themes.)

TESTING spectrum2-non-colors
READING spectrum-tokens: /spectrum-tokens/packages/tokens/src/
READING   tokens studio: /spectrum-tokens-studio-data/src/tokens-studio/spectrum2-non-colors/
TOKENS STUDIO DATA IS NON-COLOR ONLY

WARNING - STUDIO MISSING MODE DEFINITION FOR spectrum2/layout/side-label-character-count-top-margin-extra-large: ["desktop"]
WARNING - STUDIO MISSING MODE DEFINITION FOR spectrum2/layout/side-label-character-count-top-margin-large: ["desktop"]
WARNING - STUDIO MISSING MODE DEFINITION FOR spectrum2/layout/side-label-character-count-top-margin-medium: ["desktop"]
WARNING - STUDIO MISSING MODE DEFINITION FOR spectrum2/layout/side-label-character-count-top-margin-small: ["desktop"]

STUDIO SYNC SUMMARY
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout.side-label-character-count-top-margin-extra-large
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout.side-label-character-count-top-margin-large
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout.side-label-character-count-top-margin-medium
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout.side-label-character-count-top-margin-small
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout/desktop.field-width-medium
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout/mobile.field-width-medium
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout/desktop.field-width-large
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout/mobile.field-width-large
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout/desktop.field-width-extra-large
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout/mobile.field-width-extra-large
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout/desktop.field-width-small
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout/mobile.field-width-small
UPDATED METADATA - SPECTRUM NAME: field-width-small => field-width

SPECTRUM SYNC SUMMARY
NEW TOKENS: (8) field-width-medium/desktop, field-width-medium/mobile, field-width-large/desktop, field-width-large/mobile, field-width-extra-large/desktop, field-width-extra-large/mobile, field-width-small/desktop, field-width-small/mobile
MODIFIED TOKENS: (4) side-label-character-count-top-margin-extra-large, side-label-character-count-top-margin-large, side-label-character-count-top-margin-medium, side-label-character-count-top-margin-small
RENAMED TOKENS: (1) field-width
DEPRECATED TOKENS: (26) field-label-to-component-quiet-small/desktop, field-label-to-component-quiet-small/mobile, field-label-to-component-quiet-medium/desktop, field-label-to-component-quiet-medium/mobile, field-label-to-component-quiet-large/desktop, field-label-to-component-quiet-large/mobile, field-label-to-component-quiet-extra-large/desktop, field-label-to-component-quiet-extra-large/mobile, field-edge-to-text-quiet, field-edge-to-border-quiet, field-edge-to-alert-icon-quiet, field-edge-to-validation-icon-quiet, field-width/desktop, field-width/mobile, character-count-to-field-quiet-small/desktop, character-count-to-field-quiet-small/mobile, character-count-to-field-quiet-medium/desktop, character-count-to-field-quiet-medium/mobile, character-count-to-field-quiet-large/desktop, character-count-to-field-quiet-large/mobile, character-count-to-field-quiet-extra-large/desktop, character-count-to-field-quiet-extra-large/mobile, side-label-character-count-top-margin-small/mobile, side-label-character-count-top-margin-medium/mobile, side-label-character-count-top-margin-large/mobile, side-label-character-count-top-margin-extra-large/mobile
CHANGED VALUES: (4) side-label-character-count-top-margin-extra-large/desktop, side-label-character-count-top-margin-large/desktop, side-label-character-count-top-margin-medium/desktop, side-label-character-count-top-margin-small/desktop

TEST COMPLETE

The warnings in the test script aren't correct - I've fixed it in the script and updated the action.

SYNCING spectrum2-non-colors
READING spectrum-tokens: /spectrum-tokens/packages/tokens/src/
READING   tokens studio: /spectrum-tokens-studio-data/src/tokens-studio/spectrum2-non-colors/
TOKENS STUDIO DATA IS NON-COLOR ONLY
STUDIO SYNC SUMMARY
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout.side-label-character-count-top-margin-extra-large
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout.side-label-character-count-top-margin-large
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout.side-label-character-count-top-margin-medium
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout.side-label-character-count-top-margin-small
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout/desktop.field-width-medium
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout/mobile.field-width-medium
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout/desktop.field-width-large
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout/mobile.field-width-large
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout/desktop.field-width-extra-large
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout/mobile.field-width-extra-large
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout/desktop.field-width-small
UPDATED METADATA - SPECTRUM UUID: spectrum2/layout/mobile.field-width-small
UPDATED METADATA - SPECTRUM NAME: field-width-small => field-width

SPECTRUM SYNC SUMMARY
NEW TOKENS: (8) field-width-medium/desktop, field-width-medium/mobile, field-width-large/desktop, field-width-large/mobile, field-width-extra-large/desktop, field-width-extra-large/mobile, field-width-small/desktop, field-width-small/mobile
MODIFIED TOKENS: (4) side-label-character-count-top-margin-extra-large, side-label-character-count-top-margin-large, side-label-character-count-top-margin-medium, side-label-character-count-top-margin-small
RENAMED TOKENS: (1) field-width
DEPRECATED TOKENS: (26) field-label-to-component-quiet-small/desktop, field-label-to-component-quiet-small/mobile, field-label-to-component-quiet-medium/desktop, field-label-to-component-quiet-medium/mobile, field-label-to-component-quiet-large/desktop, field-label-to-component-quiet-large/mobile, field-label-to-component-quiet-extra-large/desktop, field-label-to-component-quiet-extra-large/mobile, field-edge-to-text-quiet, field-edge-to-border-quiet, field-edge-to-alert-icon-quiet, field-edge-to-validation-icon-quiet, field-width/desktop, field-width/mobile, character-count-to-field-quiet-small/desktop, character-count-to-field-quiet-small/mobile, character-count-to-field-quiet-medium/desktop, character-count-to-field-quiet-medium/mobile, character-count-to-field-quiet-large/desktop, character-count-to-field-quiet-large/mobile, character-count-to-field-quiet-extra-large/desktop, character-count-to-field-quiet-extra-large/mobile, side-label-character-count-top-margin-small/mobile, side-label-character-count-top-margin-medium/mobile, side-label-character-count-top-margin-large/mobile, side-label-character-count-top-margin-extra-large/mobile
CHANGED VALUES: (9) alert-banner-bottom-to-text/desktop, alert-banner-minimum-height/desktop, alert-banner-top-to-text/desktop, alert-banner-top-to-workflow-icon/desktop, search-field-minimum-width-multiplier, side-label-character-count-top-margin-extra-large/desktop, side-label-character-count-top-margin-large/desktop, side-label-character-count-top-margin-medium/desktop, side-label-character-count-top-margin-small/desktop

WROTE: /spectrum-tokens-studio-data/src/tokens-studio/spectrum2-non-colors/spectrum2/layout/mobile.json
WROTE: /spectrum-tokens-studio-data/src/tokens-studio/spectrum2-non-colors/spectrum2/layout/desktop.json
WROTE: /spectrum-tokens/packages/tokens/src/layout.json
WROTE: /spectrum-tokens/packages/tokens/src/layout-component.json
SYNC COMPLETE
Spectrum Tokens Pull Request
Tokens Studio Pull Request


Remove the unused function parameter "config"

Breaking change

Removing the cofig parameters from the generate_and_validate () since it was never used.
Proposed change

Removing the unused parameter config improves the function’s clarity by eliminating ambiguity. Since config is not used within the function, it does not impact its behavior. By removing this parameter, we make the function’s intent clearer, adhering to clean coding practices and enhancing maintainability
Type of change

[ ] Dependency upgrade
[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New integration (thank you!)
[ ] New feature (which adds functionality to an existing integration)
[ ] Deprecation (breaking change to happen in the future)
[ ] Breaking change (fix/feature causing existing functionality to break)
[x] Code quality improvements to existing code or addition of tests

Additional information

This PR fixes or closes issue: fixes #
This PR is related to issue:
Link to documentation pull request:

Checklist

[ ] The code change is tested and works locally.
[ ] Local tests pass. Your PR cannot be merged unless tests pass
[ ] There is no commented out code in this PR.
[ ] I have followed the development checklist
[ ] I have followed the perfect PR recommendations
[ ] The code has been formatted using Ruff (ruff format homeassistant tests)
[ ] Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[ ] The manifest file has all fields filled out correctly.
Updated and included derived files by running: python3 -m script.hassfest.
[ ] New or updated dependencies have been added to requirements_all.txt.
Updated by running python3 -m script.gen_requirements_all.
[ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

[ ] I have reviewed two other open pull requests in this repository.

This PR might break other components. Did you test it?

Removing config from the function signature would require modifications to several other parts of the codebase that pass config to this function. Since there are many dependent functions and components that expect this parameter, removing it entirely would break these components and introduce significant changes across the codebase. Instead of removing the config parameter,  it was  marked as unused within the function body by assigning it to _ (a Python convention for unused variables). This way, the function signature remains compatible with other parts of the code while making it clear that config is not used in this function.
It was tested using Pytest but due to environment issues all the checks were not successful but those related to application credential were.


support for vue3

Hello,
I'd like to ask, if there is planned support for Vue 3 somewhere in the near future.
Thanks

@simo1730  Did you find some alternative to this?  @dnasir @mudin

SOLVED in here: https://github.com/Raruto/leaflet-rotate/issues/39

[optional] you can try use this
https://github.com/littleimagine/vue-leaflet-rotate-marker


How do I change default directory of Live Server?

When I run the live server, it basically points to the default directory instead of letting me choose on which file to run the live server. I need a way such that i can get to choose which file to run on the live server(ie it may be saved anywhere on my computer and I should be able to run it!).

There is a settings liveServer.settings.root to change root from work-space root directory to anywhere else (but it should be inside of work-space).
https://github.com/ritwickdey/vscode-live-server/blob/master/docs/settings.md

I figure it's the best place to mention the following issue:
@ritwickdey The option you are mentioning only works in the main vscode settings, but not in the project settings which is kind of odd since you are going to have a different root for each project ... I guess.

@SylannBin You can configure settings for each project separately by create .vscode (folder) > settings.json and overwrite settings for that project

@ashishgupta1350 @SylannBin I am closing this issue if still have this issue then reopen it.

Hi, sorry to ask, but I do not understand how to change the settings. I see a list of settings under "Contributions" but cannot actually make any changes there. Please advise! Thank you.

@cohn17 I had some issues too. What I did was:

Create a folder under the root of the site, called .vscode
Add a file there, called settings.json
Edit the file and add the following:

{
    "liveServer.settings.root": "/dist"
}

(dist being the root folder I want the liveserver to know about)
Then I actually had to edit the global settings.json:

CTRL+SHIFT+P and type "Preferences".
Search for "liveserver" and click "Edit in settings.json"

I then added the same code inside my global settings.json:

Then launched liveserver, killed it, removed the setting in the global settings.json and then relaunched the server.

From now on, liveserver seems to follow whatever is written in the /.vscode/settings.json - file. Perhaps a bug in vscode?

how do you do this on mac I cannot make a .vscode folder with a "." as the first character.

@cohn17 I had some issues too. What I did was:

Create a folder under the root of the site, called .vscode
Add a file there, called settings.json
Edit the file and add the following:

{
    "liveServer.settings.root": "/dist"
}

(dist being the root folder I want the liveserver to know about)
Then I actually had to edit the global settings.json:

CTRL+SHIFT+P and type "Preferences".
Search for "liveserver" and click "Edit in settings.json"

I then added the same code inside my global settings.json:

Then launched liveserver, killed it, removed the setting in the global settings.json and then relaunched the server.

From now on, liveserver seems to follow whatever is written in the /.vscode/settings.json - file. Perhaps a bug in vscode?

Thankss!

Hi,
I am new to VS Code so sorry for dummy question.
What if for learning purposes I have a few different folders with the same structure inside with different lessons (versions of the sites) and I need to switch from one to another inside the same Workspace? Let's say I opened one index.html inside one of the folders inside root of my Workspace and launched it with the Live Server. Then I need to go to another folder inside my Workspace root and to open another index.html inside that separate folder. I open it up in the Live Server but there is still the previous site version opened again.
Is there a way to set it up in the way that it would open up the files from the currently selected folder inside my Workspace (from the folder where currently active file is located in and its subfolders)?

Hi,
I am new to VS Code so sorry for dummy question.
What if for learning purposes I have a few different folders with the same structure inside with different lessons (versions of the sites) and I need to switch from one to another inside the same Workspace? Let's say I opened one index.html inside one of the folders inside root of my Workspace and launched it with the Live Server. Then I need to go to another folder inside my Workspace root and to open another index.html inside that separate folder. I open it up in the Live Server but there is still the previous site version opened again.
Is there a way to set it up in the way that it would open up the files from the currently selected folder inside my Workspace (from the folder where currently active file is located in and its subfolders)?

I know I'm late, but I just figured this out. Go to the index.html file you want to launch and right-click on it, then choose "Open with Live Server". Remember to close the server first if it's already running from a different html file.

i am also facing this problem, i am also new to line server and github. pls help me. have a look at screenshot please.
"Server is Started at port : 5500"
"Invaild Path in liveServer.settings.root settings. live Server will serve from workspace root"
my code in file is:
{
"liveServer.settings.port": 5500,
"liveServer.settings.root": "/dist",
"liveServer.settings.AdvanceCustomBrowserCmdLine": "chrome --incognito --remote-debugging-port=9222",
"liveServer.settings.NoBrowser" : false,
"liveServer.settings.ignoreFiles" : [
".vscode/",
"/.scss",
"**/.sass"
],
"liveServer.settings.useLocalIp": true,
"liveServer.settings.CustomBrowser": "chrome"
}

You can change it using Ctrl+Shift+P & type "Live Server: Change Live Server workspace", toggle down/make your select

Hi,
I am new to VS Code so sorry for dummy question.
What if for learning purposes I have a few different folders with the same structure inside with different lessons (versions of the sites) and I need to switch from one to another inside the same Workspace? Let's say I opened one index.html inside one of the folders inside root of my Workspace and launched it with the Live Server. Then I need to go to another folder inside my Workspace root and to open another index.html inside that separate folder. I open it up in the Live Server but there is still the previous site version opened again.
Is there a way to set it up in the way that it would open up the files from the currently selected folder inside my Workspace (from the folder where currently active file is located in and its subfolders)?

I know I'm late, but I just figured this out. Go to the index.html file you want to launch and right-click on it, then choose "Open with Live Server". Remember to close the server first if it's already running from a different html file.

Thank you! Seriously easiest work around here. You just made this headache go away


Protobuf patched

Tried to download your method. unfortunately the protobuf doesn't work. Any fix yet ? @athrowaway2021

Could you please give the detailed output of the program and what you're trying to download? This still works for me with my old comics.

it doesnt work with borrowed titles now. only titles you own can be saved. use protobuf 3.19.0

Could you please give the detailed output of the program and what you're trying to download? This still works for me with my old comics.

is there any way for unkindle to fetch HD content?


sync/atomic: stack curruption

What version of Go are you using (go version)?
devel +fd41951
What operating system and processor architecture are you using (go env)?
AMD64 Linux
What did you do?
Compile and run this program:
package main

import "sync/atomic"

var count uint32

func main() {
	buffer := []byte("T")
	for i := 0; i < len(buffer); {
		atomic.AddUint32(&count, 1)
		_ = buffer[i]
		i++
		i++
	}
}

What did you expect to see?
No output. This is what happens in Go 1.7.
What did you see instead?
panic: runtime error: index out of range

goroutine 1 [running]:
panic(0x458f40, 0xc42000a150)
	/go/src/runtime/panic.go:500 +0x1a0
main.main()
	inc_panic_example/main.go:11 +0x76

Nice. Thanks for the report.
Git bisect reports the cause as d6098e4277bab633c2df752ed90e1e826918ca67.
/cc @randall77 @cherrymui


Update codeql.yml

Specify the branches
I'm seeing a weird behavior, i.e. fixes when there's no change in a branch. It's like CodeQL is mixing up the branches. I'm not sure if this will fix the issue, but it's what they suggest in their workflow example
@jhutchings1 if you have any suggestions let me know :)

@XhmikosR Can you point me to a pull request where things got messed up? We've been chasing a couple of issues with our alert diffing functionality, and I'm wondering if what you're seeing is an instance of that.
cc: @rneatherway @tibbes

@jhutchings1 will do as soon as I hit it again. It seems to happen if we push or make PRs sort of at the same time to different branches.
So, you think this PR shouldn't land? I mostly made it so that we follow the upstream action more closely and to see if that would fix the issue.

@jhutchings1 https://github.com/twbs/bootstrap/runs/1400254580 This is a v4-dev branch and the "fix" refers to the main branch.

Aha, yeah, I think you're hitting one of the race conditions in our diffing functionality. We're working on it, but haven't got it all fixed just yet. The changes you proposed in the PR are absolutely fine, but they won't fix the root cause, unfortunately. Hoping to have these issues fixed up soon!

Ah, perfect, I knew we couldn't be the only ones hitting this :)
I will simplify the workflow since we only need one language and I'll wait monitor for any fixes. Thanks for the reply!

@jhutchings1 https://github.com/twbs/bootstrap/runs/1400254580 This is a v4-dev branch and the "fix" refers to the main branch.

@XhmikosR :wave: I'm the engineer working on this issue. I had a look at this specific example and what you're seeing here is some older compatibility code we have for workflows that do analysis on: pull_request. This code looks for a pull request for an analysed commit and if one isn't found it speculatively does the comparison against the default branch. If you then opened a pull request against the default branch everything would appear correct. We are phasing this behaviour out. Your change to the workflow restricts the on: push triggers and should therefore prevent you seeing this in the future for that branch.


Update Header and Footer

#34

[x] Add link to Adventure Site.
[x] Add Patreon link to footer.
[x] Remove freenode link.

hey @TheShubham99 any update on this yet? 🙃


Dev command

When I run dev command I got an error.
If there is more setup to be made please update readme. Seems to be related to webpack setup.

Already being address in the https://github.com/jacekelgda/realtime-polling/pull/11


8569 drop py36 support

Proposed changes:

fixes #8569

Status (please check what you already did):

[x] updated the documentation
[x] updated the changelog (please check changelog for instructions)

Hmm seems that update makes mypy discover 146 untyped call errors 😕

Seems the newer version of sanic does not have type information yet. I reverted back to 20.3.0 and the type errors are gone again

@m-vdb The python 3.6 drop is working for now without the sanic update
It seems the last missing puzzle piece is removing the python 3.6 checks from the branch rules of the repository otherwise they are stuck in Expected — Waiting for status to be reported :https://github.community/t/expected-waiting-for-status-to-be-reported/18001
I don’t know if there’s anything we should take into consideration there as it will disable this check repository wide. I assume the risk is low overall, since we’ll keep all the other 3.7 and 3.8 checks in place - so it’s unlikely something would get merged in the meantime

I don’t know if there’s anything we should take into consideration there as it will disable this check repository wide

we can do that for main and 3.x branches

we can do that for main and 3.x branches

ah good to know! I can't do it, since I don't have the necessary edit rights - so up to you!

Thanks @twerkmeister ! Can you also address the following comments in the code:

rasa.telemetry
rasa.utils.common
tests/test_telemetry.py (and also below in the same file)

(I found those by searching for 3.6 everywhere)

good catch! Will do!

Could we please make this a priority? 🙌🏻 We actually need that for the "engine" part of the architecture revamp. We can hack it for now but it's not ideal.

Hey @tmbo, would you still know from your comment a year ago what can be done here when we drop py3.6? It's not clear whether some functionality was missing in python 3.6 that forces that function to be a generator or whether those generators can be handled differently with py 3.7 onwards? Any pointer would be help!
https://github.com/RasaHQ/rasa/blob/3ac95305b47270fa62bb70ecc8742e40e6f6a8f2/rasa/telemetry.py#L680-L749

wuhuu! 🚀


(vcredist*) Refactoring of vcredist2015 and vcredist2017

As promised here, I have crafted a new package for the "140" version of the Visual C++ Runtime, which is the version released with Visual Studio 2015 and subsequently updated in Visual Studio 2017.
The new package, vcredist140, contains all the installation and uninstallation logic, dependencies etc. The existing vcredist2015 and vcredist2017 packages are converted to meta-packages, pointing to appropriate versions of vcredist140.
The package logic has been rewritten from scratch and now supports the following features:

detection of prerequisite Service Packs (Vista, 7),
detection of this or higher version being already installed (to conserve bandwith of folks with metered connections),
more robust uninstallation.

My plan is to publish to Chocolatey.org all versions of vcredist140 corresponding to published versions of the 201x packages (i.e. 2015 RTM, 2015 Update 1/2/3-two versions, 2017 Preview5, RC1 and RC5), which is why I evolved this package starting from 2015 RTM. For the two vcredist201x packages I will publish one new version, which converts them to meta-packages and, in case of 2017, updates to RC5.
All package versions included in this PR are available for testing from a MyGet feed.
I have also obtained permission from @pocki to move vcredist2015 officially to this repo.

Please note that indentation is 2 spaces by the guidelines.

Oh? When did that happen?? I seem to recall the guidelines specifying 4 spaces earlier, why the change?
Personally, I don't mind it in nuspec, but I find code much more readable with 4 spaces.
I'll fix the nuspec issues, sure. As for the icon, I just reused KennethB's icon from the VisualStudio2015* packages. I suppose I can extract the icon from devenv.exe.

@jberezanski Yes, in the Wiki there was once written 4 (which also would be my personal preference :).
If I remember correctly @AdmiringWorm learnd me the lesson back then, so he might know more details why 2 and not 4.

In all honesty, I don't really know why 2 instead of 4.
It was changed to 2 since since the guidelines and the .editorconfig was using different values, and since the .editorconfig file was added before the guidelines it was correct (IMO) to change the guidelines to follow the editorconfig file instead.

I see. Well, I can live with that, I suppose.
All requested changes done.

Cool, thanks for reviewing!


fix grammar error

What this PR does / why we need it:
Noticed this https://github.com/fluxcd-community/helm-charts/pull/163/files and fixed DCO,signing and similar issues in other places.
Special notes for your reviewer:
Checklist

[x] DCO signed
[x] Chart Version bumped
[x] helm-docs are updated
[x] Helm chart is tested
[x] Update artifacthub.io/changes in Chart.yaml
[x] Run make reviewable

superseded by #202


PR: Create Reviewer Guidelines

Description of Changes
This PR adds REVIEW.mdto the root directory. This document contains the draft Reviewer Guidelines myself and multiple Spyder reviewers would like to add to the project's contributing process.
This document has mainly been a collaboration between myself, @juanis2112, @steff456, @CAM-Gerlach, and @ccordoba12. Review is absolutely welcome!

[x] (n/a) Wrote at least one-line docstrings (for any new functions)
[x] (n/a) Added unit test(s) covering the changes (if testable)

[x] (n/a) Included a screenshot or animation (if affecting the UI, see Licecap)

[ ] Link this document to other relevant community engagement resources. Maybe it should be pointed to in CONTRIBUTING.md?

I'm looking to merge to master because the contributing guide lists that this is for breaking changes. This is a breaking community change and not tied to any particular software release. Please let me know if it needs to be merged to a different branch.
Issue(s) Resolved

There is no related issue. This document was written in response to a review of Spyder's current Code of Conduct and to help make reviewing pull requests more clear for reviewers and PR authors.
Affirmation
By submitting this Pull Request or typing my (user)name below,
I affirm the Developer Certificate of Origin
with respect to all commits and content included in this PR,
and understand I am releasing the same under Spyder's MIT (Expat) license.

I certify the above statement is true and correct:
isabela-pf

Pinging @spyder-ide/core-developers for review per @ccordoba12's request. Thanks!

NB, check failure is unrelated; seems the dep check on macOS requires Spyder Kernels 2.x (which is compatible with the current Spyder 5), but 3.x is installed (presumably for the future Spyder 6). I'm guessing the former is in error, but I'll leave that determination to @ccordoba12 or someone more actively involved in this area.

I'm multitasking so I think I didn't do that amend quite right (that's not the commit messages I intended…), but I believe I've made the change to sentence-per-line. Thanks for providing the Gist!

As a side note, given the accidental no-message commit, spurious merge and reversion of interstitial changes, this PR might be a great chance to try out our new prototype policy and go with a squash merge, though given the otherwise well written and thought out commits and importance of the history here, I wouldn't want to loose that either and would be happy to help guide @isabela-pf with a interactive rebase to fix these issues, if she prefers.

@CAM-Gerlach I'm fine with a squash merge, especially as a test. Thanks for asking.

I think I've either made changes based on all the above reviews or left comments. Let me know if I've missed any.
Overall, though, I'd like to note a few things.

This PR is a proposal, and an experiment at that. It doesn’t have to be accepted. I’m not regularly a Spyder reviewer, so I also want to say that these changes will impact me less than many of the people commenting on this PR. Based on some of the comment threads above, it doesn’t sounds like reviewers actually want this. If that’s the case, then this PR shouldn’t be merged. I think one of the worst things we can do is break promises we make to the community, so we shouldn’t have guidelines we are going to ignore.
Because this PR links itself to the Code of Conduct, I know it needs ample review. Based on how this has been going so far, I’m not going to be able to keep up with the requested changes in the limited time I have for this. This PR is based on a document that’s been drafted and reviewed by multiple people for a month prior to the creation of the PR (it was requested that I not start with a public draft PR and I honored that). It may be best if I close this PR and someone else opens a new one (with the same content, if wanted) to steward these changes if we expect more substantive review to this document to come.

Hey @isabela-pf ; really sorry this process has taken up so much of your always-valuable time. I know we all really appreciate the thoughtfulness, grunt work, expertise and insight you've put into it, and I apologize if anything I may have said took away from that. Given that this is a policy that will have significant binding effects on all Spyder developers and contributors, we want to make sure we're all as happy with the result as we can be.
To very briefly explain my review here, I delayed a lot of the finer points of the review/copyedit until the document's initial content was closer to a final form, to avoid bogging things down earlier, and many of them were on changes that only got made right before, during or after this was made into a PR, including most of the ones that resulted in substantial discussion (merge data, ToC, docs [required] tag, verbiage around optional changes, etc), alongside a couple things I wanted to get feedback on with a wider audience.
I certainly don't think we should discard all your hard work here, especially framed as an experiment keeping in mind that the perfect is the enemy of the great. I'm happy to pitch in and do my part to help shepherd this along and find consensus, especially since it was my fault we were in this situation, both previously and now. Here's what I propose as a potential path forward to getting this merged:

Apply the couple remaining suggestions that got lost in the merge conflict
Make a decision on whether to not mandate explicit [required] tags on every non-[optional] change for now; my personal view is that removing this would greatly reduce the friction of implementing these guidelines and avoid unintended negative consequences, and we can always re-visit this later.
Address any final feedback

Then, I propose we have a discussion and vote of all @spyder-ide/core-developers who want to participate, with the following potential options. If no vote has a simple majority (>=50%) among the non-abstaining voting developers after two weeks (or earlier, if a absolute (>50%) majority of all devs who have not actively abstained is reached), then we have a community call where all core developers are encouraged to participate to discuss the changes and come to consensus on a decision.
:heavy_check_mark: Merge as is
:scientist: Merge on an experimental basis for now without explicitly trying this to the level of a Code of Conduct violation (i.e. without the second paragraph under "Expected Reviewer Behavior")
:x: Reject as is
:shrug: Abstain
What does everyone thing about this?

After getting that third option Discussion Items straightened out, I think we can move this forward again.
I think @CAM-Gerlach had the right idea above about bringing this PR to some kind of vote to make sure everyone is involved in the decision. After talking to him, @dalthviz, @steff456, and @ccordoba12 I have a proposal for a vote based on what was said above.
Specifically:

Have a version of Discussion Items added to the document.
Have a week for people to ask any questions that may not have come up in the review. (I am okay with this overlapping with the time to determine the Discussion Items, though it’s open to feedback.)
Have a vote of all spyder-ide/core-developers who want to participate, with the following options (vote by reacting to a designated comment on this PR):

:-1: Do not merge
:+1: Merge as-is
:rocket: Have a trial period for the guidelines (I propose three months), time for edits based on what we learn, then vote again on whether or not to merge this PR. This would separate it from the Code of Conduct for now, to be clear.
:eyes: Abstain from voting

If no vote has a simple majority (>=50%) among the non-abstaining voting developers after two weeks (or earlier, if a absolute (>50%) majority of all devs who have not actively abstained is reached), then we won’t merge this PR. The ideas are still open and available for revision, but they would have to become a new PR to be merged.
How does this sound?

Okay, everyone, we have now have a full draft that can be reviewed and voted upon. Since I didn't get feedback on the prior comment about voting, I'll be pulling from that until further notice.
Please vote using the following emoji reactions on this comment.
👎 Do not merge
👍 Merge and have a trial period for the guidelines (I propose three months), time for edits based on what we learn, then vote again on whether or not to merge this PR. This would separate it from the Code of Conduct for the trial, to be clear (and that will be noted at the top of the document with a final commit).
👀 Abstain from voting
If no vote has a simple majority (>=50%) among the non-abstaining voting developers after two weeks (or earlier, if a absolute (>50%) majority of all devs who have not actively abstained is reached), then we won’t merge this PR. The ideas are still open and available for revision, but they would have to become a new PR to be merged.
Voting will be open from the time of posting this comment until a week later. That means voting will close and a decision will be made at end-of-day Tuesday, February 8 Anywhere on Earth.
I've also been asked to ping @spyder-ide/core-developers to join voting. Thanks in advance for your time!

@ccordoba12 @isabela-pf @CAM-Gerlach, the macOS App bundle always fails on merging into master because of a spyder-kernels version compliance error. Do we just ignore that and merge anyway? Do we want to fix that somehow?

@mrclary I actually just spoke with @ccordoba12 about that at today's UX meeting, and he said he will fix that before we merge this, and I'd help @isabela-pf rebase this PR accordingly.

After a tedious slog, I resolved the issue with the merge conflict resolution via merge that prevented the branch from being cleanly rebased on master. I make sure there was no delta with the final product (i.e. git diff was empty).
I marked the PR as a draft to remind @ccordoba12 , or whomever merges it, to make absolutely sure to squash-merge instead of normal-merge to avoid polluting master's commit history, since I didn't individually fixup, squash or re-write the messages of individual commits (except for the merge-conflict one), even those that were originally made by mistake.

Contributors should be explicitly discourage from merging their own PRs. While it generally not appropriate to merge one's own PRs, this does happen, and appropriately so in many circumstances. So it does not seem correct to have a strict rule against it, but it should be explicitly discouraged. Where possible, excepting circumstances should be articulated.
This PR provides guidance pertaining to how PR reviews should be conducted, but it may be useful to also provide some guidance pertaining to initiating and closing review requests.

It may be a good idea to have a list of general areas of Spyder with appropriate reviewers listed for each. One issue facing contributors, particularly new or inexperienced ones, is choosing appropriate reviewer(s). While Github suggests possible reviewers, This will be different than just a list of developers that have contributed significantly to a particular source code file, but topical based, such as "macOS installer" or "plugin architecture", or whatever. A PR may span many UX elements and source code files, making it difficult to determine which reviewer(s) are best suited. A list of appropriate developers will help contributors be more confident in their selection. Choosing appropriate reviewers will also tend to elicit more prompt responses, as the PR deals with areas of expertise/interest to the reviewer.
We should advise contributors to request as few reviewers as possible; when in doubt, select only one reviewer. Another issue facing contributors is choosing how many reviewers to request. It is desirable to have a broad consensus on proposed PRs as well as to have many sets of eyes to catch potential mistakes, but having too many reviewers may unnecessarily delay merging because there is an implicit expectation that all reviewers should approve the PR before merging should occur. Everyone is busy, so the more reviewers required for approval the greater the likelihood of delay. Of course, any reviewer may add reviewers to the PR if they think it appropriate, or request the contributor to do so.
Reviewers should respond as soon as possible to a request to review a PR by acknowledging the request or recusing and recommending/assigning another reviewer.
We should require all reviewers to approve the PR before merging. If recommendations 2 & 3 are followed then any superfluous reviewers will have been removed and it becomes reasonable to expect approval from all remaining reviewers.
We should designating one of the reviewers to execute the merge request.

It may be a good idea to have a list of general areas of Spyder with appropriate reviewers listed for each.

It would definitely be helpful to have an "Experts Index", an overview of high-level areas of expertise, e.g. as a table in the contributing guide, so long as it is kept up reasonable to date. It needn't be too detailed or complicated, just a basic list of us core devs and our areas of interest (e.g. macOS packaging, etc. for you, docs, website, etc for me, LSP and Qt for Edgar, etc.). It could then be simply linked to here as general guidance for PR authors and triagers.
In addition, while not perfect, we could use CODEOWNERS (which has been improved a lot very recently) to help automate that. It works well for us on the Python PEPs repo, and I believe on the core CPython repo as well.
As a backstop, we could also have someone knowledgeable responsible for spending a few moments triaging new PRs, i.e. directing them to the appropriate reviewers.

We should advise contributors to request as few reviewers as possible; when in doubt, select only one reviewer.

Whether a requested reviewer's review is required or optional really depends on the PR and the repo involved, and unfortunately GitHub doesn't provide a straightforward, unambiguous way of signaling this. CODEOWNERS + branch protection does allow a limited form of this, where required reviewers are automatically assigned based on the files changed, but I'm not aware of a way to manually mark reviewers as required or optional for situations where this isn't sufficient.
For example, on the QtPy repo, typically @dalthviz ' review is required every PR, @ccordoba12 also reviewers more important ones, I am generally responsible for reviewing those related to CI/linting/etc,, and generally at least two out of the three of us review every PR before merging, with review requests typically reflecting that. This was basically the same as it was the docs, with me and Juanita signing off on every non-trivial PR, and Carlos as well if it was substantial enough (which was developed into a formal policy at @ccordoba12 's initiative, after a similar though a bit more serious set of instances where a certain Spyder lead maintainer :wink: merged their own PRs without both the others reviewing, and drama ensued). Generally speaking, if someone was requested for review, it was understood that their review was required.
On the other hand, on e.g. docrepr, I cast a wider net tagging Slyvain and several of his developers to get a faster review from whoever's available, with any one of them sufficient for approving and merging, and for small PRs on other repos, I sometimes find myself doing this as well to get a second look before merging soemthing.
On yet other projects, like on the PEPs repo, some reviewers are required (e.g. the PEP author and/or their core dev sponsor, or the maintainer of the given infra component, which usually indicated by codeowners, but not possible in cases where the author is not a Python org member), while some are optional and only review from one of them is required (e.g. the PEP editors tagged to provide proofreading and feedback; there is a mechanism to tag a team that only requires one review from someone on it, but often I was to target specific members based on the PR content and their previous involvement in it).
So the answer is, its complicated :laughing:

Reviewers should respond as soon as possible to a request to review a PR by acknowledging the request or recusing and recommending/assigning another reviewer.

+:100:

We should require all reviewers to approve the PR before merging. If recommendations 2 & 3 are followed then any superfluous reviewers will have been removed and it becomes reasonable to expect approval from all remaining reviewers.

I used to be strongly in favor of this (from past experience in Spyder-Docs), but now having a wider experience with different projects/repos and their needs, I think this is a sensible default for the Spyder org but can be overriden by per-repo policy. Different repos have different needs and according expectations when it comes to whether reviewers are AND and OR, and its easy for someone to work around (or abuse) this by simply removing review requests of people who haven't reviewed.

We should designating one of the reviewers to execute the merge request.

We could use the Assigned field for this; we sometimes use it to indicate when a PR is being worked on by someone other than the original author, but otherwise it is mostly redundant.

Another item we may want to discuss is when to rebase if there are no merge conflicts. If there are merge conflicts, it makes sense to rebase and resolve any conflicts. This also ensures that the CI tests pass under the latest master and proposed merge changes. However, if a PR parent commit is more than a few inconsequential commits behind the latest 5.x commit, even if there are no merge conflicts, the unit tests will not have been run against those later commits. Correct me if I'm wrong, but I think the unit tests are run on the last branch commit, not the resulting merge commit, so rebase is required in order to get accurate unit tests. However, any rebase will require reviewers to re-approve, so some balance must be reached between merge delay and respect for reviewers' time on the one hand and accurate CI tests on the other hand. Guidance on this may have to be at the discretion of the reviewer(s).

@CAM-Gerlach, thanks for your comments. It looks like we agree.

It would definitely be helpful to have an "Experts Index"

👍 It may be easier to implement this in the short term and, if needed in the future, escalate to your other ideas such as a triager or CODEOWNERS.

We should advise contributors to request as few reviewers as possible; when in doubt, select only one reviewer.
So the answer is, its complicated 😆

Exactly. I think we both understand it to be a process, not a rule. We should just pick something. Even if it is revised later, being explicit in the guidelines is better than being implicit.

We should require all reviewers to approve the PR before merging. If recommendations 2 & 3 are followed then any superfluous reviewers will have been removed and it becomes reasonable to expect approval from all remaining reviewers.

I think this is a sensible default for the Spyder org

👍 And if we find it doesn't work well, we can revise it.

We should designating one of the reviewers to execute the merge request.

We could use the Assigned field for this; we sometimes use it to indicate when a PR is being worked on by someone other than the original author, but otherwise it is mostly redundant.

👍 I think that's a great idea.

Correct me if I'm wrong, but I think the unit tests are run on the last branch commit, not the resulting merge commit, so rebase is required in order to get accurate unit tests.

This is correct.

However, if a PR parent commit is more than a few inconsequential commits behind the latest 5.x commit, even if there are no merge conflicts, the unit tests will not have been run against those later commits.

There is a branch protection setting to require the branch to be up to date before merging, so this doesn't happen. I've toyed with the idea of enabling it for various repos, and do it as an informal practice myself, but so far have mostly held off from enforcing it in branch protect, because on the larger and more complex repos (like the main Spyder one) where it has the most value, the test suite also tends to takes much longer to run (I've noticed runs of an hour or more here are common) and have a higher probability of random failures, meaning each PR would need to be rebased and wait its turn to be merged one by run after rebasing and running the test suite, which could greatly decrease development velocity.
At least personally, I've found these sorts of failures to be pretty rare, and they are still caught by the CIs on push after merging and before any release is made. This also adds extra burden to contributors, and I particularly worry that it will result in them merging rather than rebasing on master, as they have an unfortunate tendency to do, which makes the commit history, squashing and rebasing much harder to follow and work with. So I'd suggest at least not hard-enforcing this requirement with branch protect, and instead requesting it when needed on a case by case basis for major changes.

However, any rebase will require reviewers to re-approve, so some balance must be reached between merge delay and respect for reviewers' time on the one hand and accurate CI tests on the other hand.

It is configurable in the branch protection settings whether new changes dismiss earlier approvals, but yes, this is indeed a tradeoff.

Just as a side note, there are also some steps after something gets merged that maybe could be worthy to reference here. They are at https://github.com/spyder-ide/spyder/blob/master/MAINTENANCE.md mostly regarding the way to keep branches up to date between each other (like master vs 5.x for example) or when a merge also involves updating the sub-repos

:warning: :warning: :warning: IMPORTANT REMINDER to Carlos: Don't forget to squash merge! :warning: :warning: :warning:


change accountType to androidAccountType and convert to enum class in dart

Minor Polish for android account type.

@lukasgit For a second pass.
This is a breaking change and thus should be documented in the change log accordingly. Please increment the version as well.


Researchify/client eslint refactor pt.4

Description
Turn some eslint rules back on:

radix
spaced comment
no noninteractive element interaction
no static element interaction
click events have key events
arrow body style
no return assign

Type of change

[ ] Bug fix
[ ] New feature
[x] Refactoring
[ ] Documentation

Problem
Rules were suppressed before.
Solution description
As above.
Tests
SA checks passed? Y
All unit tests pass? NA
Builds successfully? Y
Risk
Low

Bug in the timestamp

Bug in the timestamp

They're fixed now.


Add tests

Feature Requests
Checklist

[x] My feature request is specific to @rootstrap/validate.

[x] I've searched open issues to make sure I'm not opening a duplicate feature request

Description
Tests should be added to validate that given certain value inputs, the custom validators return the expected result

Is there a particular testing framework you were eyeing to build out your test suite? I believe I can help you set this up and get a couple of small tests written this weekend in any case. 🙂

hi @adrichey sorry for the late response. Tests should be quite simple so I think that jest should do just fine. If you are still interested we would really appreciate the contribution!


why failed to allocate GPU's memory

i write a function:
def updatepkl(business):
    file_list = os.listdir("FR/dataset/" + business)
        for file in file_list:
	    file_path = 'FR/dataset/' + business + '/' + file
	    if os.path.isdir(file_path):
	        for i in os.listdir(file_path):
		    DeepFace.find(img_path=file_path + '/' + i, db_path="FR/dataset/" + business + '/',
                     model_name='ArcFace', detector_backend='dlib',
                    distance_metric="euclidean_l2", enforce_detection=False)  # update pkl file

When I execute this method, the GPU's memory is occupied greatly (14G,  total:16G).
When I call it again, the following error occurs:
tensorflow.python.framework.errors_impl.ResourceExhaustedError: {{function_node __wrapped__AddV2_device_/job:localhost/replica:0/task:0/device:GPU:0}} failed to allocate memory [Op:AddV2]

Please explain why this situation occurs.
thanks

Exception is clear. Your memory is not enough.

Exception is clear. Your memory is not enough.

I understand that when I call Deepface.find(), the GPU memory usage will increase.
However, shouldn't the GPU memory usage decrease after I finish executing this method?
Why is it that after calling the find method once, the GPU memory usage remains high for a long time?
Thank you very much.


Implement Py3.9 LCM and GCD

This PR implements the bpo-39648 and bpo-39479, which are planned for CPython 3.9.
This change extends the math module to implement a lcm (least common multiple) function analog to the gcd. Further both functions are extended to take an arbitrary number of int arguments.
The kind of args is in accordance to the 3.9.a6 cpython implementation, although this style of parameters is quite uncommon in the math module; in similar cases iterables are used as arguments. Maybe this changes before release.
Further, I imported the test_math.py module from CPython and skipped all failing tests (unluckily there are plenty of them)
Whats missing: cpython also accepts object arguments having index implemented, this seems so far not be finalized in the reference. Thus I defer the implementation.
The sneaky improvement in this PR is the pdc.sh (pre-delivery check), i.e., a poor mans automation to run all builds and checks.

replaced by #1916


Weird candles values on paper mode

Dear Catalyst Maintainers,
Before I tell you about my issue, let me describe my environment:
Environment

Operating System: (Linux <hostname removed> 4.13.11-1-ARCH #1 SMP PREEMPT Thu Nov 2 10:25:56 CET 2017 x86_64 GNU/Linux)
Python Version: 2.7.14
Python Bitness: 64
How did you install Catalyst: pip
Python packages: $ pip freeze:

agate==1.6.0
agate-dbf==0.2.0
agate-excel==0.2.1
agate-sql==0.5.2
alabaster==0.7.10
alembic==0.9.6
Babel==2.5.1
backports-abc==0.5
backports.functools-lru-cache==1.4
backports.shutil-get-terminal-size==1.0.0
bcolz==0.12.1
bleach==2.1.1
boto3==1.4.8
botocore==1.8.13
Bottleneck==1.2.1
ccxt==1.10.1033
certifi==2017.11.5
chardet==3.0.4
click==6.7
configparser==3.5.0
contextlib2==0.5.5
csvkit==1.0.2
cycler==0.10.0
cyordereddict==1.0.0
Cython==0.27.3
dbfread==2.0.7
decorator==4.1.2
docutils==0.14
empyrical==0.2.1
#enigma-catalyst==0.4.7+7.g881e3e59
git+git://github.com/enigmampc/catalyst
entrypoints==0.2.3
enum34==1.1.6
et-xmlfile==1.0.1
functools32==3.2.3.post2
future==0.16.0
futures==3.2.0
haikunator==2.1.0
html5lib==1.0b10
idna==2.6
imagesize==0.7.1
intervaltree==2.1.0
ipdb==0.10.3
ipykernel==4.6.1
ipython==5.5.0
ipython-genutils==0.2.0
ipywidgets==7.0.5
isodate==0.6.0
jdcal==1.3
Jinja2==2.10
jmespath==0.9.3
jsonschema==2.6.0
jupyter==1.0.0
jupyter-client==5.1.0
jupyter-console==5.2.0
jupyter-core==4.4.0
leather==0.3.3
Logbook==1.1.0
lru-dict==1.1.6
Mako==1.0.7
MarkupSafe==1.0
matplotlib==2.1.0
mistune==0.8.1
multipledispatch==0.4.9
names==0.3.0
nbconvert==5.3.1
nbformat==4.4.0
networkx==2.0
notebook==5.2.1
numexpr==2.6.4
numpy==1.13.3
openpyxl==2.4.9
pandas==0.19.2
pandas-datareader==0.5.0
pandocfilters==1.4.2
parsedatetime==2.4
pathlib2==2.3.0
patsy==0.4.1
petname==2.2
pexpect==4.3.0
pickleshare==0.7.4
prompt-toolkit==1.0.15
ptyprocess==0.5.2
pyfolio==0.8.0
Pygments==2.2.0
pyparsing==2.2.0
python-dateutil==2.6.1
python-editor==1.0.3
python-slugify==1.2.4
python-telegram-bot==9.0.0
pytimeparse==1.1.7
pytz==2017.3
pyzmq==16.0.3
qtconsole==4.3.1
redo==1.6
requests==2.18.4
requests-file==1.4.2
requests-ftp==0.3.1
s3transfer==0.1.12
scandir==1.6
scikit-learn==0.19.1
scipy==1.0.0
seaborn==0.8.1
simplegeneric==0.8.1
singledispatch==<IP_ADDRESS>
six==1.11.0
snowballstemmer==1.2.1
sortedcontainers==1.5.7
Sphinx==1.6.5
sphinxcontrib-websupport==1.0.1
SQLAlchemy==1.1.15
statsmodels==0.8.0
subprocess32==3.2.7
TA-Lib==0.4.10
tables==3.4.2
terminado==0.7
testpath==0.3.1
toolz==0.8.2
tornado==4.5.2
traitlets==4.3.2
transitions==0.6.2
typing==3.6.2
Unidecode==0.4.21
urllib3==1.22
wcwidth==0.1.7
webencodings==0.5.1
widgetsnbextension==3.0.8
xlrd==1.1.0

Now that you know a little about me, let me tell you about the issue I am
having:
Unexpected values on candles
Please consider running the following minimal example

I expect the OHLCV values printed on the terminal to match approximately the current values of the asset.
Instead, I got totally different values.

Here is how you can reproduce this issue on your machine:
Reproduction Steps

Clone the example
Run it
Check the terminal

The output is something like this:
(.envc-unstable) > $ python minimal_example.py
[2018-02-08 15:50:00.571752] WARNING: run_algo: Catalyst is currently in ALPHA. It is going through rapid development and it is subject to errors. Please use carefully. We encourage you to report any issue on GitHub: https://github.com/enigmampc/catalyst/issues
[2018-02-08 15:50:03.575462] INFO: run_algo: running algo in paper-trading mode
[2018-02-08 15:50:04.003574] INFO: exchange_bundle: pricing data for [u'btc_usd'] not found in range 2015-03-01 00:00:00+00:00 to 2018-02-07 00:00:00+00:00, updating the bundles.
    [====================================]  Ingesting daily price data for btc_usd on bitfinex:  100%
[2018-02-08 15:50:05.794220] WARNING: Loader: Refusing to download new treasury data because a download succeeded at 2018-02-08 15:41:18.331122+00:00.
[2018-02-08 15:50:05.799612] INFO: exchange_algorithm: initialized trading algorithm in live mode
[2018-02-08 15:50:05.809971] INFO: minimal_example:
STARTING SIMULATION.
Candles sample rate: 1
Candles frequency: 1T
Candles buffer size: 48

[2018-02-08 15:50:07.155399] INFO: exchange_algorithm: portfolio balances, cash:<PHONE_NUMBER>75, positions: 2.9871062668
[2018-02-08 15:50:16.178304] INFO: minimal_example:
Index: 1
Date: 2018-02-08 15:50:00+00:00

Candle:
O: 94.0                                   <--- $94 for a bitcoin on 08/Feb/2018???
H: 94.0
L: 94.0
C: 94.0
V: 0.1045

Metrics:
...

Portfolio:
Base price: 94.0
Base coin (coin2/usd):<PHONE_NUMBER>75
Amount (coin1/btc): 0.000360530851846

[2018-02-08 15:50:16.218277] INFO: exchange_algorithm: statistics for the last 1 minutes:
                                                                                symbol      amount      cost_basis  last_sale_price
period_close              starting_cash ending_cash  portfolio_value pnl         long_exposure short_exposure orders transactions price  cash
2018-02-08 15:51:00+00:00 1000<PHONE_NUMBER>8<PHONE_NUMBER>4    -2.27973066 2.98710627    0              0      0            8289.9<PHONE_NUMBER>8  btc_usd  0.00036053  13875.81428468           8285.3

Please note that the problem seems to be on the data.history. The data.current seems to be working fine to get the current price.
I expected the data.history to retrieve historical candles from the latest X candles (bar_count parameter).
Another thing worth mentioning is that I am using paper mode on bitfinex without any API keys yet.
What steps have you taken to resolve this already?
I am still investigating the issue
Sincerely,
@vonpupp.

Hi, thanks for reporting.
I was able to reproduce your issue with the code sample you have provided. I have tried to run it on a different exchange (Binance) and the data made more sense. We will investigate this.
Thanks.

Thank you @lenak25. I have changed on the same example the exchange to binance and the pair to neo_usdt, and herewitht he log:
[2018-02-08 17:54:01.428826] WARNING: run_algo: Catalyst is currently in ALPHA. It is going through rapid development and it is subject to errors. Please use carefully. We encourage you to report any issue on GitHub: https://github.com/enigmampc/catalyst/issues
[2018-02-08 17:54:04.432108] INFO: run_algo: running algo in paper-trading mode
[2018-02-08 17:54:04.981490] INFO: exchange_bundle: pricing data for [u'btc_usd'] not found in range 2015-03-01 00:00:00+00:00 to 2018-02-07 00:00:00+00:00, updating the bundles.
    [====================================]  Ingesting daily price data for btc_usd on bitfinex:  100%
[2018-02-08 17:54:07.074835] WARNING: Loader: Refusing to download new treasury data because a download succeeded at 2018-02-08 17:48:24.184994+00:00.
[2018-02-08 17:54:07.079738] INFO: exchange_algorithm: initialized trading algorithm in live mode
> /home/av/repos/customers/mdbasset/strategies/minimal_example.py(190)default_initialize()
    189     import ipdb; ipdb.set_trace() # BREAKPOINT
--> 190     context.coin_pair = symbol(context.parameters.COIN_PAIR)
    191     context.base_price = None

ipdb> context.parameters.COIN_PAIR
'neo_usdt'
ipdb> c
[2018-02-08 17:54:16.517298] INFO: exchange_algorithm: portfolio balances, cash:<PHONE_NUMBER>98, positions: 0.0
[2018-02-08 17:54:20.707616] INFO: minimal_example:
Index: 1
Date: 2018-02-08 17:54:00+00:00

Candle:
O: 108.827
H: 109.66
L: 108.0
C: 109.2
V: 357.466

Metrics:
...

Portfolio:
Base price: 109.2
Base coin (coin2/usd):<PHONE_NUMBER>98
Amount (coin1/btc): 0

[2018-02-08 17:54:20.806742] INFO: exchange_algorithm: statistics for the last 1 minutes:
                                                                                symbol      amount     cost_basis  last_sale_price
period_close              starting_cash ending_cash portfolio_value pnl         long_exposure short_exposure orders transactions price cash

2018-02-08 17:55:00+00:00 1000<PHONE_NUMBER><PHONE_NUMBER>     -13.0849696 2.9633797     0              0      0            109.2<PHONE_NUMBER>  btc_usd  0.00035069  14139.9115358           8450.1

I noticed that the cash is less than USD 1000 even when I haven't yet placed any order and I started with a capital base of 1K.
Does Catalyst save any sort of "state" of last run? Furthermore, could you please explain what is the meaning of the cost_basis which shows a value of 14139.91. I have no clue what that represents.
Thank you.

Yes, it has a state from last run. To clear it: catalyst clean-algo -n my-algo-namespace

@lenak25 and I are running your example now. We'll send you an update soon.

We narrowed it down to a Python 2 issue. We're trying to isolate the root cause. In the meanwhile, upgrading to Python 3 would some this for you.

Awesome Fred, thank you for the updates. Good to know about the state stuff and how to clear it. When I read the doc, I didn't see that.
I am glad to be helping indirectly at least by finding bugs =)

You're helping a lot. Let us know if things are okay with release 0.5.2. We've validated with your script before releasing.

In release 0.5.2


Typo in README.md

Hey there :) Great colorscheme, looking good!
In the README file there's a small typo:
    highlights = require('vesper').bufferline.highlights(),
    -- should instead be
    highlights = require('vesper').bufferline.highlights,

Keep up the great work!

Oh thanks, I'm gonna change it.
Also, thank you for the kind words!


Fix pip upgrade on windows

I added the fixes directly in main, so this does not need to be merged anymore.


Support ES2020 syntax (includes support for Dynamic Imports and BigInt)

Need to update to ESLint 6.2.0 https://eslint.org/blog/2019/08/eslint-v6.2.0-released
Related: #909, #1207, #1122

Fixed in<EMAIL_ADDRESS>


Upload to base model mcmc folder

Have you done it yet?

[x]  @kellijohnson
[x]   @aaronmberger
[ ]   @cgrandin
[ ]   @andrew-edwards

I downloaded it and placed it in its appropriate folder, but I CANNOT CLICK. Someone help.

Mine is still running, but I did:
build(T,F,T,"2019.03.00_base")
So it takes a while to recreate the RData file because need to redo forecasts and extramcmc and everything else.  I wouldn't be surprised if there was an error when just running build() if the new RData file doesn't correspond with the new/longer MCMC run...

ahh, I had the T,F,T part wrong. Thank you, building now.

Our previous base model retrospectives should still be all good, because those are based on the single MLE base model run, that's why the middle "F"


[SPARK-15022][SPARK-15023][SQL][Streaming] Add support for testing against the ProcessingTime(intervalMS > 0) trigger and ManualClock

What changes were proposed in this pull request?
Currently in StreamTest, we have a StartStream which will start a streaming query against trigger ProcessTime(intervalMS = 0) and SystemClock.
We also need to test cases against ProcessTime(intervalMS > 0), which often requires ManualClock.
This patch:

fixes an issue of ProcessingTimeExecutor, where for a batch it should run batchRunner only once but might run multiple times under certain conditions;
adds support for testing against the ProcessingTime(intervalMS > 0) trigger and AdvanceManualClock, by specifying them as fields for StartStream, and by adding an AdvanceClock action;
adds a test, which takes advantage of the new StartStream and AdvanceManualClock, to test against PR#[SPARK-14942] Reduce delay between batch construction and execution .

How was this patch tested?
N/A

still editing, will explain why ProcessingTimeExecutor, where for a batch it should run batchRunner only once but might run multiple times under certain conditions;

Test build #57391 has started for PR 12797 at commit 9d80b15.

@marmbrus @tdas @zsxwing would you mind taking a look? Thanks!

Test build #57391 has finished for PR 12797 at commit 9d80b15.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/57391/
Test PASSed.

Some minor comments about code understandability, but overall this looks good.  Thanks for working on this!

Looks pretty good. @lw-lin could you address the comments and resolve the conflicts?

Test build #57691 has started for PR 12797 at commit bc89962.

LGTM pending tests.

@marmbrus @zsxwing thank you for the patient review! :-)

Test build #57691 has finished for PR 12797 at commit bc89962.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/57691/
Test PASSed.

Merging to master / 2.0. Thanks again @lw-lin


Allow pinning casks

Provide a detailed description of the proposed feature
As a user of package X, I'd like to be able to mark a version Y of that package as blacklisted for example, when it's buggy or incompatible with my environment.
If version Y is currently installed, it should be either updated (if available), downgraded (if available) or perhaps uninstalled as it's unresolvable.
What is the motivation for the feature?
I use vagrant with virtualbox. The latest release has a bug that makes it not work in headless configuration.
That bug has been fixed in master and will be available in the next release
How will the feature be relevant to at least 90% of Homebrew users?
Bugs and regressions may happen to any package
What alternatives to the feature have been considered?
Manual install

brew pin provides this behaviour for formulae. We do not have something like this for casks. For both formulae or casks your best bet is to extract the formula or cask into your own external tap where it won't be updated without your intervention.

brew pin provides this behaviour for formulae. We do not have something like this for casks.

I know. Hence the feature request for it.

You might be interested in https://github.com/buo/homebrew-cask-upgrade.

Reopening as a cask-specific request.

This has been discussed numerous times in the homebrew-cask repository, for example see the discussion in https://github.com/Homebrew/homebrew-cask/issues/90242.


4.1 with security fixes?

Environment

Rails 5.x
Simple Form 4.1.x
Ruby 2.5.x

Is it possible to  get a release of 4.1.x  with the security patch in-tow since asking us to jump from 4.1 to 5.0 which generally indicates breaking features for a security fix can cost a lot of resources to have to make happen the same day.  Thanks!

Hi,
That's not the case here; we only released a major version because we had to deprecate the SimpleForm.file_methods configuration option - which is related to the security issue. Other than that, there are no other breaking changes.
We also didn't release other patches because there's a quick workaround if you can't upgrade: explicit set the input type for your forms that are built based on user input:
<%= form.input :avatar, as: :file %>

You can see the detailed announcement here: http://blog.plataformatec.com.br/2019/09/incorrect-access-control-in-simple-form-cve-2019-16676/


feat(ingest): Support protobuf description for enum field

Checklist

[ ] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[ ] Links to related issues (if applicable)
[ ] Tests for the changes have been added/updated (if applicable)
[ ] Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.
[ ] For any breaking change/potential downtime/deprecation/big changes an entry has been made in Updating DataHub

Summary
This PR introduces support for displaying descriptions for enum fields in Protobuf schemas during ingestion in DataHub. A new method has been added to ensure these descriptions are properly captured and shown.
Screenshots
enum TimestampUnitType {
  MILLISECOND = 0; // 10^-3 seconds
  MICROSECOND = 1; // 10^-6 seconds
  NANOSECOND = 2; // 10^-9 seconds
}

As-Is:

Enum field descriptions are not displayed during Protobuf ingestion.
To-Be:

Enum field descriptions are now correctly displayed.

Summary by CodeRabbit

New Features

Introduced methods for enhanced enum handling in Protobuf definitions, allowing for easier retrieval of enum descriptors and values with comments.

Refactor

Streamlined the visitField method for better clarity and modularity, resulting in improved code maintainability.
Added helper methods for creating schema fields and generating field descriptions, enhancing readability and separation of concerns.

Very nice! Please add or update 1 unit test with an enum. Thanks!

@david-leifker Thank you for your time and assistance. I added a test case for enum case in proto, so please take another look! https://github.com/datahub-project/datahub/pull/11027/commits/9a76918765afee7a5910e8fc467b46e8bd582677

Thanks!


Configurable scroll container

See #50

Using this version of Jump going forward until container support is merged into main

Any chance of getting this merged in? Can we do something to help with this?

I would love to see this merged.
One potential block is that master was updated to use ESLint a few days after this PR was created. Once merged, ESLint is complaining, but the fixes are simple:

Add a space after all function names
Add a space after switch keywords

@callmecavs Are there any plans to merge this and support this feature? Looks like there's quite a bit of interest.

any reason to hesitating about merging this PR?

any updates?


How to add font?

I need powerline font in my iTerm theme, but in atom ide terminal is't support.
And it also is't support Chinese .
Thanks for help.

good question, would like to know the same.

Same here.

Duplicate of #33
You can change the font from the "Font Family" entry in the config

Install the font package; Go to Packages, find Platform, click on Settings, scroll down to find Font Family,  enter:  Hack
Now all symbols show up in my powerline

This is how I set it up on a mac after some trial and error:
brew tap caskroom/fonts
brew cask install font-hack-nerd-font

In Atom settings: Packages / Platformio Ide Terminal
Font Family: Hack Nerd Font, Monospace
The icons showed up immediately without needing to relaunch the terminal

duplicate of #33


Share an image or group of images with Image Resizer App

Is it possible to add feature Share an image or group of images with Image Resizer app to change the qualit?

Is it possible to add feature Share an image or group of images with Image Resizer app to change the qualit?

Done, wait for the next release :)

check the 1.4 release :)

This will be added, when i I will reach batch resize feature, stay tuned 👀


Temporary add delay to test to make it past

@halter73

Gross :shipit:

Fix the typos in the commit the message then 🚢 this gross thing 😝


[RFC] Local developer metrics API and implementation

This commit adds the ability to log generation and build times to statsd
in XCHammmer. Through XCHammerConfig, user provides XCHammer with a
binary that can recieve statsd events on standard input and act on
events.

Putting this up in RFC form for now. I think adding good statsd logging code into XCHammer is a solid move and since it makes it easy for folks to get visibility into local developer metrics. statsd is widely known and used, so this code will be applicable across other use cases. Additionally, the paradigm of providing a binary that can receives metrics on stdin would also work for other types of metrics systems than statsd if it ever needs to support that.

It seems like this should be a configurable entrypoint where users can provide whatever script they'd like, instead of forcing a single implementation on everyone. What do you think about adding customizable paths to scripts or something? In theory you could bundle a generic one if you wanted

@keith 💯  ATM you can provide any statsd client implementation via XCHammerConfig.metricsExecutable that writes to your statsd service in any programming language.
e.g. if you wanted to write the tsd over tcp on localhost on port 1337, provide a bash script:
nc -w10 localhost 1337

Currently, the PR supports inputting arbitrary bash scripts for the metricsExecutable, but likely it will be restricted to executable files. For the relative path bit we can make it relative to the project directory if the path isn't absolute.
Does providing metricsExecutable not achieve what you need?

I guess I'm kind of thinking being even tied to the statsd format seems pretty specific. It seems like you might want to achieve this with just an arbitrary script that can gather the data it needs.

Ah nice, I got it 👍. I was originally thinking of implementing a general protocol to transmit interesting events. e.g. something similar to Bazel's BEP system. Currently, the PR uses a TSD ( time series data ) format which is compatible with statsd directly. It's actually possible in the current form to provide a metricsExecutable to maps the TSD strings to some other thing. e.g. you can define a metricsExectuable python script that reads in TSD strings and sends JSON HTTP requests to your metrics service.
That being said, it's possible we can come up with a custom binary or text based protocol e.g. via protobuf. I'm definitely on board with this - the main trade off here is it adds add another layer of things to understand and implement for the people who are simply using TSD directly.

Going to think about this in depth over the weekend.
We can probably do this in a way that is decoupled from metric reporting and makes XCHammer more robust altogether:
There would be a flag that causes XCHammer to log internal perf events to a file ( in some general format ). Through user provided scheme actions we can flush any interesting events to a service, including generation ones. All build related metrics code would then be provided through user provided scheme actions.
The overall changes to XCHammer would be:

improving configuration of schemes ( maybe the hammer config format gains post/pre actions like XcodeGen )
logging events to a file ( given a hammer config flag )
a utility or example directory containing a batteries included, statsd enabled, metric reporting system

@jerrymarino - Weren't we talking about having pre/post actions? Maybe XCHammer could just write out a file in a standard format (chrome tracing , BEP, openzipkin, etc) and that can be consumed for metrics reporting in a "post" action?

The pre/post scheme actions make it easy for users to run ad hoc scripts, which can be used for this and more if needed. I think the output log format could be something more general than the original statsd style

I'm fine just not adding this, which will require the following changes for instrumentation:

call another command tool to log generation metrics
add a runscipt action to log build times