Re: Arrow Flight + Go, Arrow for Realtime
Mark, Dis you take a look at finos perspective? It seems to have some interesting overlaps with your goals. I've come across it but have not digged in. Be curious to get your thoughts on it . Cheers On Sat., Aug. 15, 2020, 13:05 , wrote: > David, > > Still investigating, but I suspect for streaming I may have to fall back > to some form of "custom" Flight implementation over Websockets. > > Assuming Arrow/Flight actually makes sense for that link, which will > probably depend on how well it compresses. However it will be very nice > if it does, to allow common format everywhere. > > The data I need to move around is highly variable in 'type', (Arrays of > Floats, Ints & Strings with occasional Binary, or vector (array of an array > of floats in my case) but the number of columns, and their type vary by > dataset and visualization choices. So far arrow seems a good choice rather > than any 'roll your own', and it will be nice to use same format on Client > side as well as in the Server system. > > My use case is primarily 'Get', consuming large datasets for > visualization. I doubt I'll need Put or Exchange from the browser. > > Mark. > > -Original Message- > From: David Li > Sent: Saturday, August 15, 2020 5:53 PM > To: dev@arrow.apache.org > Subject: Re: Arrow Flight + Go, Arrow for Realtime > > I am curious what you accomplish with Arrow + Flight from the browser. > Right now, Flight is all gRPC-based, and browser compatibility is a bit > mixed. I expect the various transcoders/gRPC-Web can handle > GetFlightInfo/DoGet fine, though IIRC for DoGet, at least some of the > transcoders would have to buffer the entire stream before sending it to the > browser. DoPut/DoExchange seem harder/impossible to bridge right now due to > the bidirectional streaming. > > Best, > David > > On 8/14/20, m...@markfarnan.com wrote: > > Thanks Wes, > > > > I'll likely work on that once I get my head around Arrow in general > > and confirm will use for the project. > > > > Considerations for how to account for the streaming append problem to an > > otherwise immutable dataset is current concern. Still thinking through > > that. > > > > Regards > > > > Mark. > > > > -Original Message- > > From: Wes McKinney > > Sent: Wednesday, August 12, 2020 3:59 PM > > To: dev > > Subject: Re: Arrow Flight + Go, Arrow for Realtime > > > > There's a WIP patch for Flight support in Go > > > > https://github.com/apache/arrow/pull/6731 > > > > I hope to see someone taking up this work as first-class Flight > > support in Go would be very useful for building data services. > > > > On Wed, Aug 12, 2020 at 5:08 AM Adam Lippai wrote: > >> > >> Arrow is mainly about batching data and leveraging all the > >> opportunities this gives. > >> This means you either have to buffer the data yourself and flush it > >> when a reasonable sized batch is complete or play with preallocating > >> Arrow structures This was discussed recently, you might be interested > >> in the thread: > >> https://www.mail-archive.com/dev@arrow.apache.org/msg19862.html > >> > >> Note: I'm not an Arrow developer, I'm just following the "streaming" > >> features of the Arrow lib, I'm interested in having a "rolling window" > >> API (like a fixed size FIFO queue). > >> > >> Best regards, > >> Adam Lippai > >> > >> On Wed, Aug 12, 2020 at 11:29 AM wrote: > >> > >> > I'm looking at using Arrow for a realtime IoT project which > >> > includes use cases both on server, and also for transferring /using > >> > in a Browser via WASM, and have a few questions. > >> > > >> > > >> > > >> > Language in use is Go. > >> > > >> > > >> > > >> > Is anyone working on implementing Arrow-Flight in Go ? > (According > >> > to > >> > the feature matrix, nothing ready yet, so wanted to check. > >> > > >> > > >> > > >> > Has anyone tried using Apache Arrow in Go WASM (Webassembly) ? if > >> > so, > >> > any issues ? > >> > > >> > > >> > > >> > Any pointers/documentation on using/extending Arrow for realtime > >> > streaming > >> > cases. (Specifically where a DataFrame is requested, but then it > needs > >> > to > >> > 'grow' as new data arrives, often at high speed). > >> > > >> > Not language specific, just trying to understand the right pattern > >> > for using Arrow for this, and couldn't' find much in the docs. > >> > > >> > > >> > > >> > Regards > >> > > >> > > >> > > >> > Mark. > >> > > >> > > > > > > >
RE: Arrow Flight + Go, Arrow for Realtime
David, Still investigating, but I suspect for streaming I may have to fall back to some form of "custom" Flight implementation over Websockets. Assuming Arrow/Flight actually makes sense for that link, which will probably depend on how well it compresses. However it will be very nice if it does, to allow common format everywhere. The data I need to move around is highly variable in 'type', (Arrays of Floats, Ints & Strings with occasional Binary, or vector (array of an array of floats in my case) but the number of columns, and their type vary by dataset and visualization choices. So far arrow seems a good choice rather than any 'roll your own', and it will be nice to use same format on Client side as well as in the Server system. My use case is primarily 'Get', consuming large datasets for visualization. I doubt I'll need Put or Exchange from the browser. Mark. -Original Message- From: David Li Sent: Saturday, August 15, 2020 5:53 PM To: dev@arrow.apache.org Subject: Re: Arrow Flight + Go, Arrow for Realtime I am curious what you accomplish with Arrow + Flight from the browser. Right now, Flight is all gRPC-based, and browser compatibility is a bit mixed. I expect the various transcoders/gRPC-Web can handle GetFlightInfo/DoGet fine, though IIRC for DoGet, at least some of the transcoders would have to buffer the entire stream before sending it to the browser. DoPut/DoExchange seem harder/impossible to bridge right now due to the bidirectional streaming. Best, David On 8/14/20, m...@markfarnan.com wrote: > Thanks Wes, > > I'll likely work on that once I get my head around Arrow in general > and confirm will use for the project. > > Considerations for how to account for the streaming append problem to an > otherwise immutable dataset is current concern. Still thinking through > that. > > Regards > > Mark. > > -Original Message- > From: Wes McKinney > Sent: Wednesday, August 12, 2020 3:59 PM > To: dev > Subject: Re: Arrow Flight + Go, Arrow for Realtime > > There's a WIP patch for Flight support in Go > > https://github.com/apache/arrow/pull/6731 > > I hope to see someone taking up this work as first-class Flight > support in Go would be very useful for building data services. > > On Wed, Aug 12, 2020 at 5:08 AM Adam Lippai wrote: >> >> Arrow is mainly about batching data and leveraging all the >> opportunities this gives. >> This means you either have to buffer the data yourself and flush it >> when a reasonable sized batch is complete or play with preallocating >> Arrow structures This was discussed recently, you might be interested >> in the thread: >> https://www.mail-archive.com/dev@arrow.apache.org/msg19862.html >> >> Note: I'm not an Arrow developer, I'm just following the "streaming" >> features of the Arrow lib, I'm interested in having a "rolling window" >> API (like a fixed size FIFO queue). >> >> Best regards, >> Adam Lippai >> >> On Wed, Aug 12, 2020 at 11:29 AM wrote: >> >> > I'm looking at using Arrow for a realtime IoT project which >> > includes use cases both on server, and also for transferring /using >> > in a Browser via WASM, and have a few questions. >> > >> > >> > >> > Language in use is Go. >> > >> > >> > >> > Is anyone working on implementing Arrow-Flight in Go ? (According >> > to >> > the feature matrix, nothing ready yet, so wanted to check. >> > >> > >> > >> > Has anyone tried using Apache Arrow in Go WASM (Webassembly) ? if >> > so, >> > any issues ? >> > >> > >> > >> > Any pointers/documentation on using/extending Arrow for realtime >> > streaming >> > cases. (Specifically where a DataFrame is requested, but then it needs >> > to >> > 'grow' as new data arrives, often at high speed). >> > >> > Not language specific, just trying to understand the right pattern >> > for using Arrow for this, and couldn't' find much in the docs. >> > >> > >> > >> > Regards >> > >> > >> > >> > Mark. >> > >> > > >
Re: [DISCUSS] Plasma appears to have been forked, consider deprecating pyarrow.serialization
On Fri, Aug 14, 2020 at 11:56 PM Micah Kornfield wrote: > > > > > Regarding Plasma, you're right we should have started this conversation > > earlier! The way it's being developed in Ray currently isn't useful as a > > standalone project. We realized that tighter integration with Ray's object > > lifetime tracking could be important, and removing IPCs and making it a > > separate thread in the same process as our scheduler could make a big > > difference for performance. Some of these optimizations wouldn't be easy > > without a tight integration, so there are some trade-offs here. > > So I guess the question is whether it is worth continuing to try to > maintain a sepearate version of plasma within the Arrow repo? > What isn't clear is whether the Plasma that's in Ray is usable in a C++ library context (e.g. what we currently ship as libplasma-dev e.g. on Ubuntu/Debian). That seems still useful, but if the project isn't being actively maintained / developed (which, given the series of stale PRs over the last year or two, it doesn't seem to be) it's unclear whether we want to keep shipping it. > On Tue, Jul 21, 2020 at 9:28 AM Robert Nishihara > wrote: > > > Hi all, > > > > Regarding Plasma, you're right we should have started this conversation > > earlier! The way it's being developed in Ray currently isn't useful as a > > standalone project. We realized that tighter integration with Ray's object > > lifetime tracking could be important, and removing IPCs and making it a > > separate thread in the same process as our scheduler could make a big > > difference for performance. Some of these optimizations wouldn't be easy > > without a tight integration, so there are some trade-offs here. > > > > Regarding the Python serialization format, I agree with Antoine that it > > should be deprecated. We began developing it before pickle 5, but now that > > pickle 5 has taken off, it makes less sense (it's useful in its own right, > > but at the end of the day, we were interested in it as a way to serialize > > arbitrary Python objects). > > > > -Robert > > > > On Sun, Jul 12, 2020 at 5:26 PM Wes McKinney wrote: > > > > > I'll add deprecation warnings to the pyarrow.serialize functions in > > > question, it will be pretty simple. > > > > > > On Sun, Jul 12, 2020, 6:34 PM Neal Richardson < > > neal.p.richard...@gmail.com > > > > > > > wrote: > > > > > > > This seems like something to investigate after the 1.0 release. > > > > > > > > Neal > > > > > > > > On Sun, Jul 12, 2020 at 11:53 AM Antoine Pitrou > > > > wrote: > > > > > > > > > > > > > > I'd certainly like to deprecate our custom Python serialization > > format, > > > > > and using pickle protocol 5 instead is a very good idea. > > > > > > > > > > We can probably keep it in 1.0 while raising a FutureWarning. > > > > > > > > > > Regards > > > > > > > > > > Antoine. > > > > > > > > > > > > > > > Le 12/07/2020 à 19:22, Wes McKinney a écrit : > > > > > > It appears that the Ray developers have decided to fork Plasma and > > > > > > decouple from the Arrow codebase: > > > > > > > > > > > > https://github.com/ray-project/ray/pull/9154 > > > > > > > > > > > > This is a disappointing development to occur without any discussion > > > on > > > > > > this mailing list but given the lack of development activity on > > > Plasma > > > > > > I would like to see how others in the community would like to > > > proceed. > > > > > > > > > > > > It appears additionally that the Union-based serialization format > > > > > > implemented by arrow/python/serialize.h and the > > pyarrow/serialize.py > > > > > > has been dropped in favor of pickle5. If there is not value in > > > > > > maintaining this code then it would probably be preferable for us > > to > > > > > > remove this from the codebase. > > > > > > > > > > > > Thanks, > > > > > > Wes > > > > > > > > > > > > > > > > > > > >
Re: Arrow Flight + Go, Arrow for Realtime
I am curious what you accomplish with Arrow + Flight from the browser. Right now, Flight is all gRPC-based, and browser compatibility is a bit mixed. I expect the various transcoders/gRPC-Web can handle GetFlightInfo/DoGet fine, though IIRC for DoGet, at least some of the transcoders would have to buffer the entire stream before sending it to the browser. DoPut/DoExchange seem harder/impossible to bridge right now due to the bidirectional streaming. Best, David On 8/14/20, m...@markfarnan.com wrote: > Thanks Wes, > > I'll likely work on that once I get my head around Arrow in general and > confirm will use for the project. > > Considerations for how to account for the streaming append problem to an > otherwise immutable dataset is current concern. Still thinking through > that. > > Regards > > Mark. > > -Original Message- > From: Wes McKinney > Sent: Wednesday, August 12, 2020 3:59 PM > To: dev > Subject: Re: Arrow Flight + Go, Arrow for Realtime > > There's a WIP patch for Flight support in Go > > https://github.com/apache/arrow/pull/6731 > > I hope to see someone taking up this work as first-class Flight support in > Go would be very useful for building data services. > > On Wed, Aug 12, 2020 at 5:08 AM Adam Lippai wrote: >> >> Arrow is mainly about batching data and leveraging all the >> opportunities this gives. >> This means you either have to buffer the data yourself and flush it >> when a reasonable sized batch is complete or play with preallocating >> Arrow structures This was discussed recently, you might be interested >> in the thread: >> https://www.mail-archive.com/dev@arrow.apache.org/msg19862.html >> >> Note: I'm not an Arrow developer, I'm just following the "streaming" >> features of the Arrow lib, I'm interested in having a "rolling window" >> API (like a fixed size FIFO queue). >> >> Best regards, >> Adam Lippai >> >> On Wed, Aug 12, 2020 at 11:29 AM wrote: >> >> > I'm looking at using Arrow for a realtime IoT project which includes >> > use cases both on server, and also for transferring /using in a >> > Browser via WASM, and have a few questions. >> > >> > >> > >> > Language in use is Go. >> > >> > >> > >> > Is anyone working on implementing Arrow-Flight in Go ? (According >> > to >> > the feature matrix, nothing ready yet, so wanted to check. >> > >> > >> > >> > Has anyone tried using Apache Arrow in Go WASM (Webassembly) ? if >> > so, >> > any issues ? >> > >> > >> > >> > Any pointers/documentation on using/extending Arrow for realtime >> > streaming >> > cases. (Specifically where a DataFrame is requested, but then it needs >> > to >> > 'grow' as new data arrives, often at high speed). >> > >> > Not language specific, just trying to understand the right pattern >> > for using Arrow for this, and couldn't' find much in the docs. >> > >> > >> > >> > Regards >> > >> > >> > >> > Mark. >> > >> > > >
Re: [DISCUSS] Support of higher bit-width Decimal type
On Fri, Aug 14, 2020 at 11:17 PM Micah Kornfield wrote: > > Hi Jacques, > > Do we have a good definition of what is necessary to add a new data type? > > Adding a type but not pulling it through most of the code seems less than > > ideal since it means one part of Arrow doesn't work with another (providing > > a less optimal end-user experience). > > I think what I proposed below is a minimum viable integration plan (and > covers previously discussed requirements for new types). It demonstrates > interop between two reference implementations and allows conversion to/from > idiomatic language analogues. So it covers the basic goal of "arrow > interop". > > > For example, would this work include making Gandiva and all the kernels > > support this new data type where appropriate? > > Not initially. There needs to be a stepping stone to start supporting new > types. I don't think it is feasible to try to land all of this > functionality in one PR. I'll lend a hand at trying get support for > built-in compute after we get the first part done. Since (I think?) there are other data types that Gandiva already does not support, trying to use decimal256 data with Gandiva would raise the same exception that it would raise with an unsupported type. Another option would be to insert an implicit cast to decimal128 as a stopgap. > Thanks, > Micah > > > > On Fri, Aug 14, 2020 at 5:08 PM Jacques Nadeau wrote: > > > Do we have a good definition of what is necessary to add a new data type? > > Adding a type but not pulling it through most of the code seems less than > > ideal since it means one part of Arrow doesn't work with another (providing > > a less optimal end-user experience). > > > > For example, would this work include making Gandiva and all the kernels > > support this new data type where appropriate? > > > > On Wed, Aug 5, 2020 at 12:01 PM Wes McKinney wrote: > > > > > Sounds fine to me. I guess one question is what needs to be formalized > > > in the Schema.fbs files or elsewhere in the columnar format > > > documentation (and we will need to hold an associated vote for that I > > > think) > > > > > > On Mon, Aug 3, 2020 at 11:30 PM Micah Kornfield > > > wrote: > > > > > > > > Given no objections, we'll go ahead and start implementing support for > > > 256-bit decimals. > > > > > > > > I'm considering setting up another branch to develop all the components > > > so they can be merged to master atomically. > > > > > > > > Thanks, > > > > Micah > > > > > > > > On Tue, Jul 28, 2020 at 6:39 AM Wes McKinney > > > wrote: > > > >> > > > >> Generally this sounds fine to me. At some point it would be good to > > > >> add 32-bit and 64-bit decimal support but this can be done in the > > > >> future. > > > >> > > > >> On Tue, Jul 28, 2020 at 7:28 AM Fan Liya > > wrote: > > > >> > > > > >> > Hi Micah, > > > >> > > > > >> > Thanks for opening the discussion. > > > >> > I am aware of some scenarios where decimal requires more than 16 > > > bytes, so > > > >> > I think it would be beneficial to support this in Arrow. > > > >> > > > > >> > Best, > > > >> > Liya Fan > > > >> > > > > >> > > > > >> > On Tue, Jul 28, 2020 at 11:12 AM Micah Kornfield < > > > emkornfi...@gmail.com> > > > >> > wrote: > > > >> > > > > >> > > Hi Arrow Dev, > > > >> > > ZetaSQL (Google's open source standard SQL library) recently > > > introduced a > > > >> > > BigNumeric [1] type which requires a 256 bit width to properly > > > support it. > > > >> > > I'd like to add support (possibly in collaboration with some of my > > > >> > > colleagues) to add support for 256 bit width Decimals in Arrow to > > > support a > > > >> > > type corresponding to BigNumeric. > > > >> > > > > > >> > > In past discussions on this, I don't think we established a > > minimum > > > bar for > > > >> > > supporting additional bit-widths within Arrow. > > > >> > > > > > >> > > I'd like to propose the following requirements: > > > >> > > 1. A vote agreeing on adding support for a new bitwidth (we can > > > discuss > > > >> > > any objections here). > > > >> > > 2. Support in Java and C++ for integration tests verifying the > > > ability to > > > >> > > round-trip the value. > > > >> > > 3. Support in Java for conversion to/from BigDecimal [2] > > > >> > > 4. Support in Python converting to/from Decimal [3] > > > >> > > > > > >> > > Is there anything else that people feel like is a requirement for > > > basic > > > >> > > support of an additional bit width for Decimal's? > > > >> > > > > > >> > > Thanks, > > > >> > > Micah > > > >> > > > > > >> > > > > > >> > > [1] > > > >> > > > > > >> > > > > > > > https://github.com/google/zetasql/blob/1aefaa7c62fc7a50def879bb7c4225ec6974b7ef/zetasql/public/numeric_value.h#L486 > > > >> > > [2] > > > https://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html > > > >> > > [3] https://docs.python.org/3/library/decimal.html > > > >> > > > > > > >
[NIGHTLY] Arrow Build Report for Job nightly-2020-08-15-0
Arrow Build Report for Job nightly-2020-08-15-0 All tasks: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0 Failed Tasks: - test-conda-python-3.7-hdfs-2.9.2: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-github-test-conda-python-3.7-hdfs-2.9.2 - test-conda-python-3.7-kartothek-latest: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-github-test-conda-python-3.7-kartothek-latest - test-conda-python-3.7-kartothek-master: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-github-test-conda-python-3.7-kartothek-master - test-ubuntu-18.04-python-3: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-azure-test-ubuntu-18.04-python-3 - ubuntu-focal-amd64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-github-ubuntu-focal-amd64 Succeeded Tasks: - centos-6-amd64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-github-centos-6-amd64 - centos-7-aarch64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-travis-centos-7-aarch64 - centos-7-amd64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-github-centos-7-amd64 - centos-8-aarch64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-travis-centos-8-aarch64 - centos-8-amd64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-github-centos-8-amd64 - conda-clean: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-azure-conda-clean - conda-linux-gcc-py36-cpu: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-azure-conda-linux-gcc-py36-cpu - conda-linux-gcc-py36-cuda: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-azure-conda-linux-gcc-py36-cuda - conda-linux-gcc-py37-cpu: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-azure-conda-linux-gcc-py37-cpu - conda-linux-gcc-py37-cuda: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-azure-conda-linux-gcc-py37-cuda - conda-linux-gcc-py38-cpu: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-azure-conda-linux-gcc-py38-cpu - conda-linux-gcc-py38-cuda: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-azure-conda-linux-gcc-py38-cuda - conda-osx-clang-py36: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-azure-conda-osx-clang-py36 - conda-osx-clang-py37: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-azure-conda-osx-clang-py37 - conda-osx-clang-py38: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-azure-conda-osx-clang-py38 - conda-win-vs2017-py36: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-azure-conda-win-vs2017-py36 - conda-win-vs2017-py37: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-azure-conda-win-vs2017-py37 - conda-win-vs2017-py38: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-azure-conda-win-vs2017-py38 - debian-buster-amd64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-github-debian-buster-amd64 - debian-buster-arm64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-travis-debian-buster-arm64 - debian-stretch-amd64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-github-debian-stretch-amd64 - debian-stretch-arm64: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-travis-debian-stretch-arm64 - example-cpp-minimal-build-static-system-dependency: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-github-example-cpp-minimal-build-static-system-dependency - example-cpp-minimal-build-static: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-github-example-cpp-minimal-build-static - gandiva-jar-osx: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-travis-gandiva-jar-osx - gandiva-jar-xenial: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-travis-gandiva-jar-xenial - homebrew-cpp: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-travis-homebrew-cpp - homebrew-r-autobrew: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-travis-homebrew-r-autobrew - nuget: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-08-15-0-github-nuget - test-conda-cpp-valgrind: URL:
