Unclear How to Save S3 to Offset

It is very unclear how precisely how one is intended to use the HTTP client to save into a file at some non-0 offset when using the 'SetResponseStreamFactory'.
Specifically, I have a large sparse file (let's say 40gb+) which I would like to fill on-demand.  The only examples I can find for dealing with streams are in https://github.com/awslabs/aws-sdk-cpp/blob/master/aws-cpp-sdk-s3-integration-tests/BucketAndObjectOperationTest.cpp and there doesn't appear to be anything near what I need.
In the same train of thought, this nebulous comment kind of worries me... should it?
// The 'truncate' is required to ensure that if the file download IS successful, then it can be written to the
// FStream (if ::trunc is not specified, then the FStream.write fails for some unknown reason)

You can return anything that inherits from std::iostream in your closure, we haven't implemented something that does what you need, but if you want to do that, you can create some sort of adapter to make it happen.
As for that comment, if the http response returns an error, we write the payload out to the stream, but if the in flag is not turned on, we can't parse the error. Nothing will break if you don't pass that flag, but you will recieve an "UNKNOWN" error if something goes wrong.

One thing you could do is create your file stream in the closure, and then seek it to where you want it to  start. The system should start writing at the seeked position.

And I should not expect any internal retry mechanisms to conflict with this logic?

You can turn retries off or override the retry strategy if you are worried about it. But no, the response stream is recreated for each new request/response cycle (so a retry would just recreate the stream)

One word of caution. This is a use case I haven't thought about very much and in the event of an error coming across the wire, the error will be written to the stream you provide, so you'll either need to handle that, or possibly maintain your file io stuff separately and just use our default response stream, then write the response to your file manually after you've checked the error code.

S3 also has a torrent api, just fyi

Okay, looks like I will steer clear of the untrodden path for now and take the hit from the disk copy.  Thanks.

You don't have to do a disk copy, if you have sufficient ram available, the default stream will use a stringbuffer, but you need to be aware of how large the objects are that you are downloading.

So I tried to implement this, and it appears to be segfaulting.
#include <gtest/gtest.h>
#include <glog/logging.h>

#include <fstream>
#include <memory>

#include "rcp_net/NetFile.hpp"

#include <aws/core/client/ClientConfiguration.h>
#include <aws/core/http/HttpClientFactory.h>
#include <aws/core/http/HttpClient.h>
#include <aws/core/http/HttpRequest.h>
#include <aws/core/http/HttpResponse.h>

using namespace Aws;
using namespace Client;
using namespace Http;

Aws::Client::ClientConfiguration Config;

TEST(NET, Basic) {
    std::shared_ptr<HttpClientFactory> factory(new HttpClientFactory);
    std::shared_ptr<HttpClient> client(factory->CreateHttpClient(Config)); // sigh

    std::string filePath("someTestPath");
    size_t offset = 10;

    std::shared_ptr<HttpRequest> request(
        factory->CreateHttpRequest(
            Aws::String("http://google.com"),
            HttpMethod::HTTP_GET,
            [&filePath, &offset]() -> Aws::IOStream* {
                constexpr auto OpenFlag = std::ios_base::out | std::ios_base::binary;
                Aws::OFStream* ofs = new Aws::OFStream(filePath, OpenFlag);
                CHECK(ofs->good());
                return dynamic_cast<Aws::IOStream*>(ofs);
            }));

    std::shared_ptr<HttpResponse> response = client->MakeRequest(*request); //<-- *** Segfaults there ***
    ASSERT_EQ(HttpResponseCode::OK,
              response->GetResponseCode());

$> valgrind --tool=memcheck ./gtests --gtest_filter='NET.*'
==10845== Memcheck, a memory error detector
==10845== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==10845== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==10845== Command: ./gtests --gtest_filter=NET.*
==10845==
Note: Google Test filter = NET.*
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from NET
[ RUN      ] NET.Basic
==10845== Invalid read of size 8
==10845==    at 0x64F1309: std::ostream::sentry::sentry(std::ostream&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x64F16BD: std::ostream::write(char const*, long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x59089FB: Aws::Http::CurlHttpClient::WriteData(char*, unsigned long, unsigned long, void*) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x7E2DCCF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E474AF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E41CD6: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E4B9DB: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E4C180: curl_multi_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E437B2: curl_easy_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x59098E8: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x4354C3: NET_Basic_Test::TestBody() (test_net.cpp:45)
==10845==    by 0x46E252: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2090)
==10845==  Address 0xe570098 is 24 bytes before a block of size 8,192 alloc'd
==10845==    at 0x4C2B800: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10845==    by 0x64D0497: std::basic_filebuf<char, std::char_traits<char> >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x64D4541: std::basic_filebuf<char, std::char_traits<char> >::open(char const*, std::_Ios_Openmode) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x43511B: std::_Function_handler<std::iostream* (), NET_Basic_Test::TestBody()::{lambda()#1}>::_M_invoke(std::_Any_data const&) (fstream:281)
==10845==    by 0x5911E40: Aws::Utils::Stream::ResponseStream::ResponseStream(std::function<std::iostream* ()> const&) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x5909745: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x4354C3: NET_Basic_Test::TestBody() (test_net.cpp:45)
==10845==    by 0x46E252: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2090)
==10845==    by 0x466E66: testing::Test::Run() (gtest.cc:2162)
==10845==    by 0x466F0D: testing::TestInfo::Run() (gtest.cc:2338)
==10845==    by 0x467014: testing::TestCase::Run() (gtest.cc:2445)
==10845==    by 0x4672B7: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4243)
==10845==
==10845== Invalid read of size 8
==10845==    at 0x64F132B: std::ostream::sentry::sentry(std::ostream&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x64F16BD: std::ostream::write(char const*, long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x59089FB: Aws::Http::CurlHttpClient::WriteData(char*, unsigned long, unsigned long, void*) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x7E2DCCF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E474AF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E41CD6: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E4B9DB: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E4C180: curl_multi_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E437B2: curl_easy_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x59098E8: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x4354C3: NET_Basic_Test::TestBody() (test_net.cpp:45)
==10845==    by 0x46E252: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2090)
==10845==  Address 0xe570098 is 24 bytes before a block of size 8,192 alloc'd
==10845==    at 0x4C2B800: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10845==    by 0x64D0497: std::basic_filebuf<char, std::char_traits<char> >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x64D4541: std::basic_filebuf<char, std::char_traits<char> >::open(char const*, std::_Ios_Openmode) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x43511B: std::_Function_handler<std::iostream* (), NET_Basic_Test::TestBody()::{lambda()#1}>::_M_invoke(std::_Any_data const&) (fstream:281)
==10845==    by 0x5911E40: Aws::Utils::Stream::ResponseStream::ResponseStream(std::function<std::iostream* ()> const&) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x5909745: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x4354C3: NET_Basic_Test::TestBody() (test_net.cpp:45)
==10845==    by 0x46E252: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2090)
==10845==    by 0x466E66: testing::Test::Run() (gtest.cc:2162)
==10845==    by 0x466F0D: testing::TestInfo::Run() (gtest.cc:2338)
==10845==    by 0x467014: testing::TestCase::Run() (gtest.cc:2445)
==10845==    by 0x4672B7: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4243)
==10845==
==10845== Invalid read of size 8
==10845==    at 0x64F16D1: std::ostream::write(char const*, long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x59089FB: Aws::Http::CurlHttpClient::WriteData(char*, unsigned long, unsigned long, void*) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x7E2DCCF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E474AF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E41CD6: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E4B9DB: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E4C180: curl_multi_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E437B2: curl_easy_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x59098E8: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x4354C3: NET_Basic_Test::TestBody() (test_net.cpp:45)
==10845==    by 0x46E252: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2090)
==10845==    by 0x466E66: testing::Test::Run() (gtest.cc:2162)
==10845==  Address 0xe570098 is 24 bytes before a block of size 8,192 alloc'd
==10845==    at 0x4C2B800: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10845==    by 0x64D0497: std::basic_filebuf<char, std::char_traits<char> >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x64D4541: std::basic_filebuf<char, std::char_traits<char> >::open(char const*, std::_Ios_Openmode) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x43511B: std::_Function_handler<std::iostream* (), NET_Basic_Test::TestBody()::{lambda()#1}>::_M_invoke(std::_Any_data const&) (fstream:281)
==10845==    by 0x5911E40: Aws::Utils::Stream::ResponseStream::ResponseStream(std::function<std::iostream* ()> const&) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x5909745: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x4354C3: NET_Basic_Test::TestBody() (test_net.cpp:45)
==10845==    by 0x46E252: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2090)
==10845==    by 0x466E66: testing::Test::Run() (gtest.cc:2162)
==10845==    by 0x466F0D: testing::TestInfo::Run() (gtest.cc:2338)
==10845==    by 0x467014: testing::TestCase::Run() (gtest.cc:2445)
==10845==    by 0x4672B7: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4243)
==10845==
==10845== Jump to the invalid address stated on the next line
==10845==    at 0x8B48FFF9A57AE810: ???
==10845==    by 0x64F16E2: std::ostream::write(char const*, long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x59089FB: Aws::Http::CurlHttpClient::WriteData(char*, unsigned long, unsigned long, void*) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x7E2DCCF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E474AF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E41CD6: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E4B9DB: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E4C180: curl_multi_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E437B2: curl_easy_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x59098E8: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x4354C3: NET_Basic_Test::TestBody() (test_net.cpp:45)
==10845==    by 0x46E252: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2090)
==10845==  Address 0x8b48fff9a57ae810 is not stack'd, malloc'd or (recently) free'd
==10845==
*** Aborted at<PHONE_NUMBER> (unix time) try "date -d @1443730215" if you are using GNU date ***
PC: @ 0x8b48fff9a57ae810 (unknown)
==10845== Syscall param msync(start) points to uninitialised byte(s)
==10845==    at 0x4E46B3D: ??? (syscall-template.S:81)
==10845==    by 0x7C02123: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x7C02643: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x7C04EAA: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x7C06151: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x7C064E8: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x7C02A30: _ULx86_64_step (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x5677442: google::GetStackTrace(void**, int, int) (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==10845==    by 0x567CB31: ??? (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==10845==    by 0x4E4733F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.19.so)
==10845==    by 0x8B48FFF9A57AE80F: ???
==10845==    by 0x64F16E2: std::ostream::write(char const*, long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==  Address 0xffeffe050 is on thread 1's stack
==10845==
==10845== Syscall param msync(start) points to unaddressable byte(s)
==10845==    at 0x4E46B3D: ??? (syscall-template.S:81)
==10845==    by 0x7C02123: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x7C02B31: _ULx86_64_step (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x5677442: google::GetStackTrace(void**, int, int) (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==10845==    by 0x567CB31: ??? (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==10845==    by 0x4E4733F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.19.so)
==10845==    by 0x8B48FFF9A57AE80F: ???
==10845==    by 0x64F16E2: std::ostream::write(char const*, long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x59089FB: Aws::Http::CurlHttpClient::WriteData(char*, unsigned long, unsigned long, void*) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x7E2DCCF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E474AF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E41CD6: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==  Address 0x8b48fff9a57ae000 is not stack'd, malloc'd or (recently) free'd
==10845==
==10845== Syscall param msync(start) points to unaddressable byte(s)
==10845==    at 0x4E46B3D: ??? (syscall-template.S:81)
==10845==    by 0x7C02123: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x7C02BC1: _ULx86_64_step (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x5677442: google::GetStackTrace(void**, int, int) (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==10845==    by 0x567CB31: ??? (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==10845==    by 0x4E4733F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.19.so)
==10845==    by 0x8B48FFF9A57AE80F: ???
==10845==    by 0x64F16E2: std::ostream::write(char const*, long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x59089FB: Aws::Http::CurlHttpClient::WriteData(char*, unsigned long, unsigned long, void*) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x7E2DCCF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E474AF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E41CD6: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==  Address 0xe56f920 is 0 bytes after a block of size 35,984 alloc'd
==10845==    at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10845==    by 0x7E34529: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E435F5: curl_easy_init (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x59083EF: Aws::Http::CurlHandleContainer::CheckAndGrowPool() (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x59085B1: Aws::Http::CurlHandleContainer::AcquireCurlHandle() (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x590964E: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x4354C3: NET_Basic_Test::TestBody() (test_net.cpp:45)
==10845==    by 0x46E252: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2090)
==10845==    by 0x466E66: testing::Test::Run() (gtest.cc:2162)
==10845==    by 0x466F0D: testing::TestInfo::Run() (gtest.cc:2338)
==10845==    by 0x467014: testing::TestCase::Run() (gtest.cc:2445)
==10845==    by 0x4672B7: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4243)
==10845==
*** SIGSEGV (@0x8b48fff9a57ae810) received by PID 10845 (TID 0x405f580) from PID<PHONE_NUMBER>2190879760; stack trace: ***
    @          0x4e47340 (unknown)
    @ 0x8b48fff9a57ae810 (unknown)
==10845==
==10845== HEAP SUMMARY:
==10845==     in use at exit: 576,891 bytes in 6,082 blocks
==10845==   total heap usage: 8,543 allocs, 2,461 frees, 740,617 bytes allocated
==10845==
==10845== LEAK SUMMARY:
==10845==    definitely lost: 0 bytes in 0 blocks
==10845==    indirectly lost: 0 bytes in 0 blocks
==10845==      possibly lost: 9,521 bytes in 211 blocks
==10845==    still reachable: 567,370 bytes in 5,871 blocks
==10845==         suppressed: 0 bytes in 0 blocks
==10845== Rerun with --leak-check=full to see details of leaked memory
==10845==
==10845== For counts of detected and suppressed errors, rerun with: -v
==10845== Use --track-origins=yes to see where uninitialised values come from
==10845== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)

Not sure if this is the problem or not but I don't think ofstream is a
subclass of iostream
On Oct 1, 2015 1:13 PM, "Christopher J. Hanks"<EMAIL_ADDRESS>wrote:

So I tried to implement this, and it appears to be segfaulting.
#include <gtest/gtest.h>
#include <glog/logging.h>
#include
#include
#include "rcp_net/NetFile.hpp"
#include <aws/core/client/ClientConfiguration.h>
#include <aws/core/http/HttpClientFactory.h>
#include <aws/core/http/HttpClient.h>
#include <aws/core/http/HttpRequest.h>
#include <aws/core/http/HttpResponse.h>
using namespace Aws;using namespace Client;using namespace Http;
Aws::Client::ClientConfiguration Config;
TEST(NET, Basic) {
std::shared_ptr factory(new HttpClientFactory);
std::shared_ptr client(factory->CreateHttpClient(Config)); // sigh
std::string filePath("someTestPath");
size_t offset = 10;

std::shared_ptr<HttpRequest> request(
    factory->CreateHttpRequest(
        Aws::String("http://google.com"),
        HttpMethod::HTTP_GET,
        [&filePath, &offset]() -> Aws::IOStream* {
            constexpr auto OpenFlag = std::ios_base::out | std::ios_base::binary;
            Aws::OFStream* ofs = new Aws::OFStream(filePath, OpenFlag);
            CHECK(ofs->good());
            return dynamic_cast<Aws::IOStream*>(ofs);
        }));

std::shared_ptr<HttpResponse> response = client->MakeRequest(*request); //<-- *** Segfaults there ***
ASSERT_EQ(HttpResponseCode::OK,
          response->GetResponseCode());

$> valgrind --tool=memcheck ./gtests --gtest_filter='NET.'
==10845== Memcheck, a memory error detector
==10845== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==10845== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==10845== Command: ./gtests --gtest_filter=NET.
==10845==
Note: Google Test filter = NET.*
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from NET
[ RUN      ] NET.Basic
==10845== Invalid read of size 8
==10845==    at 0x64F1309: std::ostream::sentry::sentry(std::ostream&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x64F16BD: std::ostream::write(char const*, long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x59089FB: Aws::Http::CurlHttpClient::WriteData(char*, unsigned long, unsigned long, void*) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x7E2DCCF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E474AF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E41CD6: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E4B9DB: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E4C180: curl_multi_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E437B2: curl_easy_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x59098E8: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x4354C3: NET_Basic_Test::TestBody() (test_net.cpp:45)
==10845==    by 0x46E252: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::)(), char const) (gtest.cc:2090)
==10845==  Address 0xe570098 is 24 bytes before a block of size 8,192 alloc'd
==10845==    at 0x4C2B800: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10845==    by 0x64D0497: std::basic_filebuf<char, std::char_traits >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x64D4541: std::basic_filebuf<char, std::char_traits >::open(char const*, std::_Ios_Openmode) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x43511B: std::_Function_handler<std::iostream* (), NET_Basic_Test::TestBody()::{lambda()#1}>::_M_invoke(std::_Any_data const&) (fstream:281)
==10845==    by 0x5911E40: Aws::Utils::Stream::ResponseStream::ResponseStream(std::function<std::iostream* ()> const&) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x5909745: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x4354C3: NET_Basic_Test::TestBody() (test_net.cpp:45)
==10845==    by 0x46E252: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::)(), char const) (gtest.cc:2090)
==10845==    by 0x466E66: testing::Test::Run() (gtest.cc:2162)
==10845==    by 0x466F0D: testing::TestInfo::Run() (gtest.cc:2338)
==10845==    by 0x467014: testing::TestCase::Run() (gtest.cc:2445)
==10845==    by 0x4672B7: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4243)
==10845==
==10845== Invalid read of size 8
==10845==    at 0x64F132B: std::ostream::sentry::sentry(std::ostream&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x64F16BD: std::ostream::write(char const*, long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x59089FB: Aws::Http::CurlHttpClient::WriteData(char*, unsigned long, unsigned long, void*) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x7E2DCCF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E474AF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E41CD6: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E4B9DB: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E4C180: curl_multi_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E437B2: curl_easy_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x59098E8: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x4354C3: NET_Basic_Test::TestBody() (test_net.cpp:45)
==10845==    by 0x46E252: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::)(), char const) (gtest.cc:2090)
==10845==  Address 0xe570098 is 24 bytes before a block of size 8,192 alloc'd
==10845==    at 0x4C2B800: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10845==    by 0x64D0497: std::basic_filebuf<char, std::char_traits >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x64D4541: std::basic_filebuf<char, std::char_traits >::open(char const*, std::_Ios_Openmode) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x43511B: std::_Function_handler<std::iostream* (), NET_Basic_Test::TestBody()::{lambda()#1}>::_M_invoke(std::_Any_data const&) (fstream:281)
==10845==    by 0x5911E40: Aws::Utils::Stream::ResponseStream::ResponseStream(std::function<std::iostream* ()> const&) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x5909745: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x4354C3: NET_Basic_Test::TestBody() (test_net.cpp:45)
==10845==    by 0x46E252: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::)(), char const) (gtest.cc:2090)
==10845==    by 0x466E66: testing::Test::Run() (gtest.cc:2162)
==10845==    by 0x466F0D: testing::TestInfo::Run() (gtest.cc:2338)
==10845==    by 0x467014: testing::TestCase::Run() (gtest.cc:2445)
==10845==    by 0x4672B7: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4243)
==10845==
==10845== Invalid read of size 8
==10845==    at 0x64F16D1: std::ostream::write(char const*, long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x59089FB: Aws::Http::CurlHttpClient::WriteData(char*, unsigned long, unsigned long, void*) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x7E2DCCF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E474AF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E41CD6: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E4B9DB: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E4C180: curl_multi_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E437B2: curl_easy_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x59098E8: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x4354C3: NET_Basic_Test::TestBody() (test_net.cpp:45)
==10845==    by 0x46E252: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::)(), char const) (gtest.cc:2090)
==10845==    by 0x466E66: testing::Test::Run() (gtest.cc:2162)
==10845==  Address 0xe570098 is 24 bytes before a block of size 8,192 alloc'd
==10845==    at 0x4C2B800: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10845==    by 0x64D0497: std::basic_filebuf<char, std::char_traits >::_M_allocate_internal_buffer() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x64D4541: std::basic_filebuf<char, std::char_traits >::open(char const*, std::_Ios_Openmode) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x43511B: std::_Function_handler<std::iostream* (), NET_Basic_Test::TestBody()::{lambda()#1}>::_M_invoke(std::_Any_data const&) (fstream:281)
==10845==    by 0x5911E40: Aws::Utils::Stream::ResponseStream::ResponseStream(std::function<std::iostream* ()> const&) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x5909745: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x4354C3: NET_Basic_Test::TestBody() (test_net.cpp:45)
==10845==    by 0x46E252: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::)(), char const) (gtest.cc:2090)
==10845==    by 0x466E66: testing::Test::Run() (gtest.cc:2162)
==10845==    by 0x466F0D: testing::TestInfo::Run() (gtest.cc:2338)
==10845==    by 0x467014: testing::TestCase::Run() (gtest.cc:2445)
==10845==    by 0x4672B7: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4243)
==10845==
==10845== Jump to the invalid address stated on the next line
==10845==    at 0x8B48FFF9A57AE810: ???
==10845==    by 0x64F16E2: std::ostream::write(char const*, long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x59089FB: Aws::Http::CurlHttpClient::WriteData(char*, unsigned long, unsigned long, void*) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x7E2DCCF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E474AF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E41CD6: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E4B9DB: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E4C180: curl_multi_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E437B2: curl_easy_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x59098E8: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x4354C3: NET_Basic_Test::TestBody() (test_net.cpp:45)
==10845==    by 0x46E252: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::)(), char const) (gtest.cc:2090)
==10845==  Address 0x8b48fff9a57ae810 is not stack'd, malloc'd or (recently) free'd
==10845==
*** Aborted at<PHONE_NUMBER> (unix time) try "date -d @1443730215" if you are using GNU date ***
PC: @ 0x8b48fff9a57ae810 (unknown)
==10845== Syscall param msync(start) points to uninitialised byte(s)
==10845==    at 0x4E46B3D: ??? (syscall-template.S:81)
==10845==    by 0x7C02123: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x7C02643: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x7C04EAA: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x7C06151: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x7C064E8: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x7C02A30: _ULx86_64_step (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x5677442: google::GetStackTrace(void**, int, int) (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==10845==    by 0x567CB31: ??? (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==10845==    by 0x4E4733F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.19.so)
==10845==    by 0x8B48FFF9A57AE80F: ???
==10845==    by 0x64F16E2: std::ostream::write(char const*, long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==  Address 0xffeffe050 is on thread 1's stack
==10845==
==10845== Syscall param msync(start) points to unaddressable byte(s)
==10845==    at 0x4E46B3D: ??? (syscall-template.S:81)
==10845==    by 0x7C02123: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x7C02B31: _ULx86_64_step (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x5677442: google::GetStackTrace(void**, int, int) (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==10845==    by 0x567CB31: ??? (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==10845==    by 0x4E4733F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.19.so)
==10845==    by 0x8B48FFF9A57AE80F: ???
==10845==    by 0x64F16E2: std::ostream::write(char const*, long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x59089FB: Aws::Http::CurlHttpClient::WriteData(char*, unsigned long, unsigned long, void*) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x7E2DCCF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E474AF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E41CD6: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==  Address 0x8b48fff9a57ae000 is not stack'd, malloc'd or (recently) free'd
==10845==
==10845== Syscall param msync(start) points to unaddressable byte(s)
==10845==    at 0x4E46B3D: ??? (syscall-template.S:81)
==10845==    by 0x7C02123: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x7C02BC1: _ULx86_64_step (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==10845==    by 0x5677442: google::GetStackTrace(void**, int, int) (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==10845==    by 0x567CB31: ??? (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==10845==    by 0x4E4733F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.19.so)
==10845==    by 0x8B48FFF9A57AE80F: ???
==10845==    by 0x64F16E2: std::ostream::write(char const*, long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==10845==    by 0x59089FB: Aws::Http::CurlHttpClient::WriteData(char*, unsigned long, unsigned long, void*) (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x7E2DCCF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E474AF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E41CD6: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==  Address 0xe56f920 is 0 bytes after a block of size 35,984 alloc'd
==10845==    at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10845==    by 0x7E34529: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x7E435F5: curl_easy_init (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==10845==    by 0x59083EF: Aws::Http::CurlHandleContainer::CheckAndGrowPool() (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x59085B1: Aws::Http::CurlHandleContainer::AcquireCurlHandle() (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x590964E: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const (in /usr/lib/libaws-cpp-sdk-core.so)
==10845==    by 0x4354C3: NET_Basic_Test::TestBody() (test_net.cpp:45)
==10845==    by 0x46E252: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::)(), char const) (gtest.cc:2090)
==10845==    by 0x466E66: testing::Test::Run() (gtest.cc:2162)
==10845==    by 0x466F0D: testing::TestInfo::Run() (gtest.cc:2338)
==10845==    by 0x467014: testing::TestCase::Run() (gtest.cc:2445)
==10845==    by 0x4672B7: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4243)
==10845==
*** SIGSEGV (@0x8b48fff9a57ae810) received by PID 10845 (TID 0x405f580) from PID<PHONE_NUMBER>2190879760; stack trace: ***
@          0x4e47340 (unknown)
@ 0x8b48fff9a57ae810 (unknown)
==10845==
==10845== HEAP SUMMARY:
==10845==     in use at exit: 576,891 bytes in 6,082 blocks
==10845==   total heap usage: 8,543 allocs, 2,461 frees, 740,617 bytes allocated
==10845==
==10845== LEAK SUMMARY:
==10845==    definitely lost: 0 bytes in 0 blocks
==10845==    indirectly lost: 0 bytes in 0 blocks
==10845==      possibly lost: 9,521 bytes in 211 blocks
==10845==    still reachable: 567,370 bytes in 5,871 blocks
==10845==         suppressed: 0 bytes in 0 blocks
==10845== Rerun with --leak-check=full to see details of leaked memory
==10845==
==10845== For counts of detected and suppressed errors, rerun with: -v
==10845== Use --track-origins=yes to see where uninitialised values come from
==10845== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)
—
Reply to this email directly or view it on GitHub
https://github.com/awslabs/aws-sdk-cpp/issues/21#issuecomment-144834744.

Yes apologies, I have corrected the example so that no wild casting is required (that was a clip from one of my debugging permutations).

Did you rerun after making that change?
On Oct 1, 2015 1:19 PM, "Christopher J. Hanks"<EMAIL_ADDRESS>wrote:

Yes apologies, I have corrected the example so that no wild casting is
required (that was a clip from one of my debugging permutations).
—
Reply to this email directly or view it on GitHub
https://github.com/awslabs/aws-sdk-cpp/issues/21#issuecomment-144835928.

==11261== Memcheck, a memory error detector
==11261== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==11261== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==11261== Command: ./gtests --gtest_filter=NET.*
==11261==
Note: Google Test filter = NET.*
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from NET
[ RUN      ] NET.Basic
==11261== Mismatched free() / delete / delete []
==11261==    at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11261==    by 0x5911E80: Aws::Utils::Stream::ResponseStream::ReleaseStream() (in /usr/lib/libaws-cpp-sdk-core.so)
==11261==    by 0x5907C86: Aws::Http::Standard::StandardHttpResponse::~StandardHttpResponse() (in /usr/lib/libaws-cpp-sdk-core.so)
==11261==    by 0x435B78: NET_Basic_Test::TestBody() (shared_ptr_base.h:144)
==11261==    by 0x46E602: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2090)
==11261==    by 0x467216: testing::Test::Run() (gtest.cc:2162)
==11261==    by 0x4672BD: testing::TestInfo::Run() (gtest.cc:2338)
==11261==    by 0x4673C4: testing::TestCase::Run() (gtest.cc:2445)
==11261==    by 0x467667: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4243)
==11261==    by 0x467906: testing::UnitTest::Run() (gtest.cc:2090)
==11261==    by 0x410EA1: main (main.cpp:12)
==11261==  Address 0xe56fbf0 is 0 bytes inside a block of size 528 alloc'd
==11261==    at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11261==    by 0x4350CA: std::_Function_handler<std::iostream* (), NET_Basic_Test::TestBody()::{lambda()#1}>::_M_invoke(std::_Any_data const&) (test_net.cpp:36)
==11261==    by 0x5911E40: Aws::Utils::Stream::ResponseStream::ResponseStream(std::function<std::iostream* ()> const&) (in /usr/lib/libaws-cpp-sdk-core.so)
==11261==    by 0x5909745: Aws::Http::CurlHttpClient::MakeRequest(Aws::Http::HttpRequest&, Aws::Utils::RateLimits::RateLimiterInterface*, Aws::Utils::RateLimits::RateLimiterInterface*) const (in /usr/lib/libaws-cpp-sdk-core.so)
==11261==    by 0x4355C4: NET_Basic_Test::TestBody() (test_net.cpp:41)
==11261==    by 0x46E602: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2090)
==11261==    by 0x467216: testing::Test::Run() (gtest.cc:2162)
==11261==    by 0x4672BD: testing::TestInfo::Run() (gtest.cc:2338)
==11261==    by 0x4673C4: testing::TestCase::Run() (gtest.cc:2445)
==11261==    by 0x467667: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4243)
==11261==    by 0x467906: testing::UnitTest::Run() (gtest.cc:2090)
==11261==    by 0x410EA1: main (main.cpp:12)
==11261==
==11261== Invalid free() / delete / delete[] / realloc()
==11261==    at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11261==    by 0x435D0E: NET_Basic_Test::TestBody() (basic_string.h:249)
==11261==    by 0x46E602: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2090)
==11261==    by 0x467216: testing::Test::Run() (gtest.cc:2162)
==11261==    by 0x4672BD: testing::TestInfo::Run() (gtest.cc:2338)
==11261==    by 0x4673C4: testing::TestCase::Run() (gtest.cc:2445)
==11261==    by 0x467667: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4243)
==11261==    by 0x467906: testing::UnitTest::Run() (gtest.cc:2090)
==11261==    by 0x410EA1: main (main.cpp:12)
==11261==  Address 0x5b30500 is in the BSS segment of /usr/lib/libaws-cpp-sdk-core.so
==11261==
==11261== Invalid free() / delete / delete[] / realloc()
==11261==    at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11261==    by 0x435DCE: NET_Basic_Test::TestBody() (basic_string.h:249)
==11261==    by 0x46E602: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2090)
==11261==    by 0x467216: testing::Test::Run() (gtest.cc:2162)
==11261==    by 0x4672BD: testing::TestInfo::Run() (gtest.cc:2338)
==11261==    by 0x4673C4: testing::TestCase::Run() (gtest.cc:2445)
==11261==    by 0x467667: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4243)
==11261==    by 0x467906: testing::UnitTest::Run() (gtest.cc:2090)
==11261==    by 0x410EA1: main (main.cpp:12)
==11261==  Address 0x5b30500 is in the BSS segment of /usr/lib/libaws-cpp-sdk-core.so
==11261==
==11261== Invalid free() / delete / delete[] / realloc()
==11261==    at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11261==    by 0x435DF7: NET_Basic_Test::TestBody() (basic_string.h:249)
==11261==    by 0x46E602: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2090)
==11261==    by 0x467216: testing::Test::Run() (gtest.cc:2162)
==11261==    by 0x4672BD: testing::TestInfo::Run() (gtest.cc:2338)
==11261==    by 0x4673C4: testing::TestCase::Run() (gtest.cc:2445)
==11261==    by 0x467667: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4243)
==11261==    by 0x467906: testing::UnitTest::Run() (gtest.cc:2090)
==11261==    by 0x410EA1: main (main.cpp:12)
==11261==  Address 0x5b30500 is in the BSS segment of /usr/lib/libaws-cpp-sdk-core.so
==11261==
==11261== Invalid free() / delete / delete[] / realloc()
==11261==    at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11261==    by 0x435DA5: NET_Basic_Test::TestBody() (basic_string.h:249)
==11261==    by 0x46E602: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2090)
==11261==    by 0x467216: testing::Test::Run() (gtest.cc:2162)
==11261==    by 0x4672BD: testing::TestInfo::Run() (gtest.cc:2338)
==11261==    by 0x4673C4: testing::TestCase::Run() (gtest.cc:2445)
==11261==    by 0x467667: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4243)
==11261==    by 0x467906: testing::UnitTest::Run() (gtest.cc:2090)
==11261==    by 0x410EA1: main (main.cpp:12)
==11261==  Address 0x5b30500 is in the BSS segment of /usr/lib/libaws-cpp-sdk-core.so
==11261==
==11261== Mismatched free() / delete / delete []
==11261==    at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11261==    by 0x435E20: NET_Basic_Test::TestBody() (basic_string.h:249)
==11261==    by 0x46E602: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2090)
==11261==    by 0x467216: testing::Test::Run() (gtest.cc:2162)
==11261==    by 0x4672BD: testing::TestInfo::Run() (gtest.cc:2338)
==11261==    by 0x4673C4: testing::TestCase::Run() (gtest.cc:2445)
==11261==    by 0x467667: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4243)
==11261==    by 0x467906: testing::UnitTest::Run() (gtest.cc:2090)
==11261==    by 0x410EA1: main (main.cpp:12)
==11261==  Address 0xe5089f0 is 0 bytes inside a block of size 84 alloc'd
==11261==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11261==    by 0x58E5D87: char* std::basic_string<char, std::char_traits<char>, Aws::Allocator<char> >::_S_construct<char*>(char*, char*, Aws::Allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/libaws-cpp-sdk-core.so)
==11261==    by 0x58FD22B: Aws::Client::ComputeUserAgentString() (in /usr/lib/libaws-cpp-sdk-core.so)
==11261==    by 0x58FD50D: Aws::Client::ClientConfiguration::ClientConfiguration() (in /usr/lib/libaws-cpp-sdk-core.so)
==11261==    by 0x43545B: NET_Basic_Test::TestBody() (test_net.cpp:23)
==11261==    by 0x46E602: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (gtest.cc:2090)
==11261==    by 0x467216: testing::Test::Run() (gtest.cc:2162)
==11261==    by 0x4672BD: testing::TestInfo::Run() (gtest.cc:2338)
==11261==    by 0x4673C4: testing::TestCase::Run() (gtest.cc:2445)
==11261==    by 0x467667: testing::internal::UnitTestImpl::RunAllTests() (gtest.cc:4243)
==11261==    by 0x467906: testing::UnitTest::Run() (gtest.cc:2090)
==11261==    by 0x410EA1: main (main.cpp:12)
==11261==
[       OK ] NET.Basic (1543 ms)
[----------] 1 test from NET (1558 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (1587 ms total)
[  PASSED  ] 1 test.
==11261==
==11261== HEAP SUMMARY:
==11261==     in use at exit: 180,644 bytes in 3,357 blocks
==11261==   total heap usage: 8,593 allocs, 5,240 frees, 744,842 bytes allocated
==11261==
==11261== LEAK SUMMARY:
==11261==    definitely lost: 0 bytes in 0 blocks
==11261==    indirectly lost: 0 bytes in 0 blocks
==11261==      possibly lost: 1,652 bytes in 25 blocks
==11261==    still reachable: 178,992 bytes in 3,332 blocks
==11261==         suppressed: 0 bytes in 0 blocks
==11261== Rerun with --leak-check=full to see details of leaked memory
==11261==
==11261== For counts of detected and suppressed errors, rerun with: -v
==11261== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 0 from 0)

If you compiled the library with custom memory management turned on, are you passing -DAWS_CUSTOM_MEMORY_MANAGEMENT to your compiler for your test program?
It looks like the allocators and deallocators are mismatched.

# LIBRARY BUILD
buildro=install_root
cmake \
    CMakeLists.txt \
    -DCMAKE_BUILD_TYPE=Release  \
    -DCMAKE_INSTALL_PREFIX=${buildro}/usr \
    -DSDK_INSTALL_BINARY_PREFIX=${buildro}/usr/lib \
    -DTARGET_ARCH=LINUX

make -j8
make install

// Recreate.cpp
#include <gtest/gtest.h>
#include <glog/logging.h>

#include <fstream>
#include <memory>

#include <aws/core/client/ClientConfiguration.h>
#include <aws/core/http/HttpClientFactory.h>
#include <aws/core/http/HttpClient.h>
#include <aws/core/http/HttpRequest.h>
#include <aws/core/http/HttpResponse.h>

using namespace Aws;
using namespace Client;
using namespace Http;

int
main() {
    Aws::Client::ClientConfiguration Config;
    std::shared_ptr<HttpClientFactory> factory(new HttpClientFactory);
    std::shared_ptr<HttpClient> client(factory->CreateHttpClient(Config)); // sigh

    std::string filePath("someTestPath");
    size_t offset = 10;

    std::shared_ptr<HttpRequest> request(
        factory->CreateHttpRequest(
            Aws::String("http://google.com"),
            HttpMethod::HTTP_GET,
            [&filePath, &offset]() -> Aws::IOStream* {
                constexpr auto OpenFlag = std::ios_base::out | std::ios_base::binary;
                Aws::IOStream* ofs = new Aws::FStream(filePath, OpenFlag);
                CHECK(ofs->good());
                return ofs;
            }));

    do {
        std::shared_ptr<HttpResponse> response = client->MakeRequest(*request);
        assert(HttpResponseCode::OK == response->GetResponseCode());
    } while (0);
    return 0;
}

*** Error in `/tmp/a.out': free(): invalid pointer: 0x00007ffff7ba1500 ***
...
(gdb) bt
#0  0x00007ffff6fe5cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff6fe90d8 in __GI_abort () at abort.c:89
#2  0x00007ffff7022394 in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7ffff7130b28 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff702e66e in malloc_printerr (ptr=<optimized out>, str=0x7ffff712cc19 "free(): invalid pointer", action=1) at malloc.c:4996
#4  _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:3840
#5  0x00007ffff76581c0 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x0000000000401f10 in Aws::Client::ClientConfiguration::~ClientConfiguration() ()
#7  0x0000000000401972 in main ()

Error is same with or without -DAWS_CUSTOM_MEMORY_MANAGEMENT

by default, the library script you just specified will use custom memory management with dynamic linking.
How are you compiling Recreate.cpp ? Can I see the command?

% g++ Recreate.cpp -std=c++11 -lglog -laws-cpp-sdk-core -DDAWS_CUSTOM_MEMORY_MANAGEMENT

it's just -DAWS_CUSTOM_MEMORY_MANAGMENT not
-DDAWS_CUSTOM_MEMORY_MANAGEMENT
Also, you are mixing non managed and managed types.
comments in line:
int
main() {
Aws::Client::ClientConfiguration Config;
std::shared_ptr factory(new HttpClientFactory);
std::shared_ptr client(factory->CreateHttpClient(Config)); // sigh
<------
//sorry, I know that's inconvenient. I'd just do
HttpClientFactory factory;
std::shared_ptr client(factory.CreateHttpClient(Config));
------>
std::string filePath("someTestPath");

<------
//This is going to cause problems when you pass it to a type we manage. Instead, do this:
Aws::String filePath("someTestPath");
//or
const char* filePath = "someTestPath";
------>
size_t offset = 10;
std::shared_ptr<HttpRequest> request(
    factory->CreateHttpRequest(
        Aws::String("http://google.com"),
        HttpMethod::HTTP_GET,
        [&filePath, &offset]() -> Aws::IOStream* {
            constexpr auto OpenFlag = std::ios_base::out | std::ios_base::binary;
            Aws::IOStream* ofs = new Aws::FStream(filePath, OpenFlag);
            CHECK(ofs->good());
            return ofs;
        }));

<----------------
//The "new Aws::FStream" is going to segfault.
//we take ownership of this pointer and clean it up when we finish using our deallocators
//it should be
Aws::IOStream* ofs = Aws::NewAws::FStream("some tag", filePath, OpenFlag);
-------------->
do {
    std::shared_ptr<HttpResponse> response = client->MakeRequest(*request);
    assert(HttpResponseCode::OK == response->GetResponseCode());
} while (0);
return 0;

}

Okay, so we are pretty close...
// g++ -std=c++11 Recreate.cpp -laws-cpp-sdk-core  -DAWS_CUSTOM_MEMORY_MANAGEMENT -lglog
#include <gtest/gtest.h>
#include <glog/logging.h>

#include <fstream>
#include <memory>
#include <string>

#include <aws/core/client/ClientConfiguration.h>
#include <aws/core/http/HttpClientFactory.h>
#include <aws/core/http/HttpClient.h>
#include <aws/core/http/HttpRequest.h>
#include <aws/core/http/HttpResponse.h>

using namespace Aws;
using namespace Client;
using namespace Http;

int
main() {
    Aws::Client::ClientConfiguration Config;
    HttpClientFactory factory;
    std::shared_ptr<HttpClient> client(factory.CreateHttpClient(Config));

    Aws::String filePath("someTestPath");
    size_t offset = 10;

    std::shared_ptr<HttpRequest> request(
        factory.CreateHttpRequest(
            Aws::String("http://google.com"),
            HttpMethod::HTTP_GET,
            [&filePath, &offset]() -> Aws::IOStream* {
                constexpr auto OpenFlag = std::ios_base::out | std::ios_base::binary;
                Aws::IOStream* ofs = Aws::New<Aws::FStream>("BOGUS", filePath.c_str(), OpenFlag);
                CHECK(ofs->good());
                CHECK(ofs->seekp(offset, ofs->beg));
                return ofs;
            }));

    std::shared_ptr<HttpResponse> response = client->MakeRequest(*request);
    assert(HttpResponseCode::OK == response->GetResponseCode());

    return 0;
}

This code does everything my heart currently desires.  But there a few curious things.

I had to change Aws::NewAws::FStream to  Aws::New<Aws::FStream>, is that correct?
Why must the second argument of Aws::New<Aws::FStream>( be converted to a C string?  Without it the overload is apparently ambiguous

% g++ -std=c++11 test_net.cpp -laws-cpp-sdk-core  -DAWS_CUSTOM_MEMORY_MANAGEMENT -lglog
In file included from /usr/include/aws/core/utils/memory/stl/AWSAllocator.h:20:0,
                 from /usr/include/aws/core/utils/memory/stl/AWSString.h:20,
                 from /usr/include/aws/core/http/Scheme.h:20,
                 from /usr/include/aws/core/client/ClientConfiguration.h:21,
                 from test_net.cpp:8:
/usr/include/aws/core/utils/memory/AWSMemory.h: In instantiation of ‘T* Aws::New(const char*, ArgTypes&& ...) [with T = std::basic_fstream<char>; ArgTypes = {std::basic_string<char, std::char_traits<char>, Aws::Allocator<char> >&, const std::_Ios_Openmode&}]’:
test_net.cpp:33:88:   required from here
/usr/include/aws/core/utils/memory/AWSMemory.h:54:77: error: no matching function for call to ‘std::basic_fstream<char>::basic_fstream(std::basic_string<char, std::char_traits<char>, Aws::Allocator<char> >&, const std::_Ios_Openmode&)’
     T *constructedMemory = new (rawMemory) T(std::forward<ArgTypes>(args)...);
                                                                             ^
/usr/include/aws/core/utils/memory/AWSMemory.h:54:77: note: candidates are:
In file included from test_net.cpp:4:0:
/usr/include/c++/4.8/fstream:831:7: note: std::basic_fstream<_CharT, _Traits>::basic_fstream(const string&, std::ios_base::openmode) [with _CharT = char; _Traits = std::char_traits<char>; std::string = std::basic_string<char>; std::ios_base::openmode = std::_Ios_Openmode]
       basic_fstream(const std::string& __s,
       ^
/usr/include/c++/4.8/fstream:831:7: note:   no known conversion for argument 1 from ‘std::basic_string<char, std::char_traits<char>, Aws::Allocator<char> >’ to ‘const string& {aka const std::basic_string<char>&}’
/usr/include/c++/4.8/fstream:816:7: note: std::basic_fstream<_CharT, _Traits>::basic_fstream(const char*, std::ios_base::openmode) [with _CharT = char; _Traits = std::char_traits<char>; std::ios_base::openmode = std::_Ios_Openmode]
       basic_fstream(const char* __s,
       ^
/usr/include/c++/4.8/fstream:816:7: note:   no known conversion for argument 1 from ‘std::basic_string<char, std::char_traits<char>, Aws::Allocator<char> >’ to ‘const char*’
/usr/include/c++/4.8/fstream:803:7: note: std::basic_fstream<_CharT, _Traits>::basic_fstream() [with _CharT = char; _Traits = std::char_traits<char>]
       basic_fstream()
       ^
/usr/include/c++/4.8/fstream:803:7: note:   candidate expects 0 arguments, 2 provided

Should I expect this code to work if I disable memory management?

Thank you for your help.

Yes, that's what I typed but markdown and all........
I'm not sure, if I had to guess,

http://en.cppreference.com/w/cpp/io/basic_fstream/basic_fstream
the stdlib authors hard coded std::string which is incompatible with the aliased types (if memory management is turned on).

Yes, this code should work regardless of whether or not you are actually using custom memory managers.

Thanks.


Sync stage to main

MWPW-156461 fix fragments
MWPW-156114 allow custom gradient, bgColor and textColor for columns block

Test URLs:

Before: https://main--express--adobecom.hlx.live/express/
After: https://stage--express--adobecom.hlx.live/express/

Codecov Report
Attention: Patch coverage is 34.61538% with 17 lines in your changes missing coverage. Please review.

Project coverage is 40.21%. Comparing base (86f2615) to head (ef1eb28).
Report is 472 commits behind head on main.

Files
Patch %
Lines

express/scripts/utils.js
0.00%
13 Missing :warning:

express/blocks/columns/columns.js
69.23%
4 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1067      +/-   ##
==========================================
+ Coverage   36.42%   40.21%   +3.78%
==========================================
  Files         132       96      -36
  Lines       25932    22587    -3345
==========================================
- Hits         9447     9084     -363
+ Misses      16485    13503    -2982

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Accessing store and other services from

I'm trying to write an integration test for a component which touches the store service like this:
moduleForComponent('my-cool-component', {
  integration: true,
  beforeEach: function() {
    this.registry.injection('component:my-cool-component', 'store', 'service:store');
  }
});

test('Can load saved state', function(assert) {
  assert.expect(1);

  this.render(`
    {{my-cool-component}}
  `);

  assert.ok(false);
  stop();
});

What I'm getting is:
at Object.TestLoader.loadModules (http://<IP_ADDRESS>:4200/assets/test-loader.js:21:18): Attempting to inject an unknown injection: service:store`
Is this supported at all or am I missing something?

My latest PR should address this, and make sure that the store is available in this case. Needs review by @dgeb though to vet it...
As an aside: You shouldn't use initializer style injections for this (use Ember.inject.service() in the component).

Thank you for the note about Ember.inject.service(). That's corrected and the  DS._setupContainer(this.registry) workaround from another post does actually work for now.
I'll look forward to the merge!
A side question: What's the recommended way to push a model to the context of component test, eg:
test('Can process subgroups', function(assert) {

  this.set('groupModel', GroupModel.create({id: 1}));
  this.render(`
    {{subgroups-of group=groupModel}}
  `);

  assert.ok(false);
});

Nice work fixing this, I own you :beers:


php language server is crashed in version 1.13.1

VSCode Version: 1.13.1
OS Version: Ubuntu 16.04 LTS @ Gnome

Linux desktop16 4.4.0-81-generic #104-Ubuntu SMP Wed Jun 14 08:17:06 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Steps to Reproduce:

update to version 1.13.1
open a php project
output:

[Info  - 12:22:13 PM] Connection to server got closed. Server will restart.
[Info  - 12:22:14] PM Connection to server got closed. Server will restart.
[Info  - 12:22:15 PM] Connection to server got closed. Server will restart.
[Info  - 12:22:22 PM] Connection to server got closed. Server will restart.
[Error - 12:22:23 PM] Connection to server got closed. Server will not be restarted.
can not search for php symbol.

Can you open an issue on https://github.com/felixfbecker/php-language-server and tell us which version of PHP you are using?


ProgressBar::with_message does nothing?

I couldn't find an example or an existing issue about this. What does the message do?
Minimal example:
use std::{thread, time::Duration};

use indicatif::ProgressBar;

fn main() {
    let pb = ProgressBar::new(100).with_message("Frobbing the widget");
    for _ in 0..100 {
        thread::sleep(Duration::from_millis(30));
        pb.inc(1);
    }
}

Right, I suppose the API is a little confusing. with_message() sets a message, but the message only shows up if you're using a template that includes a {message} field. Want to submit a documentation clarification PR?

So something like
use std::{thread, time::Duration};

use indicatif::{ProgressBar, ProgressStyle};

fn main() {
    let style = ProgressStyle::with_template("{message} {wide_bar} {pos}/{len}")
        .expect("compile-time constant");
    let pb = ProgressBar::new(100)
        .with_style(style)
        .with_message("Frobbing the widget");
    for _ in 0..100 {
        thread::sleep(Duration::from_millis(30));
        pb.inc(1);
    }
}

?

Yup!

But it still doesn't show up :smile:.

But it still doesn't show up 😄.

Instead of {message}, it should be {msg}


Update CI dependencies

actions-rs uses deprecated features, move to dtolney for the toolchain and just use regular run commands for everything else

bors r+


[WIP]test: try fix zookeeper UT failed

[ ] I have registered the PR changes.

Ⅰ. Describe what this PR did
try fix zookeeper UT failed
Ⅱ. Does this pull request fix one issue?

fixes #5923
fixes #5952
Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

first round: https://github.com/seata/seata/actions/runs/6639838130/job/18039020531?pr=5960
I will retry the CICD workflow.

second round: https://github.com/seata/seata/actions/runs/6639838130/job/18039331533?pr=5960

third round: https://github.com/seata/seata/actions/runs/6639838130/job/18039805703?pr=5960

all the check pass.


fix(ingest/bigquery): Fix BigQueryTableType enum accesses

Checklist

[ ] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[ ] Links to related issues (if applicable)
[ ] Tests for the changes have been added/updated (if applicable)
[ ] Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.
[ ] For any breaking change/potential downtime/deprecation/big changes an entry has been made in Updating DataHub

Codecov Report
Patch coverage: 100.00% and project coverage change: -8.33 :warning:

Comparison is base (1324231) 74.87% compared to head (c5a6f58) 66.55%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #7685      +/-   ##
==========================================
- Coverage   74.87%   66.55%   -8.33%
==========================================
  Files         353      353
  Lines       35386    35385       -1
==========================================
- Hits        26496    23550    -2946
- Misses       8890    11835    +2945

Flag
Coverage Δ

pytest-testIntegration
?

pytest-testIntegrationBatch1
36.46% <100.00%> (-0.01%)
:arrow_down:

pytest-testQuick
63.55% <100.00%> (+<0.01%)
:arrow_up:

pytest-testSlowIntegration
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...ub/ingestion/source/bigquery_v2/bigquery_schema.py
66.44% <100.00%> (-0.23%)
:arrow_down:

... and 80 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Training gets stuck on GeForce RTX 2080 Ti

I'm training semantic-segmentation networks, along the lines of #288.
The code works great on GeForce GTX products, but with new RTX hardware training gets stuck randomly. Looks like a race condition or similar, because the freeze happens after multiple iterations and usually after different number of iterations (from run to run).
Using CUDA 10 and cuDNN 7.3 on 64-bit Windows (but same issue with CUDA 8 and cuDNN 5). Latest master from GitHub. MSVC debugger shows the code is waiting on this line.
Because steps to reproduce include acquisition of RTX hardware, I'll rather spend time trying to debug the issue than writing a complete set of steps – at least at this point.

That's weird.  cudaStreamSynchronize should never hang forever. It might be a bug in CUDA.  What happens if you comment out the call to cudaStreamSynchronize?  Does it stop hanging?

I agree that this might be a bug in CUDA.
The process consumes 100% of one CPU core while it's in cudaStreamSynchronize.
If I change cudaStreamSynchronize to a loop that polls cudaStreamQuery until cudaSuccess is returned, it seems that the problem goes away. But need more testing to be sure about it.

Interestingly, I haven't been able to reproduce this problem using the semantic segmentation example. But I guess this is normal if it's a race condition or similar – given our application and data, the bottlenecks are surely in somewhat different places, than with the example program/data.

@reunanen I've started seeing the same thing, with the call to cudaStreamSynchronize(0) causing a hang.  One thing that I've noticed is that it goes away when I switch from release mode to debug mode in VS2017 (v15.7.5).  This has happened on two different computers, both running Win10.  Once machine has a GTX-108Ti and the other has a Quadro M6000.  Both are up to date on the drivers and CudaToolKit10.0 / cudnn v<IP_ADDRESS>.
Similarly, I've only seen this happen on one set of dnn architectures.  Not sure if it is a size issue but the nets only have 43 layers, 8 of which are tag1/add_prev1 pairs.

Maybe it's just a windows issues then instead of something specific to that card. @reunanen, have you seen the issue on Linux?  Maybe the PR should have an #ifdef that only applies it to windows if not.

Yeah, it could well be a timing issue made visible by the new card (and/or a specific dnn architecture).
Haven't seen it on Linux, but haven't tried either.
 Whereas on RTX 2080 Ti, the occurrence of the hang is a matter of minutes, not hours. But yeah, I know – if it's a race condition or such, then even this is not too unexpected.
@davemers0160 if you cherry-pick #1514, does your release-mode build still hang?

I won't have access to the two computers until Monday.  I will try then.
I also just noticed that there is a new driver for the GTX series.  For the systems that I'm using the drivers are both version 411.63.  It might be worth checking to see if an update to the driver might fix the problem.

Also I haven't been brave enough to upgrade my Ubuntu 16.04 system from Cuda Toolkit 9.1 to 10.0.

I've only run across the error on Windows 10.  I haven't tested any Win7 or Win8.1 machines.  I also haven't upgraded any Ubuntu machines to Cuda Toolkit v10.0.

Someone here recently came across this issue and wasn't sure what was causing it.
Some interesting finds regarding this hang:
Works with CUDA 9.1 + Old nvidia driver
Didn't work with CUDA 9.2 + Old or new nvidia driver
Works with CUDA 10 + New nvidia driver
This is happening with a Titan V.
We were using CUDA 9.2 because it's used for the inferencing application where we need CUDA 9.2 and CUDA 10 requires drivers that are too new. We have no such issues in inferencing, only training.

@xsacha Did you test with #1514?
I think this continues to sound like a timing issue – race condition or so. Whether your application code is Debug mode or has optimizations turned off shouldn't change the CUDA code that is executed, but it does play a role in how quickly different things are completed, in particular relative to each other (and same for using different dnn architectures, as in @davemers0160's case; or different GPU hardware, as in mine).
So to me it sounds like this is a latent bug that pretty much every version has, but most combinations of application code / dnn architecture / GPU hardware just don't make the bug surface.

Ok, just an update. I reported before that I had it working with CUDA 10. It definitely is not working with CUDA 10, it just happens less!
CUDA 9.1 is the only release where I have no issues (without #1514 applied).
I haven't tried #1514 yet. Will get it when the next release occurs.

Ok.  So after several experiments I still am getting seeing the training sticking every once in a while even after making the changes in #1514.  It seems that if I don't load the GPUs down as much as possible then the stall happens more often.  I still have now seen the stall occur with the changes implemented on a Win 10/Cuda 10 machine.

Has anyone worked out if this only happens on WDDM or it happens on TCC too?

@davemers0160 : So is it that cudaStreamQuery never returns cudaSuccess, or simply doesn't return at all?
Pre-#1514, cudaStreamSynchronize didn't return at all (at least in the cases I saw).

@reunanen : On the windows side it was always cudaStreamSynchronize(0) that would never return.  However on the RHEL 7 side I can only guess that the hang is occurring here cudaError_t err = cudaStreamQuery(stream); because I get no error message returned.  This system is an HPC cluster so I don't have a lot of access or ability to debug since it pretty much submit the job and then peek in on every once in  awhile to make sure that it is still running.

@davemers0160 So after #1514 it's still occurring on Windows as well? And still freezing specifically in cudaStreamSynchronize(0)? If so, then I guess the remaining calls need to be replaced also. Can do.
However, do note that (the merged version of) #1514 affects Windows only. So if you are seeing a similar freeze on RHEL also, then maybe the #ifdefs need to be removed after all.

@reunanen : So far I have not seen the freeze happen on Windows after applying #1514.

I was running into a similar issue, after I upgraded my older GTX770 GPU to an RTX4090 which I had alongside my RTX2070 Super, I believe I was using the drivers for the 770 when the 2070 and 770 were installed side-by-side with an older version of CUDA (10.2)
In my particular case, the upgrade resulted in memory access violations at cudaStreamSynchronize, changing the source code to use the polling method introduced by this thread would also result in access violations so I went down a pretty terrible rabbit hole which I will try to document in this comment in the hopes that somebody finds an actual fix for this, the TLDR was that calling get_net() before train_one_step(batch_in, batch_target) in my training loop finally avoided all issues.
To begin, I am on Windows 11 (regrettably) using CUDA 12.1 on the RTX 4090 and 2070 cards, I believe having the 4090 has forced me to only use 12.1 since according to the compute-capability compatibility (say that fast 20 times) matrix that is the only one that supports cc 8.9.
I made sure, in my case, to install CUDA 12.1 (with the most recent NVidia drivers) and build dlib from source using the correct compute capability (8.9 and 7.5 for the 4090 and 2070).  I installed NSight Compute and got a trace:
Before getting to the memory error I had a series of 40-60 error 209 (oddly only some of the cuLibraryGetModule API calls returned an error 209, and the commonality of every error was that the first parameter passed was a memory address with no offset (

After going through dlib source code, and not really finding anything,  I got really frustrated and needed to understand where the issue was coming from. I have a similar implementation of my code in pytorch, so I spent considerable time building from source (and upgrading since the cmake files are not compatible with the migration of NVidia nvToolsExt to header only in CUDA 12.1)
Again, making sure I was using the same cuda libraries and compute-capability to eliminate different versions as a possibility for success/failure across pytorch/dlib.
What I observed in pytorch with CUDA 12.1 on my RTX4090 and RTX2070, was very similar to what I was seeing in dlib. It was a bit more stable in pytorch, in the sense that when the application got past a certain point it was almost guaranteed to complete, whereas in dlib it would always crash by iteration ~20000. But I most definitely observed the same errors in pytorch (no pictures of the memory error trace yet, it's a bit of a pain to step through all those error 209s, especially when it does not happen every time..... also not really motivated to do so since I found a fix, even if it is terrible)
For your consideration here is the pytorch 209 error:

The thing that finally worked for me was calling get_net before train_one_step in my training loop, it does not seem like it is a requirement based on some examples like dnn_introduction2_ex. So I'm not sure why adding that particular line of code finally got things working for dlib / CUDA 12.1 on Windows 11 @davisking
BONUS CONTENT:
Before the fix and my frustration that caused me to try pytorch and the NVidia profiling tools, I had things semi-stable for about a week (it would complete a few runs before the memory access violations). But then last Friday a storm caused the lights to go out and when it finally got back on the application would consistently give memory errors after ~20000 iterations. That led me to check the core GPU voltage, thinking maybe something got fried? (it seemed fine, can play skyrim on it with no issue) at which time I went down the above rabbit hole.
All signs point to a race condition somewhere in the CUDA libraries, or a change in the cuda api that dlib has not implemented yet?

Yeah near as I can tell this is a race condition in the cuda libraries.  You definitely shouldn't have to call get_net() before training or anything like that.  My gut feeling is that nvidia doesn't care about supporting windows as much as linux so there are just more bugs there.  Not sure what can be done about it :shrug:


Spring annotation @Transaction does not work

Please answer these questions before submitting your issue. Thanks!
Which version of Elastic-Job do you using?
1.0.6
Expected behavior
The @Transaction should work in a certain job bean.
Actual behavior
All the Spring AOP seem does not work in a job bean.
Steps to reproduce the behavior
After i checked the code, i found the SpringJobFactory.newJob exchange all the proxied bean with plain bean. that means all the proxy method(include the @Transaction)will be invalid.
Please provide the reproduce example codes (such as github link) if possible.

1.0.6版本早已不维护。由于精力有限，我们只维护最新版本。请升级至最新版再试一下，谢谢。

你好，最新版（1.1.1）的这问题已经修复。是从context中取出的proxied bean并直接设入，没有了AopTargetUtils.getTarget()操作。现在正常了。


Add missing FLAGS for pecl

Fix this issue, https://github.com/grpc/grpc/issues/14767

Thank you for your pull request. Before we can look at your contribution, we need to ensure all contributors are covered by a Contributor License Agreement.
After the following items are addressed, please respond with a new comment here, and the automated system will re-verify.

User @axot isn't covered by a CLA. They will need to complete the form at https://identity.linuxfoundation.org/projects/cncf

Regards,
CLA GitHub bot

Thank you for your pull request. Before we can look at your contribution, we need to ensure all contributors are covered by a Contributor License Agreement.
After the following items are addressed, please respond with a new comment here, and the automated system will re-verify.

User @axot isn't covered by a CLA. They will need to complete the form at https://identity.linuxfoundation.org/projects/cncf

Regards,
CLA GitHub bot

Thank you!
Can you also run tools/buildgen/generate_projects.sh. It will update config.m4.
Our tests can make sure the new pear package works in different systems.

Sorry for causing you inconvenience. The new commit seems strange.
Only config.m4.template and config.m4 should be changed. Can you rebase to the current master, then change the config.m4.template and do tools/buildgen/generate_projects.sh.

Thank you for detail explanation. I did rebase master and then update config.m4.template and config.m4.

Sorry again. Can you please sign the CLA, so the PR will pass the cla/linuxfoundation check and then start the tests?
Thanks!

@ZhouyihaiDing I think CLA was already signed yesterday. No idea why test did not start.

Hello @mehrdada, It seems the CI did not start correctly, cla/linuxfoundation check was passed, Did I do something wrong?

Oops, failed by a timeout to pull an image...

error pulling image configuration: Get https://dseasb33srnrn.cloudfront.net/registry-v2/docker/registry/v2/blobs/sha256/ab/ab47c68ac806a59d07e84e70392d31586da681fe27478c36809e017d897cfeb4/data?Expires=1521737133&Signature=Uk4JbNaSmy6wIf5WIFoQ6-o~MZ9uJgSI83Cb-mI7mCOmdq6qOKxyjYWKzmZsFumrfNSHS-XgIZiB7-IssEiAaByzJOQxc8Jk~sLWCoYQ9yLofATi63cKLp8XgO~ZFJQ2o-PZBSXtMvzdRrkaYLiDELV3U4OT~msidooi-2SNhU0_&Key-Pair-Id=APKAJECH5M7VWIS5YZ6Q: dial tcp <IP_ADDRESS>:443: i/o timeout

@ZhouyihaiDing Cloud you review this PR, thank you.

Sorry for the delay. I was trying to fix the test error #14798 in order to make sure the pecl installation works on macOS.
I am starting to verify the speed boost works on different system then this PR is ready to merge. Just to make sure, are you observing the speed boost on Ubuntu? Seems on Debian, there is not much speed boost. I will test it on macOS to make sure there is at least no speed regression there.

Here is the same warmup test under Debian 9.
env
$ php -v
PHP 7.2.3-1+0~20180306120016.19+stretch~1.gbp81bf3b (cli) (built: Mar  6 2018 12:00:19) ( NTS )

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 9.3 (stretch)
Release:	9.3
Codename:	stretch

$ ls -agh /usr/lib/php/20170718/grpc.so.*
-rwxr-xr-x 1 root 3.6M Mar 24 00:35 /usr/lib/php/20170718/grpc.so.1.10.0.original
-rwxr-xr-x 1 root  16M Mar 24 00:50 /usr/lib/php/20170718/grpc.so.1.10.0.patched

1.10.0 original
php test.php
pid: 3717
GRPC Version: 1.10.0
Warmup: 1,106.190 milliseconds

1.10.0 with this patch
php test.php
pid: 15947
GRPC Version: 1.10.0
Warmup: 802.936 milliseconds

So there is 200 ~ 300ms boost with this patch.

Thank you! I write a simple script to test the local QPS. It seems it does improve the performance a lot. Nice job!
Here are some results:

ping-pong for 30s
old
new(this patch)

Debian
217627
316971

Mac
102620
147969

Ubuntu
160890
249004

Since our dashboard is using the php extension installed by building from the source, you may not observe the performance changes there.

@ZhouyihaiDing How can I check CLA if it works?


Wrong EPSG for single-digit UTM zones with lsdmap_gdalio

lsdviztools version: 0.4.11
Python version: 3.8.16
Operating System: linux

Description
Package utm (and therefore lsdmap_gdalio) does not add a leading zero to single-digit UTM zones. What should be "EPSG:32603" (UTM 3N) instead gets translated to "EPSG:3263" (Antarctica).
What I Did
Here is a Colab notebook demonstrating the issue. With the utm output:
(544386.0105777784, 6754665.726431849, 3, 'V')
The 3 just gets tacked on to EPSG = "326" + str(UTMzone).
In my workflow I use epsg = int(32700-(np.round((45+lat)/90,0)*100)+np.round((183+long)/6,0)) to get the EPSG code that utm is doing under the hood. I think you do something different for the southern hemisphere but I'm looking at permafrost so I just ignore that part 😬
The result of projecting to 3263 is flow routing that fails and/or memory issues because your resulting DEM is 2-4 GB. But zones 47 and 48 work just fine! This has been driving me crazy but I think I've gotten to the bottom of it.

Hi Joanmarie
I think there are two instances of this error which I will try to patch next week (the other one is in lsdmap_otgrabber).
If you cannot wait you are welcome to make a pull request.
I might suggest testing if str(UTMzone) has only one character and if so prepending a 0 (that is what I will do if I get to fixing this before you do).


fix parser crashes on typescript angle-bracket.

fix issue for #68
added new test case,
separate some jsx test cases into its on it block

@gregoryzh thanks for taking on this issue 👍
I think we only need to exclude "jsx" plugin for ".ts" files, as I have seen ".js" file with react syntax so should continue to include "jsx" for them.
also please update CHANGELOG.md
thanks!

hi, updated as per commented, please take a look when you have chance


use utils in knative/pkg

Signed-off-by: runzexia<EMAIL_ADDRESS>knative/eventing#2884

/lgtm
/approve
Thanks!


Metadata in shard

This is the start of a PR to write and query data where all measurement and tag metadata is kept in each shard.
TODO

[x] Implement Shard write path
[x] Keep metadata index in Shard
[ ] Move engine, functions, and tx from influxql package to tsdb
[ ] Update Query Engine to work with metadata in shards

Going to merge this to keep things moving. Will address the query engine updates in a separate PR.


Add option for Array.prototype.fill to have no arguments

lib Update Request
Configuration Check
My compilation target is ES2020 and my lib is ESNext.
Missing / Incorrect Definition
Array.prototype.fill
Sample Code
const arr: number[][] = new Array(100).fill().map(() => new Array(100).fill(0))

Documentation Link
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/fill
The lib.dom.ts is correct according to the spec, however, Array.prototype.fill is commonly called without arguments to eliminate any holes in an array which are otherwise skipped when calling Array.prototype.map. Useful for initialising an array of arrays, objects, etc.

Duplicate of #25392.


:sparkles:  add support for graphql-config (#828)

Description
A graphql-config support with limitations:

loaders are managed by graphql-markdown
projects are not supported
include, exclude and glob pattern are not supported
schema options (eg headers) are not supported

Checklist

[ ] My changes follow the contributing guidelines of this project.
[ ] I have performed a self-review of my code.
[ ] I have made corresponding changes to the documentation.
[ ] I have added tests that prove my fix is effective or that my changes work.
[ ] New and existing unit tests pass locally with my changes.

coverage: 95.46% (+0.06%) from 95.397% when pulling 27f2111e3308c994ed03963453cfdd00af4e9ed1 on feat/graphql-config into 60161cce918fb688f9f2f29b45a3cdee3ab0e713 on main.


(maint) Cleanup RuboCop

This commit renames and removes some RuboCop cops. Previously, RuboCop was
failing with:
.rubocop.yml:205: Style/IfUnlessModifier is concealed by line 382
.rubocop.yml:81: Metrics/LineLength is concealed by line 385
Error: The Lint/HandleExceptions cop has been renamed to Lint/SuppressedException.
(obsolete configuration found in .rubocop.yml, please update it)
The Lint/StringConversionInInterpolation cop has been renamed to Lint/RedundantStringCoercion.
(obsolete configuration found in .rubocop.yml, please update it)
The Naming/UncommunicativeMethodParamName cop has been renamed to Naming/MethodParameterName.
(obsolete configuration found in .rubocop.yml, please update it)
The Style/UnneededInterpolation cop has been renamed to Style/RedundantInterpolation.
(obsolete configuration found in .rubocop.yml, please update it)
The Style/UnneededPercentQ cop has been renamed to Style/RedundantPercentQ.
(obsolete configuration found in .rubocop.yml, please update it)
RuboCop failed!

@shaigy There were two instances of the LineLength cop (https://github.com/puppetlabs/chloride/blob/master/.rubocop.yml#L386), so I removed the older one. Let me know if you'd rather keep the setting than the false one and I can switch it back.

@mwaggett I don't know what the default length setting is, so I am inclined to keep the current 237 setting. Also I am curious where are you seeing these failures? I ran rubocop from enterprise-tasks repo and didn't see any failures.

@shaigy The LineLength setting I left in disables checking the line length at all: https://github.com/puppetlabs/chloride/blob/master/.rubocop.yml#L386
I saw those failures when running bundle exec rake from this repo. I was notified that the build failed when I pushed the MAINTAINERS file removal.

Thanks @mwaggett. I see the errors. Instead of removing the line length setting https://github.com/puppetlabs/chloride/pull/23/files#diff-11a0d7906801d9dea0eccb85667ad811L78-L83
I think we should remove the https://github.com/puppetlabs/chloride/blob/master/.rubocop.yml#L386 where it is disabling the line length checking. Otherwise it is 👍

PR testing failed :( Looks like there are lines as long as 270 :( I am sorry, I should have checked :(


[Question] Downloading image descriptions?

I've tried looking for how to do this in the readme and even searched the issues for it, but couldn't find anything relevant. Is there a way to download the descriptions that Pixiv posts may have? I tried writeimageinfo, but it seems to be irrelevant.

writeimageinfo is the right one, it creates a text file containing the info. The description is labelled as Caption
ArtistID      = 1096811
ArtistName    = チャイ
ImageID       = 82726962
Title         = ソフトクリームの日
Caption       = ひんやりキャットタワー
Tags          = original, Sweets Bird, まぎれるこねこ, いきものごはん, 素晴らしきほっこりの世界, ちょこーとり, ミックスキャット, happy baby birds, ここに巣を作ろう, 密かに紛れるチョコトゥーリ
Image Mode    = big
Pages         = 1
Date          = 2020-07-03 11:30:04+00:00
Resolution    = 1200x2000
BookmarkCount = 6367
Link          = http://www.pixiv.net/en/artworks/82726962

Thank you.


Client side key management

To remove the hurdle of key management from the node, this task should be given to the UI.

@Tbaut The benefit of having this in the node and not fether is that fether is a graphical UI.  What about headless systems? What about automated systems?
Will fether have a cli for the first and an API for the second?  Until it does I think it is critical that the node continue to handle key management.  (I made a comment to that thread maybe you want to require --not-recommended or something to allow for this).


Compute aria-label for menu-toggle-button.

Currently the aria-label for the content meter is not reflective as to what visibly appears on the page thus it errors, this corrects it to use the same value in both placements when and where applicable.

 Accessibility improvements


running .tune files in terminal

I have downloaded the files and I followed the steps on the GitHub page, but how do I play/run the .tune files in my terminal?
ps: I am working with a macbook pro 13" 2016

Thank you, readme is updated in https://github.com/fulldecent/system-bus-radio/commit/735a66f2e3f09426159c43ab6740126c57d8b4e3

after you compile, on terminal use like:
./cmain ../../tunes/mary_had_a_little_lamb.tune

depending on which binary and tune you want


Regenerate roughjs shape only when the item is updated

It adds back the performance optimization of regenerating the shapes only when element properties change.
Do not merge it yet! I need to check out export etc afterwards.

Thanks for bringing it back!

Note that moving an element doesn't have to redraw the shape, but resizing it does. Not sure where it's being set but may be worth double checking

I am only doing it during resizing (line 683)/

Perfect, thanks for checking!

I am checking it now. I checked everything on existing elements and forgot to test new elements...

@vjeux it should work now.


Improve particles System

[ ] More emitter shapes (cone, sphere)
[ ] Noise:  Being able to read random values from perlin noise textures instead of pure JS random code
[ ] Sub emitters: Particles should be able to spawn a new system when they die
[ ] Trails

Can you assign me this task :)

Will do as soon as you accept the invite

@deltakosh yaaaaaaaaay I did it my self 😃 thanks David

@deltakosh hi David, I don't get what is
Noise: Being able to read random values from perlin noise textures instead of pure JS random code
I assumed you want to use a similar random method like class PerlinNoiseTextures but I don't see any similar functions. !!

So far the particles use random object from js
The idea would be to rely on external data loaded into an data array and use this data to generate random values.
The external data could be then loaded from an image containing perrin noise data (which can be generated by our procedural textures)


add possibility of global _properties object in MML

References layers and their properties
fixes #450
I'm not yet sure which properties definition should be more important. Currently if both _properties and properties for a layer contain the same property properties wins. This cannot happen with TM2, but it is necessary to specify for carto.
@pnorman please try it out if it works for you.
cc @gravitystorm

Coverage increased (+0.04%) to 89.135% when pulling 81404bb4c86b888c2f40892c5f9d9f0ae0da40a8 on nebulon42:global-properties into e7c4d2b82cf25b3f7940bf3afd47023b9046ceb0 on mapbox:master.

@pnorman please try it out if it works for you.

How would I test this in Kosmtik?

You could checkout this PR somewhere and link the git repository into node_modules/carto in Kosmtik. Or maybe even easier specify "carto": "nebulon42/carto#81404bb4c86b888c2f40892c5f9d9f0ae0da40a8" in Kosmtik's package.json (see https://docs.npmjs.com/files/package.json#github-urls for details).

Confirming that this works.


[Event Request] table 1704 "Posted Deferral Header" - OnDeleteLinesBeforeDeleteLines

Hello, would it be possible to add OnDeleteLinesBeforeDeleteLines event to table 1704 "Posted Deferral Header", like this:
    local procedure DeleteLines(DeferralDocType: Enum "Deferral Document Type"; GenJnlDocNo: Code[20]; AccountNo: Code[20]; DocumentType: Integer; DocumentNo: Code[20]; LineNo: Integer)
...
          PostedDeferralLine.SetRange("Account No.", AccountNo);
         PostedDeferralLine.SetRange("Document Type", DocumentType);
         PostedDeferralLine.SetRange("Document No.", DocumentNo);
         PostedDeferralLine.SetRange("Line No.", LineNo);
>         OnDeleteLinesBeforeDeleteLines(PostedDeferralLine, LineNo); //New Event
         PostedDeferralLine.DeleteAll();
     end;

     procedure DeleteForDoc(DeferralDocType: Integer; GenJnlDocNo: Code[20]; AccountNo: Code[20]; DocumentType: Integer; DocumentNo: Code[20])

    local procedure OnDeleteLinesBeforeDeleteLines(var PostedDeferralLine: Record "Posted Deferral Line"; LineNo: Integer)

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Nifi 5572

Add Decimal support

RecordFieldType.DECIMAL
DecimalDataType
Fix conversions for Avro + ORC
Fix broken tests

@gideonkorir can you rebase and force push to your branch?

@MikeThomsen I've just done that again after fixing the style issues

@gideonkorir there is a conflict and ideally the commits would be squashed to allow for reviews to result in easier to follow changes.

@joewitt I've fixed the conflicts, I assumed it's a squash merge according to contributor guide.

Realized I was naive in my initial PR, I've gone through all the references to RecordFieldType and made the following changes:

[x]  Update PutCassandra processor to handle decimal and added tests for that
[x] Update PutElasticSearch processor to handle decimal and added tests for that. Caveat, I'm using BigDecimal.toPlainString() so that we don't have scientific notation in the json output; not sure if OK
[x] Added decimal tests for HBase
[x] Added decimal tests for Kudu
[x] Update PutMongoRecord processor to handle decimal, added codec package that adds the necessary codecs for that.
[x] Update StandardSchemaValidator, support decimal in validate, added tests for that
[x] ResultSetRecordSet has decimal support, factoring in precision and scale of the returned decimals
[x] JsonPathRowRecordReader has decimal support, added tests for that
[x] JsonTreeRowRecordReader has decimal support, added tests for that


Fastnlight: Watch official[\W_]+michael[\W_]+richard

Fastnlight requests the watch of the watch_keyword official[\W_]*+michael[\W_]*+richard. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

official[\W_]*+michael[\W_]*+richard has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by VLAZ in Charcoal HQ


mode and default mode not parsed correctly

Describe the bug
when CRT created the deployment manifest, the defaultMode and mode value gets changed to 644 and 600  even though when I hard coded the value in template.yaml as 0644  and 0600. This prohibits me to deploy both using Monokle Desktop as well as kubectl. Here is the error:
sonali@SONALI-SRIVASTAVA:~/Monokle/ssh_enable$ kubectl apply -f ssh1.yaml
The Deployment "ssh1" is invalid:
* spec.template.spec.volumes[1].secret.defaultMode: Invalid value: 644: must be a number between 0 and 0777 (octal), both inclusive
* spec.template.spec.volumes[1].secret.items[0].mode: Invalid value: 600: must be a number between 0 and 0777 (octal), both inclusive
* spec.template.spec.containers[0].volumeMounts[1].name: Not found: "ssh-keys"

Although this is not related to custom resource template. If we have any manifest that has mode set, if we open it via Form Editor, Monokle is editing the manifest and updating the mode from 0644 to 644
So I manually updated the deployment manifest and corrected the mode values. I am able to deploy via kubectl then but still unable to deploy via Monokle because it still can not understand the mode values are correct and throw the same error as shown in screenshot.
Expected behavior
The permission should be stored correctly and after updating Monokle is still unable to understand it and then deploy
Screenshots
Error in Monokle

Successfully able to deploy via kubectl once fixed the mode and defaultMode manually

Video showing the error and steps to recreate both for CRT generated manifest and via Form:
https://user-images.githubusercontent.com/125909758/225050661-a0d012f8-1ba5-4815-b63d-dcb70b65fc0f.mp4
https://user-images.githubusercontent.com/125909758/225050542-6b8d8c0f-d4c2-4089-afbd-18c13a8534d0.mp4
Desktop (please complete the following information):

OS: Ubuntu
Version: 20.04

Additional context
Add any other context about the problem here.

Hi @cerebro31 - Thanks for reporting! Could you share your deployment YAML so we can play around with it to see whats going on? Does this happen only if you use the form-editor to edit this value?

Hi @olensmar Please find the attachment. It also happens when we create the resources using the custom resource template. Here is the link to the repo that has CRT that I have used to create the manifest.
devs_app.zip

more context - the k8s schema unfortunately defines defaultMode as
        "defaultMode": {
          "description": "defaultMode is Optional: mode bits used to set permissions on created files by default. Must be an octal value between 0000 and 0777 or a decimal value between 0 and 511. YAML accepts both octal and decimal values, JSON requires decimal values for mode bits. Defaults to 0644. Directories within the path are not affected by this setting. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set.",
          "format": "int32",
          "type": "integer"
        },

which technically means that 644 is a valid value.. perhaps we should dynamically change the type to string!? (since JSON Schema doesn't seem to have support for octal numbers) - or perhaps there is something we can do with the rjsf ui-schema to override the default behaviour!?

i'm trying to figure this out with the author of our yaml library - see https://github.com/eemeli/yaml/discussions/465

@cerebro31 the upcoming 2.0.8 release should have a fix for this - let us know!


test: 💍 ensure the database is ready in the tests

add a dependency to the app_config fixture to be sure to have access to the database when running an individual test, with TEST_PATH="tests/test_worker.py" make test

Codecov Report
Base: 92.01% // Head: 92.01% // Decreases project coverage by -0.01% :warning:

Coverage data is based on head (1459a90) compared to base (75ae5f7).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #759      +/-   ##
==========================================
- Coverage   92.01%   92.01%   -0.01%
==========================================
  Files          33       33
  Lines        2205     2204       -1
==========================================
- Hits         2029     2028       -1
  Misses        176      176

Flag
Coverage Δ

workers_datasets_based
92.01% <100.00%> (-0.01%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

workers/datasets_based/tests/test_worker.py
100.00% <100.00%> (ø)

workers/datasets_based/tests/test_worker_loop.py
100.00% <100.00%> (ø)

.../datasets_based/tests/workers/test_dataset_info.py
100.00% <100.00%> (ø)

...rkers/datasets_based/tests/workers/test_parquet.py
100.00% <100.00%> (ø)

workers/datasets_based/tests/workers/test_sizes.py
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.