Difference in Dependencies for register and inject

Considering the following two bits of code.
I want to use Service directly, so I add the inject annotation and provide the only dependency required for the __init__ method.
from antidote import LazyConstantsMeta, inject, register

class Conf(metaclass=LazyConstantsMeta):
    DOMAIN = 'domain'
    PORT = 'port'

    def __init__(self):
        self._data = {"domain":'doman value', "port":"port value" }

    def get(self, key):
        return self._data[key]

@inject(dependencies=(Conf.DOMAIN,))
class Service:
    def __init__(self, configuration):
        self.configuration = configuration

    def call_me(self):
        print("Service is being called")
        print(self.configuration)

Service().call_me()

In this version of the code, I want the Service class to be registered as a dependency which I can inject into another class. As far as I understand, I should use the @register annotation and provide the dependencies there.
from antidote import LazyConstantsMeta, inject, register

class Conf(metaclass=LazyConstantsMeta):
    DOMAIN = 'domain'
    PORT = 'port'

    def __init__(self):
        self._data = {"domain":'doman value', "port":"port value" }

    def get(self, key):
        return self._data[key]

@register(dependencies=(None, Conf.DOMAIN,))
class Service:
    def __init__(self, configuration):
        self.configuration = configuration

    def call_me(self):
        print("Service is being called")
        print(self.configuration)

@inject(dependencies=(Service,))
class Testing:
    def __init__(self, service: Service):
        self.service = service

    def test(self):
        self.service.call_me()

Testing().test()

In order to get this to work, I have to provide None as the first dependency to the Service class, which I didn't have to do with the @injection annotation. Is this mismatch expected, or am I somehow misunderstanding how to appropriately use the library?
If I don't provide none, I get the error TypeError: __init__() missing 1 required positional argument: 'configuration'

@register does not work in the same way as you might think:
@register(dependencies=(None, Conf.DOMAIN,))
class Service:
    def __init__(self, configuration):
        self.configuration = configuration

is actually equivalent to:
class Service:
    @inject(dependencies=(None, Conf.DOMAIN,))
    def __init__(self, configuration):
        self.configuration = configuration

Using @inject directly on the class, should not be supported because Service won't be a class anymore but a instance of the function wrapper:
@inject(dependencies=(Conf.DOMAIN,))
class Service:
    def __init__(self, configuration):
        self.configuration = configuration

    def call_me(self):
        print("Service is being called")
        print(self.configuration)

import inspect
inspect.isclass(Service) # False

I will add an error to make this explicit. If you ever need to only inject dependencies in a class, consider using @wire (which is what @register uses underneath).
Regarding the positional arguments in @register, it was the expected behavior. But seeing your example, I realize how counterintuitive it is. So I intend to change it to make your initial guess @register(dependencies=(Conf.DOMAIN,)) work. I will double check in depth later today.
However using @inject directly will always need None to specified as it can't know that it is a method.
In the meantime, consider using @register(dependencies=dict(configuration=Conf.DOMAIN)).

Okay, so to make sure I fully understand before closing this issue . . .
My usage of @register in the second code sample I provied is correct but instead of @inject on Testing I should instead of @wire(dependencies(Service,), methods={"__init__"]) on the Testing class?
Also as a side note, I've really enjoyed this library so far. Thank you for contributing this as open source!

My usage of @register in the second code sample I provied is correct

yes

instead of @inject on Testing I should instead use @wire(dependencies(Service,), methods={"__init__"]) on the Testing class

Yes, if you only want to inject services, you either use @wire on the class or @inject on __init__() directly.
The usage of @inject on a class directly is incorrect, it is only meant to be used on functions. So in your example the class will be treated as a function. While this works from a practical standpoint, it changes the nature of Testing which is a bad thing. So this is a bug.
As you have only 1 method to inject, you could in this case use either:
@wire(methods=['__init__'])
class Testing:
    def __init__(self, service: Service):
        self.service = service

    def test(self):
        self.service.call_me()

or
class Testing:
    @inject
    def __init__(self, service: Service):
        self.service = service

    def test(self):
        self.service.call_me()

Note that you don't even need to specify the dependencies explicitly as they can be inferred from the type annotation.
@wire is meant as a helper when you want to inject multiple methods of a class or wire a herited method (see wire_super argument).
As @wire is aware that it injects method, I intend to change how positional dependencies are working for it. It would not take into account the self argument so that @wire(dependencies=(Conf.DOMAIN,)) would work. This should be released during the week. :)
Glad you like it ! If you find any other issue or missing feature I'm definitely interested to know. :)

Thank you for the thorough explanation!


Deprecate protein folding

Summary
Details and comments

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.001%

Covered Lines:
17483

Relevant Lines:
20494

💛  - Coveralls

I think the new location for the code should be in whatever release note we end up with right. Do we want to do a release note here noting the deprecation and new location of the protein folding. Its kinda separate from the other code refactoring in that maybe just do this now so as to not have to remember later?


adding SNS lambda handler code snippet in typescript

adding lambda handler for sns event in typescript

Thanks @tomeh100 , question left on your PR

Thanks for the changes


Composer update

What steps will reproduce the problem?
What is the expected result?
What do you get instead?
Performing composer update I have:
E:\wnmp\www>composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- yiisoft/yii2 2.0.9 requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 2.0.8 requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 2.0.7 requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 <IP_ADDRESS> requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 2.0.15 requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 <IP_ADDRESS> requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 <IP_ADDRESS> requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 2.0.14 requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 <IP_ADDRESS> requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 <IP_ADDRESS> requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 <IP_ADDRESS> requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 2.0.13 requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 <IP_ADDRESS> requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 <IP_ADDRESS> requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 2.0.12 requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 <IP_ADDRESS> requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 <IP_ADDRESS> requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 2.0.11 requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 2.0.10 requires bower-asset/yii2-pjax ~2.0.1 -> satisfiable by bower-asset/yii2-pjax[2.0.8] but these conflict with your requirements or minimum-stability.
- yiisoft/yii2 2.0.6 requires bower-asset/yii2-pjax >=2.0.1 -> satisfiable by bower-asset/yii2-pjax[dev-master].
- yiisoft/yii2 2.0.6 requires bower-asset/yii2-pjax >=2.0.1 -> satisfiable by bower-asset/yii2-pjax[dev-master].
- Removal request for bower-asset/yii2-pjax == 9999999-dev
- Installation request for yiisoft/yii2 ~2.0.6 -> satisfiable by yiisoft/yii2[2.0.10, 2.0.11, <IP_ADDRESS>, <IP_ADDRESS>, 2.0.12, <IP_ADDRESS>, <IP_ADDRESS>, 2.0.13, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, 2.0.14, <IP_ADDRESS>, 2.0.14
.2, 2.0.15, <IP_ADDRESS>, 2.0.6, 2.0.7, 2.0.8, 2.0.9].
Additional info
Here is my composer.json
{
"name": "yii/service",
"description": "service",
"keywords": ["service"],
"homepage": "http://www.yiiframework.com/",
"type": "project",
"license": "service-key",
"support": {
"issues": "https://github.com/yiisoft/yii2/issues?state=open",
"source": "https://github.com/yiisoft/yii2"
},
"minimum-stability" : "stable",
"require" : {
"php" : ">=5.4.0",
"yiisoft/yii2" : "~2.0.6",
"yiisoft/yii2-redis" : "~2.0.0",
"yiisoft/yii2-bootstrap":"~2.0.0",
"bower-asset/bootstrap":"",
"fxp/composer-asset-plugin": "^1.4",
"phpunit/phpunit": "5.6.",
"twbs/bootstrap": "*"
},
"require-dev" : {
"yiisoft/yii2-debug" : "~2.0.0",
"yiisoft/yii2-gii" : "~2.0.0"
},
"config": {
"process-timeout": 1800,
"github-oauth": {
"github.com": "*****6"
},
"fxp-asset":{
"installer-paths":{
"bower-asset-library":"vendor/bower"
}
}
}
}

Q
A

Yii version
2.0.?

PHP version

Operating system

@samdark @massicode  @massicode


[CARBONDATA-3922] Support order by limit push down for secondary index queries

Why is this PR needed?
a) Limit pushdown for SI is already supported. But when order by column is not SI column, Still we were pushing down limit. Need to fix it.
b) when Limit is present and order by column and all the filter column is SI column. we can pushdown order by + limit.
This can reduce SI output results and reduce the scan time in main table.
What changes were proposed in this PR?
a) Block limit push down if order by column is not an SI column
b)  when Limit is present and order by column and all the filter column is SI column, pushdown order by + limit
Does this PR introduce any user interface change?

No

Is any new testcase added?

Yes

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/3481/

Build Failed  with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/1739/

@ajantha-bhat  please rebase

retest this please

Build Failed  with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2017/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/3758/

retest this please

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/3855/

Build Failed  with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2115/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/3911/

Build Failed  with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2170/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/3912/

Build Failed  with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2171/

@QiangCai , @akashrn5 @kunal642 : please check and merge

Build Success with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2172/

Build Success with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/3913/

@ajantha-bhat , can test cases be added to check no filter pushdown in not equal to case?

@ajantha-bhat , can test cases be added to check no filter pushdown in not equal to case?

There was already some testcase related to notNull pushdown was failing in TestNIQueryWithIndex, I will check and add notEquals anyways.

@ajantha-bhat , can test cases be added to check no filter pushdown in not equal to case?

@vikramahuja1001 :  Done added.

Build Success with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/3934/

Build Success with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2192/

Build Success with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2213/

Build Success with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/3953/

@kunal642 : PR is ready. please check and merge

Build Success with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/3976/

Build Failed  with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2236/

retest this please

Build Success with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2238/

Build passed after rebase. @kunal642 / @QiangCai : please check and merge.

retest this please

Build Success with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/4041/

Build Success with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.5/2303/


DocsArchive-<IP_ADDRESS>Auto archive content

Auto archive content from https://github.com/OPS-E2E-PPE/docs-archive-test-source

Docs Build status updates of commit 986a3d6:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error]

Cannot sync git repo to specified commit because branch Release_Archive_master_2020-03-30-03-39-23 has been deleted or has been force pushed: fatal: couldn't find remote ref refs/heads/Release_Archive_master_2020-03-30-03-39-23

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


Post Release TODOS

[ ] count for array
[ ] index for array
[ ] benchmarks (look at overhead of access vs python directly)
[ ] Other compiler flags?
[ ] string padding?
[ ] extra functions

[ ] validate_utf8
[ ] load_many/parse_many
[ ] load_many/parse_many with threads?
[ ] case insensitive at?

[ ] Add reprs to Object and Array
[ ] Expose versions of libpy_simdjson and simdjson

Note: Right now when iterate we convert everything automatically to python objects. Should we be smarter? Or is that not expected?

Note: Right now when iterate we convert everything automatically to python objects.
I think that now that we are using ranges, it would be possible to write a transform that has a shared pointer to the parser so it can convert the Objects and Arrays into our rich objects.

Could we use disambiguate_result plus the shared pointer inside the transform?


[BACKLOG-34409] Added logic to handle calling of JobFinish extension …

…point in the case of an exception (as we recently did for ktrs)

:white_check_mark: Build finished in 30m 44s
Build command:
mvn clean verify -B -e -Daudit -amd -pl engine

:ok_hand: All tests passed!
Tests run: 3821, Failures: 0, Skipped: 7    Test Results

:information_source:  This is an automatic message

:white_check_mark: Build finished in 31m 13s
Build command:
mvn clean verify -B -e -Daudit -amd -pl engine

:ok_hand: All tests passed!
Tests run: 3821, Failures: 0, Skipped: 7    Test Results

:information_source:  This is an automatic message

:white_check_mark: Build finished in 30m 33s
Build command:
mvn clean verify -B -e -Daudit -amd -pl engine

:ok_hand: All tests passed!
Tests run: 3821, Failures: 0, Skipped: 7    Test Results

:information_source:  This is an automatic message

:x: Build failed in 3m 35s
Build command:
mvn clean verify -B -e -Daudit -amd -pl engine

:exclamation: No tests found!
Errors:
Filtered log (click to expand)

script returned exit code 1

:information_source:  This is an automatic message

:x: Build failed in 2m 32s
Build command:
mvn clean verify -B -e -Daudit -amd -pl engine

:exclamation: No tests found!
Errors:
Filtered log (click to expand)

script returned exit code 1

:information_source:  This is an automatic message

:x: Build failed in 2m 47s
Build command:
mvn clean verify -B -e -Daudit -amd -pl engine

:exclamation: No tests found!
Errors:
Filtered log (click to expand)

script returned exit code 1

:information_source:  This is an automatic message

:white_check_mark: Build finished in 26m 26s
Build command:
mvn clean verify -B -e -Daudit -amd -pl engine

:ok_hand: All tests passed!
Tests run: 3824, Failures: 0, Skipped: 7    Test Results

:information_source:  This is an automatic message


⚡ Improve speed and relevance of search

Examples of searches are here https://6733f36a39f9b718a068cc2b--lamindb-qnwk.netlify.app/faq/benchmark-search

@falexwolf this is the approach we discussed yesterday, the results look reasonable for me and the speed is good.
I didn't add any postgres specific search here, can do.

Great!
Can you add extensive discussion, benchmarking results, and related resources to the top of this PR?
And link a report on laminlabs/lamindata that documents the performance?

Hm, i am not sure where to put the search benchmark.
I need a separate postgres instance for it, so maybe better to keep as a notebook.
But maybe not in FAQ.
I would just check that the top result is actually the full match, not the top N ordering.
laminhub maybe, not sure it is a good idea for bionty.

Also as you see it fails with fuzzy matching, i can add trigram or fulltext search in postgres for this case, i.e. when there are no results from the normal search or maybe just do both if it is postgres and combine.

Do you want to call to clarify?

A bit later today.

Ok! Just ping me!

Also as you see it fails with fuzzy matching

Along the lines of what we discussed, this would now be the desired behavior.
What should be tested though is that suggest_records_with_similar_names is still working as expected: https://github.com/laminlabs/lamindb/blob/dfdd732a5083c6677f7e345348f86087481e3c57/lamindb/_record.py#L74
I fear there is no unit test for this yet. Can you please add a unit test for it?


Add mock_call

Closes #
Introduced changes

Add start_mock_call cheatcode (with tests and docs)
Add stop_mock_call cheatcode (with tests and docs)

Breaking changes

Checklist

[x] Linked relevant issue
[x] Updated relevant documentation
[x] Added relevant tests
[x] Performed self-review of the code
[x] Added changes to CHANGELOG.md

@piotmag769 Added tests in https://github.com/foundry-rs/starknet-foundry/pull/385/commits/7125bde518bacd94459990c86d485656ea6d30da


[Feature]: authWithOAuth2 support AbortSignal

Please don't open issues without description. Could you elaborate what is your use case?

If you are trying to cancel a pending authWithOAuth2() call I guess we can introduce a requestKey support similar to the other SDK methods, which will allow cancelling with pb.cancelRequest(requestKey).
The problem with the "all-in-one" authWithOAuth2() call is that it performs 3 different requests - listAuthMethods, start a realtime subscription and finally call to the authWithOAuth2Code() method. It is doable but requires some more thinking.

Under the hood the builtin request cancellation is managed managed by a AbortController.
There are no plans for now to pass AbortController/AbortController.signal as argument because it will be inconsistent with the other APIs and internal implementation may change in the future.
As mentioned earlier, I'll consider supporting passing requestKey to the "all-in-one" authWithOAuth2() method but I'll have to think a little more on it and for now remains a low priority.

Thanks for your reply, I had implement it by myself, so it will not  block me.
requestKey is fine, but it need export cancelRequestKey function, let user can muanal control cancel it

Support for cancelling the OAuth2 flow using requestKey is added in v0.21.4 release.


[payload_on] is an invalid option for [light.mqtt]

Home Assistant release with the issue:

hass 0.87
Last working Home Assistant release (if known):
0.86.3
Operating environment (Hass.io/Docker/Windows/etc.):

Hass.io
Component/platform:

Description of problem:
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
light:
  - platform: mqtt
    schema: json
    name: mqtt_json_light_l1
    state_topic: "stat/light/l1/rgb"
    command_topic: "cmnd/light/l1/set"
    payload_on: "ON"
    payload_off: "OFF"
    brightness: true
    rgb: true
    effect: true
    effect_list: [colorfade_slow, colorfade_fast, flash]
    optimistic: false
    qos: 0

payload_on is not a valid option for the mqtt light json schema. The different schemas have different options.
https://www.home-assistant.io/components/light.mqtt/#json-schema---configuration


Update docs: dependencies don't build on Windows

See issue https://github.com/Azure/azure-storage-python/issues/219 for more. Hopefully this saves others from spending a few days on this problem. The recommended command pip install azure-storage does not work on Azure Web Apps, a primary environment this package is intended for, so this seems important to point out.

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

Hi @lucaluca, sorry to hear that you had to deal with this problem on Azure Web Apps. 😢
According to what I understood from reading that issue, this problem is really caused by the older version of pip which is pre-installed on Azure Web Apps and cannot install Cryptography properly. However, there is this workaround to upgrade the pip. As far as I know this is not a problem present on other Windows platforms that have newer versions of pip. The Cryptography wheel package on Windows is a statically linked build, so newer pips should install it just fine, and users do not need to build anything natively.
Please let me know whether I understood this correctly. If yes, could you please modify the documentation to point out that:

there might be a problem on Azure Web Apps to install Cryptography
the workaround is to upgrade pip and install from wheel

Best regards, and thank you for taking time to do this PR. 👍

Hi - that's good to know and I'd be happy to update the PR. Just to
clarify, because I haven't tried this, is the solution to upgrade pip AND
install from wheel? Or does upgrading pip mean you can just build without a
wheel?
On Thu, Aug 17, 2017 at 5:19 PM, Ze Qian Zhang<EMAIL_ADDRESS>wrote:

Hi @lucaluca https://github.com/lucaluca, sorry to hear that you had to
deal with this problem on Azure Web Apps. 😢
According to what I understood from reading that issue, this problem is
really caused by the older version of pip which is pre-installed on Azure
Web Apps and cannot install Cryptography properly. However, there is this
workaround
https://github.com/Azure/azure-storage-python/issues/219#issuecomment-270867174
to upgrade the pip. As far as I know this is not a problem present on other
Windows platforms that have newer versions of pip. The Cryptography wheel
package on Windows is a statically linked build, so newer pips should
install it just fine, and users do not need to build anything natively.
Please let me know whether I understood this correctly. If yes, could you
please modify the documentation to point out that:

there might be a problem on Azure Web Apps to install Cryptography
the workaround is to upgrade pip and install from wheel

Best regards, and thank you for taking time to do this PR. 👍
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-storage-python/pull/336#issuecomment-323209924,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABxYRoleJN7ljW0JfJbfrVReS-u0DbWkks5sZLyBgaJpZM4O4Wx5
.

Current recommendation is to update Python using the Extension mechanism (fix your problem automatically)
https://docs.microsoft.com/en-us/visualstudio/python/managing-python-on-azure-app-service

Thanks @lmazuel! 👍
@lucaluca Would you like to update this PR?

@lucaluca I added the suggestion on readme. Thank you!


Create a generic Code Generation Plugin

Create a new maven plugin with allow you to generate code by especifiying both the templates and the model, the templates can be created in freemarker, and the model will be in xml.

The first version of the code generation plugin is done.


LEGO: Pull request from lego/hb_835_20170303094045989 to master

LEGO: Pull request from lego/hb_835_20170303094045989 to master with localized lcls

@csigs,
Thanks for your contribution.
To ensure that the project team has proper rights to use your work, please complete the Contribution License Agreement at https://cla.microsoft.com.
It will cover your contributions to all Microsoft-managed open source projects.
Thanks,
Microsoft Pull Request Bot

Please merge to Release/1_0 instead since this is work for the release. Master will be getting post 1.0 changes soon.


DOM elements (specifically table) deleted/re-organized on clicking "edit"/"save" buttons

I'm using an email template in the content editor and when I press "edit" or "save" content is being moved from the table its in to a new table (without the important classes), or table rows are being combined (changing the layout styles)
Notice that originally, the left column image and p were in the same row. After pressing the edit button, each image and paragraph becomes its own table row. How do we get around this? I tried adding unique classes to each tr, which succeeded in preserving those two rows, but other things started disappearing/being combined instead.
Here's the code (and screenshots) of the first instance of the issue.
original code:
html after pressing "edit":
what it looks like originally:
what it looks like after pressing "edit":
Thanks,
Danielle

Hi @danielleford04,
I'm not sure of the precise cause of this behaviour however the editable  elements in ContentEdit are only designed to take inline HTML not block level elements (see the intro and limitations section to HTMLString here http://getcontenttools.com/api/html-string) and I suspect this may well be playing a part in the problems your seeing.
It would be really useful if you could provide the actual HTML here so I can have a go at reproducing the issue myself.
One possible option you might try here also (since from your HTML screenshots it appears you need the the contents of the s themselves to be editable, would be to make s containing editable content regions themselves instead of the entire block, e.g:

Title

Body

        ...

If you can provide the HTML in a format I can copy and paste into a text file I'd appreciate that as I'd like to investigate this behaviour further.

Hi @anthonyjb -
I'll look more into that, thank you for the link. I've included the jade for the whole editable area (most of this is what's -inside- of the area but i included the editable region). It is, however, jade and not html! If you want more of the code, let me know...
editable.txt
(I really hope this file format preserves formatting)

Hi @danielleford04, hanks for the file if you could also post the output HTML that CT runs against that would be awesome (sorry I should have been more specific initially).
Do let me know how you get on and if the alternative approach works out for you.

Ah! I copied and pasted code from Dev Tools and unfortunately formatting was not preserved...but here is the code before and after the save
code.zip

The alternative approach works! Though it will also require an alternative saving approach. Thanks!


Can I use the hypercore/hyperswarm/hyperbee libraries with this?

i.e. Will I have issues building these libraries (since they depend on other native libraries)?

Hi @saimon-moore yes you can, although you need to deal with building the native dependencies. We prebuild the native modules in our app CoMapeo to avoid difficulties for individual contributors trying to build locally. We are creating prebuilds for the hyper- deps (no guarantees that these will be reliably maintained, because they are mainly for our own internal use):

https://github.com/digidem/sodium-native-nodejs-mobile
https://github.com/digidem/crc-native-nodejs-mobile
https://github.com/digidem/fs-native-extensions-nodejs-mobile
https://github.com/digidem/quickbit-native-nodejs-mobile
https://github.com/digidem/simdle-native-nodejs-mobile
https://github.com/digidem/udx-native-nodejs-mobile
https://github.com/digidem/better-sqlite3-nodejs-mobile

The template we use for creating prebuilds is here: https://github.com/digidem/nodejs-mobile-prebuilds-template
Our build process for loading these prebuilt native modules is here: https://github.com/digidem/CoMapeo-mobile/blob/7e517449306f0a65c2f50f6f5695a4fd474a496d/scripts/build-backend.mjs
It's possible to build the hyper deps as part of the nodejs-mobile build process, without creating prebuilds, but it might need a bit more work setting up the right build environment.


Uncaught (in promise) Error: Not opened

The very first thing I try to do with the sdk gives an error:
const SDK = require('dat-sdk')
const sdk = await SDK()

I get Uncaught (in promise) Error: Not opened :
_openAndNotClosed

What am I doing wrong?

ps. if I run dat share mySharedDir/ --http then browse http://localhost:8080, I get a list of all my shared files. Essentially, that's all I want to do above, so I know it's possible :)

I've attached a screengrab of the console:

Is this something to do with webpack, too?

Anyway, I'm getting closer! I'm trying this:
var {
    	Hyperdrive,
    	close
    } = await SDK({
      persist: false
    })

    const myDat = 'dat://328c78dce8a95ad7bfdc5245a99c38e71d8dc75f5671017eec7ef75049dadd6e'
    const myArchive = Hyperdrive(myDat)
    await myArchive.ready()
    console.log(await myArchive.readdir('/'))

That gets a lot further - unfortunately, it lists an empty array, rather than the dozen or so files I'm sharing. And I get this error, now:

I'm guessing I'm doing something wrong, but the docs' aren't very helpful... :(

Hey! I'll investigate further tomorrow but I think the main issue you have right now is that the dat CLI doesn't support the latest versions of Hyperdrive.
Essentially, stuff using the dat:// URL scheme need an older version of the SDK (pre 2.0) or you can use something newer like dat-store which supports the hyper:// protocol

Gonna close this for now since it's been a while and there hasn't been any updates. 😅


Need guide to use on class component

Hello,
I need help how to show InterstitialAd on class component, I try to read this doc https://react-native-admob.github.io/admob/docs/api/InterstitialAd but still confused.
help me with example ,please..
Thanks

Now example code is included in example app.


Fix size of reveal icon for frost-password

#PATCH#
CHANGELOG

Fixed size of reveal icon for frost-password.
Updated frost-password to use updated icon path for reveal icon.

👍


[bazel] Clean up transition to host platform in sign_bin rule

The standard way to achieve is to use the cfg attribute on labels. Bazel documentation recommands to mark all tool requirements with executable which then requires cfg to be set to determine whether it should be built for the host or the target and avoid potential toolchain errors.

Hopefully closes #11199

Rebased again, I don't understand why english breakfast verilator is failing since it's completely unrelated.

We can probably close this? b/c with the new rules, this won't be an issue anymore.

I think we can close this now since we have the new rules.


Add exponential backoff retries for failed cache refresh

This PR adds the ability to retry failed cache refreshes with exponential backoff. Backoff wait time will increase by 2^n minutes to a maximum of the regular cache time.
This way, an API error will not necessarily be cached the whole regular cache time. At the same time, overloading the API with too many refresh attempts is avoided.
For the default of 15 minutes cache time, the retries will happen after 1m, 2m, 4m, 8m and 15m (15 instead of 16 because the backoff time cannot exceed the regular cache time).

The diff is much larger than I thought. Do we really need the extra param? There is also https://pkg.go.dev/github.com/cenkalti/backoff/v4 which might simplify the backoff algo and is already user in other parts of the code.

I had a look at this lib too but deemed it to be too much overhead for the rather simple task we would like to achieve.
The extra param is meant for selectively using the backoff for well defined cases. We could do without but then it would be all or nothing.
The actual diff for the algo is about 50 loc (tests and extra param aside).

If we don't have these cases we should minimize the impact.

I took a look at the lib again. The problem is that it is not a good fit for the way we are calling the cache.
We want to cache the error e.g. from the vehicle API for a short time. We do not want to try as often as the backoff allows until we either get a valid response or a backoff timeout. But that would be the behaviour of the Retry function from the lib.
Also, we have an external scheduler that calls the getter typically every 10 seconds. Introducing the Retry function from the lib would mean, that inside this cache getter, new threads would be started. We would have to do all sorts of thread synchronization ourselves.

Der Linter ist in einen Timeout gelaufen


feature(UI): Help modal form

Checklist:

[x] I have read and followed the contribution guidelines.
[x] I have read and followed the how to open a pull request guide.
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #52223

I read the suggestions in the issue #52223 and tried to create a first version of the modal. Lots of the comments have diversions but I built the form in a way that makes sense to me, I am open to suggestions and implementing changes as well as refactoring the code to best meet the guidelines.
Here are some pictures of what the form looks like:
After clicking on the help button:

After clicking on create help post on the forum:
Submit is active (user clicked in both checkboxes and typed at least 100 characters):

Submit not active

After clicking on the submit button the user is redirected to the page to create a help post with his description automatically filled in.
Building this feature I had some doubts about the free code camp code architecture that I would appreciate if anyone could help me with such as:

How is the process to implementing new translations in the codebase?
What components are the standard to use? The form itself I didn't know what to use, I saw some places where it was being used normal forms others imported from libraries.
Is it okay to style I component directly using style tag? Should I create a .css file to style each component or does the application uses bootstrap or some other styling framework?

I'm not sure we should lose the two links in the process.

How is the process to implementing new translations in the codebase?

The strings are added to translations.json, and accessed with the t function

I'm not sure we should lose the two links in the process.

What do you mean losing the two links? I didn't change the original modal, I just changed the functionality of the "create a help post on the forum" button to show the form instead of directly redirecting the user to the forum.

How is the process to implementing new translations in the codebase?

The strings are added to translations.json, and accessed with the t function
Learn more: https://contribute.freecodecamp.org/#/how-to-work-on-localized-client-webapp?id=how-to-work-on-localized-client-webapp

Thank you! I am going to read that and try to implement the translations now.

What do you mean losing the two links?

The modal code doesn't seem to use any hyperlinks to the web pages to the "Read-Search-Ask" and "already answered...". They are just text checkboxes. People need to be able to click a link and visit the pages and then confirm they have actually read the documentation.

The links were already been shown in the first part of the modal...

Thanks - I missed that. In any case it is better and somewhat expected that the links be in the checkboxes too.
This is looking good. Some one will have this reviewed soon. Thanks a lot for working on this.

Thank you for this pull-request @PedroRamos360
I am having some issues loading the link text though even after running clean:client:

Perhaps I am missing something quite obvious?

@Sembauke Thanks for the review! I didn't know what command to run to apply the translations before that is why I didn't catch that error. Now I ran it and applied your suggested changes.

We can change this in onSubmit with a conditional.
We should also let the user know why it is still disabled after adding text. (If the text is too short)

What happens if the What's happening message + code exceede the max of characters that can be imported as starting message in the forum?
At that point it doesn't even import the text of the box, see trying to open an help post from RPG step 165

### Tell us what's happening:

### Your code so far

WARNING

The challenge seed code and/or your solution exceeded the maximum length we can port over from the challenge.

You will need to take an additional step here so the code you wrote presents in an easy to read format.

Please copy/paste all the editor code showing in the challenge from where you just linked.

\`\`\`text
Replace these two sentences with your copied code.
Please leave the ``` line above and the ``` line below,
because they allow your code to properly format in the post.
\`\`\`

### Your browser information:

User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36

### Challenge Information:
Learn Basic JavaScript by Building a Role Playing Game - Step 165
http://localhost:8000/learn/javascript-algorithms-and-data-structures-v8/learn-basic-javascript-by-building-a-role-playing-game/step-165

It does the same for a very long tell us what's happening message, meaning the camper could loose the question they asked.

Likely need to update the help saga to parse this new form field as the question.

It seems like the submit button is still inactive but clickable after checking all the boxes.

I also included a verification for the input need to have at least 100 characters, I can remove this verification or just display this information to avoid people being confused. It doesn't need to be 100 characters necessarily but I believe a character limit makes sense otherwise they could just send an empty question to the forum.

What happens if the What's happening message + code exceede the max of characters that can be imported as starting message in the forum?
At that point it doesn't even import the text of the box, see trying to open an help post from RPG step 165

When I tested the message import was working, I am going to review it later to see if I missed something. About the max of characters problem I could put a limit based on the length of the code the user wrote or just a fixed limit for the input. I don't know how long is the character limit but if is high I believe the fixed limit would work just fine.

It's working if the URI is shorter than the limit
https://github.com/freeCodeCamp/freeCodeCamp/blob/80fb22c36c6513889cf4b44c13995c55005eff72/client/src/templates/Challenges/redux/create-question-epic.js#L164
If it's longer the written question is lost
A static limit is not going to work, as the limit is the URI length, not the code or the question length, but both together plus the other frills

It's working if the URI is shorter than the limit
https://github.com/freeCodeCamp/freeCodeCamp/blob/80fb22c36c6513889cf4b44c13995c55005eff72/client/src/templates/Challenges/redux/create-question-epic.js#L164
If it's longer the written question is lost
A static limit is not going to work, as the limit is the URI length, not the code or the question length, but both together plus the other frills

I updated the code now to add a limit of 500 characters for the textarea. The total limit of 8000 characters is a really big limit, the 500 characters limit for the textarea should be more than enough. Also even if someone manages to pass that limit (that would probably happen only if trying do it on purpose) there is already treatment for this case at the line you reffered to in which the code uses an alternative URI:
https://github.com/freeCodeCamp/freeCodeCamp/blob/80fb22c36c6513889cf4b44c13995c55005eff72/client/src/templates/Challenges/redux/create-question-epic.js#L164
Also, blocking the person from sending the message if the total limit was surpassed would not solve the problem as the code itself could have more than 8000 characters and it wouldn't help making their description smaller. In that case the person would be completely blocked from sending a question because her description would be bigger than the limit and smaller than the limit always.

The total limit of 8000 characters is a really big limit, the 500 characters limit for the textarea should be more than enough.

Halfway through the RPG project the code alone makes it too big. Is the question kept if the code is too big? It can be disheartening if the camper takes time to fill a question and then the forum precompiled post doesn't include it.
It's not the scope of this issue/PR, but it could make sense if only the file that needs changing is ported over maybe, that would reduce more the issue with too long code

The total limit of 8000 characters is a really big limit, the 500 characters limit for the textarea should be more than enough.

Halfway through the RPG project the code alone makes it too big. Is the question kept if the code is too big? It can be disheartening if the camper takes time to fill a question and then the forum precompiled post doesn't include it.
It's not the scope of this issue/PR, but it could make sense if only the file that needs changing is ported over maybe, that would reduce more the issue with too long code

Yes, you are right, it would be really frustrating to have to write the question all over again. There are three solutions that I can think of: The best one that would work for any case that would be updating the https://forum.freecodecamp.org to receive the questions in some other form like creating a table for those questions and in the URI just sending the ID, but I believe that would be unecessarily complicated. Or I could simply check if the length of the URI will pass 8000 characters if the description is filled and then simply not display the description textarea. This way the user won't waste time writing a question that won't be saved and can write it when it gets to the page. And finally even simpler than all of that would simply be always remove the textarea, or replace it with an input field the user has to fill to prove they understand like saying "I read the articles in both checkboxes and understand the guidelines of creating a question in the forum" or something like that.

It would also be possible to just take the code out when the limit passes 8000 characters and just putting the description.

You could also send the editable region with a check if there are changes outside of the editable region

Hey @PedroRamos360, This is looking great! The only thing I would do differently is:

Make the character count dynamic e.g. : Add a minimum of X more characters
When the user has reached this: X characters left
Position it at the bottom of the field with a top padding and alignment with the text above the input field.

Also: The submit button is still clickable when it is disabled.

Do you mean like showing this text Add a minimum of X more characters when user didn't type anything and then show this X characters left when they start typing?

Before the minimum is reached:
Add a minimum of X more characters
Then:
X characters left

Does it have to part of this PR? I would like to limit the scope of the PR because it is becoming increasingly complex?

Let me know @PedroRamos360, feel free to add this in another pr!

Awesome, this is exactly what I meant.
The issue with the submit button still exists though!

It looks good.
I might suggest adding a little more vertical separation between the elements inside the form. Like a row-gap of 0.5rem to the flexbox container inside the form.
Can we get @bbsmooth to OK the accessibility if they have the time?

Maybe we should stop the back button navigation and warn the user if the textarea has been filled in. Just so people do not write a bunch and hit the back button by accident.
It would be nice if the form remembered what was typed but that might be asking too much.

Awesome, this is exactly what I meant.
The issue with the submit button still exists though!

Are you sure? I fixed that in the previous commit I extracted the verification to the disabled button to a function then used that same function in the form submit function, I tested again now and it is not clickable, before I could click on it by only filling the 50 characters and not checking the checkboxes but now the only way is by filling the 50 characters and clicking the checkboxes.

It looks good.
I might suggest adding a little more vertical separation between the elements inside the form. Like a row-gap of 0.5rem to the flexbox container inside the form.
Can we get @bbsmooth to OK the accessibility if they have the time?
Maybe we should stop the back button navigation and warn the user if the textarea has been filled in. Just so people do not write a bunch and hit the back button by accident.
It would be nice if the form remembered what was typed but that might be asking too much.

Actually, it was that way before it did not erased the content even if you closed the modal and opened it again but that started creating some problems in the interface and I decided to reset all the states every time the user gets out of the page. I think I can fix that, I am going to just avoid reseting the values when the person clicks the back button.

Do the input elements not need labels or aria attributes?
Or is the link text and title enough and if so do the input elements need to be associated with the links using aria-labelledby?

Can we get @bbsmooth to OK the accessibility if they have the time?

Definitely. I have been watching this PR from a distance and it sounds like it is about ready to go. I will make a point to test it by the end of this coming weekend.

There are quite a few accessibility issues. Some of them will be relatively easy to fix and I'll start adding code suggestions. A few are going to be much more complicated, such as the textarea with the maximum character limit that dynamically updates how many characters you have left, and we may decide to save those for separate PRs.

Question. Do we really need a "Back" button on the second dialog that takes you back to the first dialog? The first dialog has the exact same information on it as the second dialog. I'm not sure I see how it helps to go back to the first dialog from the second. It seems to me if you are on the second dialog and decide you don't want to create a Help post then you just want to cancel completely, so there is no reason to go back to the first dialog. I recommend we replace the Back button on the second dialog with Cancel, just like it works on the first dialog.

Question. Do we really need a "Back" button on the second dialog that takes you back to the first dialog? The first dialog has the exact same information on it as the second dialog. I'm not sure I see how it helps to go back to the first dialog from the second. It seems to me if you are on the second dialog and decide you don't want to create a Help post then you just want to cancel completely, so there is no reason to go back to the first dialog. I recommend we replace the Back button on the second dialog with Cancel, just like it works on the first dialog.
Related to this. Is there a reason we need two separate dialogs for this? I think it would make accessibility better if we just had one.

About the back button, I agree, a Cancel button makes more sense, but I think it is good to keep the 2 part form although it is redudant. The goal of this feature, from what I understand, is to make it harder for the user to create a question in the forum to incentivate people that aren't really engaged with making a question and just want someone to tell them the answer to give up. Also I believe it can help users understand the seriousness of the alert.

How can I make this  text responsive to dark mode? If i just set the style: {color: white} it will will mess up light mode, is there a component for this in the project?

If you use the custom properties it should work.
https://github.com/freeCodeCamp/freeCodeCamp/blob/main/client/src/components/layouts/variables.css
We have Tailwind as well so it would be nice to switch whatever inline styles we can to Tailwind classes instead.
Unless there is a reason why we use inline styles. Not sure when/where we are using Tailwind or are supposed to use it.

Not sure what happened but the first modal page is missing spaces for the text when I looked.

Commited the suggested changes and adapted the help-modal.spec.ts test to match the changes in help-modal.tsx but now some error is happening at test:curriculum that I don't understand, I am going to put more time figuring it out later but in the mean time if someone knows something about this error I would appreciate the help.

This fail has likely nothing to do with your changes. I am re-running the CI to confirm. Otherwise I will look into this myself.

Amazing! Thank you for your determination to this effort.

Sorry, I added a few more accessibility updates, but I promise I'll stop now. There are still some accessibility issues that need to be addressed, but they are complicated enough that I'll save them for separate PRs.

@bbsmooth thank you for your suggestions! Applied them now and tested and its working as expected. I didn't really understand the necessity of removing the tab focus on a disabled button for accessibility, does it have to deal with screen readers or something like that? Also if it is the most correct for a disabled button to not be focused maybe we could implement this directly in the Button component to avoid inconsistencies.

It's about consistency and expectations. If something can receive keyboard focus then the implication is that it is functional, and that might be confusing to some people. Also, the color contrast on disabled controls is allowed to go below minimum contrast requirements (which ours does), as long as the are truly disabled, which means no keyboard focus. So unless we want to make the text on that disabled Submit button a lot darker, then it can't allow keyboard focus.

Do we need better visual feedback for the check box requirement? When filling out the text but forgetting to check the boxes it looks like the form is just not reacting to reaching the required text amount.
Should clicking outside the second modal screen close it now that it doesn't remember what you typed? There is some potential for accidentally losing what you typed with this approach.

Do we need better visual feedback for the check box requirement? When filling out the text but forgetting to check the boxes it looks like the form is just not reacting to reaching the required text amount.
Should clicking outside the second modal screen close it now that it doesn't remember what you typed? There is some potential for accidentally losing what you typed with this approach.

What do you mean does not react to reaching the required text amount? If you mean that the submit button keeps disabled that is intentional as it is described above the checkboxes that it is necessary to check them so the user can continue.

I'm saying if you forget to check the boxes and start typing and get "caught up" by the "enter this many characters" when you reach that and the form still can not be submitted it isn't super obvious what is missing.
Unlike the minimum characters requirement, there is no visual indication of the checkbox requirement.

Do we need better visual feedback for the check box requirement?

Yes, the form needs better error handling in general. This is an issue I was going to work on in a separate PR. I didn't want to drag this one out any longer.

Should clicking outside the second modal screen close it now that it doesn't remember what you typed?

That's a good point. Way to easy to accidentally click outside the box.

This is now live in production! Thanks @PedroRamos360 for working on this.

@huyenltnguyen

Wrapping the input elements for the checkbox inside a label, instead of adding aria-label to the inputs

We have links in the label text for the checkboxes (which is kind of an accessibility anti-pattern to begin with). Because those links open a new window, it is considered a best practice to let screen reader users know that, which is usually done with visually hidden "opens in new window" text immediately after the link. But we don't want screen reader users to hear that visually hidden text for the check box name itself, thus we were using aria-label for the checkbox to get around that.  So the trade-off here is that our code is a little cleaner but screen reader users aren't told that the link opens a new window. Not a show stopper, just wanted to make it clear why we were using aria-label. Personally, I would love to get rid of those links in the label text, especially since we have them already linked on the intro dialog page.
Concerning the tabindex issue on the disabled button, most accessibility professionals interpret WCAG to mean that that an element can only be considered disabled if it cannot be interacted with in any way, including having keyboard focus by tabbing to it. So removing tabindex="-=1" from the button does no longer makes it truly disabled and thus it must meet minimum contrast requirements to satisfy WCAG 1.4.3. (Yes, I am saying that the CSS Tricks article you linked to above is misinterpreting 1.4.3). So technically, the "disabled" Submit button in the dialog needs to have darker "Submit" text. But I wholeheartedly agree with you, we should not be disabling the Submit button in the first place and thus we won't need to worry about tabindex or contrast.
Also, I just checked production, and currently the Submit button is not disabled (even though it looks like it). I am able to click on it with both the keyboard and the mouse and get feedback from the form. The form is using the default error handling features build into the browser. They aren't perfect, but they will do for now. So I think it makes sense to get rid of aria-disabled on the Submit now.


docs: fix module name typo

fix typo in module name

:tada: This PR is included in version 2.2.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Can flux kustomize file patch?

Is there a way to load patches from file, similar like this kustomize
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
patchesStrategicMerge:
- patch-exclude.yaml

I find troublesome to use flux2-kustomize patch string.
Thanks for the tips.

No this is not possible, the Flux Kustomization can't refer to files. If you have large patches use kustomization.yaml, if you just need to override the namespace or set container images, then Flux Kustomization is suitable.


Add files via upload

Mekif H High School addition from IL

@jack12c356 Please provide us with:

the school official website URL
the school street address
a proof, which shows that the school recognizes the domain you are submitting as an official email domain for the students.

@jack12c356 Please provide us with:

the school official website URL
the school street address
a proof, which shows that the school recognizes the domain you are submitting as an official email domain for the students.

The school official website URL: http://www.makifchet.rlz.org.il/BRPortal/br/P100.jsp
The school street address: Haim Bar-Lev 1, Rishon LeTsiyon, Israel.
I can not provide the requested proof since I don't know which proof you are requesting for and how can I provide it. However, I can declare that in my school all the students and teachers are having the same Mail domain address: @mekifh.edum.org.il which is given to us by the official ministry of education of Israel. For more information, you can contact me in the mail<EMAIL_ADDRESS>

@jack12c356 Thank you for the clarification. Pull request merged.


v5.1.6 introduces breaking change

update of asn1 in #37 introduces breaking change
You can see that CI is failing since that change:
https://github.com/crypto-browserify/parse-asn1/commits/v5.1.6
although that failure doesn't appear to prevent publishing of the package.

I rolled back to v5.1.5 to address the issue I was having.

Yes, it is breaking flows in crypto-browserify and webpack too. Needs to be reverted

update of asn1 in #37 introduces breaking change
You can see that CI is failing since that change:
https://github.com/crypto-browserify/parse-asn1/commits/v5.1.6
although that failure doesn't appear to prevent publishing of the package.

yes, it is breaking flows. rolling back to v5.1.5.

ok so we had to upgrade the library due to a security vulnerability in the library.  This is only a breaking change in very out of date versions of node that are not supported anymore.  If you are building software based on that you should be aggressively pinning your dependencies with shrink wrap or package-lock.  Like I'm shocked that this is the first instance of const to show up here
You're right the ci was failing, but that's only because I hadn't changed the target of those since the iojs era which is 100% not a level of backwards compatibility we support, so I updated the tests in #44 to supported node versions.

Hi ,
After the new version of parse-asn1 ( 5.1.6)  is released we are getting error while we try to run webpack build. During the webpack build we are invoking Uglifyjs plugin. The version 5.1.6 contains ES6 code , but in previous versions it was ES5 code.  So the UglifyJS plugin is not able to parse the code. Currently our work is halted due to this issue. Can we expect a resolution to this issue at the earliest ?

you're going to need to pin it to 5.1.5 or switch from ugilfy to something like babel-minify

@calvinmetcalf I agree that us poor schlubs stuck on old versions of nodejs need to fend for ourselves, but introducing a breaking change, for whatever reason, in a patch release, breaks the contract. You need to bump the major version with this change. You can change the version of nodejs you support for sure, but that should be done in a major version bump.

this isn't a library that people depend on directly it's included with browserify/webpack so if we bumped the major, we'd just bump the thing importing it depriving other people of the security fixes

@calvinmetcalf the issue is that this will break builds for most Webpack 3 projects as it defaults to minifying with it's own version of UglifyJS which doesn't support es6. Agreed it's an old version, but I don't think it should automatically be nuked because of a few instances of let and const in a nested dependency patch release.

I've been able to work round this for now by using npm-force-resolutions with the following additions to my package.json:
"resolutions": {
  "parse-asn1": "5.1.5"
},
"scripts": {
  "preinstall": "npx npm-force-resolutions"
}

I was running into problems because<EMAIL_ADDRESS>(used by<EMAIL_ADDRESS>has a dependency on "parse-asn1": "^5.0.0",

@calvinmetcalf
Hi, how is this issue status now?
I'm the one who faced a breaking build, too, and I've commented on this issue below:
https://github.com/crypto-browserify/parse-asn1/issues/45#issuecomment-697115522

@calvinmetcalf it's not just about old versions of node, it's about old browsers that most websites still have to support. Could the const be reverted?

v5.1.7 restores support down to node 0.10.


Add new callback to DVCLive

[x] ❗ I have followed the Contributing to DVCLive guide.

[ ] 📖 If this PR requires documentation updates, I have created a separate PR (or issue, at least) in dvc.org and linked it here.

Close #85

Added callback for pytorch lightning
Didn't update docs. I'll do it when you accept my changes. It's my first PR, so I'm not sure, that I'm doing it right ¯_(ツ)_/¯

Created the issue about documentation update. I'll create a PR to dvc.org tomorrow


Merge master to live

:x: Validation status: errors

File
Status
Preview URL
Details

:x:Error

Details

[Error] Cannot sync git repo to specified state. Please make sure the pull request is mergeable. Details: Git merge results in conflict, repository remote url: https://github.com/MicrosoftDocs/office-365-management-api, working directory: W:\surm-s, target branch: live, target branch commit: 0d84c0bb09888573b482e9193d0097b774721935, source branch: master, source branch commit: .

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

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

office-365-management-api/TOC.md
:white_check_mark:Succeeded
View

office-365-management-api/breadcrumb/toc.yml
:white_check_mark:Succeeded

office-365-management-api/docfx.json
:white_check_mark:Succeeded

office-365-management-api/get-started-with-office-365-management-apis.md
:white_check_mark:Succeeded
View

office-365-management-api/images/CFW.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/Caution.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/GitHub-Mark-64px.png
:white_check_mark:Succeeded
View

office-365-management-api/images/LastChild.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/Octocat.png
:white_check_mark:Succeeded
View

office-365-management-api/images/add-an-application-dialog-OLD.png
:white_check_mark:Succeeded
View

office-365-management-api/images/add-an-application-dialog.png
:white_check_mark:Succeeded
View

office-365-management-api/images/adm.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/adm_arch.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/adm_dev.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/adm_dev_arch.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/alert_caution.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/alert_note.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/alert_security.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/arch.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/authorization-flow.png
:white_check_mark:Succeeded
View

office-365-management-api/images/azure-ad-app-added-page.png
:white_check_mark:Succeeded
View

office-365-management-api/images/azure-ad-apps-page.png
:white_check_mark:Succeeded
View

office-365-management-api/images/azure-ad-page.png
:white_check_mark:Succeeded
View

office-365-management-api/images/azure-portal-page.png
:white_check_mark:Succeeded
View

office-365-management-api/images/azure-subscription-page.png
:white_check_mark:Succeeded
View

office-365-management-api/images/big_adm.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/big_arch.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/big_dev.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/big_kw.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/box.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/bullet.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/collall.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/collapse.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/collapse_all.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/command-line-certificate-display.png
:white_check_mark:Succeeded
View

office-365-management-api/images/copycode.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/copycodeHighlight.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/dev.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/dev_arch.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/dropdown.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/dropdownHover.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/drpdown.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/drpdown_orange.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/drpdown_orange_up.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/drpup.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/exp.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/expall.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/expand_all.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/filter1a.gif
:white_check_mark:Succeeded
View

office-365-management-api/images/filter1c.gif
:white_check_mark:Succeeded
View

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

also resolved docfx conflict across master and live


PlacePicker should keep its own state

Right now, when you add some place to selection, the context from PlacePicker is immediately changed and new request is send even without user confirmation.
There should be temporary internal state of the PlacePicker which will affect context after user "close the window" (which means confirm in this case).
Example:
When you are on Results screen and you will select multiple items (like Prague, Brno, Ostrava), there will be 3 requests:

Prague
Prague and Brno
Prague, Brno and Ostrava

instead of one.

Fixed in #906


Plug-in hooks and building a plug-in culture

Related: https://github.com/highlightjs/highlight.js/issues/2174
This thread might get long.  It'll try to summarize a list of hook points here and keep it up-to-date.  The overall idea is to encourage a plugin culture - rather than adding the 100 tiny ideas people approach us with as options and spread all over the code I'd rather have a plug-in ecosystem that make it easy to write tiny plugins to enhance Highlight.js in various ways.  Deciding WHERE the code for those plugins lives would be a separate consideration.  Perhaps really useful/popular ones would exist in core, perhaps others would live elsewhere.
Worth discussing how these might work with auto-highlight also... which is really a whole bunch of different highlights happening sequentially and then one "winning"...
Basically a plugin would register itself with Highlight.js and then it would be called at various hook points and thru these well defined hook points would be able to do various things. Examples to follow.
It's also worth considering if individual languages could also act as their own plugins... ie, allowing them to hook into all the same places - except only when they are being used to highlight the code.
Hook Ideas

Post-autodecect (called after auto-detection)
Input hook (called before highlighting)
Output hook (called before returning the result)
Post-parse hook (called after parse tree is generated)

Post auto-detect
Called after auto-detection is complete and all registered languages have been "scored".  Could change the relevancy of any of the results, thereby deciding which language is detected.
Input Hook
Would have access to the incoming state... such as relevancy, language, code, etc... could change any of these... increase relevancy, pre-filter the content, etc.
Output Hook
Called just prior to returning data... again could also any of the data in the return state...
Post-parse hook
Called after the parse tree is generated.  The plugin could alter the parse tree. Or access any of the other normal state information (relevancy score, etc).

Example: Tab-rejiggering, trimming
It's been requested that we strip whitespace from the beginning and ending of code blocks. Also if someone pastes code that has 5-7 tab stops for ALL of it you could imagine perhaps removing 5 tab stops therefor scooting that content over to the left.
These kind of things could trivially be handled by an input plugin.  Handed the raw code, they would tweak the spacing, and then pass that code along to be highlighted.

Example: shebang detection, #!/bin/ruby ...
This gets into auto detection, but vaguely one could imagine this being some type of input filter also... it would analyze the first line of code (even before highlighting) and then could "focus" the highlighter to a single language or be used to "bump" a certain languages rank so that it would have a "bonus" in the auto-detection game.

Example: Highlight duplicate HTML attributes
This could be easily done by walking the parse tree and dynamically flagging certain nodes to be highlighted with a different class, etc.

Example: Relevancy boosting for people who typically only use one type of code
https://github.com/highlightjs/highlight.js/issues/2194
A post-autodetect plugin could slightly favor a language the content author knew they ALMOST ALWAYS used, thereby preventing auto-detect from doing the wrong thing.  Say if you only blog about Pascal you could give it a 10% relevancy boost.

Example: Replacing the parser entirely with experimental parsers
https://github.com/highlightjs/highlight.js/issues/1133
An input plugin could do it's own parsing and if it returned a parseTree then Hightlight.js would simply skip it's own parsing and jump straight to output processing of the parseTree into HTML.

Nice idea!
I think of per-line output hook to allow to modify (already highlighted) HTML. E.g. add line numbers - there were lots of such requests.

You don’t  really need a per line hook if you can hook the whole output. Do you? Split, add stuff. Join.

Well, you'll have to deal with html tags spanning on several rows. To simplify this task, In per-line mode we probably can close opened tags on the end of line and then re-open them on the beginning of the next line.

Well, you'll have to deal with html tags spanning on several rows. To simplify this task, In per-line mode we probably can close opened tags on the end of line and then re-open them on the beginning of the next line.

Oh, I see.  Yeah that'd be a whole other thing.    I think there are MUCH easier ways to add line numbers than wrapping every line in a span though, but that's my opinion. :-)

I think there are MUCH easier ways to add line numbers than wrapping every line in a span though, but that's my opinion. :-)

Like what?

Like using grid or flex box and just having the line numbers in their own pre block...  what I've always done and it's worked well. Or you could probably even do a pre with two code elements, but same principle.

Not really opposed to that kind of hook (if someone else wants to write a plugin), but seems like needless complexity to me when to me there are easier ways to solve the problem. :-)

Reference regarding one idea for sharing options: https://github.com/highlightjs/highlight.js/issues/1969
Not sure it's the best approach, but I wanted to save it for future reference when we come up with more of a plan for plugins.

Related:
https://github.com/highlightjs/highlight.js/pull/2285

When adding plugin support I started with the easiest piece highlightBlock.  Now I'm looking at the more complex pieces, highlight and highlightAuto... and of course highlight is reentrant in that sublanguages a recursive call to highlight.
And highlightAuto simply calls highlight a bunch of times and picks the winner... so the question is are these details that plugins need to concern themselves with, or do we try to simplify/abstract this somehow?
I think the sublanguage thing is a bit nastier to understand, and I'm leaning towards another set of callbacks so that plugin authors don't have to concern themselves with sublanguage UNLESS they really want to:

before:highlight
after:highlight
before:highlight/sublanguage
after:highlight/sublanguage

So someone just wanting to hook top-level highlight calls just uses the first two, and they they are done. Otherwise almost every plugin would have to maintain state and a flag of how "deep" it was to know if it was being called initially or if it was being called on a sublanguage.  Perhaps there are some cases where plugin authors don't care and want EVERY highlight call treated the same (you're always trying to do some transform on a particular language, for example).
But I think those cases would be fewer and it's easy enough to just add the two extra hooks... while simplifying things for a lot of other plugin authors.

With regard to autoDetect the complexity bothers me a little less.  I guess I'm assuming many plugins will target explicit highlights or auto-highlights, not both.  If that were to be the case then those authors wouldn't even notice.  However someone who wanted to target auto and highlight would find their callbacks fired like this:

before:highlightAuto
before:highlight / after:highlight (first language)
before:highlight / after:highlight (2nd language)
before:highlight / after:highlight (3rd language)
...
...
after:highlightAuto

Is it just a plugin authors responsibility to keep this in mind?  I'm thinking perhaps it we provided some meta-state that would be enough:
    hljs.addPlugin( {
      'before:highlight': ({block, data}) => {
        if (data.flags.autodetect) return;

        // continue with normal processing
    })

Is there a reason one can care about explicit highlights but not about auto-highlights?
In fact, sublanguages often use auto-detection even when you call explicit highlight.

Is there a reason one can care about explicit highlights but not about auto-highlights?

Well off the top of my head you have different categories of plugins.  Or really maybe the difference isn't between auto-and-not, it's between "just one language" vs "ALWAYS".
IE:
*Just one language
I have a kick-ass plugin that does impossible language analysis and really cool stuff with C++ code (or perhaps even something trivially simple)... I don't care about auto-highlighting (in general).  If someone says the code is "C++" then I run OR if auto-detect decides the code is C++, then I run.  But in general when the 283 other languages are tested I don't give one flip - I only care about C++.
All languages
I want to strip all whitespace from before and after code blocks because whatever tool is building the HTML couldn't be bothered to do that properly - and for my use cases whitespace never matters.  In this case I want my plugin to ALWAYS run before, and modify the code by stripping whitespace... I don't care if we know the language, I don't care if it's auto-detect, etc... I just want to strip space.
I probably don't want to strip space from sublangague though.

What I want to avoid is a world where someone wants to write a "simple" plugin like one of the above but to do it has to hook 8 different hooks, and track whether highlight is being called initially, inside of auto-detect, inside of sublanguage, inside of a  nested sublanguage, etc...

There is kind of an implied split here we don't currently even have... "after:autodetect" and "before:highlight"... since the auto-detect is the highlight... it's possible my plugin would only want to act on C++ code once it had been determined it was actually C++ code, not just when the highlighter is GUESSING.

I try to avoid designing this stuff abstractly, so the current focus is https://github.com/highlightjs/highlight.js/issues/2391.
The idea being "detect frontmatter" and if present, possibly route to a particular grammar or else the plugin would take over parsing duties itself, calling two particular grammars internally.  And already you have a case where a plugin might want to recursively call highlight from inside itself... although I suppose in that case I assume the plugin would use internal state to prevent it from triggering on it's own callbacks?

the plugin would take over parsing duties itself, calling two particular grammars internally

Looks very complicated... In plugin you'd probably want to set boundaries of languages and let the core do the actual highlighting itself.
Maybe it's worth starting with that functionality? I.e. possibility to pass to highlightBlock a markup defining language boundaries.
Then you could change the markup in before:highlightBlock.

Looks very complicated... In plugin you'd probably want to set boundaries of languages and let the core do the actual highlighting itself.

That's what I'd do here.  The plugin would split the code into two pieces in a before hook... then call highlight(yaml) and highlight(markdown), then concat the two together, then return that result... hence "bypassing" the actual highlighting we'd have done ourselves on a single large block of code.
...but the plugin author would be free to choose what works best.  Perhaps they want to add support for a language that's really impossible to parse with pure regex but easy with a few lines of JS.  In that case they wouldn't need to call highlight at all.

possibility to pass to highlightBlock a markup defining language boundaries.

I don't know what you mean here but it sounds like the opposite of a plugin, sounds like adding features back to the core library.

Then you could change the markup in before:highlightBlock.

We already have before/after for highlightBlock... technically it'd be possible to write this plugin today if it only needed to work with highlightBlock, but highlightBlock is browser-only... and that's pretty limiting.  Most plugins are going to want to hook the actual library calls so that they would work inside NodeJS, etc. not just the browser environment.

But since you brought up highlightBlock right now it's kind of a "catch-all"... the plugin author would have to figure out if a language was specified or going to be auto-detected - they also have the power to change or control this behavior... they could run their own auto-detect for example... or flag anything containing a magic string as a given language, etc.

I think we want to hide/abstract the internals as much as we can so that our hooks all make sense but don't seem to be rooted too much in implementation details.  Say highlight (for some funny reason) calls itself 20 times just because of some quirk (even in simple cases).
Someone hooking before/after highlight would NOT expect their hook to be called 21 times... we'd want to abstract that.
So that's why I think we need to have separate hooks for before/sublanguage and after/sublangage... today they call highlight, but that's an implementation detail.  It could just as easily been a specialized method that was called instead of recursively calling the main method.
You could also make the same argument about auto-detect... TODAY it calls highlight a zillion times... but that's an implementation detail.  Other libraries have really good results with machine learning for language recognition. So in that case if I hooked highlight and highlightAuto I would NOT necessarily expect highlight to be called 284 times when a call to highlightAuto was made.

So I think that leaves us with more focusing on what is happening rather than internal method dispatch:

before/sublanguage
after/sublanguage
before/autodetect (triggered say 284+ times when highlightAuto is called, etc)
after/autodetect
before/highlight (external api call)
after/highlight (external api call)
before/highlightAuto (external api call)
after/highlightAuto (external api call)
before/highlightBlock (external api call)
after/highlightBlock (external api call)

So now you have clear boundaries for functionality.  If you wanted to ALWAYS touch say "pascal"  you'd need to hook sublanguage and highlight.
The last tricky party is when you mix sublanguage  and autodetect... Is a before/sublanguage/autodetect also needed?

Actually I don't think autodetect should trigger 284 times... that seems weird and very, very internal.  Should plugins need to care about every single time attempt the auto-detect makes at detection?  I need to think about this over coffee sometime.  Seems so much of this is easy to bend to be very implementation specific if we don't think about it right.

Say I've been given a snippet of text to auto-highlight. More abstractly if you think it terms of events:

Auto-detection
Highlighting

Highlighting sublanguage 1
Highlighting sublanguage 2

So I count 4 events there.  I could hook into before/after of each of the highlighting events.
If I hooked into BEFORE auto-detection I could write my own auto-detect, or influence the built in method (whatever it was).  If I hooked AFTER I could say look at the list of potential matches and make my own choice (so perhaps augmenting the built-in support).
I don't see a case there to call any hook 284 times.  That seems to be an implementation detail of how we currently do auto-detection.

I do agree with your thought process.
A thought: do we really need separate hooks for autodetection? We can have something like "choose language" with a list of alternatives. If there is just one, it corresponds to highlight; if there are some of them, it is highlightAuto.

We can have something like "choose language" with a list of alternatives. If there is just one, it corresponds to highlight; if there are some of them, it is highlightAuto.

I don't follow what you mean.

I mean you can treat anything like autodetection. But sometimes it can choose from exactly one predefined option.
This can help with

The last tricky party is when you mix sublanguage and autodetect... Is a before/sublanguage/autodetect also needed?

The last tricky party is when you mix sublanguage and autodetect... Is a before/sublanguage/autodetect also needed?

Actually I think that would work just like the parent... the question is would you need a "sublanguage/autodect" hook... IE, autodetect/sublangauge would fire (if it wasn't explicit) and then highlight/sublanguage would fire.

I mean you can treat anything like autodetection. But sometimes it can choose from exactly one predefined option.

I still don't follow you might have to give a very specific example of what you had in mind.

Nevermind. Your event system makes sense.
So, for a highlightAuto call you'll get the following series of events:

before/autodetect (here we can override autodetection)
after/autodetect (here we can choose one of potential matches)
before/highlight
after/highlight

Do I get it right?
Then how can you implement it, given that highlighting is done inside the autodetection foreach-loop?

here we can choose one of potential matches

Or decide they are all rubbish and do something else entirely. :)

Then how can you implement it, given that highlighting is done inside the autodetection foreach-loop

Well, honestly it'll help if you stop thinking about it that way. :-)  Instead think: Auto-detection is done.  One of the side-effects is that we also get the result of each potential highlight run, which may or may not always be useful.
So, we run the auto-detection... and (assuming another plugin hasn't provided it's own output) then we decide the language is say basic.  The final two events then (depending on what the plugin does with them are more virtual - but only because of our existing implementation).  So we'd fire before/highlight then after/highlight immediately after each other.  After highlight could use the cached result from our auto-detection.
UNLESS the plugin makes changes to code inside before/highlight in which case now the auto-detection was ONLY just that - autodection.  Now we have to actually run the highlight on the modified code to generate the actual result.

I'll probably start next with just before/highlight and after/highlight, which allow for a lot of useful plugins and save the auto/sublanguage stuff for when it's asked for.

A bigger question is plugin vs plugin interaction.  For example: I was just thinking about the API and how a plugin like frontmatter would handle it's own need to reuse highlightjs....
IE, frontmatter splits the content then calls highlight twice on each part... but really does it need to then ALSO handle those hooks and realize it's running inside itself and then just do nothing?  I thought, no... so you could have a flag skipPlugins:
header = highlight(yaml, {skipPlugins: true})
body = highlight(yaml, {skipPlugins: true})

But then do I really want to skip ALL plugins, or do I really want to skip ONLY myself?   Perhaps it's not too much to expect early plugins to deal with cruft like this and then after we see what the REAL problems are we circle back and try and fix them with plugins v2. :-)
IE, for now if you were using the external API to call highlight from within a hook you'd have to be careful to avoid infinite recursion and that's the plugin authors responsibility.

But then do I really want to skip ALL plugins, or do I really want to skip ONLY myself?

Learn it from the native event listener. We could define context.
function c() {}

a.addEventListener('b', c);
a.removeEventListener('b', c); // remove `c` only

So for skipPlugins we may have something like this:
function foo() {}
function bar() {}

{skipPlugins: true} // ignore all
{skipPlugins: [foo, bar]} // ignore `foo` and `bar` only

I'd like to see more plugins deal this themselves before we consider adding anything to core.  Right now it should be pretty easy for a single plugin to prevent re-entering ITSELF.  I'm not sure plugins should "be aware" of other plugins or be able to easily turn them on and off.
You should be able to add multiple plugins and trust that they all "just work" unless they do mutually exclusive things.  I don't want plugin A saying it doesn't work with plugin B so it just turns it on and off, etc...

Closing and referencing at https://github.com/highlightjs/highlight.js/issues/2762.


Make readme more friendly to first time contributors

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Make read me first time contributor friendly by adding  detailed steps.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Sir please assign this issue to me under iwoc medium/easy.

It's great having you contribute to this project Welcome to the community :nerd_face:  You should join our Discord chat - we help and encourage each other to contribute to open source little and often

Hey, @dhruv-porwal can you please tell me what steps we can add to the readME file?

We can make readme more friendly by adding contributing guidelines, an installation guide, key features of the app, more relevant screenshots, active issues, and PRs.

@dhruv-porwal @arpitghura can you please assign the issue to me, I'm interested in improving/fixing it

Hey @mdsahilnoob, Welcome to the community. Assigning you the task.


Autofocus stops working when flashlight turns on

Autofocus runs fine while the flashlight is left off. once flashlight is turned on, autofocus stops. this persists even when flashlight is turned off.
tested with sample code and also implemented the code below in my app:
torchState = !torchState;
mScannerFragment.setTorch(torchState);
device : Samsung Galaxy S4 Active (LTE)
OS : Lollipop
Root : no

Sorry for the late answer.
I have confirmed the same bug in the Moto X 2013, I'll take a look into this next week, thanks for reporting!


Refactor configuration

The lazily instantiated tracer is now available in jaeger config
instead of the jaxrs2 package
StatsFactory is no longer required to get a TracerBuilder from the config
Extract the tracer into a field where possible
Add the ability get a NoopTracer to Tracer.java

@yurishkuro


Notify users when they have invited 5 people to join Valora

Description
Unlike v1, the next iteration of invite rewards imposes a 5-invitation limit on inviters to limit the negative impact of poor quality inviters. We have opted to forego terms and conditions for this short test, but need to notify users of the 5-invitation limit somewhere. Given that we are opting to pop a modal once the user has sent five invitations to notify them that they might not be rewarded for more invitations.
Acceptance Criteria

When inviter selects a contact to invite, pop a modal to inform them of the 5-invite limit if they have already invited five people. Copy and design are here: https://www.figma.com/file/DL6Huw867n1EZOVPJ2kNmp/Invite-Rewards?node-id=1255%3A24693
Note that we don't need to know exactly how many invites produced rewards, just the number of invitations
In the scenario above, fire a modal impression event
When a user clicks 'send anyway', fire a click event

The backend keeps count of the invites issued so that no more than 5 will be distributed for the same user, but this information is not exposed to the front end. For this experiment, we will keep count of the number of invitations sent in the front end for displaying this modal. The tradeoff is that if a user reinstalls their app or imports to another device, this number will be reset and the user will not see this notificaiton until they have sent 5 invites on the same device.


Update datefirst-transact-sql.md

Text revisions to tighten and optimize the reading flow of the material.

@fbsolo : Thanks for your contribution! The author, @edmacauley, has been notified to review your proposed change.

Thanks again @fbsolo #sign-off


Add persistent layer

What this PR does / why we need it:
The PR is mainly adding the persistent layer in dataset-service, implementing read APIs (Get and List), and reimplementing deployment API behavior to leverage the persistent state. The detailed modification is as follow
Add Persistent Layer
The persistent layer is implemented under storage package. The package consists of 2 main parts: the storage interfaces and database migration. This PR implements storage.ObservationService and storage.LogWriter which stores the observation services and log writers state. Both storages exposes a consistent interface:

Get for retrieving a single entity given a GetInput argument. The GetInput itself accepts 3 components: ID, ProjectID, and Name. Currently, ID and ProjectID is used by other components in the dataset-service, but it's possible to also retrieve an entity using its name.
List for retrieving a list of entities. It accepts ListInput which controls the scope (in our case  ProjectID is always the scope of entities) and list options such as Offset and Limit. Offset and Limit are useful for pagination.
Create and Update, these 2 interfaces are more straightforward.

Migration scripts are stored under storage/migration and we use golang-migrate for DB migration. DB migration will be done every application startup inside the storage.InitDB function.
The database is configurable via config.DatabaseConfig. One important thing to note is that MigrationSourceURL is empty for local testing, however, it has to point to the correct file URL when we deploy in Kubernetes (i.e. the migration script must be copied to dataset-service docker image and the deployment must properly set the URL)
Update LogWriterController and ObservationServiceController
The updates in the controllers are mainly wiring up the Get and List APIs with the persistent layer. The second major modification is to reimplement how deployment, redeployment, and uninstalls are handled. Before this PR, deployment happens asynchronously by not waiting helm client to complete the deployment, which means that the deployment status can be in the DEPLOYED state but the pods are not ready. With this PR, deployment APIs will immediately return the transient PENDING state and the deployment happen in the background. Eventually, the deployment state will enter a non-transient state such as DEPLOYED, UNINSTALLED, or FAILED once the helm completed the requested operation.
A data translation layer is also added to the controller. Specifically, inside dataset-service we'll use internal representation of object such as LogWriter and ObservationService stored in model package. The controller is responsible to translate the proto messages into these internal representations when handling requests and translate them back to the proto message when sending the response. The main motivation to have this approach is to decouple the API and internal object representation.
Handle errors code properly
The errors package is added to introduce known application errors such as NotFoundError, InvalidInputError, and ConflictError. These known errors will be translated into known HTTP status codes (404 for NotFoundError, 400 for InvalidInputError, and 409 for ConflictError) by errors.Handler. Unknown errors will be handled as 500 as usual.
Other Modifications

Add database as part of development environment
Simplify helm interfaces, now it only provides ReadChart,InstallOrUpgrade and Uninstall. InstallOrUpgrade and Uninstall are idempotent which simplify the caller (i.e. services) implementation.

The rest LGTM.
Some concern not related to the PR but to highlight
First is the inconsistent styling across CaraML app. Various app uses openapi differently, the conversion logic of model to/from request/response is done in controller/model, the storage layer is access via service/controller, business logic in controller/service. While there is no definite style guide, I think it add complexity when it differs from maintenance POV and harder when revisiting and context switching.
One smaller concern is on the gRPC gateway and gRPC support. I think the gRPC calls were not functioning. Also the implementation wouldn't support it fully. For now its only error code which is small, it could possibly grow bigger with headers. We haven tried integrating prometheus and healthchecks on gRPC gateway (probably doable anyway). Merlin and Turing are using cmux while this is using the gateway for similar purpose (which brings back to my previous point of consistency as well).

@leonlnj @tiopramayudi I've added the follow up items from this PR feedbacks into our backlog. Can I merge this?

@leonlnj @tiopramayudi I've added the follow up items from this PR feedbacks into our backlog. Can I merge this?

LGTM, thanks @pradithya


Container directive does not properly contain all contents when attributes are specified.

Subject of the issue
I have a container directive that takes an optional argument theme. When I put a list inside the container, it is rendered within the container if there are no attribute braces and outside the container if there are braces and the closing ::: is rendered as text.
Your environment

OS: macOS Big Sur
Packages:

├─<EMAIL_ADDRESS>│  ├─<EMAIL_ADDRESS>

Env: node v15.5.0, yarn 1.22.5

Steps to reproduce
Without attribute braces:
:::card
**Test Content**

- This
- Is
- A
- List
:::

With attribute braces:
:::card{}
**Test Content**

- This
- Is
- A
- List
:::

Expected behavior
Both cards should render the same children.
Actual behavior
The card with attributes does not contain the list, and the closing ::: is rendered as text.

Thanks, released! https://github.com/micromark/micromark-extension-directive/releases/tag/1.1.2

Thanks, released! https://github.com/micromark/micromark-extension-directive/releases/tag/1.1.2


[Docs]: fix GitHub after install image which is the GitLab one

What type of suggestions?
Wrong Information
What page is concerned?
https://docs.kubefirst.io/kubefirst/github/after-install.html
What is the issue?
GitHub after install image is the GitLab one
Code of Conduct

[X] I agree to follow this project's Code of Conduct

That page was deleted.


Password must be less than 70 bytes....

Previously I was able to log in with my password which is 100 characters. Now it will not let me log in. See the error message in the attached screenshot.

Thank you

The IPT is now using the BCrypt hashing algorithm, which is limited to passwords of 71 bytes (often 71 characters).
There are workarounds.
I would prefer the SHA512 workaround, or else limiting the length when the password is set.

Thanks! Turns our we did an update that pulled in that change and so it invalidated my password. Our SysAdmin was able to reset my password.