[Bug][dolphinscheduler-common] when Kerberos authentication is enabled and hadoop.http.authentication.type is set to kerberos and ResourceManager HA is enabled，you cannot get application status

**For better global communication, Please describe it in English. If you feel the description in English is not clear, then you can append description in Chinese(just for Mandarin(CN)), thx! **
Describe the bug
when Kerberos authentication is enabled and hadoop.http.authentication.type is set to kerberos and ResourceManager HA is enabled，you cannot get application status
To Reproduce
Steps to reproduce the behavior, for example:

ResourceManager HA enable
Kerberos authentication  yarn cluster
http authentication  enable ,hadoop.http.authentication.type is set to kerberos . see detail https://hadoop.apache.org/docs/r2.7.6/hadoop-project-dist/hadoop-common/HttpAuthentication.html
run a application on yarn by dolphinscheduler

Expected behavior
application success on yarn ,but dolphinscheduler get failed status
Screenshots
status on yarn

log

Which version of Dolphin Scheduler:
1.3.5
** improvement**

when kerberos enable，use  KerberosHttpClient   in YarnHAAdminUtils.getRMState method

What are the following two property configurations in the common.properties file
yarn.resourcemanager.ha.rm.ids=192.168.xx.xx,192.168.xx.xx
yarn.application.status.address=http://ds1:8088/ws/v1/cluster/apps/%s

What are the following two property configurations in the common.properties file
yarn.resourcemanager.ha.rm.ids=192.168.xx.xx,192.168.xx.xx
yarn.application.status.address=http://ds1:8088/ws/v1/cluster/apps/%s

yarn.resourcemanager.ha.rm.ids=<IP_ADDRESS>,<IP_ADDRESS>
yarn.application.status.address=http://yarnIp1:8088/ws/v1/cluster/apps/%s

@daipeng1104
Check that YARN IP (<IP_ADDRESS>,<IP_ADDRESS>) is valid
Application by accessing http://<IP_ADDRESS>:8088/ws/v1/cluster/info and http://<IP_ADDRESS>:8088/ws/v1/cluster/info to detect the state determine the survival of the ResourceManager
Look through you provide log, <IP_ADDRESS>, <IP_ADDRESS> invalid IP, to active the ResourceManager

@daipeng1104
Check that YARN IP (<IP_ADDRESS>,<IP_ADDRESS>) is valid
Application by accessing http://<IP_ADDRESS>:8088/ws/v1/cluster/info and http://<IP_ADDRESS>:8088/ws/v1/cluster/info to detect the state determine the survival of the ResourceManager
Look through you provide log, <IP_ADDRESS>, <IP_ADDRESS> invalid IP, to active the ResourceManager

I found the reason in the source code. In Ha mode,  YarnHAAdminUtils.getAcitveRMName  called to detect the active RM  .     but  when kerberos http authentication enabled  (core-site.xml),  the method will always return null . The reason is because the HttpUtils.get(url) can not get result when kerberos http authentication enabled .
in the dev branch, the KerberosHttpClient can solve the problem.  but  YarnHAAdminUtils.getRMState methods need to be modified to adapt  kerberos http authentication by call KerberosHttpClient.get() .

@daipeng1104
You are welcome to submit a PR to fix this.


fix(react): ensure Symbol-polyfill is present in time

...which is a delicate issue since babel-preset-env does not parse React files for usages.
@dmbch PTAL

This among other things fixes untool apps in ie11.

Why do we not just remove react (or react-dom - I am not quite sure where the issue  is originating) from jsLoader’s excludes? If it is actually react itself, there should be no significant performance implications...

Speaking of which: are we still convinced we should exclude any packages from transpilation at all? IIRC, it only gives us a perceivable performance boost for the initial transpilation as we have caching enabled.

@dmbch iirc you were the who found out that those three packages have a significant impact on transpilation and hence build time. If that's still the case, manually adding the Symbol polyfill could be a feasible tradeoff.

it only gives us a perceivable performance boost for the initial transpilation as we have caching enabled.

Imo there's also value in having a faster initial transpilation, although I obviously prefer working software over a slightly faster build.
That being said, I think I need to educate myself more about webpack and babel caches actually work especially when they are busted etc.

@robin-drexler yes, I am afraid this one was up to me... On a clean working copy, I just checked the different build times with and without the babel excludes:
Baseline (w/ excludes)
$ cd tests/fixtures/untest; un build -p
...
Child build:
    Time: 8147ms
    ...
Child node:
    Time: 4514ms
    ...
✨  Done in 9.58s.
$ cd tests/fixtures/untest; un build -p
...
Child build:
    Time: 2960ms
    ...
Child node:
    Time: 2417ms
    ...
✨  Done in 4.10s.

De-optimized/fixed (w/o excludes)
$ cd tests/fixtures/untest; un build -p
...
Child build:
    Time: 10530ms
    ...
Child node:
    Time: 6585ms
    ...
✨  Done in 11.99s.
$ cd tests/fixtures/untest; un build -p
...
Child build:
    Time: 3450ms
    ...
Child node:
    Time: 2938ms
    ...
✨  Done in 4.57s.

I did notice some slowdown of incremental rebuilds (HMR) - around 20-50ms per rebuild. All these numbers are completely unscientific, of course.
Nevertheless: while I am convinced we would be able to shave off a couple of seconds from our build times by keeping those excludes, I tend to give up trying and working around their adverse effects. The effect we are tackling here is really quite obscure and rather hard to detect. Playing whac-a-mole with such issues is not something I would like us to spend time with...

Btw., thank you @herschel666 and @jhiode for debugging the issue and opening this PR!

yes, I am afraid this one was up to me...

I didn't mean to put any blame on you. Actually, I think that was a great finding!
Nobody at the time did expect this performance workaround to cause such troubles!

The effect we are tackling here is really quite obscure and rather hard to detect. Playing whac-a-mole with such issues is not something I would like us to spend time on...

100% agree. I can tell it took some time going from "This is broken in IE. Seems to be the Symbol issue again. Didn't we fix this?" to "This is only broken in production but works in development" to "Wait, this actually never worked in prod, only dev" to  "It also and only breaks in dev when we remove the hmr middleware entry" to "Why is react.production.min.js not going through transpilation?" to "OMG! WTF! LET'S GO BOOZE and flip some tables on the way  out." :D


align right image is not working??

 <md-list>           <md-list-item *ngFor="let item of messages" align="right">             <img md-list-avatar src="assets/avatar/avatar.png" alt="...">              <h3 md-line> {{item.name}} </h3>             <p md-line>               <span> {{item.message}} </span>             </p>           </md-list-item>         </md-list>

I want it this way

@crisbeto can you determine if there's a bug here?

there's no bug but i want the avatar to align also in the right corner in my chat app..alternatively when someone reply....it's more in css i think

You can achieve the same by setting the list in RTL mode @dreweird:
<md-list dir="rtl">
  <h3 md-subheader>Items</h3>
  <md-list-item *ngFor="let item of items">
    {{item}}
  </md-list-item>
</md-list>

Note that you can also do this on individual list items.


Add random baseline

Added in PR #19. See assets/scores.txt and assets/random_baseline_*.png for an overview, or run the random demonstration agent by calling
python evaluation/eval.py


Add README.md for third party External tests

Signed-off-by: Mesbah<EMAIL_ADDRESS>

Thanks Shelley, I have added the hyperlink of the URL.


Improve FhirIO LRO Counters + minor fixes

Log the operation status + increment counters, not just # of success/failures.
Polling every 500ms is excessive, 15 seconds should be enough for expected time for an operation to complete.
Remove unsupported content structure for FHIR imports:
FhirIO.Import specifically formats input JSON into NDJSON (even for pretty input) and then writes multiple resources to a single file. Therefore, only RESOURCE or BUNDLE content type can be specified. There is no functionality lost here, as pretty JSON can still be passed as input and will be transformed before the import operation begins.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Run Java PostCommit

Run Java PostCommit

Run Java PostCommit

LGTM


fix: Error rate scale

Also go ahead and bump version and build.

Description

Motivation and Context

issue
How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

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

Author's Checklist:

[ ] My code focuses on the main motivation and avoids scope creep.
[ ] My code passes current tests and adds new tests where possible.
[ ] My code is SOLID and DRY.
[ ] I have updated the documentation as needed.

Reviewer's Checklist:

[ ] I kept my comments to the author positive, specific, and productive.
[ ] I tested the code and didn't find any new problems.
[ ] I think the motivation is good for the project.
[ ] I think the code works to satisfies the motivation.

brain.NeuralNetwork use percent of likelihood, brain.recurrent.RNN uses ratio of prediction (base 2 logarithm).  The answer here was to simply divide the ratio so it would be closer to the scale used in brain.NeuralNetwork.


conf file parsing should be generalized

Right now, the new calico conf file is not parsed correctly.

Conf file parsing generilazion is acheived through merge of below PR, this issue can be closed

Conf file parsing generilazion is acheived through merge of below PR, this issue can be closed

Conf file parsing generilazion is acheived through merge of below PR, this issue can be closed
https://github.com/Huawei-PaaS/CNI-Genie/pull/73


Rule idea: at-import-no-invalid-position

The same rule as no-invalid-position-at-import-rule but works with scss at-rules.
Related tickets:

https://github.com/kristerkari/stylelint-scss/issues/524
https://github.com/kristerkari/stylelint-scss/issues/531
https://github.com/stylelint/stylelint/issues/5322
https://github.com/stylelint/stylelint/issues/5492

I think that this can be added as a new rules since the new syntax in Sass conflicts with the stylelint rule.

FYI, an ignoreAtRules:[] option was added in https://github.com/stylelint/stylelint/pull/5520 and will be available in 14.0.0.
You can use that option in this scss/no-invalid-position-at-import-rule rule.

The no-invalid-position-at-import-rule offenses a lot about nested @import, which are supported by S(A/C)SS.


Errors out when trying to download

The download "completes" and errors out at 0 percent when trying to dl from youtube.  Latest version.  Windows 7

Yeah, its already reported here.
I'm going to be assuming what's causing the problem here, as I am in no way connected to the devs. But I'm also pretty sure I know whats wrong, considering that the cause of the issue happened in the past month or so and the last update was about 3 months ago.
Youtube-dl-gui is attempting to download the latest binaries from the GitHub Repo which is currently down. The latest updates for the youtube-dl binaries are currently being hosted on their website, here for Windows and here for Linux. The source is available here as well.
As a temporary fix for the situation so you can still use the GUI as normal, you can download the binaries manually and replace the current ones, while also remembering to disable automatic updates until it gets fixed.
The short version of why this is happening is because youtube-dl got DMCA'd off GitHub by everyone's favorite destroyer of fun and happiness, the RIAA. Its absolutely ridiculous, but a complaint was made that youtube-dl could be used to download copyrighted music. As if any sane human would ever want to have a whole collection of garbage-quality lossy-to-lossy transcoded music.
If you're interested and wanna read up on this absolutely ludicrous situation, you can check out this article on this situation by the EFF, or this article by Hackaday.

@nf33 You can actually disregard my last comment, everything is finally sorted out. YouTube-DL GUI should now function as expected when trying to update

The download "completes" and errors out at 0 percent when trying to dl from youtube. Latest version. Windows 7

See like @h3xpl01t say https://github.com/oleksis/youtube-dl-gui/issues/2#issuecomment-727641748 fix your problem for close the issue.


First draft: deep engineering blog post on performance experiments.

This PR provides a second blog post for the Amazing Performance series. It details a fix to the Python runtime, which improved performance by 317%. It describes our benchmarking setup and the experimental results.

@cnunciato @scottslowe can I get some early feedback on this? I just want to know if I'm moving in the right direction.

@RobbieMcKinstry I'll give this a look shortly. In the meantime, note that it is failing to build preview URLs due to some linting errors:

@RobbieMcKinstry I just finished giving this a content review. Overall, I think this is moving in the right direction; I look forward to seeing the finished product!
One general question: since the article is about Python, why is the first code sample written in JavaScript?

@justinvp Do you think we should land this blog or close the PR?


Standardize release, branching and labeling process for all org repos

Coming from https://github.com/opensearch-project/opensearch-plugins/issues/35, and https://github.com/opensearch-project/.github/pull/11, but that merges OpenSearch, OpenSearch Dashboards and plugins.

[x] OpenSearch - https://github.com/opensearch-project/OpenSearch/pull/853
[x] OpenSearch Dashboards - https://github.com/opensearch-project/OpenSearch-Dashboards/issues/527
[x] Plugins - https://github.com/opensearch-project/opensearch-plugins/issues/41

Let's also add text to https://github.com/opensearch-project/.github/blob/main/RELEASING.md about backporting changes.

@dblock copying the comment to the main tracking issue here:
Few questions about the differences between core & plugins:

Branches - with ODFE, branches followed the convention opendistro-<major>-<minor> - shall we do the same now but with opensearch-<major>-<minor>?
Tags - plugins have a 4th digit for plugin-related patching changes - shouldn't the labels be v<IP_ADDRESS>, etc, instead of just 3 digits like core?

Branches - with ODFE, branches followed the convention opendistro-<major>-<minor> - shall we do the same now but with opensearch-<major>-<minor>?

I find that rather unusual or unnecessary since It's not like we release plugins for multiple targets, and so I would just do what engine does and call them -.

Tags - plugins have a 4th digit for plugin-related patching changes - shouldn't the labels be v<IP_ADDRESS>, etc, instead of just 3 digits like core?

A version target is useful when you work on multiple releases, so while this sounds like a good idea, I think we will quickly end up with tons of labels, so maybe there should be a next patch label? WDYT? Open a PR into this repo with what you think we should do?

I find that rather unusual or unnecessary since It's not like we release plugins for multiple targets, and so I would just do what engine does and call them -.

Makes sense. I'm ok with removing the prefix and just going with <major>-<minor> for consistency with core.

A version target is useful when you work on multiple releases, so while this sounds like a good idea, I think we will quickly end up with tons of labels, so maybe there should be a next patch label? WDYT? Open a PR into this repo with what you think we should do?

I think this seems reasonable. That way the versions are always aligned with core, and plugins can maintain any patches with a patch label. I'm thinking patch instead of next patch, since we may have some patch (like a security or bug fix) that we will want to backport to older versions, instead of treating it as a patch only for the upcoming / current release.
I'll open a PR - can continue discussion there.

@dblock opened #17. I'm unable to add reviewers due to maintainer and/or write access issues. Please take a look there. Thanks!

@dblock
It seems with the current model we have plugins building from the equivalent branches for dependent plugins and upstream OpenSearch/OpenSearch Dashboards.
I'm not a fan of this model for plugin development. I don't like the fact that contributors across our plugins can be opening a PR to our main branch (i.e. our development branch) for some foobar feature and have it passing and then you rerun the test and now it's failing because a contributor in OpenSearch made some change that broke something in plugins or caused an issue in OpenSearch itself that is now causing downstream plugin repos compile/install/tests to be failing.
I do understand it helps catch regressions in OpenSearch itself and warns plugin developers of possible impending breaking changes, but it should not cause friction down to the plugin repositories to the point of blocking PRs. If a plugin developer sees things start breaking in a PR they will more than likely assume something is wrong with their code and work on fixing it. They might have zero experience w/ OpenSearch upstream and waste a lot of time on something that had nothing to do with their changes.
Plugins should be developing based on the latest stable release and if we want to catch regressions in OpenSearch for the plugin framework then there should be

more tests in OpenSearch for the plugin framework if we feel we are lacking, that being said there are a lot of plugins already in OpenSearch so these should be getting tested.
OpenSearch can pull the official supported plugins and do a compile/install/test check to see if the change broken something downstream. Although it'll run into the same issue of if the plugins branch is flaky or failing now it'll cause unwanted fatigue on OpenSearch having to know if they broke something or it was the plugin.

Plugins should be developing based on the latest stable release

The OpenSearch product/bundle model is a single release of core + all plugins. Sounds like a catch-22.

I am going to close this. We have https://github.com/opensearch-project/.github/blob/main/RELEASING.md#branching, which likely actually belongs in opensearch-plugins, opensearch-build or a combination of those.


Crash when pasting text

Windows Terminal version
1.14.1451.0
Windows build number
10.0.19044.1706
Other Software
No response
Steps to reproduce
Pasted a multi-line text into the terminal (nothing excessive, 5 lines 144 chars each, ascii)
Expected Behavior
No response
Actual Behavior
Crashed all tabs with no error message. The multi-line paste warning did not appear (it was a multi-line paste).
I can't reliably reproduce the issue (pasting the exact same text worked OK on a retry). I get that this is not very actionable, but that's all I have at the moment. If there's some crash dump path I can look into, or settings to make future crashes dump some info,  I'd appreciate hints.

Can you try following the steps in this post to set up automatic crash dumps/? (For more info, see this link) If that works, then you should be able to automatically get a .dmp of the terminal when it crashes. Then, can you zip that dump up and send it to us, so we can investigate? Thanks!

I definitely will, thanks!

Interesting, I must've followed that exact guide some time in the past and long since forgotten about it -- but it seems I had this active, and I do have a WindowsTerminal.exe dump. It seems to correspond, modification-time-wise, to when I had the crash.
The file is 17MB, 2Mb compressed. Should I just attach it here?

@ilor Such dumps can contain private data (like usernames and other bits of information).
Could you send the dump via mail to <my github<EMAIL_ADDRESS>I'll then forward it to the rest of the team. 🙂
(An informal mail is absolutely fine.)

tl;dr:

It's an unhandled error in Windows_UI_Xaml!DirectUI::ErrorHelper::ProcessUnhandledError
The HRESULT m_ErrorCode passed to that function is 0x80004005 (Unspecified error)
The m_description string for the error has been stripped from the MiniDump 😿
Failure bucket – no hits: a14d2eeb-64f1-cf9a-221e-7e98eff63046

Maybe there's a !xamlstowed exception in there, but it sounds like the dump unfortunately didn't have anything useful to work with. If you can get a reliable repro at all, then trying to repro this with a Feedback Hub recording might be useful. That sometimes catches extra information. (The bot is about to recommend the Terminal area path in feedback hub, but I might recommend

instead)
/feedback

I'm gonna close this as an intermittent failure. If you start seeing this regularly again, let us know and we can reopen and investigate more. Thanks!


WFLY-5027 change default Hibernate OGM module name and slot to org.hibernate.ogm:main

Linux Build 7216 is now running using a merge of 074f8a20557349b7f75865a9da64520d4c57684f

Windows Build 2271 is now running using a merge of 074f8a20557349b7f75865a9da64520d4c57684f

Linux with security manager Build 2087 is now running using a merge of 074f8a20557349b7f75865a9da64520d4c57684f

Linux with security manager Build 2087 outcome was SUCCESS using a merge of 074f8a20557349b7f75865a9da64520d4c57684f
Summary: Tests passed: 879, ignored: 281 Build time: 0:06:18

Linux Build 7216 outcome was SUCCESS using a merge of 074f8a20557349b7f75865a9da64520d4c57684f
Summary: Tests passed: 2958, ignored: 354 Build time: 0:46:41

Windows Build 2271 outcome was SUCCESS using a merge of 074f8a20557349b7f75865a9da64520d4c57684f
Summary: Tests passed: 2956, ignored: 355, muted: 1 Build time: 0:48:01


release/0.2.2

update name, home, and bump version
MNT: Re-rendered with conda-build 3.21.8, conda-smithy 3.22.0, and conda-forge-pinning 2<IP_ADDRESS>.56.36

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Resolves #6


[$1000] Green dot is not removed from LHN when deleting mention

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Sign in with account A
Mention account B from the tab where account A is signed in
Switch to the tab where account B is signed in
Verify that green dot is displayed on LHN
Switch to the tab where account A is signed in
Delete the mention
Switch to the tab where account B is signed in

Expected Result:
Green dot should be removed from LHN
Actual Result:
Green dot is not removed even if the mention is deleted
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

Version Number: <IP_ADDRESS>
Reproducible in staging?: y
Reproducible in production?:
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/43996225/cd0814a0-58f7-44d3-a2fc-5e734300a8c2
https://github.com/Expensify/App/assets/43996225/3eae00b6-a8a5-4eca-970d-8419bdd81969
Expensify/Expensify Issue URL:
Issue reported by: @Natnael-Guchima
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1683803752921809
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01bab306d114847c77
Upwork Job ID:<PHONE_NUMBER>501494784
Last Price Increase: 2023-05-12

Yup, I can reproduce this on the latest staging and on desktop as well. After deleting the message containing a mention, the green dot persists in the chat. Moving on external.
CC: @puneetlath

Heads up, the root cause might be interlinked with the you persisting: https://github.com/Expensify/App/issues/18850

This is actually a back-end thing and a case we decided not to support out of the gates.

Cool, so it needs to come internal then, yeah? Do you want to add this issue to some kind of project tracker or is it on your radar somewhere else?

We actually specifically decided not to support editing/deleting considerations for now (link to convo). In the next iteration of mentions, we may decide to support it, but that'll be discussed in the design doc. I'm going to go ahead and close this, but feel free to reopen if you disagree!


Lucia deprecation thoughts

Hello,
This is more for an opinion and information to understand if there is any plan to do anything with the Lucia implementation since the maintainer announced that the lib will be deprecated in favor of using it as a source learning tool.

I'd be open to alternatives. The current version works for me though

I don't have an alternative yet. Since I'm going to start using justship, I came cross this announcement and I was wondering if you had anything in mind to change or not.
Honestly, I don't know if this will impact or affect the ability to keep up with the updates after depreciation.


[BUG] progress.csv saved incorrectly

Required prerequisites

[X] I have read the documentation https://omnisafe.readthedocs.io.
[X] I have searched the Issue Tracker and Discussions that this hasn't already been reported. (+1 or comment there if it has.)
[X] Consider asking first in a Discussion.

What version of OmniSafe are you using?
0.3.0
System information
ubuntu 20.04
0.3.0
Problem description
After I ran some experiments, I tried to analyze these results via `StatisticsTools class. There is something that went wrong in the .csv file. And I am sure the processes end with no error.

  File "~/anaconda3/envs/test_vel/lib/python3.8/site-packages/matplotlib/_api/__init__.py", line 93, in check_isinstance
    raise TypeError(
TypeError: 'value' must be an instance of str or bytes, not a float

Reproducible example code
The Python snippets:
    eg = ExperimentGrid(exp_name='benchmark')

    # Set the algorithms.
    base_policy = ['PPO', 'PolicyGradient', 'P3O', 'PPOLag', 'FOCOPS', 'CUP', 'NaturalPG', 'TRPO']
    first_order_policy = ['CUP', 'FOCOPS', 'TRPOLag']
    second_order_policy = ['CPO', 'PCPO', 'RCPO']

    # Set the environments.
    mujoco_envs = [
        # 'SafetyAntVelocity-v4',
        # 'SafetyHopperVelocity-v4',
        # 'SafetyHumanoidVelocity-v4',
        'SafetyWalker2dVelocity-v4',
        # 'SafetyHalfCheetahVelocity-v4',
        # 'SafetySwimmerVelocity-v4',
    ]
    eg.add('env_id', mujoco_envs)

    # # Set the device.
    # avaliable_gpus = list(range(torch.cuda.device_count()))
    # gpu_id = [0, 1, 2, 3]
    # # if you want to use CPU, please set gpu_id = None
    # # gpu_id = None

    # if not set(gpu_id).issubset(avaliable_gpus):
    #     warnings.warn('The GPU ID is not available, use CPU instead.', stacklevel=1)
    #     gpu_id = None

    eg.add('algo', base_policy + first_order_policy + second_order_policy)
    eg.add('logger_cfgs:use_wandb', [False])
    eg.add('train_cfgs:vector_env_nums', [1])
    eg.add('train_cfgs:torch_threads', [1])
    eg.add('algo_cfgs:update_cycle', [2048])
    eg.add('train_cfgs:total_steps', [10240000])
    eg.add('seed', [i for i in range(0, 51, 5)])
    # total experiment num must can be divided by num_pool
    # meanwhile, users should decide this value according to their machine
    eg.run(train, num_pool=140)

    # just fill in the name of the parameter of which value you want to compare.
    # then you can specify the value of the parameter you want to compare,
    # or you can just specify how many values you want to compare in single graph at most,
    # and the function will automatically generate all possible combinations of the graph.
    # but the two mode can not be used at the same time.
    # eg.analyze(parameter='algo', values=None, compare_num=6, cost_limit=25)
    eg.render(num_episodes=10, render_mode='rgb_array', width=256, height=256)
    # eg.evaluate(num_episodes=1)

Command lines:

Extra dependencies:

Steps to reproduce:

just run the python script via experiment gird.
using StatisticsTools to analyze.

Traceback
File "~/anaconda3/envs/test_vel/lib/python3.8/site-packages/matplotlib/_api/__init__.py", line 93, in check_isinstance
    raise TypeError(
TypeError: 'value' must be an instance of str or bytes, not a float

Expected behavior
No response
Additional context
No response

I noticed that you specify twice 'CUP' in 'algo'. If you ran all experiments at the same time, it would make CUP run twice at the same time. It will cause maybe two processes to be writing one single prograss.csv because they are launched at the same time (so they have the same file name).
We will add assert to prevent this situation. Thanks for your feedback.


Deploy commands

Attention: I'm targeting the integration-tests branch because this PR depends on #5. After #5 is merged I'll rebase and change the target of this PR.
How to test this PR:
Setup tranor

check it out locally
make sure you have latest version of tsuru-client (brew install tsuru/tsuru/tsuru, apt-get install tsuru-client or checkout and build)
run tsuru install
run TSURU_TEST_HOST=http://<IP_ADDRESS>:8080 TSURU_TEST_TOKEN=$(tsuru token-show | awk '{print $3}') make prepare-test-server
configure tranor: tranor target-set https://gist.githubusercontent.com/fsouza/ac50e24d18bd7c24588164481fa3686b/raw/482b60f8ecff0cf77bcc2db8903dff5492910447
create a project: tranor project-create -n myproj -l python -t myteam

Deploy to dev

change association of docker node to dev pool: tsuru-admin docker-node-update https://<IP_ADDRESS>:2376 'pool=dev\dev.example.com'
deploy some code to dev (simple-flask-example, for example) tranor project-deploy -n myproj -e dev .

% tranor project-deploy -n myproj -e dev .
Uploading files (0.01MB)... 100.00% Processing..... ok
/home/application/current /
Collecting Flask==0.10.1 (from -r /home/application/current/requirements.txt (line 1))
  Downloading Flask-0.10.1.tar.gz (544kB)
Collecting Werkzeug>=0.7 (from Flask==0.10.1->-r /home/application/current/requirements.txt (line 1))
  Downloading Werkzeug-0.11.11-py2.py3-none-any.whl (306kB)
Collecting Jinja2>=2.4 (from Flask==0.10.1->-r /home/application/current/requirements.txt (line 1))
  Downloading Jinja2-2.8-py2.py3-none-any.whl (263kB)
Collecting itsdangerous>=0.21 (from Flask==0.10.1->-r /home/application/current/requirements.txt (line 1))
  Downloading itsdangerous-0.24.tar.gz (46kB)
Collecting MarkupSafe (from Jinja2>=2.4->Flask==0.10.1->-r /home/application/current/requirements.txt (line 1))
  Downloading MarkupSafe-0.23.tar.gz
Installing collected packages: Werkzeug, MarkupSafe, Jinja2, itsdangerous, Flask
  Running setup.py install for MarkupSafe: started
    Running setup.py install for MarkupSafe: finished with status 'done'
  Running setup.py install for itsdangerous: started
    Running setup.py install for itsdangerous: finished with status 'done'
  Running setup.py install for Flask: started
    Running setup.py install for Flask: finished with status 'done'
Successfully installed Flask-0.10.1 Jinja2-2.8 MarkupSafe-0.23 Werkzeug-0.11.11 itsdangerous-0.24
/

---- Building application image ----
 ---> Sending image to repository (5.05MB)
 ---> Cleaning up

---- Starting 1 new unit [web: 1] ----
 ---> Started unit ce122a515e [web]

---- Binding and checking 1 new unit ----
 ---> Bound and checked unit ce122a515e [web]

---- Adding routes to new units ----
 ---> Added route to unit ce122a515e [web]

---- Setting router healthcheck (Path: /) ----

OK

Promote to prod

change association of docker node to prod pool (I know it sucks, but we only have one node and a node cannot belong to multiple pools): tsuru-admin docker-node-update https://<IP_ADDRESS>:2376 'pool=prod\example.com'
promote from dev to prod tranor project-deploy -n myproj -e prod -p dev

% tranor project-deploy -n myproj -e prod -p dev
Deploying image... ok
---- Pulling image to tsuru ----
v2: Pulling from tsuru/app-myproj-dev
Digest: sha256:6b75330ea30924e31670da1f42f9aabf857fd9fc116d6c44fef4e6e7143ccb8e
Status: Downloaded newer image for localhost:5000/tsuru/app-myproj-dev:v2
---- Getting process from image ----
  ---> Process web found with command: python app.py
---- Pushing image to tsuru ----
The push refers to a repository [<IP_ADDRESS>:5000/tsuru/app-myproj-prod]
14d2416c85ce: Preparing
5e78ab837922: Preparing
422dbb1fdd60: Preparing
ff00b786a1f6: Preparing
a7ff9f535719: Preparing
f2b7c55206b1: Preparing
ddd02798417c: Preparing
fcbecd85db47: Preparing
6cb2a13b80d9: Preparing
5f70bf18a086: Preparing
45befd8a8901: Preparing
f2b7c55206b1: Waiting
ddd02798417c: Waiting
fcbecd85db47: Waiting
6cb2a13b80d9: Waiting
5f70bf18a086: Waiting
45befd8a8901: Waiting
ff00b786a1f6: Mounted from tsuru/app-myproj-dev
5e78ab837922: Mounted from tsuru/app-myproj-dev
14d2416c85ce: Mounted from tsuru/app-myproj-dev
a7ff9f535719: Mounted from tsuru/app-myproj-dev
422dbb1fdd60: Mounted from tsuru/app-myproj-dev
ddd02798417c: Mounted from tsuru/app-myproj-dev
f2b7c55206b1: Mounted from tsuru/app-myproj-dev
fcbecd85db47: Mounted from tsuru/app-myproj-dev
45befd8a8901: Mounted from tsuru/app-myproj-dev
6cb2a13b80d9: Mounted from tsuru/app-myproj-dev
5f70bf18a086: Mounted from tsuru/app-myproj-dev
v1: digest: sha256:6b75330ea30924e31670da1f42f9aabf857fd9fc116d6c44fef4e6e7143ccb8e size: 2621

---- Starting 1 new unit [web: 1] ----
 ---> Started unit 71b4c89262 [web]

---- Binding and checking 1 new unit ----
 ---> Bound and checked unit 71b4c89262 [web]

---- Adding routes to new units ----
 ---> Added route to unit 71b4c89262 [web]

---- Setting router healthcheck (Path: /) ----

OK

Deploy directly to prod

try to deploy directly to prod tranor project-deploy -n myproj -e prod .

% tranor project-deploy -n myproj -e prod .
Error: can only deploy directly to "dev", use -p/--promote to deploy to other environments

I also updated README and added some documentation to usage.md.

Current coverage is 95.29% (diff: 100%)

Merging #6 into integration-tests will increase coverage by 0.57%

@@           integration-tests         #6   diff @@
===================================================
  Files                      6          7     +1
  Lines                    757        850    +93
  Methods                    0          0
  Messages                   0          0
  Branches                   0          0
===================================================
+ Hits                     717        810    +93
  Misses                    23         23
  Partials                  17         17

Powered by Codecov. Last update a0675d1...69a1da6


Use compute data-disk attach for either data-disks or VHD page blobs.

Resolves #206 .

General comment since --disk-name moves from required to optional we make an API change and push the version to 3.0.0. I am OK with that, just wanted to point that out.

@schaefi can you do one more overall review?

@bear454 I looked over the code and apart from the two minor suggestions I'm fine with it, looks great to me. It would be nice if the commit list can be squashed before merge and there is also Robert's open review. It looks like he still has some concerns

As requested, I'm going to close this PR, squash the fixes in, and resubmit.


Separated toolchain tests from non-toolchain package builds.

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[X] The toolchain has been rebuilt successfully (or no changes were made to it)
[X] The toolchain/worker package manifests are up-to-date
[X] Any updated packages successfully build (or no packages were changed)
[X] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[X] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[X] All package sources are available
[X] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[X] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[X] All source files have up-to-date hashes in the *.signatures.json files
[X] sudo make go-tidy-all and sudo make go-test-coverage pass
[X] Documentation has been updated to match any changes to the build system
[X] Ready to merge

Summary

Backport of #10389.
We have a bug in the PR check where a change to a toolchain package prevents ptest from being run for all non-toolchain packages. This change moves toolchain ptests to a separate job, so the original BuildAndTest will build and test only non-toolchain packages.
Does this affect the toolchain?

No.
Test Methodology

PR check.

Auto cherry-pick results:

main :white_check_mark: -> https://github.com/microsoft/azurelinux/pull/10448

Auto cherry-pick pipeline run -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=639866&view=results


[WIP] Fix statistics issues

Fixes small issue where "Applicant" is used for "Application" statistics

I have looked into why the statistics page is so slow, and have found this function to be the greatest contributor:
# Count unique applicants and how many of those were actually admitted to Samfundet
  # This is done both for Samfundet as a whole and for each group
  def count_unique_applicants_in_groups
    @applicants = {}

    @admission.groups.map do |group|
      @applicants[group] = { total: Set[], accepted: Set[] }

      applicants = group.job_applications_in_admission(@admission).map(&:applicant).uniq
      applicants.each do |app|
        @applicants[group][:total].add app.id

        log_entries = LogEntry.where(admission_id: @admission.id, applicant_id: app.id, group_id: group.id)

        unless log_entries.empty?
          last_log = log_entries.last
          if application_is_accepted?(last_log)
            @applicants[group][:accepted].add app.id
          end
        end
      end

      calculate_group_applicants_admitted_ratio(@applicants[group])
    end
  end

It seems that particularly this line is very expensive because it must be done for every applicant for every job:
log_entries = LogEntry.where(admission_id: @admission.id, applicant_id: app.id, group_id: group.id)

Closed, these changes are described in issue #694

Delete branch?


Improve TLS connection establishment

Problem statement
NettyConnectionFactory may hand out a TCP connection whose TLS handshake has not yet been completed.
The channel is created and connected here:

    private ChannelFuture openConnection(Origin origin, ConnectionSettings connectionSettings) {
        bootstrap(connectionSettings);
        return bootstrap.connect(origin.host(), origin.port());
    }

    private synchronized void bootstrap(ConnectionSettings connectionSettings) {
        if (bootstrap == null) {
            bootstrap = new Bootstrap();
            bootstrap.group(executor.eventLoopGroup())
                    .channel(executor.clientEventLoopClass())
                    .handler(new Initializer())
                    .option(TCP_NODELAY, true)
                    .option(SO_KEEPALIVE, true)
                    .option(ALLOCATOR, PooledByteBufAllocator.DEFAULT)
                    .option(CONNECT_TIMEOUT_MILLIS, connectionSettings.connectTimeoutMillis());
            for (ChannelOptionSetting setting : httpConfig.channelSettings()) {
                bootstrap.option(setting.option(), setting.value());
            }
        }
    }

    private class Initializer extends ChannelInitializer<Channel> {
        @Override
        protected void initChannel(Channel ch) {
        }
    }

Notice the empty channel initialiser. The channel handlers are not added here where you expect. Instead, they are added later when the connection is established.
Netty connection is emitted via Mono.sink() when the TCP connection establishment completes. This is when the TLS handshake begins. So the handshake continues in the background, and yet the connection is emitted to the consumers.
We should really look at the TLS handshake future, and emit the connection only once it completes.
    public Mono<Connection> createConnection(Origin origin, ConnectionSettings connectionSettings, SslContext sslContext) {
        return Mono.create(sink -> {
            ChannelFuture channelFuture = openConnection(origin, connectionSettings);

            channelFuture.addListener(future -> {
                if (future.isSuccess()) {
                    sink.success(new NettyConnection(origin, channelFuture.channel(), httpRequestOperationFactory,
                            httpConfig, sslContext, sendSni, sniHost));
                } else {
                    sink.error(new OriginUnreachableException(origin, future.cause()));
                }
            });
        });
    }

Impact

This could result in requests failing unnecessarily if the handshake ends up in failure. The connection pool could have handed out an alternative connection instead.

But in a normal production use the TLS handshake would only fail if the origin is improperly configured. Either in Styx or in the remote end (the origin itself).

Also, some end-to-end tests may be affected. They are built assuming the connection pool never emits unless the connection is readily usable.

Luckily Netty SSL handler buffers all sent data chunks until the handshake completes. So there is no risk of losing data, nor sending anything unencrypted or unauthenticated.

Please clarify and document the Netty behaviour - and close this issue if no work is required.

Please clarify and document the Netty behaviour - and close this issue if no work is required.

Check above. I have edited the description.

Accidentally closed. Reopening.

Closing all issues over 3 years old. New issues can be created if problems are still occurring.


Update README.md

Updating access restrictions in SASL section of the readme as well as removing some unecessary configs.

Thanks! haven't used SASL myself so can't review, but i trust you! :)

It works well now, thank you very much


Fix default entrypoint handling on older Pythons

The fallback here for updating a dictionary needs to be a dictionary, not a list.
I haven't added any new tests or anything, but I can if I'm pointed in the right direction. Not sure how this library wants to test these types of edge cases with entry points.
Resolves #478
TODO:

[x] Unit tests and/or doctests in docstrings
[x] Tests pass locally
[ ] Docstrings and API docs for any new/modified user-facing classes and functions
[x] Changes documented in docs/release.rst
[ ] Docs build locally
[ ] GitHub Actions CI passes
[x] Test coverage to 100% (Codecov passes)

Thanks Vyas! 🙏
Made some tweaks to handle the release note. Hope that is ok. Please update as needed
Also maybe we should test this somehow. Currently we test the presence of a single entrypoint. Maybe we should also test the absence of any entrypoints?
https://github.com/zarr-developers/numcodecs/blob/a5539b5876fb76f014ac74c17fa98d805d5bbfda/numcodecs/tests/test_entrypoints.py#L22-L24

OK this fix isn't right. The issue isn't the fallback case, but rather a real case where numcodecs.codec is being registered as None. Looking into that now.

@martindurant , could you please look over this?

Was seeing AVX2 issues on macOS builds, that I thought we just fixed with PR ( https://github.com/zarr-developers/numcodecs/pull/479 ). So toggling PR to ensure latest changes in main are picked up

OSX failures are the sporadic:
#error AVX2 is not supported by the target architecture/platform and/or this compiler.

Trying a rebuild.

Maybe one more rerun? Looks like attempt 2 passed one of the previously failing jobs but the other failed again.

Have added a fix in main to disable AVX2 in macOS GHA jobs and merged that into here. That should resolve that issue

Since the only entrypoint added is coming from the test entrypoint that we load ourselves. Wonder if we can avoid using a subprocess by simply testing there are no entrypoints present (and effectively those code paths work) before trying to add our own entrypoint (to test that we can load entrypoints). What do you think Vyas?

Since the only entrypoint added is coming from the test entrypoint that we load ourselves. Wonder if we can avoid using a subprocess by simply testing there are no entrypoints present (and effectively those code paths work) before trying to add our own entrypoint (to test that we can load entrypoints). What do you think Vyas?

I'm afraid I don't understand how your suggestion avoids the problem. My concern is that because importlib_metadata is patching the standard library, as soon as the test importing it runs all subsequent tests in the same process will see the patched library. If there are any other edge cases where simply importing importlib_metadata causes problems, we would start seeing random unexpected failures in other tests based on test ordering (and of course partitioning if tests are run with pytest-xdist). At present, that mostly affects the other test in test_entrypoints.py, so we might be OK just based on pytest's default ordering of tests, but I don't know that we want to rely on that. Also, there's no guarantee that the monkey-patching wouldn't affect any of numcodecs dependencies in unexpected ways.
If you think those cases aren't worth worrying about, though, then I can revert the multiprocessing change.

Ah missed we added tests for the backport package importlib_metadata
Ok would it be possible to move these into their own test file? Maybe test_entrypoints_backport.py or similar? We could then also have some top-level check to make sure importlib_metadata is around before testing (ideally without importing given the associated issues)

Done. The test is now in its own module and only runs if importlib_metadata is available.

Thanks Vyas! 🙏


consensus: handle out of order block arrival

Depends

[ ] #757

Problem
Right now, a a node does not check to see if he has the next block
after applying the current one. This causes him to needlessly wait if
blocks arrive out of order for any reason.
Solution
Check for the next block after applying the current one.

Closing since we've rewritten the consensus


Minimise use of default() dispatcher

Task/Issue URL: https://app.asana.com/0/488551667048375/1205529944668184/f
Description
Steps to test this PR
Feature 1

[ ]
[ ]

UI changes

Before
After

!(Upload before screenshot)
(Upload after screenshot)

Current dependencies on/for this PR:

develop

PR #3747   👈

This comment was auto-generated by Graphite.


Add helm install module onto kosmos

What would you like to be added:
Add helm charts module onto kosmos for users quick start
Why is this needed:
Helm is a popular way to install k8s components.

/cc @calvin0327  Can you help us ?


Hex.pm checksum change

Precheck

Do not use the issues tracker for help or support requests (try Elixir Forum, Stack Overflow, IRC or mailing lists, etc).
For proposing a new feature, please start a discussion on elixir-ecto.
For bugs, do a quick search and make sure the bug has not yet been reported.
Finally, be nice and have fun!

Environment

Elixir version (elixir -v):

Erlang/OTP 22 [erts-10.5.6] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [hipe]

Elixir 1.10.1 (compiled with Erlang/OTP 21)

Database and version (PostgreSQL 9.4, MongoDB 3.2, etc.):

postgres (PostgreSQL) 9.6.17

Ecto version (mix deps):

3.4.3

Database adapter and version (mix deps):

Ecto.Adapters.Postgres

Operating system:

OSX catalina 10.15.2 (19C57)

Current behavior
We installed ecto 3.4.3 just yesterday. At that time ecto 3.4.3 had a checksum of 60920bb20dcb9b1fd9e3d3e073fd8c1bf17012cae11d57ad9b460d1c149b08b5.
The last time I ran mix deps.get it had a checksum of
9b6f18dea95f2004d0369f6a8346513ca3f706614f4ede219a5f3fe5db5dd962
Heres the mix lock diff
-  "ecto": {:hex, :ecto, "3.4.3", "97aa870ad58503818db7f2af61c62b25a001454f73b4e768fb7a66f588858067", [:mix], [{:decimal, "~> 1.6 or ~> 2.0", [hex: :decimal, repo: "hexpm", optional: false]}, {:jason, "~> 1.0", [hex: :jason, repo: "hexpm", optional: true]}, {:telemetry, "~> 0.4", [hex: :telemetry, repo: "hexpm", optional: false]}], "hexpm", "60920bb20dcb9b1fd9e3d3e073fd8c1bf17012cae11d57ad9b460d1c149b08b5"},
+  "ecto": {:hex, :ecto, "3.4.3", "3a14c2500c3964165245a4f24a463e080762f7ccd0c632c763ea589f75ca205f", [:mix], [{:decimal, "~> 1.6 or ~> 2.0", [hex: :decimal, repo: "hexpm", optional: false]}, {:jason, "~> 1.0", [hex: :jason, repo: "hexpm", optional: true]}, {:telemetry, "~> 0.4", [hex: :telemetry, repo: "hexpm", optional: false]}], "hexpm", "9b6f18dea95f2004d0369f6a8346513ca3f706614f4ede219a5f3fe5db5dd962"},

This raises alarms for a possible security issue.
Expected behavior
I'd expect the checksum to be the same for the same release version.
This is probably fine but I just wanted to double check that no ones published a dodgy release like like https://github.com/rest-client/rest-client/issues/713

Thanks for checking in. Hex.pm allows republishing the package within the 1st hour, we'd sometimes do that when we e.g. forgot to include something in the release. I'm sure everything is fine but I'll let @josevalim confirm since he did the release :)

When I change ecto to version 3.4.3 in my mix.exs and try to update it I get the following;
❯ mix deps.update ecto
** (Mix) No matching version for ecto ~> 3.4.3 (from: mix.exs) in registry

The latest version is: 3.4.2

novistore on  master [!] is 📦 v0.1.0 via 🔮 1.10.3 (OTP 22) took 2s
❯ mix hex.config
api_key: nil (default)
api_url: "https://hex.pm/api" (default)
cacerts_path: nil (default)
diff_command: "git diff --no-index __PATH1__ __PATH2__" (default)
home: "/Users/henricus/.hex" (default)
http_concurrency: 8 (default)
http_proxy: nil (default)
http_timeout: nil (default)
https_proxy: nil (default)
mirror_url: nil (default)
no_verify_repo_origin: false (default)
offline: false (default)
repos_key: nil (default)
resolve_verbose: false (default)
unsafe_https: false (default)
unsafe_registry: false (default)

novistore on  master [!] is 📦 v0.1.0 via 🔮 1.10.3 (OTP 22)
❯ mix hex.info ecto
A toolkit for data mapping and language integrated query for Elixir

Config: {:ecto, "~> 3.4"}
Releases: 3.4.3, 3.4.2, 3.4.1, 3.4.0, 3.3.4, 3.3.3, 3.3.2, 3.3.1, ...

Licenses: Apache-2.0
Links:
  GitHub: https://github.com/elixir-ecto/ecto

@hl this is really unexpected, you're not behind a proxy or a hex mirror, are you? Could you rm ~/.hex/cache.ets and try again?

❯ rm ~/.hex/cache.ets
remove /Users/henricus/.hex/cache.ets? y

novistore on  master [!] is 📦 v0.1.0 via 🔮 1.10.3 (OTP 22)
❯ mix deps.update ecto
** (Mix) No matching version for ecto ~> 3.4.3 (from: mix.exs) in registry

The latest version is: 3.4.2

novistore on  master [!] is 📦 v0.1.0 via 🔮 1.10.3 (OTP 22)
❯ mix hex.info ecto
A toolkit for data mapping and language integrated query for Elixir

Config: {:ecto, "~> 3.4"}
Releases: 3.4.3, 3.4.2, 3.4.1, 3.4.0, 3.3.4, 3.3.3, 3.3.2, 3.3.1, ...

Licenses: Apache-2.0
Links:
  GitHub: https://github.com/elixir-ecto/ecto

novistore on  master [!] is 📦 v0.1.0 via 🔮 1.10.3 (OTP 22)
❯ mix deps.get
** (Mix) No matching version for ecto ~> 3.4.3 (from: mix.exs) in registry

The latest version is: 3.4.2

Could you paste the entry you have for ecto from mix deps?

Like this?
novistore on  master [!] is 📦 v0.1.0 via 🔮 1.10.3 (OTP 22)
❯ mix deps G ecto
* ecto (Hex package) (mix)
  locked at 3.4.2 (ecto) b3959b8a
* ecto_sql (Hex package) (mix)
  locked at 3.4.2 (ecto_sql) f2b06410
* phoenix_ecto (Hex package) (mix)
  locked at 4.1.0 (phoenix_ecto) c5e666a3

Yes.
I cannot reproduce this locally. What's your Hex version? Are you using the latest one?

I think so
novistore on  master [!] is 📦 v0.1.0 via 🔮 1.10.3 (OTP 22)
❯ mix hex.info
Hex:    0.20.5
Elixir: 1.10.3
OTP:    22.3.2

Built with: Elixir 1.10.0 and OTP 21.3

@wojtekmach you can take a look if you like
ssh<EMAIL_ADDRESS>

What happens if you create a new mix project, add {:ecto, "~> 3.4.3"} and run mix deps.get, does that work?

@ericmj fyi: I was seeing checksum mismatch (inner) when doing: mix hex.package fetch ecto 3.4.3 on @hl machine. I purged /tarballs/ecto-3.4.3.tar and /packages/ecto, and that fixed it for him. Perhaps there's a bug when overwriting the release, I'll look into it later.

spoken with @josevalim, he overwrote the release within the 1h window. Closing.

We can also see from the audit log that 3.4.3 was republished: https://hex.pm/packages/ecto/audit_logs?page=1.

@ericmj does republishing purge the fastly cache automatically?

The fastly cache is purged, but any intermediate or local caching we cannot purge of course. The hex client does conditional HTTP requests to ensure we always fetch a fresh version.

@ericmj I had the same issue this morning, and I hadn't downloaded this version between the one-hour window, so I'm quite certain that it's not due to local caching here. I didn't clear it, and just now executed mix deps.get again, and it worked, but it didn't before.

@jeroenvisser101 Did you have the original issue that @damienadermann reported or the issue @hl reported?

@ericmj I've cleared my console since, but was working with @hl to reproduce and got the same output he posted, running the same commands.
mix deps.get reported The latest version is: 3.4.2 while mix hex.info ecto listed 3.4.3.


Vulkan RHI: High overhead of ICommandList::SetProgramBindings in multi-threaded rendering scenario

Describe the bug
"Asteroids" sample and "Parallel Rendering" tutorial built for Vulkan API has significantly lower FPS than for DirectX API in multi-threaded rendering scenario.
Steps To Reproduce
Steps to reproduce the behavior:

Run "Parallel Rendering" tutorial built for DirectX, set grid size to 25 or higher => get ~400 FPS

Run "Parallel Rendering" tutorial built for Vulkan, set grid size to 25 or higher => get ~150 FPS

Run "Asteroids" sample built for DirectX, set scene complexity to 8 (35000 asteroids) => get ~294 FPS
Run "Asteroids" sample built for Vulkan, set scene complexity to 8 (35000 asteroids) => get ~77 FPS

Expected behavior
Comparable FPS is expected for DirectX and Vulkan version for the same application with equal parameters.
Desktop (please complete the following information):

OS: Windows 11
Version 23H2
HW: Intel Core i7-7820X, NVidia GeForce 2070 SUPER
Build environment Visual Studio 2022

Rootcause
Multi-threaded rendering performance became limited by std::mutex lock in Vulkan::Program::GetNativePipelineLayout called from Vulkan::ProgramBindings::Apply, as seen in Tracy:


out-of-date note about Schema-based labeling

Issue in ./help/xdm/tutorials/labels.md
This page has a note that reads:

IMPORTANT
Schema-based labeling is part of attribute-based access control, which is currently available in a limited release for US-based healthcare customers. This capability will be available to all Adobe Real-Time Customer Data Platform customers once it is fully released.

This feature has been fully released and is available to all Adobe Real-Time Customer Data Platform customers in all regions.  Please remove this note wherever it appears

Thank you for submitting this issue. We will review the documentation and make the necessary updates as quickly as possible. Tracking internally in PLAT-207408.

We've reviewed the documentation and updated it to reflect the availability. Closing this issue.


Use proxy defined in git

When I am at work I am behind a proxy and cannot call sync on my repo. Making fw use the proxy that is defined in git would solve this issue. I created PR for this issue here

#92


[SPARK-31010][SQL][ML][FOLLOW-UP] Throw exception when use untyped UDF by default

What changes were proposed in this pull request?

This PR proposes to throw exception by default when user use untyped UDF(a.k.a org.apache.spark.sql.functions.udf(AnyRef, DataType)).
And user could still use it by setting spark.sql.legacy.useUnTypedUdf.enabled to true.
Why are the changes needed?

According to #23498, since Spark 3.0, the untyped UDF will return the default value of the Java type if the input value is null. For example, val f = udf((x: Int) => x, IntegerType), f($"x") will  return 0 in Spark 3.0 but null in Spark 2.4. And the behavior change is introduced due to Spark3.0 is built with Scala 2.12 by default.
As a result, this might change data silently and may cause correctness issue if user still expect null in some cases. Thus, we'd better to encourage user to use typed UDF to avoid this problem.
Does this PR introduce any user-facing change?

Yeah. User will hit exception now when use untyped UDF.
How was this patch tested?

Added test and updated some tests.

Test build #118024 has started for PR 27488 at commit 809703e.

ping @cloud-fan @mengxr @WeichenXu123 please help review.

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-K8s/22789/
Test PASSed.

Test build #118024 has finished for PR 27488 at commit 809703e.

This patch fails MiMa tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Test build #118028 has started for PR 27488 at commit 23e52ea.

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-K8s/22793/
Test PASSed.

Test build #118028 has finished for PR 27488 at commit 23e52ea.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Test build #118127 has started for PR 27488 at commit 93bf652.

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-K8s/22892/
Test PASSed.

Test build #118127 has finished for PR 27488 at commit 93bf652.

This patch fails build dependency tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

retest this please

Test build #118136 has started for PR 27488 at commit 93bf652.

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-K8s/22900/
Test PASSed.

Test build #118136 has finished for PR 27488 at commit 93bf652.

This patch fails build dependency tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Jenkins, retest this please.

Test build #118145 has started for PR 27488 at commit 93bf652.

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-K8s/22907/
Test PASSed.

Test build #118145 has finished for PR 27488 at commit 93bf652.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

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/118145/
Test PASSed.

Test build #118198 has started for PR 27488 at commit 549cdf4.

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-K8s/22960/
Test PASSed.

Test build #118198 has finished for PR 27488 at commit 549cdf4.

This patch fails build dependency tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Jenkins, retest this please.

Test build #118212 has started for PR 27488 at commit 549cdf4.

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-K8s/22972/
Test PASSed.

Test build #118212 has finished for PR 27488 at commit 549cdf4.

This patch fails build dependency tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Jenkins, retest this please.

Test build #118216 has started for PR 27488 at commit 549cdf4.

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-K8s/22976/
Test PASSed.

Test build #118216 has finished for PR 27488 at commit 549cdf4.

This patch fails build dependency tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Test build #118227 has started for PR 27488 at commit 3297976.

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-K8s/22987/
Test PASSed.

Test build #118227 has finished for PR 27488 at commit 3297976.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Test build #118243 has started for PR 27488 at commit 6969596.

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-K8s/23003/
Test PASSed.

Test build #118243 has finished for PR 27488 at commit 6969596.

This patch fails build dependency tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Jenkins, retest this please.

Test build #118246 has started for PR 27488 at commit 6969596.

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-K8s/23005/
Test PASSed.

Test build #118246 has finished for PR 27488 at commit 6969596.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

retest this please.

Test build #118280 has started for PR 27488 at commit 6969596.

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-K8s/23039/
Test PASSed.

Test build #118280 has finished for PR 27488 at commit 6969596.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

retest this please.

Test build #118287 has started for PR 27488 at commit 6969596.

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-K8s/23045/
Test PASSed.

Test build #118287 has finished for PR 27488 at commit 6969596.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

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/118287/
Test PASSed.

Kindly ping @cloud-fan @mengxr @WeichenXu123

LGTM. Also ping @srowen @zhengruifeng Could you help double check ?

Test build #118708 has started for PR 27488 at commit 0d1601b.

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-K8s/23459/
Test PASSed.

Test build #118717 has finished for PR 27488 at commit 0d1601b.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

retest this please

Test build #118721 has started for PR 27488 at commit 0d1601b.

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-K8s/23472/
Test PASSed.

Test build #118721 has finished for PR 27488 at commit 0d1601b.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

retest this please

Test build #118727 has started for PR 27488 at commit 0d1601b.

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-K8s/23478/
Test PASSed.

Test build #118727 has finished for PR 27488 at commit 0d1601b.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

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/118727/
Test PASSed.

thanks, merging to master/3.0!

thanks all!

We were using spark 3.3 and able to resolve this issue by setting the property (spark.sql.legacy.allowUntypedScalaUDF=true) when running the spark job
gcloud dataproc jobs submit spark \
--cluster eu-mbnl-mbnl-uat-pipe-transform-v2 \
--region europe-north1 \
**--properties=spark.sql.legacy.allowUntypedScalaUDF=true** \
--class com.pythian.edp.pm.spark.job.MbnlRawPmProcessingSparkJob \
--jars gs://1138473b246ed9c7-eu-mbnl-mbnl-uat-data-edl-static/spark-jobs/mbnlSparkPmCmProcessing/mbnlSparkPmCmProcessing-assembly-0.1.0-SNAPSHOT_adhoc.jar \
-- --configurationURI gs://1138473b246ed9c7-eu-mbnl-mbnl-uat-data-edl-static/spark-job-configs/329abd38-ea1a-4d30-8106-ab65ff9fccb4-PM-3G-nokia_m3ua_association_set/ing-n-a-rnc-1727153888.yml \
--pubSubProjectId bmas-eu-mbnl-mbnl-uat-pipe \
--pubSubTopicName data-notifications \
--sendPubSubNotification \
--traceDatasets > mbnl_mbnl_uat_ingestion_log 2>&1

Now we have been migrated to spark 3.5 and started getting this error again
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: org.apache.spark.sql.AnalysisException: [UNTYPED_SCALA_UDF] You're using untyped Scala UDF, which does not have the input type information. Spark may blindly pass null to the Scala closure with primitive-type argument, and the closure will see the default value of the Java type for the null argument, e.g. `udf((x: Int) => x, IntegerType)`, the result is 0 for null input. To get rid of this error, you could:
1. use typed Scala UDF APIs(without return type parameter), e.g. `udf((x: Int) => x)`.
2. use Java UDF APIs, e.g. `udf(new UDF1[String, Integer] { override def call(s: String): Integer = s.length() }, IntegerType)`, if input types are all non primitive.
3. set "spark.sql.legacy.allowUntypedScalaUDF" to "true" and use this API with caution.


SQL parsed incorrectly when statements concatenated

Azure Data Studio Version: 1.18.1

Steps to Reproduce:

The following SQL executes correctly, but seems like it should be an error.  100SELECT should be an invalid identifier, I think.

SELECT 100SELECT TOP (1000) [StateProvinceID]
      ,[StateProvinceCode]
      ,[CountryRegionCode]
      ,[IsOnlyStateProvinceFlag]
      ,[Name]
      ,[TerritoryID]
      ,[rowguid]
      ,[ModifiedDate]
  FROM [AdventureWorks2017].[Person].[StateProvince]

Same SQL works in SSMS so I'll close this as "won't fix"


[BEAM-2550] add UnitTest for JOIN in DSL

@XuMingmin @takidau
I have only tested bounded vs bounded join scenario, since we already have enumerated every cases like bounded vs bounded, unbounded vs unbounded in tests for BeamJoinRel, test here is mainly to test the integration of JOIN with the DSL methods.
Also I kinda fixed a related bug in BeamIOSourceRel -- which have not setCoder for the rows.

Changes Unknown when pulling d6104cc59c410eab2a0dd89dd825410fe2f0d95a on xumingming:BEAM-2550-test-join-in-dsl into ** on apache:DSL_SQL**.

@takidau can you take a peak here and merge it if good to go?

LGTM, merging.

Merged, feel free to close.


Develop/document process map for existing process for PAYMENT

Assuming CFOB does not already have this documented

Done and on the GCDevEx sharepoint site. Is a single document for the existing process for procurement (sole source) and payment by direct deposit.


Fixed vscode unit test settings

What does this PR do?
Some settings were missing to properly setup the tests

Motivation

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge


Remove version: FlorianHoech.DisplayCAL version <IP_ADDRESS>

[Automated] It returns code over 400 in all urls
Microsoft Reviewers: Open in CodeFlow

URL: https://sourceforge.net/projects/dispcalgui/files/release/<IP_ADDRESS>/DisplayCAL-<IP_ADDRESS>-Setup.exe/download
OK
(Automated message - build 923)

Close with reason: Package still available.;


Opaque Data structs for FFI

This RFC is an offshoot of (and hopes to supersede) #1861 as mentioned in this comment.
This is a rewrite of the original RFC with a focus on the simpler syntactically Opaque unsized struct, and tries to serve as a document exploring both the motivation for implementing this feature in rust today, as well as the different approaches for handling the size_of_val and type_of_val features.
I made the decision to focus the core text of the RFC on the DynSized approach to the size_of_val and type_of_val problem, as it is the solution to the problem which causes the largest change to the language, and needs the most exploration. The other solutions are mentioned in the Alternatives section, and are simpler in concept and implementation, so need less text discussing them. However, I have tried to keep the pieces of the RFC which discuss this separated, so that it is easy to tell which parts of the RFC are related to the DynSized trait, and which are related to the Opaque struct.
rendered

Reading the RFC makes me think, could impl !Sized for Opaque {} be an alternative to a lang-item + DynSized? It seems not because:

size_of_val would still work on T: !Sized unless the compiler special-case it for slices and traits
There is no guarantee that impl !Sized would still ensure &Opaque is thin
Supporting impl !Sized is more work than a special lang item
The general semantic is unclear

The syntax Trait + ?DynSized could also be written which would relax this DynSized requirement, and not include the vtable entries for size_of_val and align_of_val

What does it mean to create a trait object of an opaque type?

Perhaps NonOpaque or Transparent would be a better name than DynSized.
Strictly speaking, we cannot say that the type can be figured out at runtime, right?

What about using libc::c_void?

Also, I generally don't know how I feel about this... it is definitely an important problem, and I like this solution's concept, but it seems to touch rather a lot of stuff across the language. That makes me nervous. I feel like there are possibly a lot of places where bounds would change and unexpected behavior might happen, like the point that @kennytm makes here.

What does it mean to create a trait object of an opaque type?

A reference to a trait, or a trait object &Trait is represented something like this:
// A trait like `Trait` with a method:
trait Trait {
    fn method(&self);
}

// Is represented something like this (I haven't actually looked
// into Rust's exact VTable layout, so this might be wrong...)
struct TraitVTable {
    size: usize,
    align: usize,
    methods: TraitVTableMethods,
}

struct TraitVTableMethods {
    method: fn(this_ptr: *const u8),
}

struct &Trait {
    data: *const u8,
    vtable: *const TraitVTable,
}

If you have an opaque type:
struct Mine(Opaque);

impl Trait for Mine {
    fn method(&self) { println!("Hello!"); }
}

Would then be cast to a trait object by taking the pointer to the Mine object and putting it in the data slot, and taking a pointer to the vtable and putting it in the vtable slot. A trait object which references an Opaque object would be written as &Trait + ?DynSized and would look something like:
struct &Trait + ?DynSized {
    data: *const u8,
    vtable: *const TraitVTableMethods,
}

That way it doesn't need a size and align field in its VTable.

Perhaps NonOpaque or Transparent would be a better name than DynSized.
Strictly speaking, we cannot say that the type can be figured out at runtime, right?

We do know the type, and if we have a trait object of the opaque type it can be figured out at runtime, we just cannot know the layout of the type. That's what Opaque means (just like forward-declared types in C/C++).

What about using libc::c_void?

That type is not safe to put behind a & or &mut pointer as it is represented as struct c_void(u8). I cover that possibility in the Motivations section.
If we do land this type, it would be awesome to change the definition of libc::c_void to use an Opaque definition, but that would be a backwards-incompatible change so we would need a major version bump of libc, which would be unfortunate.

Also, I generally don't know how I feel about this... it is definitely an important problem, and I like this solution's concept, but it seems to touch rather a lot of stuff across the language. That makes me nervous. I feel like there are possibly a lot of places where bounds would change and unexpected behavior might happen, like the point that @kennytm makes here.

I agree that this is an unfortunately large change to the language, which is why I try to also mention the other, much smaller, options which don't involve introducing the DynSized trait.
This was designed such that no bounds would change without them being explicitly annotated, so no unexpected behavior should happen. If some behavior would change anywhere, that's a bug in the RFC's design. This RFC should be 100% backwards-compatible.
The main reason why DynSized was used in the main body of the RFC is because it needs the most explanation, as it is the most complex option, and I didn't want to elaborate on all of this in the Alternatives section. It also needs the most exploration of its impacts on the rest of the language.

Reading the RFC makes me think, could impl !Sized for Opaque {} be an alternative to a lang-item + DynSized?

Nope, I think we would need both impl !Sized and DynSized. impl !Sized could be used as a replacement for lang-item. The other option with impl !Sized would be to make it so each implementation has to choose its own size_of_val and align_of_val, and people writing individual bindings would have to write specific code for each type that they wrap which calculates the correct values.

@mystor Well RFC #19 will need to be heavily modified to allow actual implementation in an impl !Sized. I guess a lang-item is good enough 😆.
// wat.
impl !Sized for CStr {
    fn size_of_val(&self) -> usize { strlen(...) + 1 }
}

@kennytm I do mention how this would be implemented under this RFC - It would be done by writing impl DynSized for CStr.

@mystor
Ah, got it. So self in these methods would then only be usable for calling other methods? Since that data is opaque, what is the point of that? Why not just write a function?

Strictly speaking, we cannot say that the type can be figured out at runtime, right?

Sorry, this is a typo. It should say "we cannot say that the size can be figured out at runtime"... that's why I proposed a name that does not include the word "sized".

That type is not safe to put behind a & or &mut pointer as it is represented as struct c_void(u8). I cover that possibility in the Motivations section.
If we do land this type, it would be awesome to change the definition of libc::c_void to use an Opaque definition, but that would be a backwards-incompatible change so we would need a major version bump of libc, which would be unfortunate.

Got it :+1:

It also needs the most exploration of its impacts on the rest of the language.

Mostly, I am thinking of weird corner cases that might impact soundness or something... like what is the interaction with ! or PhantomData or closures or lifetimes? For example,

Is Fn() -> impl Opaque not opaque? What about an FnMut() -> () closure that contains an Opaque (e.g. through capturing)?
Is PhantomData<(!, T)> where T: Opaque a ZST or an Opaque? or does it matter? can this cause weirdness with dropck?

Part of me wonders if there is a more formal way to define Opaqueness in the type system. i.e. is there any type theory exploring this issue which might show us where bugs might show up? (btw, I don't know that much about type theory, so I might be totally wrong).
Also, I do want to underscore that I like the RFC in general... I just have vague uneasiness, too...

@mark-i-m
So the first thing I want to point out is that Opaque is not a Trait, rather
it is a concrete type like [u8] or str, which is unsized. You wrote <T: Opaque> in your comment, which is not legal syntax, and would be like writing
<T: [u8]>.
Just like in rust today, you cannot have a value of type Opaque in the same
way you cannot have a value of type [u8], you can only hold a value of these
types behind a reference, like &Opaque or &[u8].
Another value is "made opaque" by including a field of an "opaque" data type as
its last member, for example, the CStr data type would be "made opaque" by
defining it with a single Opaque field.

Ah, got it. So self in these methods would then only be usable for calling other methods? Since that data is opaque, what is the point of that? Why not just write a function?

You would not be able to implement a trait which requires passing around self
by value on an opaque type, just like how you cannot implement it on [u8].
However, just like [u8], you would be able to implement traits which only
require passing around values of the type by reference. For example, struct CStr(Opaque) would be able to implement the trait Deref<Target=[u8]>, as:
struct CStr(Opaque);

impl Deref for CStr {
    type Target = [u8];
    fn deref(&self) -> &[u8] {
        unsafe {
            slice::from_raw_parts(self as *const _ as *const u8, self.len())
        }
    }
}

The reason why I want to support implementing inherit methods and traits on
opaque objects is for consistency with the rest of the types in the language. We
should treat these types the same way as other unsized types as much as
possible. There is no reason to require you to write:
let x: &CStr = ...;
cstr_len(x);
// -- instead of --
x.len();

Sorry, this is a typo. It should say "we cannot say that the size can be figured out at runtime"... that's why I proposed a name that does not include the word "sized".

Values which are Opaque do not implement either Sized or DynSized, which
is what makes them unique. It would be possible with the full extensions of this
RFC to unsafely implement DynSized on one of these values, which would allow
defining methods which calculate size.

Mostly, I am thinking of weird corner cases that might impact soundness or something... like what is the interaction with ! or PhantomData or closures or lifetimes? For example,

Is Fn() -> impl Opaque not opaque? What about an FnMut() -> () closure that contains an Opaque (e.g. through capturing)?

You cannot write this expression, as Opaque is not a trait. In addition, it is
not possible to capture a value of type Opaque in a closure, as you cannot
have a value, you can only capture references to a value containing Opaque.

Is PhantomData<(!, T)> where T: Opaque a ZST or an Opaque? or does it matter? can this cause weirdness with dropck?

It would be a ZST, just like PhantomData<(!, [u8])>. It would have the same
implications as raw slices do on dropck today.

Part of me wonders if there is a more formal way to define Opaqueness in the type system. i.e. is there any type theory exploring this issue which might show us where bugs might show up? (btw, I don't know that much about type theory, so I might be totally wrong).

This is what we're doing here. We're defining Opaqueness as being !Sized and
!DynSized, and thus having no way of defining what the layout or alignment of
the data behind the reference is, nor ability to gain a value of this type.

Also, I do want to underscore that I like the RFC in general... I just have vague uneasiness, too...

My main comfort with this RFC is that it is very similar to code which we
already have today, namely it is very similar to our existing !Sized types
like [u8] and str. Most of the problems which might come up with adding such
a feature to the type system have already been worked out for those types, with
the small exception of the size_of_val and align_of_val methods which are
dealt with in this RFC.
IMO the main risk here doesn't really come from its interactions with the type system, so
much as the problem of someone implementing it, and how to handle the
size_of_val and align_of_val options. The biggest problem with the RFC as
written is that it adds a new magical built-in trait, like ?Sized, to handle
size_of_val and align_of_val. This is definitely possible and correct, but
may be a change which we don't want to make to the language due to its scale.

surprised to find that there is no definition of semantic of the DynSized in this rfc

@liigo what do you think is missing? There is an entire section of the rfc dedicated to describing the dynsized trait, and I tried my best to be thorough.

@mystor Maybe there lacks a summary line of docs of DynSized.

Given that the original extern type RFC is in FCP, I'm going to close this one out for the time being. We can re-open later if needed.
Thanks, @mystor, for whipping this up!


Convert to Quarto

Now that the R Dev Guide has been converted to Quarto, I propose we do the same for the R Contributor site.
Advantages (all of which come out the box with Quarto):

search
dark mode
a more modern appearance

Also, I suspect that Quarto is better known/understood in the R contributor community than Jekyll, so it could make it easier for others to contribute. It will make previewing locally easier as well.
Since most of the site is written in .md files, the conversation should be as straightforward as replacing _config.yml with a _quarto.yml, then publishing through a gh-pages branch with a GHA. (I'm not sure how the publishing currently works - presumably some combo of the Gemfile and CNAME).
I'm happy to do this and submit a pull request if there's interest.
Also, I'd like to propose that we take this as an opportunity to to develop a brand for R Contributors that can be applied through a brand.yml file - I'll raise a separate issue about that.

Good idea!


2lc

Pleas check, 2lc for 10.14 , and sai mi how work this kext on 10.14 . https://github.com/alexandred/VoodooI2C/releases

@seftandshelby Hi, thanks for information. It's a I2C. But the version 2.1.1 is not working better than 2.0.1 in this GitHub, and I am not going to update.
If you want tot try it on 10.14, I edited the source code to let it work on 10.14. For more information, you can visit my reply in https://github.com/alexandred/VoodooI2C/issues/70.


hyde requesting specific version of jinja2

end of last year / beginning of this year, I have built a website with hyde.
Now on a new machine, I tried to regenerte the site with "hyde gen -r", getting the following tracebak:
Traceback (most recent call last):
File "/usr/lib/python-exec/python2.7/hyde", line 5, in
from pkg_resources import load_entry_point
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2720, in <modu
le>
parse_requirements(requires), Environment()
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 588, in resolv
e
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: Jinja2==2.7.1
I have jinja2 v2.7.3 installed, via portage on gentoo v2.7.1 not available anymore.
To avoid installing older versions manually and possibly interfering with the package system, it would be nice to have a new release of hyde that can cope with newer versions of jinja2. Thanks a lot!
for my curiosity: where is this version requirement specified???
Kind regards,
Didier

I have the same issue. @dcolle have you found a fix?

You could use a virtualenv to isolate the website and its dependencies.
Versions are likely specified in the setup.py and/or a requirements.txt

@boghison @dcolle the issue should be fixed now using the master branch of the repository.
Thanks a lot for your help!


Add support for pumps

I would like to add support for pumps. I believe I will start with having the pumps ON or OFF.

done


[FEATURE] Maybe the clock can be larger

The current clock is on the screen. Maybe the clock can be larger, or the oversized flip clock will be better.

+1 please

I would love to have a flip clock option similar to the one the Lenovo Smart Clock 2 has (which is what I'm running this on), or at least have the text larger.
I'd also love a way to disable the clock movement completely, as this is annoying to me

I've modified this myself, and have enlarged the clock text size as well as disable the random movements. I don't think it's ready for a PR here, but you can try it out yourself:
https://github.com/CobreDev/wallpanel-android/releases/


bug: Prevent wiping down output file on error.

In case of error, sometimes genny left over an empty file to which it was suppose to be writing the generating code. This causes some problems when running go generate again. One has remove all such files to be able to re-run go-generate. Resolves https://github.com/cheekybits/genny/issues/23

@matryer Do you think maybe you will have time to review this sometime?


DRILL-7774: IS NOT NULL predicate fails with NPE for the case of non-existing columns with non-deterministic expression

DRILL-7774: IS NOT NULL predicate fails with NPE for the case of non-existing columns with non-deterministic expression
Description
Added null check.
Documentation
NA
Testing
Added unit test for the issue.

@KazydubB, could you please take a look?


Kubernetes 1.5.x plan ?

Any Plans to update to the latest Version of the Kube ?

Master is now tracking 1.6


[AzureMonitorDistro] Update AzureEventSourceLogForwarder defaults to warning

The Application Insights .NET SDK captures warning logs by default, and we are aligning with this behavior.

API change check
API changes are not detected in this pull request.


Use uWebSocket

@sairus2k note, that you still have problem in Travis CI

The problem doesn't reproduce locally.
On Apr 28, 2017 11:21 PM, "Andrey Sitnik"<EMAIL_ADDRESS>wrote:

@sairus2k https://github.com/sairus2k note, that you still have problem
in Travis CI
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/logux/logux-server/pull/31#issuecomment-298042364,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDjx0j3_t_wqvF0L0XRV49UxFjb4hYjks5r0hHFgaJpZM4NLd7m
.

OK, I will try to look on my machine. Maybe it is related to concurrency. Or to yarn lock?

@ai Probably, localhost on Travic-CI resolves to ipv6 address
This is the issue:
https://github.com/uWebSockets/uWebSockets/issues/342
Then it fails only for node version 6.10.2 with another error. I restarted build using close and reopen pull request and all tests passed.

Great invastigation. Sorry, I stock on Autoprefixer 7 release :(

Thanks. Whatis your Twitter and VK accounts for announce?

https://vk.com/sairus2k


Revise one word in ISSUE_TEMPLATE.md

Coverage decreased (-0.1%) to 62.314% when pulling 326d4ec73c5b721d457907b2d5c49eb3f48526ae on gangliao-patch-2 into e05f4ff26700dd34aa6d3c6da7061c62c5fa39c9 on develop.


Figma to Pynecone plugin

Are there any plans to convert Figma designs to Pynecone FE apps?

We do have plans for this in the future but have been focusing on improving the core of the library because we have limited bandwidth at the moment

Makes sense. Is there a way to convert from ReactJS code to Pynecone source code directly? There are currently some plugins (such as Quest) that convert Figma designs to React code. We could leverage that, and build on top of it to convert React code to Python Pynecone source files.

https://reflex.dev/docs/components/html-to-reflex/


[Python] Change expected values in test_strings and test_category

I noticed a test failure while looking at contributing on #235 (Deprecations in pandas 0.19 means moving to the public API ).

In test_strings, this is not blocking but more reflective of what is written to disk
In test_category, this test erratically fails on Python 2.7

I isolated the 2.7 python section in the travis file to highlight the test failure:
https://travis-ci.org/guillett/feather/builds/166061964
Then I updated the tests to pass the tests
https://travis-ci.org/guillett/feather/builds/166066370
Rationale for updating test_strings:
I run the following snippet:
import pandas as pd
values = ['foo', None, u'bar', 'qux', None]

def dtype(v):
	try:
		return pd.lib.infer_dtype(v)
	except TypeError as e:
		return '##ERROR'

print(values)
print([dtype(v) for v in values])
print('')
import feather
path = 'strings.feather'
feather.write_dataframe(pd.DataFrame({'strings': values}),path)
df = feather.read_dataframe(path)
print(df.strings.values)
print([dtype(v) for v in df.strings.values])

Python 2.7:
['foo', None, u'bar', 'qux', None]
['string', '##ERROR', 'unicode', 'string', '##ERROR']

['foo' None 'bar' 'qux' None]
['string', '##ERROR', 'string', 'string', '##ERROR']

Python 3.5
['foo', None, 'bar', 'qux', None]
['string', '##ERROR', 'string', 'string', '##ERROR']

['foo' None 'bar' 'qux' None]
['string', '##ERROR', 'string', 'string', '##ERROR']

The Unicode item is directly converted to string by Python 3.5 and the type of the data loaded from disk is string for both Python versions.

Current coverage is 80.31% (diff: 100%)

Merging #238 into master will increase coverage by 0.04%

@@             master       #238   diff @@
==========================================
  Files            12         12
  Lines           892        894     +2
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            716        718     +2
  Misses          176        176
  Partials          0          0

Powered by Codecov. Last update 6b5a27c...aef5838

The behavior described above is problematic only for python 2.7 and pandas 0.19.0 (as per indicated by @evolvedmicrobe in #237.
The current master fails for python 2.7 and pandas 0.19.0 (cf. https://travis-ci.org/guillett/feather/builds/166356260)
I added travis builds here (fixing pandas to 0.18.0 to get the full picture) as advised by @jreback in #239).

this was superceded by #242


How to show an image or play video from iPhone to Sony TV

I'm researching a way to cast image or video to Sony TV. I can discover the device with this lib. But I don't know how to show image and video from my iPhone to TV.
UPNP api a bit complicated. Please help and demo code to do that.
I guess first we upload file to GCDWebServer. And then use AVTransport to display it to TV.

https://www.youtube.com/watch?v=COw56J-qs7w&t=31s


Feature required in #73

I took some time to implement the feature mentioned in https://github.com/shekhargulati/strman-java/issues/73

Codecov Report

Merging #77 into master will increase coverage by <.01%.
The diff coverage is 85.71%.

@@             Coverage Diff              @@
##             master      #77      +/-   ##
============================================
+ Coverage     99.03%   99.03%   +<.01%
- Complexity      139      144       +5
============================================
  Files             3        3
  Lines          4154     4160       +6
  Branches         50       50
============================================
+ Hits           4114     4120       +6
  Misses           23       23
  Partials         17       17

Impacted Files
Coverage Δ
Complexity Δ

src/main/java/strman/Strman.java
88.01% <85.71%> (+0.23%)
142 <9> (+5)
:arrow_up:

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 605eb4f...57b2c05. Read the comment docs.


samples/plugins/gke: adds integration tests

This CL adds an integration test for the GKE's plugin push command.

One comment about Windows support, otherwise LGTM.


Using maftools on germline data

Firstly many thanks for maftools, it's really awesome!
I am interested in plotting a lolliplop plot and your package makes really nice looking ones. I have germline SNV data and am trying to input it as a "maf" file, it is just a tab separated tsv file with the minimum headers as described on your bio conductor vignette, but it doesn't seem to read in. An example of the file I have created is below:

Hugo_Symbol	Chromosome	Start_Position	End_Position	Reference_Allele	Tumor_Seq_Allele2	Variant_Classification	Variant_Type	Tumour_Sample_Barcode
CNCL	chr10	1586138	1586138	G	A	stop_gained	SNP	1
CNCL	chr10	1602439	1602442	CAG	C	frameshift_variant	DEL2
CNCL	chr10	1523884	1523884	G	A	stop_gained	SNP	3
CNCL	chr10	1592548	1592548	C	T	missense_variant	SNP	4

When I try to read this in I get:

> laml.maf = system.file('extdata', 'CNCL_cases.maf.csv', package = 'maftools')
> laml = read.maf(maf = laml.maf)

Reading Error in data.table::fread(input = maf, sep = "\t", stringsAsFactors = FALSE,  :    Input is empty or only contains BOM or terminal control characters
--

Not sure what I am doing here, I assume the input file is the problem?
Many thanks

Hi,
You dont have to run the below line. It is only to access the example file included in the package.
> laml.maf = system.file('extdata', 'CNCL_cases.maf.csv', package = 'maftools')

In your case, it should just be the path to your maf file.
> laml.maf = "CNCL_cases.maf.csv"
> laml = read.maf(maf = laml.maf)

Many thanks it worked well!