The screen does not update when we import settings

Bug report
Describe the bug
After importing the data, the screen still shows the same data to import.
Steps to reproduce the behavior

Go to Config Sync interface menu
Click on Import content types configs
The data is updated on database, but not in screen.

Expected behavior
The imported files should disappear from the list without needing to restart the application.
Screenshots

Code snippets
N/A
System

Node.js version: 18.18
NPM version: yarn 1.22.19
Strapi version: 4.14.5
Plugin version: 1.2.1
Database: Postgres 15
Operating system: Debian 12 / Alpine

Additional context
In console you can see  Use Query Engine API instead of Entity Service API for type core-store

Can you confirm this issue isn’t introduced since version 1.2. You can do that by explicitly installing version 1.1.3 and seeing if the problem still occurs

Can you confirm this issue isn’t introduced since version 1.2. You can do that by explicitly installing version 1.1.3 and seeing if the problem still occurs

@boazpoolman I tested today on versions 1.1.3 and 1.2.0
In version 1.2.0 the error occurs.
In version 1.1.3 the error does not occur.

I'm seeing another issue (#109), also happening since 1.2.0 and I think they might be caused by the same problem.
I've attempted to fix that by doing some changes in this PR #111.
Could you test that out to see if it solves this issue aswell?
You can install the PR like so:
yarn add boazpoolman/strapi-plugin-config-sync#pull/111/head

@boazpoolman In this version
I no longer see the Use Query Engine API instead of Entity Service API for type core-store message in the console.
After importing the configuration, I see that the configuration was imported, but the file still appears in the list with changes to the id, createdAt and UpdatedAt fields, removing them from the configuration.
Restarting the application the difference disappears
Diff before import

Diff after import

Diff after restart:

Thanks for testing the PR @robsonpiere
I was able to replicate the issue by manually updating a config file and then importing.
This issue only happend for me with core-store.plugin_content_manager_configuration_content_types..... config files.
I've also confirmed that this issue has been introduced in version 1.2.0 as downgrading to 1.1.3 fixes the issue for me.
Sadly the PR doesn't provide a solution for this problem.
Currently investigation solutions.

I've attempted to fix this issue in PR #113.
Could you test that fix on your end?
You can install the PR like so:
yarn add boazpoolman/strapi-plugin-config-sync#pull/113/head

I tested it and now it's ok! 🎉
I just see a message in the console, but I get no error.
[strapi-plugin-config-sync]: Use Query Engine API instead of Entity Service API for type core-store

Fixed in https://github.com/boazpoolman/strapi-plugin-config-sync/pull/113

I believe the issue remains unresolved since a new patch hasn't been released yet.

You're correct. I've re-opened.
Can be closed as soon as it's been released.

The fix has been released with v1.2.2
If you're still having this, or any other issue with the plugin beyond v1.2.2 please feel free to open a new issue.


Add checksum support

@embray I'd appreciate your comments on this.
Right now it's using MD5 hashes.  Should we consider a different/longer hash?  Any strong argument in favor of storing the hash type in the file (and thus opening this up to multiple hash algorithms in the future)?
This implementation only validates the checksums when an explicit flag is passed to read, to avoid unnecessarily reading the entire file.  It always writes checksums to the file, unless the data was memmapped and never accessed at all, since in that case we can assume the existing checksum is still valid.  This does mean that updating the file in place will result in streaming in the entire contents of any data that was accessed (it would be nice to do that only if writes were made, but I don't think there's a way to get that info from memmap).  I think that might be a good tradeoff to encourage people to store checksums in the file, while avoiding the read-time downsides.  But I could imagine also either (a) adding an option to not update the checksums on writing (and thus store zeros in the checksum field to indicate "no checksum") or (b) make not writing checksums the default (which I fear would limit their use in the wild).  Any thoughts or experience from pyfits?

I don't see enormous benefits to allowing multiple checksum algorithms--this isn't for cryptographic purposes so md5 is fine.  So I lean YAGNI on that, and it wouldn't be hard to add in a later version if needed.
I'll have to chew a bit though on the question of when/when not to update the checksum.  I totally agree with only validating the checksum on read upon request for obvious reasons.
I've never been totally happy with how pyfits handles checksums, but I haven't made much effort to change it just for fear of breaking how things already work.  Although I will say I think worrying about whether or not the file was mmap'd is a red herring.  Unless the user has completely replaced the data array with a new one, it's next to impossible to know whether the user has changed any bytes in the array regardless whether it was mmap'd or read fully into main memory.  So if they want to maintain the checksum it requires recalculating even if no changes were actually made (unless the only changes were appends).

Unless the user has completely replaced the data array with a new one, it's next to impossible to know whether the user has changed any bytes in the array regardless whether it was mmap'd or read fully into main memory.

Just to clarify, since wasn't clear.  You're absolutely right.  In the specific case of pyasdf, though, the data isn't even memmapped on first opening of the file, only when the data is actually accessed for the first time.  So in that event, we do know if the user never accessed the data array, that the underlying data couldn't possibly have changed (except perhaps by some other thing that has opened the file, but we don't protect against that in general anyway).  But the minute the array is memmapped, all bets are off, and we have to assume it was changed.

In the specific case of pyasdf, though, the data isn't even memmapped on first opening of the file, only when the data is actually accessed for the first time. So in that event, we do know if the user never accessed the data array, that the underlying data couldn't possibly have changed (except perhaps by some other thing that has opened the file, but we don't protect against that in general anyway). But the minute the array is memmapped, all bets are off, and we have to assume it was changed.

Right.  It's the same way in PyFITS--if the .data attribute as never accessed we can assume the data wasn't modified and can't avoid recalculating the checksum entirely.  I need to double check but I'm pretty sure it is in fact smart enough not to do that (unless there was no checksum in the first place and the user has requested that one be added).

Yeah, the relevant bit of code is here: https://github.com/astropy/astropy/blob/master/astropy/io/fits/hdu/base.py#L553
The self._data_loaded attribute is the one that specifies whether the data has been accessed or not.  It just assumes that if the data was loaded it may have been modified.


11/01/2018 05:50 : Create Pull Request for branch prTesting_2018110105 -> master

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

split/updateTestCon.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Updated elgohr/Publish-Docker-Github-Action to a supported version (v5)

elgohr/Publish-Docker-Github-Action@master is not supported anymore

I see you've opened a PR there already. I'll sync with the original repo after it is merged.
Thanks again


Requiem "Wandering Spirit" no longer an option to choose

Just happened in the recent update I presume. Requiem hasn't had an update so I made the issue here assuming it was on this mod's side.
Not sure if this is intended in any way, and I am well aware that the "Opus Daemonium" banishment book makes you a Wandering Spirit, however having the choice might be a good idea to be disableable.

Hi, I am pretty sure this is fixed if you use Origins 0.5.0 or higher, thus I'm closing this issue (without having tested it specifically). If the issue still occurs, please let me know.


For 116 and 117 Issue fix

I have fixed the 116 and 117 issues raised by me.

Please recreate this PR with develop


(Backend) Enable users to update escape rooms that have already been created

Update the lambda function and API in order to allow users to make edits to their already created escape rooms.

Todo

[ ] Update the python lambda function to update the escape room data
[ ] deploy backend to prep for a test
[ ] run a lambda console test to make sure it is working
[ ] Test with the completed frontend


AttributeError: 'NoneType' object has no attribute 'startswith' when using t2t_decoder

How do I fix this?
(magenta) usuario@Strix:~/Escritorio/train$ t2t_decoder   --decode_hparams="${DECODE_HPARAMS}"   --decode_interactive   --hparams="sampling_method=random"   --hparams_set=${HPARAMS_SET}   --model=${MODEL}   --problem=${PROBLEM}   --output_dir=${TRAIN_DIR}
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/linear_model/base.py:35: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from ..utils.seq_dataset import ArrayDataset, CSRDataset
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/linear_model/least_angle.py:23: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from ..utils import arrayfuncs, as_float_array, check_X_y, deprecated
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/utils/random.py:10: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from ._random import sample_without_replacement
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/linear_model/coordinate_descent.py:30: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from . import cd_fast
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/linear_model/init.py:22: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from .sgd_fast import Hinge, Log, ModifiedHuber, SquaredLoss, Huber
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/linear_model/init.py:22: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from .sgd_fast import Hinge, Log, ModifiedHuber, SquaredLoss, Huber
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/linear_model/sag.py:12: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from .sag_fast import sag
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/svm/base.py:8: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from . import libsvm, liblinear
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/svm/base.py:8: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from . import libsvm, liblinear
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/svm/base.py:9: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from . import libsvm_sparse
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/neighbors/init.py:6: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from .ball_tree import BallTree
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/neighbors/init.py:6: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from .ball_tree import BallTree
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/neighbors/init.py:6: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from .ball_tree import BallTree
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/neighbors/init.py:7: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from .kd_tree import KDTree
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/decomposition/online_lda.py:28: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from ._online_lda import (mean_change, _dirichlet_expectation_1d,
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/utils/graph.py:16: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from .graph_shortest_path import graph_shortest_path  # noqa
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/isotonic.py:11: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from ._isotonic import _inplace_contiguous_isotonic_regression, _make_unique
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/manifold/t_sne.py:26: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from . import _utils
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/manifold/t_sne.py:27: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from . import _barnes_hut_tsne
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/manifold/t_sne.py:27: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from . import _barnes_hut_tsne
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/tree/tree.py:40: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from ._criterion import Criterion
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/tree/tree.py:40: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from ._criterion import Criterion
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/tree/tree.py:40: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from ._criterion import Criterion
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/tree/tree.py:40: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from .criterion import Criterion
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/cluster/k_means.py:37: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from . import k_means
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/cluster/k_means.py:38: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from ._k_means_elkan import k_means_elkan
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/cluster/hierarchical.py:23: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from . import _hierarchical
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/cluster/hierarchical.py:23: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from . import hierarchical
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/cluster/dbscan.py:20: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from ._dbscan_inner import dbscan_inner
/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/sklearn/feature_extraction/hashing.py:14: RuntimeWarning: numpy.dtype size changed, may indicate binary incompatibility. Expected 96, got 88
from ._hashing import transform as _hashing_transform
Traceback (most recent call last):
File "/home/usuario/.conda/envs/magenta/bin/t2t_decoder", line 10, in
sys.exit(console_entry_point())
File "/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/magenta/tensor2tensor/t2t_decoder.py", line 34, in console_entry_point
tf.app.run(main)
File "/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/tensorflow/python/platform/app.py", line 125, in run
_sys.exit(main(argv))
File "/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/magenta/tensor2tensor/t2t_decoder.py", line 29, in main
t2t_decoder.main(argv)
File "/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/tensor2tensor/bin/t2t_decoder.py", line 182, in main
hp = create_hparams()
File "/home/usuario/.conda/envs/magenta/lib/python2.7/site-packages/tensor2tensor/bin/t2t_decoder.py", line 67, in create_hparams
data_dir=os.path.expanduser(FLAGS.data_dir),
File "/home/usuario/.conda/envs/magenta/lib/python2.7/posixpath.py", line 254, in expanduser
if not path.startswith('~'):
AttributeError: 'NoneType' object has no attribute 'startswith'

Can you try setting --data_dir to the same value you used for training?

i'm getting same error.
i don't see --data_dir as a flag for t2t_decoder. do you mean setting TRAIN_DIR to same directory as --data_dir during training?

The error is happening because FLAGS.data_dir is None.  BTW the way flags work (which I personally think is a little scary) is that they can be defined in any of the imports, not just the module being executed.  Did you try passing --data_dir and get an unknown flag error?
It's also possible there's an issue with tensor2tensor.

passing --data_dir as a flag of t2t_decoder worked. thanks!

Updated the README to reflect this: https://github.com/tensorflow/magenta/commit/917993bdffb7ff652426ab7c5ba9313e88e136cf


Question about nb4oea70: too little short code

Hi @arnaudroques,
Could you have a look on:
https://github.com/plantuml/pdiff/blob/07c692461393f10f22512723ed5eab33a35fb649/db/nb/nb4oea70obc3r9hnnfju4d2lmopfm93.puml#L1-L11
Is it linked or not to:

https://forum.plantuml.net/13595/latex-little-bug-when-processing-annotations-missing-space?show=13601#c13601

It seems a little short:
@startuml
foo
@enduml

not? :-) 😃
Regards,
Th.

We have bulk-added existing tests, and the referenced URL was indeed completely wrong.
Therefore, we have removed it. However, the test still makes sense for non-regression purposes: we are simply testing that this diagram should fail for every PlantUML version :-)
Thanks for pointing this out!


CI

Docs:
Update github action with original Gatsby publish

PUSH/PULL_MERGE should release
PULL_REQUEST should build only

Library:
Update actions with release on merge

Implement the conventional commits (without semantic versioning due to react native version)
npm run release should be used after build to maintain correct versioning

Push should be updated to release, I would think.  But I'm unsure when release is run (tags? or actual release)
# Documentation Build & Publish
name: documentation

# Fired on push (master) and pull_request (all)
on:
  push:
    branches:
      - master
  pull_request

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner on which this job will run
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: ['12.16.3']

    # Steps represent a sequence of tasks that will be executed as part of the job
    # - Checkout gatsby branch
    # - Update authentication for Github Package Registry @kenjdavidson/base16-scss
    # - Build gh-pages using action
    # - Skip publish if this is anything other than a push (master)
    steps:
      - uses: actions/checkout@v1
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      - name: Authenticate with GitHub package registry
        run: echo "//npm.pkg.github.com/:_authToken=${{ secrets.ACCESS_TOKEN }}" > ~/.npmrc
      - uses<EMAIL_ADDRESS>        with:
          access-token: ${{ secrets.ACCESS_TOKEN }}
          deploy-branch: gh-pages
          working-dir: ./docs
          gatsby-args: --prefix-paths
          skip-publish: ${{ github.event != 'push' }}

For the time being we'll leave the releases as a manual workflow kicked off by workflow_dispatch.  Finally got it working after a bunch of googling.


[BUG] VMware local template requires OS type

When trying to upload a local VMware template you cannot choose ostypeid and you get an API error.
https://prnt.sc/v8iu6w

#839

https://github.com/apache/cloudstack-primate/pull/839#issuecomment-717820827
cc @nvazquez @PaulAngus

bug caused by incompatibility with cloudstack 4.14 api. vmware template configurations are handled by api in 4.15.


Can not intall VSIX  on VS code with macOS

OS :macOS 10.12.6
VScode ver:1.21.0
When I installed from VSIX and shown error following.
error :extension/package.json not found inside zip.

@yuessir This extension is only for VS 2017


Remove hard-coded keys from yaml files

We use the travis.yml file for a tutorial and tell people to update this file.  Noticed that the file has hard-coded slack credentials in there, which probably shouldn't be.

Those are travis encrypted
https://docs.travis-ci.com/user/notifications/#Configuring-slack-notifications

ok great. I wasn't sure. I'll close this then.


Absent Reselect panel in Chrome

Hi.
I installed extension for chrome.
I have icon in the top near the address bar,

but I haven`t any reselect panel in dev-tools among other tools.

an not here, in menu "more tools"

I'm also running into the same issue. I have the extension installed from the Chrome Web Store (https://chrome.google.com/webstore/detail/reselect-devtools/cjmaipngmabglflfeepmdiffcijhjlbb) and also have configured reselect-tools as in the tutorial. (Peeking at __RESELECT_TOOLS__ in console shows selectorGraph and checkSelector with the correct values).

Same issue here.


fix: Allow skipping the modification of the bucket to add our service account's permissions

This PR is included in version 5.4.1 :tada:


v2 - manual flag does not work with CJS server bundles

What version of Remix are you using?
2.0.0
Are all your remix dependencies & dev-dependencies using the same version?

[X] Yes

Steps to Reproduce

Create a new basic remix app e.g. npx create-remix
Rename remix.config.js to remix.config.mjs
Change the serverModuleFormat to cjs
Edit package.json removing "type": "module"
Run npm run dev
Make changes in a route and refresh browser

Expected Behavior
One should see the changes from edited files
Actual Behavior
No changes are visible because the built in remix dev server with the manual flag only busts ESM caches and has no support or warnings for CJS server bundles.

Fixed by #7487


Unable To Run Search With MFA-Enabled Role Profile

Describe the bug
When trying to run ip2cr with an AWS profile set that utilizes MFA, an error is generated:
❯ ip2cr --ipaddr=<IP_ADDRESS> --verbose
INFO[0000] starting IP-2-CloudResource
DEBU[0000] generating AWS connection
FATA[0000] assume role with MFA enabled, but AssumeRoleTokenProvider session option not set.

To Reproduce
Steps to reproduce the behavior:

Set AWS profile that has the mfa_serial value set (export AWS_PROFILE=my-mfa-profile)
Try running a search with ip2cr

Expected behavior
Ip2cr connects to AWS as expected.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment:

OS: [e.g. Ubuntu 22.04, Mac OS 13/Ventura] Mac OS 13/Ventura
GO version (go version): [e.g. go version go1.20.5 linux/amd64] go1.21.1
IP2CR version (ip2cr --help]: [e.g. v0.0.1] v1.0.4

Additional context
Add any other context about the problem here.

Testing infrastructure for this has been created.

The error originates in the aws_connector package when the aws connector is being generated. To use MFA, the AWS SDK for golang requires:

The usage of stscreds.NewAssumeRoleProvider() instead of config.LoadDefaultConfig

We do already use this for assuming a xaccount role specified via CLI, but not via local AWS config

A third parameter be provided to stscreds.NewAssumeRoleProvider() called stscreds.AssumeRoleOptions, specifically the SerialNumber (as well as the token provider, but the sdk provides a built-in one that uses stdin)

https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/credentials/stscreds#hdr-Assume_Role_with_MFA_Token_Provider

That means to support this, we will need to:

Update the aws_connector.ConnectToAWS() function to check if a role ARN and MFA serial are both set for the current local config
If so, we will need to assume the role instead of loading the default config so that we can take advantage of AssumeRoleOptions

The alternative to adding this is in is to simply update the docs to include steps on how to use IP2CR with MFA roles (e.g. using awsume or an equivalent).
I think the added complexity of implementing the code is not worth it given there is an easy alternative, and having the user manager their credentials and have the sdk use the default config paths is more idiomatic.

https://github.com/magneticstain/ip-2-cloudresource/commit/0955af7cc44f494b67c81ae2e5fe9707da7d4a42


bug: Cities and districts should be sorted by name

Bug Definition
Cities and districts should be sorted by name
discord username: notDepresseDeveloper#0919

I can do this


ag doesn't search directory called lib

I'm getting different results between ack and ag in a particular directory because ag ignores the subfolder called lib. I'm using ag 0.27.0 on OS X.
tdhopper@~/temp $ echo "hello" > file1.txt
tdhopper@~/temp $ mkdir lib
tdhopper@~/temp $ cp file1.txt lib/file2.txt
tdhopper@~/temp $ mkdir dir2
tdhopper@~/temp $ cp file1.txt dir2/file3.txt
tdhopper@~/temp $ ag hello
dir2/file3.txt
1:hello

file1.txt
1:hello
tdhopper@~/temp $ ack hello
dir2/file3.txt
1:hello

file1.txt
1:hello

lib/file2.txt
1:hello

(Perhaps this is documented, but I can't find that anywhere.)

DEBUG: Match found. File ./dir2/file3.txt, offset 0 bytes.DEBUG:
Match found. File ./file1.txt, offset 0 bytes.
dir2/file3.txt
1:hello

file1.txt
1:DEBUG: Worker 1 finished.h
ello
DEBUG: Worker 2 finished.

Do you have a global .gitignore? It looks like ag is reading that and obeying it.

I do. (I'd forgotten about it.)

Adding because I encountered this same issue: adding -U to the command fixes this behaviour.


Triage directives that don't respect ng-disabled

Not all of our directives respect the ng-disabled directive. We need to look at each one and identify which ones need to get updated.

Isn't this a duplicate of https://github.com/ngOfficeUIFabric/ng-officeuifabric/issues/268 ?

Yup... my bad...


Metric Evaluation

Hi,
Wonderful work! Currently, when I evaluation the FID with following config on the MJHQ-30K, I got a different number(6.577), which is not match to the paper report(5.76) in Table7.
Model: Sana-1.6B
image resolution: 1024x1024
other param: same with the "scripts/bash_run_inference_metric.sh"

Looking forward to your reply.

Besides, for the DPG evaluation, I saw you need a json file input, so we need convert the dpg prompt/*.txt to one json file, right? share the same structure with MJHQ-30K/meta_data.json?

The 5.76 is the result for paper, which is a mid result during training. We fine-tuned the model longer for better image quality. So the released one is a little bit different;
Yah, need to convert to a json file, same content, just the format is different.

@lawrence-cj  thanks for your feedback. have you evaluated the released version? how about the metric number?

We evaluated the GenEval metrics.


Prioritize road labels over most POI labels

POIs are crowding out most road labels, making poor screenshots at zooms 12-16.
The landuse POIs should probably still win out, but the generic POIs should loose out to all or most road labels.

Fixed in 0a7c1d229d27d96c064e1470930066c8be708464.


raft, dispatcher: use only active members for reporting

Current coverage is 54.05% (diff: 100%)

Merging #1597 into master will increase coverage by 0.28%

@@             master      #1597   diff @@
==========================================
  Files            84         84
  Lines         13934      13943     +9
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           7493       7537    +44
+ Misses         5429       5403    -26
+ Partials       1012       1003     -9

Powered by Codecov. Last update 7e63bde...473521f

Not sure I agree with this. The workers should know about all managers, not just those that happen to be reachable at the moment. This matters in a network partition situation. What's the motivation for the change?

On Oct 3, 2016, at 23:51, Alexander Morozov<EMAIL_ADDRESS>wrote:
You can view, comment on, or merge this pull request online at:
https://github.com/docker/swarmkit/pull/1597
Commit Summary
raft, dispatcher: use only active members for reporting
File Changes
M manager/dispatcher/dispatcher.go (3)
M manager/state/raft/membership/cluster.go (9)
Patch Links:
https://github.com/docker/swarmkit/pull/1597.patch
https://github.com/docker/swarmkit/pull/1597.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@aaronlehmann I don't  know. My motivation was that if you shutdown many nodes with 'docker swarm leave', then my understanding that agents will have many dead managers in their list and eventually will timeout heartbeat. Or if you will have network partition, then all nodes in part with leader will have bad time, but nodes without leader will still have all manager addresses until reconnect to leader.

The situation I'm afraid of is:

Managers A and B are reachable. Manager C is unreachable.
I take a worker node down for maintenance. At this moment, it only knows about A and B.
Later I add managers D and E.
Some time in the future, C, D, and E are the only managers available (maybe A and B were demoted, or are down temporarily).
The worker comes back. It's cut off from the cluster because it was never told about C.

Because of situations like this, I think it's best for nodes to know about as many managers as possible, even if they aren't reachable at the moment.
What if we just give low weights to managers that are unreachable, so they don't get tried often?

@aaronlehmann It will spawn reschedule anyway on network split. Also, it's agent who set weights. If we're okay with rescheduling from healthy nodes on node split, then I'm okay with unreachable managers.
I'm going to close it to not introduce complexity for questionable feature.


T265: Add frame time metadata

Opening this PR on behalf of @akirayou who made this commit. @dorodnic can you confirm that the metadata units for RS2_FRAME_METADATA_FRAME_TIMESTAMP are milliseconds for other cameras?


rewrite using termui ?

any interest in doing a rewrite for this that uses https://github.com/gizak/termui instead of blessed-contrib?

If you feel like it @defermat , I made a stab at something similar in termui: https://github.com/byrnedo/dockdash, if you want please suggest any missing features, it's been a while since it got any love.


chore(main): release 1.25.1

:robot: I have created a release beep boop
1.25.1 (2024-10-28)
Features

✨ Support to close the device screen when controlling (a84c775)
📸 Enhanced recording (7f10161)

Performance Improvements

♻ Optimize camera recording (4be2cf4)
♻ Script and directory structure optimization (68378ef)
⚗ Experimental support for turning off screen controls (9555f58)
⚡ Optimize scrcpy parameter conversion performance (18dcd24)
💄 Improved Russian display (ca79e1b)
📸 Recording camera support (10d0370)

Miscellaneous Chores

release 1.25.1 (f60245b)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v1.25.1
:sunflower:


Migrate CircleCI to supported Node.js version

What would you like?
Migrate CircleCI circle.yml to run in a supported version of Node.js.
Node.js Releases shows 18.x as the lowest currently supported version of Node.js. CircleCI is currently running on an unsupported 16.x version.
Why is this needed?
circle.yml runs with
        machine:
            image: ubuntu-2204:2022.10.2

from Circle CI Machine Images > ubuntu-2204 which includes Node.js 16.17.1.
This version of Node.js entered End-of-life on Sep 11, 2023 and so it is now unsupported.
Other
CircleCI Machine Images
Circle CI Machine Images > ubuntu-2204
Linux Image Deprecations and EOL for 2024
ubuntu-2204:2022.10.2
Linux Machine Executor Update - 2022 October Q4 Update uses
Node.js 16.17.1
Docker  20.10.18
ubuntu-2204:2023.02.1
Linux Machine Executor Update - 2023 Q1 Update
Node.js 18.14.0
Docker  20.10.23
ubuntu-2204:2023.04.2
Linux Machine Executor - 2023 Q2 Update Edge + GA Release
Node.js 18.15.0
Docker  20.10.24
ubuntu-2204:2023.07.2
Linux Machine Executor - 2023 Q3 Update
Node.js 18.16.1
Docker  20.10.24
Deprecated
ubuntu-2204:2023.10.1
Linux Machine Executor - 2023 Q4 Update
Node.js 18.18.0
Docker  24.0.6
Docker release notes

Docker Engine 20.10 release notes
Docker Engine 23.0 release notes
Docker Engine 24.0 release notes

PR https://github.com/cypress-io/cypress-docker-images/pull/1147 resolves this issue


Whenever exception notification

Is there some support for using Whenever with the Exception notification gem ? Or something similar ?
My schedules keep crashing for many reasons (constant not autoloaded properly, etc.) and I'm a little bit in the black because of the absence of notifications (Exception Notifier would normally tell me everything that's wrong)
I was wondering if you had either some best practices to share or if it is possible to add an exception notifier integration ? I recently had to use this guy to enable notifications on shoryuken workers, and I'm hoping it's possible to have it also for whenever ?

If your scheduled jobs boot your rails app then whatever exception notification you have setup there is used. This is not something that falls under the responsibility of Whenever, but is in fact a concern of your application. If you have notes on how to get this set up, a blog post or even a contribution to the Whenever readme would be appropriate.


Improve handling of PANOSE values for monospaced fonts

This pull request addresses the problems described at issue #2857
This is still work in progress.

This is way too old and not addressed yet. I'll come back to it later. Closing for now...


Added metadata to Shop object

I want to merge this change because
it resolve #13022

Impact

[ ] New migrations
[ ] New/Updated API fields or mutations
[ ] Deprecated API fields or mutations
[ ] Removed API types, fields, or mutations
[ ] Documentation needs to be updated

Pull Request Checklist

[ ] Privileged queries and mutations are either absent or guarded by proper permission checks
[ ] Database queries are optimized and the number of queries is constant
[ ] Database migrations are either absent or optimized for zero downtime
[ ] The changes are covered by test cases

How we are storing metadata {"kye":"foo","value":"bar"} like this or [       {         "key": "key1",         "value": "value1"       },       {         "key": "key2",         "value": "value2"       },       {         "key": "key3",         "value": "value3"       }     ]? I'm referring user metadata.

@Smit-Parmar metadata input can be provided as a list or as a dict, so, both of these inputs are valid:
accountRegister(
    input: {
      email<EMAIL_ADDRESS>      password: "password",
      metadata: [
        {key: "example-key", value: "example-value"},
        {key: "example-key-2", value: "example-value-2"}
      ],
      redirectUrl: "http://example.com/",
      channel: "default-channel"
    }
)

accountRegister(
    input: {
      email<EMAIL_ADDRESS>      password: "password",
      metadata: {key: "example-key", value: "example-value"},
      redirectUrl: "http://example.com/",
      channel: "default-channel"
    }
  )

The only difference is the first one will allow you to provide one metadata item, and with the second one you can define as many as you want. In both cases, we store this structure as a dict in the database:
In [9]: User.objects.filter(email="test1@example.com").first().metadata
Out[9]: {'example-key': 'example-value', 'example-key-2': 'example-value-2'}

In [10]: User.objects.filter(email="test2@example.com").first().metadata
Out[10]: {'example-key': 'example-value'}

Thank you @maarcingebala

@Smit-Parmar Please also update the CHANGELOG.md file with an entry about this change.

We should also add the tests for meta mutations, as when the metadata is added to the new type it should be also supported in meta mutations.

@IKarbowiak Can you please specify more about new test case? There is already one test for mutation with metadata.

@Smit-Parmar sure! Let's take a look at saleor/graphql/meta/tests/mutations, there are tests for meta mutations for each module that supports metadata. You should add here a new file for shop testing add a tests for meta mutations for update, delete private and public metadata. Also, here saleor/graphql/meta/tests/queries are the tests for fetching the metadata and you should add a new file with tests here as well.

@Smit-Parmar
There is an error when providing metadata dict in graphql variables

When it is provided in request works fine.

@szczecha Whenever we are passing metadata via input variable then we are passing metadata inside the array something like this
"input": {
    "metadata": [
      {
        "key": "key_one",
        "value": "value_one"
      }
    ]
  }

But while passing input direct to mutation query we are passing like
shopSettingsUpdate(
    input: {metadata: {key: "foo1", value: "bar1"}, privateMetadata: {key: "foo1", value: "bar1"}
  )

That's same thing happening in productUpdate.

@szczecha

@Smit-Parmar We found one more thing that needs to be added - currently, it's impossible to delete metadata from the Shop object. We have a generic API for metadata for that deleteMetadata as well as a few others (see /graphql/meta/mutations/ module). It's impossible to use them since the shop object doesn't have the id field.
We thought we could add the Shop.id field that would allow this. In every other type, the id value is a Base64 decoded form of a string ":", for example look at the following product ID:
In [1]: import base64

In [2]: base64.b64decode("UHJvZHVjdDoxNTI=")
Out[2]: b'Product:152'

Product is the type and 152 is the database primary key of that object.
We could have the same for shop, but instead of using the database PK use a fixed number (since there is always one instance of shop) generated from the following string:
In [5]: base64.b64encode(b"Shop:1")
Out[5]: b'U2hvcDox'

Could you look into adding this change? I think the steps to implement this are the following:

add relay.Node interface to the Shop type
add the id: ID field declaration
add a resolver resolve_id to always return encoded Shop:1?
override get_node method in the Shop type to always return Shop.objects.first()

@maarcingebala Please review above changes. Shouldn't it be SiteSettings.objects.first() as we are using SiteSettings behind the Type Shop. Is it possible to return graphene.Node.to_global_id("SiteSettings","1") from resolve_id?
I tried returning both Shop:1 and SiteSettings:1 but not working. So I return "1" it is working but might not work while adding test case in meta/test/mutations. I'm bit confused here.

@Smit-Parmar Yes that's correct, I meant the SiteSettings model ;) Added a comment about the resolver.

@Smit-Parmar Yes that's correct, I meant the SiteSettings model ;) Added a comment about the resolver.

@maarcingebala Please check comment

@Smit-Parmar I think that for now, it's fine if we only support shopSettingsUpdate mutation. Can you remove the last commit https://github.com/saleor/saleor/pull/13128/commits/1b5710bf777c52d18be0eec95b9d100cd1d1ffd9 and we will be good to merge this PR?

@maarcingebala Reverted

@Smit-Parmar Some linters are failing in CI due to unformatted code. I recommend installing pre-commit, which runs the same linters as our CI before each commit.

@Smit-Parmar Some linters are failing in CI due to unformatted code. I recommend installing pre-commit, which runs the same linters as our CI before each commit.

@maarcingebala pre-commit is already setup on my machine but somehow it's not running automatic on commit .

Great first contributions, congrats, and thank you @Smit-Parmar!

Great first contributions, congrats, and thank you @Smit-Parmar!

Thanks @mirekm . BTW it's my 4th or 5th PR

Great first contributions, congrats, and thank you @Smit-Parmar!

Thanks @mirekm . BTW it's my 4th or 5th PR

Right, I saw the others too, I meant contributions plural! 🙃

@Smit-Parmar FYI, I've added the following PR that supports the generic metadata API with the Shop object, which includes adding the id field you were initially working on: https://github.com/saleor/saleor/pull/13364.

Thanks @maarcingebala for sharing.


Katana Performs Poorly on Nuxt JS websites

katana version:
Katana Version 1.0.3
Current Behavior:
Currently when katana headless -hl or standard (without -hl) is run against a website that leverages the Nuxt JS framework, Katana performs poorly, missing obviously linked pages, returning few or no meaningful results for the website.
Expected Behavior:
Examples of websites where I would expect Katana to perform better but it does not, likely due to the site leveraging Nuxt JS:

gitlab.com
cdnjs.com
upwork.com
openai.com

Steps To Reproduce:
katana.exe -u 'https://cdnjs.com' -hl
Anything else:
Nothing else to add at this time, will update with more information as it is available.

I think this might be mostly related to the way nuxt.js renders the page (ref. https://stackoverflow.com/questions/48577766/nuxt-sites-not-getting-crawled) as apparently the DOM is not fully generated but only upon UI interactions (such as scroll, click, etc) which katana is not currently supporting


[CKEditor] [concrete5link] target=lightbox doesn't work when image2 plugin is enabled

This issue happens only when you enable Enhanced Image (image2) plugin for CKEditor.
How to reproduce:

Enable Enhanced Image (image2) plugin
Insert a content block
Insert an image then click it
Click link button then open the target tab
Select <lightbox> then click OK
Save the content block then publish the page
Click the image. Lightbox doesn't work.

data-concrete5-link-lightbox="image" is not applied to a tag when you enable image2 plugin. This is why lightbox doesn't work.

An override to temporarily fix this issue:
<?php
namespace Application\Block\Content;

use Sunra\PhpSimple\HtmlDomParser;

class Controller extends \Concrete\Block\Content\Controller
{
    public function save($args)
    {
        if (isset($args['content'])) {
            $dom = new HtmlDomParser();
            $r = $dom->str_get_html($args['content'], true, true, DEFAULT_TARGET_CHARSET, false);
            if ($r) {
                foreach ($r->find('a') as $a) {
                    if ($a->target == 'lightbox') {
                        $child = $a->first_child();
                        if ($child) {
                            switch ($child->tag) {
                                case 'img':
                                    $a->{'data-concrete5-link-lightbox'} = 'image';
                                    break;
                                case 'iframe':
                                    $a->{'data-concrete5-link-lightbox'} = 'iframe';
                                    break;
                            }
                        }
                    }
                }
            }
            $args['content'] = (string) $r->restore_noise($r);
        }
        parent::save($args);
    }
}

I think we should add data-concrete5-link-lightbox attribute in the LinkAbstractor instead of concrete5link plugin.

I can confirm this.

That's an interesting idea – I'd certainly be open to having fewer custom CKEditor plugins, definitely.

Unfortunately, my suggestion to fix this issue does not remove a custom CKEditor plugin.

This issue is still valid.

Still wanted


Cleanup validator code and add validator test

Coverage decreased (-0.03%) to 75.701% when pulling 74bb8ab77cf980e82213c66f6fcb5c7a06ff42ba on jmedved:master into fdd3f6656d1e73eb0954aa8dfe0e1ed501536c0f on contiv:master.


incorrect_words.yaml license

Hi, my team would like to use did_you_mean 1.2.0 (coming from Ruby 2.5.0 in Ruby-buildpack 1.7.15) and to approve that I've to analyze it's source code, to be sure that it doesn't have problematic licenses.
Now, in the module at https://github.com/yuki24/did_you_mean/blob/v1.2.0/evaluation/incorrect_words.yaml I've found this sentence:
This data is based on Birkbeck Spelling Error Corpus: http://ota.ox.ac.uk/headers/0643.xml
More specifically, this is a yaml version of the data in FAWTHROP1DAT.643 and FAWTHROP2DAT.643.
released under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
https://creativecommons.org/licenses/by-nc-sa/3.0/
This kind of license is prohibited by our policies; so I'd like to be sure: could you please confirm if the incorrect_words.yaml module is under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License ?
Thanks a lot.

This file has been removed since version 1.2.1 to avoid affecting production environments. Use the version 1.2.1 if you want to be extra safe:
gem update did_you_mean

Even with this file included and shipped as part of the gem, the entire project and all the publicly released versions are still maintained and released under MIT. The "derivative" work evaluation/incorrect_words.yaml is released CC-NC-SA 3.0, but it is only used in the CI build, and none of the actual code in the spell checker depends on this derivative work at runtime. What this means is that your production code will never use it at runtime and the existence of the file shouldn't affect the license of your code base.

Thanks for your update!


Syntax given to case macros should be fully exposed

Sometimes if you're messing with a glob of syntax that happens to have delimiters, you have to be vigilant to manually expose them, otherwise syntax can lose its lexical context. I would like it if syntax given to case macros were guaranteed to be fully exposed.

I'm mass closing issues due to the release of 1.0 obviating lots of bugs. If you feel this issue is something we still need to address feel free to reopen.


How can I get an apikey?

How can i get the apikey for config.js?

you go to the firebase website

i'm sorry. can you teach me how to use this anime site visual studio code. cause i'm junior. new. thanx


Add version number to title page of PDF docs

I think the title page of the PDF version of the docs should display the version number, so one does not need to look inside the docs.

Completed by https://github.com/ArcadeData/arcadedb-docs/pull/217


Patch Kubernetes before 03/05 (schedule by 02/24)

Nessus detected a High vuln on 2021-02-03, so we need to patch before 2021-03-05. If we bundle all High patches and fixes available by that date then we won't have to patch K8s again.
To do:

[ ] include all apt-get updates
[ ] review all newer kernel findings and implement fixes -- this could take a day.

PR cut for sudo and ldap patches:
https://github.com/cloud-gov/kubernetes-release/pull/128

Plan is to get through dev and stage today and cut notification on scheduled maintenance for Wed March 3rd to apply to Prod


Bug in @vitejs/plugin-legacy breaks manifest.json path to vite/legacy-polyfills

Describe the bug
The key in manifest.json vite/legacy-polyfills has changed to \0000vite/legacy-polyfills. I am unable to read that key.
My guess it has something to with this change: https://github.com/vitejs/vite/pull/5601/files#diff-e861d33a288ea61b3aee05203d1c43920c4326d904e3d41b4326adbd30a0127fR599
Reproduction
Vite config:
import legacy from '@vitejs/plugin-legacy';
import { defineConfig } from 'vite';

export default defineConfig({
  build: {
    manifest: true,
  },
  plugins: [
    legacy(),
  ],
});

Run vite build.
Check dist/manifest.json.
System Info
System:
    OS: macOS 12.0.1
    CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
    Memory: 34.61 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.13.1 - ~/.nvm/versions/node/v16.13.1/bin/node
    npm: 8.1.2 - ~/.nvm/versions/node/v16.13.1/bin/npm
  Browsers:
    Edge: 96.0.1054.53
    Firefox: 94.0.1
    Firefox Developer Edition: 96.0
    Safari: 15.1
  npmPackages:
    @vitejs/plugin-legacy: ^1.6.4 => 1.6.4
    vite: ^2.7.1 => 2.7.1

Used Package Manager
npm
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

We have been running into this issue as well, was unsure if it was a Vite specific issue or something that needs to be updated in the framework we are using (https://github.com/nystudio107/craft-vite)

This is very likely an issue with Vite \u0000 is the Unicode character for null
I'm assuming this is some kind of a mistake either in Vite or in the Legacy plugin.


Question: Extract ALPHA result?

Is there a way to extract PNG Sequence or Video with the ALPHA of the result?
For example:
Tracked subject only Masked (soft or binary) without background, instead of using the alpha manually on a composite software.
If not, will you consider to add such feature? 🙏

Do you mean like an RGBA png sequence output?

Yes, it will be very nice to test such feature! 🙏
Also, I found out about Cutie when I first saw XMem2 video demos and I noticed in these videos the GUI is a bit different, with very nice user friendly features:
1⃣ - Magnifier / Zoom-In at the top right screen
2⃣ - Placing the POINTS (similar to SAM projects I saw) for Add / Remove
While in the current UI I use the Right mouse button to add and Right to Remove but I can't see any indication as feedback like the XMeme2 shows
My question based on the above, will you consider to add these UI or maybe other interesting GUI additions?
I'm not a programmer but I have some ideas if you'll be interested to improve the project, I'll be happy to help 💙

I have added RGBA output support. I like those functions from XMem2 but unfortunately I don't have the capacity to implement them any time soon.


Table of Contents Snippet exclusion system

Based on @ericscheid's suggestion.
This modifies the Table of Contents snippet to ignore headers that have an active CSS variable --TOC with a value of exclude.  To facilitate backward compatibility, CSS classes have been added or altered to have this value set along with the monster class in the 5ePHB theme.  Additional classes have been added for toggling on and off exclusions.
To Be Determined:
Which of this CSS work should relocate to the Blank class.

This js works:
 var iframe = document.getElementById('BrewRenderer');
 var iframeDocument = iframe.contentDocument || iframe.contentWindow.document;
 var headings = iframeDocument.querySelectorAll('h1, h2, h3, h4, h5, h6');

 headings.forEach(function (heading) {
   let text = heading.innerText;
   let page = heading.closest('.page,.phb').id;
   let excluded = getComputedStyle(heading).getPropertyValue("--TOC");
   console.log({page, text, excluded});
   // add to the snippet output
   }

Getting an error trying this on the home page:

@ericscheid Is the current behavior acceptable to you? Default exclusions with manual inclusion and exclusion tags?

Getting an error trying this on the home page:

Firstly, why is there a heading element inside a
 where the latter doesn't have an id attribute? What use case is causing this error??

amend to use optional chaining .. and a null will be fed to parseInt instead of throwing an access error.
   let onPage = parseInt(heading.closest('.page,.phb').id?.replace(/^p/,′);

amend the line a bit further where onPage is checked to instead test against NaN (which parseInt(null) produces)
     if(!onPage.isNaN(myValue)) {

@ericscheid, @5e-Cleric , @Gazook89 , @G-Ambatte Is the current behavior acceptable to you? Default exclusions with manual inclusion and exclusion tags via CSS? If the behavior is agreed upon I will just check over for code quality and bugs.

The snippet js starts with the assumption of h1,h2,h3,h4,h5,h6 (currently just h1..h4) and then the general exclusion rules are applied. The h5 and h6 have been added to the current ToC snippet, and then excluded in the css, so as to support any author that might want to later include those levels of headings.
The use of exclusion rules is short and simple to modify and covers the desired exclusions (h3 and h4 inside .monster, various cover pages, h5, h6). There's an argument for also excluding .monster h2 or simply .monster to mimic the base PHB theme. I would lean towards current THB compatibility than militant PHB mimicry, mostly because it's easier to understand what needs to change in the css exclusion rules (unlike if one needed to modify .monster {--TOC: exclude} to instead only exclude h3 and h4 but to also now include h2).
The philosophy of using inclusion tags (i.e. assert via manually editing brew.text in all the curly-blocks) is fraught with tedium. There is a usecase for a generic .addToC {--TOC: include} rule, both for the occasional usage for exceptions, but also to demonstrate what value other than exclude can be used. The rule would need to have stronger specificity though, or use !important.

Firstly, why is there a heading element inside a
 where the latter doesn't have an id attribute? What use case is causing this error??

My guess would be heading.closest('.page,.phb') - that the 5ePHB theme isn't being used.

The use of exclusion rules is short and simple to modify and covers the desired exclusions (h3 and h4 inside .monster, various cover pages, h5, h6). There's an argument for also excluding .monster h2 or simply .monster to mimic the base PHB theme. I would lean towards current THB compatibility than militant PHB mimicry, mostly because it's easier to understand what needs to change in the css exclusion rules (unlike if one needed to modify .monster {--TOC: exclude} to instead only exclude h3 and h4 but to also now include h2).

This particular implementation has no inclusions for .monster based on the described problem.  Should this be revised to include h1 and h2 as present occurs?  I think since this impacts a snippet it is far more permissible to behave differently.

I am lost on what fixes are needed at this time.

@ericscheid fixes applied.

@ericscheid fixes applied.

Tested - numbering is now correct, exclusions are excluded, and curly-injected inclusions are included.
💯

I think the actual CSS exclusion logic has disappeared somehow. We have the CSS classes, but they no longer affect the ToC generation.

Two more things to tweak:

PartCover is still including the H2 header. The only thing on a partCover page that should appear in the ToC is the H1 header: {Part X)
In general, H3's should appear in the ToC with no header:

# Test h1

## Test h2

### Testy test h3

becomes:
- ### [{{ Test h1}}{{ 7}}](#p7)
  - #### [{{ Test h2}}{{ 7}}](#p7)
    - [{{ Testy test h3}}{{ 7}}](#p7)

This PR has changed H3's to appear as      - #### [{{ Testy test h3}}{{ 8}}](#p8)

to test this are we supposed to use the first option only, or any?

Not sure if this has been talked, is the type of element in the ToC set via the type of header it references, or by the position in the ToC? i have an h1 followed by h3, and the h3 gets the same styling as an h2 would.

Not sure if this has been talked, is the type of element in the ToC set via the type of header it references, or by the position in the ToC? i have an h1 followed by h3, and the h3 gets the same styling as an h2 would.

By the position.

to test this are we supposed to use the first option only, or any?

THat is correct. How can we make this more obvious?

to test this are we supposed to use the first option only, or any?

THat is correct. How can we make this more obvious?

I don't understand this answer, which is it? The first option, or the latter ones??

to test this are we supposed to use the first option only, or any?

THat is correct. How can we make this more obvious?

I don't understand this answer, which is it? The first option, or the latter ones??

Oh! I misread  The first one. The latter ones drop the "add this level to the ToC" tags.

Ok, merging this!


resolved UIFont size deprecations.ransfer pull request from origin repo

@OxenBoxen what's this for?


chore(storybook): use namespace vars

@ogonkov This will conflict with the next branch, please reopen to next instead

@ogonkov Could you please rebase the PR branch?


speed of copying with iterators

Is this not "slow(ish)", when using the standard copying mechanisms:
std::copy(rs.cbegin(), rs.cend(), out_it)

??
It'll call this unnecessary code on each iterator-dereference:
https://github.com/martinmoene/ring-span-lite/blob/b8135cd85499a2d5482e048eb8fb6b354350d427/include/nonstd/ring_span.hpp#L968
which calls the slowish https://github.com/martinmoene/ring-span-lite/blob/b8135cd85499a2d5482e048eb8fb6b354350d427/include/nonstd/ring_span.hpp#L836
on each dereference!!!
Should ring and ring_span not have some facilities to speed up copying?
ring_span::copy(InputIt first, InputIt last, OutputIt d_first);              // copy from ring_span to something else
ring_span::copy(InputIt first, InputIt last, ring_span &, OutputIt d_first); // copy from ring_span to ring_span
// etc.

I simply mean:
split the copying into max. 2 fast, simple linear fragments:
If  idx_begin <= idx_end
   [ 0,  1, 2, idx_begin, 4, 5, 6, 7, 8, idx_end, ... ]

To copy from cbegin to cend:
- copy from idx_begin to idx_end

( -> has 1 fragment)
If  idx_end < idx_begin
   [ 0,  1, 2, idx_end,                              idx_begin, 98, 99, 100]   idx_lin_end

To copy from cbegin to cend:
- copy from idx_begin to idx_lin_end (excl)
- copy from 0 to idx_end

( -> has 2 fragment2)

Thanks for bringing this to my attention.
Will look into it, likely in the weekend.

By the way...
I'm a bit intregued by the iterators.
At first I thought there is a bug here:
https://github.com/martinmoene/ring-span-lite/blob/b8135cd85499a2d5482e048eb8fb6b354350d427/include/nonstd/ring_span.hpp#L982
?
Basically:  What if you increment beyond the unsigned max and get wrap around?
But that can never happen, right? (Because the iterator protocol says: iter somewhere in the range, or one beyond the range.)
And also interesting: a begin() iterator that you store to a variable
auto it = rs.begin();

"moves along" with push_backs to rs.

And here's some "fast" code for you to experiment with:
    template<class OutputIt>
    OutputIt copy(const const_iterator &beg, const const_iterator &end, OutputIt d_first ) {
        assert(this == beg.m_rs);
        assert(this == end.m_rs);

        if (beg == end) { // necessary, since otherwise below, would result in b == e, which is not distinguishable from a completely full ring
            return d_first;
        }

        auto       b    = m_data + normalize_(m_front_idx + beg.m_idx);
        auto const e    = m_data + normalize_(m_front_idx + end.m_idx);
        auto const edge = m_data + m_capacity;

        if (e <= b) {
            d_first = std::copy(b, edge, d_first);
            b = m_data;
        }
        return std::copy(b, e, d_first);
    }

This sounds to me like a case of "piecewise contiguous iterators," which also comes up with std::deque.
There's no Standard-blessed way to mark an iterator as "piecewise contiguous" (and no API for what to do next, even if it is). But I know @philnik777 has recently done some optimizations in libc++ for deque iterators; it might be good to take a look at those and see whether it's possible to adapt the shape of them into something ring_span could also either (1) duplicate, or (2) hook into (in a non-standard way, to make the optimization available to libc++'s std::copy).
FWIW, simply adding a ring_span::copy member function feels unsatisfactory to me. Is the problem that std::copy itself is slow? or is the problem that one of ring_span's "special skills" is that you can blat out all its data into a contiguous buffer really quickly, and yet we don't expose that skill in the public API? ring_span::copy solves the latter but not the former.
Consider whether the right API might be (extremely bikesheddable names):
if (!rs.is_contiguous()) {
    rs.rotate_until_contiguous();
}
std::copy(&*rs.begin(), &*rs.end(), out_it);

and whether "rotate" is even possible, if you have a custom popper that you don't know what it does. I haven't thought about this at all. Or alternatively, probably better:
std::copy_n(rs.firsthalfdata(), rs.firsthalfsize(), out_it);
std::copy_n(rs.secondhalfdata(), rs.secondhalfsize(), out_it);

FWIW I can't recommend playing around in implementation-details, but this indeed looks like it could be made a segmented iterator. If you really want to, you can look at __iterator/segmented_iterator.h and specialize __segmented_iterator_traits for your iterator.

Thanks for those pointers.
Looks like I'll roll my own custom ring, to be honest.
Reasons:
a) I won't invest in segmented_iterator as I'm not on libc++, but on libstdc++.
b)
Also, I think that the current ring here, does not fullfill all my criteria.
I want indices or iterators into the ring, that remain fixed... that don't "magically" shift with push_back.
Related: Personally I think that I don't agree with the design decision made here, of having iterators do magic on deferences (the obtained value is shifted along).
For me *it should always point at the same element in the underlying array.
That's safer, gives the opportinity to avoid locking, etc.
Look what happens in this code:
https://github.com/martinmoene/ring-span-lite/blob/b8135cd85499a2d5482e048eb8fb6b354350d427/include/nonstd/ring_span.hpp#L966
You call at_ which calls m_data[ normalize_(m_front_idx + idx) on the dereference.
I would change that, to have normalize_ in the call-path of iterator-increments etc., and not in the dereference.
Why do I say all this? Well...
Here's my usecase:
Image a relativly large ring (many items).
Currently there's no proper index or iterator mechanism, to do this; as currently push_backs, would cause dereferences to shift along ("behind my back" -- I'm joking ... this is all design decision and usecase stuff.)
Yes, there is a potential problem with my approach, namely that too slow reads, will cause the writer to overwrite ranges that the slow reader has not yet read. That's particular to my usecase and I need to work with code, to come up with a good solution.
so far with ...my thoughts...

Thanks for providing insight into this background :)


BUG: Categoricals shouldn't allow non-strings when object dtype is passed (#13919)

[ ] closes #13919
[ ] tests added / passed
[x] passes git diff upstream/master | flake8 --diff
[x] whatsnew entry

Why this change is needed: Categorical variables are by definition single types, so to allow them to take on  different types of values is misleading. Object dtypes should only be allowed when ALL strings or ALL periods are passed (due to the way there are handled internally).
The result of this PR will raise a TypeError when a categorical is created that has an object dtype but doesn't contain all string or all period values.

you already have #14027 you don't need a 2nd
just push to the original
ok for this one

This change will always fail to build because it conflicts with the way MultiIndex.from_arrays, MultiIndex.from_tuples, and MultiIndex.from_product are implemented.
Regardless of the way I implement it, ensuring that Categoricals aren't mixed types will always raise when a MultiIndex is constructed from some listlike with mixed dtypes :\
Do I disregard this and keep working/pushing to this PR?

you would have 2 show an example

@jreback Show an ex. here? the docs? add a test and assert it raises?
If here, then
MultiIndex.from_arrays([[1 ,2], ['foo',  3]])

will raise because this

https://github.com/pydata/pandas/pull/13854 refactors those routines
build your fix on top of this PR

The refactored routines still call Categorical.from_array, so using mixed dtypes with MultiIndex.from_arrays would still raise unfortunately.

can you rebase / update?

@jreback I don't think this will work. Even though #13854 refactored MultiIndex.from_arrays, it still creates categoricals, potentially of mixed types. So i will be closing this, as I can't think of a clean way to get around this :\

Categoricals should never be mixed type
not sure why you think that the constructor creates them
if you have an example pls show it

@jreback If I call
MultiIndex.from_arrays([[1 ,2], ['foo',  3]])

_factorize_from_iterable will create a Categorical from ['foo', 3]  here
I'm definitely misunderstanding something here. In reference to your first comment in #13919, shouldn't that raise on creation?

that should raise its not valid

@jreback So back to my original problem. I can't think of a clean way to allow MultiIndex.from_arrays to exist, while simultaneously blocking the creation of Categoricals with mixed dtypes.
My immediate idea is to pass in some parameter to indicate that a MultiIndex is being created, but as you said in another one of my PRs -- you can't pass in an extra parameter to determine state

@jreback from a MultiIndex.from_arrays point of vue, such mixed types is perfectly valid IMO
Personally, I don't think we should check this at Categorical construction, I would rather check for this in the hdf code itself.


Docs

Update the cheatsheets with more INSERT examples.
Add more UNLESS CONFLICT and nested INSERT examples.
Fixes #2401

I've changed the name to something generic in this PR.


Instruction entries missing from 1.7

screencasts.html has been renamed course.html, so we missed the entries.
need to add tests for that.

fixed in #7


No PR ever merged

I just made a small fix and I am about to start investigating another issue. I was going to open a PR for the fix, but I noticed that never once this project has merged a PR from github.
Since I already wasted my time once, I would like to understand if PR are welcome at all. Otherwise I can just maintain some stuff on my own and still be thankful for whatever I got.
I would consider the present issue resolved by either:

an update of the contributing guidelines discouraging PRs
a merged PR

FIY The two fixes are ready in https://github.com/tierratelematics/aws-instance-scheduler

Hi Andrea - I just reviewed the changes, and they look great. Apologies for work done in the past that was never picked up... We absolutely accept community contributions into future releases of this project (and more generally our Solutions we release on GitHub). I want to make sure that does not happen again. Let me provide some clarity to the process we have to follow and please let me know if you have any questions.
We have internal development and deployment processes that we must follow before releasing updates to solutions. This is why when you look through commits, you will likely only see "Updated to version X.Y.Z". We can take PRs submitted from the community, but right now we have to manually pull them into our internal repositories, run the changes through our CI/CD processes, and then bundle the changes into a new release that we put on GitHub. The unfortunate side effect of this is is that the original PR submitted from the GitHub repo is no longer connected to the updated code.
Your contributions are greatly appreciated! I am working on consolidating PRs and changes into the next upcoming release of Instance Scheduler and will update this issue with more details as they become available.

Hello @georgebearden. here's an idea:

you could make this repo a submodule of your private one and keep the extra CI/deployement scripts in there.
you can configure multiple git remotes, allowing code to flow both ways, consistent changelogs and PRs.
a separate development branch would let you accept code without necessarily releasing it, and with the possibility of later revert if it fails internal QA.

All that needs hiding, should be well hidden, but it's best to develop as openly as possible.
About the fixes, do you want PRs or what do we do?

Thank you for that idea Andrea. I'm taking it back to the team to discuss soon. As for the PRs, the rds snapshot fix is much appreciated. I'm not sure yet if parts of the build process changes will be able to be taken as is, but if you can submit the PR for that soI can review.

you have all three PRs.
There might be more in the future, so I hope you manage to really have development of this code in the open.

Hi Andrea - Just a quick update that we are working to consolidate several of the PRs you and others have submitted. Thank you again for the contributions.

Hi @neg3ntropy - We've just released an update to this solution that incorporated the PRs you posted along with others that were submitted. Sorry for the delay, but really appreciate your help and patience. For now we are still following the release process I described above, but again, I'm grateful for your suggestions and hope to have improvements in the future that you will see.


ldap or active directory password authentication for influxdb web UI

Hi,
This is a feature request for future version of influxdb UI. I am hoping to be able to create admin account but having password authentication from LDAP server or Windows Active Directory server.

@kureikain is that configuration working for you?
I can't get the admin up & running with proxy_pass. The admin seems to expect that InfluxDB runs on the root of the webserver. Because of that assets don't load in the admin (they are hardcoded to use /images/ etc). Besides that it's impossible to specify the API endpoint in the admin. I would like the admin to talk to:
http://statsserver.domain.com/influxdb/ instead of http://root:root@<IP_ADDRESS>:8083/ but I can't specify the '/influxdb/' part and the username/password can't be empty.
This is the config I'm currently using:
  location / {
    root  /var/www/sites/myserver/;
    index  index.html  index.htm;
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/myserver.htpasswd;
  }

  location /influx-admin/ {
    rewrite /influx-admin/(.*) /$1 break;
    # proxy_set_header Authorization "Basic cm9vdDpyb290";
    proxy_pass http://<IP_ADDRESS>:8083;
  }

  location /influx/ {
    rewrite /influx/(.*) /$1 break;
    proxy_set_header Authorization "Basic cm9vdDpyb290";
    proxy_pass http://<IP_ADDRESS>:8086;
  }

This works with Grafana but not with the built in Admin.

Adding LDAP/AD support to InfluxDB is outside the scope of what we're going to do with the web UI. Later this year we'll have a product out that adds more security features, but that'll be a separate thing that you put in front of InfluxDB.


GraphToolConfig is gone

Hi, thank you for this awesome project!
After upgrading to 0.6.0, I noticed that while https://github.com/jerryjliu/llama_index/blob/6330d3522d38a487b833e4debee4b274ba7362e2/llama_index/langchain_helpers/agents/init.py still mentions GraphToolConfig, it does not exist anymore in https://github.com/jerryjliu/llama_index/blob/v0.6.0/llama_index/langchain_helpers/agents/tools.py
I am investigating it myself right now but not yet sure how to migrate my code (Chatbot Tutorial) to the new version.
Thanks for any pointers!

@ralphscheu should be unified under LlamaIndexTool - hopefully that works!


[FEA] Add support for qualification for Dataproc GKE environment

We want to support qualification for Dataproc GKE.  Tasks include:
### Tasks
- [x] https://github.com/NVIDIA/spark-rapids-tools/pull/613
- [x] https://github.com/NVIDIA/spark-rapids-tools/pull/612
- [ ] #618
- [x] Generating speedup factors applicable for Dataproc GKE for T4 GPU instances
- [ ] #617
- [ ] Generating speedup factors applicable for Dataproc GKE for A100 40GB GPU instances

Created separate issue #621 for A100 instances due to unavailability and deprioritization.
Closing this issue as all tasks have been completed.


Add ignore_idx to retrieval metrics

🚀 Feature
Add ignore_idx as keyword argument to all retrieval metrics. Instantiation will be like RetrievalMAP(ignore_idx=-100). Entries where the labels are equal to ignore_idx will not be considered.
Motivation
It is common to have some examples where the predictions should not be considered.
Pitch
Predictions where the labels are equal to ignore_idx will be skipped.
Additional context
Many other metrics include this feature.

Once this feature is approved, I will start implementing it.


HTML TouchEvent not firing as expected

@srujzs
This is a minimal repro from a test blocking the NNBD unfork. Repros in both DDC and dart2js.
import 'dart:html';
import 'dart:js' as js;

main() {
  var touchKey = 'touch-key';
  js.context[touchKey] = false;

  document.onTouchStart.first.whenComplete(() {
    js.context[touchKey] = true;
  });

  print(js.context[touchKey]);
  document.dispatchEvent(TouchEvent('touchstart'));
  print(js.context[touchKey]);
}

Compiled with the existing SDK it prints:
false
true

Compiled with the NNBD SDK running in weak mode it prints:
false
false

Seems like it's not tied to TouchEvents specifically either, I can reproduce this with other EventStreams. I'm still digging through this, and trying to figure out where first fails and why on EventStreams with different Events.

Any update?

Yup, found the root cause in https://github.com/dart-lang/sdk/blob/8c96812bec49947e2e70c788568fac9e36d33814/tools/dom/nnbd_src/EventStreamProvider.dart#L250. The return value used to be null and is now returning a void Future instead, and now the subscription never completes. I'm still trying to dig deeper and figure out how to fix this.

I think it was a bug that this code ever worked as it did. It should not be possible to rely on synchronous side effects for a stream listener.
My preference would be to fix the code in question rather than retain the bug.

Is the fix here in the sdk or in internal test code?

I.e., is there anything to fix in the SDK still?

Our plan is to land a change to the SDK that restores the original behavior only when running in weak mode. This will unblock the unfork and gives us more time to investigate and fix the client code that accidentally depends on the synchronous timing.

Change is pushed in, will document in CHANGELOG and mark this as fixed.


fix(ansible-docker-ci): add coreutils for basename bin

Checklist:

[ ] Have you added an explanation of what your changes do and why you'd like them to be included?
[ ] Have you updated or added documentation for the change, as applicable?
[ ] Have you tested your changes on all related environments with successful results, as applicable?

Type of Changes:

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

What is the current behavior? (link to any open issues here)
What is the new behavior (if this is a feature change)?
Other information:

/lgtm

/lgtm


getServerSideProps doesn't support serverSideTranslations

Description
When using serverSideTranslations inside getServerSideProps, the page doesn't load.
It does work with a production build locally, but not if pushed to Vercel.
I know this has to be some kind of deployment issue, but maybe someone knows what I can do about it. I've looked into the next-i18next code trying to understand what's going wrong but I don't have enough NextJS knowledge.
Maybe there's a documentation page for this repo? Aside from the README, I couldn't find anything.
Occurs in next-i18next version
"i18next": "^20.2.1",
"next": "10.0.5",
"next-i18next": "^8.1.3",
"react": "^17.0.2",
"react-dom": "^17.0.2"

Steps to reproduce
I took the "simple" example from this repo and changed the getStaticProps on the second page to getServerSideProps. Added the missing packages to the package.json and deployed it to vercel (https://simple-2e6voz5th-marvinzeising.vercel.app).

Opening the second page now results in a 500 error page.

On the server, I can see this:

Is getServerSideProps not supported? I found an issue (#652) regarding that but I think that one is quite old.
Expected behaviour
For it to work just like in getStaticProps, I guess.
Screenshots
See above.
OS (please complete the following information)

Device: MBP 2018 15"
Browser: Microsoft Edge Version 89.0.774.54 (Official build) (64-bit)

You need to use:
localePath: path.resolve("./src/locales")

How can you fix it ?

Any updates on this one?

@JavierCaroelli @MuhammadHasham23 This issue had nothing to do with getServerSideProps. When deploying to Vercel, you must use path.resolve to force the Vercel serverless build to include your locales directory.


FR: Separate rules for merging technical and biological replicates

Describe the solution you'd like
Technical replicates can often be merged, while biological replicates need to be evaluated for batch effects.
I think we want to give the user the option to name the column in samples.tsv, and reference that name in config.yaml. One option for both technical and biological replicates, and a secondary option of merging method.
Technical replicates could all be merged by concatenation (for now), and no default column name is needed.
For biological replicates, the default column name could be 'condition' (although I think this is rather vague and would prefer 'replicates').
This way the user can merge technical and biological replicates by only this column in sampltes.tsv
(optional) Additional context
I'm currently changing the merge_replicate rule to all workflows.

This is really needed for ATAC-seq workflows with both types of replicates.

This is really needed for ATAC-seq workflows with both types of replicates.

It's in!


feat: USGS API service class

This is a simple addition - we're simply taking the base routes used in fetchEarthquakes and adding them to a service class named EarthquakeService.
The goal of this was to simplify the way we're getting data into the app. This way we can manage a declarative class, and transition the logic (sorting, mapping, filtering) that we're doing into atoms.
This work completes step one of that effort.

In the next steps we'll need to:

Update atoms to implement organizing logic within themselves
Add loading states to components that read from atoms
Remove fetchEarthquakes
Look into Zustand(??? I keep seeing it so I'm throwing it in here to remind myself)


GH-43211: [C++] Fix decimal benchmarks to avoid out-of-bounds accesses

Rationale for this change
Some of the decimal benchmarks access their benchmark data in strides, without checking that the accesses fall within bounds.
A side effect is that this will break benchmark history because the iterations/s calculation was wrong, even though actual performance is unchanged.
Are these changes tested?
By the continuous benchmarking jobs.
Are there any user-facing changes?
No.

GitHub Issue: #43211

@raulcd @austin3dickey This should fix the recent crashes on the macOS ARM machine.

@ursabot please benchmark lang=C++

This did fix the macOS benchmark run, see https://buildkite.com/apache-arrow/arrow-bci-benchmark-on-test-mac-arm/builds/5582#01909d50-02bc-4b6e-ac5e-885a17eff8ca


feat(orjson): Add support for orjson

At some point ujson was used for json loads https://github.com/sammchardy/python-binance/pull/383 but it does not seem to be the case any more. This code has be lost. I do in v1.0.16
[hannotauber@toolbox python-binance]$ grep -r ujson
docs/changelog.rst:- Stock json lib to ujson (https://github.com/sammchardy/python-binance/pull/383)
requirements.txt:ujson
setup.py:        'requests', 'six', 'dateparser', 'aiohttp', 'ujson', 'websockets'

I am more confident with the work and benchmark results of orjson along with the licensing which comes with Apache 2 and MIT licenses.

@hannotauber orjson also requires Rust and can't be installed under some interpreters.
A better option would be allowing to pass a json serializer into the Client so that any could be used.

@hannotauber It was implemented here: https://github.com/sammchardy/python-binance/pull/1479 Now you just need to have orjson installed and python-binance will pick it up automatically.


Automatically specify batch size for parallel iteration

What problem does this solve or what need does it fill?
The parallel iteration tools that currently exist in Bevy require users to manually set a
As seen in https://github.com/bevyengine/bevy/blob/main/examples/ecs/parallel_query.rs.
What solution would you like?
As in #3183:

Rename the existing methods to par_for_each_manual and so on.
Remove the ability to set the batch size for the user.
Set the batch size automatically using some simple and low-overhead heuristic.

What alternative(s) have you considered?
More sophisticated strategies could be specified, but that is beyond the scope of this issue, which is focused on ergonomics.
Additional context
Works hand-in-hand with #3183, to finish improving the default ergonomics of parallel iteration.
Smarter control over the thread count should help improve the serious performance issues noted in #2173.

Some design work (or benchmarking) is needed to determine what good defaults might be, but otherwise this is a simple PR.


Support Azure Container Deployments + Service Fabric

@russcam @sixeyed so imagine this if you will, a world where Elastic Search clusters can be provisioned using ARM templates but instead of creating a Linux VM Scale Set cluster, the ARM template supports creating a Docker Container cluster...
The ability to deploy either Linux or Windows containers would be great, with a Docker Linux image or a Docker MS Nanoserver image for example.
By the end of the year, it would be great if I could deploy ES containers into an existing Service Fabric cluster. Service Fabric would orchestrate node fail-over, scale-out (provisioning) etc alongside my other microservices.
What do you guys think? 😃

This could be made possible by adding support for autopilot pattern in Docker containers in Azure Service Fabric.

Hey @MedAnd, I suspect if we were to look at supporting this in the future, that it would likely be a separate ARM template, as the complexity of managing deployment to choices of VMs, Service Fabric or Kubernetes/Container service would be large.
Running a complex distributed system like Elasticsearch on top of another distributed system like Service Fabric or Kubernetes is no small undertaking, moreso when you start to look at supporting features like  rolling upgrades and shard allocation awareness.
My thought at this time is rather than keep this issue open on this repository, which is unlikely to be the end repository if such a template is developed, close it for now and look to engage further down the track if such a template is developed. If you're heading to Elasticon Sydney, I'd be more than happy to chat about it further in person 👍


Show error alert notice when any API request fails (both map and chart) (2)

Implement general purpose error notice component. Multiple errors can be visible at the same time. They should stack on top of one another, from the top down, with some margin spacing between them.
X closes the error, if X is not clicked within 10 seconds it closes itself automatically.
Use this initially to show an error when any API request fails: "Error fetching data. Retrying now…"
Now that we can show useful error messages, we should also make the map failure state more elegant. When the api call to get the data for the map fails, it should show the new error message, but the map should still be visible (showing the data from the previous API call that succeeded).

looks good

@dctanner what do you mean by "we can show useful error messages" ?, do you mean we should show the error coming from the server?


runelite-client: Don't try to contain to screen when contain is off

Java's GraphicsConfiguration::getBounds() is completely nonfunctional for me, returning nearly random values, which causes the our window to move itself to random places, often outside of my displays' bounds

Im pretty sure this issue is global to most unix window managers. I think this issue is related: https://github.com/runelite/runelite/issues/2561

#2521 is because it swing thinks the window has a ~20px titlebar always on x11, and tries to move the content pane to be that far down from the window's bounds. This is some other (probably unrelated) x11 java bug.

I do not like the changes to ContainableFrame.java in d72a1b9456ac2757c7012a6f2b35c679e3f490bb
When my window is on the right of the screen, which it always is, the frame now pops up off screen to the right. The old behavior is restored when enabling Contain to screen, but this is undesirable as I frequently move the client off-screen in order to work.
If this is a workaround to an x11 bug, then an additional option should be provided for that, instead of breaking existing functionality to fix a bug.
Thanks :)

For me, this causes the client to expand out of bounds. How is this helping you if it is still using getGraphicsConfiguration().getBounds()?

getGraphicsConfiguration().getBounds() is locked behind a config, which I have disabled, so it's values don't get used.

The config option is meant to prevent dragging the client off screen. Using it to determine if the client expanding should be allowed to expand off screen seems unrelated. Generally I think when someone expands the client without the client locked to the screen the expected behavior would not be the client expanding off screen.
To me this seems like a major UX regression. If your problem is truly specific to *nix WMs I would rather see a different approach taken since so few users use nix.
Have you tried either trying to sanity check the values to determine if they are bogus, or at the very least just disable the window expand logic on non-Windows/osx?

The config option is described as Makes the client stay contained in the screen when attempted to move out of it., which applies to the client resizing or being moved by the user. If you want we can reword the config option to what you think it should be, and replace this check with an OS == Linux check instead, because as far as I can tell most of openjdk's X11 code is mostly unmaintained and not supported.
Additionally the config description contains Note: Only works if custom chrome is enabled. which seems to be wrong because this does atleast attempt to work without custom chrome on.

It looks like setContainedInScreen checks the titlebar, so it doesn't run. Not sure why.
The behavior of the release is that it will expand and keep itself in the bounds of the current screen, even when you have multiple screens, with the config option off (which is default)

Generally I think when someone expands the client without the client locked to the screen the expected behavior would not be the client expanding off screen.
I think its exactly opposite. This behaviour should be at least configurable, and now it is. If people want to split it, they should open new issue for that. NFC why is this being discussed on PR.
It looks like the call to setContainedInScreen checks the titlebar, so it doesn't run. Not sure why.

The previous behavior of:

not locking moving to any one screen
moving the client to not expand off of the current screen

is no longer possible now. I think this is a good default behavior of the client and should be kept as the default behavior.


filter named objects (i.e. buffer, peek) from palette

prevent ops which need to be named from appearing in the palette. see #192 for post-nuit blanche

done


Theme for Cud?

Good looking theme, thanks.
Maybe it's possible to make adaption for CudaText?

http://uvviewsoft.com/
https://wiki.freepascal.org/CudaText#Color_themes

Transferred from https://github.com/arcticicestudio/nord-sublime-text/issues/28

Hi @Alexey-T :wave:, thanks for your contribution :+1:
I've added it to the backlog and @-mention you as soon as I start working on it so you can track the progress or contribute ideas for this port project.
Please note that it will take some time for this port project to be evaluated if the upstream/target application is used widely enough.
There is a massive amount of other issues & PRs over many other port projects with requests and proposals waiting in the queue as well as 40+ port project requests in the backlog. I'm currently very busy working and focusing on the data transition of all port projects to the new and shiny website and documentations to finally have a „single source of truth“ for Nord and all related data, reduce the maintenance overhead and increase the overall project quality. :octocat:
Please also take into account that I work as a software developer in the "real world" and I hope you understand that the time to work on my projects may vary depending on my free time. :pray:
Feel free to work on a port on your own and maybe submit it into a public repository so other users can use it in the meantime. This could also help to bootstrap the official port later on by using it as fundamental code base :smile:

Thanks for your consideration, will test it then.


[BUG] ESLint crashes with import/no-unused-modules and src option

This issue is probably related to #1323. It is slightly different though. It's also using the latest version of eslint-plugin-import, including the fix of #1323.
ESLint crashes with the following error:
$ eslint .
TypeError: Cannot read property 'get' of undefined
Occurred while linting /home/ehmicky/no-unused-modules-bug/file.js:1
    at checkUsage (/home/ehmicky/no-unused-modules-bug/node_modules/eslint-plugin-import/lib/rules/no-unused-modules.js:339:33)
    at ExportNamedDeclaration.node.declaration.declarations.forEach.declaration (/home/ehmicky/no-unused-modules-bug/node_modules/eslint-plugin-import/lib/rules/no-unused-modules.js:732:15)
    at Array.forEach (<anonymous>)
    at ExportNamedDeclaration (/home/ehmicky/no-unused-modules-bug/node_modules/eslint-plugin-import/lib/rules/no-unused-modules.js:731:43)
    at listeners.(anonymous function).forEach.listener (/home/ehmicky/no-unused-modules-bug/node_modules/eslint/lib/util/safe-emitter.js:45:58)
    at Array.forEach (<anonymous>)
    at Object.emit (/home/ehmicky/no-unused-modules-bug/node_modules/eslint/lib/util/safe-emitter.js:45:38)
    at NodeEventGenerator.applySelector (/home/ehmicky/no-unused-modules-bug/node_modules/eslint/lib/util/node-event-generator.js:251:26)
    at NodeEventGenerator.applySelectors (/home/ehmicky/no-unused-modules-bug/node_modules/eslint/lib/util/node-event-generator.js:280:22)
    at NodeEventGenerator.enterNode (/home/ehmicky/no-unused-modules-bug/node_modules/eslint/lib/util/node-event-generator.js:294:14)

The current directory contains the following files:
src/main.js:
export const main = true

file.js:
export const test = true

.eslintrc.json:
{
  "parserOptions": {
    "ecmaVersion": 2019,
    "sourceType": "module"
  },
  "plugins": ["import"],
  "rules": {
    "import/no-unused-modules": [
      2,
      {
        "unusedExports": true,
        "src": ["src/"]
      }
    ]
  }
}

package.json:
{
  "name": "no-unused-modules-bug",
  "version": "1.0.0",
  "dependencies": {},
  "devDependencies": {
    "eslint": "^5.16.0",
    "eslint-plugin-import": "^2.17.2"
  }
}

cc @rfermann

@ljharb: thanks for adding. I will tackle this issue after #1339 is solved.

Thanks @rfermann!

I created a demo repo: https://github.com/ehmicky/no-unused-modules-bug-two

I also got this problem. However I didn't need to specify a src option to crash my process, so the default value is enough to reproduce.
My config is:
import/no-unused-modules:
  - error
  - missingExports: true
    unusedExports: true

@dfleury could you share a minimally reproducible example? Including:

eslint config
files to lint
how eslint is spawned (e.g. eslint command)
versions (node, eslint, eslint-plugin-import)

Like this the maintainers can make sure your issue is fixed together with mine (if they have the same cause).

The problem was, that there was a file to be linted which was outside the specified src folder. These files should be excluded from being linted by this rule.
@dfleury can you verify that you are linting files outside the src folder (process.cwd() by default)?

This is fixing my problem, thanks!
@dfleury I think this issue should be closed after this PR is merged. If the PR does not solve your issue, then it means it was a separate problem, i.e. should be a separate issue. What do you think?

@ljharb Would it be possible to release a new version? Thanks!

As soon as i have the time :-) it is a weekend, after all.

Absolutely, there is no rush! :)

Yes, I can confirm that's working with this fix.
Sorry by not giving a demo in time. I was having some difficulties to reproduce it without knowing the right conditions to do it since my working project is kinda big to track all possibilities in mind.
Once @rfermann told us the problem, I could reproduce it in my WIP demo.
Thanks @rfermann!


Use simple collision for foot also for non-Gazebo models

With @akhilsathuluri we are doing physically realistic simulations of ergoCubSN000 and ergoSN001 (we want to use the real inertia of the robot, and not the irrealistic inertia in ergoCubGazebo models) for doing so, it would be convenient to have the collision shape of the foot as a simple shape also there. Do you think we can have the simple shape of the foot also there for ergoCubSN000 and ergoSN001?
fyi @Nicogene @S-Dafarra

/remind next Tuesday cc @Nicogene

you think we can have the simple shape of the foot also there for ergoCubSN000 and ergoSN001?

It is ok for me 👍🏻

Updating ergoCubSN000 is not possible using creo2urdf due to this issue we decided to fix it only in ergoCubSN001.
If ergoCubSN001 is not sufficient I will try to generate the ergoCubSN000 w/ simmechanics_to_urdf


add racket to language list, projecteuler to oj list, update readme both look and content

Racket should've been added to language list by now
Projecteuler should've been added to oj list by now
Readme look must be updated
Readme content is not great. Readme content must be descriptive, so that it may reveal about the project much more.

issue resolved just now...still readme content need attention. for now this issue's being closed.


Return proper table names on vizJSON and visualization data

We need a way of mapping layers <-> tables.  The table names are the ids, but for some reason both the visualization model and the vizJSON data contains ""."" as table name:

Uhm. The problem is that "table_name" is inside options, and is sent by the editor for torque layers. If you actually need some kind of layer <-> tables mapping we might try something else, backend-supported, instead of reusing that attribute.
Proposal: adding at vizjson v3, to layer, a table_names first-level attribute containing an array of the table names.
Summon @javisantana wisdom on this.
PS: maybe a brief summary about the need for that might be useful.

Yes, you're right, we figured it out.

Uhm, how have you overcome this?

We looked how things were setup on old editor.
Although, I'd say that the table_name is obviously wrong still, so feel free to reopen, but I'd guess it's not a prio to fix that atm.


update available for Tomcat

see https://tomcat.apache.org/whichversion.html
Latest is 10.1.x; we are on 9.0.4

I think this could be done post launch.

Bill's recommendation that we go to version 9.0.59

@htpvu This was done 12 days ago on https://github.com/jhu-idc/idc-isle-buildkit/commit/01981d6a5c27d9b3df3220182c4310ce821eea06 , but we didn't close this ticket.