SpecFlow step definitions with parametrized cucumber expressions are not recognized

I have simple step definitions, like:
[Then(@"there should be {int} pizzas listed")]
public void ThenThereShouldBePizzasListed(int expectedCount)
{
            ...
}

or
[Then(@"the home page main message should be: {string}")]
public void ThenTheHomePageMainMessageShouldBe(string expectedMessage)
{
    ...
}

but the related steps are displayed as undefined. The ones without parameter work...

This sounds like a perfectly sensible approach to me @aslakhellesoy . Not being as familiar as yourself with this codebase, it sounds like, from your description, that this will work across step definitions in all languages.
One thing to note is the StepArgumentTransformation will be a verbatim string literal when special regex characters are used (i.e. @"regex characters (.*)"). I'm not sure if that impacts the implementation.

@aslakhellesoy Thx for the improvements. I have some notes/feedback.

The unnamed parameters can be used with type name as you have observed, but makes sense to mention that this is always the .NET type name, not the c# keyword (Int32 vs int). But the extension defines the most commonly used c# type keywords and use them as an alias for the full type name. So if you make a conversion with decimal return type, you will be able to use it both as {Decimal} (because this is the type name) or {decimal} because this is an alias for {Decimal}.
Not with the plugin, but with the final integration, you will be able to make named parameter types in [StepArgumentTransformation("some-regex", Name = "mytypename")].
Again in the final version we had to introduce an automatic inclusion of enumeration parameter types. Enums can be converted by default by SpecFlow anyway, so you want to be able to use {Color} (assuming Color is an enum type), without having any StepArgumentTransformation for them.
Altogether the parameter matching is fairly complex, because it had to match with the existing parameter type system of SpecFlow, so in the VS extension we simply use .*? for all cucumber expression parameters. I haven't run into conflict so far and generally it is better to show a match that might cause parameter errors runtime than showing it as "unspecified" just because we could not interpret perfectly the parameter rules. I would like to keep highlighting, that many teams use assets (e.g. step argument conversions) from external assemblies, so by only parsing c# it is never going to be perfect. So it is better to prepare for imperfection.
In general verbatim and non-verbatim C# strings are interchangeable. So theoretically we should support both in all places where we need strings. Also with new C# you can use interpolated strings in attributes $"hello {foo} bar", but this is fortunately very rarely used. And you can also use constants as well, but that is also rarely used.

The comprehensiveness of @gasparnagy 's reply compared to mine does a good job of highlighting the difference of one who writes the software, and one who simply consumes it :joy:
I think I'll defer to @gasparnagy in this case!


Fix: Item edit pages not hidden/redirect for anon or non-authorised users

References

Fixes #2728

Description
Refactored all guards based on SomeFeatureAuthorizationGuard as well as their dependents into functional guards for compatibility with Angular 17. Additionally, ensured proper fixes across module files, resolvers, and tests to accommodate these changes, while addressing issue #2728 with additional guard implementation and corresponding test coverage.
Instructions for Reviewers
List of changes in this PR:

First, refactored SomeFeatureAuthorizationGuard and SingleFeatureAuthorizationGuard as functional guards as well as all other guards that extended them.
Second, updated all the routes that use them and verified that they still function in exactly the same way as they do on demo.dspace.org
Third, refactored the unit tests to work with the new functional guards as well.
Fourth, created new guards for the routes described in issue #2728 and verified that after adding them the issue no longer occurs.
Fifth, wrote unit tests for the new guards.

How to test and review this PR:

Steps to reproduce the bug can be found in #2728
With the new feature, anon users are redirected to login page, and users without item edit rights are shown forbidden page
These changes aim to prevent unauthorized access to certain Item pages requiring specific authorizations.

Checklist
This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

[x] My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
[x] My PR passes ESLint validation using yarn lint
[x] My PR doesn't introduce circular dependencies (verified via yarn check-circ-deps)
[x] My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
[x] My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
[x] If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
[x] If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
[x] If my PR fixes an issue ticket, I've linked them together.

@tdonohue Thank you for your feedback! The 403 errors for Community/Collection Administrators when managing roles/groups have now been fixed.

Merging immediately as this works well and fixes the noted high priority bugs.  @atarix83 : if you have feedback on this PR after OR2024, we can ask that it be addressed in a follow-up PR.
Thanks again @ZahraaChreim-Atmire and @LotteHofstede !


Deferred highlighting with vim.schedule causes issue

The previous API was defininig the highlight groups synchronously. Now that vim.schedule is used, the function returns the HL group name but it's not defined yet because the scheduled function hasn't run yet.
Not sure why you've enabled that but I would tend to believe that this new behavior is incorrect.
Users of barbar.nvim who update their packages are all affected by this issue, LMK what's the ETA and resolution when you have more details.
Link: https://github.com/romgrk/barbar.nvim/issues/98

fuuuu an user yesterday wanted to load hl groups when requested to load nvim faster. But then, telescope users reported that the get_highlight_name was causing errors because it's called asynchronously and suggested wrapping in vim.schedule.
I guess maybe we should just revert back to how it was before.

should be fixed, sorry for the inconvenience

Cool! Beyond the inconvenience, I do understand the point of making things snappier. If you're interested in reinstating the behavior, maybe we could work out an API that is async-aware? E.g. it could return none or a default HL group (Normal?) if the function is called before the devicon HL group is defined.

telescope uses get_highlight_name in a lua callback, so when we moved the nvim_command call inside of it, it broke because vim functions need to be wrapped in a schedule call when used asynchronously.
This is not too important rn, async stuff should be treated with caution and maybe rethinking how to make it work would take more time. Breakage like this is not supposed to happen, maybe tests would be required at some point.


error: Unsported attribute

Hallo:
Adapter v0.1.6
Roborock Q7 Max
99+ mal
`

roborock.0
2023-04-21 19:12:31.632
error
Unsported attribute: charge_status of get_status. Please contact the dev to add the newly found attribute of your robot.

roborock.0
2023-04-21 19:12:31.632
error
Unsported attribute: switch_map_mode of get_status. Please contact the dev to add the newly found attribute of your robot.

roborock.0
2023-04-21 19:11:31.634
error
Unsported attribute: charge_status of get_status. Please contact the dev to add the newly found attribute of your robot.

roborock.0
2023-04-21 19:11:31.633
error
Unsported attribute: switch_map_mode of get_status. Please contact the dev to add the newly found attribute of your robot.

`
Um welchen Attribut handelt es sich?  Wie kann ich helfen?

Hi,
das ist in der aktuelle dev Version bereits behoben. https://github.com/copystring/ioBroker.roborock/commit/5bb518ab31436b9bed1ec9ca640e6d6ee4d72938


Browser test and throws()

I used Teston to test es6 code in both  browser and node. Also added throws(). This needed some modification. Added a HTML file that run the tests. The link to run the test in README.md need to be pointed to your projects and GitHub pages pages activated. The version also need to be updated

Hello!
Is the pull request rejected? I think I have handled  your change requests. Should I Close and do a new one?
BR Håkan

Sorry, I missed this – merged now, thank you so much!

Thank you! You ave really made an impressive amount of repos.

You have to activate GitHub pages for "Runt tests in browser" to work. The link is correct i think.

Yeah, and getting the new github security updates from all those repos makes my inbox scream 😄

Tried to run testes in browser under:
https://github.com/testonjs/teston#test
It fails. Is GitHub pages inactivated by design? Might the link be wrong after all?
BTW: I have deleted my fork

Should work now

Excellent! Tested and it is up and running!


SoVi Spreadsheet

[https://deltacouncil.sharepoint.com/:x:/r/sites/Extranet-Science/Shared Documents/NCEAS-DSP working group/2023/Social Vulnerability Sub-group/Social vulnerability factors.xlsx?d=wfbfdd00238874abea31a2b06ff98e741&csf=1&web=1&e=wX6Mng](SoVi Spreadsheet)


replace git-pull-request icon with lucide icon

The current icons for the diff and source control view don't have the proper stroke and fill config, so they end up always being black. This replaces them with the built-in lucide icon for git pull requests.
Before:

After:

The current icons work fine for me. I'm pretty sure they don't have to be prefixed with lucide from reading the docs. I'm nowhere defining the icon myself, so they already have to be coming from the included lucide icons.
I think you are using some custom plugin or theme, which break them. Your current pull request icon doesn't match the actual from lucide and how it's looking for me, because you already have the arrow in it.

https://docs.obsidian.md/Plugins/User+interface/Icons

...huh. You're right, it looks fine in a fresh vault. After some debugging, turns out something in the Jira integration plugin is overriding or conflicting. I'll figure out what's causing the conflict on that side - that plugin should probably not be replacing the icon.


Update PULL_REQUEST_TEMPLATE to include an API spec change in the checklist.

Coming from https://github.com/opensearch-project/opensearch-api-specification/issues/387, update PR template to include a checkbox that requests that all API changes be documented in the OpenAPI spec used to generate clients.

@riysaxen-amzn @sbcd90 anyone?


When editing profile, editing text around URLs causes errors

Subject: When editing profile, editing text around URLs causes errors
Description:
Edited my profile, specifically a text that contained a link and whenever I tried to delete or insert a letter or space, in or near the URL, the cursor jumped and would not let me correct the text. See the video linked below.
Results:
It should have allowed me to edit the text like normal.
Backend version: develop-d732f04e
Frontend version: develop-d732f04e
User Agent: Mozilla/5.0 (Android 11; Mobile; rv:87.0) Gecko/87.0 Firefox/87.0
Page: https://app.couchers.org/user
User (spoofable): jesse (57)

Is this still an issue? @jesseallhands

Actually just going to close this, hasn't been re-reported in 3 years...


Add support for region during signup

Currently the sign up process defaults to us-west-2 region, we should add support to take a region input parameter as we add support for additional AWS regions.

Closed via https://github.com/momentohq/momento-cli/pull/31


Raise TypeError if Point is init with > 3 args

Closes #525.

Coverage increased (+0.01%) to 79.931% when pulling eadcbacd030fd82d495565edeadec7c20ad71b76 on snorfalorpagus:fix525 into e302ceb942cb7b2d7aedae4f94810bad1b1a7441 on Toblerity:master.

Thanks @snorfalorpagus !


Fix id_tensor_storage for XLA tensors.

XLA tensors don't have storage and attempting to get it's storage will get
RuntimeError: Attempted to access the data pointer on an
invalid python storage.
Repro:
from transformers import pytorch_utils
import torch_xla.core.xla_model as xm
device = xm.xla_device()
a = torch.ones((10,10)).to(device)
pytorch_utils.id_tensor_storage(a)  # raises RuntimeError

With this patch it would print out
(device(type='xla', index=0), 1, 400).

Hi @muellerzr this is Han from Pytorch/XLA. currently this is affecting the ability to save the model after training for on TPUs.
for example:
+ python3 examples/pytorch/xla_spawn.py --num_cores=4 examples/pytorch/image-pretraining/run_mae.py --dataset_name=cifar10 --remove_unused_columns=False --label_names=pixel_values --mask_ratio=0.75 --norm_pix_loss=True --do_train=true --do_eval=true --base_learning_rate=1.5e-4 --lr_scheduler_type=cosine --weight_decay=0.05 --num_train_epochs=3 --warmup_ratio=0.05 '--per_device_train_batch_size=8 ' '--per_device_eval_batch_size=8 ' --logging_strategy=steps --logging_steps=30 --evaluation_strategy=epoch --save_strategy=epoch --load_best_model_at_end=True --save_total_limit=3 --seed=1337 --output_dir=MAE --overwrite_output_dir=true --logging_dir=./tensorboard-metrics --debug=tpu_metrics_debug

would raise Runtime error.
Please take a look, thanks!
cc. @JackCaoG

Hey thanks for the patch.
I really relinquish relying on private torch parts (aside from backporting functionality to older torch versions).
Also tensor_id isn't a data_ptr iiuc, so it would probably break other logic (trying to figure out storage space and such).
Can we move the fix directly in transformers to keep as-is ?

Agree with @Narsil, it'd be better to keep this isolated to the library, with either transformers or accelerate (or both if needed)

Sounds good, thanks @Narsil  @muellerzr !


VPN unreliable after resume

Investigate, perhaps quick fix with command to close and open Steam.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Fixed with Admin command restarting Steam.
https://github.com/cloudRIG/CLI/commit/6309f79362845533b30c68efb34447bbfa5b0eb0#diff-6d186b954a58d5bb740f73d84fe39073L173


characters disapear when indenting lines pastes with tabs in it (my indent is spaces)

Description
What steps will reproduce the problem?

    doc = KML.kml(
        KML.Placemark(
            KML.name(areaName),
            KML.MultiGeometry(
                KML.Polygon(
                    KML.outerBoundaryIs(
                        KML.LinearRing(
                            KML.coordinates("""
					6.2617340087890625,43.817649841308594
					6.2622528076171875,43.82663154602051
					6.2747039794921875,43.82625961303711
					6.2741851806640625,43.81727600097656
					6.2617340087890625,43.817649841308594
                                            """
                                             )
                        )
                    )
                )
            )
        )
    )

if you try to indent (with tab key) the coordinates lines, the first digits at the begining of each line will disappear.
these lines were copy/paste from another file and they contains tabs I think
my indentation tuning is with 4 spaces
thanks
Versions

Spyder version: 4.1.4
Python version: 3.8.3
Qt version: 5.9.7
PyQt5 version: 5.9.2
Operating System: Windows 10

Dependencies

# Mandatory:
atomicwrites >=1.2.0           :  1.4.0 (OK)
chardet >=2.0.0                :  3.0.4 (OK)
cloudpickle >=0.5.0            :  1.5.0 (OK)
diff_match_patch >=20181111    :  20200713 (OK)
intervaltree                   :  None (OK)
IPython >=4.0                  :  7.16.1 (OK)
jedi =0.17.1                   :  0.17.1 (OK)
nbconvert >=4.0                :  5.6.1 (OK)
numpydoc >=0.6.0               :  1.1.0 (OK)
paramiko >=2.4.0               :  2.7.1 (OK)
parso =0.7.0                   :  0.7.0 (OK)
pexpect >=4.4.0                :  4.8.0 (OK)
pickleshare >=0.4              :  0.7.5 (OK)
psutil >=5.3                   :  5.7.0 (OK)
pygments >=2.0                 :  2.6.1 (OK)
pylint >=1.0                   :  2.5.3 (OK)
pyls >=0.34.0;<1.0.0           :  0.34.1 (OK)
qdarkstyle >=2.8               :  2.8.1 (OK)
qtawesome >=0.5.7              :  0.7.2 (OK)
qtconsole >=4.6.0              :  4.7.5 (OK)
qtpy >=1.5.0                   :  1.9.0 (OK)
rtree >=0.8.3                  :  0.9.4 (OK)
sphinx >=0.6.6                 :  3.1.2 (OK)
spyder_kernels >=1.9.2;<1.10.0 :  1.9.2 (OK)
watchdog                       :  None (OK)
zmq >=17                       :  19.0.1 (OK)

# Optional:
cython >=0.21                  :  0.29.21 (OK)
matplotlib >=2.0.0             :  3.2.2 (OK)
numpy >=1.7                    :  1.18.5 (OK)
pandas >=0.13.1                :  1.0.5 (OK)
scipy >=0.17.0                 :  1.5.0 (OK)
sympy >=0.7.3                  :  1.6.1 (OK)

Here is the result of the indenting :
  doc = KML.kml(         KML.Placemark(             KML.name(areaName),             KML.MultiGeometry(                 KML.Polygon(                     KML.outerBoundaryIs(                         KML.LinearRing(                             KML.coordinates("""<PHONE_NUMBER>625,43.817649841308594<PHONE_NUMBER>875,43.82663154602051<PHONE_NUMBER>875,43.82625961303711 					6.2741851806640625,43.81727600097656 					6.2617340087890625,43.817649841308594

If you copy/paste the lines above into your spyder editor, you can reproduce the bug by trying to indent the numbers

my editing tuning (sorry it's in french) with 4 spaces for indentation

Hi @thierryhedde thanks for the feedback! I was able to reproduce this behavior. For now, one way to workaround this problem is selecting more than one line when indenting:

We will check this for a future release :+:


Add script from going from balance export -> unclaimed airdrop amts

This is a simple script intended to go from the balance export, to stats on unclaimed airdrop, but accounting forthe already distributed 20% for folks who haven't done any txs yet.
So it outputs the amount technically unclaimed, and the amount unclaimed including the 20% for folks who haven't done anything yet.
Output when I ran it Aug 16th:
unclaimed non-already-distributed balance 27788676.819247 osmo
unclaimed & inactive 34648325.61145 osmo
simple prediction for unclaimed and inactive (div by .8) 34735846.02405875 osmo

Codecov Report

Merging #420 (dc97d89) into main (af6cb98) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #420   +/-   ##
=======================================
  Coverage   18.50%   18.50%
=======================================
  Files         142      142
  Lines       22035    22035
=======================================
  Hits         4078     4078
  Misses      17273    17273
  Partials      684      684

Continue to review full report at Codecov.

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


Swift 3 Support

Hi,
Is there an updated version that compiles on x8 available? : )

There is an open PR for Swift 3 support that compiles with Xcode 8. I do have some updates for that as well, as well as some new features.
However, I won't be merging this until Xcode 8 is released officially over the next few weeks.

I'm closing this since https://github.com/shaps80/InkKit/issues/4 will address this issue


Fix error handling in auth0 ul customize to gracefully ignore specific prompt errors

🔧 Changes

This PR improves error handling for the auth0 ul customize functionality, ensuring that specific prompt-related errors (such as "Your account does not have custom prompts" or "feature is not available for your plan") are gracefully ignored. This change prevents the function from failing due to these non-critical issues and enhances the robustness of the system.

Improved error checking for specific API responses related to unavailable features.
Updated relevant test cases to ensure proper handling of ignored errors.

📚 References

N/A
🔬 Testing

This change was tested with updated unit tests that verify:

Error handling for unavailable prompts or features, ensuring these errors are safely ignored.
Manual End-to-end testing with various branding settings and prompt customizations to validate system behaviour in different scenarios.

📝 Checklist

[x] All new/changed functionality is covered by tests
[x] I have added documentation for all new/changed functionality (or N/A)

Codecov Report
Attention: Patch coverage is 77.77778% with 2 lines in your changes missing coverage. Please review.

Project coverage is 72.05%. Comparing base (5ce0e13) to head (ec9e6a5).

Files with missing lines
Patch %
Lines

internal/cli/universal_login_customize.go
77.77%
2 Missing :warning:

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1081   +/-   ##
=======================================
  Coverage   72.05%   72.05%
=======================================
  Files          94       94
  Lines       12938    12942    +4
=======================================
+ Hits         9322     9326    +4
  Misses       3069     3069
  Partials      547      547

Flag
Coverage Δ

72.05% <77.77%> (+<0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


assertThat is ambiguous for generics in java 8

If the first argument of assertThat is a generic that cannot be inferred, compilation fails with:
reference to assertThat is ambiguous
both method assertThat (java.lang.CharSequence) in org.assertj.core.api.Assertions and method assertThat(org.assertj.core.api.AssertProvider) in org.assertj.core.api.Assertions match
The code snippet below demonstrates the error:
package com.example.assertj;

import static org.assertj.core.api.Assertions.*;

import org.assertj.core.api.Assertions;
import org.junit.Test;

public class AssertjTest {

    public static <T> T returnGeneric() {
        return (T) new Object();
    }

    @Test
    public void failsToCompileWithJava8(){
        assertThat(returnGeneric()).isEqualTo("foo");
    }
}

This was done using assertj-core 3.1.0
Workaround is to explicitly cast. e.g.
        assertThat((Object) returnGeneric()).isEqualTo("foo");

Is this something that can be fixed within assertj, or is there no way to avoid the explicit cast?

Can you give a try to StrictAssertions instead of Assertions ?

Same with StrictAssertions:
reference to assertThat is ambiguous
both method assertThat(java.util.OptionalDouble) in org.assertj.core.api.StrictAssertions and method assertThat(java.util.Optional) in org.assertj.core.api.StrictAssertions match

I'm actually not sure this can be fixed, Java 8 is much stricter about generics.
This issue reminds me of https://github.com/joel-costigliola/assertj-core/issues/365 and http://stackoverflow.com/questions/29499847/ambiguous-method-in-java-8-why/29500086#29500086.

I'm closing this as I don't think there is a solution for that.
Feel free to prove me wrong and I'll gladly reopen this issue.


[5.5] Throw BadMethodCallException when attempting to resolve a policy that is not defined on the gate

This is in reference to this internals discussion which Taylor gave 👍
At the moment, if you check authorization on an "undefined" ability, it'll just return false:
$result = Gate::check('func_doesnt_exist_on_policy_and_ability_not_defined', $user);

This creates the illusion that the check went through and returned false, when in actual fact it couldn't be checked because the function doesn't exist on the policy and the ability is not even defined. By forcing an exception, it'll ensure that policies are properly defined on the Gate.

Seems is_callable is in a lot of places, will maybe send another PR with a better implementation.

I don't think throwing an exception is the solution there,
it can break an entiere application, just for one missing ability.
Throwing an exception is more clean, but just returning false is better in the day-to-day functionnality, it's not breaking anything.

I disagree - case in point, we implemented a policy check and had a typo in the ability name (extra space) the Gate blindly just returned false leading us to believe everything was all fine even though it couldn't actually explicitly check the permission; this to me is an exception. If the gate can't explicitly check a permission because it can't find a class or closure to check by, it should throw an exception.
If you attempted to call a function on a class that doesn't exist would you just want it to return null ? Blindly return false is not helpful, and at best completely misleading.


Nuitka-Scons:INFO: Backend C compiler: gcc (gcc). ccache: error: Bad magic value: 0x0000 module.requests

Nuitka fails during the backend compilation.
Nuitka-Options:INFO: Used command line options: 5gtop.py --standalone
Nuitka:INFO: Starting Python compilation with Nuitka '1.2' on Python '3.10' commercial grade 'not installed'.
Nuitka-Plugins:INFO: multiprocessing: Injecting pre-module load code for module 'multiprocessing':
Nuitka-Plugins:INFO: multiprocessing:     Monkey patching "multiprocessing" load environment.
Nuitka-Plugins:INFO: multiprocessing: Injecting post-module load code for module 'multiprocessing':
Nuitka-Plugins:INFO: multiprocessing:     Monkey patching "multiprocessing" for compiled methods.
Nuitka:INFO: Completed Python level compilation and optimization.
Nuitka:INFO: Generating source code for C backend compiler.
Nuitka:INFO: Running data composer tool for optimal constant value handling.
Nuitka:INFO: Running C compilation via Scons.
Nuitka-Scons:INFO: Backend C compiler: gcc (gcc).
ccache: error: Bad magic value: 0x0000
Backend C: 83.9%|████████████████████▉    | 265/316scons: *** [module.requests.o] Error 1
ccache: error: Bad magic value: 0x0000
Backend C: 84.5%|█████████████████████    | 267/316scons: *** [module.requests.compat.o] Error 1

Nuitka version, full Python version, flavor, OS, etc. as output by this
command.  > python -m nuitka --version
1.2
Commercial: None
Python: 3.10.7 (tags/v3.10.7:6cc6b13, Sep  5 2022, 14:08:36) [MSC v.1933 64 bit (AMD64)]
Flavor: Unknown
Executable: C:\Users\1pdos\AppData\Local\Programs\Python\Python310\python.exe
OS: Windows
Arch: x86_64
WindowsRelease: 1

How did you install Nuitka and Python
Nuitka was installed using Pip
Python was installed using the installer on the Python website.

The specific PyPI names and versions
certifi==2022.9.24
cffi==1.15.1
charset-normalizer==2.1.1
huawei-lte-api==1.6.7
icmplib==3.0.3
idna==3.4
Nuitka==1.2
ordered-set==4.1.0
pycparser==2.21
pycryptodomex==3.15.0
pyusb==1.2.1
requests==2.28.1
urllib3==1.26.12
usb==0.0.83.dev0
windows-curses==2.3.1
xmltodict==0.13.0
zstandard==0.19.0

Many times when you get an error from Nuitka, your setup may be special

Compilation was done in fresh, clean Windows 10 environment with only Python, Nuitka and Google Chrome installed.

Also supply a Short, Self Contained, Correct, Example
5gtop.zip

Provide in your issue the Nuitka options used

5gtop.py --standalone

With the current factory there is an option --clean-cache=ccache that you should use once. This may be another case where the parsing of errors from C commands could detect the need I guess. I will try and add a parsing for that message as well. We recently adding something for clcache.
https://nuitka.net/doc/factory.html

Thanks. That did the trick and all is working. Good stuff.

This has been added at some point and is part of the 1.4 release.


Invalid line value on TrailingWhitespace error with gradle

Expected Behavior
When using the gradle plugin, it seems that the line number is invalid for some TrailingWhitespace error but it works as expected when executing the jar (it returns the proper line).
When using gradle, I'm expecting line 6 to be reported, similar to when using the jar.
$ ./gradlew detektCheck
[...]
Ruleset: style - 5min debt
	TrailingWhitespace - [test.kt] at /tmp/test.kt:6:38

Current Behavior
But instead, line 3 is reported:
$ ./gradlew detektCheck
[...]
Ruleset: style - 5min debt
        TrailingWhitespace - [test.kt] at /tmp/test.kt:3:23

Steps to Reproduce (for bugs)
Use this file:
package demo

fun main(args: Array<String>) {
    println("""
        Hello, world!
        here is a trailing space -->
        """)
}

Run java -jar detekt-cli-1.0.0.RC8-all.jar -i test.kt -> line 6 is reported (OK)
Run ./gradlew detektCheck -> line 3 is reported (NOK)

Your Environment

Version used: 1.0.0-RC8

Thanks for reporting this. This issue is already fixed and will be included in the new detekt version.
Duplicate #1030


Error while trying to start overfast-api

Describe the bug
Errored when trying to run overfast-api in production
To Reproduce

git clone https://github.com/TeKrop/overfast-api && cd overfast-api
Created and edited .env and changed APP_PORT, APP_BASE_URL
apt install make (GNU make 4.3)
make up (inside folder overfast-api)
shows error

root@itzdrli-dev-armv8:/home/dev/overfast-api# make up
Building OverFastAPI (production mode)...
docker compose build
WARN[0000] /home/dev/overfast-api/docker-compose.yml: `version` is obsolete
[+] Building 43.4s (37/44)                                                                                docker:default
 => [redis internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 109B                                                                                0.0s
 => [redis internal] load metadata for docker.io/library/redis:alpine                                                                                1.2s
 => [redis internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [redis 1/4] FROM docker.io/library/redis:alpine@sha256:0389bb8416d7c6ed065c25745179bf5d358e5d9472dd30a687ab36ffbb650262                                                                                1.3s
 => => resolve docker.io/library/redis:alpine@sha256:0389bb8416d7c6ed065c25745179bf5d358e5d9472dd30a687ab36ffbb650262                                                                                0.0s
 => => sha256:0389bb8416d7c6ed065c25745179bf5d358e5d9472dd30a687ab36ffbb650262 10.20kB / 10.20kB                                                                                0.0s
 => => sha256:94747bd812346354fd5042870b6e44e5406880a4e6b5736a9cf9c753110df11b 4.09MB / 4.09MB                                                                                0.3s
 => => sha256:cdfbf2aae844ce899e13c8e08b524cfba67d9ddd6c5ca10be36c85aac3dc2ce7 961B / 961B                                                                                0.1s
 => => sha256:16098e28f60cd9af53fb043cf88a98958b3760bc0ac96b7a4e8ee40ce1e3e7d3 2.48kB / 2.48kB                                                                                0.0s
 => => sha256:cdb453bbf44653b2fff791f1950bc858a4156551f0a99eb868a81e17144a5297 7.92kB / 7.92kB                                                                                0.0s
 => => sha256:510e151e1774050d5f5bb60a85736a80fa6c006791db5cebe6d506d65dec84a1 178.15kB / 178.15kB                                                                                0.3s
 => => sha256:70498b03edf90991b22ce539adf5694ff45163da2c71ec1501e5611fd228913e 934.59kB / 934.59kB                                                                                0.4s
 => => extracting sha256:94747bd812346354fd5042870b6e44e5406880a4e6b5736a9cf9c753110df11b                                                                                0.2s
 => => sha256:b4a58c1d515ac6de0babaf7b798a89ae1a6707d9b0a70b647b735060b7da96cd 12.14MB / 12.14MB                                                                                0.5s
 => => sha256:f5bb1f316352fd460172c7e484e857550bb23940c213e90eeda6853f5c7f80dc 97B / 97B                                                                                0.5s
 => => extracting sha256:cdfbf2aae844ce899e13c8e08b524cfba67d9ddd6c5ca10be36c85aac3dc2ce7                                                                                0.0s
 => => sha256:8e79f523a11aead29e92102b8b50db1bca63e4571c30cda9b899fdee8177ed98 573B / 573B                                                                                0.6s
 => => sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1 32B / 32B                                                                                0.5s
 => => extracting sha256:510e151e1774050d5f5bb60a85736a80fa6c006791db5cebe6d506d65dec84a1                                                                                0.1s
 => => extracting sha256:70498b03edf90991b22ce539adf5694ff45163da2c71ec1501e5611fd228913e                                                                                0.1s
 => => extracting sha256:b4a58c1d515ac6de0babaf7b798a89ae1a6707d9b0a70b647b735060b7da96cd                                                                                0.5s
 => => extracting sha256:f5bb1f316352fd460172c7e484e857550bb23940c213e90eeda6853f5c7f80dc                                                                                0.0s
 => => extracting sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1                                                                                0.0s
 => => extracting sha256:8e79f523a11aead29e92102b8b50db1bca63e4571c30cda9b899fdee8177ed98                                                                                0.0s
 => [redis internal] load build context                                                                                0.0s
 => => transferring context: 878B                                                                                0.0s
 => [redis 2/4] WORKDIR /redis                                                                                0.1s
 => [redis 3/4] COPY init.sh ./                                                                                0.0s
 => [redis 4/4] RUN chmod +x init.sh                                                                                0.2s
 => [redis] exporting to image                                                                                0.0s
 => => exporting layers                                                                                0.0s
 => => writing image sha256:2c92f9ca2855eb09cbfdea5edabec9d27a207e0ca51a6d7dd5a51a1263b2e513                                                                                0.0s
 => => naming to docker.io/library/overfast-api-redis                                                                                0.0s
 => [app internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 1.04kB                                                                                0.0s
 => [worker internal] load metadata for docker.io/library/python:3.12-alpine                                                                                1.2s
 => [worker internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 1.04kB                                                                                0.0s
 => [app internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [worker internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [app main  1/10] FROM docker.io/library/python:3.12-alpine@sha256:d24ed567ee3b972478a232ceff84b0d002e18ee9f5d38234ecbffece23dfa084                                                                          1.8s
 => => resolve docker.io/library/python:3.12-alpine@sha256:d24ed567ee3b972478a232ceff84b0d002e18ee9f5d38234ecbffece23dfa084                                                                                0.0s
 => => sha256:d24ed567ee3b972478a232ceff84b0d002e18ee9f5d38234ecbffece23dfa084 1.65kB / 1.65kB                                                                                0.0s
 => => sha256:6714e211c290dc39908616ed0befdcc8f9097b69ee62d17f2f1833d764b93ef0 1.37kB / 1.37kB                                                                                0.0s
 => => sha256:0fe205a492b75b71368b95db211dc148d50240d50752f04b34d1024084561296 6.64kB / 6.64kB                                                                                0.0s
 => => sha256:820650aa2f5b8e795b04058fa617fb87ad3397f0fc2582400f9855b84f2d4401 465.47kB / 465.47kB                                                                                0.4s
 => => sha256:4e0f3549117ae48d35d3cbea60bca5ef0d654723e8065274c93137c3f2b44a60 14.68MB / 14.68MB                                                                                0.4s
 => => sha256:a5b6895e2863b5497adb5d68fe8e5241835c9624c9a31fd2b8532b08da56b638 242B / 242B                                                                                0.1s
 => => sha256:629a421706977cd903f62bb22483a0fa6cba236a94d23543e616bf5c24516467 2.74MB / 2.74MB                                                                                0.5s
 => => extracting sha256:820650aa2f5b8e795b04058fa617fb87ad3397f0fc2582400f9855b84f2d4401                                                                                0.2s
 => => extracting sha256:4e0f3549117ae48d35d3cbea60bca5ef0d654723e8065274c93137c3f2b44a60                                                                                0.8s
 => => extracting sha256:a5b6895e2863b5497adb5d68fe8e5241835c9624c9a31fd2b8532b08da56b638                                                                                0.0s
 => => extracting sha256:629a421706977cd903f62bb22483a0fa6cba236a94d23543e616bf5c24516467                                                                                0.3s
 => [app internal] load build context                                                                                0.1s
 => => transferring context: 10.25MB                                                                                0.1s
 => [worker internal] load build context                                                                                0.1s
 => => transferring context: 10.25MB                                                                                0.1s
 => [app main  2/10] WORKDIR /code                                                                                0.1s
 => [app main  3/10] RUN apk add build-base &&   apk add libffi-dev &&   pip install poetry==1.8.2                                                                                24.3s
 => [app main  4/10] COPY pyproject.toml /code/                                                                                0.0s
 => [app main  5/10] COPY poetry.lock /code/                                                                                0.0s
 => [app main  6/10] RUN poetry config virtualenvs.create false &&  poetry install --only main --no-interaction --no-ansi                                                                                8.7s
 => [app main  7/10] COPY ./app /code/app                                                                                0.0s
 => [worker main  8/10] COPY ./static /code/static                                                                                0.1s
 => [app main  9/10] COPY ./build/overfast-crontab /etc/crontabs/root                                                                                0.0s
 => [app main 10/10] RUN chmod +x /etc/crontabs/root                                                                                0.2s
 => [worker] exporting to image                                                                                1.3s
 => => exporting layers                                                                                1.2s
 => => writing image sha256:097b9c11ac8d43b68212e99b3aaa27c6faaa9496a4a56c2dd17d1e8e7bf5b007                                                                                0.0s
 => => naming to docker.io/library/overfast-api-worker                                                                                0.0s
 => [app] exporting to image                                                                                1.3s
 => => exporting layers                                                                                1.2s
 => => writing image sha256:0d945663dff46a7417e3bee5a459b9bdbe73b8b0bf075392d2382d10e3253569                                                                                0.0s
 => => naming to docker.io/library/overfast-api-app                                                                                0.0s
 => [nginx internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 284B                                                                                0.0s
 => [nginx internal] load metadata for docker.io/library/nginx:1.20.2-alpine                                                                                1.2s
 => [nginx internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [nginx 1/4] FROM docker.io/library/nginx:1.20.2-alpine@sha256:016789c9a2d021b2dcb5e1c724c75ab0a57cc4e8cd7aab7bb28e69fec7c8c4fc                                                                              1.0s
 => => resolve docker.io/library/nginx:1.20.2-alpine@sha256:016789c9a2d021b2dcb5e1c724c75ab0a57cc4e8cd7aab7bb28e69fec7c8c4fc                                                                                0.0s
 => => sha256:455c02918c4592a9beeeae47df541266f3ea53ed573feb767e5e8ab8dcee146e 2.72MB / 2.72MB                                                                                0.2s
 => => sha256:08b6b842dcd703db7772921ad226048f2f8b0bec2e1fcaaa55a59b66c4772db3 7.14MB / 7.14MB                                                                                0.3s
 => => sha256:016789c9a2d021b2dcb5e1c724c75ab0a57cc4e8cd7aab7bb28e69fec7c8c4fc 1.65kB / 1.65kB                                                                                0.0s
 => => sha256:1a946edcecbd2fd3121946a05e978c3a03c5d94c67d2376d3fbb62ed0c470d90 1.57kB / 1.57kB                                                                                0.0s
 => => sha256:d6a1e2ab00f777c5cc735d3a1c78769cea2e2a220511c162907da2c6758e916f 8.76kB / 8.76kB                                                                                0.0s
 => => sha256:d49e54c17cd83bb015a10bea1e05084d9630afc9a4feac1aa3ceb5ae647dd9d8 603B / 603B                                                                                0.4s
 => => extracting sha256:455c02918c4592a9beeeae47df541266f3ea53ed573feb767e5e8ab8dcee146e                                                                                0.1s
 => => sha256:0263029b2ae8863b72df3f821517b4ac5cfaff6cd482cca560636edee07d91a2 894B / 894B                                                                                0.3s
 => => sha256:7a15a92d87b89cf5803fd585091af1cd8ba3216f8bb9639c7e7beb8358f88f4b 664B / 664B                                                                                0.4s
 => => extracting sha256:08b6b842dcd703db7772921ad226048f2f8b0bec2e1fcaaa55a59b66c4772db3                                                                                0.5s
 => => sha256:9fed390110deadba2d9f188f3d75b177f94ceababaf7d603ed64b30ad346ee0d 1.39kB / 1.39kB                                                                                0.5s
 => => extracting sha256:d49e54c17cd83bb015a10bea1e05084d9630afc9a4feac1aa3ceb5ae647dd9d8                                                                                0.0s
 => => extracting sha256:0263029b2ae8863b72df3f821517b4ac5cfaff6cd482cca560636edee07d91a2                                                                                0.0s
 => => extracting sha256:7a15a92d87b89cf5803fd585091af1cd8ba3216f8bb9639c7e7beb8358f88f4b                                                                                0.0s
 => => extracting sha256:9fed390110deadba2d9f188f3d75b177f94ceababaf7d603ed64b30ad346ee0d                                                                                0.0s
 => [nginx internal] load build context                                                                                0.0s
 => => transferring context: 92.88kB                                                                                0.0s
 => [nginx 2/4] COPY nginx.conf /etc/nginx/nginx.conf                                                                                0.0s
 => [nginx 3/4] COPY ngx_http_redis_module.so /usr/lib/nginx/modules/ngx_http_redis_module.so                                                                                0.0s
 => [nginx 4/4] COPY overfast-api.conf /etc/nginx/conf.d/default.conf                                                                                0.0s
 => [nginx] exporting to image                                                                                0.0s
 => => exporting layers                                                                                0.0s
 => => writing image sha256:b17cb20d6e98fc6abf923c2c485464ed198eae699a116e9fdddc583ea98ba96b                                                                                0.0s
 => => naming to docker.io/library/overfast-api-nginx                                                                                0.0s
Stopping OverFastAPI and cleaning containers...
docker compose down -v --remove-orphans
WARN[0000] /home/dev/overfast-api/docker-compose.yml: `version` is obsolete
Launching OverFastAPI (production mode)...
docker compose up -d
WARN[0000] /home/dev/overfast-api/docker-compose.yml: `version` is obsolete
[+] Running 5/5
 ✔ Network overfast-api_default     Created                                                                                0.1s
 ✔ Container overfast-api-redis-1   Healthy                                                                                4.6s
 ✘ Container overfast-api-app-1     Error                                                                                19.6s
 ✔ Container overfast-api-worker-1  Started                                                                                4.1s
 ✔ Container overfast-api-nginx-1   Created                                                                                0.0s
dependency failed to start: container overfast-api-app-1 is unhealthy
make: *** [Makefile:65: up] Error 1

Expected behavior
overfast-api runs well
Screenshots
Additional context
my server specs:

and docker version:

@itzdrli Found an issue with healthcheck since Docker update on my server, updating ⌛

I fixed the issue on my side, let me know if it solved it for you 👍

@TeKrop I have done the whole thing again and still errored, here is the full log
root@itzdrli-dev-armv8:/home/dev# git clone https://github.com/TeKrop/overfast-api
Cloning into 'overfast-api'...
remote: Enumerating objects: 2792, done.
remote: Counting objects: 100% (776/776), done.
remote: Compressing objects: 100% (391/391), done.
remote: Total 2792 (delta 586), reused 406 (delta 385), pack-reused 2016
Receiving objects: 100% (2792/2792), 14.24 MiB | 21.96 MiB/s, done.
Resolving deltas: 100% (1963/1963), done.
root@itzdrli-dev-armv8:/home/dev# cd overfast-api/
root@itzdrli-dev-armv8:/home/dev/overfast-api# make up
Building OverFastAPI (production mode)...
docker compose build
WARN[0000] The "APP_VOLUME_PATH" variable is not set. Defaulting to a blank string.
WARN[0000] The "APP_PORT" variable is not set. Defaulting to a blank string.
[+] Building 42.0s (22/33)                                                                                docker:default
 => [redis internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 109B                                                                                0.0s
 => [redis internal] load metadata for docker.io/library/redis:alpine                                                                                0.8s
 => [redis internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [redis 1/4] FROM docker.io/library/redis:alpine@sha256:0389bb8416d7c6ed065c25745179bf5d358e5d9472dd30a687ab36ffbb650262                                                                                0.0s
 => [redis internal] load build context                                                                                0.0s
 => => transferring context: 878B                                                                                0.0s
 => CACHED [redis 2/4] WORKDIR /redis                                                                                0.0s
 => CACHED [redis 3/4] COPY init.sh ./                                                                                0.0s
 => CACHED [redis 4/4] RUN chmod +x init.sh                                                                                0.0s
 => [redis] exporting to image                                                                                0.0s
 => => exporting layers                                                                                0.0s
 => => writing image sha256:2c92f9ca2855eb09cbfdea5edabec9d27a207e0ca51a6d7dd5a51a1263b2e513                                                                                0.0s
 => => naming to docker.io/library/overfast-api-redis                                                                                0.0s
 => [worker internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 1.04kB                                                                                0.0s
 => [app internal] load metadata for docker.io/library/python:3.12-alpine                                                                                0.7s
 => [app internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 1.04kB                                                                                0.0s
 => [app internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [worker internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [worker main  1/10] FROM docker.io/library/python:3.12-alpine@sha256:d24ed567ee3b972478a232ceff84b0d002e18ee9f5d38234ecbffece23dfa084                                                                       0.0s
 => [app internal] load build context                                                                                0.1s
 => => transferring context: 10.25MB                                                                                0.1s
 => [worker internal] load build context                                                                                0.1s
 => => transferring context: 10.25MB                                                                                0.1s
 => CACHED [worker main  2/10] WORKDIR /code                                                                                0.0s
 => CACHED [worker main  3/10] RUN apk add build-base &&   apk add libffi-dev &&   pip install poetry==1.8.2                                                                                0.0s
 => [app main  4/10] COPY pyproject.toml /code/                                                                                0.1s
 => [worker main  5/10] COPY poetry.lock /code/                                                                                0.0s
 => ERROR [app main  6/10] RUN poetry config virtualenvs.create false &&  poetry install --only main --no-interaction --no-ansi                                                                                40.2s
------
 > [app main  6/10] RUN poetry config virtualenvs.create false &&       poetry install --only main --no-interaction --no-ansi:
1.580 Skipping virtualenv creation, as specified in config file.
1.881 Installing dependencies from lock file
2.118
2.118 Package operations: 41 installs, 1 update, 0 removals
2.118
2.118   - Installing mdurl (0.1.2)
2.119   - Installing sniffio (1.3.1)
39.88
39.88   gaierror
39.88
39.88   [Errno -3] Try again
39.88
39.88   at /usr/local/lib/python3.12/socket.py:964 in getaddrinfo
39.90       960│     """
39.90       961│     # We override this function since we want to translate the numeric family
39.90       962│     # and socket type values to enum constants.
39.90       963│     addrlist = []
39.90     → 964│     for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
39.90       965│         af, socktype, proto, canonname, sa = res
39.90       966│         addrlist.append((_intenum_converter(af, AddressFamily),
39.90       967│                          _intenum_converter(socktype, SocketKind),
39.90       968│                          proto, canonname, sa))
39.90
39.90 The following error occurred when trying to handle this error:
39.90
39.90
39.90   NameResolutionError
39.90
39.90   <urllib3.connection.HTTPSConnection object at 0xffff8c0d8950>: Failed to resolve 'pypi.org' ([Errno -3] Try again)
39.90
39.90   at /usr/local/lib/python3.12/site-packages/urllib3/connection.py:205 in _new_conn
39.91       201│                 source_address=self.source_address,
39.91       202│                 socket_options=self.socket_options,
39.91       203│             )
39.91       204│         except socket.gaierror as e:
39.91     → 205│             raise NameResolutionError(self.host, self, e) from e
39.91       206│         except SocketTimeout as e:
39.91       207│             raise ConnectTimeoutError(
39.91       208│                 self,
39.91       209│                 f"Connection to {self.host} timed out. (connect timeout={self.timeout})",
39.91
39.91 The following error occurred when trying to handle this error:
39.91
39.91
39.91   MaxRetryError
39.91
39.91   HTTPSConnectionPool(host='pypi.org', port=443): Max retries exceeded with url: /pypi/mdurl/0.1.2/json (Caused by NameResolutionError("<urllib3.connection.HTTPSConnection object at 0xffff8c0d8950>: Failed to resolve 'pypi.org' ([Errno -3] Try again)"))
39.91
39.91   at /usr/local/lib/python3.12/site-packages/urllib3/util/retry.py:515 in increment
39.92       511│         )
39.92       512│
39.92       513│         if new_retry.is_exhausted():
39.92       514│             reason = error or ResponseError(cause)
39.92     → 515│             raise MaxRetryError(_pool, url, reason) from reason  # type: ignore[arg-type]
39.92       516│
39.92       517│         log.debug("Incremented Retry for (url='%s'): %r", url, new_retry)
39.92       518│
39.92       519│         return new_retry
39.92
39.92 The following error occurred when trying to handle this error:
39.92
39.92
39.92   ConnectionError
39.92
39.92   HTTPSConnectionPool(host='pypi.org', port=443): Max retries exceeded with url: /pypi/mdurl/0.1.2/json (Caused by NameResolutionError("<urllib3.connection.HTTPSConnection object at 0xffff8c0d8950>: Failed to resolve 'pypi.org' ([Errno -3] Try again)"))
39.92
39.92   at /usr/local/lib/python3.12/site-packages/requests/adapters.py:700 in send
39.93       696│             if isinstance(e.reason, _SSLError):
39.93       697│                 # This branch is for urllib3 v1.22 and later.
39.93       698│                 raise SSLError(e, request=request)
39.93       699│
39.93     → 700│             raise ConnectionError(e, request=request)
39.93       701│
39.93       702│         except ClosedPoolError as e:
39.93       703│             raise ConnectionError(e, request=request)
39.93       704│
39.93
39.93 Cannot install mdurl.
39.93
39.93
39.93   gaierror
39.93
39.93   [Errno -3] Try again
39.93
39.93   at /usr/local/lib/python3.12/socket.py:964 in getaddrinfo
39.95       960│     """
39.95       961│     # We override this function since we want to translate the numeric family
39.95       962│     # and socket type values to enum constants.
39.95       963│     addrlist = []
39.95     → 964│     for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
39.95       965│         af, socktype, proto, canonname, sa = res
39.95       966│         addrlist.append((_intenum_converter(af, AddressFamily),
39.95       967│                          _intenum_converter(socktype, SocketKind),
39.95       968│                          proto, canonname, sa))
39.95
39.95 The following error occurred when trying to handle this error:
39.95
39.95
39.95   NameResolutionError
39.95
39.95   <urllib3.connection.HTTPSConnection object at 0xffff8c0d8590>: Failed to resolve 'pypi.org' ([Errno -3] Try again)
39.95
39.95   at /usr/local/lib/python3.12/site-packages/urllib3/connection.py:205 in _new_conn
39.96       201│                 source_address=self.source_address,
39.96       202│                 socket_options=self.socket_options,
39.96       203│             )
39.96       204│         except socket.gaierror as e:
39.96     → 205│             raise NameResolutionError(self.host, self, e) from e
39.96       206│         except SocketTimeout as e:
39.97       207│             raise ConnectTimeoutError(
39.97       208│                 self,
39.97       209│                 f"Connection to {self.host} timed out. (connect timeout={self.timeout})",
39.97
39.97 The following error occurred when trying to handle this error:
39.97
39.97
39.97   MaxRetryError
39.97
39.97   HTTPSConnectionPool(host='pypi.org', port=443): Max retries exceeded with url: /pypi/sniffio/1.3.1/json (Caused by NameResolutionError("<urllib3.connection.HTTPSConnection object at 0xffff8c0d8590>: Failed to resolve 'pypi.org' ([Errno -3] Try again)"))
39.97
39.97   at /usr/local/lib/python3.12/site-packages/urllib3/util/retry.py:515 in increment
39.97       511│         )
39.97       512│
39.97       513│         if new_retry.is_exhausted():
39.97       514│             reason = error or ResponseError(cause)
39.97     → 515│             raise MaxRetryError(_pool, url, reason) from reason  # type: ignore[arg-type]
39.97       516│
39.97       517│         log.debug("Incremented Retry for (url='%s'): %r", url, new_retry)
39.97       518│
39.97       519│         return new_retry
39.97
39.97 The following error occurred when trying to handle this error:
39.97
39.97
39.97   ConnectionError
39.97
39.97   HTTPSConnectionPool(host='pypi.org', port=443): Max retries exceeded with url: /pypi/sniffio/1.3.1/json (Caused by NameResolutionError("<urllib3.connection.HTTPSConnection object at 0xffff8c0d8590>: Failed to resolve 'pypi.org' ([Errno -3] Try again)"))
39.97
39.97   at /usr/local/lib/python3.12/site-packages/requests/adapters.py:700 in send
39.98       696│             if isinstance(e.reason, _SSLError):
39.98       697│                 # This branch is for urllib3 v1.22 and later.
39.98       698│                 raise SSLError(e, request=request)
39.98       699│
39.98     → 700│             raise ConnectionError(e, request=request)
39.98       701│
39.98       702│         except ClosedPoolError as e:
39.98       703│             raise ConnectionError(e, request=request)
39.98       704│
39.98
39.98 Cannot install sniffio.
39.98
------
failed to solve: process "/bin/sh -c poetry config virtualenvs.create false && \tpoetry install --only main --no-interaction --no-ansi" did not complete successfully: exit code: 1
make: *** [Makefile:61: up] Error 17

It seems you had a ponctual DNS issue with pypi.org (where python packages are downloaded), so it failed before the healthcheck. Can you retry now and tell me if it's still the case?

Can you retry now and tell me if it's still the case?

yes, I have retried and still the same, but when I do ping pypi.org, it shows fine (maybe?

Hmm that's weird 🤔 Can you try to clean Docker cache before build? I'm usually doing make clean for that. Be careful as it will do a general cleaning, not only the images and layers concerning the API
docker image prune -af
docker network prune -f

Thanks, I'll try that later when I'm free.
Another working theory is that my docker has some DNS related issues. Bcz another container of mine has the same issue, so I'll try to fix it by both way.

From: Valentin Porchet @.>
Sent: Tuesday, June 11, 2024 9:16:12 AM
To: TeKrop/overfast-api @.>
Cc: Itz_Dr_Li @.>; Mention @.>
Subject: Re: [TeKrop/overfast-api] Error while trying to start overfast-api (Issue #130)
Hmm that's weird 🤔 Can you try to clean Docker cache before build? I'm usually doing make clean for that. Be careful as it will do a general cleaning, not only the images and layers concerning the API
docker image prune -af
docker network prune -f
—
Reply to this email directly, view it on GitHubhttps://github.com/TeKrop/overfast-api/issues/130#issuecomment-2160083414, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AMPKALDFIFWYCLSD3O3JSQTZG2W4ZAVCNFSM6AAAAABJA2ANEGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRQGA4DGNBRGQ.
You are receiving this because you were mentioned.Message ID: @.***>

@itzdrli OK 👍 Don't hesitate to give me an update when you'll have some news, in order to know if the healthcheck issue is solved for you

@TeKrop hey, the issue up there is solved by changing DNS server, but now another issue came up:
after I created a new instance (removed all old containers) then I cloned the repo and edited .env, then I did make up, everything seems fine:

then I checked my docker panel and it showed like this:

so I went to see the log of  overfast-api-nginx-1:
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration

/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/

/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh

10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf

10-listen-on-ipv6-by-default.sh: info: /etc/nginx/conf.d/default.conf differs from the packaged version

/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh

/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh

/docker-entrypoint.sh: Configuration complete; ready for start up

2024/06/11 17:33:38 [emerg] 1#1: dlopen() "/usr/lib/nginx/modules/ngx_http_redis_module.so" failed (Error relocating /usr/lib/nginx/modules/ngx_http_redis_module.so: unsupported relocation type 7) in /etc/nginx/nginx.conf:7

nginx: [emerg] dlopen() "/usr/lib/nginx/modules/ngx_http_redis_module.so" failed (Error relocating /usr/lib/nginx/modules/ngx_http_redis_module.so: unsupported relocation type 7) in /etc/nginx/nginx.conf:7

any idea how this happend?

@itzdrli I just noticed you're using ARM-based environment, and I didn't test the API on this kind of environment 😅
The ngx_http_redis.so nginx module I'm using in the project has only been compiled once for the project, and it may explain the issue you're encountering.
I'm currently working on dynamically compiling it on image build instead, I hope it will solve your issue, I'll keep you updated 👍

@itzdrli I made the update in the last release, let me know if it works better on your end now

@TeKrop everything is running now, and they are working fine! Thank you for all the help!


A field that resolves to undefined is not present in response

If a resolver resolves undefined, the corresponding field is not present in the results' data, whereas according to specs the corresponding field should be null:

If result is null (or another internal value similar to null such as undefined or NaN), return null.

const resolvers = {
  Query : {
    foo: () => of(undefined),
    bar: () => of('bar')
  }
};
const res = await graphql(gql`{foo, bar}`, schema).toPromise();
// actual: res = { data : { bar: 'bar'}};
// expect: res = { data : { bar: 'bar', foo: null}};

Made me run into compatibility issues such as https://github.com/apollographql/apollo-client/issues/4267

:tada: This issue has been resolved in version 3.0.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


X11 login loop after update to F41

Describe the bug
After running ujust update and upgrading to F41 (branch stable-daily), I can't use X11.
I have installed the package gnome-session-xsession to be able to run a X11 session.
After rebooting and trying to log in to the X11 session, it just brings me back to the locked screen and loops like that.
I checked $USER/.local/share/xorg/Xorg.0.log, and the first issue seems to be this line:
Failed to load module "nouveau" (module does not exist, 0)
After which it tries to load fbdev and vesa with the same results.
The final error message is: (EE) failed to create screen resources(EE)
Since Bluefin uses the proprietary NVIDIA driver, I assume Nouveau isn't installed and X11 isn't looking for the proprietary one.
The same problem happens on my ASUS laptop running the latest branch, so I assume I'm not the only one with this problem.
Suggestions and help would be greatly appreciated! 😊
What did you expect to happen?
To be able to log into an X11 session.
Output of rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:stable-daily
                   Digest: sha256:809a8d2f1a15261e769476643c02027ec253a50570b4dfd7e14c87efd48a6407
                  Version: 41.20241113 (2024-11-13T06:12:52Z)
          LayeredPackages: gnome-session-xsession gnome-shell-extension-pop-shell

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:stable-daily
                   Digest: sha256:809a8d2f1a15261e769476643c02027ec253a50570b4dfd7e14c87efd48a6407
                  Version: 41.20241113 (2024-11-13T06:12:52Z)
          LayeredPackages: gnome-shell-extension-pop-shell

Output of groups
axelkaliff wheel docker incus-admin lxd libvirt

Extra information or context
No response

X11 isnt supported by Fedora anymore (and ideally not by us anymore either). Try removing the kargs that disable nouveau with rpm-ostree kargs --editor.


v3.2.3 fails to install

pip install pyquest-cffi==3.2.3 fails (on Linux) with the message:
    CMake suite maintained and supported by Kitware (kitware.com/cmake).
    __file__ /tmp/pip-install-zdnpfpa9/pyquest-cffi/setup.py
    src_path /tmp/pip-install-zdnpfpa9/pyquest-cffi
    CMake Error: The current CMakeCache.txt directory /tmp/pip-install-zdnpfpa9/pyquest-cffi/pyquest_cffi/questlib/CMakeCache.txt is different than the directory /home/nvogt/vanilla/HQS_pyquest/pyquest_cffi/questlib where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt
    CMake Error: The source "/tmp/pip-install-zdnpfpa9/pyquest-cffi/QuEST/QuEST/CMakeLists.txt" does not match the source "/home/nvogt/vanilla/HQS_pyquest/QuEST/QuEST/CMakeLists.txt" used to generate cache.  Re-run cmake with a different source directory.

v3.2.2 installs fine.

Thank you for reporting!
CMake failed due to old CMake cache when building the sdist distribution.
This should be fixed now in <IP_ADDRESS>

Yes, fixed!
Thanks!


Increment library version to 0.7.4 & utils to 0.7.1

Pull Request Test Coverage Report for Build 1400

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.08%) to 38.14%

Totals

Change from base Build 1398:
0.08%

Covered Lines:
1833

Relevant Lines:
4806

💛  - Coveralls


You have to click twice on an action to delete (using keyboard)

Describe the Bug with repro steps
Simple repro
What type of Logic App Is this happening in?
Consumption (Portal)
Are you using new designer or old designer
New Designer
Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg
Yes
Workflow JSON
No response
Screenshots or Videos
No response
Browser
Chrome
Additional context
No response
AB#25598018

I get that this is a simple repro but @kisubedi for issues you open, please fill out the form completely with repro steps and video of the issue. It does make things easier for us.

Unable to reproduce this on standalone/portal on LogicApps

@kisubedi I also don't really understand this one. Please provide more information. I'm marking this as needs more info so it'll auto close in 14-21 days otherwise.


Make helmfile respect signals send by kill command (not only Ctrl+C in terminal)

/fix #746

As far as I understand the signal handling code (https://github.com/helmfile/helmfile/blob/main/main.go#L29-L40) should live in lambda function (https://github.com/helmfile/helmfile/blob/main/main.go#L20-L22) to be able to be handled immediately.
In my experiment moving mentioned logic to lambda and adding debug print I ensured, that signal is handled immediately (even when it's send by kill).
Unfortunately I don't understand how CleanWaitGroup supposed to work. So my change just hangs up on CleanWaitGroup and waits until successful end of apply (not propagates a signal to child processes)

I tried to just drop CleanWaitGroup.Wait() and all works as I expect, except cleaning temporary files.

@yxxhero Can you please take a look? So far I have no idea how to better exec cleanup from lambda/propograte cancel context.
Maybe you can point me to the right direction, please?

@dm3ch please fix ci issue.

@dm3ch you can use golangci-lint as your lint tool. it will help you automatically check lint errors.

@dm3ch please fix ci issue.

It seems that now tests and lint should be fixed.
But I'm not sure that it's effective to fix tests and lint when code changes itself are awful themselves. :)

When test is ok. We will review the code.

Missed some of failed, would try to fix

@yxxhero Fixed race condition, can you please run tests one more time?

@yxxhero Fixed race condition, can you please run tests one more time?

sure.

@dm3ch is it ready to review?

@dm3ch is it ready to review?

Yes

@dm3ch Hey! Thanks a lot for your contribution. This looks good so far. A quick confirmation though- is this supposed to fix the issue by letting helmfile explicitly cancel the running commands (like helm) on SIGTERM/SIGINT?
I presume Ctrl-C worked just because it sends SIGINT to both the helmfile and its child processes, whereas kill -SIGINT just sends it to the helmfile process so helmfile needs to cancel/wait for children depending on the situation.
Is my understanding correct? I'd really appreciate it if you could correct any details/mistakes in my understanding because I'd like to be 100% sure this doesn't break anything/does fix the issue! Thanks.

@mumoshu good question.

@mumoshu After some time of researching this phenomenon I also resulted in theory that bash is sending SIGINT to both parent and child process (process group).
So If I right understand before this change sig handling in helmfile wasn't the thing that actually triggered exit. The exit was the result of helm exit with != 0 exit code.
With my changes exit is also triggered by helm exit code != 0, but I pass SIGINT to the helm process in case helmfile received SIGINT.

LGTM

@dm3ch could you help me to test?

@dm3ch could you help me to test?

Tested, works fine in my case, temp files were cleaned properly

@dm3ch Thanks for your feedback.

@yxxhero I have resolved conflicts. Can you please approve CI?

BTW, what we are waiting for? Are we waiting a review from other maintainers?

I don't understand what's wrong with integration tests:

One of jobs seems to have timeout to github API
Another job, I don't understand at all what's wrong.

I would be glad if someone would point me what's wrong

rerun

@mumoshu WDYT about new changes?


Player primary rank removed

I own a prison server and there appears to be a rank glitch where i remove their world specific rank and give them their new rank using the world selector
Once i do this/this happens, their primary/non-world specific rank dissapears/get removed from the rank.
Its only fixed when i give them their primary rank back.
This is a huge problem as i cant constantly give people their primary rank back once they become removed from it upon the world specific rankup.

Can you give me a specific example with a specific user, specific groups to which they are a member, and the exact commands being used in the order they are being used?

for example
FireyJelly apart of group Default, and in a world specific group called PrisonD4
when they go to rankup to PrisonD3
it executes /pex user FireyJelly group remove PrisonD4 Prison
and then it executes /pex user FireyJelly group add PrisonD3 Prison
to remove them from that group in the world 'Prison' and add the new rank in the same world 'Prison'
once this occures, FireyJelly is then removed from group Default aswell
Thereby leaving him only in PrisonD3 in Prison
but removed from group Default in all worlds
(The order the commands were used are the correct and exact order they are being used)

it executes /pex user FireyJelly group remove PrisonD4 Prison

What exactly is "it"?  PEX has no automated tasks at all.
Which exact permission node in the "Default" group is "FireJelly" no longer able to access after being removed from "PrisonD4"?
Why are these groups not inheriting the "Default" groups permissions?

It refers to the server, or rather upon a signclick (via ServerSigns) that removes them from PrisonD4 and adds them to PrisonD3
The adding to PrisonD3 is delayed as to not execute first
FireyJelly becomes completly removed from the group upon an inspection via /Pex user FireyJelly
this is also visualy indicated from the lack of all chat/username formating that the group designates to FireyJelly or all users under that group for that matter
And that's because when I do this it removes the Prison rank's suffix, and also, if FireyJelly were of a donor or other rank on the Default ladder and this occurred, I wouldnt be able to have the Prison ranks inheriting from those other ranks on the Default ladder as it would give Default ranked players donor/higher ranked permissions
(Keep in mind that I used FireyJelly as a basic example of the problem, but this happens with everyone on any group of the Default ladder, but is only fixed once I re-add them back to their primary/default ladder'd group)

You didn't show me your permissions.yml file.  I cannot magically summon your server hierarchy into my own brain.  Show me the file.  :P

/Pex user FireyJelly

PEX typically will not display whichever group is default; true.  PEX knows that a user with no group listed is in the default: true group.
Without a specific missing permission node, I can't verify that the user is actually removed from the default; true group.
The "PrisonD4" suffix should be removed from someone who is no longer in that group.
It sounds to me like ServerSigns is not executing the correct commands to change user groups.

i have a strong feeling that the problem is a lack in understanding the issue
ill try bPermissions but ty for whatever u do

Yeah, that happens when someone says "I need help with X" and they refuse to show you their information— as if their server setup was the only one of its kind in the entire history of Minecraft's 50 million servers.
*nod nod*


Bounty: Test Bounty

Reward Size in USD
10 USD
Bounty
Add new feature
Acceptance Criteria

sign up mintycode.io

Go to Mintycode to approve the Bounty.

Hi, Can I work on this bounty?


[WIP] Add a CMakeLists.txt

Make comments, test.
I like if we can make the all in one header with cmake.

This really needs to use some loops and separate lists. This is a great first attempt but the nightmare of maintenance this style creates is problematic.
Since all the examples and tests have the same compiler options, you can create a LIST and iterate over the list to define all of the targets instead of doing each on its own line.

Not only loops, but you can use some general file(GLOB... to create the lists. Also consider source_group so the generated projects are properly organized for msvc. Additionally the compiler flags should match the settings of the current Ninja build. Finally it should probably find and link to whatever Lua version you choose via cmake options.

@alkino check out the work I started about a year ago here: 1a381ae4a1e5bbf0305028fbe76730d5114303c9.
It's quite a bit more organized, I don't mean to deter you from contributing. :)

I'm not an expert of cmake. I did it only because @ThePhD thinks it was useful. Don't be shy to promote your work or modify my patch.

That is much better! I'll look a bit more, now.

Can we build against the seperate sol source files, and run 'single.py' in the cmake build? Otherwise editing sol with tools like clion won't work properly.
@Nava2 which tools actually don't support globbing of cmake files? without globbing, it's just a hassle whenever you add or remove any files to the project

@mrgreywater, tools that don't use the CMake daemon can't have it work. Clion is nice enough to use it. KDevelop and QtCreator couldn't last I checked.

@Nada2 I tested both Kdevelop and QtCreator and they both worked fine with file(GLOB. So unless there is some other important IDE that for some reason is incompatible, I don't see why this should feature should be disregarded.
file(GLOB EXAMPLES_SRC ./examples/*.cpp)
file(GLOB TEST_SRC ./test_*.cpp ./test_*.hpp ./tests.cpp)

First, thanks mrgreywater for all this comments. I fix some of them.
For LuaJIT, there is no findLuajit. I add https://gitlab.kitware.com/cmake/cmake/issues/17204
Maybe we could do this ourself.
About globbing I don't really care. What is the consensus?
About single.py, I add it but it's not "automatic". I need to do "make single_sol && make install". Do you have any idea to generate it when doing "make install" or "make" alone.
About IDE and OS, I use only linux with vim. I have no access to other.

@alkino There are cmake modules like these: https://github.com/cactus/cronkite/blob/master/cmake/modules/FindLuaJIT.cmake which can find LuaJIT. Imo it would make sense to use something like that.
For the globbing, let's wait for @ThePhD @Nava2 to comment on that again.
With the single/sol/sol.hpp automatic command I don't really know. I would have to fiddle with that myself to try if it's possible.
I can test on different OS's (except Mac). I can try on all platforms before merging, it's just that cmake often needs some minor tweaking for each platform/compiler. e.g find_package probably won't really work on windows, so we need some other way to manually supply the desired lua path.

I have a FindLuaJIT and FindLua module that works cross-platform. I'll donate those to the project. If globbing works now, I see no concern @mrgreywater!

So, if we disable tests and examples, single.py is not run. And we install an old sol.hpp.
And do you want sol.hpp installed on system in "include/sol/sol.hpp" or "include/sol.hpp"?

For the install target, only enable it if python 3 is found and the single header can be generated.
Additionally, I'd not install sources into include/ but into /usr/src (/src on windows). See http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRSRCSOURCECODE

I think we should close this PR and start a new. It's gotten rather convoluted now and we are getting to a point that its not a WIP anymore, but nearing merge quality!

He can just squash everything, no need to create a new PR oO

tests are now in a subfolder.
@alkino can you fix the remaining issues and maybe squash the commits?

Done.
I think we should squash and merge it. (it's possible with github). Be careful to change the name of the commit and not of the ticket.

I haven't forgot about this, I've just been trying to manage everything else!
Thanks for the hard work on this. Once I integrate it I'll finally be able to set up all the tests.

I have changes to how the Lua configs work from the upstream requests. I'll add those in later, though. LGTM, assuming @mrgreywater agrees.

There still needs to be single vs. source-tree targets created. The examples should be built with the single header, the tests should be built against both (and tested).


Create 2022_09_08_LetItBeKnown.tweet

Please ensure the filename is correctly formatted, i.e. 2022_09_08...

Fixed @IstoraMandiri

The line breaks here are weird, shouldn't it be one line?
In any case, i'll merge this to see what happens!

Yes, as anticipated, the line breaks in this PR didn't render as intended on twitter.
Good one to note for future reviews, and style guides.
https://twitter.com/ETC_Network/status/1568091745249886208


Preview pose estimate

Instead of sending directly a pose estimate, the user must now confirm
with Enter (or undo with Esc)
Closes #8

I tested it a little on a stage simulation. setting the pose estimate on an idle robot seems intuitive enough, also didn't have have a problem with huge offsets, so we can skip the ghost laser. The step size is still not intuitive though, but that shouldn't be part of this pr.
I noticed one problem: I don't seem to be able to reset the ghost once the robot drives away from it. I would expect the ghost to go back to the robot once esc is hit

The ghost not moving when the robot moves is sort of intended: the ghost should NOT move when the robot moves, BUT since atm we don't have a separate mode for sending a pose it looks super ugly if the robot starts moving and a ghost stays... Will try to think about a solution

The ghost not moving when the robot moves is sort of intended: the ghost should NOT move when the robot moves, BUT since atm we don't have a separate mode for sending a pose it looks super ugly if the robot starts moving and a ghost stays... Will try to think about a solution

I fixed everything except Maxi's comment about leaving the logic in app. That would require moving the publisher inside the app. Let me know if I should do it in this PR or in a new one

Ok maybe you can make a greater or equal for the nalgebra version :) splititng the pose eestimate can be done in another PR

Cargo should do that automatically for  to some degree:
https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html


divulsing, epitheca

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.2
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 120
deps=[d,e]

/trunk merge


Widgets don’t fit for incorrect height

All of the widgets seem to not fit in the box and overflow out for different window sizes, especially if it's smaller.
Way to recreate the bug:

Open the widget
Scale the window sizes

Possible solution:

Fix the CSS such that everything inside of the widget-popout boxes are scaled from it.

Done and fixed by Min, 06/06/24


Open source and libre fonts we can recommend

This is a draft for a future implementers’ doc. Please feel free to review the recommendations.
While we recommend using system fonts to get the best performance whenever possible, implementers might want to use Open Source Fonts in order to provide users with more choice. On the Android platform, for instance, system fonts are limited to one typeface per family, which means you don’t get a lot of options out of the box.
Consequently, amongst the thousands of fonts available online, a pre-selection of 26 have been reviewed in details. Those typefaces were selected based on multiple factors:

they have enough styles (4: regular, italic, bold, bold italic) and don’t break authors’ expectations;
they can be used in body copy;
they are of good quality and were designed with screen rendering in mind;
they can be free alternatives to system fonts available on other platforms;
they offer good-enough support for at least latin languages.

Here’s the complete list of those 27 fonts:

IBM Plex Sans
IBM Plex Serif
Crimson Text
Spectral
Vollkorn
Lora
Gandhi Sans
Gandhi Serif
Gentium Book Basic
PT Sans
PT Serif
Merriweather Sans
Merriweather Serif
Alegreya
Heuristica
Bitter
Charis SIL
Faustina
Volkhov
Libre Franklin
DejaVu Sans
Rubik
Source Sans Pro
Fira Sans
Proza Libre
Rosario
Clear Sans

How were those fonts reviewed
Each of the 27 fonts has been undergoing tests in real rendering situations.
They were rendered on the Android, iOS, MacOS, and Windows platforms, using SD and HD displays when possible, in multiple browsers (IE11, Edge, Safari, Chrome, Firefox).
Then each font was:

compared to its closest reference (system font);
tested against the latin, cyrillic and greek languages;
tested against the small capitals and numeric OpenType features.

Note: For some reason, a lot of Google Fonts don’t have the “™” character so you’d better fine-tune your font-stacks.
Results
It is important to state that you can’t really go wrong with those fonts. We simply decided to go with fonts providing the best rendering in the worst situation possible (Windows ClearType on a mediocre screen), and the best language support as well. If you don’t have to support Windows, for instance, then you can try fonts we don’t recommend.
We sometimes forget that users can’t necessarily afford bleeding-edge technology, which is why it was important to review those fonts in various conditions.
For your information, here are the results for Windows ClearType rendering at 1em (or 100%).
Buggy

IBM Plex Sans (will become excellent once hinting issues are fixed)

Mediocre

Alegreya
Crimson Text (supports latin + cyrillic + greek though)
Lora
Spectral (maybe try using medium instead of regular on Windows)

Average

Gentium Book Basic
Heuristica
Volkhov
DejaVu Sans
Faustina (Average+)

Good

Vollkorn
PT Serif
Bitter (the Google Fonts version was reviewed but the FontSquirrel version is more complete)
Charis SIL
Rubik
Source Sans Pro
PT Sans
Gandhi Serif

Excellent

IMB Plex Serif
Merriweather Sans
Merriweather
Gandhi Sans
Fira Sans
Proza Libre
Rosario
Clear Sans

Recommended Typefaces
Twelve typefaces are recommended so that implementers can pick a few among this extended selection.
Note: Supported Languages focus on diacritics. Support for latin languages like English, which are not using diacritics, is implied.
Serif fonts
Charis SIL

Source: https://software.sil.org/charis/
Google Fonts: NO
Design: SIL International
License: SIL-OFL

Reference: Charter
Classification: Slab
Styles: 4
Metrics:

Contrast: TBD
x-height: TBD
weight: TBD
width: TBD

Supported Languages: Albanian, Bosnian, Czech, Danish, Dutch, Estonian, Finnish, French, German, Hungarian, Italian, Latvian, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish, Swedish, Turkish, Cyrillic.
OpenType Features: none
Faustina

Source: https://github.com/Omnibus-Type/Faustina
Google Fonts: YES
Design: Omnibus Type
License: SIL-OFL

Reference: Charter, Bookerly
Classification: Slab
Styles: 8
Metrics:

Contrast: 0.39
x-height: 0.76
weight: 0.06
width: 0.45

Supported Languages: Albanian, Bosnian, Czech, Danish, Dutch, Estonian, Finnish, French, German, Hungarian, Italian, Latvian, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish, Swedish, Turkish.
OpenType Features: none
IBM Plex Serif

Source: https://github.com/IBM/type
Google Fonts: NO
Design: IBM
License: SIL-OFL

Reference: Georgia, Droid Serif
Classification: Modern
Styles: 6
Metrics:

Contrast: TBD
x-height: TBD
weight: TBD
width: TBD

Supported Languages: Albanian, Bosnian, Czech, Danish, Dutch, Estonian, Finnish, French, German, Hungarian, Italian, Latvian, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish, Swedish, Turkish.
OpenType Features: none
Merriweather

Source: https://fonts.google.com/specimen/Merriweather
Google Fonts: YES
Design: Sorkin Type Co
License: SIL-OFL

Reference: Iowan Old Style
Classification: Modern
Styles: 8
Metrics:

Contrast: 0.51
x-height: 0.75
weight: 0.08
width: 0.52

Supported Languages: Albanian, Bosnian, Czech, Danish, Dutch, Estonian, Finnish, French, German, Hungarian, Italian, Latvian, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish, Swedish, Turkish, Cyrillic.
OpenType Features: none
PT Serif

Source: https://fonts.google.com/specimen/PT+Serif
Google Fonts: YES
Design: ParaType
License: Paratype PT Serif Free Font License

Reference: Charter
Classification: Slab
Styles: 4 (+ 2 for captions)
Metrics:

Contrast: 0.55
x-height: 0.71
weight: 0.06
width: 0.47

Supported Languages: Albanian, Bosnian, Czech, Danish, Dutch, Estonian, Finnish, French, German, Hungarian, Italian, Latvian, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish, Swedish, Turkish, Cyrillic.
OpenType Features: none
Vollkorn

Source: http://vollkorn-typeface.com
Google Fonts: YES
Design: Friedrich Althausen
License: SIL-OFL

Reference: Athelas, Bembo
Classification: Modern
Styles: 8
Metrics:

Contrast: 0.53
x-height: 0.68
weight: 0.06
width: 0.45

Supported Languages: Albanian, Bosnian, Czech, Danish, Dutch, Estonian, Finnish, French, German, Hungarian, Italian, Latvian, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish, Swedish, Turkish, Cyrillic
OpenType Features: small caps, numeric figure values, numeric spacing values (and more)
Sans-serif fonts
Clear Sans

Source: https://01.org/clear-SANS
Google Fonts: NO
Design: Intel
License: Apache 2.0

Reference: Trebuchet MS
Classification: Sans
Styles: 8
Metrics:

Contrast: TBD
x-height: TBD
weight: TBD
width: TBD

Supported Languages: Albanian, Bosnian, Czech, Danish, Dutch, Estonian, Finnish, French, German, Hungarian, Italian, Latvian, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish, Swedish, Turkish, Cyrillic, Greek.
OpenType Features: none
Fira Sans

Source: https://github.com/mozilla/Fira
Google Fonts: YES
Design: Carrois Apostrophe for Mozilla
License: SIL-OFL

Reference: Seravek
Classification: Humanist
Styles: 18
Metrics:

Contrast: 0.25
x-height: 0.76
weight: 0.07
width: 0.42

Supported Languages: Albanian, Bosnian, Czech, Danish, Dutch, Estonian, Finnish, French, German, Hungarian, Italian, Latvian, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish, Swedish, Turkish, Cyrillic, Greek.
OpenType Features: none
Libre Franklin

Source: https://github.com/impallari/Libre-Franklin
Google Fonts: YES
Design: Impallari Type
License: SIL-OFL

Reference: Arial, Helvetica, San Fransisco, Franklin Gothic
Classification: Sans
Styles: 18
Metrics:

Contrast: 0.28
x-height: 0.71
weight: 0.07
width: 0.44

Supported Languages: Albanian, Bosnian, Czech, Danish, Dutch, Estonian, Finnish, French, German, Hungarian, Italian, Latvian, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish, Swedish, Turkish.
OpenType Features: none
Merriweather Sans

Source: https://fonts.google.com/specimen/Merriweather+Sans
Google Fonts: YES
Design: Sorkin Type Co
License: SIL-OFL

Reference: Arial, Helvetica, San Fransisco
Classification: Sans
Styles: 8
Metrics:

Contrast: 0.30
x-height: 0.75
weight: 0.08
width: 0.45

Supported Languages: Albanian, Bosnian, Czech, Danish, Dutch, Estonian, Finnish, French, German, Hungarian, Italian, Latvian, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish, Swedish, Turkish.
OpenType Features: none
PT Sans

Source: https://fonts.google.com/specimen/PT+Sans
Google Fonts: YES
Design: ParaType
License: Paratype PT Sans Free Font License

Reference: Seravek
Classification: Humanist
Styles: 4 (+ 2 for captions + 2 for narrow)
Metrics:

Contrast: 0.16
x-height: 0.71
weight: 0.06
width: 0.39

Supported Languages: Albanian, Bosnian, Czech, Danish, Dutch, Estonian, Finnish, French, German, Hungarian, Italian, Latvian, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish, Swedish, Turkish, Cyrillic.
OpenType Features: none
Source Sans Pro

Source: https://github.com/adobe-fonts/source-sans-pro
Google Fonts: YES
Design: Adobe
License: SIL-OFL

Reference: Seravek
Classification: Humanist
Styles: 12
Metrics:

Contrast: 0.20
x-height: 0.74
weight: 0.06
width: 0.39

Supported Languages: Albanian, Bosnian, Czech, Danish, Dutch, Estonian, Finnish, French, German, Hungarian, Italian, Latvian, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish, Swedish, Turkish.
OpenType Features: numeric figure values
Windows
We recommend picking system fonts if you don’t find any in this list of recommendations. Indeed, Microsoft has been investing a lot of resources to design fonts that render perfectly on this platform, especially with ClearType. Typefaces like Cambria, Constantia, Arial Nova, Georgia Pro, Sitka, Verdana Pro, and more, offer a large amount of styles, excellent language support and perfect rendering, even on mediocre screens.
There’s really no need to use an alternative if you can use those typefaces.

[Update] Added Intel’s Clear Sans to the review and recommended list as I wasn’t particularly happy with Rubik.

This is now in docs, in a more advanced state and much better shape that this issue so it’s time to close it.
Any additional recommendation will be made in docs on the develop branch, especially for languages we deal with in i18n but please feel free to open a dedicated issue for each script/language if applicable.


How to reload config?

Do i have to recompile the project to apply new changes from config?

@mustardfrog nah you don't have to recompile the pj again. for now refreshing is still not supported, but you can kill and restart the wm, it will auto detect it.

This is really exciting. And now i want learn more about windows managers.
Are you working on this project alone?  If so, I will try to contribute to it.
btw I made a facebook group called "Myanmar Rustaceans" and you are welcome to join. (it has me and my two other friends who don't even know programming haha)

Yep I'm working alone, and I'm happy to welcome you or others contributions and feedback as 15 y.o drop out open source programmer, it mean a lot.

I am no master either. I just wanna learn rust and this may be the perfect spot.

Joined the group.

Nice


Differentiate between chat and follow blocks in notification

Fixes wrong red box showing up after you follow block someone. Also remove block from users store since it was unused. cc @keybase/y2ksquad

Merging over CI flakes


emacs plugin tweak to open buffer from stdin

inspired by this

Can you provide a quick summary of usage info?


@auth for static group authorization on @function field in Query without @model transformer

Note: If your question is regarding the AWS Amplify Console service, please log it in the
official AWS Amplify Console forum

** Which Category is your question related to? **
GraphQL Transformer
** What AWS Services are you utilizing? **
Amplify, Cognito, Lambda
** Provide additional details e.g. code snippets **
I was previously using static group authorization on a custom query for lambda function access control, as shown below.
type Query {
  calculate(submission: CalculatorSubmission): CalculatorResponse @function(name: "calculate")
  @auth(rules: [{allow: groups, groups: ["CalculatorAccess"]}])
}

Recently, this was broken by the following code change to the transformer, and I receive the thrown InvalidDirectiveError
    const modelDirective = parent.directives.find(dir => dir.name.value === 'model');
    if (!modelDirective) {
      throw new InvalidDirectiveError('Types annotated with @auth must also be annotated with @model.');
    }

As shown in the following warning message that is still in the transformer, authorization logic should work with static group authorization, which initially informed my design. However, there is no way for this code to run now, right?
    if (
      parent.name.value === ctx.getQueryTypeName() ||
      parent.name.value === ctx.getMutationTypeName() ||
      parent.name.value === ctx.getSubscriptionTypeName()
    ) {
      console.warn(
        `Be careful when using @auth directives on a field in a root type. @auth directives on field definitions use the source \
object to perform authorization logic and the source will be an empty object for fields on root types. \
Static group authorization should perform as expected.`
      );
    }

Is there any workaround to secure lambda functions with static group authorization using the @auth transformer? I don't need an RDS object.

thanks!


Creating Bookmark Crashes...

It appears that an issue occurs when attempting to create a bookmark. Specifically, the site closes immediately after clicking the bookmark button, suggesting that the application may have crashed, resulting in the tab being closed.

I tried to add a bookmark and I cannot reproduce the issue.
It works as intended.

I tried to add a bookmark and I cannot reproduce the issue.
It works as intended.

I tried this on my iPhone to see if it’s just a desktop issue and it does in fact close the page the website after I bookmark but when I go back to the bookmark, it shows up..

I still can't reproduce. I tried bookmarking on iPhone, and it works.


Routes are considered not to be a round trip journey.

Routes are operated in the forward direction only. There shouldn't be duplexes.
The routes processing algorithm currently doesn't have constraints for such a behavior. It should be corrected accordingly.

Fixed by this PR: #10. :+1: