fix(RouteRegistry): reindex projected array

See https://www.php.net/manual/en/function.array-filter.php.
Fixes #231

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.09%

Covered Lines:
138

Relevant Lines:
148

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.09%

Covered Lines:
138

Relevant Lines:
148

💛  - Coveralls


Separate projection from query execution

Fixes #1120

This PR contains now the first steps of the refactoring to the new query model. Although some usages become now a bit more verbose, the new model feels much more flexible.

I am not yet quite happy with ProjectableQuery, maybe Selectable or something might be better?

@Shredder121 @johnktims  Finally building now. Please review ;)
Some other changes done

rename from Projectable to Fetchable
QueryMetadata validation off by default
experimental Scala query types removed

Let's keep this in progress until we finalize the method names for Fetchable

Concerning finishing the javadocs, I'd like to continue that on a per module basis, that's why there are some empty stubs.
So in order to continue with the javadoc fixes, it would be good to get this merged.

I see, I do agree with that.


chars - right bottom corner ruin my code ;)

https://github.com/tebe6502/Mad-Pascal/blob/master/samples/neo6502/demoeffects/plasma.pas
I wrote workaround but one char left behind ;) no one likes left someone behind :D
binary attached: plasma_0x1000.zip

bad_0x1000.zip
if i try full screen :]

I changed write(row) to NeoDrawString(0, y * 7, row); and now is faster and without last character bug.

What's the exec address of this binary ?

Also the program is the drawString version ?

write version with workaround (last row have one char less the then others) : https://github.com/tebe6502/Mad-Pascal/blob/a58dba631941b7e035a6820e01a52c43baed7a35/samples/neo6502/demoeffects/plasma.pas
DrawString no bugs, fastest: https://github.com/tebe6502/Mad-Pascal/blob/master/samples/neo6502/demoeffects/plasma.pas

What's the exec address of this binary ?

$1000, 0x1000 ;)
neo plasma_0x1000.bin@1000 run@1000

The problem is the console system is designed to operate like one, so it is a print character and advance system. So if you print on the last character of a line it will move to the next character position, the first line on the next line down, and if you are on the bottom of the line this involves scrolling. It could be changed to delay the move till printing but that may cause other issues (e.g. the cursor is not where you'd expect it to be after printing a character).
For this specific usecase I'd suggest making it 53x29 and using the bottom line for a text comment.

I guess using text 'x' to 313,231 wouldn't trigger the scrolling.


RIP ATOM

We know you are going to get axed first in the name of vscode.
RIP.

It does not make sense to develop 2 competing products. It's a valid question how Github will handle it.

I personally think this is not the only thing we all want to know about the future of GitHub but this question is so important what will append to Atom ? to all these package the community created ?
Why do microsoft take so much time to tell us what are their plans ? Do they fear more of us leave GitHub ?

@zmilonas but if Atom is not continued because as @medokin

said it make no sense to develop 2 competing products
will you continue to use an unsuported software (even if it was the coolest when it was active) ?


Extract ApiModelControllerBase and ApiMutableModelControllerBase classes

As per issue https://github.com/opnsense/core/issues/1123 I hereby submit a proposed refactoring.
In order to support the very common case of a controller that that implements getters and setters on a model, I've extracted out two classes, ApiModelControllerBase that can be inherited by read-only API controllers, and ApiMutableModelControllerBase that can be inherited by read-write API controllers.
I have also refactored the IDS and traffic shaper using these two classes. The set code path probably needs review, especially the validation may be a little bit iffy. I also think there's some room for further simplification, specifically in whether OPNsense\Base\ApiModelControllerBase\getModelNodes is correct in the general case. That, or if there needs to be an extention to the model to mark in the metadata if a field should be exposed in the API or not.
I have done basic validation of the get methods, ensuring that I get the same result before and after refactoring, but I have not done testing of the set methods or validation.

getModelName() may also be unneccesary if that can be pulled out of the model metadata.

@pv2b I also think its better to move getModelName to the model metadata. The idea to add simple model classes is good, I'll cherry pick your changes in step by step and refactor where needed.

@pv2b just did some refactoring on your code in https://github.com/opnsense/core/commit/7a67a2c03d07559c929d817aea28b7abd1edf8d0
Let me briefly explain the things I've changed:

move the internal model name (internalModelName) to a property, we may even remove that tag eventually or put a default in there... its only used to set/get the start of the in/out structure from the api point of view
define class name and namespace for your model in $this->internalModelClass
move getModel() to the model base, the default behaviour is mostly the same, you can extend if needed.
validate properties on initialize(), your abstract method forces validation which I couldn't do for the properties, so hence the property validation
getModelNodes() probably better to use the model already available on $this item
and some typo's, nothing special

I will refactor the proxy code in the next commit.

Okay, I like this improved version, but as we discussed on IRC probably it's better to make internalModelClass and internalModelName into statics. I wanted to make them static methods in my version, but in PHP you can't make abstract static functions for some reason. protected static member should not be a problem though.
I think it would be better to put a default in for internalModelName instead, or perhaps just automatically grab it from the class name somehow... or it might as I said be better if that were actually defined as part of the model itself.

Closing this PR to work on #1134 now.


Overload ok_to_log

From @martindsouza on August 31, 2013 11:57
Overload procedure to also accept the global constant integers instead of characters
Copied from original issue: tmuth/Logger---A-PL-SQL-Logging-Utility#42

Just needed to expose private function.


Notification many users

How about notifications from many users, not just one?

You mean information about to whom the notifications will be sent?

Yeap. Now you can only send one user.


lammps-cython: remove

Motivation for this change
Project has not been touched in the last two years and is broken.
The bindings are now incompatible with the library it wraps.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

You forgot to add aliases.


Bug: toolkit shrinks to smaller width with small text input

I was working on enhancing the UI of the package website,  i found out that toolkit shrinks when the text input is smaller.
i have attached a image for the same.
i am fixing this issue and would like the maintainers to assign me the same.

@prateek3255 can I work on this?

Nice catch! assigned it to you @helloshantanu

@prateek3255
Can I take this issue?

@prateek3255 I've resolved this issue allow me to create the PR and kindly merge it as hacktoberfest-accepted.

Nice catch! assigned it to you @helloshantanu

Can I take this issue @prateek3255 ?


Missing backslash in path

In paragraph https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/custom-script-windows#running-a-custom-script-more-than-once-by-using-the-cli
the path reads:
C:\WindowsAzure\Logs\Plugins\Microsoft.Compute.CustomScriptExtension<HandlerVersion>\CustomScriptHandler.log
It should be
C:\WindowsAzure\Logs\Plugins\Microsoft.Compute.CustomScriptExtension\<HandlerVersion>\CustomScriptHandler.log

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 40aaccb8-19ba-168f-f5bf-65f1f5331541
Version Independent ID: 6cdfd166-633a-50a3-2b45-cde0e991e540
Content: Azure Custom Script Extension for Windows - Azure Virtual Machines
Content Source: articles/virtual-machines/extensions/custom-script-windows.md
Service: virtual-machines
Sub-service: extensions
GitHub Login: @GabstaMSFT
Microsoft Alias: gabsta

#reassign @GabstaMSFT

@martindufresne-orc thank you for surfacing this, update is currenting being processed.

@GabstaMSFT Thanks for updating the document.

@VikasPullagura-MSFT this ticket is good to close.

Thanks for your contribution to our documentation
We sincerely apologize for the delayed response. Unfortunately, we have been unable to review this issue in a timely manner. However, we are making overall enhancements to our content. We are closing this issue for now as there has been no activity for a while. If you feel that the problem persists, please respond to this issue with additional information.
?
Please continue to provide feedback about the documentation. We appreciate your contributions to our community.
#please-close


updated experimental/Readme.md with fixed deadlinks

- What I did
- How I did it
- How to verify it
- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "master" git@github.com:prertik/docker.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

LGTM except DCO

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "master" git@github.com:prertik/docker.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842354511344
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.


The date picker in "Localizing" demo is marked invalid

When the value is changed, the date picker in "localizing" demo is marked as invalid for no reason.

Error is with Sugar.js. I created a ticket there: https://github.com/andrewplummer/Sugar/issues/648
The demos are using 2.0.6 version while the 2.0.4 version is working so we could use that in our bower.json. @tomivirkki WDYT?

Looking at Sugar.js recent development, I don't think a fix will done any time soon. So I think better to use Sugar 2.0.4 as it is just a development dependency. https://github.com/vaadin/vaadin-date-picker/pull/642


Starting grid isn't placed properly when adding new scene

Godot version: 3.2.2-stable_win64
OS/device including version: Win10 Pro + GeForce 840M/PCIe/SSE2 GLES3
Issue description:
When adding new scene the starting grid is showing wrong. When restarting the application, it works back again.
Steps to reproduce: Not sure
Minimal reproduction project:
Godot101_IntroTo3D(KidzCanCode).zip
Screenshot:

It looks correct in the screenshot you posted, I don't see the issue.
Regardless, the grid has been overhauled for Godot 4.0, so any bugs with the grid likely don't exist anymore.


MAINT: version bounds 1.9.0rc1

I never get this quite right, but here is the
first draft of the version bounds for 1.9.0rc1,
which is probably even more complicated with some
of the meson stuff until I'm used to that

for reference, last branching we did this:
gh-15191

I think if NumPy releases before us we can, in theory,
squeeze another +1 version if we're careful to address
warnings (I think we actually ignored some though..)

Can you explain the rationale behind an upper bound on Python? Presumably, people should be able to build on whichever version of Python they like.
I'm still -1 on NumPy pinning, and would prefer a helpful warning. But I know the SciPy team has already converged on this as an acceptable practice.

Maybe deprecations in the Python language itself? Not trying to defend it aggressively, but I suppose that eventually the probability of a successful build from source drops as the versions/years go by?

I suspect that those deprecations are quite rare, and if users run into them we can simply fix them (this is during the build process, after all).

I wonder if we'd feel compelled to release new source distributions in that event, which then means we need to rebuild new binary wheels for PyPI with a much newer version of Python than the old release? Which then might mean a new pip which has new rules or something? I dunno, I don't feel too strongly about it, but just kind of imagining what could go wrong given what tends to go wrong even for "normal" releases.
If minor shims for developers are fair game though, can't you just delete the version bounds in the source if a little bit of hacking is reasonable anyway?
I guess this way we get "insurance" against maintenance complaints (i.e., this is our policy, hack as you see fit if you want support beyond it).

Does this pin prevent future versions of Python from attempting to build the source package? If so, I suppose it makes some sense, since as you say devs can still apply a small patch.

Does this pin prevent future versions of Python from attempting to build the source package?

I tried (python -m pip install -v ., which now goes through meson) locally in a Python 3.10 venv with:
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -61,7 +61,7 @@ maintainers = [
 # Note: Python and NumPy upper version bounds should be set correctly in
 # release branches, see:
 #     https://scipy.github.io/devdocs/dev/core-dev/index.html#version-ranges-for-numpy-and-other-dependencies
-requires-python = ">=3.8,<3.11"
+requires-python = "<3.10"
 dependencies = [

And what happened was the entire source was built successfully, and then at the very last step, you see:
ERROR: Package 'scipy' requires a different Python: 3.10.4 not in '<3.10'
and nothing gets installed in site packages, etc. So, I suppose the answer is a (very annoyingly implemented) yes. At least the build is way faster so it is not like waiting 8-10 minutes as it used to be.
That said, this PR can't fly at the moment with the version pin because of the failure in CI, which I can also reproduce locally (see below the fold)--apparently the pep621 PyPI package can't parse the '>=3.8,<3.11', which we could parse before switching build backends. I suspect that's a bug rather than an ecosystem statement on upper version bounds, though I could be wrong cc @FFY00.

  Running command Getting requirements to build wheel
  Traceback (most recent call last):
    File "/home/treddy/python_virtual_envs/python_310_venv_scipy_general/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 363, in <module>
      main()
    File "/home/treddy/python_virtual_envs/python_310_venv_scipy_general/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 345, in main
      json_out['return_val'] = hook(**hook_input['kwargs'])
    File "/home/treddy/python_virtual_envs/python_310_venv_scipy_general/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 130, in get_requires_for_build_wheel
      return hook(config_settings)
    File "/tmp/pip-build-env-5seiz966/overlay/lib/python3.10/site-packages/mesonpy/__init__.py", line 805, in get_requires_for_build_wheel
      with _project(config_settings) as project:
    File "/usr/lib/python3.10/contextlib.py", line 135, in __enter__
      return next(self.gen)
    File "/tmp/pip-build-env-5seiz966/overlay/lib/python3.10/site-packages/mesonpy/__init__.py", line 784, in _project
      with Project.with_temp_working_dir(
    File "/usr/lib/python3.10/contextlib.py", line 135, in __enter__
      return next(self.gen)
    File "/tmp/pip-build-env-5seiz966/overlay/lib/python3.10/site-packages/mesonpy/__init__.py", line 479, in with_temp_working_dir
      yield cls(source_dir, tmpdir, build_dir)
    File "/tmp/pip-build-env-5seiz966/overlay/lib/python3.10/site-packages/mesonpy/__init__.py", line 380, in __init__
      self._metadata = pep621.StandardMetadata.from_pyproject(self._config, self._source_dir)
    File "/tmp/pip-build-env-5seiz966/overlay/lib/python3.10/site-packages/pep621.py", line 227, in from_pyproject
      packaging.specifiers.Specifier(requires_python_string) if requires_python_string else None,
    File "/tmp/pip-build-env-5seiz966/overlay/lib/python3.10/site-packages/packaging/specifiers.py", line 98, in __init__
      raise InvalidSpecifier(f"Invalid specifier: '{spec}'")
  packaging.specifiers.InvalidSpecifier: Invalid specifier: '>=3.8,<3.11'
  error: subprocess-exited-with-error

  × Getting requirements to build wheel did not run successfully.
  │ exit code: 1
  ╰─> See above for output.

  note: This error originates from a subprocess, and is likely not a problem with pip.
  full command: /home/treddy/python_virtual_envs/python_310_venv_scipy_general/bin/python /home/treddy/python_virtual_envs/python_310_venv_scipy_general/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py get_requires_for_build_wheel /tmp/tmp7huy0k7n
  cwd: /home/treddy/github_projects/scipy
  Getting requirements to build wheel ... error
error: subprocess-exited-with-error

× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.
(python_310_venv_scipy_general) treddy@adobe:~/github_projects/scipy$

That is likely a bug, I need to look better into the standards though.
Regarding it erroring out at the last step. It seems the wheel is successfully built but the metadata says it is not compatible with Python 3.10. We could verify if the interpreter being used for the build is compatible with the specified requires-python field preemptively, as I probably no valid use case would require the backend to succeed in such case.

That is likely a bug, I need to look better into the standards though.

The standard says nothing, and there's a long and inconclusive thread on Discourse. SciPy 1.7.x and 1.8.x do it like this already, and both setuptools and pip install upper bounds just fine.
There's folks who would like to not have upper bounds, and advocate instead for raising an exception in setup.py dynamically at build time. This is clearly a little strange (remove metadata to attempt a build that you know for certain will raise an exception), but there's complicated reasons for and against.

suspect those deprecations are quite rare,

This is not true, we have fixes for changes in new Python versions in every release of both NumPy and SciPy. if you don't believe me, just try to take a recent 1.X.0 release and try to build it with a version of Python that was released more than a year after that particular minor release. I'm not sure if your chance of success is zero or non-zero, but I am sure that it is very low.

and if users run into them we can simply fix them (this is during the build process, after all).

Wanting an obscure error halfway through the build rather than a "this is not supported" message right at the start is just a poor choice. Users would be much better served by getting an informative error saying "this Python is too new, please use the main branch or a newer version of SciPy".
At this point I am deciding to stop caring, because there's better ways to spend my time than to re-litigate this yet again. So I'll unsubscribe from this thread.

Users would be much better served by getting an informative error saying "this Python is too new, please use the main branch or a newer version of SciPy".

I see now that this patch is only applied on the 1.9.x branch, and that the main branch does not have similar pinning—so, that seems fine (as long as users always can always try to build the latest source on latest Python).

Thanks for taking the time to think through the Python version pinning with me. After further consideration, I get why the Python pin makes sense, specifically because it affects source builds of a release branch only. The built wheels are already tied to a Python version, and the pin does not preclude anything that isn't otherwise possible (other than trying to build an old SciPy on a newer Python). The latest source build is the sensible place to support new Pythons.
I'm sorry that the conversation frustrated you @rgommers. We're all tuning in to a lot of things simultaneously, so sometimes a reminder of why we do things the way we do is helpful.

The standard says nothing, and there's a long and inconclusive thread on Discourse. SciPy 1.7.x and 1.8.x do it like this already, and both setuptools and pip install upper bounds just fine.

I had a look and this field is a pep 440 version specifier, which allows multiple comma separated clauses, including upper bounds. The issue seems to be a bug in pep621 or packaging that does not allow a list.
I am not sure if we are talking about the same thing here. Did I miss something?

I think I've addressed the reviewer comments in my latest commit, however at least locally I get a different type of error when trying to build on Linux in a Python 3.9 venv now:
python -m pip install -v .
  Traceback (most recent call last):
    File "/home/tyler/python_3_9_12_scipy_general/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 363, in <module>
      main()
    File "/home/tyler/python_3_9_12_scipy_general/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 345, in main
      json_out['return_val'] = hook(**hook_input['kwargs'])
    File "/home/tyler/python_3_9_12_scipy_general/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 130, in get_requires_for_build_wheel
      return hook(config_settings)
    File "/tmp/pip-build-env-_ecfq9dy/overlay/lib/python3.9/site-packages/mesonpy/__init__.py", line 805, in get_requires_for_build_wheel
      with _project(config_settings) as project:
    File "/home/tyler/github_projects/spack/opt/spack/linux-ubuntu22.04-skylake_avx512/gcc-11.2.0/python-3.9.12-osore4bvxpxd66nnaw6pvjrmkf7csyia/lib/python3.9/contextlib.py", line 119, in __enter__
      return next(self.gen)
    File "/tmp/pip-build-env-_ecfq9dy/overlay/lib/python3.9/site-packages/mesonpy/__init__.py", line 784, in _project
      with Project.with_temp_working_dir(
    File "/home/tyler/github_projects/spack/opt/spack/linux-ubuntu22.04-skylake_avx512/gcc-11.2.0/python-3.9.12-osore4bvxpxd66nnaw6pvjrmkf7csyia/lib/python3.9/contextlib.py", line 119, in __enter__
      return next(self.gen)
    File "/tmp/pip-build-env-_ecfq9dy/overlay/lib/python3.9/site-packages/mesonpy/__init__.py", line 479, in with_temp_working_dir
      yield cls(source_dir, tmpdir, build_dir)
    File "/tmp/pip-build-env-_ecfq9dy/overlay/lib/python3.9/site-packages/mesonpy/__init__.py", line 430, in __init__
      self._metadata.dynamic.remove('version')
  ValueError: list.remove(x): x not in list
  error: subprocess-exited-with-error

  × Getting requirements to build wheel did not run successfully.
  │ exit code: 1
  ╰─> See above for output.

  note: This error originates from a subprocess, and is likely not a problem with pip.
  full command: /home/tyler/python_3_9_12_scipy_general/bin/python /home/tyler/python_3_9_12_scipy_general/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py get_requires_for_build_wheel /tmp/tmpotyqonyz
  cwd: /home/tyler/github_projects/scipy
  Getting requirements to build wheel ... error
error: subprocess-exited-with-error

× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

yeah, CI agrees with me here it seems, @FFY00 thoughts?

My initial testing suggests we'll be in better shape when https://github.com/FFY00/meson-python/pull/77 gets merged. I think one source of confusion for me was that the pep621 update on its own made things look even worse, but when combined with the latest meson-python looks solid with this feature branch as well.

[...] the pep621 update [...]

On that topic, pep621 is now called pyproject-metadata, see https://github.com/FFY00/python-pyproject-metadata/issues/10

Ok, the release history shows pep621 active as of two days ago: https://pypi.org/project/pep621/#history
I can't keep track of it all perfectly, just hoping the pieces are in place to do an rc soon.

Ok, the release history shows pep621 active as of two days ago

True, but 0.4.0.post2 is still < 0.5.0. ;-)

I can't keep track of it all perfectly, just hoping the pieces are in place to do an rc soon.

🤞

Yeah, pep621 was renamed to pyproject-metadata, meson-python 0.6.0 will have the updated dependency.

With the release of meson-python 0.6.0 I've locally confirmed that the issues above seem to be resolved on this branch locally.
I rebased/resolved merged conflicts and pushed in--hopefully the CI agrees.


Provide base classes that do not extend from support library

It would be a nice enhancement to provide alternative classes that do not use support library.

Give an example.  You have to extend from AppCompatActivity to get a
Toolbar nowadays....
On Apr 29, 2015 1:01 PM, "fmnstr"<EMAIL_ADDRESS>wrote:

It would be a nice enhancement to provide alternative classes that do not
use support library.
—
Reply to this email directly or view it on GitHub
https://github.com/sockeqwe/mosby/issues/22.

There is already some kind of Delegate you can use to bring the functionality and workflow of MVP and ViewState to other components. I will rename that delegate in Version 1.1 to make it more easier to plugin to your custom base activity, fragment or view class.
See #14


Update detekt to 1.20.0-RC1

Codecov Report

Merging #230 (6f9ebea) into main (d2e045f) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #230   +/-   ##
=======================================
  Coverage   73.44%   73.45%
=======================================
  Files          66       66
  Lines        2975     2976    +1
  Branches      477      477
=======================================
+ Hits         2185     2186    +1
  Misses        523      523
  Partials      267      267

Impacted Files
Coverage Δ

...xvanyo/composelife/model/CellStateSerialization.kt
89.70% <ø> (ø)

...alexvanyo/composelife/navigation/BackstackState.kt
93.10% <ø> (ø)

...navigation/MutableBackstackNavigationController.kt
100.00% <ø> (ø)

...anyo/composelife/ui/action/ActionCardNavigation.kt
55.17% <ø> (ø)

...mposelife/ui/action/CellUniverseActionCardState.kt
25.86% <ø> (ø)

...xvanyo/composelife/ui/info/CellUniverseInfoCard.kt
79.58% <ø> (ø)

.../alexvanyo/composelife/ui/cells/CellWindowState.kt
76.08% <100.00%> (+0.53%)
:arrow_up:

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Core SEACrowd patch on VEnv Initialization

Reason:
I was trying to follow the steps on creating the venv for this repo (using conda version: 23.5.2) however I encountered some issues when executing conda env create -f conda.yml. It's caused by several requirements conflicting each other for the following points

pandas==1.3.3 throws an error on subprocess with following message:

  error: subprocess-exited-with-error

  × Getting requirements to build wheel did not run successfully.
  │ exit code: 1
  ╰─> [17 lines of output]
....
        File "<string>", line 18, in <module>
      ModuleNotFoundError: No module named 'numpy'
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

failed

CondaEnvException: Pip failed

torchaudio==0.11 isn't compatible with python >= 3.11, only can be installed with at max python~=3.10.0, with following message:

Pip subprocess error:
ERROR: Ignored the following yanked versions: 2.0.0
ERROR: Ignored the following versions that require a different python version: 1.21.2 Requires-Python >=3.7,<3.11; 1.21.3 Requires-Python >=3.7,<3.11; 1.21.4 Requires-Python >=3.7,<3.11; 1.21.5 Requires-Python >=3.7,<3.11; 1.21.6 Requires-Python >=3.7,<3.11
ERROR: Could not find a version that satisfies the requirement torchaudio==0.11 (from versions: 2.0.1, 2.0.2, 2.1.0)
ERROR: No matching distribution found for torchaudio==0.11

failed

CondaEnvException: Pip failed

Sorry, this PR was contaminated by another PR. Closing this first and re-create it later.


Throw exception instead of returning true

Some themes doesn’t have a config (yet) so we don’t want to throw a error if there isn’t any

I don't agree with you. Themes should be updated anyway, because of new functionality in newer versions


Can't call with apps

Hi!
I was wondering if I've missing something as the options to call from Skype are blocked and on Whatsapp don't even appear.
Thank you in advance!

Hi,
web versions of those applications don't have such options. That's why they are invisible or disable

Oh! I wasn't aware! Thank you for the quick response 😃


Type errors with Wagmi as of version 0.6.0

Am unable to use the ledger live wagmi connector with wagmi as of wagmi version 0.6.0.
Current version of wagmi is 0.8.7
I have added IFrameEthereumConnector as per the example.
import { IFrameEthereumConnector } from '@ledgerhq/ledger-live-wagmi-connector';

export const client = createClient({
  autoConnect: true,
  connectors: [
    new MetaMaskConnector({ chains }),
    new IFrameEthereumConnector({ chains, options: {} }),
  ],
  provider,
});

However I see various type errors including:

Type 'IFrameEthereumConnector' is not assignable to type 'Connector<any, any, any>'.
Types of property 'chains' are incompatible.

Hey @geositta, thanks for your feedback! 🙌
Indeed the dependency of wagmi used by our connector is currently set to ^0.5.5, we might need to update this dependance to make the connector compatible with newer versions of the lib that might have brought breaking changes.
I took a quick look at it and was able to make our smoke test pass with wagmi dependency up to ^0.7.0.
We will need to take a deeper look at this. Could you share a minimal reproductible example / project where you are encountering this error so that we can properly investigate?
Many thanks

Hey @geositta, thanks for your feedback! 🙌
Thanks for your response @chabroA. I made a create wagmi project where you should be able to see the type error locally.
https://github.com/geositta/wagmi-vite-react

There appears to be a completely separate issue when running npm run dev
Failed to resolve entry for package "@ledgerhq/iframe-provider"

Hey @geositta,
The connector library has been updated and the latest version 0.2.0 includes, among other things, an update of the wagmi dependency that should solve your issue 👍

@chabroA thank you, however I am still seeing type errors for the IFrameEthereumConnector:
const ledgerConnector: IFrameEthereumConnector
Type 'IFrameEthereumConnector' is not assignable to type 'Connector<any, any, any>'.

Property 'onAccountsChanged' is protected but type 'IFrameEthereumConnector' is not a class derived from 'Connector<Provider, Options, Signer>'.

@chabroA also a second issue that I am able to recreate in two different repos is a problem with how ethers/lib/utils is imported.
https://github.com/geositta/wagmi-ledger-live
Compiled with problems:

ERROR in<EMAIL_ADDRESS>3:0-56

Module not found: Error: Can't resolve 'ethers/lib/utils' in '/wagmi-ledger-live/node_modules/@ledgerhq/ledger-live-wagmi-connector/lib'
Did you mean 'utils.js'?
BREAKING CHANGE: The request 'ethers/lib/utils' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

@chabroA also a second issue that I am able to recreate in two different repos is a problem with how ethers/lib/utils is imported. https://github.com/geositta/wagmi-ledger-live
Compiled with problems:

ERROR in<EMAIL_ADDRESS>3:0-56

Module not found: Error: Can't resolve 'ethers/lib/utils' in '/wagmi-ledger-live/node_modules/@ledgerhq/ledger-live-wagmi-connector/lib'
Did you mean 'utils.js'?
BREAKING CHANGE: The request 'ethers/lib/utils' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

@chabroA this is still an issue it looks like with 0.4.0 on ethers 5.7.2.


dependencies

This is an excellent repository. But I failed to reproduce the script. Can you provide a more detailed requirements.txt accompanying dependency versions?

Thanks for your comment, @zzl2022. Can you please be more specific? Which part are you not able to reproduce?

Dear Dr. Gollini,
Greetings for the day!
Thank you for your letter.
You can download the attachment to view my confusion about your repository.
It would be very grateful if you could help me.  I look forward to hear from you soon!
Best Regards,
Zhilei Zhao
Beijing Institute of Technology
Beijing China
At 2023-03-30 02:27:59, "Gollini" @.***> wrote:
Thanks for your comment, @zzl2022. Can you please be more specific? Which part are you not able to reproduce?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

Dear @zzl2022,
Maybe there was a mistake on my side, but I can't find the attachment.
If you can please send it again, I will be more than glad to help you.

Dear @zzl2022,
I have updated the requirements.txt with the dependencies versions when building this repository.
Please let me know if the problem continues. The repository was built five months ago, so maybe an update from my side is required.

Dear @zzl2022, Maybe there was a mistake on my side, but I can't find the attachment. If you can please send it again, I will be more than glad to help you.

Dear Dr. Gollini,
Thank you for your patient reply!
I have uploaded the attachment again.
Issues about the public Github repository.docx
Thank you for your willingness to help me.


Reconfigure to use Ruff for linting and formatting

This PR swaps calling the reusable flake8 workflow for the new reusable ruff workflow. Also adds new ruff configuration options to the pyproject.toml.
Still deciding whether or not to reformat the entire repository within this PR.

Trufflehog is failing because of a commit hash in a comment linking to a MintPy PR. Safe to ignore.


[bug] Random Chinese & Japanese characters in AI summaries

describe the bug
brief description of the bug.
When I try and use AI features, there're often random CH/JP characters
system info

os: macOS 15.0.1
screenpipe version: Version 0.18.0 (20241216.221903)

additional context

you can find logs in ~/.screenpipe on macOS/Linux, and %APPDATA%\.screenpipe on Windows.
you can get app logs by right clicking in the app background and clicking the console tab.

send an issue to apple - this is their OCR

this is apple OCR
maybe try to force english language

Force English language is done by going to Screenpipe settings --> recordings --> dropdown menu under "languages" right?

yes


Fix: SPInfoPathFormsServiceConfig - MaxSizeOfUserFormState parameter could never be set

This PR fixes a bug for setting the "MaxSizeOfUserFormState" for InfoPath Forms Services. If you've tried to set this parameter it was always throwing an error and the default value was (still) used.
The assignment was basically "current value = (current value * 1024)" before.
Not sure if someone could change the test too (not familiar with testing these things, sorry).
The test uses the default value of this service application. So even if the value wasn't changed with the Set method - the tests could never reveal that because of the default value that's tested against.

[x] Change details added to Unreleased section of changelog.md?
[ ] Added/updated documentation and descriptions in .schema.mof files where appropriate?
[ ] Examples updated for both the single server and small farm templates in the examples folder?
[x] New/changed code adheres to Style Guidelines?
[ ] Unit and Integration tests created/updated where possible?

This change is

@cvollmann Thanks for catching that. The test does not require any modification. I'll review this PR once AppVeyor finishes. Cheers

Codecov Report

Merging #836 into dev will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##             dev    #836   +/-   ##
=====================================
  Coverage     91%     91%
=====================================
  Files        111     111
  Lines      10812   10812
  Branches       1       1
=====================================
  Hits        9939    9939
  Misses       872     872
  Partials       1       1

Merging this PR since the requested change has been applied.


Update asp.net runtime image

Upgrade to .net 9
Fixes #2931

Cherry-picked into private repo copy; which should undergo CI there; and then land here. It is cherrypick with your authorship attribution...... but I'm not sure if the robot keeps that.

This got merged in private repo; and should make its way here shortly. Thank you for your contribution!


Make all types available to library consumers.

Hi, this library is great!  Really takes out a lot of the legwork when setting up an itunes client.
I noticed quite a few of the types aren't made available to consumers.  This PR gives library consumers access to all types.

I didn't set up the the exports correctly from the dist


Bluetooth: GATT: Fix taking address of packed member of struct sc_data.

Fix GCC9 warning "warning: taking address of packed member of
'struct sc_data' may result in an unaligned pointer value"
Issue is that the on-air structure of sc_data was re-used for the gatt
service changed data.
Added build assert because data is stored in settings, so the structure
should be the same size to be compatible.
Signed-off-by: Joakim Andersson<EMAIL_ADDRESS>

CC: @thomasstenersen

We couldn't use UNALIGNED_GET?

We couldn't use UNALIGNED_GET?

Maybe. I don't see the reason to use a packed struct to store this data though. So I think this is the correct fix, as long as it is compatible with existing stored sc setting.

I recall it being used to store data in over the air byte format, on Linux there are types to represent different bytes order storage but we don't have that on zephyr so for now we have being using packed to indicate it may be a different byteorder.

I recall it being used to store data in over the air byte format, on Linux there are types to represent different bytes order storage but we don't have that on zephyr so for now we have being using packed to indicate it may be a different byteorder.

Right. This is after the byte-order has been fixed, which is why I don't think the packed struct should be used anymore.
notify_cb:
				struct sc_data *sc;

				sc = (struct sc_data *)data->ind_params->data;
				sc_save(cfg->id, &cfg->peer,
					sys_le16_to_cpu(sc->start),
					sys_le16_to_cpu(sc->end));

sc_save:
	if (!(cfg->data.start || cfg->data.end)) {
		cfg->data.start = start;
		cfg->data.end = end;
		modified = true;
		goto done;
	}


chore: update google-cloud-datastore from 2.2.9 to 2.3.0

Updates com.google.cloud:google-cloud-datastore from 2.2.9 to 2.3.0.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.google.cloud", artifactId = "google-cloud-datastore" } ]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #147.


Missing docs for Microsoft.Web

Please could App Service team contribute documentation for Microsoft.Web metrics. Looks like most other providers have.
I'm interested in 'Connections' (AppConnections) and whether it relates to inbound connections maintained by the load balancer, outbound connections made by the app, ... ?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: a0a586c4-71fd-e60b-9c4c-1a3eb2443c74
Version Independent ID: 2f3706cc-073b-a310-8da4-2a5a90da6473
Content: Azure Monitor supported metrics by resource type - Azure Monitor
Content Source: articles/azure-monitor/platform/metrics-supported.md
Service: azure-monitor
Sub-service: metrics
GitHub Login: @anirudhcavale
Microsoft Alias: ancav

@ishepherd Thank you for your feedback, we will direct the feedback to concerned team to take it forward.

@ishepherd Thank you for your query. Microsoft.Web/sites (excluding functions) should cover the App Service related Metrics.
Definition for Connections with in App Service has been documented as below, for additional details please refer here.
The number of bound sockets existing in the sandbox (w3wp.exe and its child processes). A bound socket is created by calling bind()/connect() APIs and remains until said socket is closed with CloseHandle()/closesocket().
Highlighted should refer to the App services connections metric you are looking for,

Hope this information helps. Please feel free to revert back if you have any further queries. Thank you

@BharathNimmala-MSFT Ok so it sounds like the figure covers both inbound and outbound connections, across all the individual worker app(s) that are running our code.
Thanks for the thorough response!

@ishepherd Glad to hear that the information helped. At this point it appears that there's no further edits or updates needed to the documentation. We will go ahead and close this issue, however if you have any further queries please tag us in your reply and will be happy to reopen the thread and continue the conversation. Thank you


log_prob - allow only constrained or unconstrained inputs; allow multiple constrained inputs

Summary:

Revise the log_prob implementation to allow only constrained or only unconstrained params, in accord with the documentation

Allow multiple constrained parameter inputs in the form of a CSV file, similar to standalone_gqs

Description:
The log_prob method exposes a Stan model's  log_prob function which takes as an input the vector of parameter values on the unconstrained scale and returns the gradients.
Desiderata

To amortize the cost of instantiating the model, the log_prob method should be able to accept an array of parameter vectors and then call the model's log_prob method on each.

Depending on the use case, the input parameters may be available on the constrained or unconstrained scale.

Current implementation

Constrained parameters are specified as a JSON object with entries for all parameters in the model, structured accordingly.  Because the input file can only contain one JSON object, the current implementation doesn't admit of getting radients for more than one set of parameters on the constrained scale.

The documentation states that the user can only specify one or the other.

The code, as written, allows for inputs in the form of a file of one or more sets of parameters on the unconstrained scale and/or a file of a single set of parameter values on the constrained scale.    If both are present, the logic will first computes the gradients for all unconstrained parameter sets, then compute the gradients for the constrained parameter set.  This means that the last row of the output corresponds to the constrained parameters, if constrained parameter input file is present.

https://github.com/stan-dev/cmdstan/blob/6bfcc1cd7315d11a90bfa2c09a6a8e2e5a4fd282/src/test/interface/log_prob_test.cpp#L42-L54
Reproducible Steps:
Changed CmdStan code to check for this; unit tests fail.
.
Current Version:
v2.31.0

checking the header - all other methods output lp__ - two underscores - log_prob CSV output has only one - lp_.
technically OK,  but inconsistent.


DIrector::is_cli() doesn't ever return true for cgi-fcgi

Affected Version
All of them m8
Description
Director::is_cli() relies on php_sapi_name() which doesn't return true when running in cgi-fcgi
Steps to Reproduce
I am running PHP in a certain configuration cgi-fcgi
When I run /vendor/bin/sake dev and I have code that calls Director::is_cli() it doesn't return  true.
Possible fix
As a fallback (possibly whitelisted for cgi-fcgi result) we can use the following code to soft-detect CLI.
$isCLI = stripos($_SERVER['SCRIPT_NAME'], 'clip-script.php') !== false;

Alternative fix:
Ditch php_sapi_name() entirely, and rely exclusively on $_SERVER variable.

Note: raised from slack convo at https://silverstripe-users.slack.com/archives/C0QSDASKT/p1619041534288500

That seems a little odd - cgi-fcgi is specifically mentioned on https://www.php.net/manual/en/function.php-sapi-name.php
@tractorcow could you try the PHP constant PHP_SAPI instead and see if that's also returning a falsey value?  I'm not sure if there's a difference between the function and the constant.

@tractorcow , Were you executing PHP using php-cli? Or were you using the CGI binary instead?
(NOTE: CLI is different from CGI).

Whenever something depends on the type of interface, make sure your check is conclusive. Especially when you want to distinguish the command line interface (CLI) from the common gateway interface (CGI).
Note, that the php-cgi binary can be called from the command line, from a shell script or as a cron job as well! If so, the php_sapi_name() will always return the same value (i.e. "cgi-fcgi") instead of "cli" which you could expect.
Bad things happen to good people. Do not always expect /usr/bin/php to be a link to php-cli binary.

Framework only checks for CLI usage (does not allow for CGI binary execution to be assumed as CLI). Instead it assumes that CGI execution has been passed through by the web-server.
If this is the case, then isCLI returning false for executions via CGI make sense as its not being executed via the CLI binary.


Fix issue #279 (bug with Safari)

Calling any method defined on String.prototype on the expanded term
forces the string to be properly represented, fixing an issue affecting
Safari users.
See https://github.com/olivernn/lunr.js/issues/279

See the discussion on https://github.com/olivernn/lunr.js/pull/359
I think that this fix would be less invasive, as it's very inexpensive for performance, and does not change the expanded term (other than forcing the correct string representation).
As for the underlying causes of this issue, it does not seem to be related to unicode, but more to some low-level detail of the string representation. It would be worth looking deeper into lunr.TokenSet to find exactly where the string gets corrupted.

Repeating here my comment on the issue, for documentation:
I think I managed to pinpoint the exact place in lunr.TokenSet where the string gets sometimes corrupted in Safari:
https://jsfiddle.net/egLzL24L/77/ (see line 38 and relevant comment)
Which corresponds to this line in the repo: https://github.com/olivernn/lunr.js/blob/f9aeea2c592dc08eec67937bcb5b34903e6c04dc/lib/token_set.js#L309
It seems that the string concatenation (no matter if done with .concat or with +) results in the corruption, which is fixed by calling any String.prototype method on the string. The two strings that get concatenated look fine, only the result is corrupted.
As of why this happens, and what exactly triggers it, I have no clue. I would be inclined to think that some underlying memory optimization of string concatenation is buggy in Safari in some corner case.

Again, thanks for doing a deep investigation on this, great work!
I'm happy to put together a release with this workaround to unblock people who are being caught by this issue, just a couple of things:

Remove the changes to lunr.js, i.e. just commit the changes to lib/token_store.js
Is there a test that we can specifically for this?

I've squashed and merged these changes now.
As a general rule tests are normally great. Having some specifically for safari would be good, though not essential to get this merged. Its unlikely that I will remember to run them in a browser, plus currently there is no browser tests running on travis.
I'm going to start work on improving unicode support within lunr, as such I will introduce a bunch of tests with documents containing non-ascii characters. In my mind this work should allow us to revert this change.
Another lesson from this is to get browser based tests running as part of the build. Browser bugs, though rare, do exist and can cause a lot of disruption.


Add email

dev
JIRA

Main JIRA ticket

Code reviewers

[ ] @github_username

Second Level Review

[ ] @github_username

Summary of issue
ToDo
Summary of change
ToDo
Testing approach
ToDo
CHECK LIST

[ ]  СI passed
[ ]  Сode coverage >=95%
[ ]  PR is reviewed manually again (to make sure you have 100% ready code)
[ ]  All reviewers agreed to merge the PR
[ ]  I've checked new feature as logged in and logged out user if needed
[ ]  PR meets all conventions

You forgot about the "formatting" commit.
It must be the last one in history.


request feature of Resume Upload, with WriterAt interface (or request documentation)

from https://godoc.org/cloud.google.com/go/storage I'm doing uploading by this NewWriter interface
w := obj.NewWriter(ctx)
// Write some text to obj. This will overwrite whatever is there.
// ...
if n, err := io.Copy(w, r); err != nil {
    // TODO: Handle error.
}

but I met some cases the returned err is nil but n is not the same size of input r; since my input r is seekable, I seek it to offset 0; and call obj.NewWriter to get another writer, retry io.Copy for the whole buffer, this is to copy the whole thing since beginning
I found io.WriterAt interface https://golang.org/src/io/io.go?s=8275:8351#L220 wonder if obj Writer has that?
I'm not seeing in the source code https://github.com/GoogleCloudPlatform/google-cloud-go/blob/master/storage/writer.go ; or if you do, this can also be a documentation request please have examples how to retry if the first io.Copy is a partial success

https://cloud.google.com/storage/docs/json_api/v1/how-tos/resumable-upload#example_uploading_the_file
is the resumable upload in multiple chunks implemented? the WriterAt interface looks like a good mapping to the Content-Range request; some times my upload file could be too big, I would like to do upload in multiple chunks
PUT https://www.googleapis.com/upload/storage/v1/b/myBucket/o?uploadType=resumable&upload_id=xa298sd_sdlkj2 HTTP/1.1
Content-Length: 524288
Content-Type: image/jpeg
Content-Range: bytes 0-524287/2000000

[BYTES 0-524287]

This file contains the resumable upload implementation: https://github.com/google/google-api-go-client/blob/master/gensupport/resumable.go.
We do call it from the Writer: https://github.com/GoogleCloudPlatform/google-cloud-go/blob/master/storage/writer.go#L84.
You can set Writer.ChunkSize to whatever value works for you before starting the write.

what I ask for is a starting offset, like the whole file size may be 2.5GB, and first io.Copy returned with 1.1GB, and then I should have a WriteAt interface to resume uploading the remaining 1.4GB, do you have example code how to do it?
the ChunkSize looks like to specify maximum transfer chunk size which is low level implementation and I do not care; as long as it can finish writing the whole 2.5GB file content,
    // ChunkSize controls the maximum number of bytes of the object that the
    // Writer will attempt to send to the server in a single request. Objects
    // smaller than the size will be sent in a single request, while larger
    // objects will be split over multiple requests. The size will be rounded up
    // to the nearest multiple of 256K. If zero, chunking will be disabled and
    // the object will be uploaded in a single request.
    //
    // ChunkSize will default to a reasonable value. Any custom configuration
    // must be done before the first Write call.
    ChunkSize int
    // contains filtered or unexported fields

this is a request of GCloud Storage objects to have a WriterAt interface, to allow overwrite from any particular offset
https://golang.org/pkg/io/#WriterAt

OK, I now understand what you're asking for. Will add this to my queue.

I met some cases the returned err is nil but n is not the same size of input r

Did you see if w.Close() returned an error? I think it would have in this case. If we don't upload your whole file, we should not succeed.

What you're proposing is retrying the resumable upload at a higher level. But we already have retry logic built in to the upload (see the link in my April 6 comment). Instead of adding another layer of retry, we should understand why your upload is failing, and improve the existing logic to handle your case.
So can you provide more information about the errors you are seeing? (As I said above, if you're not seeing an error, even from Writer.Close, then we have a different bug.)

2017/06/01 21:43:09 unable to close gcs file "gs://ox-perf-data/path/to/.../20170602/044200.1496378520.1496378580.avro":
googleapi: Error 503: Backend Error, backendError &googleapi.Error{Code:503, Message:"Backend Error", Body:

{
 "error": {
  "errors": [
   {
    "domain": "global",
    "reason": "backendError",
    "message": "Backend Error"
   }
  ],
  "code": 503,
  "message": "Backend Error"
 }
}

sorry that was only the last error, but the system indeed has some partially written some times
n, err := io.Copy(gcsFile, buf)
// at this time err is nil but  n != buf.Len()

Error 503

This shouldn't happen:
func shouldRetry(status int, err error) bool {
	if 500 <= status && status <= 599 {
		return true
	}
...

(from https://github.com/google/google-api-go-client/blob/master/gensupport/retry.go#L71).
I'll try to understand better tomorrow.

n, err := io.Copy(gcsFile, buf)
// at this time err is nil but  n != buf.Len()

I'll look into this too.

One thing I forgot to ask: are you using the most recent version of the client? If not, what commit are you pinned to?

#596

OK, I think I got it. https://code-review.googlesource.com/13657
For the curious: the shouldRetry logic quoted above applies to the upload itself, but not the initial POST that gets the URI for the upload. My theory is that that initial call was failing.
Coincidentally, this just happened in a recent Travis run.


New docs engine

Based on feedback from some of our users and (even) developers, we will try to build stand-alone documentation hosting.
We need opinions on:

Should the docs be replicated to github wiki? If convenient documentation solution is chosen and implemented, should we even care about github wiki?
What features would our users like to see on documentation site, apart from being able to read documentation in convenient fashion, obviously :)

Motivation:

@lagovas has put a lot of effort into producing awesome tutorials, which do not fit neither our blog nor github structure.
upon release of forthcoming products, keeping all documentation in one place might simplify cross-product usage - for example, acra users, who will want custom functionality from acra writer modules, will still need access to themis documentation, and if it's worth a few clicks instead of going to different site, it is going to save a lot of time, nerve and context switching

What would everyone say if we do it w/ Jekyll, which has plenty of themes that look like what we need:

https://github.com/CloudCannon/Aviator-Jekyll-Theme
https://github.com/tomjohnson1492/documentation-theme-jekyll

Adding block layout from designs like this

https://github.com/mmistakes/skinny-bones-jekyll

might make docs design more sophisticated and interesting.

On the other hand, we have plenty of people knowing Python and some people already did similar  things on Pelican (although we were not that happy with it).

Finally, we ended up needing a custom solution (docs management CMS of some kind), able to:

custom page templates
navigation pane with hierarchy
in-page navigation tree autogenerated
proper documentation search
markdown editing

Some good examples:

https://stripe.com/docs
https://www.librato.com/docs/api/ (language-specific pages!!)
http://docs.basho.com/

change history (with diffs)
reverting changes
interactive snippets

for history, one more example - https://tangerine-lemon.cloudvent.net/

@gene-eu releases from GH should be from all public repositories or only from themis (like on themis.cossacklabs.com)? the same question about commits/ci

custom list of reps

proposal 1: add a table of mapping words to pre-defined links like Secure Message to https://github.com/cossacklabs/themis/wiki/Secure-Message-cryptosystem and map them automatically during render MD to final output (via extended md syntax or something like that).
also, need to add an ability to decline mapping if some words appear in text many times or in some specific cases
proposal 2: add a table of named code snippets and extend md syntax where we could to reference via the name to these snippets that will be replaced by code blocks. it's should ease maintaining code snippets across texts

Awesome, do both

It really became a thing of it's own, planned and executed separately, closing this.


⚠ Bofrost.be has degraded performance

In 0e2f493, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1752 ms

Resolved: Bofrost.be performance has improved in 229079e.


correct type for readdir

Includes potential for readdir returning an Array<Buffer>, which happens when encoding is set to 'buffer'. https://nodejs.org/api/fs.html#fs_fs_readdir_path_options_callback

/cc @mroch


Include ResearchGate and Medium on config.yml

Description
Please include ResearchGate and Medium on config.yml

Environment

Minimal Mistakes version:
Ruby gem or remote theme version:
Jekyll version:
Git repository URL:
Operating system:
GitHub Pages hosted (if yes provide URL to site):

Expected behavior

Steps to reproduce the behavior

Closing as this is a duplicate of several other issues like #1676
Additional sidebar links can be added using /includes/author-profile-custom-links.html or creating your own layout overrides as per the docs.


drumkv1: 0.8.5 -> 0.8.6

Semi-automatic update. These checks were performed:

built on NixOS
found 0.8.6 with grep in /nix/store/k2mm58aav72xhc9kf5a8ysb6yxrbnj6c-drumkv1-0.8.6
found 0.8.6 in filename of file in /nix/store/k2mm58aav72xhc9kf5a8ysb6yxrbnj6c-drumkv1-0.8.6

@GrahamcOfBorg build drumkv1

Failure on x86_64-darwin (full log)
Partial log (click to expand)
Package ‘drumkv1-0.8.6’ in /Users/graham/nix-borg/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-ndnd/pkgs/applications/audio/drumkv1/default.nix:17 is not supported on ‘x86_64-darwin’, refusing to evaluate.

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowBroken = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowBroken = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Partial log (click to expand)
shrinking /nix/store/mx4326rxz1lk0aqd1690xlwwpisdygj9-drumkv1-0.8.6/lib/lv2/drumkv1.lv2/drumkv1.so
shrinking /nix/store/mx4326rxz1lk0aqd1690xlwwpisdygj9-drumkv1-0.8.6/lib/lv2/drumkv1.lv2/drumkv1_ui.so
shrinking /nix/store/mx4326rxz1lk0aqd1690xlwwpisdygj9-drumkv1-0.8.6/lib/libdrumkv1.so.0.8.6
gzipping man pages under /nix/store/mx4326rxz1lk0aqd1690xlwwpisdygj9-drumkv1-0.8.6/share/man/
strip is /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/mx4326rxz1lk0aqd1690xlwwpisdygj9-drumkv1-0.8.6/lib  /nix/store/mx4326rxz1lk0aqd1690xlwwpisdygj9-drumkv1-0.8.6/bin
patching script interpreter paths in /nix/store/mx4326rxz1lk0aqd1690xlwwpisdygj9-drumkv1-0.8.6
checking for references to /tmp/nix-build-drumkv1-0.8.6.drv-0 in /nix/store/mx4326rxz1lk0aqd1690xlwwpisdygj9-drumkv1-0.8.6...
postPatchMkspecs
/nix/store/mx4326rxz1lk0aqd1690xlwwpisdygj9-drumkv1-0.8.6

Success on aarch64-linux (full log)
Partial log (click to expand)
shrinking /nix/store/3bdjlsdrpimzycds80iknswqcknwa3lr-drumkv1-0.8.6/lib/lv2/drumkv1.lv2/drumkv1.so
shrinking /nix/store/3bdjlsdrpimzycds80iknswqcknwa3lr-drumkv1-0.8.6/lib/libdrumkv1_ui.so.0.8.6
shrinking /nix/store/3bdjlsdrpimzycds80iknswqcknwa3lr-drumkv1-0.8.6/lib/libdrumkv1.so.0.8.6
gzipping man pages under /nix/store/3bdjlsdrpimzycds80iknswqcknwa3lr-drumkv1-0.8.6/share/man/
strip is /nix/store/lvx1acn1ig1j2km8jds5x3ggh3f2wa8v-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/3bdjlsdrpimzycds80iknswqcknwa3lr-drumkv1-0.8.6/lib  /nix/store/3bdjlsdrpimzycds80iknswqcknwa3lr-drumkv1-0.8.6/bin
patching script interpreter paths in /nix/store/3bdjlsdrpimzycds80iknswqcknwa3lr-drumkv1-0.8.6
checking for references to /build in /nix/store/3bdjlsdrpimzycds80iknswqcknwa3lr-drumkv1-0.8.6...
postPatchMkspecs
/nix/store/3bdjlsdrpimzycds80iknswqcknwa3lr-drumkv1-0.8.6


Jesse: Watch sudge.org.tr

Jesse requests the watch of the watch_keyword sudge\.org\.tr. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

sudge\.org\.tr has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


python.pythonPath does not load in projects startup terminal

Environment data

VS Code version: 1.38.0
Extension version (available under the Extensions sidebar): 2019.9.34911
OS and version: windows 10 pro
Python version (& distribution if applicable, e.g. Anaconda): 3.7.4
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): venv
Relevant/affected Python packages and their versions: XXX
Jedi or Language Server? (i.e. what is "python.jediEnabled" set to; more info #3977): language server

Expected behaviour
If you save off you project with a terminal active, next time you start the project:
On initial load the terminal does not honor python.pythonPath
If I close the terminal and start a new on it does.
Actual behaviour
my python.pythonPath is not loaded when project is loaded
Steps to reproduce:
create a python venv in windows.
create a .vscode/settings.json with a single entry aka:
{
    "python.pythonPath": "C:\\venvs\\winapp-lra\\Scripts\\python.exe"
}

Hi @fenchu! Thank you for reporting this. When you say the python.pythonPath is not loaded, do you mean the virtual environment is not activated on the terminal that was first opened? If so, this is the current behavior, and then this issue would actually be a feature request. However, if you mean that the interpreter displayed in the status bar doesn't match the one in your settings.json file, then that's a bug and we'd need some more information to investigate what's going on.
Would you mind showing what is displayed on your status bar?

Dup of https://github.com/microsoft/vscode-python/issues/5330


music fixes and attempted memory optimization

ye

Zenith is gonna check this out in ~90 mins!

hey I'm so super sorry I just got home and I feel horrendously motion sick, I'll need a little extra time to recover before I can get to this

Love the options redo, as long as we can keep it under 9 its great!

i tried optimizing some memory with the other two commits and accidentally broke the music and sfx (i clearly can't do assembly language)

Skill issue 😝

Have you tried clearing your sram? Go to options and clear default settings (or clear your save file) it’s probably conflicting with old sram save data

oh you clobbered A here
.proc _music_play
ldx	_options
txa
and #$08
tax
beq	start
rts

Fix:
.proc _music_play
pha
ldx	_options
txa
and #$08
tax
beq	start
pla
rts
start:
pla

ah. i see
thank you

now you clobbered Y and all the sfx are the same xD
Fix:
.proc _sfx_play
tax
jsr popa
pha
tya
pha
ldy	_options
tya
and #$10
tay
bne end
pla
tay
pla
jmp famistudio_sfx_play
end:
pla
tay
pla
    rts

.endproc

:agony:

muchas gracias

wait lmao
invalid opcode moment

Edit: I forgot it sets the N flag not the C flag, so for music off it should be
bpl musicon
  rts
musicon:

alright that should do it

looks and sounds good, merging
apologies for the long wait, ended up passing out all evening and wasn't allowed on the pc (and then had school)


Problem with Gnome Shell dropdowns

Hi 👋🏻, thank you so much for your interest in providing this feedback. ✨
But there is a better place to share the same, which is the project repository, where you can talk to the theme maintainers.
✅ Clicking here, you can open an Issue on it.


Should we keep the same policy in one trajectory ?

The paper of impala say :

At the beginning of each trajectory, an actor updates its own local policy µ to the latest learner policy π and runs it for n steps in its environment.

does it means that we should keep the same policy in one trajectory.
I think the implementation here maybe update the policy at sampling that will cause different policy.
https://github.com/facebookresearch/torchbeast/blob/ddeec0174fe651649f27452fb684aa7745d3f00d/torchbeast/monobeast.py#L162

Hey Peter, thanks for your interest!
You're right, in both Polybeast and Monobeast we update the actor policy "hogwild", i.e., whenever a learning step has happened, including during a rollout. Think of it as an additional exploration feature :).
Also do feel free to change and play around with that logic in your copy of the codebase. Notice that to keep the policy fixed during a rollout generation, one would need to keep num_actors many copies of the model around, at least naively.
By the way, even the original Impala implementation does this hogwild update in its "single-machine" training setup, see the comment at https://github.com/deepmind/scalable_agent/blob/master/experiment.py#L507. In TorchBeast, our aim is to implement an Impala-like agent, not necessarily do 100% what the Impala paper said. That said, I don't believe updating the actor policy this way hurts training performance at all.


Fix Document is not defined error.

There was an issue where if you provided an empty string to useColor, it gave an document is not defined error (server side error only, basically a warning).

Pretty sure that doing just useColor() would also trigger this error.

Also. the toHex function can be changed to something like this (it doesn't exactly match the code style since it's from my recreation of the ColorService in hopes of fixing the error):
function toHex(value: string) {
    if (!value.startsWith("#")) value = "#" + value;

    if (value.length === 4 || value.length === 5) {
        value = value
            .split("")
            .map((v, i) => (i ? (i < 4 ? v + v : v === "f" ? undefined : v + v) : "#"))
            .join("");

        return value;
    } else if (value.length === 7) {
        return value;
    } else if (value.length === 9) {
        return value.endsWith("ff") ? value.slice(0, 7) : value;
    }

    return "#000000";
}

basically instead of creating a canvas which probably can also be less performant, we just add back the # if it's missing.

To add support for hex colors like 0xffffff (equal to #ffffff), just before the check if the color starts with #, add a check if it starts with 0x.

There was an issue where if you provided an empty string to useColor, it gave an document is not defined error (server side error only, basically a warning).

Checking for an empty string doesn't make much sense since it will return #000000 anyway if a valid HEX value isn't provided. The error you're encountering hasn't been reproduced on my end, which leads me to believe that the issue is likely on your side rather than with the library. Also, you shouldn't be running it in a server environment.

basically instead of creating a canvas which probably can also be less performant

Removing the canvas isn't the kind of change you'd want to make for "performance" reasons, as it facilitates the conversion of named colors, and string RGB, HSL, and HWB values into HEX, ensuring almost complete compatibility with CSS behavior.


Consensus: DIP-0020: Dash opcode updates - OP_CAT and OP_SPLIT.

This PR is intended as a partial implementation of https://github.com/dashpay/dips/blob/master/dip-0020.md
Enable and implement OP_CAT.
Rename OP_SUBSTR to OP_SPLIT and implement it.
Copied from https://reviews.bitcoinabc.org/D1097 mentioned in the document.
Idea is to receive feedback on this PR and if positive, proceed with the rest of the disabled opcodes.

Opcodes themselves look good but pls note that develop branch should be kept backwards compatible. You can't just (re)implement them like that, you need to use some activation mechanism (could re-use DEPLOYMENT_V17 (https://github.com/dashpay/dash/pull/3808) for this) and implement corresponding tests i.e. (at least) smth like https://github.com/Bitcoin-ABC/bitcoin-abc/commit/7ad4d7937bd8b7fddf9a799ed85fa1a1150fe200 + https://github.com/Bitcoin-ABC/bitcoin-abc/commit/f103591b993fef4359819bd1fb956f47e7b540e2.

@UdjinM6 Thanks for the quick reaction!
If you can, please confirm my understanding that the following should be done here:

Add DEPLOYMENT_DIP0020 to src/chainparams.cpp or just reuse DEPLOYMENT_V17.
Add a script verification flag (maybe ENABLE_DIP0020_OPDCODES) that enables these opcodes and is automatically enabled if the DEPLOYMENT_DIP0020 or DEPLOYMENT_V17 criteria is active.
Implement test that checks this flag is activated properly.
Also fix the script tests to accommodate the enable flag.

Correct. Also, pls rebase this PR on top of the latest develop to fix simplepose test failures.

Also, be aware of the timeline found here https://github.com/dashpay/dash/issues/3775, feature freeze on Dec. 7 is approaching quickly. Although that date may get pushed back.

In the implementation this pr is based on, the mempool is cleared once the new opcodes are enabled. Same with replay protection. See https://github.com/Bitcoin-ABC/bitcoin-abc/commit/f103591b993fef4359819bd1fb956f47e7b540e2#diff-97c3a52bc5fad452d82670a7fd291800bae20c7bc35bb82686c2c0a4ea7b5b98R2610
Is this necessary? It's missing here.

Does it really make sense to break this up into a number of PRs? because really, all of this needs to be merged for v0.17, or none of it.

all of this needs to be merged for v0.17, or none of it.

Why? I mean, ideally yes, it would be nice to have all of them activated at once but technically speaking, none of them require another one to function.

Either way is fine by me. The main reason I only added two opcodes in this pr was that I was unsure how this will be received, so I didn't want to spend too much time adding all the opcodes. In any case I will be adding the rest of the opcodes soon.

I'd say let's merge this one and then work on other opcodes in following PR(s).
@PastaPastaPasta ?

bump

@PastaPastaPasta About the src/test/monolith_opcodes_string.cpp, we agreed with @UdjinM6 that they were basically doing the same thing the script_tests.cpp are doing so kind of redundant. I think it's fine.

I'm not sure why not you couldn't have src/test/monolith_opcodes_string.cpp... / why that wouldn't make sense. A bit of test redundancy wouldn't be the end of the world

@PastaPastaPasta not a big fan of the new naming scheme personally tbh, so I'm fin either way

@PastaPastaPasta not a big fan of the new naming scheme personally tbh, so I'm fin either way

I don't have a strong prefernce, but I'd like to figure out what style we want to do and follow that

I don't have a strong prefernce, but I'd like to figure out what style we want to do and follow that

I don't think a backport PR like this is a good place to apply/enforce these rules. We could maybe start doing this in our own PRs introducing new features though...

I don't have a strong prefernce, but I'd like to figure out what style we want to do and follow that

Sounds good, please disregard formatting changes. Imo, please change the negative boolean

bump :D negative boolean


Fix duplicatioins in allure report

In allure report request and response logs are duplicated.
Additional: change request name to contain endpoint information.

Demo has been done.


Remove vsphere-hostname

MCO fix to set hostname has landed, so this service is no longer needed

/test e2e-vsphere

/retest

/skip
vsphere test fails on flakes


Use only two threads when building kie-wb-distributions

kie-wb-distributions will soon contain third GWT webapp, which means
the build will start to fail with OOM. This is a quick fix which
will make sure only two parallel threads are used to build the
kie-wb-distributions repo.
CC @cristianonicolai

+1, thanks @psiroky

@mbiarnes are you ok with these changes?


Great minds think alike

https://github.com/xkortex/passcrux
This town ain't big enough for two Harry-Potter-influenced Hashicorp-SSS-based data-splitting applications written in Golang...
So, wanna join forces?
:)
(Obviously, there's more than enough room in cyberspace, just was quoting the old spaghetti western trope :) )

What were the odds! Unfortunately I'm in side project hell right now because I've overcommitted myself to various things but I wish you all the best with your project!


No failure when used as pre-commit hook

Describe the bug

I used this as a pre-commit hook. The hook generated new files. Git commit passed OK, instead of failing.
#To Reproduce

Steps and/or code snippet(s) to reproduce the behavior:

Add a new output.
Configure the pre-commit hook.
Commit.

Expected behavior

It should fail because it created new files. That means the template output is out of sync, and thus there's a hook failure.
Additional Information

copier_template_tester Version:  1.0.2
OS: [e.g. macOS/Windows]: Linux
OS Version [e.g. Catalina/10]: Fedora 37

I can replicate the issue like this:
~/Developer/packages/calcipy_template  main≡ > nvim "asdf"ctt.toml
~/Developer/packages/calcipy_template  main≡  ~2 > git add -A
~/Developer/packages/calcipy_template  main≡  ~2 > git commit -m "asdf"

copier-template-tester...................................................Passed
check for added large files..............................................Passed
check that executables have shebangs.................(no files to check)Skipped
check json...........................................(no files to check)Skipped
check for merge conflicts................................................Passed
check for broken symlinks............................(no files to check)Skipped
check toml...............................................................Passed
check vcs permalinks.....................................................Passed
check yaml...............................................................Passed
debug statements (python)............................(no files to check)Skipped
detect destroyed symlinks................................................Passed
detect private key.......................................................Passed
fix double quoted strings............................(no files to check)Skipped
fix end of files.........................................................Passed
fix utf-8 byte order marker..............................................Passed
fix python encoding pragma...........................(no files to check)Skipped
forbid new submodules................................(no files to check)Skipped
mixed line ending........................................................Passed
pretty format json...................................(no files to check)Skipped
trim trailing whitespace.................................................Passed
beautysh.............................................(no files to check)Skipped
mdformat.............................................(no files to check)Skipped
pyproject-fmt........................................(no files to check)Skipped
shellcheck...........................................(no files to check)Skipped
Detect secrets...........................................................Passed
yamlfix..............................................(no files to check)Skipped
copier_forbidden_files...............................(no files to check)Skipped
[main 8a440e8] asdf
 3 files changed, 6 insertions(+), 2 deletions(-)

~/Developer/packages/calcipy_template  main↑1  ?1 > git status
On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .ctt/new/

nothing added to commit but untracked files present (use "git add" to track)
~/Developer/packages/calcipy_template  main↑1  ?1 >

I think to fix this, ctt would need to check if any of the folders were untracked and exit 1, but otherwise defer to pre-commit to check for differences on tracked files.
I don't think this is a pre-commit bug because pre-commit intentionally ignores untracked files: https://github.com/pre-commit/pre-commit/issues/708#issuecomment-368245812

Hi @yajo, thanks for following up. Sorry to have let this issues sit stale for so long
I think I have this issue fixed with v1.1.0. Feel free to reopen this issue if ctt isn't worked as expected!


Fixed number of decimal places in styles

Fixes #897.
From initial testing, trimming the numbers in domTree's toNode function seems to apply everywhere. It's a little more processor-intensive than rounding numbers before they become strings, but this seems to allow us to only round in this one place and catch everything.
I set the values to a max of 4 decimal places, but this can trivially be changed to any precision.

@kokopelli314 thanks for fixing those line endings.  I don't see any discernible changes in the screenshots so I think it's okay to replace the existing ones with the new ones from https://circleci.com/gh/Khan/KaTeX/5269#artifacts/containers/0 and  https://circleci.com/gh/Khan/KaTeX/5271#artifacts/containers/0.
@ylemkimon I'm surprised that nothing showed up in the "checks" tab.  Is the service that's running the screenshot app down?

Question: does this make us less accurate compared against LaTeX? Or is there no hope of being identical given layout engines that we shouldn't worry about <1/10000 ems? (Is that the correct epsilon for this PR?)

@edemaine Yup, I think 1/10,000 em would be the precision rounding with 4 decimal places.
To put it in perspective, if someone uses KaTeX on a billboard with em's 100 feet tall, the rounding would be to the nearest ~1/10th inch.
It's an interesting visual to imagine, but I'm definitely open to increasing the precision a couple orders of magnitude if that makes more sense.

The mathematician in me is uncomfortable throwing away precision for no reason. I guess the advantage is cleaner input. Is this for humans reading the output, or to speed up HTML parsers down the line? The costs seem to be possible inaccuracy (maybe only visible in printed output?), and maybe decreased performance (though not sure how measurable that is). Sorry, should have posted these questions on the original issue before the PR, but at least now we can try to evaluate them.

The mathematician in me is uncomfortable throwing away precision for no reason. I guess the advantage is cleaner input. Is this for humans reading the output, or to speed up HTML parsers down the line? The costs seem to be possible inaccuracy (maybe only visible in printed output?), and maybe decreased performance (though not sure how measurable that is). Sorry, should have posted these questions on the original issue before the PR, but at least now we can try to evaluate them.

@kokopelli314 sorry abut the duplicate comments, GitHub was having some issues yesterday.

By the way, I'm reminded that TeX lengths have some fixed-point precision. Maybe worth tracking that down and (roughly) matching it?

Those long numbers will most come from converting units and I think it's enough to round the number there:
https://github.com/Khan/KaTeX/blob/0b7b4db7fc6649ffc316016b81386f4e1cebaee0/src/units.js#L58-L59

@kevinbarabash It seems the bot froze. I've restarted the bot, for future reference:
now scale bot.katex.org 0
now scale bot.katex.org 1

I found what TeX does: see page 58 of the TeXbook:

TeX represents all dimensions internally as an integer multiple of the tiny units called sp. Since the wavelength of visible light is approximately 100 sp, rounding errors of a few sp make no difference to the eye.

According to our own table, 1sp = 1/65516pt = 1/6551.6em with our ptPerEm = 10. I think these means that this PR's 1/10000 tolerance is less than TeX's, so seems like a fine choice. A more radical choice would be to change KaTeX's internal representation to sp, but I'm not sure that's worth the effort.
Have you tried measuring the performance hit with yarn test:perf?
Do we care that render and renderToString will use different measurements (only the latter will round)?  @ylemkimon's suggestion of changing calculateSize instead would fix this.

It looks like calculateSize is a better (and much more efficient) place to do the rounding. I'll try making that change this evening, and run performance tests.
@kevinbarabash With the TeX info that @edemaine found, do you think it's still beneficial to make the precision configurable?

@kokopelli314 this is good for now, we can always add it in the future.

You'd need to adjust:
https://github.com/Khan/KaTeX/blob/b2432e8ad238dbb723d5f3c83c530fe31fadfee6/src/mathMLTree.js#L177-L178
and
https://github.com/Khan/KaTeX/blob/b2432e8ad238dbb723d5f3c83c530fe31fadfee6/src/mathMLTree.js#L185-L186
.

@ylemkimon Thanks for pointing out those lines!
It looks like there are some DOM tree elements that don't run their styles through calculateSize, meaning they're not rounded now. In particular I've noticed vlist and strut are not rounded. Would this require a more comprehensive refactor of the buildCommon.makeVList function?

@kokopelli314 how much work would it be to round those values that don't go through calculateSize?  Is it just vlist and strut or are there other places we need to add rounding?

@kokopelli314 is it necessary to usecalculateSize to do the rounding?  Could we do the rounding right inside of makeVList and staticSvg themselves?

Hey, @kokopelli314, if testing has become frustrating, remember that you can test locally and work things out before pushing a commit to the KaTeX repository. On the command line, you can run: yarn run test.
If you are developing on a Windows box like me, that doesn't work so well. Git will occasionally change all my font file line endings to CRLF. That's no problem until eslint writes 26,000 error messages. So I usually don't run eslint locally.
Instead, I write: yarn run test:jest, and yarn run test:flow locally. For the linter, I usually wait until CircleCI does its run. On a small PR, the number of true lint errors is usually pretty small.
Hope that helps.

@kevinbarabash That seems easier. I just made the change, moving the rounding function to utils.js. Does that look good?
@ronkok Thanks for the tip! The 26,000 eslint error messages show up when I run git commit. I get around it by running dos2unix before each commit, but that has the side effect of marking nearly all files as modified. Know of a way around the commit auto-linting?

git commit -n -m '<message>' will commit in a way that evades hooks/pre-commit

@kokopelli314 I'm going to close this for now due to lack of activity.  Feel free to reopen this PR if you get some time to address the edits that @ylemkimon suggested.


update scipy import style

noticed something interesting while I was looking through lightgbm python code - they don't use "import scipy as sp", which at first I thought was a bad decision.  Then I ran into this, which suggested that for scipy it's better to import specific modules instead of  the top-level namespace:
https://docs.scipy.org/doc/scipy/reference/api.html#guidelines-for-importing-functions-from-scipy
https://stackoverflow.com/questions/36014733/official-abbreviation-for-import-scipy-as-sp-sc
https://github.com/rougier/python-opengl/issues/1
Seems like it might be good to apply this suggested style to intepret-community as well.

closing this issue as the fix has been merged (actually, merged back in May!)


A couple of fixes, one in sysbox-fs and one in a dind test.

CI failed due to known instability in sysbox pod tests in Travis CI. Those same tests pass in my local dev machine. Will commit.


Initial test: Adding LocalNeighborhood to SPRAS

First attempt at adding LocalNeighborhood method to SPRAS using the CONTRIBUTING.md guide. Output appears to be in the desired format. Ran into some hurdles with the summary and graphspace analyses in config.yaml: needed to set these as false to get the local neighborhood operational.

Excellent, thank you. Altaf helped me debug the error causing summary and graphspace to not work with Local Neighborhood, so I pushed another commit.

We're done with this contributing guide pull request


ca_orange_county_sherrif.py

Created "scrape-meta" and "scrape" functions for the Orange County Sheriff's Department. This currently pulls all officer records hyperlinked on OCSD's website (https://www.ocsheriff.gov/about-ocsheriff/peace-officer-records-releases) as .zip files. I tested using WSL on a Windows machine and it worked properly.
An update will need to be made to also download files that have URLs provided in plain text only (not hyperlinked). There are currently two such .zip files.

Closing since we handled PR in #29


fix many cpp lint errors

refer to #1990

BTW, this will have some conflicts with other PRs.
@StrikerRUS I think we should merge this ASAP.

@StrikerRUS yeah, but it seems the reinterpret_cast is the only way, and it actually equals to c style cast.

@StrikerRUS BTW, as json11 is not maintained by us, we can disable the lint check over it.

@guolinke Yes, but why?.. As it's not a "submodule" (as compute) it falls into situation when it's maintained by no one. I think it's not right. Seems that the license allows to modify it. I remember there were some dangerous warnings from cpplint for json11.

Okay, I think we won't modify it, so we can keep it as it is. However, if these warnings are easy to fix, we could fix it directly.


bl-collapsible - new features

Should support

lazyLoading
animations

inspiration https://github.com/basarat/expandible

What do you mean by lazy loading?

lazy render as in https://github.com/basarat/expandible?
or really loading?

We are rendering content only if Collapsible is opened, so you would suggest to do that only for the first time and after that hiding it by CSS class?

is that right?


runtime: merge workarounds to false deadlocks

In #40368, I avoided false deadlocks from startm in sysmon by reserving M ids in advance to make it look like the new M is already running to checkdead.
Later, I discovered that @dvyukov fixed a nearly identical issue in #6070 by temporarily decrementing the number of idle locked M's, to make checkdead see an extra M. Slightly different approach, but same end result.
We should merge these two approaches back to one just to keep things simpler and easier to understand.
cc @aclements @mknyszek @ianlancetaylor

With your change to startm to reserve an ID while holding sched.lock, is the logic in sysmon even necessary?

I'm also certain that the incidlelocked logic in sysmon is unnecessary after my change. There is similar logic in retake that I'll need to look at more closely.

Bumping to 1.17, but @prattmic, please bump to Backlog if you don't plan on working on this in 1.17.

@prattmic Is anything going to happen in 1.17?  If not, we should change the milestone to Backlog.  Thanks.


sentry: preserve original Secret metadata

When storeKubernetes writes a secret it overrides existing metadata. We expect secret to be created in advance, so we must preserve original metadata such as lables (and annotations), which is usefull to keep secret under helm management.
Signed-off-by: Dinar Valeev<EMAIL_ADDRESS>Description

Issue reference

Please reference the issue this PR will close: #[issue number]
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[ ] Code compiles correctly
[ ] Created/updated tests
[ ] Unit tests passing
[ ] End-to-end tests passing
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Specification has been updated / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Provided sample for the feature / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

/ok-to-test

@yaron2 Ah, sorry for that. Fixed

Thanks for your contribution @k0da.
We will need to test and validate our K8s upgrade scenarios to make sure this doesn't break anything.


Extended FABs don’t require an icon

This issue is a bug report.
Description
In Material design, an extended FAB doesn’t require an icon.
https://material.io/design/components/buttons-floating-action-button.html#extended-fab

So, I think the @required below should be removed.
https://github.com/flutter/flutter/blob/216a65b6697f2ca5cf3501e50c3f9592334fbe4b/packages/flutter/lib/src/material/floating_action_button.dart#L116
If you guys agree, I can create a pull request to fix it.
Steps to Reproduce

null
Logs

null

Good point, will fix this.

@HansMuller you saw that there is already a PR? #27711

@zoechi I have seen #27711, thanks for the reminder


jwt_authn: bypass CORS preflight request

Signed-off-by: Yangmin Zhu<EMAIL_ADDRESS>For an explanation of how to fill out the fields, please see the relevant section
in PULL_REQUESTS.md
Description: Bypass the CORS preflight request in the JWT filter
Risk Level: Low
Testing: Added unit test and integration test
Docs Changes: Added in jwt_authn_filter.rst
Release Notes: Added jwt_authn: added to bypass the CORS preflight request.
Optional Fixes: https://github.com/istio/istio/issues/16171
[Optional Deprecated:]

cc @qiwzhang @lizan

@lizan @qiwzhang @diemtvu
I have a few questions regarding the CORS preflight support in the jwt_authn filter and it might be faster to just ask in the PR.

Can we add the support to allow the jwt_authn filter to bypass the CORS preflight request? This unblocks the use case in https://github.com/istio/istio/issues/16171 and might be useful for other Envoy customers as well.

There might be a alternative solution that doesn't change the jwt_authn filter by adding a special RequirementRule that sets allow_missing_or_failed to true for CORS preflight request.

I prefer to add this as the bulit-in feature in the jwt_authn filter as it's kind of a standard to bypass the CORS preflight request. This PR adds the support without any configuration changes. If you prefer to add a new option to control this, we can add something like bool bypass_cors_preflight to JwtAuthentication.

Let me know if you have any other suggestions, thank you!

For the Istio issue, it should be solved with authz (rbac), or the custom
authn filter today.  Having jwt filter always passed, preflight request not
going to help if other filters still reject it.
I let @lizan and @qiwzhang address the need for Envoy. Personally, I think
we should simplify this JWT filter and move more to rbac for access
control.
On Wed, Nov 13, 2019, 12:02 AM Yangmin Zhu<EMAIL_ADDRESS>wrote:

@lizan https://github.com/lizan @qiwzhang https://github.com/qiwzhang
@diemtvu https://github.com/diemtvu
I have a few questions regarding the CORS preflight support in the
jwt_authn filter and it might be faster to just ask in the PR.

Can we add the support to allow the jwt_authn filter to bypass the
CORS preflight request? This unblocks the use case in istio/istio#16171
https://github.com/istio/istio/issues/16171 and might be useful for
other Envoy customers as well.

There might be a alternative solution that doesn't change the jwt_authn
filter by adding a special RequirementRule that sets
allow_missing_or_failed to true for CORS preflight request.

I prefer to add this as the bulit-in feature in the jwt_authn filter
as it's kind of a standard to bypass the CORS preflight request. This PR
adds the support without any configuration changes. If you prefer to add a
new option to control this, we can add something like bool
bypass_cors_preflight to JwtAuthentication.
2.
Let me know if you have any other suggestions, thank you!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/envoyproxy/envoy/pull/9004?email_source=notifications&email_token=AF7X24PE2HD444WPDIEKMZTQTOYBFA5CNFSM4JMPVTI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOED5HMNA#issuecomment-553285172,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AF7X24NKQ3TEW7ODNCTZOFDQTOYBFANCNFSM4JMPVTIQ
.

I prefer 2) with a flag in config "bypass_cors_preflight" to enable it.

@diemtvu Actually this PR doesn't fix the bug in Istio, I have another PR that changes the istio_authn filter.
@lizan Let me know what do you think.

Can you fix the doc build?

@lizan Fixed the doc, thanks for the review.

@envoyproxy/api-shepherds API LGTM


Test PR for CI tools

Deleted some whitespace.

@PerezHz Any idea why Appveyor isn't running?

@MasonProtter don't know for sure, but just tried to activate my fork in appveyor and it is now running correctly; did you go to the projects tab in appveyor and clicked on "+ new project" and added the original Symbolics.jl repo?

It looks like appveyor is now ready; could you please try to push another commit to trigger a build?

Its saying that a build is queued in the checks tab but not in the merge box. Strange.

🤔... Could you please try to go to https://ci.appveyor.com/project/MasonProtter/symbolics-jl and see if there's a "new build" button which you can click?


New Crowdin translations

New Crowdin pull request with translations

Codecov Report

Merging #346 (281488f) into master (63c1546) will not change coverage.
The diff coverage is n/a.

 Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Updated java generation

Updated java generation to use ChannelProvider and
ExecutorProvider interfaces
Updated tests

PTAL

PTAL

There is generated sample code that is put on the XApi classes that references the defaultInstance() method, which should be updated.

PTAL

LGTM