Issue #37

@Cylix and @simpuc please take a look about what was being discussed on issue #37.
I just made a little change on the constructor (explict keyword) and included another constructor.
All tests seems to pass...
PS: To this fix works properly tacopie also needs some fix for the std::atomic issues. Should I do a pull request there too?
[----------] Global test environment set-up.
[----------] 25 tests from RedisClient
[ RUN      ] RedisClient.ValidConnectionDefaultParams
[       OK ] RedisClient.ValidConnectionDefaultParams (35 ms)
[ RUN      ] RedisClient.ValidConnectionDefinedHost
[       OK ] RedisClient.ValidConnectionDefinedHost (1 ms)
[ RUN      ] RedisClient.InvalidConnection
[       OK ] RedisClient.InvalidConnection (12 ms)
[ RUN      ] RedisClient.AlreadyConnected
[       OK ] RedisClient.AlreadyConnected (1 ms)
[ RUN      ] RedisClient.Disconnection
[       OK ] RedisClient.Disconnection (1 ms)
[ RUN      ] RedisClient.DisconnectionNotConnected
[       OK ] RedisClient.DisconnectionNotConnected (0 ms)
[ RUN      ] RedisClient.CommitConnected
[       OK ] RedisClient.CommitConnected (1 ms)
[ RUN      ] RedisClient.CommitNotConnected
[       OK ] RedisClient.CommitNotConnected (1 ms)
[ RUN      ] RedisClient.SyncCommitConnected
[       OK ] RedisClient.SyncCommitConnected (1 ms)
[ RUN      ] RedisClient.SyncCommitNotConnected
[       OK ] RedisClient.SyncCommitNotConnected (1 ms)
[ RUN      ] RedisClient.SyncCommitTimeoutConnected
[       OK ] RedisClient.SyncCommitTimeoutConnected (1 ms)
[ RUN      ] RedisClient.SyncCommitTimeoutNotConnected
[       OK ] RedisClient.SyncCommitTimeoutNotConnected (1 ms)
[ RUN      ] RedisClient.SyncCommitTimeout
[       OK ] RedisClient.SyncCommitTimeout (1001 ms)
[ RUN      ] RedisClient.SyncCommitNoTimeout
[       OK ] RedisClient.SyncCommitNoTimeout (1004 ms)
[ RUN      ] RedisClient.SendConnected
[       OK ] RedisClient.SendConnected (0 ms)
[ RUN      ] RedisClient.SendNotConnected
[       OK ] RedisClient.SendNotConnected (0 ms)
[ RUN      ] RedisClient.SendConnectedSyncCommitConnected
[       OK ] RedisClient.SendConnectedSyncCommitConnected (1 ms)
[ RUN      ] RedisClient.SendNotConnectedSyncCommitConnected
[       OK ] RedisClient.SendNotConnectedSyncCommitConnected (1 ms)
[ RUN      ] RedisClient.SendNotConnectedSyncCommitNotConnectedSyncCommitConnected
[       OK ] RedisClient.SendNotConnectedSyncCommitNotConnectedSyncCommitConnected (1 ms)
[ RUN      ] RedisClient.Send
[       OK ] RedisClient.Send (1 ms)
[ RUN      ] RedisClient.MultipleSend
[       OK ] RedisClient.MultipleSend (1 ms)
[ RUN      ] RedisClient.MultipleSendPipeline
[       OK ] RedisClient.MultipleSendPipeline (1 ms)
[ RUN      ] RedisClient.DisconnectionHandlerWithQuit
[       OK ] RedisClient.DisconnectionHandlerWithQuit (101 ms)
[ RUN      ] RedisClient.DisconnectionHandlerWithoutQuit
[       OK ] RedisClient.DisconnectionHandlerWithoutQuit (2012 ms)
[ RUN      ] RedisClient.ClearBufferOnError
[       OK ] RedisClient.ClearBufferOnError (3 ms)
[----------] 25 tests from RedisClient (4206 ms total)

[----------] 29 tests from RedisSubscriber
[ RUN      ] RedisSubscriber.ValidConnectionDefaultParams
[       OK ] RedisSubscriber.ValidConnectionDefaultParams (1 ms)
[ RUN      ] RedisSubscriber.ValidConnectionDefinedHost
[       OK ] RedisSubscriber.ValidConnectionDefinedHost (1 ms)
[ RUN      ] RedisSubscriber.InvalidConnection
[       OK ] RedisSubscriber.InvalidConnection (1 ms)
[ RUN      ] RedisSubscriber.AlreadyConnected
[       OK ] RedisSubscriber.AlreadyConnected (1 ms)
[ RUN      ] RedisSubscriber.Disconnection
[       OK ] RedisSubscriber.Disconnection (0 ms)
[ RUN      ] RedisSubscriber.DisconnectionNotConnected
[       OK ] RedisSubscriber.DisconnectionNotConnected (0 ms)
[ RUN      ] RedisSubscriber.CommitConnected
[       OK ] RedisSubscriber.CommitConnected (0 ms)
[ RUN      ] RedisSubscriber.CommitNotConnected
[       OK ] RedisSubscriber.CommitNotConnected (1 ms)
[ RUN      ] RedisSubscriber.SubscribeConnected
[       OK ] RedisSubscriber.SubscribeConnected (1 ms)
[ RUN      ] RedisSubscriber.PSubscribeConnected
[       OK ] RedisSubscriber.PSubscribeConnected (1 ms)
[ RUN      ] RedisSubscriber.UnsubscribeConnected
[       OK ] RedisSubscriber.UnsubscribeConnected (1 ms)
[ RUN      ] RedisSubscriber.PUnsubscribeConnected
[       OK ] RedisSubscriber.PUnsubscribeConnected (0 ms)
[ RUN      ] RedisSubscriber.SubscribeNotConnected
[       OK ] RedisSubscriber.SubscribeNotConnected (0 ms)
[ RUN      ] RedisSubscriber.PSubscribeNotConnected
[       OK ] RedisSubscriber.PSubscribeNotConnected (0 ms)
[ RUN      ] RedisSubscriber.UnsubscribeNotConnected
[       OK ] RedisSubscriber.UnsubscribeNotConnected (0 ms)
[ RUN      ] RedisSubscriber.PUnsubscribeNotConnected
[       OK ] RedisSubscriber.PUnsubscribeNotConnected (0 ms)
[ RUN      ] RedisSubscriber.SubConnectedCommitConnected
[       OK ] RedisSubscriber.SubConnectedCommitConnected (3 ms)
[ RUN      ] RedisSubscriber.SubNotConnectedCommitConnected
[       OK ] RedisSubscriber.SubNotConnectedCommitConnected (2 ms)
[ RUN      ] RedisSubscriber.SubNotConnectedCommitNotConnectedCommitConnected
[       OK ] RedisSubscriber.SubNotConnectedCommitNotConnectedCommitConnected (2003 ms)
[ RUN      ] RedisSubscriber.SubscribeSomethingPublished
[       OK ] RedisSubscriber.SubscribeSomethingPublished (2 ms)
[ RUN      ] RedisSubscriber.SubscribeMultiplePublished
[       OK ] RedisSubscriber.SubscribeMultiplePublished (2 ms)
[ RUN      ] RedisSubscriber.SubscribeNothingPublished
[       OK ] RedisSubscriber.SubscribeNothingPublished (2001 ms)
[ RUN      ] RedisSubscriber.MultipleSubscribeSomethingPublished
[       OK ] RedisSubscriber.MultipleSubscribeSomethingPublished (3 ms)
[ RUN      ] RedisSubscriber.PSubscribeSomethingPublished
[       OK ] RedisSubscriber.PSubscribeSomethingPublished (2 ms)
[ RUN      ] RedisSubscriber.PSubscribeMultiplePublished
[       OK ] RedisSubscriber.PSubscribeMultiplePublished (3 ms)
[ RUN      ] RedisSubscriber.PSubscribeNothingPublished
[       OK ] RedisSubscriber.PSubscribeNothingPublished (2002 ms)
[ RUN      ] RedisSubscriber.MultiplePSubscribeSomethingPublished
[       OK ] RedisSubscriber.MultiplePSubscribeSomethingPublished (3 ms)
[ RUN      ] RedisSubscriber.Unsubscribe
[       OK ] RedisSubscriber.Unsubscribe (3 ms)
[ RUN      ] RedisSubscriber.PUnsubscribe
[       OK ] RedisSubscriber.PUnsubscribe (2 ms)
[----------] 29 tests from RedisSubscriber (6076 ms total)

[----------] 6 tests from Reply
[ RUN      ] Reply.NullReply
[       OK ] Reply.NullReply (1 ms)
[ RUN      ] Reply.Error
[       OK ] Reply.Error (0 ms)
[ RUN      ] Reply.BulkString
[       OK ] Reply.BulkString (0 ms)
[ RUN      ] Reply.SimpleString
[       OK ] Reply.SimpleString (1 ms)
[ RUN      ] Reply.Integer
[       OK ] Reply.Integer (2 ms)
[ RUN      ] Reply.Array
[       OK ] Reply.Array (1 ms)
[----------] 6 tests from Reply (10 ms total)

[----------] 7 tests from ArrayBuilder
[ RUN      ] ArrayBuilder.WithNoData
[       OK ] ArrayBuilder.WithNoData (0 ms)
[ RUN      ] ArrayBuilder.WithNotEnoughData
[       OK ] ArrayBuilder.WithNotEnoughData (0 ms)
[ RUN      ] ArrayBuilder.WithPartOfEndSequence
[       OK ] ArrayBuilder.WithPartOfEndSequence (0 ms)
[ RUN      ] ArrayBuilder.WithAllInOneTime
[       OK ] ArrayBuilder.WithAllInOneTime (0 ms)
[ RUN      ] ArrayBuilder.WithAllInMultipleTimes
[       OK ] ArrayBuilder.WithAllInMultipleTimes (0 ms)
[ RUN      ] ArrayBuilder.EmptyArray
[       OK ] ArrayBuilder.EmptyArray (0 ms)
[ RUN      ] ArrayBuilder.InvalidSize
[       OK ] ArrayBuilder.InvalidSize (0 ms)
[----------] 7 tests from ArrayBuilder (7 ms total)

[----------] 6 tests from BuildersFactory
[ RUN      ] BuildersFactory.Array
[       OK ] BuildersFactory.Array (0 ms)
[ RUN      ] BuildersFactory.BulkString
[       OK ] BuildersFactory.BulkString (0 ms)
[ RUN      ] BuildersFactory.Error
[       OK ] BuildersFactory.Error (0 ms)
[ RUN      ] BuildersFactory.Integer
[       OK ] BuildersFactory.Integer (0 ms)
[ RUN      ] BuildersFactory.SimpleString
[       OK ] BuildersFactory.SimpleString (0 ms)
[ RUN      ] BuildersFactory.Unknown
[       OK ] BuildersFactory.Unknown (0 ms)
[----------] 6 tests from BuildersFactory (8 ms total)

[----------] 9 tests from BulkStringBuilder
[ RUN      ] BulkStringBuilder.WithNoData
[       OK ] BulkStringBuilder.WithNoData (0 ms)
[ RUN      ] BulkStringBuilder.WithNotEnoughData
[       OK ] BulkStringBuilder.WithNotEnoughData (0 ms)
[ RUN      ] BulkStringBuilder.WithPartOfEndSequence
[       OK ] BulkStringBuilder.WithPartOfEndSequence (0 ms)
[ RUN      ] BulkStringBuilder.Null
[       OK ] BulkStringBuilder.Null (0 ms)
[ RUN      ] BulkStringBuilder.WithAllInOneTime
[       OK ] BulkStringBuilder.WithAllInOneTime (0 ms)
[ RUN      ] BulkStringBuilder.WithAllInMultipleTimes
[       OK ] BulkStringBuilder.WithAllInMultipleTimes (0 ms)
[ RUN      ] BulkStringBuilder.WithAllInMultipleTimes2
[       OK ] BulkStringBuilder.WithAllInMultipleTimes2 (0 ms)
[ RUN      ] BulkStringBuilder.WithAllInMultipleTimes3
[       OK ] BulkStringBuilder.WithAllInMultipleTimes3 (0 ms)
[ RUN      ] BulkStringBuilder.InvalidEndSequence
[       OK ] BulkStringBuilder.InvalidEndSequence (0 ms)
[----------] 9 tests from BulkStringBuilder (8 ms total)

[----------] 7 tests from ErrorBuilder
[ RUN      ] ErrorBuilder.WithNoData
[       OK ] ErrorBuilder.WithNoData (0 ms)
[ RUN      ] ErrorBuilder.WithNotEnoughData
[       OK ] ErrorBuilder.WithNotEnoughData (0 ms)
[ RUN      ] ErrorBuilder.WithPartOfEndSequence
[       OK ] ErrorBuilder.WithPartOfEndSequence (0 ms)
[ RUN      ] ErrorBuilder.WithAllInOneTime
[       OK ] ErrorBuilder.WithAllInOneTime (0 ms)
[ RUN      ] ErrorBuilder.WithAllInMultipleTimes
[       OK ] ErrorBuilder.WithAllInMultipleTimes (0 ms)
[ RUN      ] ErrorBuilder.WithAllInMultipleTimes2
[       OK ] ErrorBuilder.WithAllInMultipleTimes2 (0 ms)
[ RUN      ] ErrorBuilder.WithAllInMultipleTimes3
[       OK ] ErrorBuilder.WithAllInMultipleTimes3 (0 ms)
[----------] 7 tests from ErrorBuilder (8 ms total)

[----------] 10 tests from IntegerBuilder
[ RUN      ] IntegerBuilder.WithNoData
[       OK ] IntegerBuilder.WithNoData (0 ms)
[ RUN      ] IntegerBuilder.WithNotEnoughData
[       OK ] IntegerBuilder.WithNotEnoughData (0 ms)
[ RUN      ] IntegerBuilder.WithPartOfEndSequence
[       OK ] IntegerBuilder.WithPartOfEndSequence (0 ms)
[ RUN      ] IntegerBuilder.WithAllInOneTime
[       OK ] IntegerBuilder.WithAllInOneTime (0 ms)
[ RUN      ] IntegerBuilder.With64BitInteger
[       OK ] IntegerBuilder.With64BitInteger (0 ms)
[ RUN      ] IntegerBuilder.NegativeNumber
[       OK ] IntegerBuilder.NegativeNumber (0 ms)
[ RUN      ] IntegerBuilder.WithAllInMultipleTimes
[       OK ] IntegerBuilder.WithAllInMultipleTimes (0 ms)
[ RUN      ] IntegerBuilder.WithAllInMultipleTimes2
[       OK ] IntegerBuilder.WithAllInMultipleTimes2 (0 ms)
[ RUN      ] IntegerBuilder.WithAllInMultipleTimes3
[       OK ] IntegerBuilder.WithAllInMultipleTimes3 (0 ms)
[ RUN      ] IntegerBuilder.WrongChar
[       OK ] IntegerBuilder.WrongChar (0 ms)
[----------] 10 tests from IntegerBuilder (13 ms total)

[----------] 5 tests from ReplyBuilder
[ RUN      ] ReplyBuilder.WithNoData
[       OK ] ReplyBuilder.WithNoData (0 ms)
[ RUN      ] ReplyBuilder.WithNotEnoughData
[       OK ] ReplyBuilder.WithNotEnoughData (0 ms)
[ RUN      ] ReplyBuilder.WithPartOfEndSequence
[       OK ] ReplyBuilder.WithPartOfEndSequence (0 ms)
[ RUN      ] ReplyBuilder.WithAllInOneTime
[       OK ] ReplyBuilder.WithAllInOneTime (0 ms)
[ RUN      ] ReplyBuilder.WithAllInMultipleTimes
[       OK ] ReplyBuilder.WithAllInMultipleTimes (0 ms)
[----------] 5 tests from ReplyBuilder (4 ms total)

[----------] 7 tests from SimpleStringBuilder
[ RUN      ] SimpleStringBuilder.WithNoData
[       OK ] SimpleStringBuilder.WithNoData (0 ms)
[ RUN      ] SimpleStringBuilder.WithNotEnoughData
[       OK ] SimpleStringBuilder.WithNotEnoughData (0 ms)
[ RUN      ] SimpleStringBuilder.WithPartOfEndSequence
[       OK ] SimpleStringBuilder.WithPartOfEndSequence (0 ms)
[ RUN      ] SimpleStringBuilder.WithAllInOneTime
[       OK ] SimpleStringBuilder.WithAllInOneTime (0 ms)
[ RUN      ] SimpleStringBuilder.WithAllInMultipleTimes
[       OK ] SimpleStringBuilder.WithAllInMultipleTimes (0 ms)
[ RUN      ] SimpleStringBuilder.WithAllInMultipleTimes2
[       OK ] SimpleStringBuilder.WithAllInMultipleTimes2 (1 ms)
[ RUN      ] SimpleStringBuilder.WithAllInMultipleTimes3
[       OK ] SimpleStringBuilder.WithAllInMultipleTimes3 (1 ms)
[----------] 7 tests from SimpleStringBuilder (8 ms total)

[----------] Global test environment tear-down
[==========] 111 tests from 10 test cases ran. (10362 ms total)
[  PASSED  ] 111 tests.

Hi,
Thanks a lot for the PR, saves me some time and I appreciate a lot :)
There is apparently an issue with the build on Mac+clang. I checked on my phone and I think it might be because  is not included in redis_error.hpp. I can't check for now, but will try to fix that tonight if you can't do it in the meantime.
As for tacopie, you can do a PR too (I'm the owner of the library), that would be awesome!
Thanks again :)

I did a PR on tacopie also, everything looks good.
If you accept the PR on tacopie first, i think we can build here again without any errors.
For me, seems this error is coming from tacopie (because it's not fixed yet).
I'm not sure how you will manage this dependency issue.

Not exactly related, but tacopie is a dependency since 3.0.0, right?

cpp_redis has no dependency. Its only requirement is C++11.

Maybe you should update your README.md.

Ok, I did have a look.
The compilation error on mac+clang was fixed by adding the #include <string> in the redis_error.hpp file.
Moreover, I also got some warnings on mac+clang concerning the usage of ATOMIC_VAR_INIT: braces around scalar initializer [-Wbraced-scalar-init].
AFter some searches, did find a relevant post about it: https://llvm.org/bugs/show_bug.cgi?id=23899.
So I updated the PR to use the right syntax (aka atomic_bool var = ATOMIC_VAR_INIT(val) instead of var(ATOMIC_VAR_INIT(val)).
Travis looks fine with the changes, so I merge: do not hesitate to come back to me if there is still any issue.
I also merged PR on tacopie, making the same changes concerning ATOMIC_VAR_INIT.
Thanks again a loooot for this, that's really cool!
Have a nice one :)

Hello @Cylix, thanks for your time and the library, but seems we have a problem 😕
On the attempt to fix the warnings on mac+clang, msvc 2013 builds got broken again (cpp_redis and tacopie).
I'm doing some tests here now and I'll let you know.
If I get to some workaround, I'll do another PR, ok?
[]'s

Thanks for your time too, I really appreciate :)
Waiting for the travis result and I merge that!
I hope you'll be satisfy with cpp_redis.

I confirm the resolution
Thank you


[IOTDB-1462] fix cross space compaction recover use wrong storage group name bug

Problem
Currently, when we recover cross space compaction, We pass ${logicalStorageName}-${virtualStorageGroupId} to find its timeseries in MManager which must be empty.
Solution
Only pass storageGroupName to MManager.

Coverage decreased (-0.01%) to 67.869% when pulling 96db3744dba80bc59192766ed5c55e2c7fd2df2c on fix_cross_space_compaction_recover_bug into 81e8949e1f54cbf7974e12788cff5ec58de1aba6 on master.


relation link

I'm not really sure how I feel about this.
You are searching for the DataType in every single row.
2 relationships and 25 results per page results in 50 additional queries, of which 49 are not necessary.
I think this should be implemented in a controller.

Agreed.  That code should live elsewhere

Closing as the fork was deleted.


Create colour suggestions – Button 2.0. Compare defined colour choices against using the Mix Modifier in Tokens Studio

A proposal is ready for review, @vnys


Ignore NoClassDefFoundError in obtainTokenForHiveMetastore()

This follows the same approach used by obtainTokenForHBase()
Thanks to Chester who discovered the discrepancy in the thread 'Possible bug on Spark Yarn Client (1.5.1) during kerberos mode'

Merged build triggered.

Merged build started.

Test build #44123 has started for PR 9213 at commit 3721bc9.

Test build #44123 has finished for PR 9213 at commit 3721bc9.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):\n  * class MutableUnsafeRow(val writer: UnsafeRowWriter) extends GenericMutableRow(null) \n

Merged build finished. Test PASSed.

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

I have the same question as in a different change. How does this occur? it means Spark was compiled with Hive, and it wasn't present at runtime, which seems like a more fatal error.

@tedyu you know you also need to create JIRAs; I think you've been around long enough to read https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark  But, I am not sure this change should be made.

I presented the change to get some feedback.
If the feedback is affirmative, I will create JIRA.

@tedyu next time can you create a JIRA first and then send out the change? That allows us to decouple the fix from the problem so others may submit alternative fixes if they want.

Andrew:
Steve logged SPARK-11265 whose scope seems wider than not failing the job.
If his PR for SPARK-11265 doesn't encompass mine, I will create another JIRA.
Otherwise I will close this one.

Please just include it in the PR description even if you're not sure. If it doesn't apply we can always file a new JIRA.

Should be covered by SPARK-11265


Close to tray

Hi,
Visual Studio Code can take some time to open (especially visible on laptops or slow HDD).
I'm not aware if this feature already exists (integrated or provided by some extension), but it would nice if it started at boot, minimized to tray and close button would also minimize it to tray.

Duplicate of #11723


Typo in net_plotter.py

Hey,
I came across a little bug in net_plotter.normalize_direction(..) (line 125) for norm='dfilter'. Typed ngorm, should be norm
Regards

Thanks for the report! Just fixed it.


Support for Django 3

django.utils.encoding.python_2_unicode_compatible() - Alias of six.python_2_unicode_compatible().

Codecov Report

Merging #1175 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master    #1175   +/-   ##
=======================================
  Coverage   70.98%   70.98%
=======================================
  Files          63       63
  Lines        3102     3102
  Branches      444      444
=======================================
  Hits         2202     2202
  Misses        747      747
  Partials      153      153

Impacted Files
Coverage Δ

filer/templatetags/filer_image_tags.py
35.71% <100%> (ø)
:arrow_up:

filer/models/abstract.py
75.89% <100%> (ø)
:arrow_up:

filer/models/filemodels.py
85.5% <100%> (ø)
:arrow_up:

filer/utils/loader.py
83.33% <100%> (ø)
:arrow_up:

filer/models/thumbnailoptionmodels.py
90% <100%> (ø)
:arrow_up:

filer/utils/recursive_dictionary.py
55.55% <100%> (ø)
:arrow_up:

filer/templatetags/filer_tags.py
43.63% <100%> (ø)
:arrow_up:

filer/utils/compatibility.py
61.29% <100%> (ø)
:arrow_up:

filer/fields/multistorage_file.py
87.87% <100%> (ø)
:arrow_up:

filer/thumbnail_processors.py
50% <100%> (ø)
:arrow_up:

... and 3 more

Continue to review full report at Codecov.

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


[REQUEST] Manage the scripts output by a command

Is your feature request related to a problem? Please describe.
I want to manage the scripts output by a command more easily.
e.g. pyenv
if [[ -n "$PYENV_ROOT" && -d "$PYENV_ROOT" ]]; then
    if [[ ! -f "${PYENV_ROOT}/zpyenv.zsh" ]]; then
        {
            pyenv init - --no-rehash zsh
            pyenv virtualenv-init - zsh
        } >"${PYENV_ROOT}/zpyenv.zsh"
    fi

    zinit snippet "${PYENV_ROOT}/zpyenv.zsh"
fi

e.g. kubectl completion
if [[ "${+commands[kubectl]}" == 1 ]]; then
    if [[ ! -f "${ZDOTDIR}/kubectl_completion.zsh" ]]; then
        kubectl completion zsh >"${ZDOTDIR}/kubectl_completion.zsh"
    fi

    zinit ice wait''
    zinit snippet "${ZDOTDIR}/kubectl_completion.zsh"
fi

Describe the solution you'd like
# kubectl completion will be created and compiled
zinit ice if'[[ "${+commands[kubectl]}" == 1 ]]' wait''
zinit eval 'kubectl completion zsh'

# kubectl completion will be also updated
zinit update

While the syntax isn't quite ideal here's what I am using currently do that:
zinit light-mode lucid wait has"kubectl" for \
  OMZP::kubectl \
  id-as"kubectl_completion" \
  as"completion" \
  atclone"kubectl completion zsh > _kubectl" \
  atpull"%atclone" \
  run-atpull \
    zdharma/null

The solution from @pschmitt works, but I believe it only creates the completion once. If something in the CLI changes, the completion would not update accordingly. Obviously, creating hooks for programs not managed by zinit is a whole different story ...
However, it would be great if there was a hook for programs that are managed by zinit. For instance, if I include a (gzipped) github binary using zinit, I would like to have a hook that I can use to update these built-in completions. Unfortunately atpull/atclone are executed before extracting the downloaded archive (thus, the binary is not yet available) and atload/atinit are executed too often for this case. Is there already any hook I could use for that?

The solution from @pschmitt works, but I believe it only creates the completion once. If something in the CLI changes, the completion would not update accordingly. Obviously, creating hooks for programs not managed by zinit is a whole different story ...
However, it would be great if there was a hook for programs that are managed by zinit. For instance, if I include a (gzipped) github binary using zinit, I would like to have a hook that I can use to update these built-in completions. Unfortunately atpull/atclone are executed before extracting the downloaded archive (thus, the binary is not yet available) and atload/atinit are executed too often for this case. Is there already any hook I could use for that?

would zinit creinstall kubectl_completion work just fine?

You could invoke ziextract --auto manually in the atclone''/atpull'' ices to virtually have the same effect as extract'' executing before them.


[admin-theme] Allow specifying custom CSS and JS

We should add a few settings to the admin_theme module allowing to supply custom CSS and JS files; these should be lists of strings containing URLs to the static files (as users may add multiple files if they need), static files have to be deployed in separate steps (this should be made clear in the README).
Settings could be named:
OPENWISP_ADMIN_THEME_CSS and OPENWISP_ADMIN_JS
As usual we need tests and docs for this feature.

Means it's kind of custom theming ?

Working on it!

While working on it, I developed some thoughts on how this can be made more useful. Instead of passing only URLs of static files, we can take care of static files by code. The user will have to only add the directory in STATICFILES_DIRS. I am in favor of something like this.
OPENWISP_ADMIN_JS = {
    "cdn" : [
        {
            "src" : "",
            "integrity" : "",
        }
    ]
    "statics" : [
        "path/to/static/file"
    ]
}

This will surely make things a little more complex. What is your opinion on it?

Instead of passing only URLs of static files, we can take care of static files by code

I am not sure if I understand this properly. :-(

Means you are saying something like the user should have an theme file saved in a particular directory and whenever the
"statics" : [         "path/to/static/file"     ]
is triggered it will render the file present in that directory right ?
Sorry if it's wrong :smile:

Yes! @IAmAMissingColon


GUI doesn't respond

Made the necessary adjustments to the GUI python file (changing COM ports and corresponding paths) and the python file runs but unfortunately the app isn't responsive. Is there any solution to this issue?

Unquote time.sleep(0.04) in VitalSign.py and it will respond!

which firmware or image file did you guys use for iwr6843aop?


Typo on the page

Issue in ./help/troubleshooting/miscellaneous/adobe-commerce-244-update-composer.md
This articles provides a solution to avoid the issue with composer plugins when upgrading from Adobe Commerce 2.4.3 and erlier to Adobe Commerce 2.4.4 or higher (when future versions are released).
This should be earlier

jira ticket: https://jira.corp.adobe.com/browse/MSKB-1883

@ak77-prime Hi Anthony thanks for spotting this typo.

@ak77-prime I made this update in a PR in the enterprise/internal repo here https://git.corp.adobe.com/AdobeDocs/commerce-knowledge-base.en/pull/94
I am now going to close this issue https://experienceleague.adobe.com/docs/commerce-knowledge-base/kb/troubleshooting/miscellaneous/adobe-commerce-244-update-composer.html?lang=en


Turn Active Learning On

The docs misses how to actually turn Active Learning On.

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

ID: fcd7d96a-7def-6b8b-2753-2904737ac743
Version Independent ID: e71a1b3f-da7c-e79e-8bdf-54a5ecf8d8ca
Content: Active learning suggestions - QnA Maker - Azure Cognitive Services
Content Source: articles/cognitive-services/QnAMaker/Concepts/active-learning-suggestions.md
Service: cognitive-services
Sub-service: qna-maker
GitHub Login: @nerajput1607
Microsoft Alias: nerajput

@manknewl we'll review your feedback and get back to you shortly. Thanks.

@manknewl - Thanks again for reporting the issue. The doc is now published at https://docs.microsoft.com/en-us/azure/cognitive-services/qnamaker/how-to/use-active-learning#turn-on-active-learning-for-alternate-questions.
#please-close


ADTTE vignette & template

if anybody particularly wanted to work on this let me know but otherwise i'll take it as having drafted the workflow it should be easier for me to set these up.

Include some extra non standard examples like Time to Progression

@bundfussr do we need an admiralonco version of the list_tte_source_objects code at https://github.com/pharmaverse/admiral/blob/main/R/derive_param_tte.R so that i can create the equivalent onco table as per https://pharmaverse.github.io/admiral/articles/bds_tte.html#pre-defined-time-to-event-source-objects? if so any ideas where i should put it?

yes makes sense @bundfussr, let's go for a similar convention to what Thomas suggests for https://github.com/pharmaverse/admiral/issues/1205. Are you ok to make an admiral issue for this and make the required updates please? https://github.com/pharmaverse/admiral/pull/1210 might help here. i've drafted the ADTTE vignette, but would need this, our test ADRS, and onco_tte_sources from Matt before i can test it and get it ready for review

@bundfussr should https://github.com/pharmaverse/admiralonco/issues/31 actually be called tte_sources instead of onco_tte_sources then as well? or could the helper object name also be an argument we pass to list_tte_source_objects()?

@rossfarrugia , yes, the title is a bit misleading. We do not need to create a new class. We just want to create some tte_source objects. I assume they should be used as examples because their definition includes the PARAMCD value, which is company specific. I would expect that the major part of tte_source objects is defined at company level. I have added this task to the oncology issue at admiralroche.

I have created https://github.com/pharmaverse/admiral/issues/1212 for the list_tte_source_objects() update.


How can I use jax to generate code for backward pass?

Hi,
I want to use jax to autogenerate a code for calculating the backward pass. Any idea where to begin?
For Example given this:
def sigmoid(x):
    return 1. / (1. + np.exp(-x))

I want to generate:
def sigmoid_backward(x):
        return 1. / (1. + np.exp(-x)) * (1. - 1. / (1. + np.exp(-x)))

There is commercial software doing the same (as far as I understand) for C++ and they have a
prototype. You can search for some literature on their website.
I think it would be great to have something along the same lines available in jax.

Thanks for the question!
When you say "I want to generate: [Python code]", do you mean you want to generate Python source text? I'm going to assume yes, but correct me if I'm wrong. (If you just want a Python callable, take a look at JAX's autodiff cookbook.)
Generating Python source text is outside of JAX's scope. However, have you looked at Tangent? It might do exactly what you want.
(By the way, I think your sigmoid_backward computes the derivative of sigmoid, i.e. the coefficients of the Jacobian, but it doesn't implement a backward pass, i.e. what we would call a vector-Jacobian product, or VJP. To be a VJP, it needs to take another argument, namely the "incoming gradients" shaped like the output.)

Since we've got a lot of issues, if Tangent is a good fit for what you need, let us know so we can close this one!

Yes, although tangent is not complete at least it showed me the way. Thanks.


Publication preview image not enlarged on click

Have you checked that your issue isn't already filed?

[X] I read through FAQ and searched through the past issues, none of which addressed my issue.
[X] Yes, I have checked that this issue isn't already filed.

Bug description
Publication preview thumbnails are not enlarged and displayed at original size upon mouse click
How to reproduce the bug

Go to any publication entry with a preview image which originally is of larger size than the thumbnail (e.g., any image from my personal site).
Click on the thumbnail to zoom in.
The image is centered but still displayed at the same small (and unreadable) size.

Error messages and logs
No error message.
What operating system are you using?
Not applicable (e.g. you're using GitHub Pages or other hosting)
Where are you seeing the problem on?
Deployed site
More info
A publication thumbnail is displayed at a reduced size by default, which is supposed to be centered, enlarged, and displayed at its original size upon click. In reality, the thumbnail is simply centered without any size change.
According to @george-gca from #2662

imagemagick creates a reduced version of those images, since they are displayed in this location at a really small size, and simply doesn't use the original version.

I was struggling with the same thing, so I dug into it. I think this is not technically a bug, but instead the interaction of non-obvious expected behavior from two different plugins:

jekyll-imagemagick only scales images down (not up)
medium-zoom calculates the zoomed size based on what's in sizes, not the source image's actual dimensions

jekyll-imagemagick only scales images down (not up)

All the details are in here…
It turns out that small original images aren't being resized at all, because jekyll-imagemagick is hard-coded to request that Image Magick shrink images, not enlarge them. This is a big part of why the tiny gif preview images in the example site content don't enlarge.
In the jekyll-imagemagick source,  the line that constructs the Image Magick -resize command is:

cmd += "-resize "#{long_edge}>" #{resize_flags} "

You can also see this by examining what jekyll-imagemagick prints to the Jekyll logs, which looks like:

Imagemagick: Running command "convert "/path/to/assets/img/1.jpg" -quality 85 -resize "1400>" "/path/to/_site/assets/img/1-1400.webp""

The > in the geometry "shrinks an image with dimension(s) larger than the corresponding width and/or height argument(s)" (source).

…but the TL;DR is: images that start out with a width smaller than what's requested in site.imagemagick.widths will be output without any resizing, no matter what their file names claim.
If you inspect the responsive images created by jekyll-imagemagick for the example site content, images that are supposed to be 1400px wide are still 800px wide, since the originals are all 800px wide. This means the default srcset is also mis-specified, since width descriptors are supposed to match the actual image widths.
What to do about it?
Most immediately, perhaps the documentation of this feature in al-folio and the example content could clarify for users what to expect? Namely:

Images will only be down-scaled (never up-scaled)
The largest size in site.imagemagick.widths should be smaller than your smallest image width, otherwise you will be needlessly generating (and incorrectly plugging into srcset) duplicate images with unchanged size.

People who are up for customizing might want to look into the other responsive image plugins out there, some of which offer more flexibility.
So for @WYF99, the upper limit on the zoomed thumbnail size will be 480px wide, even though there are images in the srcset that claim to be 800px and 1400px (they aren't – they're all 480px, too). But that doesn't solve the tiny zoom problem, since the zoomed previews often aren't even making it to 480px wide. That's because…
medium-zoom calculates the zoomed size based on what's in sizes, not the source image's actual dimensions
On @WYF99 's page, the thumbnails have been given sizes="200px". The thumbnails actually render at 70px–125px width (depending on viewport size) for the larger Bootstrap breakpoints.
Taking the viewport >1200px case as an example, the concrete size of the thumbnails is 125px wide, while the physical width of the source image is 480px. But instead of the zoom scaling factor being calculated as 480 / 125, it's being calculated as 200 / 125, resulting in a too-small zoomed image.

The gory details are in here…
medium-zoom uses CSS animation to create the zoom effect. It finds the ratio between the intrinsic size of the image and the concrete size of the image as rendered on the page and then calculates a scaling factor to pass into transform: scale (basically — there are a few more twists to the algorithm, code here).
The problem is that for images with a srcset, the intrinsic dimensions (naturalHeight and naturalWidth) are adjusted based on the sizes attribute, or the default "100vw" that's assumed if sizes is missing.
You can check what scaling factor is being applied by bringing up the Javascript console, clicking on a thumbnail, and entering this at the console prompt:
> document.body.getElementsByClassName('medium-zoom-image--opened')[0].style.transform
'scale(1.59289) translate3d(243.269px, -108.779px, 0px)'

The transform is using a scale of ~1.6, causing that dinky zoom. To understand where that scale number came from, enter this at the console prompt (while the zoom is still displayed!):
> document.body.getElementsByClassName('medium-zoom-image--hidden')[0].naturalWidth
200

The intrinsic width of the thumbnail image is being reported as 200px instead of 480px, thanks to sizes, resulting in the scaling factor being calculated as 200 / 125.
If you read this far, you might also be interested in this code pen I made demonstrating how sizes affects intrinsic dimensions.

What to do about it?

Try to be much more accurate and granular with the sizes specification (but this is non-trivial and maybe even sub-optimal).

Use medium-zoom's data-zoom-src attribute to explicitly point to a larger image to use for the zoomed view. You can specify it like:
<img src="/assets/img/1.jpg"
     srcset="/assets/img/1-480.webp 480w,
             /assets/img/1-800.webp 800w"
     sizes="95vw"
     data-zoomable
     data-zoom-src="/assets/img/1-800.webp">

I think this could be incorporated into figure.liquid, perhaps even with some logic for picking which image size you want assigned as the zoomed source.

The second approach is probably easier, since highly accurate sizes specs get really verbose and painful to generate. Also, you'd still be leaving the browser in charge of picking exactly which size image is used for the zoomed view, which can result in visibly inconsistent behavior.


Toggle auto play on mouse enter/leave etc.

Auto play utility initializes timeout on the first render but if property autoPlay is changed afterwards the animation doesn't stop. When the flag is toggled it should pause/resume animation accordingly to its value.

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior
When autoPlay flag is changed after first render from truetofalsethe internalsetTimeout` handler should be removed and animation stopped.
Current Behavior
Even if the flag changes its state the animation still continues.
Context
It's common behavior to pause carousel animation when user is hovering over the active element and when the mouse leaves the element animation is resumed.
Your Environment

Tech
Version

react-swipeable-views
0.13.3

React
16.8.6

@LKay @ykzts @M1chaelTran You can Fixed by That :-)


[D1] Add wrangler d1 insights

Hold off on adding wrangler d1 insights to https://developers.cloudflare.com/workers/wrangler/commands/#d1 until CLI command and output is finalized
Mention wrangler d1 insights on https://developers.cloudflare.com/d1/observability/metrics-analytics/ with examples to increase awareness

@rozenmd mind reviewing?


Feature request: Simple note function for nodes?

When Inventory is used as a server overview, it would be very useful to be able to display/edit a note or some other type of editable text not fetched from facts.

Puppetboard doesn't have a database or anyway of storing data.  Maintaining another database and keeping that database in sync with PuppetDB is out of scope.
If PuppetDB API allowed for adding new data to a node then this would be a viable feature.  Or if there was a service that had a REST API that could allow for notes to be added to a node and it was responsible for keeping those notes in sync with the node, that could also work.
For now this is out of scope of puppet board.

That sounds reasonable, yes. I will probably have to add a custom fact to Facter or similar.

You could stuff it in your hiera data for the node and turn it into a fact.


Charts + other external widgets

This may be a dopey question - but is there a simple way to incorporate e.g D3, Chartist or similar into the page? Bearing in mind that these libs may be doing animations, interpolations etc on their element...I've had a a brief look at the hoops React has had to go through to make this work (looks horrendous!) and was wondering if there's an easier route in Inferno. Cheers.

@minimok Hey, I do believe we can port many of the current React based charting libraries to Inferno with relative ease – as Inferno properly supports SVG out of the box (React has only recently done so)

You can use Inferno to render the SVG and then simply use D3 for modifying the contents of it. Its not optimal but works.


freetype: Add version 2.13.1 and fix git tag names

Before adding new features and new modules, please go to issues to submit the relevant feature description first.
Write good commit messages and use the same coding conventions as the rest of the project.
Please commit code to dev branch and we will merge into master branch in feature
Ensure your edited codes with four spaces instead of TAB.

增加新特性和新模块之前，请先到issues提交相关特性说明，经过讨论评估确认后，再进行相应的代码提交，避免做无用工作。
编写友好可读的提交信息，并使用与工程代码相同的代码规范，代码请用4个空格字符代替tab缩进。
请提交代码到dev分支，如果通过，我们会在特定时间合并到master分支上。
为了规范化提交日志的格式，commit消息，不要用中文，请用英文描述。

I just noticed:
Cloning into 'source.tmp/freetype'...
git -c core.fsmonitor=false checkout ver-2-13-1
error: pathspec 'ver-2-13-1' did not match any file(s) known to git

xmake is lowercasing the second part of the version, this is wrong in this case

I just noticed:
Cloning into 'source.tmp/freetype'...
git -c core.fsmonitor=false checkout ver-2-13-1
error: pathspec 'ver-2-13-1' did not match any file(s) known to git

xmake is lowercasing the second part of the version, this is wrong in this case

I fixed it on dev branch.


python38Packages.aiohue: 3.0.3 -> 3.0.6

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python38Packages.aiohue is: "Python package to talk to Philips Hue"
meta.homepage for python38Packages.aiohue is: "https://github.com/home-assistant-libs/aiohue"
meta.changelog for python38Packages.aiohue is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

Warning: a test defined in passthru.tests did not pass

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 3.0.6 with grep in /nix/store/6v674y3q99g24z0j4xw5zkmy02c60iyx-python3.8-aiohue-3.0.6

found 3.0.6 in filename of file in /nix/store/6v674y3q99g24z0j4xw5zkmy02c60iyx-python3.8-aiohue-3.0.6

Rebuild report (if merged into master) (click to expand)

7 total rebuild path(s)

4 package rebuild(s)

4 x86_64-linux rebuild(s)
3 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
docbookrx
home-assistant
python38Packages.aiohue
python39Packages.aiohue

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/6v674y3q99g24z0j4xw5zkmy02c60iyx-python3.8-aiohue-3.0.6 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python38Packages.aiohue https://github.com/r-ryantm/nixpkgs/archive/b0ad8dae9727dfe9c6d938dede68bec1b88074dc.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/6v674y3q99g24z0j4xw5zkmy02c60iyx-python3.8-aiohue-3.0.6
ls -la /nix/store/6v674y3q99g24z0j4xw5zkmy02c60iyx-python3.8-aiohue-3.0.6/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review took longer than 45m and timed out

Maintainer pings
cc @fabaff for testing.

conflicts


Need other agent variables

What about other agent variables available to builds, like Agent.OS, Agent.OSVersion, etc.? These would be incredibly useful and I would think could be readily available as any other agent variables.

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

ID: 611642f0-881f-10b9-ae94-3c562001d1f0
Version Independent ID: 41efb94b-4c7a-64a3-b23b-70c8634ae727
Content: Release variables  and debugging - Azure Pipelines
Content Source: docs/pipelines/release/variables.md
Product: devops
GitHub Login: @alexhomer1
Microsoft Alias: ahomer

Thank you for your feedback. The list does not cover every variable because these depend on a range of factors such as the agent version and location. As the topic says: "Some of the most significant variables are described in the following tables. To view the full list, see View the current values of all variables". Using this approach, you can see there is an Agent.OS variable:

For other variables that you would like to see added to the product, I suggest you file a request on the Developer Community website at https://developercommunity.visualstudio.com/spaces/21/index.html, where they can be upvoted and are tracked by the product teams.

https://developercommunity.visualstudio.com/content/problem/445506/need-exposed-variable-for-agent-osversion.html


chore(pitr): pitr backup support display backup progress

Type of change:

[ ] Bugfix
[ ] New feature provided
[x] Improve performance
[ ] Backport patches

What this PR does / why we need it:

support display backup progress when check backup task status.
Pre-submission checklist:

[ ] Did you explain what problem does this PR solve? Or what new features have been added?
[ ] Have you added corresponding test cases?
[ ] Have you modified the corresponding document?

Codecov Report

Merging #321 (f5c7865) into main (46be6a7) will decrease coverage by 39.05%.
The diff coverage is 23.32%.

:exclamation: Current head f5c7865 differs from pull request most recent head b4bd5a3. Consider uploading reports for the commit b4bd5a3 to get more accurate results

@@             Coverage Diff             @@
##             main     #321       +/-   ##
===========================================
- Coverage   62.36%   23.32%   -39.05%
===========================================
  Files           2        6        +4
  Lines         279      403      +124
===========================================
- Hits          174       94       -80
- Misses        103      302      +199
- Partials        2        7        +5

Impacted Files
Coverage Δ

pitr/agent/internal/pkg/pkg.go
0.00% <0.00%> (ø)

pitr/agent/internal/pkg/opengauss.go
4.08% <4.08%> (ø)

pitr/agent/pkg/gsutil/conn.go
35.71% <35.71%> (ø)

pitr/agent/pkg/cmds/cmd.go
49.46% <49.46%> (ø)

pitr/agent/pkg/xerror/error.go
61.53% <61.53%> (ø)

pitr/agent/pkg/strutil/rand_string.go
90.90% <90.90%> (ø)

... and 1 file with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

approved


Fixed a bug with positioning of plugin overlay

There is a difference in calculation of the offset based on the
"position" property of html element, now we take it into account.

Coverage increased (+0.01%) to 82.495% when pulling 210d7783e43a37eb163bebc073dad1e770db057c on vxsx:bugfix/plugin-content-overlay-positioning into d49b5449af00c3d5fcff2daad195f2f5edf6920c on divio:release/3.4.x.


Cannot install on Debian Stretch

It seems that it's not possible to install this on Debian Stretch. I followed the instructions from here: https://packagecloud.io/claudyus/LXC-Web-Panel/install
Running: apt-get install lwp
yields as result: E: Unable to locate package lwp
Any suggestions?

Even if you install from here https://packagecloud.io/claudyus/LXC-Web-Panel version 0.9 is two years old.
What I have done in Debian 9 Stretch is:
apt-get install python-ldap
git clone https://github.com/claudyus/LXC-Web-Panel.git
cd LXC-Web-Panel/jsbuild
npm install
node_modules/.bin/bower install --allow-root
node_modules/.bin/grunt --allow-root
cd ..
python setup.py install
mkdir /etc/lwp
cp lwp.example.conf /etc/lwp/lwp.conf
mkdir /var/lwp
cp lwp.db /var/lwp/lwp.db

You can run lwp now. Default credentials is admin/admin. Don't forget to change password  at domain:5000/lwp/users


renovate: ignore all gops updates

Otherwise the gops version in images/runtime/build-gops.sh will still be bumped, see https://github.com/cilium/cilium/pull/27624
Fixes: 14760a1b2ffb ("vendor: downgrade github.com/shirou/gopsutil/v3 to v3.23.2")

This only affects renovate configuration, no need to run full CI. Marking as ready to merge.


[backport/v1.22] build: update LLVM to 14.0.0 (#21135)

Risk Level: Low
Testing: CI
Docs Changes: Added
Release Notes: Added
Platform Specific Features:
Signed-off-by: Keith Smiley<EMAIL_ADDRESS>Signed-off-by: Lizan Zhou<EMAIL_ADDRESS>Signed-off-by: Ryan Northey<EMAIL_ADDRESS>Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

add changelog

this fails with
cd /b/f/w/external/net_colm_open_source_ragel && /bin/bash /b/f/w/external/net_colm_open_source_ragel/missing automake-1.15 --foreign
configure.ac:24: error: version mismatch.  This is Automake 1.15.1,
configure.ac:24: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:24: comes from Automake 1.15.  You should recreate
configure.ac:24: aclocal.m4 with aclocal and run automake again.
ragel/Makefile.am:2: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
WARNING: 'automake-1.15' is probably too old.
         You should only need it if you modified 'Makefile.am' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'automake' program is part of the GNU Automake package:
         <[http://www.gnu.org/software/automake>](http://www.gnu.org/software/automake%3E)
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <[http://www.gnu.org/software/autoconf>](http://www.gnu.org/software/autoconf%3E)
         <[http://www.gnu.org/software/m4/>](http://www.gnu.org/software/m4/%3E)
         <[http://www.perl.org/>](http://www.perl.org/%3E)
Makefile:343: recipe for target '/b/f/w/external/net_colm_open_source_ragel/Makefile.in' failed
make: *** [/b/f/w/external/net_colm_open_source_ragel/Makefile.in] Error 1
make: Leaving directory '/b/f/w/bazel-out/k8-opt/bin/external/envoy/bazel/foreign_cc/ragel.build_tmpdir'
_____ END BUILD LOGS _____
rules_foreign_cc: Build wrapper script location: bazel-out/k8-opt/bin/external/envoy/bazel/foreign_cc/ragel_foreign_cc/wrapper_build_script.sh
rules_foreign_cc: Build script location: bazel-out/k8-opt/bin/external/envoy/bazel/foreign_cc/ragel_foreign_cc/build_script.sh
rules_foreign_cc: Build log location: bazel-out/k8-opt/bin/external/envoy/bazel/foreign_cc/ragel_foreign_cc/Configure.log

its not immediately clear why
also not sure if this is the best resolution - changing the compiler post-release
with this commit the size of the release tarballs drops > 2GB -> ~200MB, but we could probably resolve another way - like with the the remove-ci-apps-hack

ill patch the hack mentioned instead and close this


Runtime type checking

I request a runtime type checking system that perhaps looks something like this:
function square(x: number!) {
  return x * x;
}

Where the ! tells the compiler to generate a runtime type check for a number, something akin to tcomb.js.
Of course, this gets much more complicated with interfaces, but you get the idea.

For people like me coming here looking with high hopes, you might want to take a look at http://angular.github.io/assert/

Well, this can't be very complex to implement since you already have the infrastructure for type checking. At least you could expect to get injected type checking for primitive types when compiling with --debug, as mentioned in the other thread:

This has lead us to introduce type checks for all exported functions in TypeScript, although they really feel verbose in a typed language.

export function add(x: number, y: number): number {
  if (typeof x !== 'number' || typeof y !== 'number') {
    throw new TypeError('x and y need to be numbers');
  }
  return x + y;
}

If this does not match your design goals, maybe you should change them?

Primitive TypeChecking is easy, and the results of doing it yourself guide type inference. If you expect to receive something other than the indicated type, perhaps you should not specify number.

I would expect to get a runtime error if a function receives eg a string instead of a number in runtime. That would really kill the flaws of working with JavaScript.
Don't get me wrong, I love TypeScript, but I really hate JavaScript..

But, IMO, you need to learn to love JavaScript to fully take advantage of TypeScript.

@jeansson did you take a look at tcomb?

Well I think that is mission impossible for me. JavaScript is great for what is was made for, but for large complex systems built and maintained by a team I can't see how it could be a good modern option.
@jedmao Thank you, will have a look. But I still think it should be implemented in the TypeScript compiler (with a flag)

@RyanCavanaugh it's been almost 2 years since this feature request was made and I'm wondering what it would take for the design goals to change or make an exception for this particular request? Now that the initial TypeScript roadmap is complete, perhaps we can entertain this idea?
I think this proposed compiler flag would only make sense in development and staging environments, but it would serve as a great tool for debugging the application at runtime.
Consider the scenario in which an API request is made and we expect the API response to adhere to a model (interface).
interface Foo {
    bar: string;
}

function handleResponse(data: Foo) {
    return data;
}

Compiles to:
const __Foo = {
    validate: (d) => {
        if (typeof d.bar !== 'string') {
            throw new TypeError('Foo.bar should be a string.');
        }
    }
};

function handleResponse(data) {
    Foo.validate(data);
    return data;
}

handleResponse({ bar: 'baz' }); // OK
handleResponse({ bar: 42 }); // TypeError('Foo.bar should be a string.');

Rather than getting some error about some foo prop being undefined, wouldn't it be more useful to know that the complex type that was defined as input didn't come back the way we expected?

@jedmao
+1 on that. Of course this is only relevant during development and testing, at least to begin with, because I guess it adds up to compile time and also adds runtime overhead. I recently encountered a situation where this would have saved a lot of time where an API returned a string inside a json-object where a number was expected. That resulted to weird runtime behavior that would be very easy to spot if I could compile with a --runtimeErrors flag.
I think this a natural next step for TypeScript

@jedmao @jeansson If it is string vs number you can already do what you want, but you have to use classes because you have to use decorators, but it can be done.
model.ts
import reified from './reified';

export default class Model {
    @reified bar: string;
    @reified baz: number;

    constructor(properties: Partial<Model> = {}) {
        Object.assign(this, properties);
    }
}

const y = new Model({
    baz: '42' as any,
    bar: 'hello'
});

reified.ts
import 'reflect-metadata';

export default function <T extends Object>(target: T, key: string) {
    const fieldKey = `${key}_`;
    console.log(target[fieldKey]);
    const fieldTypeValue = getTypeTestString(Reflect.getMetadata('design:type', target, key));

    Object.defineProperties(target, {
        [key]: {
            get() {
                console.log(`${key}: ${fieldTypeValue} = ${this[fieldKey]}`);
                return this[fieldKey];
            },
            set(value) {
                if (fieldTypeValue && typeof value !== fieldTypeValue) {
                    throw TypeError(`${fieldTypeValue} is incompatable with ${typeof value}`);
                }
                this[fieldKey] = value;
            }, enumerable: true, configurable: true
        }
    });
}

function getTypeTestString(type) {
    switch (type) {
        case Number: return 'number';
        case String: return 'string';
        default: return undefined;
    }
}

Obviously this doesn't work for complex types.

@aluanhaddad, your solution would add footprint to the compiled output. The idea here is that it would be a compiler flag you could turn off for production builds and that it would work with complex types, not just classes.

I am not recommending it as a solution.

@aluanhaddad The whole point is that I should not be forced to check this manually in a typed language, so the type checking needs to be injected automatically at compile time if the flag is set. It also prevents the overhead @jedmao  mentioned because the runtime type checking will not be injected when you build the release version.
Why do you not like this solution?

Look https://github.com/codemix/babel-plugin-typecheck. It could work like this but automatically.

Rather than building runtime type checking into the compiler - an alternative might be to expose type metadata to runtime code (e.g. via Reflect.getMetadata); probably only for reachable types.  We can then build type checking libraries on top of that

This lib came across my slack this morning - although designed for Facebook's flow it states it could work with Typescript. It is built upon the work of the babel-plugin-typecheck that @GulinSS mentioned.
https://codemix.github.io/flow-runtime/

I can't understand why this is out of the scope of typescript, which adds exactly this kind of things to JS.
Seems that it would be a better idea to use flow + flow-runtime instead.

I just did a proof of concept using TypeScript.
Only enforcing type checking at compile time and not run-time in JavaScript is dangerous.
You are essentially tricking developers into thinking they are writing Type safe JavaScript, when in fact, the moment any data from an outside system ( like the client ) comes into a "Typed" function you are going to be NaN and can't read property length of undefined errors all day long.

To illustrate my point:
declare var require: any

// declare a Person type
interface Person {
    firstName: string;
    lastName: string;
    age: number;
}

// declare a greeter function
// notice the last argument is a number being multiplied by two
function greeter(person: Person) {
    return "Hello, " + person.firstName + " " + person.lastName + ". I am " + person.age * 2 + " years old.";
}

var http = require('http');
var qs = require('querystring');

// let's create a HTTP server. its going to accept a parameter and call a function with that parameter
var server = http.createServer(function(req, res){

  // let's define a user, they have a valid age
  var user = { firstName: "Jane", lastName: "User", age: 42 };

  // parse the incoming url for parameters
  var parsed = qs.parse(req.url);

  // we've got an incoming value for parameter "age" from an external interface
  // since this is done dynamically at run-time, typescript has no way of validation
  // we will see NaN here if we put in any non-number values

  if (typeof parsed.age !== 'undefined') {
    user.age = parsed.age;
  }

  // Now we run: curl http://localhost:8000/?foo=bar&age=cat
  // Outputs: "Hello, Jane User. I am NaN years old."

  // While this seems like a minor detail, it's actually very important
  // because the majority of applications we build need to deal with third party datasources,
  // or untrusted data sources ( the client )

  // We thought that `greeter(user)` was a typed function, but in fact, it is NOT.
  //
  // Maybe Microsoft will add this feature? Nope.
  // See:
  //      https://github.com/Microsoft/TypeScript/issues/1573
  //      https://typescript.codeplex.com/discussions/401501

  // Quote from lead developer: "This remains outside our design goals"

  res.end(greeter(user));

});

server.listen(8000)

I've made a library for doing this sort of thing: https://github.com/pelotom/runtypes
It allows you to build composable validators which can be used to coerce untyped values to typed ones in a type-safe manner. It has the nice property that you don't need to repeat your type specification at the type and value level; simply specify the runtime validator, and make a type alias to the inferred type of the thing it validates.
It doesn't support function validation yet but I'm certainly open to adding that functionality.

@pelotom - Good to see. Thank you for posting.
Is there any adoption of this kind of technique ( runtypes library )? We are evaluating the usage of TypeScript at scale for a large enterprise. Your library looks neat, but it seems to not have much of a following?
As for function validation, I'd probably make that a separate module.

@Marak: I literally just published it today, so that might explain lack of adoption ;) I'd love to get people using it which is why I posted here.
I will say it is very well tested and I have been using it heavily for some time as an internal library in a private company project.

@aluanhaddad

Primitive TypeChecking is easy, and the results of doing it yourself guide type inference. If you expect to receive something other than the indicated type, perhaps you should not specify number.

This is not the case. A library author making a library, for example a Transform class that has API like transform.translate(30,20,40) might simply want to be helpful to any and all programmers, even if they are brand new to JavaScript. Throwing a helpful error (in this case when .translate doesn't receive a number) not only saves end users time in figuring out what a problem, but can also help them learn.
The problem here isn't about accepting other things beside numbers or not, the problem is about making runtime errors easy to work with and easy to learn from.
Furthermore, the consumer application of a library written in TypeScript may not have type checking at all. It can be beneficial to provide runtime errors for those consumer apps or libraries.
By arguing strictly against runtime type checks, you're arguing for the absolute possibility for non-typescript runtime consumers of any given library to be open to complete breakage, which defeats the whole purpose of writing your library for the benefit of your end user.
Just saying. Runtime checks can be really nice, and it can definitely be redundant to write the runtime checks when they are already written in TypeScript (in cases where the type check is deemed important for a library author's end user).

I'm not arguing against argument validation, including any runtime type checking deemed appropriate, I'm arguing against the idea that TypeScript should automatically synthesize these checks.
For simple types it's trivial to write these checks yourself and for complex types, which includes almost all TypeScript types, it's simply not feasible.

@pelotom I'm writing a library with the same goal io-ts, basically it's a porting of flow-io to TypeScript. A distinctive feature I want is being able to do runtime type introspection (a la tcomb)

@gcanti cool, sounds like we have similar goals :)

For simple types it's trivial to write these checks yourself
@aluanhaddad
Yes of course, and then we can stop using arrow functions, and come back to the prototype.method thing, forget about the rest parameters because, hey, isn't Array.prototype.slice.call(parameters,3) simple enough?
If you say that Typescript should not do it because it is simple enough doing it yourself then the entire syntax-sugar thing makes no sense.

If you have philosophical reasons to not include it into TS then it is fine, at the end it is a matter of opinion, but don't say that it does not makes sense just because it does not fit your expectations/ideas.

My point is that for a bread and butter type like
(x: number) => "Hello"

there is no way to generate a meaningful runtime type check.
If all you want is checking primitive types then yes it can work but it is of extremely limited value and I think it will run out of mileage very quickly.
It is not just a philosophical difference, as it is a non-trivial problem.

I think this issue really should be properly considered again now we have strict null checks.
When it comes to dependencies (even node/browser apis) it's in declarations file we trust. One little mistake in these user contributed files and our compile time checks only help to mask a bug.
Im suprised this isnt a design goal - I wonder if such a flag existed how many codebases would start breaking due to an ill informed typesystem.

I would add that type checking at runtime sounds great in principle, but there are pros and cons. TINSTAA - a recent project I worked on used runtime flow checking. However we ran into issues with it and unfortunately ended up stripping it out. Ultimately it cost us more than it gave us.
Bare in mind it is going to change the code you write (no different from compilers and TS of course) and is dependent on the maintainers (who I have huge support for in the OSC); even type definitions can be wrong  - think of the ever changing JS lib that is in production before v1!
It would be great in development but needs to be backed by a team who can handled the (huge) number of edge /variations in JS/TS. Ultimately error handling has to written in by the developer regardless of if its a lib or the browser that has found your bug / bad data.

Since this seems to be an hot topic and because internet seems to forget, I'd like to remind everyone that, 3 years ago, this feature has been implemented as a research project. It seems on the TypeScript team radar according to this.
Why that work wasn't merged yet, as @RyanCavanaugh, already stated: It's not in the TypeScript Design Goals
If that doesn't satisfy you, here's a few more reasons:

It impacts performance negatively both on the compiler and runtime side of things.
It a research project therefore it requires a lot more work to be production ready.
TypeScript's type system is still in the state of flux. See: #202 #1213 #5453
If one wants a typed language that compiles to JavaScript there are other alternatives out there that are designed around type safety. Type safety isn't really a TypeScript Design Goals.
TypeScript's type system is purposefully unsound because the language is designed to be a superset of JavaScript. This makes it possible to progressively migrate an existing JavaScript to TypeScript without having a massive headache.

@BleuShan, although the research project was introduced 3 years ago, this thread was created only 3 months after the fact (still pretty fresh).
The performance implications are a valid concern, but many great features have begun with performance issues until there was enough love to work them out. Also, it's only a performance issue for those who enable the compiler flag, knowing full well to what behavior they are subscribing.
It definitely requires more work to be ready. My original request was more about whatever it takes to spark that momentum.
Though some of the type system is in flux, there is a lot that is locked down as of 1.0 and especially 2.0.
Perhaps the design goals should change? I feel that TypeScript is superior to the alternatives; thus, why I submitted the feature request to this project in the first place.
There would be no migration headache if the feature were introduced as a compiler flag with a default value of false.

@aluanhaddad, I love TypeScript as well as JavaScript and I would love to see TypeScript continue to dominate alternatives at every corner! If we could figure out a solution to the run-time type checking w/o duplication of type information, I really think it would provide a value in catching more errors before they reach production environments.

@jedmao In an perfect world, yes we could have a type system that was 100% reified and at the same time fully transparent.
If it were 100% fidelity, I would be all for it because it would be just a consequence of using the language.
So I am not opposed to that ideal. What I am opposed to is trying to take 20% of TypeScript's expressiveness and reify it so that it can be checked.
Basically, I have yet to see a solution that can type check even the most trivial functions at runtime. When I say runtime typechecking I am including a requirement that JavaScript code be able to consume it unfettered. It should just happen.
That would mean the type system would be fully manifest in the value space and would not even be a language feature so much as a framework.
That could be a powerful framework and I might well use it. But I haven't seen a solution that works.
Taking that a bit further, if you have to write in TypeScript to call into it then it is not TypeScript anymore because it is not JavaScript anymore.
That would mean that all usages would need to encode sufficient information to type check all of their consumers.

I started on the side of adding this to the core of TypeScript, but I've come around to thinking it's best left to third-party libraries. I'd rather the TypeScript team remain completely focused on adding awesome features to the fully-erased static type system without having to consider, each time they add a feature, its implication on some runtime validation system. TypeScript's excellent type system enables perfectly usable library solutions to this problem:
https://github.com/gcanti/io-ts
https://github.com/pelotom/runtypes
IMO, that's pretty ideal; if a feature can be implemented as a library instead of as a core part of the language, it should be.

@pelotom Makes total sense athough would be a lot easier for the TypeScript team to maintain than others.
Does such a library exist currently? The two examples you included don't appear to modify compiler output to include run time exceptions on unexpected types.

@pelotom That's kinda what I've thought. Given that TypeScript's story is very similar Typed Racket, it makes sense to implement a  function contract decorator library. I wish I had time to port clojure.spec to TypeScript.

@nbransby I'm not sure if such a library exists, but why do you need it to be a library that modifies compiler output?

https://github.com/Microsoft/TypeScript/issues/13835
as mentioned by others ideally for me this would be a compiler flag to create non-production ready code to help debug issues. A bit like turning optimisations off on a traditional compiler.
Related trivia: Googles j2objc which trans-compiles java to objective c puts in these runtime checks to ensure generated code behaves like java - for example Objective C doesn't blow up on dereferencing nil so every occurrence of this in the generated code is wrapped in a function call: nil_chk, which throws a null pointer exception if nil

Compiler output is what we're talking about here. TypeScript already forces
us (for example) to check for null otherwise it throws a compile-time
error. So, if we are forced to write null checks, and output code is
therefore going to have null checks (for example), then why not just
automate it? Etc.
On Apr 3, 2017 2:21 PM, "nbransby"<EMAIL_ADDRESS>wrote:

#13835 https://github.com/Microsoft/TypeScript/issues/13835
as mentioned by others ideally for me this would be a compiler flag to
create non-production ready code to help debug issues. A bit like turning
optimisations off on a traditional compiler.
Related trivia: Googles j2objc which trans-compiles java to objective c
puts in these runtime checks to ensure generated code behaves like java -
for example Objective C doesn't blow up on dereferencing nil so every
occurrence of this in the generated code is wrapped in a function call:
nil_chk, which throws a null pointer exception if nil
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/1573#issuecomment-291277778,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASKziOHTip5Z7JctdXWm7_UrnEBGOYQks5rsWLzgaJpZM4DNGGs
.

I'm actually currently implementing something like that, as it doesn't seem such a feature will be added to the compiler soon.
My aim was to utilize the new transformer API (scheduled for TypeScript 2.3 and already in the nightly builds) with TypeScript as a dependency. I think that this has several advantages over creating a TypeScript fork, which has to be maintained separately.
I'm trying to adapt as many features from the specifications as possible (e.g. Interface Declaration Merging) and I hope there won't be many limitations.
For the runtime code I'm making use of flow-runtime, which offers almost any type reflection mechanisms needed.
I will publish a first draft version of the code soon and I'm looking forward to your feedback.

@fabiandev awesome! Did you also take a look at https://github.com/gcanti/io-ts ?

Someone already mentionned tcomb : something interesting there's a babel plugin to turn flow annotations in tcomb validation : https://github.com/gcanti/babel-plugin-tcomb
I should not be too difficult to adapt it for Typescript.

@jedmao I did have a look at io-ts, but decided to go with flow-runtime though, mostly because of its documentation and live demo. Anyway, the runtime representation should not be too difficult to change. I may add a way to make it entirely replaceable in the future.
@abenhamdine babel-plugin-flow-runtime does that job already pretty well. I don't think creating a babel plugin is that easy right now. As far as I know, babel doesn't understand TypeScript, but Flow according to https://github.com/Microsoft/TypeScript/issues/11441#issuecomment-252336980. Also see https://github.com/babel/babylon/issues/320 and https://github.com/babel/babel/issues/5201. I also thought I'll give the transformer API a try.

@fabiandev thx for the explanation !
Hang in there, can't wait to try your work 😄

@pelotom I took a look at https://github.com/pelotom/runtypes and I have to say I really like the direction you've taken.
The explicit method contracts approach and the tidy dsl you've built up around it seem quite elegant.

@aluanhaddad thanks!

https://github.com/gcanti/babel-plugin-tcomb is very useful for development when migrating from plain JS, because it gives real confidence if you type core parts. Given the amount of bugs that both Flow and TypeScript have at the moment such asserts give real confidence and I would love if TypeScript had flag to turn on runtime type checking based on annotations. They are also really helpful for checking API boundaries with exact object checking.

I've just made my work public on generating runtime type checks with the TypeScript transformation API: https://github.com/fabiandev/ts-runtime
I think there's a lot of room for improvements and there are some limitations at this point, but I'd love to hear what you think. Feel free to open issues and/or to send PRs.

Look great, thanks @fabiandev

I've created a playground for ts-runtime, similar to TypeScript's playground, to try it in a browser: https://fabiandev.github.io/ts-runtime/

@fabiandev I tried this snippet and the results were quite impressive
interface A<T> {
    prop: T;
}
function f(x: A<number>, y: A<number>): A<number> {
    x.prop = x.prop - y.prop;
    return x;
}

const x: A<number> = {
    prop: 1
};

const g: (x: any, y: any) => any = f;

// fails with "Uncaught RuntimeTypeError: x.prop must be a number"
const y = g({prop: 'a'}, {prop: 'b'});

alert(y.prop);

I would say that this is not TypeScript anymore but, whatever it is, it sports impressively early and informative errors.

@aluanhaddad thank you, glad you like it! I'm currently making use of flow-runtime for runtime type reflections and assertions, while for modifying the AST and emitting the resulting code, the TypeScript compiler API is used. There are still quite some things that can be improved and some limitations apply, due to both, ts-runtime and flow-runtime, but I hope it will evolve over time.

@fabiandev -
Looking very good!
How far away is this from full support of TypeScript type system?
I'd imagine a lot of people will want to use this.

Thanks @Marak! There are still a few conditions that have yet to be implemented. Also I'm considering switching to io-ts from flow-runtime, as some browser benchmark tests I've performed lately were not really satisfactory, and its behavior is not as expected in some cases.

How is this going?... having a flag for debugging purposes is definitely a plus, I can still imagine situations where you can run into problems, eg in a react reducer:
interface ActionType {
   type: string,
   payload?: any
}

export default function myReducer(state: MyStateType, action: ActionType): MyStateType{
   if (action.type === "MY_ACTION"){
      let data: MyStateType = action.payload;
      return data;
   }
   return state;
}

I don't understand the "bad performance" argument.  If you only enforce type checking for variables that are declared as "runtime checkable", say RunType<Foo>, then by default the types will remain unchecked until you wrap them in that special generic type, so no added overhead.

It is wasteful and useless to do runtime checks on every assignment since the compiler can rule out many cases of illegal assignments statically.
However, runtime type checking can be useful at specific moments during run time, specifically when receiving data from a source that one knows is not check-able statically.
Therefore, it would be useful to have some compiler support for generating a runtime structural validation function that can be called at will on objects of type any that return objects of the desired type (essentially like a static type guard) or throw an exception.
For example:
interface Employee {
    name: string;
    salary: number;
}

function webServiceHandler ( possibleEmployee: any ) {
    try {
        const actualEmployee = <runtime Employee>possibleEmployee;
    }
    catch (e) {
        // validation failed;
    }
}

I don't propose this particular syntax at all. Perhaps this could be implemented with annotations or some other mechanism but I absolutely believe that having the compiler generate a proper runtime type checker automatically would be very very useful.

@saabi I think it would be nicer to simply declare any type you need runtime-checked to be a generic like RunType<Foo> - that way you don't need to worry about explicitly checking the type.  The compiler could figure out when it needs to insert that check and do it automatically and you write the code as normal.

@jez9999 It is difficult if not impossible for the compiler to decide where a runtime check would be needed.
It must be specified by the programmer where he deems it necessary.
The pattern I described also allows precise control of what to do on the event of a validation failure.

@saabi I'd imagine it would be whenever the variable was modified, like assignment and delete?  When else might it be needed?

@jez9999 That's uses up even more CPU resources than checking at every parameter assignment on every call site. It would make it useless to me and many other programmers.
Typically there's only a few places, which only a developer can determine that need runtime type checking. Such as when receiving data from an untrusted source like a web service client.
Additionally, in the event of a validation failure, checking everywhere without clearly marked try {} catch {} blocks makes the code more difficult to understand and control.

Yeah, I come from the C# world where we have the luxury of being able to assume that a class is unchangeable.  It'd be nice to have that for select variables in TS.

As a Flow user and casual observer of TypeScript, I have to say, I love the concept of flow-runtime.  After seeing numerous ugly, hard-to-read runtime type checking APIs over the years, flow-runtime was a huge relief, because there's really no better syntax for expressing type assertions than the flow types themselves, and the same would go for TypeScript:
const json = {
  name: 'Andy',
  email<EMAIL_ADDRESS>};
type UserInfo = {
  name: string,
  email: string,
  phone?: string,
};
(json: UserInfo); // performs a runtime type check

However, flow-runtime still has a few rough edges, and the primary limitation of babel-plugin-flow-runtime is that babel plugins can only process one file at a time, so it has no good way to determine if types being imported from another module were actually converted to runtime types.  I assume the TypeScript compiler is significantly more well-prepared in this aspect.

@jedwards1211
My suggestion is not to use the syntax as is, but to add a runtime keyword such as <runtime SomeType>someReference for manual runtime checks, thus clearly differentiating a compile time check from a runtime check.

Oh I see, cool!

@RyanCavanaugh Please revisit this, and especially consider doing it in a non-production environments, or always doing it when encountering a runtime keyword (see @saabi's comment).
Perhaps the design goals could be expanded to include this?

From the goals

Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.

This is ironic, given than TypeORM relies heavily on runtime metadata about decorators AFAIK.

So if I'm building a library that can be adopted by plain javascript users, it's prone to weird errors for them.  It'd be cool to have a flag for JS builds to do complete type checking.

Not any more prone than any regular Javascript library.
The real usefulness lies in localized dynamic type checks for the reverse situation.
When Typescript code must use data coming from an untrusted (more specifically non type checked) environment (that means from Javascript code, or from network transmitted JSON) it could definitely use a statically generated dynamic type check at the receiving location.

@jedwards1211

This is ironic, given than TypeORM relies heavily on runtime metadata about decorators AFAIK.
The problem with this goal is there's just no better way to define types for validating things like JSON documents than with the syntax of TypeScript/Flow itself.  Until runtime type introspection becomes common, we'll be stuck with an excess of crappy validation libraries that are nowhere near as elegant.

Perhaps I am beating a dead horse, but decorator metadata does not represent types. It embeds values that have a compile time type that corresponds to a conveniently named (if conflation is desired) runtime value.
https://github.com/fabiandev/ts-runtime uses an orthogonal approach and with good reason.

@saabi Actually the syntax can be much more easier by using as operator.
interface Employee {
    name: string;
    salary: number;
}

function webServiceHandler ( possibleEmployee: any ) {
    try {
        const actualEmployee = possibleEmployee as Employee;
        // Code for type assertion should be generated when the compiler
        // spot that we are casting `any` to a specific type
    }
    catch (e) {
        // validation failed;
    }
}

@wongjiahau That would have to be optional, it's currently the best way to add properties to objects that don't have them in their type. Unfortunately it's quite common when interfacing with other javascript or global objects on web pages and this check would break them.
example
function setup(stack: any[]) {
  if ((stack as any).setupDone) {
    return;
  }
  // ...
  (stack as any).setupDone = true;
}

Anyway, will anyone support me if I'm going to implement this feature by forking this project?
(I will seriously implement this if I got more than 20 reactions)

Apologies, my example used a non-any type when you specified casting any -> non-any.
Still, it's a backwards-incompatible change which means you're fighting an uphill battle. That's why other people have suggested new syntax such as !.

@wongjiahau I wouldn't necessarily want all "as" operators to create type checking code around it. I'd much rather be explicit with it with a simple ! on a case-by-case basis. Did you take a look at io-ts?

@jedmao I did look at io-ts, I actually wanted to use it but it is not really natural when you have nested type.
@tbillington Ok now I understand your concern (of the backwards-compatibility).
So, I guess the syntax should looks like this as suggested by @jedmao?
function square1(x: number!) {
  // TS compiler will generate code that will assert the type is correct
  return x * x;
}

function square2(x: number) {
  // TS compiler will not generate any type-assertion code
  return x*x;
}

var apple: any = "123";
square1(apple); // Compiler will not generate error, since the type of `apple` is `any`.
square2(apple); // Compiler will throw error

var banana = "123";
square1(banana); // Compiler will generate error because you can't cast string to number by any means

@jedmao  @tbillington What do you think?

@wongjiahau my opinion is that the compiler errors should be exactly as they are w/o change. The only difference is runtime. As such,  I don't see how the ! operator would suppress any compiler errors at all.
Let's take your example:
function square1(x: number!) {
  // TS compiler will generate code that will assert the type is correct
  return x * x;
}

The TS compiler would simply emit something akin to the following:
function square(x) {
    if (typeof x !== 'number') {
        throw new TypeError('Expected a number.');
    }
    return x * x;
}

Super easy with primitive types, but more complicated with interfaces and more complex types (but io-ts solves that issue).
I just wish it were built into the compiler itself so we didn't have to do all this extra stuff. But it really is complex and requires a lot of thought behind it in order to do it right.
Here's some other ideas I thought of recently:
// First line of file
const x: number! = 42; // compiler error: redundant type checking on a known type.

const x: number = 42;
const y: number! = x; // also redundant

const x: number = 42;
const y: string! = x; // compiler error:
const z: string! = x as any; // OK, but should it be?

There's really a lot to think about here.

@jedmao I understand what you say, but please allow me to clarify the error suppression with a typical example.
Suppose you have the following code (using express.js) :
interface Fruit {
  name: string,
  isTasty: boolean
}

app.post("/uploadFruit", (req, res) => {
  const newFruit = req.body; // Note that `req.body` has type of `any`

  // This line shouldn't throw compile error because we already tell the compiler
  // to assert that newFruit is type of `Fruit` by adding the `!` operator
  saveFruit(newFruit);
});

function saveFruit(newFruit: Fruit!) {
  // save the fruit into database
}

If that line of saveFruit(newFruit) will throw compilation error, then this runtime typechecking feature would be meaningless already.
I hope you can understand what I'm trying to say.
Moreover, I think that syntax A will be better than syntax B
// syntax A
const apple!: string = "...";

// syntax B
const apple: string! = "...";

This is because syntax A will be much more easier to be parsed, and it is also more consistent with the ?: operator.
So you can read the !: operator as must be a.

@wongjiahau I'm not suggesting that saveFruit(newFruit) should throw a compiler error, as req.body is of type any. Just like it won't throw a compiler error today, it shouldn't in the future. That's exactly what I said before. Current compiler errors should remain compiler errors, period.
That said, I still don't see where any error is being "suppressed" as you say.
I do kinda' like the !: operator idea. That would make forced union types a lot easier to read:
function foo(x!: string | number) {}

@jedmao Sorry for the misunderstanding, because I thought the compiler will throw error if we cast from any to a specific type, just realized it won't throw error.
So, do you guys want to fork this project and implement this feature?

I think Microsoft would have to agree to accept a community PR for me to invest time in this. Also, I just don't have the bandwidth.

Creator of Node.js seems to be working on similar project for TypeScript: https://github.com/ry/deno


Feature: create simple search (unified) collection

create a typesense collection that contains all searchable entities present in the database

just because we had a look at this today: typesense has a federated search feature that allows to search multiple collections at the same time -> so as far as I can tell, no need for a unified collection

@sennierer I am a little bit surprised by this message. First: @stefanprobst, @kaggl  and me have been discussing the pros and cons of a unified collection vs. a federated search implementation a while ago already. This you couldn't know; but I re-iterrared the arguments for the unified collection  – which was also Stefan's preference -  and the implementation implications of a federated search  in the "viecpro board of director's" meeting weeks ago, and we decided on this approach towards the end of the meeting.
I am always open to re-evaluate the decision, but given that this is a lower priority feature atm  (in accordance with the view of the viecpro editoral team) I would postpone this until more urgent issues have been resolved.
And an important sidenote: This is not the first time that I see that several people had to re-discover features or implications of a tool that we use across projects; and I see a deeper issue there that we lack a place where we can reliably deposit such information or a structure or space where we can share such information regularly so that people actually can find it.
That was a main line in my ongoing argumentation for a different place to deposit such information than in github issues (where people might stumble across them, but will most likely never find them if they actively search). When I last brought that up in the apis-jfx (and I did that several times), nobody saw the urgency to change something so that we don't have to do the same work over and over again.

I didnt recall that we had already discussed this. If we already decided against federated search I am fine with that, just wanted to mention it here as we looked at it yesterday for another topic.
And regarding the place to deposit information: even if we had (yet another) place to put information in, chances are high I would have missed that information too.
Anyhow, now its where it should be, with the issue for implementing the unified collection. I also agree that the unified search is not high priority.

Yeah, sure, I will let you know when I start working on this in case something new might have come up. And don't get me wrong – thank you for pointing this out; of course the feature you hinted to might have slipped my attention; this can always happen.
Regarding the documentation I still (respectfully) disagree, but thats neither the topic now, nor a pressing issue.
Thanks for clarifying, all good.

This is not the first time that I see that several people had to re-discover features or implications of a tool that we use across projects;

it took me 20seconds to do a google search for "typesense search multiple collections" and find the official typesense documentation federated search. so I'm not sure it's that big of an issue

and I see a deeper issue there that we lack a place where we can reliably deposit such information or a structure or space where we can share such information regularly so that people actually can find it.

Feel free to document your findings in the https://github.com/acdh-oeaw/prosnet-team repository - I'd be very interested in your arguments against federated search
(to me, documenting the reasoning behind the decision in this issue seems more reasonable, but YMMV)


Admin Privileges and Git with GCM Core

Hi all,
I've seen several cases where using GIT with GCM as it is natively installed with VS 2017 and 2019 and users in NON Admin configurations will be able to complete commands from Git on the command line tool (though the GCM prompts every time for credentials). However after prompting for Credentials, _and completing the git action _ Visual Studio reports a failure as it was unable to save the credential to the windows credential store.  This is not a great experience for users and I'm not sure what we can do about it from a "fix" standpoint but I think that we need to call out that as it stands using Git with NTLM (at least) in VS requires you to be able to perform an action and save the credential 1 time at least as admin (after that it's just referencing it) and you can be a standard user unless you need to change it.

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

ID: 8fc5e99e-c7bd-9519-c739-bfc6ab1a97fe
Version Independent ID: 03884a15-6e09-1a83-e83a-584addb57248
Content: Run as administrator - Visual Studio (Windows)
Content Source: docs/ide/user-permissions-and-visual-studio.md
Product: visual-studio-windows
Technology: vs-ide-general
GitHub Login: @TerryGLee
Microsoft Alias: tglee

@Taysser-Gherfal Please take a look at this; thanks.

@rub8n Please take a look at this; thanks.

@SamGrantham Hello; apologies for the delay in getting back to you on the issue you filed. I've checked in with our engineering team and here is what they had to say:
"Regarding the specific problem of failing to write to the Windows Credential Store...the best place to go for support on issues like these is the GCM public issues on GitHub: https://github.com/GitCredentialManager/git-credential-manager (or complete an issue template at https://github.com/GitCredentialManager/git-credential-manager/issues/new/choose)."
We'll close this issue, but we hope you'll contact us again with your ideas on how we can improve the documentation.


Error: Nonexisting input files. Aborting.

Error is shown even if file exists!
$ ls
PARSIFAL - Bavarian State Opera-1.mp4  PARSIFAL - Bavarian State Opera-3.mp4
PARSIFAL - Bavarian State Opera-2.mp4  PARSIFAL - Bavarian State Opera.mp4

$ ls | renamer
The following input files do not exist:
PARSIFAL - Bavarian State Opera-1.mp4  PARSIFAL - Bavarian State Opera-3.mp4
PARSIFAL - Bavarian State Opera-2.mp4  PARSIFAL - Bavarian State Opera.mp4

Error: Nonexisting input files. Aborting.

$ ls -la
total 573M
664 -rw-rw-r-- 1 nikhil nikhil 123M 2022-04-15 19:57 PARSIFAL - Bavarian State Opera-1.mp4
664 -rw-rw-r-- 1 nikhil nikhil 123M 2022-04-15 19:57 PARSIFAL - Bavarian State Opera-2.mp4
664 -rw-rw-r-- 1 nikhil nikhil 169M 2022-04-15 19:57 PARSIFAL - Bavarian State Opera-3.mp4
664 -rw-rw-r-- 1 nikhil nikhil 161M 2022-04-15 19:41 PARSIFAL - Bavarian State Opera.mp4
$  renamer  *.mp4
Error: No replacements found

Would you happen to be on FreeBSD?

Ubuntu 20.4

I can't replicate this on my machine 😕 Does this only happen for files with spaces or does this happen every time?
Are you able to compile the code? If so what happens if you run renamer with this line commented?
https://github.com/marcusbuffett/pipe-rename/blob/53a97b850c9b55ffb68ad4c81cca524eca170eb4/src/main.rs#L328

Error is shown even if file exists!
$ ls
PARSIFAL - Bavarian State Opera-1.mp4  PARSIFAL - Bavarian State Opera-3.mp4
PARSIFAL - Bavarian State Opera-2.mp4  PARSIFAL - Bavarian State Opera.mp4

But these two files (!) do not exist, do they 😉?
And that is the reason why you shouldn't use ls as input for pipes in general or parse its output, especially without some basic precautions. E.g. using ls -1 or ls -Q (no idea if this would work, given how renamer implements its logic) etc.
The appropriate (and more powerful) option is to use find -type f if you want to really pipe the input, but renamer will also happily do renamer * for this particular case (proved by the output in your own initial comment).

$ ls | renamer
The following input files do not exist:
PARSIFAL - Bavarian State Opera-1.mp4  PARSIFAL - Bavarian State Opera-3.mp4
PARSIFAL - Bavarian State Opera-2.mp4  PARSIFAL - Bavarian State Opera.mp4

Error: Nonexisting input files. Aborting.

Yep, clearly they don't exist as your subsequent ls -la proves. At least I don't see two files named:

PARSIFAL - Bavarian State Opera-1.mp4  PARSIFAL - Bavarian State Opera-3.mp4
PARSIFAL - Bavarian State Opera-2.mp4  PARSIFAL - Bavarian State Opera.mp4
... instead it's four files:
PARSIFAL - Bavarian State Opera-1.mp4
PARSIFAL - Bavarian State Opera-2.mp4
PARSIFAL - Bavarian State Opera-3.mp4
PARSIFAL - Bavarian State Opera.mp4
... whose namea end in .mp4 and starts with PARSIFAL, right?

Your shell should have done the right thing for you with renamer * and renamer would have interpreted it correctly (actually it did as the last line of output you provided proves).
What shell are you using? Perhaps provide the output of the following commands:
$SHELL --version; env|grep -P '^(LC_|LANG|EDITOR)'

@mtimkovich @marcusbuffett I strongly suggest closing this. This seems to be a case of wrong usage rather than a defect in renamer as I showed in my previous commit.


[LeadSpace] Update styles to apply color theme as a container modifier

User Story

As a [user role below]:
IBM.com adopter

I need to:
apply a color theme modifier class at the same level as the container level class of the leadspace

so that I can:
easily switch color themes

Additional information

Currently, the color theme class is a parent class to the bx--leadspace class. This will need to be modified to be the same level as bx--leadspace.

Acceptance criteria

[ ] Updated storybook stories, scss, and React prop for switching themes

Will this be in Release v1.2.0 @jeffchew


A collection of MolStandardize improvements

Here's (most of) what's there:

Integrate the default parameters for the standardizer into the code (removing the requirement for the files, which was a problem for things like the MinimalLib). You can still specify filenames if wanted
Allow providing parameters via JSON
Completes a bunch of API functions which were just placeholders (i.e. which would generate exceptions if called). Most of these also required signature changes, but I don't feel overly guilty about changing the signature for functions which haven't actually be useable until this point.
a bunch of generic formatting and cleanup

@greglandrum I'm ready to merge, but conflicts crept in.


Two questions about eICU database (v2.0)

1.Does the eICU database (v2.0) collect patient mortality (like the MIMIC database) to allow the calculation for 28-day mortality? Thank you
2.In the table 'apachepredvar', I don't know the diagnostic criteria about aids, lymphoma, diabetes, etc. Thank you

In general it's better to raise a single issue about a single question with an informative title. It will make it easier for future users to search for these questions. Thanks!
To answer:

No. Only in-hospital mortality is collected.
These are comorbid conditions documented during a patient's stay in order to apply the APACHE IV system. You can read about them in the APACHE IV article: Acute Physiology and Chronic Health Evaluation (APACHE) IV: Hospital mortality assessment for today’s critically ill patients.


[stable/rabbitmq] podAnnotations value

What this PR does / why we need it:
This PR adds a podAnnotations value to be used to annotate pods in the rabbitmq StatefulSet
in downstream charts.

/check-cla

/ok-to-test


Fix set cgo 1 in dockerfile 2.1

/assign @elgnay

/close
2.1 is not supported. No need to merge this.


iOS 10 support

Sidebar doesn't respect safe margin insets on iOS 10.

Would you be willing to submit a pull request?


Fixes #6429 Reorganize scripts/e2e folder

Which problem is this PR solving?

Fix #6429

Description of the changes

In this PR all categories of e2e tests moved to e2e/ directory within scripts folder

How was this change tested?

Attaching screenshot below :

Checklist

[X] I have read https://github.com/jaegertracing/jaeger/blob/master/CONTRIBUTING_GUIDELINES.md
[x] I have signed all commits
[ ] I have added unit tests for the new functionality ~not needed
[ ] I have run lint and test steps successfully ~not needed

for jaeger: make lint test
for jaeger-ui: npm run lint and npm run test

Please fix DCO

@Ashu463 you also need to update files referring to those scripts

closing until at least one PR is done right