Setting form field validator error text manually keeping animation

Hi everyone,
I'm building a form in which I validate the inputs with an API call and therefore can't use the built-in validator function to set the error under the field.
I am aware that the error can be set manually via the errorText attribute but doing so get rid of the nice animation provided by the widget.
Is there a way to set the validator animation manually while keeping the animation?
Thanks!

We're closing this issue because it seems to be a question or request for help rather than a clearly reproducible bug, regression or new feature request.
Good places to ask questions or work through problems where you're more likely to get a fast response include:

Stack Overflow
Gitter
Flutter Community Slack

Thanks for using Flutter!


How to defined width and height value

Hi,
I'm trying to set width and height properties on  component like this :

In the result I only have the alt/class/src properties in the code :

How can I have this

Thanks

Hey @NicolasLoisirsEncheres , please check documentation
For width: https://github.com/scaleflex/vue-cloudimage-responsive-plain#width
For Height: https://github.com/scaleflex/vue-cloudimage-responsive-plain#height

I saw the w and h in the query, but my question is "is it possible to have width and height in html attribute ?"
Because a best pratice to reduce cumulative layout shift is to have width and height html attributes in img tag
cf : https://web.dev/optimize-cls/

Hey @NicolasLoisirsEncheres, now it isn't possible , also checked the cumulative layout shift and yes we have some issues with it, will fix in next release. Thanks for pointing out this issue


Docstring fix

When deploying a new project and running make install , I encounter two errors.
Example setup command:
cookiecutter -f gh:alexandrainst/alexandra-ml-template

Example configuration from the prompt:
You've downloaded /home/bourdeet/.cookiecutters/alexandra-ml-template before. Is it okay to delete and re-download it? [yes]: yes
project_name [Project name, in snake_case]: test_project
project_description [Short description of the project]: Here is my description
author_name [Your full name]: Test
email<EMAIL_ADDRESS><EMAIL_ADDRESS>open_source [Is this a public open source project? [y/N]]: N
python_version [Your Python version, written as 3.xx]: 3.11
dependency_manager [Which dependency manager do you use? [pip/POETRY]]: pip
license_checker [Do you want to check that your dependencies are only using open source licenses? [Y/n]]: n

First error upon running make install:
Installing the 'test_project' project...
Initialized empty Git repository in /home/bourdeet/projects/RK_iot_forretningsdesign/tes/test_project/.git/
Signed with GPG key [ID GPG_KEY].
pre-commit installed at .git/hooks/pre-commit
Updated dependencies in pyproject.toml.
No .pre-commit-config.yaml file was found
- To temporarily silence this, run `PRE_COMMIT_ALLOW_NO_CONFIG=1 git ...`
- To permanently silence this, install pre-commit with the --allow-missing-config option
- To uninstall pre-commit run `pre-commit uninstall`
make[1]: *** [makefile:111: add-repo-to-git] Error 1
make: *** [makefile:36: install] Error 2

The first error can be avoided by adding a dot to the name pre-commit-config.yaml. When running make install again, I get a second error related to docstring formatting of some of the template files:
Installing the 'test_project' project...
[...]
pre-commit installed at .git/hooks/pre-commit
Updated dependencies in pyproject.toml.
black....................................................................Passed
ruff.....................................................................Failed
- hook id: ruff
- exit code: 1
- files were modified by this hook

config/__init__.py:1:1: D104 Missing docstring in public package
src/scripts/freeze_dependencies.py:12:9: D102 Missing docstring in public method
src/scripts/freeze_dependencies.py:22:9: D102 Missing docstring in public method
tests/__init__.py:1:1: D104 Missing docstring in public package
tests/test_dummy.py:4:5: D103 Missing docstring in public function
Found 7 errors (2 fixed, 5 remaining).

nbstripout...........................................(no files to check)Skipped
mypy.....................................................................Passed
make[1]: *** [makefile:111: add-repo-to-git] Error 1
make: *** [makefile:36: install] Error 2

I have added the missing docstring in the problematic file.

I am trying to check that the install runs fine, but I realized that calling:
cookiecutter -f git@github.com:alexandrainst/alexandra-ml-template

This downloads the template from the main branch. @saattrupdan  do you know if one can call a specific git branch from cookiecutter? I tried:
cookiecutter -f gh:alexandrainst/alexandra-ml-template@docstring_fix
cookiecutter -f git@github.com:alexandrainst/alexandra-ml-template@docstring_fix
cookiecutter -f gh:alexandrainst/alexandra-ml-template.git@docstring_fix
but it doesn't seem to work

I am trying to check that the new commits can run on install, but I realized that calling:
cookiecutter -f git@github.com:alexandrainst/alexandra-ml-template

This downloads the template from the main branch. @saattrupdan do you know if one can call a specific git branch from cookiecutter? I tried:
cookiecutter -f gh:alexandrainst/alexandra-ml-template@docstring_fix
cookiecutter -f git@github.com:alexandrainst/alexandra-ml-template@docstring_fix
cookiecutter -f gh:alexandrainst/alexandra-ml-template.git@docstring_fix
but it doesn't seem to work

It seems like you can specify the branch name with the --checkout argument, as described here:
$ cookiecutter -f git@github.com:alexandrainst/alexandra-ml-template --checkout docstring_fix


How to change date format?

Is it possible to change date format like day, month, year, hour, min, sec.?
it says how to change it in original repo. but I couldn't change it with your repo.
https://github.com/Bigkoo/Android-PickerView/issues/899
https://github.com/Bigkoo/Android-PickerView/issues/1009

在自定义布局中移动"年"、"月"两个控件的顺序即可 (Move the "year" and "month" controls in the order of the custom layout)

🍎这样婶儿的(Such as):

通过调整布局文件解决此需求(Solve this needs by adjusting the layout file) : https://github.com/Bigkoo/Android-PickerView/issues/899


Integration test

build csl_demo and csl_demo-debug (done) and run them in CI

there is no X11 in sandbox
the application is graphical, hard to interact with from scripts
needs blockfrost token
idea: headless x server, screenshot tests
idea: headless mode for demo app, take command line arguments
may help: https://github.com/marketplace/actions/create-a-desktop-screenshot

related: #18

fixed in #25
adding scripted integration tests with locally running plutip, cardano-node, kupo, ogmios in #35


Support for Cross Region COPY - DLM

https://aws.amazon.com/about-aws/whats-new/2019/12/amazon-data-lifecycle-manager-enables-automation-snapshot-copy-via-policies/

https://github.com/cloudtools/troposphere/blob/0607f3f5bfb75635ee9e2e5cbbaee5ab0d8d639c/troposphere/dlm.py#L62-L69
AWS::DLM::LifecyclePolicy
AWS::DLM::LifecyclePolicy.Schedule

Thanks for the issue.


split or combine turbulent fluxes?

ClimaLand recently changed their turbulent fluxes to separately store SHF and LHF. ClimaAtmos currently just provides one combined turbulent fluxes field. We should choose one of these conventions to follow and use it throughout CliMA.
Currently, to adapt between these two approaches, the bucket SHF gets updated with the combined turbulent fluxes from Atmos, and bucket LHF is zeroed out.

Could you point me to where the surface fluxes are updated? If you can, a better temporary solution would be using ρ_flux_q_tot * LH_v0 as LHF, and ρ_flux_h_tot - LHF as SHF.


Off-Canvas contentScroll inner scrollbox

I've been facing an issue with the off-canvas option contentScroll: false when using an inner box in the off-canvas with a specific height that is supposed to be scrollable.
Due to the touchmove and touchstart event listeners you can't touchmove on mobile devices within that box.
You can find an example here:
https://codepen.io/KaiTheGreat/pen/mMBZjp
Simply open the codepen on a mobile device (or use e.g. the chrome dev tools with touch emulation), click the red alert button and try to touchmove in the gray box.
This PR fixes the issue be adding additional listeners to [data-off-canvas-scrollbox] which is supposed to be assigned to the inner box.
I've extended the visual test offcanvas/nested.html to show the fix.
@kball @IamManchanda @brettsmason what do you think about this?

This looks good to me! Thanks for the pen!

I think we'd need to document this approach... that said, part of me wonders if we could fix the original handler to not need this... perhaps by checking the target in the event handler and not preventing default/propagation for inner elements?

@kball I 100% agree: we should definitely find a way without extensive usage of data-off-canvas-scrollbox!
In a current project I've added dozen of these attributes but it's still not working in all cases. Precisely I've great problems with a slider that is dynamically build and uses touch events (which are getting prevented by the off-canvas).
So a solution without that attribute is probably the best way.
As far as I see the whole touch event listeners are primarily created for iOS.
I'm still trying to understand what's exactly happing in _stopScrollPropagation and _recordScrollable so any help on this is appreciated.
Any idea how to stop propagation (so the body's _stopScrolling doesn't take effect) for the off-canvas and it's scrollable children without an additional class/selector?

I'm coming back to this issue since I'm more and more reaching the limits of the current touch handling of the off-canvas (if contentScroll === false).
Firstly I've come to the conclusion there's probably no way around the additional data-off-canvas-scrollbox attribute. Although I'd prefer not using it I don't see any alternative because the inner scrollbox has to be treated the same way as the outer off-canvas. Otherwise there will always be the  problem the page content (body) gets scrolled when the end of the inner scrollbox is reached (iOS issue).
So imo it's unavoidable to have such a markup

Lorem ipsum

dolor sit amet

Secondly I've got an UI issue with the scrollbox feature.
Although my scrollbox attribute works the user may get confused if the inner scrollbox is not completely visible (e.g. if not having scrolled down enough) because after having reached the end of the scrollbox, further scroll down does not continue to scroll down the outer off-canvas.
So the user has to put his finger outside the scrollbox to be able to reach the rest of the off-canvas.
It would be more intuitive to cause a scroll down/up in the off-canvas if the user has reached the end of the inner scrollbox and is still touch moving down/up.
I'm currently working on this additional scroll continue feature.
But regarding the markup I will stick to the data-off-canvas-scrollbox attribute.
@kball hope this is ok for you?
To get away from preventing default / stopping propagation doesn't seem to be possible in my eyes so far.

Done!
I've now extended the present _stopScrollPropagation function to affect the outer off-canvas as well (if called from the scrollbox).
Seems to work fine for me. I'm not 100% happy with looking for the outer off-canvas (elem.closest('[data-off-canvas]')) on every touch move.  But since it's limited to the boundary area of the scrollbox and since this.$element is not available in this scope it's good to go with in my eyes.
@kball @IamManchanda would be great if can review this PR!
(just comment in the further dummy text in the visual test nested.html line 209-213 to see what my latest commit does)
p.s.
if you wonder why I've also added [data-off-canvas-scrollbox-outer] to the parent selector:
This provides the possibility to explicitly specify the outer parent container in cases the default [data-off-canvas] doesn't fit.

@ncoden I've just run into the same issue for another project.
Would you review this PR and merge if ok?
I've created a new, simple codepen that shows the issue pretty well.
Just open the dev tools with touch emulation (or any real mobile device) and try to touchmove down the drilldown in the offcanvas.
https://codepen.io/KaiTheGreat/pen/oELvLB
Without my fix (checkbox unchecked) this doesn't work.

@SassNinja I am not able to make it works with the codepen you given. I tested with both Firefox dev tools and BrowserStack (safari on iOS 11). Should the drilldrow scroll on mobile ?

@ncoden I think FF doesn't emulate the touch behavior appropriately.
Try the Chrome dev tools, click the 'Toggle device toolbar' icon, choose iPad landscape and try to touch move (not scroll!) the drilldown in the offcanvas.
The drilldown is supposed to be moved.
Without my PR (checkbox unchecked) this doesn't work.

Maybe it helps if you take a look at this screen capture to understand the issue

Hmm.. I am unable to reproduce the "patch" in https://codepen.io/KaiTheGreat/pen/oELvLB
See: https://giphy.com/gifs/l3nSOjb8rbfQIfYBi (in Giphy because this is a huge gif)

Which Chrome version was used for testing and what can we do here? Is some more testing needed?

I think we need an example which always reproduces the issue in talk (not only on my side).
In general it's seems to be really tricky error-prone if you've got more than just 'simple content' in the off-canvas on mobile / touch devices.
I'll try to create another, more complex codepen that hopefully always shows the issue.

Poke @ncoden
Are you able to reproduce the issue (and the fix) with my latest codepen?

I missed your reply. I'll check that again when I have some time.

I'd like to finish this PR...
My latest codepen is still relevant:
https://codepen.io/KaiTheGreat/pen/EERrBV
Since the codepen is probably a very very specific use case (and bcz it should be done anyway) I've added a section in the docs to describe this incl. a simple example.
@ncoden @DanielRuf would be awesome if one of you could manage to take a look!

This pull request has been mentioned on Foundation Open Source Community. There might be relevant details there:
https://foundation.discourse.group/t/foundation-for-sites-v6-6-0-is-here-farout/30/1


The app crashes

I use Fedora39
The app doesn't start, just crashes
Here is the details from Problem Reporting app (there is a problem reporting the issue from the app)

Thank you for reporting the problem. Please check if v1.0.6 (latest) version of the app is working properly. It should be available shortly. Just run
flatpak update

and then try to launch the app

I think this is related to issue #3.

@kyouhan does that still happen?

just download Chatgpt Electron and i promis you wont face the issues we are all facing with this app , I use Ubuntu and is Crashes and doesnt work for me neither, they puttting a bad taste in people mouth that love flatpaks.. But yeah if you guys want a Chatgpt Desktop Appllication , head over to Software center and download ChatGPT Electron by: Nikola ,  that way you dont have to worry about chatbotClient issues, and plus Nikola application is very minimal in storage usage compare to chatbotClient.. GoodLuck.

I believe his problem was due to  https://github.com/soufrabi/chatbot-client/issues/3  with ozone wayland flags

@DEGENMUTANT  a little more info
such as flatpak run output and whether you are in wayland /x11 session would help.
I apologize for the inconvenience you faced.


papplMain()?

Would be interesting to provide a standard command-line interface for PAPPL-based printer applications, like the one that LPrint provides.

This is now done, thanks to PR #26!


RATIS-881. Fix Failed unit test because test before MiniRaftCluster ready

What's the probelm ?

What's the reason ?
The root cause is RaftServerMetrics::getPeerCommitIndexGauge happens before RaftServerMetrics::addPeerCommitIndexGauge.
When some RaftServerImpl setRole(RaftPeerRole.LEADER, "changeToLeader"), the statement waitForLeader succ to get leader and test begin, but role.startLeaderState ->
new LeaderState ->
LeaderState::addSenders->RaftServerMetrics::addFollower -> RaftServerMetrics::addPeerCommitIndexGauge has not finished.

@lokeshj1703 Thanks for your review. I have updated the patch.

@runzhiwang Thanks for the contribution! @bshashikant Thanks for the review! I have committed the PR to master branch.
Made a minor change in the commit: Removed @VisibleForTesting annotation on RaftServerImpl@isLeaderReady.


[2801] /subject-areas endpoint

Context
Changes proposed in this pull request
Guidance to review
Checklist

[ ] Make sure all information from the Trello card is in here
[ ] Attach to Trello card
[ ] Rebased master
[ ] Cleaned commit history
[ ] Tested by running locally

 Add v3 /subject-areas endpoint


[pwm/lint] Minor lint fix

Signed-off-by: Michael Schaffner<EMAIL_ADDRESS>

Thank you very much for making this update! I created a PR #8177 to fix this, but it has not been merged yet. Maybe we shall close either one of them?

Thank you very much for making this update! I created a PR #8177 to fix this, but it has not been merged yet. Maybe we shall close either one of them?

Hi Muqing,
Oh goodness. My apologies, I had no idea this was still lingering.   I'm happy to merge/approve either of these (@msfschaffner any preference?).   If this happens again, please feel free to just place a comment (e.g. "Can we merge this now?") on the on lingering PR to send a reminder.
-Martin

Thanks @Muqing-Liu, I have merged yours - let's close this one.


Fixed Winograd minibatch issue

I fixed the minibatch issue for convolution using winograd. I had to insert checks for divisibility of minibatch by the unroll factor for the benchmark cases.

Codecov Report

Merging #194 into master will decrease coverage by 0.08%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #194      +/-   ##
==========================================
- Coverage   14.77%   14.68%   -0.09%
==========================================
  Files         191      191
  Lines       28334    28450     +116
  Branches     5889     5891       +2
==========================================
- Hits         4186     4178       -8
- Misses      23498    23631     +133
+ Partials      650      641       -9

Impacted Files
Coverage Δ

src/libxsmm_dnn_handle.c
0% <0%> (ø)
:arrow_up:

src/libxsmm_gemm_diff.c
65.33% <0%> (-10.67%)
:arrow_down:

tests/diff.c
33.33% <0%> (-4.77%)
:arrow_down:

src/libxsmm_trace.c
63.55% <0%> (-1.87%)
:arrow_down:

src/generator_gemm.c
26.72% <0%> (-1.73%)
:arrow_down:

src/generator_x86_instructions.c
20.08% <0%> (-0.11%)
:arrow_down:

src/generator_gemm_common.c
44.8% <0%> (+0.36%)
:arrow_up:

src/libxsmm_main.c
44.16% <0%> (+0.44%)
:arrow_up:

src/libxsmm_malloc.c
45.89% <0%> (+0.55%)
:arrow_up:

src/generator_gemm_sse3_avx_avx2_avx512.c
60.91% <0%> (+1.01%)
: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 b047c00...0f6c857. Read the comment docs.


Bump Arcanist requirement in composer.json

Hey bud,
Could you bump the version requirement for Arcanist to bring in 0.2.0
Cheers!

Whoops, it was still depending on dev-main 🙈 Just tagged a 0.2.0 version that uses the correct dependency. Thanks for pointing that out!

Delighted - thank you :D


For all extensions on the web?

Is this only for archiving "your" extension or does it work for all extensions across the web?
How do you manage storage then?

it's only archiving public extensions on the chrome web store for now. I store them on the same server serving crx.dam.io, thank to OVH :)

But that's a lot of data isn't it? And what about the bandwidth?

Bandwidth is free with ovh :smiley:


[stable/metricbeat] Set dnsPolicy explicitly to ClusterFirstWithHostNet

What this PR does / why we need it:
Allow metricbeat installs to work properly when outputting to cluster-local destination.
Which issue this PR fixes

fixes #8083

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped

@davidarcher looks like there is a conflict you need to resolve still with Chart.yaml.
After can @mattfarina please merge? This issue also blocks my ability to write out to elasticsearch when ES is hosted inside the cluster.

Hi @aba182 I've got this one-liner cleaned up and all CI checks passing. Should be gtg.
CC'ing @paulczar @mattfarina

/lgtm


System.ApplicationException: abort: No space left on device

klb-n4-flex
rhg-flex
System.ApplicationException: abort: No space left on device

hg Command was
pull<EMAIL_ADDRESS>hg version is: Mercurial Distributed SCM (version 3.0.1)
(see http://mercurial.selenic.com for more information)

  at Chorus.VcsDrivers.Mercurial.HgRepository.PullFromTarget (System.String targetLabel, System.String targetUri) [0x00106] in <d98940b1597342908bfb88b257fca6f5>:0
  at Chorus.VcsDrivers.Mercurial.HgNormalTransport.Pull () [0x00000] in <d98940b1597342908bfb88b257fca6f5>:0
  at Chorus.VcsDrivers.Mercurial.HgRepository.Pull (Chorus.VcsDrivers.RepositoryAddress source, System.String targetUri) [0x00050] in <d98940b1597342908bfb88b257fca6f5>:0
  at LfMergeBridge.LanguageForgeSendReceiveActionHandler.LibTriboroughBridgeChorusPlugin.Infrastructure.IBridgeActionTypeHandler.StartWorking (SIL.Progress.IProgress progress, System.Collections.Generic.Dictionary`2[TKey,TValue] options, System.String& somethingForClient) [0x001cd] in <dbee31384bce49b1bd2ffaab93484008>:0
  at LfMergeBridge.LfMergeBridge.Execute (System.String actionType, SIL.Progress.IProgress progress, System.Collections.Generic.Dictionary`2[TKey,TValue] options, System.String& somethingForClient) [0x000df] in <dbee31384bce49b1bd2ffaab93484008>:0
  at LfMerge.Core.Actions.SynchronizeAction.DoRun (LfMerge.Core.ILfProject project) [0x0013c] in /build/lfmerge-7000072-qfHNDk/lfmerge-7000072-<IP_ADDRESS>/src/LfMerge.Core/Actions/SynchronizeAction.cs:98
  at LfMerge.Core.Actions.Action.Run (LfMerge.Core.ILfProject project) [0x0010d] in /build/lfmerge-7000072-qfHNDk/lfmerge-7000072-<IP_ADDRESS>/src/LfMerge.Core/Actions/Action.cs:142
  at LfMerge.Program.RunAction (System.String projectCode, LfMerge.Core.Actions.ActionNames currentAction) [0x000ed] in /build/lfmerge-7000072-qfHNDk/lfmerge-7000072-<IP_ADDRESS>/src/LfMerge/Program.cs:128

These have been resolved manually after resolving server issues.


Add support for S3Key VersionID while publishing revision to CodeDeploy

Currently we are publishing revision to CodeDeploy with S3Bucket+Key+eTag but we should add support VersionID as well for buckets with versioning enabled

Has there been any progress on this issue? Is it possible to rollback to previous versions without referencing version in deployment?


Toil not hot-deploying module

I have a user script that depends on another module (tsv, which I wrote and put on PyPI). In my Azure cluster, the module is installed on my master, but not on the Mesos agents. It looks like it isn't being hot-deployed.
=========> Failed job 'main_job' 41d94979_88af_44bc_8554_6d7fcb598350
---TOIL WORKER OUTPUT LOG---
INFO:toil:Running Toil version 3.6.0-f930a841e79d1032a44670b85c319411ca539ede.
ERROR:toil.resource:Failed to import user module ModuleDescriptor(dirPath=u'/tmp/tmpgRNEyn/d7b795521a9c20756fa7b94f204c5490', name='hgvmbuilder.importsam', fromVirtualEnv=False) from sys.path (['/usr/local/bin', '/usr/local/lib/python2.7/dist-packages/pip-9.0.1-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/mesos.interface-0.22.0-py2.7.egg', '/usr/local/lib/python2.7/dist-packages/mesos-0.22.0-py2.7-linux-x86_64.egg', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', u'/tmp/tmpgRNEyn/d7b795521a9c20756fa7b94f204c5490']).
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/toil/worker.py", line 325, in main
    job = Job._loadJob(jobGraph.command, jobStore)
  File "/usr/local/lib/python2.7/dist-packages/toil/job.py", line 858, in _loadJob
    userModule = cls._loadUserModule(userModule)
  File "/usr/local/lib/python2.7/dist-packages/toil/job.py", line 835, in _loadUserModule
    return userModule.load()
  File "/usr/local/lib/python2.7/dist-packages/toil/resource.py", line 570, in load
    return importlib.import_module(module.name)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/home/anovak/hgvm-builder/src/hgvmbuilder/importsam.py", line 23, in <module>
ImportError: No module named tsv
ERROR:toil.worker:Exiting the worker because of a failed job on host hgvm1agent4
WARNING:toil.jobGraph:Due to failure we are reducing the remaining retry count of job 'main_job' 41d94979_88af_44bc_8554_6d7fcb598350 with ID 41d94979_88af_44bc_8554_6d7fcb598350 to 0
WARNING:toil.jobGraph:We have increased the default memory of the failed job 'main_job' 41d94979_88af_44bc_8554_6d7fcb598350 to<PHONE_NUMBER> bytes
<=========

real    0m9.585s
user    0m0.956s
sys     0m0.128s
anovak@hgvm1master1:~$ python -i
Python 2.7.12 (default, Jul 18 2016, 15:02:52)
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tsv
>>> print tsv.__file__
/usr/local/lib/python2.7/dist-packages/tsv.pyc
>>>
anovak@hgvm1master1:~$

It's not in an egg this time.

Even though tsv.pyc is not in an egg, is Toil maybe not able to deploy the module because there's an egg-info directory for it?
anovak@hgvm1master1:~/hgvm-builder$ ls /usr/local/lib/python2.7/dist-packages | grep tsv
tsv-1.1-py2.7.egg-info
tsv.py
tsv.pyc

I just tried to fix it with a sudo pip install --upgrade tsv==1.1, and that's the configuration that it produces. Since the plain pip install is the form recommended by the docs, the tsv module really ought to now be available for hot deployment.

is Toil maybe not able to deploy the module because there's an egg-info directory for it?
I don't think so, Toil doesn't skip hot deploying eggs it just fails on the attempt like you saw in the other issue.

It looks like you didn't install tsv in a virtualenv. That will prevent hot deployment from working on the module.

Does that include the user script? Meaning that I can't provide commands on a user's command line, without them entering a virtualenv, and have them be hot-deployed?

Unfortunately it does include the user script. So to get commands outside the virtualenv you'd have to do something like symlink the executable from within the virtualenv onto the user's path.

The documentation shows creating a virtualenv as the "first order of business", but it definitely doesn't say that not using a virtualenv won't work. So if that's the case the documentation needs to be changed to reflect this limitation.
Since you're supposed to create the virtualenv with --system-site-packages, doesn't that mean that having a dependency other than Toil already installed on the system, and used from within the virtualenv, will break hot deployment? If I have tsv installed at the system level, then when I create a virtualenv with --system-site-packages and install something that depends on tsv in there, it'spossible it will just use the system tsv, right? Then Toil won't be able to hot-deploy that dependency.
Is there a good reason why it works like this? It seems extremely limiting.

The docs also say that I'm supposed to copy my workflow to each host, and the section title is "Hot-deploying Toil", which I'm pretty sure isn't possible.

Yes, that is a typo. I can rewrite this section.

doesn't that mean that having a dependency other than Toil already installed on the system, and used from within the virtualenv, will break hot deployment?

Yes, if the dependency is not on the other hosts. The user script and all of its dependencies need to be within a virtualenv to use hot deployment. I'm not very familiar with the hot deployment code but IIRC the virtualenv is required as a convenient (from Toil's standpoint) way to isolate & identify the packages that need to be deployed.

This is stale, and possibly specific to Azure support, which has been deprecated.  If this is still an issue, please reopen.


[SPARK-6720][MLLIB] PySpark MultivariateStatisticalSummary unit test for normL1...

... and normL2.
Add test cases to insufficient unit test for normL1 and normL2.
Ref: https://github.com/apache/spark/pull/5359

Test build #29740 has started for   PR 5374 at commit dc5718c.

Test build #29740 has finished for   PR 5374 at commit dc5718c.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

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

Test build #29791 has started for   PR 5374 at commit 5541b24.

Test build #29791 has finished for   PR 5374 at commit 5541b24.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

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

LGTM. Merged into master. (The JIRA number is wrong. Do you mind updating the title?)

LGTM. Merged into master. Thanks!


Using update options to create or incrementally update entities

using update options to create or incrementally update entities

@gs-gunjan can we add a test here with entities with "." in the field name in the content.


Generated java files should be added to published source artifact

Currently if I generate artifact using
task sourceJar(type: Jar) {
	from sourceSets.main.allJava
	classifier "sources"
  }

publishing {
	publications {
		freeplaneEvents(MavenPublication) {
			from components.java
			artifactId 'freeplane-events'
			artifacts = [jar]
			artifact sourceJar {
				classifier "sources"
			}
		}
	}
}

generated files are not added to freeplane-events-0.0.1-SNAPSHOT-sources.jar .
Therefore they can not be found when the jar is referenced from other projects.
How can I change the configuration?
Maybe the plugin should do it automatically?
Regards,
Dimitry

As a work around I can use
task sourceJar(type: Jar) {
	from sourceSets.main.allJava, file('apt_generated')
	classifier "sources"
  }

You should use compileJava.options.annotationProcessorGeneratedSourcesDirectory (or compileJava.apt.generatedSourcesDir if you use an older Gradle version; or possibly sourceSets.main.output.generatedSourcesDir added by this plugin) instead of the file(…), but otherwise that's the way to go. You may want to use allSource rather than allJava. And you probably should add a task dependency to the compileJava task to make sure the code is compiled and sources are generated before you actually package the source JAR.
I added a comment on https://github.com/gradle/gradle/issues/2300#issuecomment-371473196 about whether the generated sources directory should automatically be added to the sourceSets.main.allJava; but this has many side effects.

Fwiw, I just released 0.16 with this change.

Hi @tbroyer - what do you think about adding a setting to flip this on or off (default on is fine)? I've been wrangling with this change for a couple days and it's pretty tiring tracking down all the plugins that get affected by having generated code in allJava (broken javadoc, spotless, license format plugin, personally would much rather add the generated code in my sourceJar task manually as it's much simpler.

@anuraaga I'd suggest keeping 0.15 then. Given your feedback, maybe I'll just revert the change (it also "broke" IDE integrations, see #79)

Fwiw, I reverted this change and released v0.17 (which is, functionally, the same as v0.15)


Crash if /usr/local/share/GeoIP/alias/ doesn't exist

Hi,
thank you very much for writing this tool. It's exactly what I was looking for since I don't want to accept the Maxmind Terms of Services.
I tried both compiling from source and downloading the binary, but either way it crashes with "Abort (core dumped)".
I then had a look at your code and found that the output gets copied to /usr/local/share/GeoIP/alias/ which didn't exist on my fresh installation of OPNsense.
So I created the folder and now it's working.

Thank you for feedback!
I've made a change to the code to fix this issue.

Thank you for feedback!
I've made a change to the code to fix this issue.


add dotnet for arm64

Description
This PR moves the dotnet installing from the .deb file to the official dotnet install script. What auto-detects arm64 and amd64
Example run with my test image: https://github.com/QuintenQVD0/yolks/actions/runs/3404735771/jobs/5662191602 The binary get stored in /usr/local/bin/ what is in PATH
edit:
note: that this image will now include also sdk and not just the runtime anymore
All Submissions:

[x] Have you ensured there aren't other open Pull Requests for the same update or change?
[x] Have you created a new branch for your changes and PR from that branch and not from your master branch?

New Image Submissions:

[x] Have you added your image to the Github workflows?
[x] Have you updated the README list to contain your new image?

It nows actuly runs aplications: https://pastebin.com/BWVcdz81


Add iblint ability

This adds a basic ability to lint Interface Builder files using the npm package iblint. I'm not actually sure if this works. I'm no ruby on rails guy so I'm not sure how to test this by executing or by writing tests for it. I don't mind writing tests if someone doesn't mind helping pointing me in the right direction.
@gylaz

@gylaz What's your take on this?

@tonyd256 What's your level of interest on getting this merged in?

@gylaz At this point very little.

Given that this isn't a popular linter yet, I'm going to close this without merging then.
Thanks for the work @tonyd256! Maybe we'll re-open this once iblint is used more in the community.

@gylaz Sounds good. Just so you know, iblint is a thoughtbot thing that I created. It was experimental and is closed source even. So the community really isn't going to pick it up. Anyways, can probably kill that repo too if no one in the mobile team wants to use it.


Train 293

This is Train 293, against the master branch. It contains the following pull requests:
#2107 (Use the more recent marathon endpoint)
#2220 (Bump pkgpanda pkgs kazoo and gunicorn)
#2222 (update fault domain script)
#2224 (bump dcos log sha)

@mesosphere-mergebot bump-ee

@mesosphere-mergebot label ready for review

The cloudformation/simple failure is https://jira.mesosphere.com/browse/DCOS-19542

I think the azure/arm failure is https://jira.mesosphere.com/browse/DCOS_OSS-1830 . Should we separate that out into more specific tickets?

@mesosphere-mergebot override-status teamcity/dcos/test/aws/cloudformation/simple
https://jira.mesosphere.com/browse/DCOS-19542

@margaret I agree that this looks like the Azure failure here is due to flakiness on the Azure side, but unfortunately our Azure details are so minimal it's really hard to know without logging in to Azure... However I reviewed all of the linked PR's, and they all passed the Azure tests at least once. @mellenburg I think we need to add some extra debug capture to dcos-launch when Azure cluster fails to come up like this. (this is the equivalent of AWS ROLLBACK for azure :-/

@mesosphere-mergebot override-status teamcity/dcos/test/azure/arm https://jira.mesosphere.com/browse/DCOS_OSS-1830

@mesosphere-mergebot merge-it


nbdev_export UserWarning

(base) gerardogarcia@Gerardos-MacBook-Pro kdone % nbdev_export
/Users/gerardogarcia/mambaforge/lib/python3.9/site-packages/nbdev/export.py:53: UserWarning: Could not find #|default_exp cell. Note nbdev2 no longer supports nbdev1 syntax. Run nbdev_migrate to upgrade.
See https://nbdev.fast.ai/getting_started.html for more information.
warn("Could not find #|default_exp cell. Note nbdev2 no longer supports nbdev1 syntax. Run nbdev_migrate to upgrade.\n"
The issue is that every page has the #|default_exp directive and I cannot find the reason this is failing
I would like to know which page is the one without the directive.
Here is the repository
https://github.com/geg00/kdone

@geg00 it looks like your index.ipynb has an #|export but no #|default_exp. I'll rename this issue and leave it open so we can clarify the warning message


The react-native update to the 0.4.1 version, the title is not centered

The normal version of 0.4.0,  I dont't know how to modify,  need help,  thank you.

I've just checked basic example in the examples folder and it's centered. If you have something specific, please, share the code with me, I'll try to take a look.

thank you very match!
I trid it, example no problem.   i have a look again
Thanks again

Amazing！
basic example run, ok!
But, I copy the basic example code into the index.ios.js in my project,  not centered.
index.ios.js
'use strict';

var React = require('react-native');
var {
  AppRegistry,
  StyleSheet,
  Text,
  View,
  Navigator,
  TouchableHighlight,
} = React;

var NavigationBar = require('react-native-navbar');

class Example extends React.Component {
  render() {
    return (
      <View>
        <Text>Some content</Text>
      </View>
    );
  }
}

var test = React.createClass({

  renderScene: function(route, navigator) {

    var Component = route.component;
    var navBar = route.navigationBar;

    if (navBar) {
      navBar = React.addons.cloneWithProps(navBar, {
        navigator: navigator,
        route: route
      });
    }

    return (
      <View style={styles.navigator}>
        {navBar}
        <Component navigator={navigator} route={route} />
      </View>
    );
  },

  handleNext() {
    alert('Next button click handler');
  },

  render: function() {
    return (
      <Navigator
        style={styles.navigator}
        renderScene={this.renderScene}
        initialRoute={{
          component: Example,
          navigationBar: <NavigationBar
            title="Initial View"
            onNext={this.handleNext}
          />
        }}
      />
    )
  },

});

var styles = StyleSheet.create({
  navigator: {
    flex: 1
  },
});

AppRegistry.registerComponent('test', () => Basic);

Result

oh.....my fault.... I upgrade to 0.4.7, to solve the problem.


dataloader issue in "Text classification from scratch": Invalid dtype: object

Starting with the basic Text classification from scratch
keras issue#18468, converting examples  shows this example as having been converted from keras2->keras3
It all runs fine, until end_to_end_model.evaluate(raw_test_ds)  bumps into some dataloader issue?

Traceback (most recent call last):
File ".../torch-kerasNLP.py", line 190, in
main()
File ".../torch-kerasNLP.py", line 187, in main
end_to_end_model.evaluate(raw_test_ds)
File ".../keras/src/utils/traceback_utils.py", line 123, in error_handler
raise e.with_traceback(filtered_tb) from None
File ".../torch/utils/data/dataloader.py", line 631, in next
data = self._next_data()
^^^^^^^^^^^^^^^^^
File ".../torch/utils/data/dataloader.py", line 675, in _next_data
data = self._dataset_fetcher.fetch(index)  # may raise StopIteration
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File ".../torch/utils/data/_utils/fetch.py", line 41, in fetch
data = next(self.dataset_iter)
^^^^^^^^^^^^^^^^^^^^^^^
File ".../tree/init.py", line 435, in map_structure
[func(*args) for args in zip(*map(flatten, structures))])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File ".../tree/init.py", line 435, in
[func(*args) for args in zip(*map(flatten, structures))])
^^^^^^^^^^^
ValueError: Invalid dtype: object

Hi, Thanks for reporting the issue.
I was able to run the example without any issues, make sure you upgrade the Keras version to the latest.
Here is the working Gist  for reference.


[SPARK-42234][SQL] Rename error class: UNSUPPORTED_FEATURE.REPEATED_PIVOT

What changes were proposed in this pull request?
This PR proposes to rename UNSUPPORTED_FEATURE.REPEATED_PIVOT to REPEATED_CLAUSE.
Why are the changes needed?
REPEATED_PIVOT is actually not an UNSUPPORTED_FEATURE, and there must be other cases we should cover in more generic way
Does this PR introduce any user-facing change?

No.
How was this patch tested?

Updated UTs.

+1, LGTM. Merging to master/3.4.
Thank you, @itholic and @srielau for review.


Automation Use No Interactive Prompt?

Greetings,
Maybe my PS inexperience is shining brightly in this question, but I'm trying execute a PS script, that invokes Posh-SSH,  from a monitoring tool called PRTG. It's a simple process where I've written a script that is fired by PRTG when an event occurs. The script is bellow, my issue is it appears that Posh-SSH will invoke a interactive dialog window and wait for credentials and because of this the script never completes it's execution. I'm puzzled why that dialog window from the New-SSHSession even presents itself considering I'm using a key file for authentication, but again, I don't that much PS experience so I might be missing something simple. This Newbie says thanks for any insight on my issue.
`

Test values
$phoneNumber = 'xxxXXXxxxx'
$message = (Get-Date).DateTime

Capture phone and message parameters from CLI
#param([string]$phoneNumber = "phoneNumber", [string]$message = "message")

Assembly send command string.
$SendCommand = "sendsms " + $phoneNumber + " " + "'" + $message + "'"

Test code to pass credentials
#$username = "alert"
#$password = " " | ConvertTo-SecureString -asPlainText -Force
#$credential = New-Object System.Management.Automation.PSCredential($username,$password)

#Open SSH session using key authentication.
New-SSHSession -ComputerName <IP_ADDRESS> -Credential alert -KeyFile "C:\keys\keyA.key" -Port 2220

Send command to fire SMS alert
Invoke-SSHCommand -Command $SendCommand -SessionId 0

Kill SSH session
Remove-SSHSession -SessionId 0

Jobs done, next?
`

The reason is that even if you provide a key the credentials param is still mandatory so we know to what user we should associate the key to. You can create a credential object with the user and a empty password and pass the key param.


[AutoDiff] make diff_wit_fns instead of fn_refs

Main change
The main point of this PR is to make the differentiation pass look up witnesses and make differentiable_witness_function instructions, instead of looking up attributes and making function_refs.
Related changes
Some fixes were required to make this work properly:

LinkEntity::SecondaryPointer needed to be set to nullptr.
Added some logic to LoadableByAddress to handle differentiable_witness_function.
Do not canonicalize the generic signature in the differentiability witnesses. This makes the "tau" stuff appear in the diagnostics, breaking some tests. Canonicalization is not necessary because all users that require canonicalization canonicalize it again anyways.
Adjusted some tests.
Some interesting stuff happened in differentiable_sil_attr_roundtrip.swift, see the comment.

I used this PR as an opportunity to move all "derivative lookup" logic into its own file. I think this makes it easier to read and also it'll make incremental compilation faster.
What I'm doing next
I'm going to run toolchain build and swift-apis tests on this because it's a big change.
I'll be online from ~9pm to ~10pm tonight to fix any CI failures or address any comments. After that, I'll be out until Monday, so feel free to do whatever you want with this if you want to extend it over the weekend.
Next steps
This does not yet eliminate SILDifferentiableAttr, which is still used for at least:

Initial triggering of differentiation.
Canonicalization fills in a SILDifferentiableAttr, and then the jvp/vjp from that gets copied to the witness.

I think it'll be quite easy for a follow-up PR to remove these things and delete SILDifferentiableAttr, and that's what I think the next PR should do.
After that, all the typechecking and SILGen simplifications that we want should be unblocked. And then after that we should be able to implement cross-file and cross-module retrodiff and start using it in the stdlib.
I plan not to work on any of this until Monday, so feel free to start doing stuff on it if you want.

@swift-ci please test tensorflow

@swift-ci Please test tensorflow linux

I figured out why the tests are failing. I pushed a fix that makes it slightly better but does not fix it. I have to sign off now, feel free to do more stuff to this.
The reason the tests are failing is that inlinable functions with differentiability_witness_function instructions are getting inlined into the module, but the corresponding witness tables are not getting inlined into the module. So deserialization tries to look up the witness table, does not find it, and dies.

I had a bit of time to investigate the failure today, so I added a simple testcase that triggers it that should make it pretty clear what's happening. In the testcase, the test_serialized function gets serialized into the module, so there's a reference to the differentiability witness, so the differentiability witness needs to get serialized into the module. Otherwise, deserialization fails because it doesn't see the witness.
Okay, that's all I'll be doing for now.

In the testcase, the test_serialized function gets serialized into the module, so there's a reference to the differentiability witness, so the differentiability witness needs to get serialized into the module. Otherwise, deserialization fails because it doesn't see the witness.

Thanks for the clear explanation! I think I understand the SIL serialization issues and I'll investigate now.

@swift-ci Please test tensorflow

@swift-ci Please test tensorflow

@swift-ci Please test tensorflow

@swift-ci Please test tensorflow

Concern
This makes litrun test/AutoDiff -sv 2x slower for me (10s -> 20s). I haven't done any investigation of this. It should probably be investigated eventually.

Shall we investigate the (compile-time and/or runtime) performance regressions before merging this PR? I suspect generating differentiability_witness_function instructions instead of JVP/VJP function_refs may impact runtime performance - TF-994 tracks devirtualization.

I'll spend a bit of time measuring the compile time and runtime performance impact of this. I'll report back on the PR before merging and we can decide whether to go ahead.

Runtime performance
Microbenchmark
func descendQuadratic(
  a: Float, b: Float, x0: Float, rate: Float, count: Int
) -> Float {
  var x = x0
  for _ in 0..<count {
    let g = gradient(at: x) { x in
      x * x + a * x + b
    }
    x -= rate * g
  }
  return x
}

let x1 = descendQuadratic(
  a: 0, b: 0, x0: 10, rate: 0.001, count: 10_000_000)
print(x1)

When compiled with -O, the runtime goes from 4.9s to 5.7s on my workstation.
swift-models Benchmark
No noticeable difference when running this benchmark.
Internal Google model
An internal Google model is affected, with about the same amount of performance regression as the microbenchmark.
Decision
I will implement devirtualization before merging this patch because we don't want to check in such a big performance regression without being sure that we have a solution.

A swift-apis failure also remains after the latest fixes, so I will investigate that too:
Step 17/34 : RUN /swift-tensorflow-toolchain/usr/bin/swift test
 ---> Running in a31cd76d5d87
[1/13] Compiling Tensor Random.swift
[3/14] Merging module Experimental
[4/16] Wrapping AST for Experimental for debugging
[5/16] Compiling ExperimentalTests XCTestManifests.swift
[6/17] Merging module Tensor
[7/21] Wrapping AST for Tensor for debugging
[8/35] Linking libTensor.so
[9/71] Compiling TensorFlow Exports.swift
[10/71] Compiling TensorFlow Freezable.swift
[11/71] Compiling TensorFlow Optimizer.swift
[12/71] Compiling TensorFlow Threading.swift
[13/71] Compiling TensorFlow Utilities.swift
[14/71] Compiling TensorFlow Execution.swift
[15/71] Compiling TensorFlow LazyTensorContext.swift
[16/71] Compiling TensorFlow Context.swift
[17/71] Compiling TensorFlow ArrayOps.swift
[18/71] Compiling TensorFlow SGD.swift
[19/71] Compiling TensorFlow Runtime.swift
[20/71] Compiling TensorFlow Serialization.swift
[21/71] Compiling TensorFlow Comparison.swift
[22/71] Compiling TensorFlow StdlibExtensions.swift
[23/71] Compiling TensorFlow EagerExecution.swift
[24/71] Compiling TensorFlow TensorHandle.swift
[25/71] Compiling TensorFlow TensorShape.swift
[26/71] Compiling TensorFlow RawOpsGenerated.swift
[27/71] Compiling TensorFlow LazyTensorTFFunctionBuilder.swift
[28/71] Compiling TensorFlow LazyTensorTrace.swift
[30/71] Compiling TensorFlow LazyTensorTraceCache.swift
[31/71] Compiling TensorFlow PythonConversion.swift
[32/71] Compiling TensorFlow Dataset.swift
[33/71] Compiling TensorFlow BackwardsCompatibility.swift
[34/72] Merging module TensorTests
[35/72] Wrapping AST for TensorTests for debugging
[36/72] Compiling TensorFlow DataTypes.swift
[37/72] Compiling TensorFlow DifferentialOperators.swift
[38/72] Compiling TensorFlow LazyTensorOperation.swift
[39/72] Compiling TensorFlow LazyTensorShapeInference.swift
[40/72] Compiling TensorFlow ShapedArray.swift
[41/72] Compiling TensorFlow StringTensor.swift
[43/73] Merging module ExperimentalTests
[44/73] Wrapping AST for ExperimentalTests for debugging
[45/73] Compiling TensorFlow Sequential.swift
[46/73] Compiling TensorFlow Embedding.swift
[47/73] Compiling TensorFlow Initialization.swift
[48/73] Compiling TensorFlow Tensor.swift
[49/73] Compiling TensorFlow TensorGroup.swift
[52/73] Compiling TensorFlow Initializers.swift
[53/73] Compiling TensorFlow Layer.swift
[54/73] Compiling TensorFlow MomentumBased.swift
[55/73] Compiling TensorFlow NN.swift
[56/73] Compiling TensorFlow Upsampling.swift
[57/73] Compiling TensorFlow Dense.swift
[58/73] Compiling TensorFlow Dropout.swift
[60/73] Compiling TensorFlow TFTensorOperation.swift
[61/73] Compiling TensorFlow Recurrent.swift
[62/73] Compiling TensorFlow Basic.swift
[63/73] Compiling TensorFlow Loss.swift
[64/73] Compiling TensorFlow Normalization.swift
[65/73] Compiling TensorFlow Pooling.swift
[66/73] Compiling TensorFlow Convolutional.swift
[67/73] Compiling TensorFlow Core.swift
[68/73] Compiling TensorFlow Math.swift
swift: /swift-base/swift/lib/SIL/SILDifferentiabilityWitness.cpp:36: static swift::SILDifferentiabilityWitness *swift::SILDifferentiabilityWitness::createDeclaration(swift::SILModule &, swift::SILLinkage, swift::SILFunction *, swift::IndexSubset *, swift::IndexSubset *, swift::GenericSignature, swift::DeclAttribute *): Assertion `!module.DifferentiabilityWitnessMap.count(mangledKey) && "Cannot create duplicate differentiability witness in a module"' failed.
Stack dump:
0.	Program arguments: /swift-tensorflow-toolchain/usr/bin/swift -frontend -merge-modules -emit-module /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/BackwardsCompatibility~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Bindings/EagerExecution~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Bindings/RawOpsGenerated~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Bindings/TFTensorOperation~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Context~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/ArrayOps~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/DataTypes~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/DifferentialOperators~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/Execution~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/LazyTensorContext~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/LazyTensorOperation~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/LazyTensorShapeInference~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/LazyTensorTFFunctionBuilder~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/LazyTensorTrace~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/LazyTensorTraceCache~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/PythonConversion~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/Runtime~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/Serialization~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/ShapedArray~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/StringTensor~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/Tensor~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/TensorGroup~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/TensorHandle~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/TensorShape~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/Threading~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Core/Utilities~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Exports~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Freezable~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Initializers~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Layer~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Layers/Convolutional~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Layers/Core~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Layers/Dense~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Layers/Dropout~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Layers/Embedding~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Layers/Initialization~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Layers/Normalization~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Layers/Pooling~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Layers/Recurrent~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Layers/Sequential~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Layers/Upsampling~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Loss~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Operators/Basic~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Operators/Comparison~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Operators/Dataset~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Operators/Math~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Operators/NN~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Optimizers/MomentumBased~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Optimizers/Optimizer~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Optimizers/SGD~partial.swiftmodule /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/StdlibExtensions~partial.swiftmodule -parse-as-library -sil-merge-partial-modules -disable-diagnostic-passes -disable-sil-perf-optzns -target x86_64-unknown-linux-gnu -disable-objc-interop -I /swift-apis/.build/x86_64-unknown-linux-gnu/debug -enable-testing -g -module-cache-path /swift-apis/.build/x86_64-unknown-linux-gnu/debug/ModuleCache -swift-version 4.2 -Onone -D SWIFT_PACKAGE -D DEBUG -enable-anonymous-context-mangled-names -emit-module-doc-path /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.swiftdoc -emit-module-source-info-path /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.swiftsourceinfo -module-name TensorFlow -o /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.swiftmodule
1.	Swift version 5.1.1-dev (Swift 655b1919ac)
/swift-tensorflow-toolchain/usr/bin/swift[0x4bf7844]
/swift-tensorflow-toolchain/usr/bin/swift[0x4bf545e]
/swift-tensorflow-toolchain/usr/bin/swift[0x4bf7af8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f84a613e890]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f84a45a1e97]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f84a45a3801]
/lib/x86_64-linux-gnu/libc.so.6(+0x3039a)[0x7f84a459339a]
/lib/x86_64-linux-gnu/libc.so.6(+0x30412)[0x7f84a4593412]
/swift-tensorflow-toolchain/usr/bin/swift[0xe91012]
/swift-tensorflow-toolchain/usr/bin/swift[0x12b8e0b]
/swift-tensorflow-toolchain/usr/bin/swift[0x12d29d3]
/swift-tensorflow-toolchain/usr/bin/swift[0x125e36f]
/swift-tensorflow-toolchain/usr/bin/swift[0x125e3d3]
/swift-tensorflow-toolchain/usr/bin/swift[0x759965]
/swift-tensorflow-toolchain/usr/bin/swift[0x4e094e]
/swift-tensorflow-toolchain/usr/bin/swift[0x4d6be7]
/swift-tensorflow-toolchain/usr/bin/swift[0x4d3c6d]
/swift-tensorflow-toolchain/usr/bin/swift[0x474290]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f84a4584b97]
/swift-tensorflow-toolchain/usr/bin/swift[0x473eda]
The command '/bin/sh -c /swift-tensorflow-toolchain/usr/bin/swift test' returned a non-zero code: 1

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow macos

Updates!
tldr: Only one remaining blocker, a swift-apis compile failure, which I am investigating now.
Runtime performance
https://github.com/apple/swift/pull/28480 has fully fixed the performance regression in the microbenchmark posted above and in the internal google model.
*Compiletime performance
There's a bit of slowdown as measured by running the AD compiler test suite. None of it seems egregious, so I will defer investigation. Filed TF-1013 for future investigation. You can see the measurements at https://gist.github.com/marcrasi/456d09d15a14f9af092db2e7b24186bb.
swift-apis compile failure
Step 17/34 : RUN /swift-tensorflow-toolchain/usr/bin/swift test
 ---> Running in 1cd353790e84
[1/13] Compiling Tensor Random.swift
[3/14] Merging module Experimental
[4/16] Wrapping AST for Experimental for debugging
[5/16] Compiling ExperimentalTests XCTestManifests.swift
[6/17] Merging module Tensor
[7/21] Wrapping AST for Tensor for debugging
[8/37] Linking libTensor.so
[9/71] Compiling TensorFlow Exports.swift
[10/71] Compiling TensorFlow Freezable.swift
[11/71] Compiling TensorFlow Optimizer.swift
[12/71] Compiling TensorFlow Execution.swift
[13/71] Compiling TensorFlow LazyTensorContext.swift
[14/71] Compiling TensorFlow Threading.swift
[15/71] Compiling TensorFlow Utilities.swift
[16/71] Compiling TensorFlow Context.swift
[17/71] Compiling TensorFlow ArrayOps.swift
[18/71] Compiling TensorFlow StdlibExtensions.swift
[19/71] Compiling TensorFlow SGD.swift
[20/71] Compiling TensorFlow Runtime.swift
[21/71] Compiling TensorFlow Serialization.swift
[22/71] Compiling TensorFlow EagerExecution.swift
[23/71] Compiling TensorFlow RawOpsGenerated.swift
[24/71] Compiling TensorFlow TensorHandle.swift
[25/71] Compiling TensorFlow TensorShape.swift
[26/71] Compiling TensorFlow Comparison.swift
[27/71] Compiling TensorFlow LazyTensorTFFunctionBuilder.swift
[28/71] Compiling TensorFlow LazyTensorTrace.swift
[29/71] Compiling TensorFlow LazyTensorTraceCache.swift
[30/71] Compiling TensorFlow PythonConversion.swift
[32/71] Compiling TensorFlow Dataset.swift
[33/71] Compiling TensorFlow BackwardsCompatibility.swift
[34/72] Compiling TensorFlow DataTypes.swift
[35/72] Compiling TensorFlow DifferentialOperators.swift
[36/72] Merging module TensorTests
[37/72] Wrapping AST for TensorTests for debugging
[39/73] Merging module ExperimentalTests
[40/73] Wrapping AST for ExperimentalTests for debugging
[41/73] Compiling TensorFlow ShapedArray.swift
[42/73] Compiling TensorFlow StringTensor.swift
[43/73] Compiling TensorFlow LazyTensorOperation.swift
[44/73] Compiling TensorFlow LazyTensorShapeInference.swift
[45/73] Compiling TensorFlow Sequential.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[46/73] Compiling TensorFlow Embedding.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[47/73] Compiling TensorFlow Initialization.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[48/73] Compiling TensorFlow Tensor.swift
[49/73] Compiling TensorFlow TensorGroup.swift
[52/73] Compiling TensorFlow Initializers.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[53/73] Compiling TensorFlow Layer.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[54/73] Compiling TensorFlow MomentumBased.swift
[55/73] Compiling TensorFlow NN.swift
[56/73] Compiling TensorFlow Upsampling.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[57/73] Compiling TensorFlow Dense.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[58/73] Compiling TensorFlow Dropout.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[60/73] Compiling TensorFlow TFTensorOperation.swift
[61/73] Compiling TensorFlow Recurrent.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[62/73] Compiling TensorFlow Basic.swift
[63/73] Compiling TensorFlow Loss.swift
[64/73] Compiling TensorFlow Normalization.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[65/73] Compiling TensorFlow Pooling.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[66/73] Compiling TensorFlow Convolutional.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[67/73] Compiling TensorFlow Core.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[68/73] Compiling TensorFlow Math.swift
[69/74] Merging module TensorFlow
[70/81] Wrapping AST for TensorFlow for debugging
[71/100] Compiling TensorFlowTests LazyTensorTestHelper.swift
[72/100] Compiling TensorFlowTests RuntimeTests.swift
[73/100] Linking libTensorFlow.so
[74/100] Compiling TensorFlowTests ContextTests.swift
[75/100] Compiling TensorFlowTests Helpers.swift
[76/100] Compiling TensorFlowTests ComparisonTests.swift
[77/100] Compiling TensorFlowTests LazyTensorOperationTests.swift
[78/100] Compiling TensorFlowTests LazyTensorHandleTests.swift
[79/100] Compiling TensorFlowTests LazyTensorTraceCacheTests.swift
[80/100] Compiling TensorFlowTests LazyTensorTFFunctionBuilderTests.swift
[81/100] Compiling TensorFlowTests TensorTests.swift
[82/100] Compiling TensorFlowTests LazyTensorEvaluationTests.swift
[83/100] Compiling TensorFlowTests LazyTensorShapeInferenceTests.swift
[84/100] Compiling TensorFlowTests TensorGroupTests.swift
[85/100] Compiling TensorFlowTests LazyTensorExplicitTraceTests.swift
[86/100] Compiling TensorFlowTests LazyTensorTraceTests.swift
[87/100] Compiling TensorFlowTests XCTestManifests.swift
[88/100] Compiling TensorFlowTests InitializerTests.swift
[89/100] Compiling TensorFlowTests TrivialModelTests.swift
[90/100] Compiling TensorFlowTests DatasetTests.swift
[91/100] Compiling TensorFlowTests SequentialTests.swift
[92/100] Compiling TensorFlowTests FreezableTests.swift
[93/100] Compiling TensorFlowTests LossTests.swift
[94/100] Compiling TensorFlowTests MathTests.swift
[95/100] Compiling TensorFlowTests BasicTests.swift
[96/100] Compiling TensorFlowTests LayerTests.swift
[97/100] Compiling TensorFlowTests TensorAutoDiffTests.swift
[98/101] Merging module TensorFlowTests
[99/102] Wrapping AST for TensorFlowTests for debugging
[100/102] Compiling TensorFlowPackageTests LinuxMain.swift
[101/103] Merging module TensorFlowPackageTests
[102/103] Wrapping AST for TensorFlowPackageTests for debugging
/usr/bin/ld.gold: error: /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlowTests.build/LossTests.swift.o: multiple definition of 'AD__$s10TensorFlow9huberLoss9predicted8expected5delta9reductionAA0A0VyxGAI_AIxA2IXFtAA0aB13FloatingPointRzlFfA2_A2IcfU__PSRS10TensorFlow0aB13FloatingPointRzl'
/usr/bin/ld.gold: /swift-apis/.build/x86_64-unknown-linux-gnu/debug/TensorFlow.build/Loss.swift.o: previous definition here
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
<unknown>:0: error: link command failed with exit code 1 (use -v to see invocation)
[102/103] Linking TensorFlowPackageTests.xctest
The command '/bin/sh -c /swift-tensorflow-toolchain/usr/bin/swift test' returned a non-zero code: 1

Okay, I have uploaded a fix that seems to work. I think it's not very proper, but if all the tests pass then it's probably good enough for now.
Gonna retrigger the swift-apis tests.
@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow macos

@swift-ci please test tensorflow macos

@swift-ci please test tensorflow macos

@swift-ci please test tensorflow macos

@swift-ci please test tensorflow macos

@swift-ci please test tensorflow macos

@swift-ci please test tensorflow macos

@swift-ci please test tensorflow macos

swift-apis tests have gotten farther, but are still failing. The failure is currently a bit mysterious to me. Compilation succeeds, a lot of tests succeed, and then suddenly it says "Exited with signal code 11," with no other explanatory message. Investigating now.
Full test output:
Step 17/34 : RUN /swift-tensorflow-toolchain/usr/bin/swift test
 ---> Running in f9f367c76ab2
[1/13] Compiling Experimental Complex.swift
[3/14] Merging module Experimental
[4/16] Wrapping AST for Experimental for debugging
[5/16] Compiling ExperimentalTests XCTestManifests.swift
[6/17] Merging module Tensor
[7/21] Wrapping AST for Tensor for debugging
[8/35] Linking libTensor.so
[9/71] Compiling TensorFlow Exports.swift
[10/71] Compiling TensorFlow Freezable.swift
[11/71] Compiling TensorFlow Optimizer.swift
[12/71] Compiling TensorFlow Execution.swift
[13/71] Compiling TensorFlow LazyTensorContext.swift
[14/71] Compiling TensorFlow Threading.swift
[15/71] Compiling TensorFlow Utilities.swift
[16/71] Compiling TensorFlow Context.swift
[17/71] Compiling TensorFlow ArrayOps.swift
[18/71] Compiling TensorFlow Runtime.swift
[19/71] Compiling TensorFlow Serialization.swift
[20/71] Compiling TensorFlow StdlibExtensions.swift
[21/71] Compiling TensorFlow EagerExecution.swift
[22/71] Compiling TensorFlow RawOpsGenerated.swift
[23/71] Compiling TensorFlow SGD.swift
[24/71] Compiling TensorFlow Comparison.swift
[25/71] Compiling TensorFlow TensorHandle.swift
[26/71] Compiling TensorFlow TensorShape.swift
[27/71] Compiling TensorFlow LazyTensorTFFunctionBuilder.swift
[28/71] Compiling TensorFlow LazyTensorTrace.swift
[30/71] Compiling TensorFlow LazyTensorTraceCache.swift
[31/71] Compiling TensorFlow PythonConversion.swift
[32/71] Compiling TensorFlow BackwardsCompatibility.swift
[33/72] Merging module TensorTests
[34/72] Wrapping AST for TensorTests for debugging
[35/72] Compiling TensorFlow DataTypes.swift
[36/72] Compiling TensorFlow DifferentialOperators.swift
[37/72] Compiling TensorFlow Dataset.swift
[39/73] Merging module ExperimentalTests
[40/73] Wrapping AST for ExperimentalTests for debugging
[41/73] Compiling TensorFlow LazyTensorOperation.swift
[42/73] Compiling TensorFlow LazyTensorShapeInference.swift
[43/73] Compiling TensorFlow ShapedArray.swift
[44/73] Compiling TensorFlow StringTensor.swift
[45/73] Compiling TensorFlow Sequential.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[46/73] Compiling TensorFlow Embedding.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[47/73] Compiling TensorFlow Initialization.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[48/73] Compiling TensorFlow Tensor.swift
[49/73] Compiling TensorFlow TensorGroup.swift
[52/73] Compiling TensorFlow Initializers.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[53/73] Compiling TensorFlow Layer.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[54/73] Compiling TensorFlow MomentumBased.swift
[55/73] Compiling TensorFlow NN.swift
[56/73] Compiling TensorFlow Upsampling.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[57/73] Compiling TensorFlow Dense.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[58/73] Compiling TensorFlow Dropout.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[60/73] Compiling TensorFlow TFTensorOperation.swift
[61/73] Compiling TensorFlow Recurrent.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[62/73] Compiling TensorFlow Basic.swift
[63/73] Compiling TensorFlow Loss.swift
[64/73] Compiling TensorFlow Normalization.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[65/73] Compiling TensorFlow Pooling.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[66/73] Compiling TensorFlow Convolutional.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[67/73] Compiling TensorFlow Core.swift
/swift-apis/Sources/TensorFlow/Layer.swift:94:6: warning: '@differentiating' attribute is deprecated; use '@derivative(of:)' instead
    @differentiating(inferring(from:))
     ^
[68/73] Compiling TensorFlow Math.swift
[69/74] Merging module TensorFlow
[70/81] Wrapping AST for TensorFlow for debugging
[71/100] Compiling TensorFlowTests LazyTensorTestHelper.swift
[72/100] Compiling TensorFlowTests RuntimeTests.swift
[73/100] Compiling TensorFlowTests Helpers.swift
[74/100] Linking libTensorFlow.so
[75/100] Compiling TensorFlowTests ComparisonTests.swift
[76/100] Compiling TensorFlowTests LazyTensorOperationTests.swift
[77/100] Compiling TensorFlowTests ContextTests.swift
[78/100] Compiling TensorFlowTests LazyTensorTFFunctionBuilderTests.swift
[79/100] Compiling TensorFlowTests LazyTensorHandleTests.swift
[80/100] Compiling TensorFlowTests LazyTensorTraceCacheTests.swift
[81/100] Compiling TensorFlowTests TensorTests.swift
[82/100] Compiling TensorFlowTests LazyTensorEvaluationTests.swift
[83/100] Compiling TensorFlowTests LazyTensorExplicitTraceTests.swift
[84/100] Compiling TensorFlowTests LazyTensorShapeInferenceTests.swift
[85/100] Compiling TensorFlowTests TensorGroupTests.swift
[86/100] Compiling TensorFlowTests XCTestManifests.swift
[87/100] Compiling TensorFlowTests LazyTensorTraceTests.swift
[88/100] Compiling TensorFlowTests SequentialTests.swift
[89/100] Compiling TensorFlowTests DatasetTests.swift
[90/100] Compiling TensorFlowTests TrivialModelTests.swift
[91/100] Compiling TensorFlowTests InitializerTests.swift
[92/100] Compiling TensorFlowTests LossTests.swift
[93/100] Compiling TensorFlowTests FreezableTests.swift
[94/100] Compiling TensorFlowTests MathTests.swift
[95/100] Compiling TensorFlowTests BasicTests.swift
[96/100] Compiling TensorFlowTests LayerTests.swift
[97/100] Compiling TensorFlowTests TensorAutoDiffTests.swift
[98/101] Merging module TensorFlowTests
[99/102] Wrapping AST for TensorFlowTests for debugging
[100/102] Compiling TensorFlowPackageTests LinuxMain.swift
[101/103] Merging module TensorFlowPackageTests
[102/103] Wrapping AST for TensorFlowPackageTests for debugging
[103/103] Linking TensorFlowPackageTests.xctest
Test Suite 'All tests' started at 2019-11-27 06:56:35.939
Test Suite 'debug.xctest' started at 2019-11-27 06:56:35.941
Test Suite 'BasicOperatorTests' started at 2019-11-27 06:56:35.941
Test Case 'BasicOperatorTests.testGathering' started at 2019-11-27 06:56:35.941
Test Case 'BasicOperatorTests.testGathering' passed (0.029 seconds)
Test Case 'BasicOperatorTests.testBatchGathering' started at 2019-11-27 06:56:35.969
Test Case 'BasicOperatorTests.testBatchGathering' passed (0.003 seconds)
Test Case 'BasicOperatorTests.testPadded' started at 2019-11-27 06:56:35.973
Test Case 'BasicOperatorTests.testPadded' passed (0.001 seconds)
Test Case 'BasicOperatorTests.testPaddedConstant' started at 2019-11-27 06:56:35.974
Test Case 'BasicOperatorTests.testPaddedConstant' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testPaddedReflect' started at 2019-11-27 06:56:35.974
Test Case 'BasicOperatorTests.testPaddedReflect' passed (0.001 seconds)
Test Case 'BasicOperatorTests.testPaddedSymmetric' started at 2019-11-27 06:56:35.975
Test Case 'BasicOperatorTests.testPaddedSymmetric' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testVJPPadded' started at 2019-11-27 06:56:35.975
Test Case 'BasicOperatorTests.testVJPPadded' passed (0.001 seconds)
Test Case 'BasicOperatorTests.testVJPPaddedConstant' started at 2019-11-27 06:56:35.977
Test Case 'BasicOperatorTests.testVJPPaddedConstant' passed (0.001 seconds)
Test Case 'BasicOperatorTests.testVJPPaddedReflect' started at 2019-11-27 06:56:35.977
Test Case 'BasicOperatorTests.testVJPPaddedReflect' passed (0.001 seconds)
Test Case 'BasicOperatorTests.testVJPPaddedSymmetric' started at 2019-11-27 06:56:35.978
Test Case 'BasicOperatorTests.testVJPPaddedSymmetric' passed (0.001 seconds)
Test Case 'BasicOperatorTests.testElementIndexing' started at 2019-11-27 06:56:35.979
Test Case 'BasicOperatorTests.testElementIndexing' passed (0.001 seconds)
Test Case 'BasicOperatorTests.testElementIndexingAssignment' started at 2019-11-27 06:56:35.979
Test Case 'BasicOperatorTests.testElementIndexingAssignment' passed (0.001 seconds)
Test Case 'BasicOperatorTests.testNestedElementIndexing' started at 2019-11-27 06:56:35.980
Test Case 'BasicOperatorTests.testNestedElementIndexing' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testSliceIndexing' started at 2019-11-27 06:56:35.980
Test Case 'BasicOperatorTests.testSliceIndexing' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testSliceIndexingAssignment' started at 2019-11-27 06:56:35.980
Test Case 'BasicOperatorTests.testSliceIndexingAssignment' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testEllipsisIndexing' started at 2019-11-27 06:56:35.981
Test Case 'BasicOperatorTests.testEllipsisIndexing' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testNewAxisIndexing' started at 2019-11-27 06:56:35.981
Test Case 'BasicOperatorTests.testNewAxisIndexing' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testSqueezeAxisIndexing' started at 2019-11-27 06:56:35.982
Test Case 'BasicOperatorTests.testSqueezeAxisIndexing' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testStridedSliceIndexing' started at 2019-11-27 06:56:35.982
Test Case 'BasicOperatorTests.testStridedSliceIndexing' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testStridedSliceIndexingAssignment' started at 2019-11-27 06:56:35.982
Test Case 'BasicOperatorTests.testStridedSliceIndexingAssignment' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testWholeTensorSlicing' started at 2019-11-27 06:56:35.983
Test Case 'BasicOperatorTests.testWholeTensorSlicing' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testAdvancedIndexing' started at 2019-11-27 06:56:35.983
Test Case 'BasicOperatorTests.testAdvancedIndexing' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testConcatenation' started at 2019-11-27 06:56:35.984
Test Case 'BasicOperatorTests.testConcatenation' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testVJPConcatenation' started at 2019-11-27 06:56:35.984
Test Case 'BasicOperatorTests.testVJPConcatenation' passed (0.001 seconds)
Test Case 'BasicOperatorTests.testTranspose' started at 2019-11-27 06:56:35.985
Test Case 'BasicOperatorTests.testTranspose' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testReshape' started at 2019-11-27 06:56:35.985
Test Case 'BasicOperatorTests.testReshape' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testFlatten' started at 2019-11-27 06:56:35.985
Test Case 'BasicOperatorTests.testFlatten' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testFlatten0D' started at 2019-11-27 06:56:35.985
Test Case 'BasicOperatorTests.testFlatten0D' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testReshapeToScalar' started at 2019-11-27 06:56:35.985
Test Case 'BasicOperatorTests.testReshapeToScalar' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testReshapeTensor' started at 2019-11-27 06:56:35.986
Test Case 'BasicOperatorTests.testReshapeTensor' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testUnbroadcastRank4ToRank2' started at 2019-11-27 06:56:35.986
Test Case 'BasicOperatorTests.testUnbroadcastRank4ToRank2' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testUnbroadcastRank4ToRank3' started at 2019-11-27 06:56:35.986
Test Case 'BasicOperatorTests.testUnbroadcastRank4ToRank3' passed (0.0 seconds)
Test Case 'BasicOperatorTests.testUnbroadcast3x3To1x3' started at 2019-11-27 06:56:35.986
Test Case 'BasicOperatorTests.testUnbroadcast3x3To1x3' passed (0.001 seconds)
Test Case 'BasicOperatorTests.testSliceUpdate' started at 2019-11-27 06:56:35.987
Test Case 'BasicOperatorTests.testSliceUpdate' passed (0.001 seconds)
Test Case 'BasicOperatorTests.testBroadcast3x0To3x3' started at 2019-11-27 06:56:35.988
Test Case 'BasicOperatorTests.testBroadcast3x0To3x3' passed (0.001 seconds)
Test Case 'BasicOperatorTests.testBroadcast3x1To3x3' started at 2019-11-27 06:56:35.989
Test Case 'BasicOperatorTests.testBroadcast3x1To3x3' passed (0.001 seconds)
Test Case 'BasicOperatorTests.testBroadcastTensor' started at 2019-11-27 06:56:35.991
Test Case 'BasicOperatorTests.testBroadcastTensor' passed (0.0 seconds)
Test Suite 'BasicOperatorTests' passed at 2019-11-27 06:56:35.991
	 Executed 37 tests, with 0 failures (0 unexpected) in 0.049 (0.049) seconds
Test Suite 'ComparisonOperatorTests' started at 2019-11-27 06:56:35.991
Test Case 'ComparisonOperatorTests.testElementwiseComparison' started at 2019-11-27 06:56:35.991
Test Case 'ComparisonOperatorTests.testElementwiseComparison' passed (0.0 seconds)
Test Case 'ComparisonOperatorTests.testLexicographicalComparison' started at 2019-11-27 06:56:35.991
Test Case 'ComparisonOperatorTests.testLexicographicalComparison' passed (0.0 seconds)
Test Case 'ComparisonOperatorTests.testIsAlmostEqual' started at 2019-11-27 06:56:35.991
Test Case 'ComparisonOperatorTests.testIsAlmostEqual' passed (0.0 seconds)
Test Suite 'ComparisonOperatorTests' passed at 2019-11-27 06:56:35.992
	 Executed 3 tests, with 0 failures (0 unexpected) in 0.001 (0.001) seconds
Test Suite 'ContextTests' started at 2019-11-27 06:56:35.992
Test Case 'ContextTests.testDropout' started at 2019-11-27 06:56:35.992
Test Case 'ContextTests.testDropout' passed (0.001 seconds)
Test Case 'ContextTests.testMultithreadedDropout' started at 2019-11-27 06:56:35.993
Test Case 'ContextTests.testMultithreadedDropout' passed (0.002 seconds)
Test Suite 'ContextTests' passed at 2019-11-27 06:56:35.995
	 Executed 2 tests, with 0 failures (0 unexpected) in 0.003 (0.003) seconds
Test Suite 'DatasetTests' started at 2019-11-27 06:56:35.995
Test Case 'DatasetTests.testMultiValue' started at 2019-11-27 06:56:35.995
Test Case 'DatasetTests.testMultiValue' passed (0.002 seconds)
Test Case 'DatasetTests.testSingleValueManualIterator' started at 2019-11-27 06:56:35.997
Test Case 'DatasetTests.testSingleValueManualIterator' passed (0.002 seconds)
Test Case 'DatasetTests.testDatasetIteration' started at 2019-11-27 06:56:35.998
Test Case 'DatasetTests.testDatasetIteration' passed (0.001 seconds)
Test Case 'DatasetTests.testSingleValueTransformations' started at 2019-11-27 06:56:36.000
Test Case 'DatasetTests.testSingleValueTransformations' passed (0.001 seconds)
Test Case 'DatasetTests.testSingleValueHOFs' started at 2019-11-27 06:56:36.001
Test Case 'DatasetTests.testSingleValueHOFs' passed (0.013 seconds)
Test Case 'DatasetTests.testParallelMap' started at 2019-11-27 06:56:36.013
Test Case 'DatasetTests.testParallelMap' passed (0.004 seconds)
Test Case 'DatasetTests.testMapToDifferentType' started at 2019-11-27 06:56:36.018
Test Case 'DatasetTests.testMapToDifferentType' passed (0.004 seconds)
Test Case 'DatasetTests.testSingleValueBatched' started at 2019-11-27 06:56:36.021
Test Case 'DatasetTests.testSingleValueBatched' passed (0.001 seconds)
Test Case 'DatasetTests.testDoubleValueDatasetIteration' started at 2019-11-27 06:56:36.022
Test Case 'DatasetTests.testDoubleValueDatasetIteration' passed (0.002 seconds)
Test Suite 'DatasetTests' passed at 2019-11-27 06:56:36.024
	 Executed 9 tests, with 0 failures (0 unexpected) in 0.029 (0.029) seconds
Test Suite 'InitializerTests' started at 2019-11-27 06:56:36.024
Test Case 'InitializerTests.testInitializers' started at 2019-11-27 06:56:36.024
Test Case 'InitializerTests.testInitializers' passed (0.0 seconds)
Test Case 'InitializerTests.testFactoryInitializers' started at 2019-11-27 06:56:36.024
Test Case 'InitializerTests.testFactoryInitializers' passed (0.0 seconds)
Test Case 'InitializerTests.testNumericInitializers' started at 2019-11-27 06:56:36.024
Test Case 'InitializerTests.testNumericInitializers' passed (0.001 seconds)
Test Case 'InitializerTests.testScalarToTensorConversion' started at 2019-11-27 06:56:36.025
Test Case 'InitializerTests.testScalarToTensorConversion' passed (0.0 seconds)
Test Case 'InitializerTests.testArrayConversion' started at 2019-11-27 06:56:36.025
Test Case 'InitializerTests.testArrayConversion' passed (0.0 seconds)
Test Case 'InitializerTests.testDataTypeCast' started at 2019-11-27 06:56:36.025
Test Case 'InitializerTests.testDataTypeCast' passed (0.0 seconds)
Test Case 'InitializerTests.testBoolToNumericCast' started at 2019-11-27 06:56:36.026
Test Case 'InitializerTests.testBoolToNumericCast' passed (0.0 seconds)
Test Case 'InitializerTests.testRandomUniform' started at 2019-11-27 06:56:36.026
Test Case 'InitializerTests.testRandomUniform' passed (0.001 seconds)
Test Case 'InitializerTests.testRandomNormal' started at 2019-11-27 06:56:36.027
Test Case 'InitializerTests.testRandomNormal' passed (0.004 seconds)
Test Case 'InitializerTests.testRandomTruncatedNormal' started at 2019-11-27 06:56:36.031
Test Case 'InitializerTests.testRandomTruncatedNormal' passed (0.002 seconds)
Test Case 'InitializerTests.testGlorotUniform' started at 2019-11-27 06:56:36.033
Test Case 'InitializerTests.testGlorotUniform' passed (0.002 seconds)
Test Case 'InitializerTests.testGlorotNormal' started at 2019-11-27 06:56:36.036
Test Case 'InitializerTests.testGlorotNormal' passed (0.002 seconds)
Test Case 'InitializerTests.testOrthogonalShapesValues' started at 2019-11-27 06:56:36.037
Test Case 'InitializerTests.testOrthogonalShapesValues' passed (0.009 seconds)
Test Suite 'InitializerTests' passed at 2019-11-27 06:56:36.046
	 Executed 13 tests, with 0 failures (0 unexpected) in 0.022 (0.022) seconds
Test Suite 'LayerTests' started at 2019-11-27 06:56:36.047
Test Case 'LayerTests.testSequential' started at 2019-11-27 06:56:36.047
Test Case 'LayerTests.testSequential' passed (0.018 seconds)
Test Case 'LayerTests.testConv1D' started at 2019-11-27 06:56:36.064
Test Case 'LayerTests.testConv1D' passed (0.001 seconds)
Test Case 'LayerTests.testConv1DDilation' started at 2019-11-27 06:56:36.065
Test Case 'LayerTests.testConv1DDilation' passed (0.0 seconds)
Test Case 'LayerTests.testConv2D' started at 2019-11-27 06:56:36.066
Test Case 'LayerTests.testConv2D' passed (0.0 seconds)
Test Case 'LayerTests.testConv2DGradient' started at 2019-11-27 06:56:36.066
Exited with signal code 11
The command '/bin/sh -c /swift-tensorflow-toolchain/usr/bin/swift test' returned a non-zero code: 1

Investigation update for the curious.
This reproduces the segfault:
import TensorFlow

func testConv2DGradient() {
    let filter =  Tensor(shape: [3, 3, 2, 4], scalars: (0..<72).map(Float.init))
    let bias = Tensor<Float>(zeros: [4])
    let layer = Conv2D<Float>(filter: filter,
                              bias: bias,
                              activation: identity,
                              strides: (2, 2),
                              padding: .valid)
    let input = Tensor(shape: [2, 4, 4, 2], scalars: (0..<64).map(Float.init))
    let grads = gradient( at: input, layer) { $1($0).sum() }
}

testConv2DGradient()

The backtrace from lldb is
* thread #1, name = 'retain', stop reason = signal SIGSEGV: invalid address (fault address: 0x29)
  * frame #0: 0x00007ffff75a281a libswiftCore.so`swift_retain + 42
    frame #1: 0x00007ffff7b4ec00 libswiftTensorFlow.so`AD__$s10TensorFlow6Conv2DV14callAsFunctionyAA0A0VyxGAGF__vjp_src_0_wrt_0_1 + 128
    frame #2: 0x0000555555557561 retain`AD__$s6retain18testConv2DGradientyyF10TensorFlow0E0VySfGAF_AC0C1DVySfGtcfU___vjp_src_0_wrt_0_1 + 209
    frame #3: 0x00005555555570df retain`reabstraction thunk helper from @callee_guaranteed (@guaranteed TensorFlow.Tensor<Swift.Float>, @guaranteed TensorFlow.Conv2D<Swift.Float>) -> (@owned TensorFlow.Tensor<Swift.Float>, @owned @escaping @callee_guaranteed (@guaranteed TensorFlow.Tensor<Swift.Float>) -> (@owned TensorFlow.Tensor<Swift.Float>, @owned TensorFlow.Conv2D<Swift.Float>.TangentVector)) to @escaping @callee_guaranteed (@in_guaranteed TensorFlow.Tensor<Swift.Float>, @in_guaranteed TensorFlow.Conv2D<Swift.Float>) -> (@owned TensorFlow.Tensor<Swift.Float>, @owned @escaping @callee_guaranteed (@guaranteed TensorFlow.Tensor<Swift.Float>) -> (@out TensorFlow.Tensor<Swift.Float>, @out TensorFlow.Conv2D<Swift.Float>.TangentVector)) + 143
    frame #4: 0x00007ffff79f1f98 libswiftTensorFlow.so`reabstraction thunk helper <A, B, C where A: Swift.Differentiable, B: Swift.Differentiable, C: TensorFlow.TensorFlowFloatingPoint> from @callee_guaranteed (@in_guaranteed A, @in_guaranteed B) -> (@owned TensorFlow.Tensor<C>, @owned @escaping @callee_guaranteed (@guaranteed TensorFlow.Tensor<C>) -> (@out A.TangentVector, @out B.TangentVector)) to @escaping @callee_guaranteed (@in_guaranteed A, @in_guaranteed B) -> (@out TensorFlow.Tensor<C>, @owned @escaping @callee_guaranteed (@in_guaranteed TensorFlow.Tensor<C>) -> (@out A.TangentVector, @out B.TangentVector)) + 72
    frame #5: 0x00007ffff7b0830d libswiftTensorFlow.so`partial apply forwarder for reabstraction thunk helper <A, B, C where A: Swift.Differentiable, B: Swift.Differentiable, C: TensorFlow.TensorFlowFloatingPoint> from @callee_guaranteed (@in_guaranteed A, @in_guaranteed B) -> (@owned TensorFlow.Tensor<C>, @owned @escaping @callee_guaranteed (@guaranteed TensorFlow.Tensor<C>) -> (@out A.TangentVector, @out B.TangentVector)) to @escaping @callee_guaranteed (@in_guaranteed A, @in_guaranteed B) -> (@out TensorFlow.Tensor<C>, @owned @escaping @callee_guaranteed (@in_guaranteed TensorFlow.Tensor<C>) -> (@out A.TangentVector, @out B.TangentVector)) + 93
    frame #6: 0x00007ffff74971f1 libswiftCore.so`Swift.valueWithPullback<A, B, C where A: Swift.Differentiable, B: Swift.Differentiable, C: Swift.Differentiable>(at: A, _: B, in: @differentiable (A, B) -> C) -> (value: C, pullback: (C.TangentVector) -> (A.TangentVector, B.TangentVector)) + 113
    frame #7: 0x00007ffff79f1a04 libswiftTensorFlow.so`TensorFlow.valueWithGradient<A, B, C where A: Swift.Differentiable, B: Swift.Differentiable, C: TensorFlow.TensorFlowFloatingPoint>(at: A, _: B, in: @differentiable (A, B) -> TensorFlow.Tensor<C>) -> (value: TensorFlow.Tensor<C>, gradient: (A.TangentVector, B.TangentVector)) + 1220
    frame #8: 0x00007ffff79f2c69 libswiftTensorFlow.so`TensorFlow.gradient<A, B, C where A: Swift.Differentiable, B: Swift.Differentiable, C: TensorFlow.TensorFlowFloatingPoint>(at: A, _: B, in: @differentiable (A, B) -> TensorFlow.Tensor<C>) -> (A.TangentVector, B.TangentVector) + 617
    frame #9: 0x000055555555674a retain`retain.testConv2DGradient() -> () + 2122
    frame #10: 0x0000555555555ef4 retain`main + 20
    frame #11: 0x00007fffed14a52b libc.so.6`__libc_start_main(main=(retain`main), argc=1, argv=0x00007fffffffde68, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffffffde58) at libc-start.c:308:16
    frame #12: 0x0000555555555c3a retain`_start + 42

The only SIL differences that this PR causes on this code are:

Declarations for differentiability witnesses of Tensor<>.sum(), Conv2D.callAsFunction(:), and identity(:) appear.
A few function_refs turn into differentiability_witness_functions.

It's pretty surprising that this affects memory management.
Current ideas of what might be going on:

IRGen for differentiability_witness_functions does something improper with ownership. (Seems unlikely because these function pointers should be trivial.)
There's some latent nondeterministic memory management issue that suddenly popped up.

Next, I'm going to carefully read through the SIL to see if I see anything suspicious in it.

I think I solved it. I uploaded a commit, and I'm going to run all the tests now.
This is the problem:
// If the witness is a declaration, then LoadableByAddress cannot have changed
// the type because the function is in a different module.
if (instr->getWitness()->isDeclaration())
  return true;

The comment is false. LoadableByAddress can change the type of a function in a different module because pre-LoadableByAddress SIL references the pre-LoadableByAddress versions of external functions.
So I have fixed it by making LoadableByAddress work on external differentiability witnesses.
I have also added a cross-module LoadableByAddress test.
While writing the test, I realized that we didn't have print/parse/serialization/deserialization for differentiability_witness_functions with explicit types, so I added all that too.

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

This is really awesome. Thank you Marc!

@swift-ci Please test tensorflow

@swift-ci Please test tensorflow

@swift-ci Please test tensorflow

The comment is false. LoadableByAddress can change the type of a function in a different module because pre-LoadableByAddress SIL references the pre-LoadableByAddress versions of external functions.
So I have fixed it by making LoadableByAddress work on external differentiability witnesses.
I have also added a cross-module LoadableByAddress test.

Nice! differentiability_witness_function verification isn't defined yet, oops - it seems like verification should've caught this error?
https://github.com/apple/swift/pull/28501 to apple:marcrasi-use-diff-witness adds SILVerifier::checkDifferentiableFunctionWitnessInst.

@swift-ci Please test tensorflow

Merging now! Verified that the extended test suite (tensorflow/swift-apis, etc) passes.


Examples of correct and incorrect code

I find myself very often searching for examples online, since TSLint's docs are lacking them. For TSLint to be useful, one must know what its rules are about, and this is currently not provided by the documentation alone.
The ESLint team did a great job in this regard, and I think you should take inspiration from them, e.g. https://eslint.org/docs/rules/no-empty.
If this is not under consideration already, please consider it 🙂

Closing as a duplicate of #1329
For the time being the easiest way to understand a rule is to look at the tests.

Thanks for the housekeeping efforts, and sorry for the duplicates.

Actually, can you guide me a bit on how to understand the tests? They are somewhat cryptic.

The test consist of different line types:
Code lines everything that is not listed below.
Message substitution (or template)
[name]: message are typically located at the bottom of the file. They define names that can be reused in error markup
Error Markup
~~~~~ [error message] the squiggles are located below a code line at the position the error is shown. The error message is either the real message or the name of a message substitution.
~nil means the error has a width of 0.
~~~ or ~nil without an error message indicate an error that continues on the next line.
[foo % ('a', 'b')] interpolates the strings a and b into the message substitution identified by foo. The substitution is done by node's util.format.
Example:
foo(b);
    ~ [err % ('a', 'b')]
eval('some code');
~~~~~~~~~~~~~~~~~ [Usage of 'eval' is forbidden.]

[err]: Use '%s' instead of '%s'.

The above means there is an error Use 'a' instead of 'b'. on the first line at the identifier b.
There's also an error on the eval() call. That message is not substituted.

the testing markup is documented here: https://palantir.github.io/tslint/develop/testing-rules/

Thanks to both :smile:


Fix forcerename tracking wrong username

Prior to this, the forcerename command would wrongfully display (forcerenamed from Guest [number])

The build fails with the following error:
/home/travis/build/Zarel/Pokemon-Showdown/server/users.js
  945:1  error  Trailing spaces not allowed  no-trailing-spaces

Remove trailing spaces on line 945.


SyntaxError

https://github.com/GRAAL-Research/deepparse-address-data/blob/41e695f399260deb2cf572f8af3b2a6ba0b9f07c/lzma_decompress.py#L48

Thank you for the fix @RoTorEx.
Your pull request has been merged!


How to load note sequence before playing

I am playing note sequence using for loop, below is my code.
function play(){
for (var i=0;i<=1;i++)
{
for (var j=0;j<=32;j++)
{
	if(composition[i][j]!=40)
      {
		MIDI.noteOn(0, composition[i][j], velocity, delay);
       }
	else if(composition[i][j]==40)
       {
		 MIDI.noteOff(0, composition[i][j],velocity, delay);
        }

delay=delay+0.1;
}
}
}

When function play() is called, it do not play sequence of note from "for" loop with correct delay.
If I just put "alert("xyz"), after initialization of "composition[][]" array & before "for" loop, just to get time before starting loop. If I wait some time & release the alert, note sequence get played correctly.
Is there way to first load sequence before starting. I am not hardcore developer, detail answer with example will be great help.

I see some questions are answered recently, can anybody please guide me.
i am getting note sequence in table, & then converting table values in 2D javascript array & then trying to play it but not getting correct timing if I do not use alert to get stop execution for some time.


fix: Add a runtime dependency

Defining runtime dependency for @codecademy/tracking
Saw error in consumer build system:
'@babel/runtime/regenerator' is imported by<EMAIL_ADDRESS>but could not be resolved – treating it as an external dependency
No name was provided for external module '@babel/runtime/regenerator' in output.globals – guessing '_regeneratorRuntime'

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Judah Anthony seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

📬Published Alpha Packages<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://5f933b37c7fa31492e11a582--gamut-preview.netlify.appDeploy Logs