Verify CSRF

Send with Apollo mutations, have server verify it (e.g., remove protect_from_forgery with: :null_session).

Finished by #9.


Update for DIP-163

Summary
DIP-163 (https://github.com/LibertyDSNP/spec/pull/163) Now has published as a required field. We need to make it required.
Abstract
See https://github.com/LibertyDSNP/spec/pull/163
Specification
Note published field is now required
Copyright
Copyright and related rights waived via CC0.

Superseded by #19


impl Eq,Debug,Show for Map #501

close: #501
Changed:

API changed to impl debug, moved debug_linked_list from linkedhashmap.mbt to debug.mbt and renamed. The result are also changed (more in test) to make hte type checking happy. This implement Show and Debug trait.

// fn debug_linked_list[K : Show, V : Show](self : Map[K, V]) -> String {
pub fn to_string[K : Debug, V : Debug](self : Map[K, V]) -> String {

// to debug.mbt
pub fn debug_write[K : Debug, V : Debug](
  self : Map[K, V],
  buf : Buffer
) -> Unit {

Eq:

check size
from head to tail, both the idx(not sure about this), and the K, V should be the same, then we call them equal.

Pull Request Test Coverage Report for Build 1632
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 88.413%

Totals

Change from base Build 1630:
0.0%

Covered Lines:
2434

Relevant Lines:
2753

💛  - Coveralls

Pull Request Test Coverage Report for Build 1633
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 88.413%

Totals

Change from base Build 1630:
0.0%

Covered Lines:
2434

Relevant Lines:
2753

💛  - Coveralls

I think the to_string method should return something like {key1: value1, key2: value2}

Pull Request Test Coverage Report for Build 1636
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

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

Totals

Change from base Build 1630:
0.3%

Covered Lines:
2615

Relevant Lines:
2947

💛  - Coveralls

Thank you for your review! The necessary updates have been made.

Pull Request Test Coverage Report for Build 1637
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 88.734%

Totals

Change from base Build 1635:
0.0%

Covered Lines:
2615

Relevant Lines:
2947

💛  - Coveralls


Fancy Zones: option for hotkey assignment to move window to specific fancy zone

Provide a description of the new feature / enhancement
currently you can only use the windows hotkeys (win+left, win+right) to move/cycle windows through fancy zones. it would be nice to allow assign hotkeys to move the active window to specific fancy zone.

@igpit
this is tracked in https://github.com/microsoft/PowerToys/issues/492


Add dropdown menu to wen.tools with the links to wallet.wen.tools and swap.wen.tools added

Add dropdown menu to wen.tools with the links to wallet.wen.tools and swap.wen.tools added

could also change the anchor to  horizontal: 'left', instead so the menu appears directly underneath the button

Task was completed prior to this PR


Data lost when I use the custom Metrics

Runtime version :

.Net 5.0
Microsoft.ApplicationInsights: 2.18.0

Hosting environment: Windows

We are using custom Metrics to track our build data, here is our code, let's take the BuildLog metrics as a sample, in one round build of the repository, there are about 109k entries, and from the request, we catch by fiddler, there are 3 API calls, and totally about 1.3k aggregated entries in the API calls, and the sum of all the aggregated metrics value is about 16k.
and the tracked value is different each time we run our application(we have made sure that we generate the same data each time).
So does that means our metrics data has been sampled? if so is there any way to disable the sampling?

There is no sampling for Metrics, but you might be hit with capping issues.
Could you check dimension capping https://docs.microsoft.com/en-us/azure/azure-monitor/app/get-metric#dimension-and-time-series-capping ?

Great! Thanks @cijothomas, that helps.


Add Review List Component for Dynamic Page

Description
This PR introduces a new Review List component that renders a list of user reviews on dynamic pages. Each review includes the rating, comment, and other relevant details.
Type of Change

[x] New feature (non-breaking change which adds functionality)

Checklist

[x] The Review List component is tested and displays reviews correctly
[x] Code is properly documented and follows project standards
[x] Component is responsive and integrates well with other dynamic page elements

Related Issues
N/A
Additional Information
This component will dynamically display reviews submitted by users and can be expanded to include features like pagination or review filtering in future updates.

:tada: This PR is included in version 1.52.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


feat: direct child task calls and list-all

Description
Allows you to directly call tasks from included file and adds --list-all flag which lists all tasks including tasks from external files that are being included.
Related Issue
Relates to uds-cli #441 #325

Great work on this! I think there are some opportunities to finally refactor some of this code out of runner.go, happy to pair on that. Other general feedback is to see if we break up some of the more complex/nested logic into functions


Add LenExpr to the ast walker

walkExpr gets confused now that len() is part of the language itself instead of a builtin; this fixes the problem.

Codecov Report

Merging #169 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #169      +/-   ##
==========================================
- Coverage   76.53%   76.51%   -0.03%
==========================================
  Files          40       40
  Lines        2779     2780       +1
==========================================
  Hits         2127     2127
- Misses        521      522       +1
  Partials      131      131

Impacted Files
Coverage Δ

ast/util/walk.go
16.76% <ø> (-0.11%)
:arrow_down:

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 083978e...95973ae. Read the comment docs.

Could you please add test?

PTAL, I have added a test that looks for lenexpr

merged https://github.com/mattn/anko/pull/171


Synchronization primitives for ARMv5 assembler

For atomically updating object headers in generated code, ARMv5 needs the now-deprecated 'swp' instruction, which is not yet implemented in the assembler.
For now, we'll just assert that we're running on a single core when the target is ARMv5.

The assert remains in place and concurrent worker threads are disabled on ARMv5. In addition, we have no customers using multiprocessor ARMv5 hardware.


Update veeam-backup-and-replication.md

Adding 12.1 release information. EoL date appears to be same as 12.0 per https://www.veeam.com/product-lifecycle.html

@marcwrobel Thanks for the reply and consideration. I think there is value to report the version. Maybe need to document 11a to be consistent?

@marcwrobel added a commit to include 11a release to be more consistent. Do not believe this is much additinoal effort to track currently.

Thought about it again an I am not a big fan of adding those versions:

If 12 has been superseeded by 12.1 (as we can see it on https://www.veeam.com/kb4420), this means 12 is EOL and 12.1 must be used instead (the same applies to 11a).
But considering only 12 is mentioned on https://www.veeam.com/product-lifecycle.html, this means the 12 cycle is still supported, but with 12.1 has its latest version.

So I think it would make more sense to add those 12.1 / 11a (and other if needed) as latest releases of their respecting major version. WDYT ?

@marcwrobel OK. I can agree with adding 12.1 / 11a (and others as needed) as the major version. I updated the file / PR accordingly.

@marcwrobel OK. I can agree with adding 12.1 / 11a (and others as needed) as the major version. I updated the file / PR accordingly.

That's not what I had in mind : I was thinking of starting to document latest releases. The release cycle must continue to match what's visible on https://www.veeam.com/product-lifecycle.html IMO.

@marcwrobel May you provide an example of what you had mind? I think that will help. Thank you.

@adrianwells this is what I meant: https://github.com/endoflife-date/endoflife.date/pull/4493 (preview available on https://deploy-preview-4493--endoflife-date.netlify.app/veeam-backup-and-replication).
I also added some automation based on https://www.veeam.com/kb2680 in https://github.com/endoflife-date/release-data/pull/280.

@marcwrobel Thank you for the example. This seems like a good improvement.

Ok, closing this PR in favor of #4493 then.


Incorrect formatting when reordering module declarations

This:
pub mod a; // a
pub mod c; // c
pub mod b; // b

Gets formated to:
pub mod a; // a
pub mod b;
pub mod c; // c // b

Using cargo fmt.
cargo 1.57.0 (b2e52d7ca 2021-10-21)
rustfmt 1.4.37-stable (f1edd04 2021-11-29)
found by @Patiga

Thanks for the report!
I can confirm that I can also reproduce the error on rustfmt 1.4.38-nightly (5056f4cf 2022-01-05).
This is a bit of a tricky one because comments aren't explicitly represented in the ast that rustfmt uses to reformat your code. Here's a high level overview of what's happening:
When going to rewrite and reorder the modules the Span starts from the start of the first module to the end of the last module. Because the trailing comments for mod a and mod c are within this span we find them easily, but we don't pick up on the trailing inline comment for mod b.
| start here
v
pub mod a; // a
pub mod c; // c
pub mod b; // b
         ^
         | end here

Mentally You can think that rustfmt is grouping each mod with it's associated post comment (except for the last one because it's outside the span). Here's what those groups would look like:
pub mod a; // a | <-- end of item 1
pub mod c; // c | <-- end of item 2
pub mod b; | <--end of item 3 (remember we don't know about this comment because it's outside the span)

Then rustfmt reorders and writes the modules:
pub mod a; // a
pub mod b;
pub mod c; // c

And lastly, rustfmt checks to see if there were any trailing comments that it might have missed and that's when it appends // b to the end of the now shuffled mod items because at that point there's no context that the trailing comment used to be associated with mod b.
pub mod a; // a
pub mod b;
pub mod c; // c // b

I hope that explanation of the issue helps! I've started looking into this, and I have a few ideas of how we might solve it, but I'll need a little more time to work out issues and fully test what I'm thinking!

In case anyone else wants to give this a go the Span I described above is located on Line 293 when calling FmtVisitor::walk_reorderable_or_regroupable_items, and what the fix will ultimately come down to is finding a reliable way to extend the span past any trailing comments.
https://github.com/rust-lang/rustfmt/blob/5056f4cfb311a084420f1828cd58af94d143f5e0/src/reorder.rs#L290-L300

Is this a duplicate of existing issues, e.g. #4027?

Yup, looks like this is a duplicate

Going to close in that case to try to avoid dialog getting split across too many issues


Unable to undo changes using ctrl + z after toggling to another file..

monaco-editor version: 0.X.Y
Browser:
OS:
Steps or JS usage snippet reproducing the issue:
step 1 : go to some file i.e [file1] and do changes here
step 2 : go to another file i.e [file 2] and do some changes here
step 3 : go back to file1 and use ctrl + z. unable to undo changes

i dont see any method like undo() or redo() or saveViewState() or restoreViewState()

@manideepmothe641 Please see how the playground is implemented at https://microsoft.github.io/monaco-editor/playground.html
That shows an example of having tabs, and multiple models (one model per tab) and calling editor.saveViewState(), editor.setModel(), editor.restoreViewState().


Question: Dynamic weight in contracted mode

Hi, itinero is nice project and very help me with my problems.
I'm trying to make routing with traffic jam. With my own implement of WeightHandler. It's works fine without contacted mode, i can easily get edge id and edge profile id. But in contacted mode, graph is different, and edges ids is different too. How can i convert contracted edge to obvious edge? Is this possible?

i use ExpandEdge, that is DirectedMetaGraph extension, maybe this help someone

This is not possible with the current implementation of contraction hierarchies. We do plan a solution for this using customizable contraction hierarchies but we can't really say yet when we have this done.


Update documentation for Workspace names to reflect in-place upgrades of MRC, MRS, MRS-SQL

There are three Microsoft R Client flavors:

Microsoft R Client
Microsoft R Server
Microsoft R Server for SQL Server

These all upgrade in-place. Therefore, we will always update the name with the name of the newer version that was just installed regardless of whether the user changed the name. Update the documentation to reflect this.

Names changed again... We may want to re-file this in docs repo.


Schedule Steel House trip to Hurricane

Coordinate with development to find a time for Steel House community visit to island.

Discussed at 7/22 Research-Advancement meeting. NK sent invitation for August 9 workshop same day.


[docs] Add documentation for the assets directory

The readme does not mention or explain the assets directory like it does with all the other root directories.
We should update this to be documented and explain how to properly use and organize assets.

Hi @frankcalise, first and foremost enjoying the React Native Radio 📻, Could I pick this issue up and have away?

@jvm-cognition Glad you liked the podcast!
Yes of course, we would certainly appreciate the contribution.


Get a PDO instance ... error

@dereuromark i've never had this problem before, but since I upgrade from 2.0.0-alpha11 to dev-master, I get this error, each times I try to get an instance of pdo :
.... __construct() must be an instance of PDO, instance of Propel\Runtime\Connection\PdoConnection given.
So to extract the instance I use the code below
 // new way to manage events
        // we get the PDO for the Sabre connection from the Propel connection
        $pdo = Propel::getConnection();

        // We set the BackEnd for sabre Backends
        $calendarBackend = new CalDavPDO($pdo->getWrappedConnection());

CalDavPDO is a class that use sabre.io
Could you give me an advice to solve the problem ?
Thank's a lot and sorry for my poor english level.

https://github.com/propelorm/Propel2/compare/2.0.0-alpha11...master#diff-65b0c78ee5e492f02556b3ef9878fa06d609655a8eded21f4cee6f6393256c3dL18
You will see that in order to be PHP8 ready, the next release will have to use an interface contract and proxy into PDO instead of just extending it.
This can have some minor BC breaking impact for e.g. your use case.
Are you able to fix up your code accordingly?

@dereuromark How could I get the pdo interface, I always find problems with mixing sabre pdo code with propel.
I can make it work, but sometimes I've to mix sabre code with propel code and the code isn't synchronized between the two interfaces.

Do you have any suggestions or a PR on what could be improved here?
We plan to do a final release soon.

Do you have any suggestions or a PR on what could be improved here?
We plan to do a final release soon.

I finally find a "workaround" and it's working, but I'm not really satisfied with this solution.

I finally find a "workaround" and it's working, but I'm not really satisfied with this solution.

Do you want to elaborate a bit more?
Or shall we close this topic then?

Do you want to elaborate a bit more?
Or shall we close this topic then?

Since there is no further regression or php8 issues, I will close this now
The changelog will outline the changes regarding this BC breaking topic on release then.

Since there is no further regression or php8 issues, I will close this now
The changelog will outline the changes regarding this BC breaking topic on release then.


[BUG]: Jupyter help magic unconverted unicode character

When using jupyter help magic (?), the output gets messed up, since jyputer internally wraps unicode characters around parts of the output to format it.
I think this is why it is also excluded when setting nbsphinx_execute = "always".
The problem should be solvable with a re.sub().
Expected/Notebook render:

Actual render HTML:

Actual render PDF:

Json representation of the cell:
{
   "cell_type": "code",
   "execution_count": 4,
   "metadata": {
    "tags": [
     "nbval-ignore-output"
    ]
   },
   "outputs": [
    {
     "data": {
      "text/plain": [
       "\u001b[1;31mDocstring:\u001b[0m\n",
       "%%bash script magic\n",
       "\n",
       "Run cells with bash in a subprocess.\n",
       "\n",
       "This is a shortcut for `%%script bash`\n",
       "\u001b[1;31mFile:\u001b[0m      c:\\anaconda3\\lib\\site-packages\\ipython\\core\\magics\\script.py\n"
      ]
     },
     "metadata": {},
     "output_type": "display_data"
    }
   ],
   "source": [
    "%%bash?"
   ]
  },

OS: Windows 10
Version: nbsphinx==0.4.2

Thanks for the report!
I've known this problem for quite some time already and I've even started working on it on the
https://github.com/spatialaudio/nbsphinx/compare/ansi-in-text branch (but I think this was the wrong approach).
I hope I can finish this at some point ...

I think this is why it is also excluded when setting nbsphinx_execute = "always".

Those outputs are generated by JupyterLab.
They are apparently not generated by the Classic Notebook nor by nbconvert --execute (which is used in nbsphinx).
It's good to see that more people are using JupyterLab and that this problem is finally reported!

Unrelated to this issue: I've noticed spurious scroll bars (or rather scroll buttons) in your HTML screenshot.
I normally don't see those, do you also see them on https://nbsphinx.readthedocs.io/en/0.4.3/code-cells.html?
Which browser are you using?
Do you have an idea how to get rid of them?

The scrollbars are only shown Chrome (not in FireFox) and are displayed due to an overflow caused by sphinx-copybutton for single line of code cells.
Still need to investigate, which css 'clash' causes it.

After some playing around, the following scss fixed the issue for me:
div.nbinput div.input_area,
div.nboutput div.output_area {
  padding: 0 !important;
}
div.nbinput,
div.nbinput div.prompt,
div.nbinput div.input_area,
div.nbinput div[class*="highlight"],
div.nbinput div[class*="highlight"] pre,
div.nboutput,
div.nbinput div.prompt,
div.nbinput div.output_area,
div.nboutput div[class*="highlight"],
div.nboutput div[class*="highlight"] pre {
  padding: 0.2em !important;

  a.copybtn {
    width: 0.8em;
    height: 0.8em;
  }
}

a.copybtn {
  padding: 0;
}

compiled css version:
div.nbinput div.input_area,
div.nboutput div.output_area {
  padding: 0 !important;
}

div.nbinput,
div.nbinput div.prompt,
div.nbinput div.input_area,
div.nbinput div[class*="highlight"],
div.nbinput div[class*="highlight"] pre,
div.nboutput,
div.nbinput div.prompt,
div.nbinput div.output_area,
div.nboutput div[class*="highlight"],
div.nboutput div[class*="highlight"] pre {
  padding: 0.2em !important;
}

div.nbinput a.copybtn,
div.nbinput div.prompt a.copybtn,
div.nbinput div.input_area a.copybtn,
div.nbinput div[class*="highlight"] a.copybtn,
div.nbinput div[class*="highlight"] pre a.copybtn,
div.nboutput a.copybtn,
div.nbinput div.prompt a.copybtn,
div.nbinput div.output_area a.copybtn,
div.nboutput div[class*="highlight"] a.copybtn,
div.nboutput div[class*="highlight"] pre a.copybtn {
  width: 0.8em;
  height: 0.8em;
}

a.copybtn {
  padding: 0;
}

Haven't found any buggy outputs for that yet.
Note: The !important is to overwrite the css from nbsphinx.

@s-weigand Thanks for the work-around. I've created #333, hoping that we can solve this without having to add a ton of CSS stuff to each project.

@s-weigand I've taken a stab at the original issue: #348.
There is still a problem, though. If you have an idea how to solve this, please comment over there.

@s-weigand OK, I've tried another approach: #351. Can you please check if that works for you?


Unify include paths for headers between core, internal plugins, and external plugins.

Updated based on feedback

include/ts for C API headers.
include/tscpp for C++ API headers (link with libtscpp.so)
include/tsutil for C++ utility headers (link with libtsutil.so)

lib/ts is moved to lib/tscore which builds the libtscore library. A new directory, "lib/tsutil", is created for "dual use" utility C++ headers which builds libtsutil. These are headers used in the TS core and intended to be available to plugins. The goal of this restructuring is to unify include paths for core, internal plugins, and external plugins. That in turn enables exporting the dual use utility headers such as TextView.h. With the include paths the same, secondary includes will work as expected.
This only moves the installed version of TextView.h to include/tsutil as a demonstration and to validate the feasibility of making the move. This current structure is the result of many discussions on this PR, the mailing list, and the IRC channel.
UPDATE
All references to "atscppapi" have been changed to "tscpp". This includes the library name and the internal library namespace. The "README` file in this PR has been updated to reflect the re-arrangement.

ts/... : C API functions.
tscpp/... : C++ API functions.
tsutil/... : Internally used utilities not dependent on TS specifically.
tscore/... : Internal use only libraries.

These paths become the same for core and plugins so that internal plugins have less of a privileged position over external plugins and serve as better examples for plugin developers.
lib/ts was split into libtscore and libtsutil so that the dual use headers were in a separate library than the purely core headers. This was recommended by both @bryancall and @dragon512.
Key issues to handle for exporting dual use C++ headers -

The include path for a given header (e.g. TextView.h) must be the same between the core and a plugin because of headers including other headers.
Care must be taken to not impose core based requirements on plugins (e.g., not using assert at all).
I would like to minimize the number of -I include options on the compiler line. Relatedly, having include paths that have semantic meaning would help ease the pain of them being longer.
Avoid having "magic" or other "don't really include this" headers. Dual use headers need to not drag in other entangled headers. Let's not be Boost.

I disagree about having all of the C++ headers in a single directory. Bryan and I touched on this in our IRC discussion and I've become more convinced that splitting is the correctly approach. Among many other reasons, one issue is "I've included header leif.h. Do I need to link to a library too?". In the proposed scheme, if the header is in src/api/core, you don't. If it is in src/api/tscpp you do and the library is libatscppapi.so.

This doesn't fall with the standard way of laying out source code.  Normally external headers go into an include directory at the top level (e.g. include/ts & include/tscpp).

The standard way to layout headers is to have you stuff under a directory so you have to say
#include "dir/header"
This proposal means we have a clear
#include "api/tscpp/header.h"
#include "api/ts/ts.h"
#include "ts/ts.h"
and all you have in our build for include path is ./src
the dev package/ install move headers under a include directory with the same source layout

What I would propose would be:
It would change to:
lib/cppapi/include/atscppap moves to include/tscpp and would be installed at /usr/local/include/tscpp
proxy/api/ts moves to include/ts and would be installed at  /usr/local/include/ts
Rename lib/ts to lib/ats so it doesn't conflict with the external api directory.
There would be one library for cpp APIs (e.g. TextView & Url) would change to:
/usr/local/lib/libtscpp.so
And this is how you would include headers:
#include "ats/ink_time.h" - internal C
#include "ats/Regex.h" - internal C++
#include "ts/ts.h" - exernal C API
#include "tscpp/TextView.h" - external C++ (also used internally)
#include "tscpp/Url.h" - external C++ API

So the current release (which @bryancall makes a great point on as we are about to release) I am good with @bryancall proposal. I still believe that it will be better long term to move code under src/

[approve ci autest]

The goal of the way this PR was set up was precisely to provide for gradual movement during the 8.0 lifetime. The net effect of this PR is to create some directories and move 3-4 header files. That is as minimally disruptive as possible, IMHO, to achieve the stated goal.
"There would be one library for cpp APIs (e.g. TextView & Url)"
That is not possible without some major restructuring. At minimum almost everything would have to link with libtsutil and libtscpp instead of just the former. We would also be linking in the pure CPPAPI code which is currently not anywhere in the core. Even if were willing to do that, then it be much better to not have that code talk back through the C API but directly interact with the core. If this is a real problem then we should put the dual use headers in the C API directory because the linkage for them for a plugin is identical to that of the C API.
I am fine with using a top level include as suggested.

I think we should change lib/ts to lib/tsutil so that libtsutil.so is compiled in lib/tsutil.  Then we can just directly export headers from there to install/include/tsutil in parallel with include/ts and include/tscpp. In addition to distinguishing based on linkage, this would also separate pure utility classes in tsutil from API related classes in tscpp and ts.

I updated the main comment. As noted I had two people push for putting the dual use headers in a separate library. I named that "libtsutil" because it's the utility library. The former "libtsutil" was moved to "libtscore" and put in "lib/core". Plugins don't need to link with "libtsutil" as that is pulled in by the traffic_server binary but it can be used to do linkage verification during build rather than after installation.

[approve ci autest]

[approve ci autest]

[approve ci autest]

[approve ci autest]

[approve ci autest]

[approve ci autest]

I was talking to @SolidWallOfCode  about this some more. I know one of the issues I deal with is that I cannot install different versions of ATS in a unified tree structure that is default for most Linux distros.
I would suggest a layout such as ( ie what we see on install)
.../include/trafficserver7/api/c/plugin
/util
/c++/plugin
/util
This allow user to:

install ats 7 and 8 on the same distro in a unified directory layout and have it work
dev can decide if the just include <api/c/plugin/ts.h> or if they want to say <trafficserver7/c/api/ts.h>
we have a clear layout for adding new API for stuff such as Lua or python or Go
we have a clear understanding if the header is part of the internal <core/??.h> vs <api/C++/ts.h>

If I were doing this today...

install ats 7 and 8 on the same distro in a unified directory layout and have it work

configure --prefix=/path/for/ts7 or configure --prefix=/path/for/ts8

dev can decide if the just include <api/c/plugin/ts.h> or if they want to say <trafficserver7/c/api/ts.h>

Dev should use the appropriate tsxs to build their plugin: the one found in /path/for/ts7 or /path/for/ts8. Those know where to find the correct headers.
I am inclined to think that the problem of installing two ATS versions side-by-side is for packaging to fix, not build. In that case it is solved outside the ATS source. But maybe I'm missing something where we hard-code paths.

@d2r - the problem there is that you really want the version directory in the middle of the paths, not the front. E.g.

/usr/include/ts7/...
/usr/lib/ts7/...
/usr/bin/ts7/...

rather than (which actually, is how I do it)

/opt/ats7/include/...
/opt/ats7/lib/...
/opt/ats7/bin/...

Overall, though, I agree it is primarily a packaging problem, not a code problem.

@d2r - the problem there is that you really want the version directory in the middle of the paths, not the front. E.g.

Ah I see. Why do I want this?

Because you would like to have the files in the normal places, rather than gathered off to the side in an obscure place. E.g. binaries under "/usr/bin", log files in "/var/log/...", libraries in "/usr/lib/...", etc.

Because you would like to have the files in the normal places, rather than gathered off to the side in an obscure place. E.g. binaries under "/usr/bin", log files in "/var/log/...", libraries in "/usr/lib/...", etc.

OK. I thought configure could do this now. And for plugin building, I thought tsxs used the same paths.
$ ./configure --help
...
By default, `make install' will install all the files in
`/usr/local/trafficserver/bin', `/usr/local/trafficserver/lib' etc.  You can specify
an installation prefix other than `/usr/local/trafficserver' using `--prefix',
for instance `--prefix=$HOME'.

For better control, use the options below.

Fine tuning of the installation directories:
  --bindir=DIR            user executables [EPREFIX/bin]
  --sbindir=DIR           system admin executables [EPREFIX/sbin]
  --libexecdir=DIR        program executables [EPREFIX/libexec]
  --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]
  --sharedstatedir=DIR    modifiable architecture-independent data [PREFIX/com]
  --localstatedir=DIR     modifiable single-machine data [PREFIX/var]
  --libdir=DIR            object code libraries [EPREFIX/lib]
  --includedir=DIR        C header files [PREFIX/include]
  --oldincludedir=DIR     C header files for non-gcc [/usr/include]
  --datarootdir=DIR       read-only arch.-independent data root [PREFIX/share]
  --datadir=DIR           read-only architecture-independent data [DATAROOTDIR]
  --infodir=DIR           info documentation [DATAROOTDIR/info]
  --localedir=DIR         locale-dependent data [DATAROOTDIR/locale]
  --mandir=DIR            man documentation [DATAROOTDIR/man]
  --docdir=DIR            documentation root [DATAROOTDIR/doc/trafficserver]
  --htmldir=DIR           html documentation [DOCDIR]
  --dvidir=DIR            dvi documentation [DOCDIR]
  --pdfdir=DIR            pdf documentation [DOCDIR]
  --psdir=DIR             ps documentation [DOCDIR]

So I'd expect things like --includedir=/usr/include/ts7 to work. But maybe they don't or it is not sufficient?

That could be done, it just seems a bit painful for the common case.

That could be done, it just seems a bit painful for the common case.

I assumed installing two different versions of ATS on the same system was an uncommon case.
Otherwise it seems like we have already a solution for this—and unless I am missing something—if things aren't working properly the challenge is more likely one for packaging to solve.

This has nothing to do with autoconf.
This has to do with support a layout and source layout so:
headers map the same way for our source tree and what is install by default not matter what layout if uses.
This has nothing to do with the libs.. this is only headers. The libs are already versioned. the headers have no version seperatation. This is also about having this options for the install when using a unifed layout. The "opt" layouts don't need to have a include/ts7/... however the layouts such as GNU or OpenBSD or Arch ( which distros would use) do.
The only "other" questions is should we have an install options to change trafficserver to trafficserver-7 or trafficserver-8 and have a symlink for which tarfficserver is used.
This allows us and mroe importantly linux distros a way to support more than one trafficserver install at a time. This allows an easy way for customer to migrate and use trafficserver.
Yes people can do "custom" builds and installs. however this is not what we want to do to grow users. we have to make it easy for them to get what they need without making customs builds/package/installs of our code. It should just work.

headers map the same way for our source tree and what is install by default not matter what layout if uses.

Could you elaborate? What's meant by "map the same way" and what does it accomplish?

This has nothing to do with the libs.. this is only headers. The libs are already versioned. the headers have no version seperatation. This is also about having this options for the install when using a unifed layout. The "opt" layouts don't need to have a include/ts7/... however the layouts such as GNU or OpenBSD or Arch ( which distros would use) do.

OK just headers then. But I am puzzled because this seems to be exactly what e.g. configure --includedir=/usr/local/include/ts7 is for. It lets us override the default location which sounds like what we want to do. If that's what we want to do, then we can just build that way and package.

This allows us and mroe importantly linux distros a way to support more than one trafficserver install at a time. This allows an easy way for customer to migrate and use trafficserver.

Well if I am not mistaken, we don't support rolling upgrades of a single system. What kind of migration are we supporting in this sense?

I don't think it is a good idea to include the version numbers in the paths by default (e.g. /include/trafficserver7/api/c/plugin).  If a user wants to override the prefix and use something like /opt/ats7 they can.  Most open source project don't do this and I don't see a real world case where you would want to run two different major version of ATS on the same server.

If we're talking about include paths, we're not talking about production machines. Those should not have the include files installed. Therefore this is about build and development machines, which are quite likely to have different versions installed simultaneously. For instance, Walt is right now working on a bug which requires him to build a plugin under 5 and 7. I think yinst does the high level directory technique under the hood to maintain multiple versions, but we're moving to RPMs and that's a bit harder to do with those. The root question is whether default built images of TS should support side by side installs of the development environment. If not, should it be easy to do that by inserting a directory in the path so the side by side can be in the "standard" directory area, rather than forced off to a non-standard base directory.

For instance, Walt is right now working on a bug which requires him to build a plugin under 5 and 7. I think yinst does the high level directory technique under the hood to maintain multiple versions

Specifically to these statements, I think only one is active at a time. I am familiar with the package manager and plugin that Walt is working on now, and I have previously worked on the same plugin in the same use case several times. If I wanted to switch from 5 to 7, I remove ATS 5 and install ATS 7, clean, and rebuild. Both at the same time does not make sense to me. But at least I can say it is not necessary to do the work.

Therefore this is about build and development machines, which are quite likely to have different versions installed simultaneously.

I have never needed to do this. In fact I actively avoid doing it. This is the first time I remember hearing of anyone trying it.

I don't see any argument made against this minus "I don't get it."
A large number of projects do this stuff. They allow for more than one version of the tool to be install and compiled against.
Examples are( just a simple scan of some stuff on ubuntu:
libcurl3, libcurl4, openssl openssl1.0, libssl1.1 libssl1.0, libpcre2 libpcre3 libpcre. list goes on ... very long
The point of this is to make it easier for our users to make plugins and migrate between version without having to jump through hoops. This is a minor change. it does not affect anybody that is doing on "one" version at a time model. At the end of the day the user can say:
#include<ts7/api/c/ts.h>
or ( via a tweak in a build file)
#include <api/c/ts.h>
or with the power of symlinks and a common practice
#include<ts/api/c/ts.h>
This is a small change that will make it work better for everyone.
The only argument is that it is better to make it more complex for the users to do thing correctly when they want to migrate from one major version to another.
Given that we want to build a community and have more active users that are not hardcore C/C++ developers. These people will want to use standard RPMs/DEP/etc file that installs in a unified directory structure. Arguments such as "I never heard of this" or "I actively avoid this"is subjective. No one is preventing a person from uninstalling or reinstalling if they want to. do five or ten extra steps if that floats your boat.. I will not judge you.. you are free to do so. However, we don't need to force this on others
Why do we want to make using ATS correctly harder for our users?
Why are we not following a standard practice that is actively used as I pointed out various examples of libraries above?
This is an enabling tweak, not one that disables or forces any use case to become more complex.
This change is about making it easier for developers to develop plugins. Easier for our users to use traffic server, which should help us grow the traffic server community.
Why do we not want this?

I would like to split this discussion up a bit. There are two quite different points at issue.
One is whether, by default, ATS should structure its installed include headers in a version dependent path. As Bryan noted, it is possible to do this now by two different methods, either the isolated directory (e.g. "/opt/ats5", "/opt/ats7", ...) or explicitly overriding all of the paths with "./configure".
The other issue, which is much more important to me and this PR is, under that base directory, what is the directory layout? I have one structure (done in this PR), Jason has proposed a different one. For reasons enumerated earlier, I think Bryan's suggestion isn't feasible. I would accept a compromise based on Jason's layout. That is,
"/api/c/plugin" // Plugin API headers
"/api/c/util" // Dual use utility.
"/api/cpp/plugin" // Plugin API headers
"/api/cpp/util" // Dual use utility
"/api/core" // Internal / core only.

To be very clear, none of the versioned include path work is part of this PR. That's a completely orthogonal issue to be dealt with else where.

I think is mostly starting to look reasonable (except for the suggestions of versions in include directory names :). However, I think I'd prefer to have as few libraries and include directories as possible. I think a reasonable compromise is to structure this by

Is it internal only?
Is it external and internal?

As such, I think I'd like to see

libtscapi.so (and e.g. tscapi/ts.h)
libtscore.so - Internal library only, no public interfaces
libtscppapi.so (and e.g. tscpp/Async.h
libtscppcore.so (Assuming there are any pieces of the CPP Apis that are internal only)

I was torn on the requirements of having plugins link in libtscapi.so, but there are pros and cons. A is that we now have to change how non-core plugins are built (i.e. more user complexity). A significant pro is that we get explicit version control of plugins! Meaning, it will no longer be possible to (accidentally) load a 7.x plugin against an ATS 8.0 installation.

I don't understand that library structure. Why wouldn't the contents of libtscore.so be in libtscppcore.so? What's the difference? All of the internal interfaces are C++. I'm fine with internal only code in libtscppcore.so if you'd prefer that name.
Also, that structure has no provision for dual use C++ utilities, such as TextView.h, support for which is the goal of this PR.

After some IRC discussion, I think the C API issue to too fraught to be encompassed by this PR, so I would rather go with minimal changes there and leave it to future generations to decide. Therefore the proposed structure is
Headers:

include/ts - C API
include/tscpp/api - C++ API
include/tscpp/util - C++ utilities.
include/tscore - Internal use only, equivalent to the current "lib/ts" for headers.

Source files:

src/lib/tscore - Internal use only, equivalent of current "lib/ts" for source.
src/lib/cpp/api/ - C++ API source
src/lib/cpp/util/ - C++ dual use utilities soruce.

Libraries:

libtscore - Internal only code, equivalent of current libtsutil.
libtscppapi - C++ API library.
libtscpputil - C++ dual use utilities.

From a C++ plugin writers perspective It would be less confusing if we were to collapse cpp/util and cpp/api into one include directory.  This is what OpenSSL does for their different libs.

Isn't openSSL a C library, not C++? Speaking as a C++ plugin writer, I find the split less confusing because the purpose and use of those files are different. The split will also reduce confusion for developers working in the core and not in plugins, as it will be instantly clear which headers are valid for use in the core, and which are not.

I'm ok with the C API layout. Did we agree to break out InkAPI.cc into a libtscapi.so.. ? I'm probably ok either way, but I do like that benefit of the automatic major version control that dlopen will do for us with that change.
However, I suspect traffic_server would still need to link with such a library, because otherwise the regressions for InkAPITest.cc would not work I think?

I'm not going to change how the C API is linked in this PR. That is really orthogonal to the purpose of this PR. For the C++ API, I will be changing the linking only to the extent of (possibly) renaming the library. Otherwise it will be the same.

[approve ci centos]

I don't do this by hand anymore, I have a script that updates from a clean master to this state.

[approve ci autest]

I still think it is a bad idea to split up the C++ API into to directories.  I am +0 on this.

@SolidWallOfCode This doesn't cleanly cherry pick to 8.0.x.  If you want it in 8.0.0 you will need to make a PR off the 8.0.x branch.


Fix wrong usage of escape analysis in MemBehavior

The EscapeAnalysis:canEscapeTo function was actually broken, because it did not detect all escapes of a reference/pointer.
I completely replaced the implementation with the correct one (canObjectOrContentEscapeTo) and removed the now obsolete canObjectOrContentEscapeTo.
Fixes a miscompile.
rdar://problem/39161309

@swift-ci test and merge


Feature/scheduler

Scheduler modified to execute actions from harvest, proposals, referendums and forum contracts. It could execute any action of any contract with the permission @execute and if the action does not need parameters.
Removed deferred transactions from calcplanted, calctrx, calcrep from harvest to prevent them to auto-schedule.
Schedulers now takes seconds as timestamp.
Added the cancelexec action to cancel the execute deferred transaction if necessary.

Closing this it has all been merged


Create documentation for running scraper locally

If you're able to get the scraper to successfully add information to a development site, please create add more documentation to the readme regarding things people show know to get up and running and any notes you think would be useful to add additional scraping features.

PR https://github.com/codeforboston/GovLens/pull/121 refactors the scraper and updates documentation for running it locally.
Future work will include improving this documentation and documenting how to run the scraper in production.


SDK Content Diffs - Roslyn

The following content diffs are appearing between the MSFT SDK and the Source-Build SDK. This content diff has been known to appear, disappear, and resurface.
Files appearing in the source-build SDK and not in the MSFT sdk:
+./sdk/x.y.z/Roslyn/bincore/System.Collections.Immutable.dll
+./sdk/x.y.z/Roslyn/bincore/System.Reflection.Metadata.dll

I have tracked the diffs down to the following commits and builds:

dotnet/dotnet commits
dotnet-source-build build without diff (internal Microsoft link)
dotnet-source-build build with diff (internal Microsoft link)

[Triage] This is likely caused by version lifting and the transient nature is due to version alignment.  We do not see the ROI for an in-depth investigation as there is no evidence of behavior issues.  We think the bincore directory is a candidate to add an exclusion for.


Candidate Release Comments (Organizational Users)

This issue was created to collect comments about the upcoming metrics release.
This thread is for comments about Organizational Users
GitHub location: https://github.com/chaoss/wg-value/blob/master/focus-areas/living-wage/org_users.md
Release candidate: https://chaoss.community/metric-organizational-users
See all release candidates of metrics are at:
https://chaoss.community/metrics-rc/
Important Dates
Release Freeze: June 21st, 2019
Candidate Release: June 24th, 2019
Comments Close: July 24th, 2019
Release Date: August 1st, 2019

This was noted in the community meeting on July 9th, 2019.
Requesting more information of sample and known implementations (5 and 6)

@andyl I suggest that this metric either needs to be developed in much more detail or I think it should be removed for Metrics Version 1 release. Ultimately, I suggest this metric is tabled until the next metrics release version.

+1 on more development here.

I think what this metric is getting at is both contribution diversity of organizations, as well as consumption diversity and volume of consumption by downstream projects. We might consider incorporating the V-Index. https://opensource.com/article/18/5/metrics-project-success

These links are all dead and the website is pointing to a 404 now.

Was there a name change somewhere along the line?

Renamed organizational impact - looking at it now - will update all relevant information.

404s are fixed and relevant information on the website was edited to reflect the change.

The header for this metric is long. Suggest just calling it "Organizational Impact"  rather than "Downstream Organizational Impact of a Project Software"
Also, the question no longer reflects the objective of the metric.

OK to release.


There is an property for CI, but no place to init it or set it.

Hi,
I find we use CI->$property in both function _ci_load_library() and _ci_load_stock_library(), but there is no place to set the property or init the property.
         // Safety: Was the class already loaded by a previous call?
            if (class_exists($class, FALSE))
            {
                    $property = $object_name;
                    if (empty($property))
                    {
                            $property = strtolower($class);
                            isset($this->_ci_varmap[$property]) && $property = $this->_ci_varmap[$property];
                    }

                    $CI =& get_instance();
                    **if (isset($CI->$property))**
                    {
                            log_message('debug', $class.' class already loaded. Second attempt ignored.');
                            return;
                    }

                    return $this->_ci_init_library($class, '', $params, $object_name);
            }

So even this lib had already been loaded, for the CI->$property will always been empty, which will cause we repeat load the lib,

https://github.com/bcit-ci/CodeIgniter/blob/3.1.10/system/core/Loader.php#L1283


WIP: Avoid calling mget with massive number of keys in Readdir

This PR is related to #95 .
In the original implementation, mget is called once with all the keys which correspond to files in a directory. When there are many files in a directory, this call might block the Redis server process.
In this PR, I changed it to call mget in smaller fixed batch. The consequence is that we reduce the chance of blocking the Redis server, but ReadDir is made slower when the number of files in a directory exceeds the batch size (which is set to 4096 now).
For small directories, the latency difference is trivial:

Before

In [24]: %timeit os.listdir("/Users/satoru//jfs/some-files/")
1.26 ms ± 2.57 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

After

In [25]: %timeit os.listdir("/Users/satoru/jfs/some-files/")
1.27 ms ± 11.3 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

When I run the benchmark in a directory with more than 200,000 files, the new version is obviously slower:

Before

In [15]: %timeit os.listdir("/Users/satoru/jfs/many-files/")
446 ms ± 2.87 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

After

In [19]: %timeit os.listdir("/Users/satoru/jfs/many-files/")
488 ms ± 8.5 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

I've changed the code to call mget in two goroutines, it turns out to be faster than the original implementation when reading a folder with 300,000 files.

Before

In [2]: %timeit os.listdir("/Users/satoru/jfs/many-files/")
657 ms ± 10.6 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [3]: %timeit os.listdir("/Users/satoru/jfs/many-files/")
654 ms ± 9.33 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [4]: %timeit os.listdir("/Users/satoru/jfs/many-files/")
648 ms ± 8.35 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

After

In [5]: %timeit os.listdir("/Users/satoru/jfs/many-files/")
525 ms ± 10.8 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [6]: %timeit os.listdir("/Users/satoru/jfs/many-files/")
613 ms ± 5.61 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [7]: %timeit os.listdir("/Users/satoru/jfs/many-files/")
617 ms ± 9.69 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

I've changed the code to call mget in two goroutines, it turns out to be faster than the original implementation when reading a folder with 300,000 files.

Before

In [2]: %timeit os.listdir("/Users/satoru/jfs/many-files/")
657 ms ± 10.6 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [3]: %timeit os.listdir("/Users/satoru/jfs/many-files/")
654 ms ± 9.33 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [4]: %timeit os.listdir("/Users/satoru/jfs/many-files/")
648 ms ± 8.35 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

After

In [5]: %timeit os.listdir("/Users/satoru/jfs/many-files/")
525 ms ± 10.8 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [6]: %timeit os.listdir("/Users/satoru/jfs/many-files/")
613 ms ± 5.61 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [7]: %timeit os.listdir("/Users/satoru/jfs/many-files/")
617 ms ± 9.69 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

For folders with less files (100 in my benchmark), it's slower than the original implementation:

Before

In [18]: %timeit os.listdir("/Users/satoru/jfs/some-files/")
685 µs ± 8.8 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [19]: %timeit os.listdir("/Users/satoru/jfs/some-files/")
666 µs ± 12.2 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [20]: %timeit os.listdir("/Users/satoru/jfs/some-files/")
656 µs ± 2.74 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

After

In [15]: %timeit os.listdir("/Users/satoru/jfs/some-files/")
752 µs ± 6.62 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [16]: %timeit os.listdir("/Users/satoru/jfs/some-files/")
748 µs ± 4.29 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [17]: %timeit os.listdir("/Users/satoru/jfs/some-files/")
722 µs ± 38.2 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

For folders with less files (100 in my benchmark), it's slower than the original implementation:

Before

In [18]: %timeit os.listdir("/Users/satoru/jfs/some-files/")
685 µs ± 8.8 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [19]: %timeit os.listdir("/Users/satoru/jfs/some-files/")
666 µs ± 12.2 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [20]: %timeit os.listdir("/Users/satoru/jfs/some-files/")
656 µs ± 2.74 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

After

In [15]: %timeit os.listdir("/Users/satoru/jfs/some-files/")
752 µs ± 6.62 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [16]: %timeit os.listdir("/Users/satoru/jfs/some-files/")
748 µs ± 4.29 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [17]: %timeit os.listdir("/Users/satoru/jfs/some-files/")
722 µs ± 38.2 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

@suzaku Based on the result from benchmark, we should have a fast path for small directorym, thanks.

@suzaku Based on the result from benchmark, we should have a fast path for small directorym, thanks.

Could you also add a benchmark in Go (for both of small and large directory)?

Could you also add a benchmark in Go (for both of small and large directory)?

@davies Is it safe here to use multiple HSCAN instead of a huge HGETALL here?

@davies Is it safe here to use multiple HSCAN instead of a huge HGETALL here?

@suzaku It's OK to use HSCAN. Right now, what's behavior for 5 millions files?

@suzaku It's OK to use HSCAN. Right now, what's behavior for 5 millions files?

If HSCAN is OK, we can set up a goroutine to do HSCAN on smaller batches instead of calling HGETALL upfront.
I haven't tested 5 million files yet. Creating files can be quite time consuming, I didn't wait that long...

If HSCAN is OK, we can set up a goroutine to do HSCAN on smaller batches instead of calling HGETALL upfront.
I haven't tested 5 million files yet. Creating files can be quite time consuming, I didn't wait that long...

Let's merge this one first, then optimize the hgetall() later.

Let's merge this one first, then optimize the hgetall() later.


Use subtests. Need to stob building on go < 1.7.

note
This PR is based on google/jsonapi#38. Once it is merged into master, this PR will be rebased. There is only one commit unique to this PR.

After #38 is merged, I will rebase this one and it should resolve any conflicts.


Publication flow seems to be paused

The publication flow in TEST seems to be paused. My submitted notices are not published for 2 days. Could you confirm?

this notice is waiting for a week to be published, is it only my issue?
35bfeb3d-78a4-49ed-a6af-4df88a501504-01

In the Preview environment, it is possible for notices to get stuck in the back-end system (TED Monitor): they enter a technical workflow error and we don't manually acknowledge them to put them into Not Published status - so they stay indefinitely in Submitted.
For your specific notice, the error is that it links to a previous notice that hasn't been published and the system puts it in error as it cannot establish a link between the notices.
In future we will implement the CVS rule that checks that linked notices are have been Published but until then these back-end errors may happen. In any case, it's useful for eSender applications to check the links before submission (regardless of the CVS check) though I realise that this case was just a test that had a confusing outcome for you.

If you encounter an issue specific to one of our applications, in the "Preview" or "Production" environment, please contact the TED helpdesk at<EMAIL_ADDRESS>


Implementation of sliceLastElements

https://github.com/BlakeGuilloud/ganon/issues/140
Made some modifications to the function. Thought it would be more useful if an array was passed in, instead of just applying to a sample.
Also, fixed the unit tests. They were feeling since they were looking for object equivalence instead of just equality.

[x] Running yarn lint does not trigger any linter warnings
[x] The test of the method you have fixed is passing
TODO:
[ ] You have written a new skeleton method for someone else to work on!

Hey @pkabra  ! Thanks for your contribution.- we are stoked to have you on board. Unfortunately your pull request does not meet all of the criteria of our Contributing Guide since no new skeleton method is provided. We will be closing out the pull request for the time being. Please follow the guidelines set out in CONTRIBUTING.md and reopen the pull request! Thanks


confusing ctor in MonoTojos

@rultor release, tag is 0.8.0

@rultor release, tag is 0.8.0

@yegor256 OK, I will release it now. Please check the progress here

@rultor release, tag is 0.8.0

@yegor256 Done! FYI, the full log is here (took me 8min)


[Enhancement] Animation on checkbox

Example: https://daisyui.com/components/form/checkbox

Actually, I don't like the component having too much animation, but it's ok to make some effects... I will think about this and put it into backlog


Support forwording the email to Gotify Notifications

Dear,
Good day,
I was wondering if you would support and instruct in how we could forward the email to Gotify Notifications, in my use case i would configure all my services in my homelab to send there email to mailcatcher as a centralized email centre, but i will be grate if i'm able to get a notification of the received email while I'm out of home, i found gotify can ease this task. alot of homelab users would love this addition.
to make it clear:
Service -> mailcatcher -> Gotify
Thanks,

Sorry, this is not something MailCatcher is designed to do. You might be interesting in trying MailHog — it has a more comprehensive API and forwarding capabilities.

Sorry, this is not something MailCatcher is designed to do. You might be interesting in trying MailHog — it has a more comprehensive API and forwarding capabilities.


FastAPI demo doesn't work

FastAPI demo doesn't work. I get error:
[...]
/lib/python3.7/site-packages/loginpass-0.5-py3.7.egg/loginpass/_fastapi.py", line 72, in auth
    return await handle_authorize(remote, token, user_info, request)
TypeError: object UserInfo can't be used in 'await' expression

FastAPI version:
$ pip freeze | grep fastapi
fastapi==0.67.0
$ pip freeze | grep loginpass
loginpass==0.5

This library hasn't been re-released to PyPi since the FastAPI support was merged.
Version 0.5 issued in 74732302b5c974ee1580d8301ff3cddd9a630d95 on May 18, 2020
Add FastAPI Support https://github.com/authlib/loginpass/pull/73: merged Nov 28, 2020
This project is a REALLY GOOD IDEA imo, but it looks like it's pretty dead.


Task finished with error [-1017] Error Domain=NSURLErrorDomain Code=-1017 "cannot parse response"

[REQUIRED] Step 1: Describe your environment

Xcode version: 13.2.1
Firebase SDK version: 8.10.0
Installation method: CocoaPods (Flutter)
Firebase Component: Storage
Target platform(s): iOS

[REQUIRED] Step 2: Describe the problem
Steps to reproduce:
I have my app in beta test release with few users and in my Crashlytics dashboard i can see the following error :
Task <24E18897-20B7-45FD-9621-85FF09DC6326>.<1> finished with error [-1017] Error Domain=NSURLErrorDomain Code=-1017 "cannot parse response" UserInfo={_kCFStreamErrorCodeKey=-1, _NSURLErrorFailingURLSessionTaskErrorKey=BackgroundUploadTask <24E18897-20B7-45FD-9621-85FF09DC6326>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
    "BackgroundUploadTask <24E18897-20B7-45FD-9621-85FF09DC6326>.<1>",
    "LocalUploadTask <24E18897-20B7-45FD-9621-85FF09DC6326>.<1>"
), NSLocalizedDescription=cannot parse response, _kCFStreamErrorDomainKey=4, NSErrorFailingURLStringKey=https://firebasestorage.googleapis.com/v0/b/mybucket/o/user%2FNyq7dMqe1kcAZ77R1YwH5fsAkV83%2Fcontent%2F43aa2d41-7a19-11ec-bd39-85fcd9d025?uploadType=resumable&name=user%2FNqe1kcAZ77R1YwH5fsAkV83%2Fcontent%2F43aa2d41-7a19-11ec-bd39-8508fcd025&upload_id=ADPycdv0-OYZPx3zAGzLrn25ZdI9srgkgABHGKb_1fCqUO7AAPHsZTkz_iVX1NfuYQsn0LHgCCiOsSzhLiP4Ho7VynSf_ceJJw&upload_protocol=resumable, NSErrorFailingURLKey=https://firebasestorage.googleapis.com/v0/b/mybucket/o/user%2FNyqMqe1kcAZ77R1YwH5fsAkV83%2Fcontent%2F43aa2d41-7a19-11ec-bd39-8508fcd9d025?uploadType=resumable&name=user%2FNyq7dMqe1kcAZ77R1YwH5V83%2Fcontent%2F432d41-7a19-11ec-bd39-8508f9d025&upload_id=ADPycdv0-OYZPx3zAGzLrn25ZdI9srgkgABHGKb_1fCqUO7AAPHsZTkz_iVX1NfuYQsn0LHgCCiOsSzhLiP4Ho7VynSf_ceJJw&upload_protocol=resumable}
GTMSessionFetcher invoking fetch callbacks, data (null), error Error Domain=NSURLErrorDomain Code=-1017 "cannot parse response" UserInfo={_kCFStreamErrorCodeKey=-1, _NSURLErrorFailingURLSessionTaskErrorKey=BackgroundUploadTask <24E18897-20B7-45FD-9621-85FF09DC6326>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
    "BackgroundUploadTask <24E18897-20B7-45FD-9621-85FF09DC6326>.<1>",
    "LocalUploadTask <24E18897-20B7-45FD-9621-85FF09DC6326>.<1>"
), NSLocalizedDescription=cannot parse response, _kCFStreamErrorDomainKey=4, NSErrorFailingURLStringKey=https://firebasestorage.googleapis.com/v0/b/mybucket/o/users%2FNyq7dMqe1kcAZ77R1YwH5fsAkV83%2Fcontent%2F43aa2d41-7a19-11ec-bd39-8508fcd9d025?uploadType=resumable&name=users%2FNyq7dMqe1kcAZ77R1YwH5fsAkV83%2Fposts%2F43aa2d41-7a19-11ec-bd39-8508fcd9d025s&upload_id=ADPycdv0-OYZPx3zAGzLrn25ZdI9srgkgABHGKb_1fCqUO7AAPHsZTkz_iVX1NfuYQsn0LHgCCiOsSzhLiP4Ho7VynSf_ceJJw&upload_protocol=resumable, NSErrorFailingURLKey=https://firebasestorage.googleapis.com/v0/b/mybucket/o/user%2FNyq7dMqe1kcAZ77R1YwH5fsAkV83%2Fcontent%2F43aa2d41-7a19-11ec-bd39-8508fcd9d025-low_res?uploadType=resumable&name=user%2FNyq7dMqe1kcAZ77R1YwH5fsAkV83%2Fposts%2F43aa2d41-7a19-11ec-bd39-8508f&upload_id=ADPycdv0-OYZPx3zAGzLrn25ZdI9srgkgABHGKb_1fCqUO7AAPHsZTkz_iVX1NfuYQsn0LHgCCiOsSzhLiP4Ho7VynSf_ceJJw&upload_protocol=resumable}

This is maybe not a bug but i have no clue about what does this error mean... I have asked about it on StackOverFlow but as i am not getting answers with a bounty, i think it's time to post it here to see if there is a real issue :/
Relevant Code:
I don't have a relevant code since it's throwing this error only around 5-10% of the time for my users according to how much they upload.
I have a similar log for the Android SDK actually.

Hi @Tom3652, unfortunately, Flutter is beyond my scope of expertise. I'll be closing this issue for now as this should be filed through FlutterFire repository.

Hello @rizafran,
This error doesn't come from the iOS SDK ?
I am a Flutter dev but it seems to be Swift errors, so do you mean that it's the Flutter implementation of the Firebase iOS SDK that would lead to this error, rather than the Firebase iOS SDK itself ?
Thanks !

You're correct that it is an iOS SDK issue (or Firebase console issue). However, we may not be able to do much to help without a non-Flutter example here.  Would you share the Podfile.lock and details about the iOS versions the crashes occur on - in case that provides us with any clues.
I'll reopen for now for some more digging and conversation, but as @rizafran pointed out, we'll likely need a more isolated repro.

Sure i understand of course, but my code is really simple i am not doing more than in the documentation regarding the upload except that i don't put an extension at the end of my files for bucket URLs.
That means that i am uploading myfileID.mp4 to myBucketUrl/some/path/{myfileID}  without .mp4. This works fine most of the time so i don't think it's because of this...
I was simply looking for an explanation of this error cannot parse response rather than asking you to fix something in the SDK.
I would ask naively the following questions :

Which response and is there any trace of the request ?
Which method is calling this server side ? (probably the one for the UploadTask object)
Is there any chance to raise a useful error here if we know the method throwing this error ?

Would you share the Podfile.lock and details about the iOS versions the crashes occur on - in case that provides us with any clues.

Also to specify, it doesn't crash the app fortunately :) it's only an upload error.
Another relevant point, my users that have experienced this told me that they could retry the upload and it was eventually working (because i have handled any failures in my UI).
So this means that the file is not broken or something...
The iOS versions are :

15.1.1
15.2.1

Podfile.lock
PODS:
  - "app_settings (3.0.0+1)":
    - Flutter
  - app_tracking_transparency (0.0.1):
    - Flutter
  - AppAuth (1.4.0):
    - AppAuth/Core (= 1.4.0)
    - AppAuth/ExternalUserAgent (= 1.4.0)
  - AppAuth/Core (1.4.0)
  - AppAuth/ExternalUserAgent (1.4.0)
  - apple_maps_flutter (0.0.1):
    - Flutter
  - audioplayers (0.0.1):
    - Flutter
  - camera (0.0.1):
    - Flutter
  - cloud_functions (3.2.5):
    - Firebase/Functions (= 8.10.0)
    - firebase_core
    - Flutter
  - connectivity_plus (0.0.1):
    - Flutter
    - ReachabilitySwift
  - disk_space (0.0.1):
    - Flutter
  - emoji_picker_flutter (0.0.1):
    - Flutter
  - FBAEMKit (12.2.1):
    - FBSDKCoreKit_Basics (= 12.2.1)
  - FBSDKCoreKit (12.2.1):
    - FBAEMKit (= 12.2.1)
    - FBSDKCoreKit_Basics (= 12.2.1)
  - FBSDKCoreKit_Basics (12.2.1)
  - FBSDKLoginKit (12.2.1):
    - FBSDKCoreKit (= 12.2.1)
  - Firebase/Analytics (8.10.0):
    - Firebase/Core
  - Firebase/Auth (8.10.0):
    - Firebase/CoreOnly
    - FirebaseAuth (~> 8.10.0)
  - Firebase/Core (8.10.0):
    - Firebase/CoreOnly
    - FirebaseAnalytics (~> 8.10.0)
  - Firebase/CoreOnly (8.10.0):
    - FirebaseCore (= 8.10.0)
  - Firebase/Crashlytics (8.10.0):
    - Firebase/CoreOnly
    - FirebaseCrashlytics (~> 8.10.0)
  - Firebase/Database (8.10.0):
    - Firebase/CoreOnly
    - FirebaseDatabase (~> 8.10.0)
  - Firebase/DynamicLinks (8.10.0):
    - Firebase/CoreOnly
    - FirebaseDynamicLinks (~> 8.10.0)
  - Firebase/Functions (8.10.0):
    - Firebase/CoreOnly
    - FirebaseFunctions (~> 8.10.0)
  - Firebase/Messaging (8.10.0):
    - Firebase/CoreOnly
    - FirebaseMessaging (~> 8.10.0)
  - Firebase/Performance (8.10.0):
    - Firebase/CoreOnly
    - FirebasePerformance (~> 8.10.0)
  - Firebase/Storage (8.10.0):
    - Firebase/CoreOnly
    - FirebaseStorage (~> 8.10.0)
  - firebase_analytics (9.0.5):
    - Firebase/Analytics (= 8.10.0)
    - firebase_core
    - Flutter
  - firebase_auth (3.3.5):
    - Firebase/Auth (= 8.10.0)
    - firebase_core
    - Flutter
  - firebase_core (1.11.0):
    - Firebase/CoreOnly (= 8.10.0)
    - Flutter
  - firebase_crashlytics (2.4.5):
    - Firebase/Crashlytics (= 8.10.0)
    - firebase_core
    - Flutter
  - firebase_database (9.0.5):
    - Firebase/Database (= 8.10.0)
    - firebase_core
    - Flutter
  - firebase_dynamic_links (4.0.4):
    - Firebase/DynamicLinks (= 8.10.0)
    - firebase_core
    - Flutter
  - firebase_messaging (11.2.5):
    - Firebase/Messaging (= 8.10.0)
    - firebase_core
    - Flutter
  - firebase_performance (0.8.0-4):
    - Firebase/Performance (= 8.10.0)
    - firebase_core
    - Flutter
  - firebase_storage (10.2.5):
    - Firebase/Storage (= 8.10.0)
    - firebase_core
    - Flutter
  - FirebaseABTesting (8.11.0):
    - FirebaseCore (~> 8.0)
  - FirebaseAnalytics (8.10.0):
    - FirebaseAnalytics/AdIdSupport (= 8.10.0)
    - FirebaseCore (~> 8.0)
    - FirebaseInstallations (~> 8.0)
    - GoogleUtilities/AppDelegateSwizzler (~> 7.6)
    - GoogleUtilities/MethodSwizzler (~> 7.6)
    - GoogleUtilities/Network (~> 7.6)
    - "GoogleUtilities/NSData+zlib (~> 7.6)"
    - nanopb (~> 2.30908.0)
  - FirebaseAnalytics/AdIdSupport (8.10.0):
    - FirebaseCore (~> 8.0)
    - FirebaseInstallations (~> 8.0)
    - GoogleAppMeasurement (= 8.10.0)
    - GoogleUtilities/AppDelegateSwizzler (~> 7.6)
    - GoogleUtilities/MethodSwizzler (~> 7.6)
    - GoogleUtilities/Network (~> 7.6)
    - "GoogleUtilities/NSData+zlib (~> 7.6)"
    - nanopb (~> 2.30908.0)
  - FirebaseAuth (8.10.0):
    - FirebaseCore (~> 8.0)
    - GoogleUtilities/AppDelegateSwizzler (~> 7.6)
    - GoogleUtilities/Environment (~> 7.6)
    - GTMSessionFetcher/Core (~> 1.5)
  - FirebaseCore (8.10.0):
    - FirebaseCoreDiagnostics (~> 8.0)
    - GoogleUtilities/Environment (~> 7.6)
    - GoogleUtilities/Logger (~> 7.6)
  - FirebaseCoreDiagnostics (8.11.0):
    - GoogleDataTransport (~> 9.1)
    - GoogleUtilities/Environment (~> 7.7)
    - GoogleUtilities/Logger (~> 7.7)
    - nanopb (~> 2.30908.0)
  - FirebaseCrashlytics (8.10.0):
    - FirebaseCore (~> 8.0)
    - FirebaseInstallations (~> 8.0)
    - GoogleDataTransport (~> 9.1)
    - GoogleUtilities/Environment (~> 7.6)
    - nanopb (~> 2.30908.0)
    - PromisesObjC (< 3.0, >= 1.2)
  - FirebaseDatabase (8.10.0):
    - FirebaseCore (~> 8.0)
    - leveldb-library (~> 1.22)
  - FirebaseDynamicLinks (8.10.0):
    - FirebaseCore (~> 8.0)
  - FirebaseFunctions (8.10.0):
    - FirebaseCore (~> 8.0)
    - GTMSessionFetcher/Core (~> 1.5)
  - FirebaseInstallations (8.11.0):
    - FirebaseCore (~> 8.0)
    - GoogleUtilities/Environment (~> 7.7)
    - GoogleUtilities/UserDefaults (~> 7.7)
    - PromisesObjC (< 3.0, >= 1.2)
  - FirebaseMessaging (8.10.0):
    - FirebaseCore (~> 8.0)
    - FirebaseInstallations (~> 8.0)
    - GoogleDataTransport (~> 9.1)
    - GoogleUtilities/AppDelegateSwizzler (~> 7.6)
    - GoogleUtilities/Environment (~> 7.6)
    - GoogleUtilities/Reachability (~> 7.6)
    - GoogleUtilities/UserDefaults (~> 7.6)
    - nanopb (~> 2.30908.0)
  - FirebasePerformance (8.10.0):
    - FirebaseCore (~> 8.0)
    - FirebaseInstallations (~> 8.0)
    - FirebaseRemoteConfig (~> 8.0)
    - GoogleDataTransport (~> 9.1)
    - GoogleUtilities/Environment (~> 7.6)
    - GoogleUtilities/ISASwizzler (~> 7.6)
    - GoogleUtilities/MethodSwizzler (~> 7.6)
    - nanopb (~> 2.30908.0)
  - FirebaseRemoteConfig (8.11.0):
    - FirebaseABTesting (~> 8.0)
    - FirebaseCore (~> 8.0)
    - FirebaseInstallations (~> 8.0)
    - GoogleUtilities/Environment (~> 7.7)
    - "GoogleUtilities/NSData+zlib (~> 7.7)"
  - FirebaseStorage (8.10.0):
    - FirebaseCore (~> 8.0)
    - GTMSessionFetcher/Core (~> 1.5)
  - Flutter (1.0.0)
  - flutter_app_badger (0.0.1):
    - Flutter
  - flutter_contacts (0.0.1):
    - Flutter
  - flutter_facebook_auth (3.5.3):
    - FBSDKCoreKit (~> 12.2.1)
    - FBSDKLoginKit (~> 12.2.1)
    - Flutter
  - flutter_ffmpeg/min-gpl-lts (0.4.2):
    - Flutter
    - mobile-ffmpeg-min-gpl (= 4.4.LTS)
  - flutter_image_compress (0.0.1):
    - Flutter
    - Mantle
    - SDWebImage
    - SDWebImageWebPCoder
  - flutter_native_text_input (2.1.0):
    - Flutter
  - FMDB (2.7.5):
    - FMDB/standard (= 2.7.5)
  - FMDB/standard (2.7.5)
  - geocoding (1.0.5):
    - Flutter
  - geolocator_apple (1.2.0):
    - Flutter
  - Google-Mobile-Ads-SDK (8.11.0):
    - GoogleAppMeasurement (< 9.0, >= 7.0)
    - GoogleUserMessagingPlatform (>= 1.1)
  - google_maps_flutter (0.0.1):
    - Flutter
    - GoogleMaps
  - google_mobile_ads (0.0.1):
    - Flutter
    - Google-Mobile-Ads-SDK (= 8.11.0)
  - google_sign_in (0.0.1):
    - Flutter
    - GoogleSignIn (~> 5.0)
  - GoogleAppMeasurement (8.10.0):
    - GoogleAppMeasurement/AdIdSupport (= 8.10.0)
    - GoogleUtilities/AppDelegateSwizzler (~> 7.6)
    - GoogleUtilities/MethodSwizzler (~> 7.6)
    - GoogleUtilities/Network (~> 7.6)
    - "GoogleUtilities/NSData+zlib (~> 7.6)"
    - nanopb (~> 2.30908.0)
  - GoogleAppMeasurement/AdIdSupport (8.10.0):
    - GoogleAppMeasurement/WithoutAdIdSupport (= 8.10.0)
    - GoogleUtilities/AppDelegateSwizzler (~> 7.6)
    - GoogleUtilities/MethodSwizzler (~> 7.6)
    - GoogleUtilities/Network (~> 7.6)
    - "GoogleUtilities/NSData+zlib (~> 7.6)"
    - nanopb (~> 2.30908.0)
  - GoogleAppMeasurement/WithoutAdIdSupport (8.10.0):
    - GoogleUtilities/AppDelegateSwizzler (~> 7.6)
    - GoogleUtilities/MethodSwizzler (~> 7.6)
    - GoogleUtilities/Network (~> 7.6)
    - "GoogleUtilities/NSData+zlib (~> 7.6)"
    - nanopb (~> 2.30908.0)
  - GoogleDataTransport (9.1.2):
    - GoogleUtilities/Environment (~> 7.2)
    - nanopb (~> 2.30908.0)
    - PromisesObjC (< 3.0, >= 1.2)
  - GoogleMaps (6.0.1):
    - GoogleMaps/Maps (= 6.0.1)
  - GoogleMaps/Base (6.0.1)
  - GoogleMaps/Maps (6.0.1):
    - GoogleMaps/Base
  - GoogleSignIn (5.0.2):
    - AppAuth (~> 1.2)
    - GTMAppAuth (~> 1.0)
    - GTMSessionFetcher/Core (~> 1.1)
  - GoogleUserMessagingPlatform (2.0.0)
  - GoogleUtilities (7.7.0):
    - GoogleUtilities/AppDelegateSwizzler (= 7.7.0)
    - GoogleUtilities/Environment (= 7.7.0)
    - GoogleUtilities/ISASwizzler (= 7.7.0)
    - GoogleUtilities/Logger (= 7.7.0)
    - GoogleUtilities/MethodSwizzler (= 7.7.0)
    - GoogleUtilities/Network (= 7.7.0)
    - "GoogleUtilities/NSData+zlib (= 7.7.0)"
    - GoogleUtilities/Reachability (= 7.7.0)
    - GoogleUtilities/SwizzlerTestHelpers (= 7.7.0)
    - GoogleUtilities/UserDefaults (= 7.7.0)
  - GoogleUtilities/AppDelegateSwizzler (7.7.0):
    - GoogleUtilities/Environment
    - GoogleUtilities/Logger
    - GoogleUtilities/Network
  - GoogleUtilities/Environment (7.7.0):
    - PromisesObjC (< 3.0, >= 1.2)
  - GoogleUtilities/ISASwizzler (7.7.0)
  - GoogleUtilities/Logger (7.7.0):
    - GoogleUtilities/Environment
  - GoogleUtilities/MethodSwizzler (7.7.0):
    - GoogleUtilities/Logger
  - GoogleUtilities/Network (7.7.0):
    - GoogleUtilities/Logger
    - "GoogleUtilities/NSData+zlib"
    - GoogleUtilities/Reachability
  - "GoogleUtilities/NSData+zlib (7.7.0)"
  - GoogleUtilities/Reachability (7.7.0):
    - GoogleUtilities/Logger
  - GoogleUtilities/SwizzlerTestHelpers (7.7.0):
    - GoogleUtilities/MethodSwizzler
  - GoogleUtilities/UserDefaults (7.7.0):
    - GoogleUtilities/Logger
  - GTMAppAuth (1.2.2):
    - AppAuth/Core (~> 1.4)
    - GTMSessionFetcher/Core (~> 1.5)
  - GTMSessionFetcher/Core (1.7.0)
  - image_editor (0.0.1):
    - Flutter
  - image_picker (0.0.1):
    - Flutter
  - in_app_purchase_storekit (0.0.1):
    - Flutter
  - in_app_review (0.2.0):
    - Flutter
  - leveldb-library (1.22.1)
  - libwebp (1.2.1):
    - libwebp/demux (= 1.2.1)
    - libwebp/mux (= 1.2.1)
    - libwebp/webp (= 1.2.1)
  - libwebp/demux (1.2.1):
    - libwebp/webp
  - libwebp/mux (1.2.1):
    - libwebp/demux
  - libwebp/webp (1.2.1)
  - Mantle (2.2.0):
    - Mantle/extobjc (= 2.2.0)
  - Mantle/extobjc (2.2.0)
  - mobile-ffmpeg-min-gpl (4.4.LTS)
  - nanopb (2.30908.0):
    - nanopb/decode (= 2.30908.0)
    - nanopb/encode (= 2.30908.0)
  - nanopb/decode (2.30908.0)
  - nanopb/encode (2.30908.0)
  - package_info_plus (0.4.5):
    - Flutter
  - path_provider_ios (0.0.1):
    - Flutter
  - perfect_volume_control (0.0.1):
    - Flutter
  - "permission_handler (5.1.0+2)":
    - Flutter
  - photo_manager (2.0.0):
    - Flutter
    - FlutterMacOS
  - PromisesObjC (2.0.0)
  - ReachabilitySwift (5.0.0)
  - record (0.0.1):
    - Flutter
  - screen_capture_event (0.0.1):
    - Flutter
  - SDWebImage (5.12.2):
    - SDWebImage/Core (= 5.12.2)
  - SDWebImage/Core (5.12.2)
  - SDWebImageWebPCoder (0.8.4):
    - libwebp (~> 1.0)
    - SDWebImage/Core (~> 5.10)
  - share_plus (0.0.1):
    - Flutter
  - shared_preferences_ios (0.0.1):
    - Flutter
  - sign_in_with_apple (0.0.1):
    - Flutter
  - sqflite (0.0.2):
    - Flutter
    - FMDB (>= 2.7.5)
  - url_launcher_ios (0.0.1):
    - Flutter
  - video_compress (0.3.0):
    - Flutter
  - video_player (0.0.1):
    - Flutter
  - video_thumbnail (0.0.1):
    - Flutter
    - libwebp

DEPENDENCIES:
  - app_settings (from `.symlinks/plugins/app_settings/ios`)
  - app_tracking_transparency (from `.symlinks/plugins/app_tracking_transparency/ios`)
  - apple_maps_flutter (from `.symlinks/plugins/apple_maps_flutter/ios`)
  - audioplayers (from `.symlinks/plugins/audioplayers/ios`)
  - camera (from `.symlinks/plugins/camera/ios`)
  - cloud_functions (from `.symlinks/plugins/cloud_functions/ios`)
  - connectivity_plus (from `.symlinks/plugins/connectivity_plus/ios`)
  - disk_space (from `.symlinks/plugins/disk_space/ios`)
  - emoji_picker_flutter (from `.symlinks/plugins/emoji_picker_flutter/ios`)
  - Firebase/Messaging
  - firebase_analytics (from `.symlinks/plugins/firebase_analytics/ios`)
  - firebase_auth (from `.symlinks/plugins/firebase_auth/ios`)
  - firebase_core (from `.symlinks/plugins/firebase_core/ios`)
  - firebase_crashlytics (from `.symlinks/plugins/firebase_crashlytics/ios`)
  - firebase_database (from `.symlinks/plugins/firebase_database/ios`)
  - firebase_dynamic_links (from `.symlinks/plugins/firebase_dynamic_links/ios`)
  - firebase_messaging (from `.symlinks/plugins/firebase_messaging/ios`)
  - firebase_performance (from `.symlinks/plugins/firebase_performance/ios`)
  - firebase_storage (from `.symlinks/plugins/firebase_storage/ios`)
  - Flutter (from `Flutter`)
  - flutter_app_badger (from `.symlinks/plugins/flutter_app_badger/ios`)
  - flutter_contacts (from `.symlinks/plugins/flutter_contacts/ios`)
  - flutter_facebook_auth (from `.symlinks/plugins/flutter_facebook_auth/ios`)
  - flutter_ffmpeg/min-gpl-lts (from `.symlinks/plugins/flutter_ffmpeg/ios`)
  - flutter_image_compress (from `.symlinks/plugins/flutter_image_compress/ios`)
  - flutter_native_text_input (from `.symlinks/plugins/flutter_native_text_input/ios`)
  - geocoding (from `.symlinks/plugins/geocoding/ios`)
  - geolocator_apple (from `.symlinks/plugins/geolocator_apple/ios`)
  - google_maps_flutter (from `.symlinks/plugins/google_maps_flutter/ios`)
  - google_mobile_ads (from `.symlinks/plugins/google_mobile_ads/ios`)
  - google_sign_in (from `.symlinks/plugins/google_sign_in/ios`)
  - GoogleUtilities
  - image_editor (from `.symlinks/plugins/image_editor/ios`)
  - image_picker (from `.symlinks/plugins/image_picker/ios`)
  - in_app_purchase_storekit (from `.symlinks/plugins/in_app_purchase_storekit/ios`)
  - in_app_review (from `.symlinks/plugins/in_app_review/ios`)
  - package_info_plus (from `.symlinks/plugins/package_info_plus/ios`)
  - path_provider_ios (from `.symlinks/plugins/path_provider_ios/ios`)
  - perfect_volume_control (from `.symlinks/plugins/perfect_volume_control/ios`)
  - permission_handler (from `.symlinks/plugins/permission_handler/ios`)
  - photo_manager (from `.symlinks/plugins/photo_manager/ios`)
  - record (from `.symlinks/plugins/record/ios`)
  - screen_capture_event (from `.symlinks/plugins/screen_capture_event/ios`)
  - share_plus (from `.symlinks/plugins/share_plus/ios`)
  - shared_preferences_ios (from `.symlinks/plugins/shared_preferences_ios/ios`)
  - sign_in_with_apple (from `.symlinks/plugins/sign_in_with_apple/ios`)
  - sqflite (from `.symlinks/plugins/sqflite/ios`)
  - url_launcher_ios (from `.symlinks/plugins/url_launcher_ios/ios`)
  - video_compress (from `.symlinks/plugins/video_compress/ios`)
  - video_player (from `.symlinks/plugins/video_player/ios`)
  - video_thumbnail (from `.symlinks/plugins/video_thumbnail/ios`)

SPEC REPOS:
  trunk:
    - AppAuth
    - FBAEMKit
    - FBSDKCoreKit
    - FBSDKCoreKit_Basics
    - FBSDKLoginKit
    - Firebase
    - FirebaseABTesting
    - FirebaseAnalytics
    - FirebaseAuth
    - FirebaseCore
    - FirebaseCoreDiagnostics
    - FirebaseCrashlytics
    - FirebaseDatabase
    - FirebaseDynamicLinks
    - FirebaseFunctions
    - FirebaseInstallations
    - FirebaseMessaging
    - FirebasePerformance
    - FirebaseRemoteConfig
    - FirebaseStorage
    - FMDB
    - Google-Mobile-Ads-SDK
    - GoogleAppMeasurement
    - GoogleDataTransport
    - GoogleMaps
    - GoogleSignIn
    - GoogleUserMessagingPlatform
    - GoogleUtilities
    - GTMAppAuth
    - GTMSessionFetcher
    - leveldb-library
    - libwebp
    - Mantle
    - mobile-ffmpeg-min-gpl
    - nanopb
    - PromisesObjC
    - ReachabilitySwift
    - SDWebImage
    - SDWebImageWebPCoder

EXTERNAL SOURCES:
  app_settings:
    :path: ".symlinks/plugins/app_settings/ios"
  app_tracking_transparency:
    :path: ".symlinks/plugins/app_tracking_transparency/ios"
  apple_maps_flutter:
    :path: ".symlinks/plugins/apple_maps_flutter/ios"
  audioplayers:
    :path: ".symlinks/plugins/audioplayers/ios"
  camera:
    :path: ".symlinks/plugins/camera/ios"
  cloud_functions:
    :path: ".symlinks/plugins/cloud_functions/ios"
  connectivity_plus:
    :path: ".symlinks/plugins/connectivity_plus/ios"
  disk_space:
    :path: ".symlinks/plugins/disk_space/ios"
  emoji_picker_flutter:
    :path: ".symlinks/plugins/emoji_picker_flutter/ios"
  firebase_analytics:
    :path: ".symlinks/plugins/firebase_analytics/ios"
  firebase_auth:
    :path: ".symlinks/plugins/firebase_auth/ios"
  firebase_core:
    :path: ".symlinks/plugins/firebase_core/ios"
  firebase_crashlytics:
    :path: ".symlinks/plugins/firebase_crashlytics/ios"
  firebase_database:
    :path: ".symlinks/plugins/firebase_database/ios"
  firebase_dynamic_links:
    :path: ".symlinks/plugins/firebase_dynamic_links/ios"
  firebase_messaging:
    :path: ".symlinks/plugins/firebase_messaging/ios"
  firebase_performance:
    :path: ".symlinks/plugins/firebase_performance/ios"
  firebase_storage:
    :path: ".symlinks/plugins/firebase_storage/ios"
  Flutter:
    :path: Flutter
  flutter_app_badger:
    :path: ".symlinks/plugins/flutter_app_badger/ios"
  flutter_contacts:
    :path: ".symlinks/plugins/flutter_contacts/ios"
  flutter_facebook_auth:
    :path: ".symlinks/plugins/flutter_facebook_auth/ios"
  flutter_ffmpeg:
    :path: ".symlinks/plugins/flutter_ffmpeg/ios"
  flutter_image_compress:
    :path: ".symlinks/plugins/flutter_image_compress/ios"
  flutter_native_text_input:
    :path: ".symlinks/plugins/flutter_native_text_input/ios"
  geocoding:
    :path: ".symlinks/plugins/geocoding/ios"
  geolocator_apple:
    :path: ".symlinks/plugins/geolocator_apple/ios"
  google_maps_flutter:
    :path: ".symlinks/plugins/google_maps_flutter/ios"
  google_mobile_ads:
    :path: ".symlinks/plugins/google_mobile_ads/ios"
  google_sign_in:
    :path: ".symlinks/plugins/google_sign_in/ios"
  image_editor:
    :path: ".symlinks/plugins/image_editor/ios"
  image_picker:
    :path: ".symlinks/plugins/image_picker/ios"
  in_app_purchase_storekit:
    :path: ".symlinks/plugins/in_app_purchase_storekit/ios"
  in_app_review:
    :path: ".symlinks/plugins/in_app_review/ios"
  package_info_plus:
    :path: ".symlinks/plugins/package_info_plus/ios"
  path_provider_ios:
    :path: ".symlinks/plugins/path_provider_ios/ios"
  perfect_volume_control:
    :path: ".symlinks/plugins/perfect_volume_control/ios"
  permission_handler:
    :path: ".symlinks/plugins/permission_handler/ios"
  photo_manager:
    :path: ".symlinks/plugins/photo_manager/ios"
  record:
    :path: ".symlinks/plugins/record/ios"
  screen_capture_event:
    :path: ".symlinks/plugins/screen_capture_event/ios"
  share_plus:
    :path: ".symlinks/plugins/share_plus/ios"
  shared_preferences_ios:
    :path: ".symlinks/plugins/shared_preferences_ios/ios"
  sign_in_with_apple:
    :path: ".symlinks/plugins/sign_in_with_apple/ios"
  sqflite:
    :path: ".symlinks/plugins/sqflite/ios"
  url_launcher_ios:
    :path: ".symlinks/plugins/url_launcher_ios/ios"
  video_compress:
    :path: ".symlinks/plugins/video_compress/ios"
  video_player:
    :path: ".symlinks/plugins/video_player/ios"
  video_thumbnail:
    :path: ".symlinks/plugins/video_thumbnail/ios"

SPEC CHECKSUMS:
  app_settings: d103828c9f5d515c4df9ee754dabd443f7cedcf3
  app_tracking_transparency: 5b1745ef9ade815f7455cb6a0848349589afb7c5
  AppAuth: 31bcec809a638d7bd2f86ea8a52bd45f6e81e7c7
  apple_maps_flutter: c59725efea39e13e703cde52a1d2b14866ad68a8
  audioplayers: 455322b54050b30ea4b1af7cd9e9d105f74efa8c
  camera: fe33292aff715a981eb34d7ce7b35b54337ff34c
  cloud_functions: acab801c51eb2c8772dc2f61397eb8b92012b81c
  connectivity_plus: 413a8857dd5d9f1c399a39130850d02fe0feaf7e
  disk_space: e94d34bbdf77954adfb39e60bde9cc5c7233eda6
  emoji_picker_flutter: 4f9a1ac31d355e1bf9622a1e821a809149130127
  FBAEMKit: 4cea610d0bc1680572f2aad7b25db7a2f2690d82
  FBSDKCoreKit: 5b1992fe65802ca26be7e68bc4fac5f59fa39908
  FBSDKCoreKit_Basics: a6a92ca628e05f86f458a4721574c5ddfb058ba3
  FBSDKLoginKit: 7467b7f988ca4fdf48f12a839bcfce4264752429
  Firebase: 44213362f1dcc52555b935dc925ed35ac55f1b20
  firebase_analytics: ab4a37ccfdc157e9fe43a2d47c230b39a405fbcc
  firebase_auth: 9d959bddc3b255ddfb67cf630a5bbb6186964356
  firebase_core: 2ca2d6cc8a11693e701b37126afae4800be5dbac
  firebase_crashlytics: 994376faf6e6acb76b9081ee0a00d8596038dc2b
  firebase_database: 54f02e0bac6bac2d21436ac3d4c83f8f34a9f219
  firebase_dynamic_links: 6d11136201d2f929a3c7b124b9b478ae2e64a06e
  firebase_messaging: c616c3449770c7e9f4db1ceb3fd2612b0b4d9283
  firebase_performance: ff8e2d10f82ffefa5a6cb8ac8edc26a44a72e18f
  firebase_storage: 740e81d4bef3360d50447dda37da9b8914a2acc0
  FirebaseABTesting: aac00a5472250a45f1462675792030e44df025c7
  FirebaseAnalytics: 319c9b3b1bdd400d60e2f415dff0c5f6959e6760
  FirebaseAuth: 59a2d2b933b5b79e18fb1e6ad230c6abdaa73d26
  FirebaseCore: 04186597c095da37d90ff9fd3e53bc61a1ff2440
  FirebaseCoreDiagnostics: 64d9709d804a6c25bd77841371c1fcfd909d5601
  FirebaseCrashlytics: 3b7f17cdf5bf1ae6ad5956696a6c26edeb39cca7
  FirebaseDatabase: 5f3e83b0a0d8759378fbd5d05661244d14dfbbb0
  FirebaseDynamicLinks: bb6ac718f763ec43560f0e2bb6b655a798b277af
  FirebaseFunctions: 9c406f9b2deb72719437565c106ca4a439d2a661
  FirebaseInstallations: 044eede8a049bce71c4541ee68d6e4364fcbe774
  FirebaseMessaging: b0aeba17332ee1ee610662b4d1e02a86db82f08f
  FirebasePerformance: 4f6d878a30f70f5ea4327c36868cd3624e762a07
  FirebaseRemoteConfig: a6a1ce9dabf404817ae2a44e8421d276660d9091
  FirebaseStorage: 815410224b548172c578f02554a86bbc8f817f50
  Flutter: 50d75fe2f02b26cc09d224853bb45737f8b3214a
  flutter_app_badger: 65de4d6f0c34a891df49e6cfb8a1c0496426fa68
  flutter_contacts: edb1c5ce76aa433e20e6cb14c615f4c0b66e0983
  flutter_facebook_auth: dbc47556cbdc61ced50e14473bd32461386a1425
  flutter_ffmpeg: 3ec3912c74649851e6c3b1885511eef78142ac4f
  flutter_image_compress: fd2b476345226e1a10ea352fa306af95704642c1
  flutter_native_text_input: ce34c74884f3d4c9e1a6daf9bc2d0bea66a62c49
  FMDB: 2ce00b547f966261cd18927a3ddb07cb6f3db82a
  geocoding: 32cfcdb16d38d907caaba65e2e42ad10d38bee58
  geolocator_apple: b741765c55dc21950e3e106e8b3584e55cf81ce5
  Google-Mobile-Ads-SDK: be2192b51b74d74a6ed70590c2e8275412f1b71e
  google_maps_flutter: abdb8dee6c52d4be36ad131ee6ebfacd14417c5a
  google_mobile_ads: a2f8b901601401bf7e691b4224d5992e9a37599a
  google_sign_in: c5cecea71f3be43282263550556e311c4cc03582
  GoogleAppMeasurement: a3311dbcf3ea651e5a070fe8559b57c174ada081
  GoogleDataTransport: 629c20a4d363167143f30ea78320d5a7eb8bd940
  GoogleMaps: c213fc2334b7374144cede914da779b99be0ab74
  GoogleSignIn: 7137d297ddc022a7e0aa4619c86d72c909fa7213
  GoogleUserMessagingPlatform: ab890ce5f6620f293a21b6bdd82e416a2c73aeca
  GoogleUtilities: e0913149f6b0625b553d70dae12b49fc62914fd1
  GTMAppAuth: ad5c2b70b9a8689e1a04033c9369c4915bfcbe89
  GTMSessionFetcher: 43748f93435c2aa068b1cbe39655aaf600652e91
  image_editor: c1d038630eedea60d2dee9c14f36aa66c7f9cfab
  image_picker: 9aa50e1d8cdacdbed739e925b7eea16d014367e6
  in_app_purchase_storekit: 6dec89fe3b9698847ed4aaf65fde6c17491620ad
  in_app_review: 4a97249f7a2f539a0f294c2d9196b7fe35e49541
  leveldb-library: 50c7b45cbd7bf543c81a468fe557a16ae3db8729
  libwebp: 98a37e597e40bfdb4c911fc98f2c53d0b12d05fc
  Mantle: c5aa8794a29a022dfbbfc9799af95f477a69b62d
  mobile-ffmpeg-min-gpl: 792c147353792f50127471b6a355a3c414a0d83d
  nanopb: a0ba3315591a9ae0a16a309ee504766e90db0c96
  package_info_plus: 6c92f08e1f853dc01228d6f553146438dafcd14e
  path_provider_ios: 7d7ce634493af4477d156294792024ec3485acd5
  perfect_volume_control: 79b165ecd79d6ee20e60bf15534de61ebf3bb5f3
  permission_handler: ccb20a9fad0ee9b1314a52b70b76b473c5f8dab0
  photo_manager: 4f6810b7dfc4feb03b461ac1a70dacf91fba7604
  PromisesObjC: 68159ce6952d93e17b2dfe273b8c40907db5ba58
  ReachabilitySwift: 985039c6f7b23a1da463388634119492ff86c825
  record: 7ee2393532f8553bbb09fa19e95478323b7c0a99
  screen_capture_event: bcf965bb31968a51c08ad3698725c5ad8c597124
  SDWebImage: 240e5c12b592fb1268c1d03b8c90d90e8c2ffe82
  SDWebImageWebPCoder: f93010f3f6c031e2f8fb3081ca4ee6966c539815
  share_plus: 056a1e8ac890df3e33cb503afffaf1e9b4fbae68
  shared_preferences_ios: aef470a42dc4675a1cdd50e3158b42e3d1232b32
  sign_in_with_apple: f3bf75217ea4c2c8b91823f225d70230119b8440
  sqflite: 6d358c025f5b867b29ed92fc697fd34924e11904
  url_launcher_ios: 02f1989d4e14e998335b02b67a7590fa34f971af
  video_compress: fce97e4fb1dfd88175aa07d2ffc8a2f297f87fbe
  video_player: ecd305f42e9044793efd34846e1ce64c31ea6fcb
  video_thumbnail: c4e2a3c539e247d4de13cd545344fd2d26ffafd1

PODFILE CHECKSUM: 29286db4be3b97d567e731f06a182f0c9b2ce852

COCOAPODS: 1.11.2

In debug mode yesterday i have tried to make it happen in my app by uploading 100 files simultaneously but i didn't get any failure...
I also specify that i am using the Blaze plan and i am not using the default bucket to upload my files.
Thank you for your time anyway, much appreciated

I have submitted a case 2 weeks ago to Firebase Support as well with a reproductible code sample and they are investigating :)

Thanks for the update, @Tom3652. I see that you have filed a ticket via Firebase Support. With this, I'll be closing this issue for now so you can continue your discussions in your case and to avoid confusion, but let me know if this ticket needs to be reopened for any further discussion.


zperf tcp upload failed when using same port

same build with https://github.com/intel/zephyr-ia/issues/2

move to inner-source


ConnectTimeoutException issue on WiFi in 1.4.9

I am using 1.4.9 library in Android Studio and getting following exception. The same call is working on 3G.  PFB the excpetion:
cz.msebera.android.httpclient.conn.ConnectTimeoutException: Connect to *****  timed out
Please solve this issue.
Device Samsung S3 4.0.1
Android Studio 2.0

i also encounter this bug，waste my three days to find this bug。

i also encounter this bug!

@eniserkaya try another lib  Okhttp~


Replace pycrypto with cryptography

Closes #250 Use cryptography.io instead of pycrypto

This seems to break in Python 2
NameError: global name 'FileExistsError' is not defined


Set up a special job or website to get the login info of auto-imaged VMs

Auto imaged VMs do not have predictable ports.  To access them it is necessary to find the endpoint in Azure.  Lots of users do not have the Azure subscription set up on their machines.   We should have a Jenkins job or web service that talks to a machine with the subscription to get the connection info.

There is a job in Jenkisn for this now


Move examples to a standalone project

Summary
Move examples to a standalone project
Motivation
example modifies does not show in webrtc commits.
Describe alternatives you've considered
Additional context

A couple of thoughts:

The pro of taking it out of the commit logs is partly offset by the difficulty of keeping pions-webrtc and the examples in sync. Especially when things are moving fast.

I was recently surprised to learn that the gstreamer packages were moved to an internal directory. I think it is not good that other people can't use them. Those gstreamer packages were an important part of me building my first POC pions-webrtc app.

My thoughts from Slack:

I wouldn't built all these (different signaling) separate examples. It doesn't really show off more capabilities of our tools and it kinda bloats our examples (which they already are).
I would consider splitting the examples in two: basic examples just showing off the API (e.g.: 'data-channels') and more involved examples (the ones with external dependencies) (like 'janus-gateway'). I would consider moving the the latter out of tree.
I would build out the pions/sfu (or just pions/mediaserver?) and add all of these as pluggable transports. (Instead of multiple signaling examples)

Regarding @rob-deutsch comments:

we could build the examples as part of the pions/webrtc CI. All examples in the separate repo can have a go modules to pull in dependencies.
While it may be convenient we really don't want anyone to rely on the packages that are now in examples/internal. If we want to provide this we should find a place where we can correctly maintain and support these capabilities.

Also, please make sure to keep the commit history when pulling things into a separate repo.

Duped with #561


Equivalent of np.lib.stride_tricks.as_strided

Does it already exists, or would it be possible to have np.lib.stride_tricks.as_strided in JAX?
I use it to build views of arrays with a rolling windowed last axis as below.
This then enables a quick calcuation of any rolling statistics.
def rolling_window(a, window, padding='same'):
    """
    Produces a rolling window view of array.

    Args:
        a: ndarray
            Array to produce a rolling view over. The rolling view is over the last axis.
        window: int
            Size of rolling window
        padding: str
            Type of padding, if 'same' then using reflecting padding so that rolling axis stays the same length.

    Returns: ndarray
        If `a` is shape [..., T] this returns an array of shape [..., T, window] if padding == 'same'
        otherwise a shape [..., T - window + 1, window]

    Examples:
        >>> a = np.arange(5) #0,1,2,3,4
        >>> print(rolling_window(a,3, padding='same'))
        [[1 0 1]
         [0 1 2]
         [1 2 3]
         [2 3 4]
         [3 4 3]]
        >>> print(rolling_window(a,3,padding=None))
        [[0 1 2]
         [1 2 3]
         [2 3 4]]
        # Using it to perform rolling mean
        >>> b = rolling_window(a,3,padding='same')
        >>> print(np.mean(b, axis=-1))
        [0.66666667 1.         2.         3.         3.33333333]

    """
    if padding.lower() == 'same':
        pad_start = np.zeros(len(a.shape), dtype=np.int32)
        pad_start[-1] = window // 2
        pad_end = np.zeros(len(a.shape), dtype=np.int32)
        pad_end[-1] = (window - 1) - pad_start[-1]
        pad = list(zip(pad_start, pad_end))
        a = np.pad(a, pad, mode='reflect')
    shape = a.shape[:-1] + (a.shape[-1] - window + 1, window)
    strides = a.strides + (a.strides[-1],)
    return np.lib.stride_tricks.as_strided(a, shape=shape, strides=strides)

Thanks for the question! I've used as_strided a lot in NumPy as well (like here and here).
There are two reasons (at least) you might want to use as_strided: first for efficiency (e.g. don't allocate a buffer for the rolling window array, make it just a view of the existing buffer, and moreover get better cache locality that way), and second for a convenient way of expressing the rolling window array (whether it formed a copy or not).
Under a jit, i.e. in an XLA computation, the notion of "buffer" and hence "view into the same buffer" doesn't exist; instead, there are only values. That's quite different from the NumPy buffer semantics: for example, in NumPy we know when new buffers are allocated (and know how to avoid it, e.g. with stride_tricks) and rely on that knowledge to understand how in-place updating of the values in the buffer affect aliases. In contrast, in XLA value semantics, which values in our computation are backed by buffers is totally up to the compiler; for example, when XLA decides to fuse operations, that means none of the temporary values among those operations are ever backed by a buffer. A corollary is that not only does "buffer" and "view into the same buffer" not exist under a jit, but also we don't need it to for efficiency. (Another optimization XLA can do underneath its buffer-free programming model is layout optimization.)
Outside of a jit, i.e. doing op-by-op computation in Python, it's a different story. Each DeviceArray is backed by a device buffer. While we don't allow in-place updating of the values in the buffer (we treat buffers as immutable), still there are some operations that avoid performing a copy, like reshapes and transposes, and instead just update metadata (see #1668). That's something like forming "views" of the underlying buffer, except for the fact that this sublanguage isn't rich enough to express slicing or striding like NumPy's. We considered growing the language to NumPy-style views, but decided that's probably not worth the complexity, as jit is our main performance model anyway.
All that is to say that for efficiency as_strided would only make sense in op-by-op (eager) mode, not under a jit, and also that we have chosen not to support it in op-by-op mode for now.
For providing a convenient way of expressing rolling windows, we could consider adding some kind of "strided view" helper function (which would always perform a copy in op-by-op evaluation), but on the other hand it might be easy enough to express these kinds of values via alternative means. One way to do it would be just to do some padding, reshaping, and slicing. Another way might be to use a gather operation like this (I didn't put in the padding logic):
import numpy as jnp

def rolling_window(a: jnp.ndarray, window: int):
  idx = jnp.arange(len(a) - window + 1)[:, None] + jnp.arange(window)[None, :]
  return a[idx]

a = jnp.arange(5)
print(rolling_window(a, 3))

[[0 1 2]
 [1 2 3]
 [2 3 4]]

WDYT?

Thanks for the in-depth reply! I also think choosing to develop jit features over buffer features is the way to go.  Hmm, not sure you need worry about helpers for things like stride views unless it becomes something other people are looking for. Using slicing and indexing is a pretty good alternative for rolling windows.

In case it's helpful to anyone coming here and looking for a jitted moving window into a 1D array, something like this works (also without padding logic):
from functools import partial
import jax.numpy as jnp
from jax import jit, vmap

@partial(jit, static_argnums=(1,))
def moving_window(a, size: int):
    starts = jnp.arange(len(a) - size + 1)
    return vmap(lambda start: jax.lax.dynamic_slice(a, (start,), (size,)))(starts)

a = jnp.arange(10)
print(moving_window(a, 4))

[[0 1 2 3]
 [1 2 3 4]
 [2 3 4 5]
 [3 4 5 6]
 [4 5 6 7]
 [5 6 7 8]
 [6 7 8 9]]

Modified the erdmann's code a bit for 2D array.
from functools import partial
import jax
import jax.numpy as jnp
from jax import jit, vmap

@partial(jit, static_argnums=(1,))
def moving_window(matrix, window_shape):
    matrix_width = matrix.shape[1]
    matrix_height = matrix.shape[0]

    window_width = window_shape[0]
    window_height = window_shape[1]

    startsx = jnp.arange(matrix_width - window_width + 1)
    startsy = jnp.arange(matrix_height - window_height + 1)
    starts_xy = jnp.dstack(jnp.meshgrid(startsx, startsy)).reshape(-1, 2) # cartesian product => [[x,y], [x,y], ...]

    return vmap(lambda start: jax.lax.dynamic_slice(matrix, (start[1], start[0]), (window_height, window_width)))(starts_xy)

matrix = jnp.asarray([
    [1, 2, 3, 4],
    [5, 6, 7, 8],
    [9, 10, 11, 12]
])
print(moving_window(matrix, (2, 3))) # window width = 2, window height = 3

[[[ 1  2  3]
  [ 5  6  7]]

 [[ 2  3  4]
  [ 6  7  8]]

 [[ 5  6  7]
  [ 9 10 11]]

 [[ 6  7  8]
  [10 11 12]]]