Add an option to enable/disable the forward declaration of records and enums

Hi
I am again working on Djinni with C++ /CX and C++ /CLI to use Djinni together with managed Code and for the Windows Phone.
Unfortunately it seems like the C++ /CLI on Visual Studio 2012 does not like Forward declarations on structs and enums. Therefore I added a command line Switch to the Djinni Source Code to enable/disable the forward declaration Feature.
Feel free to pull this Change into Djinni main. If I've missed something in my implemenation please let me know and I'll fix it.
Later on I plan to give you a pull-request on my current work with the C++ /CLI and the C++ /CX Generator.
Cheers
Christian

Automated message from Dropbox CLA bot
@cfo82, thanks for the pull request! It looks like you haven't yet signed the Dropbox CLA. Please sign it here and update the thread so we can consider merging your code.

I just sent the Dropbox CLA. Cheers

I feel like this is going down a rabbit hole. If we start adding these switches to bypass compiler problems it's only a matter of time until we have hundreds of compatibility options. That's highly impractical to have a reliable test suite for, especially if the switches specifically start targeting certain compilers. We'd have to run these tests with those specific compilers for regression checks. That's a maintenance nightmare.
I really have a bad feeling about this. It's creating a precedent for adding complexity I think shouldn't exist. But that's just me.

Do you have a Suggestion what to do instead of removing the Code by using a Compiler Switch? Because it really leads to compiler errors in context with C++ /CLI with those Forward declarations turned on.

It's very possible that there are other things in Djinni's generated code and support library that VS2012 won't support. Visual Studio 2015 has much better C++11/14 support - would it be possible for you to update to 2015?

Unfortunately its not possible to upgrade to VC2015 for me. But I can test if VC2015 would fix the issue. That might be important for the discussion, right?
Second place I have to test will be in context with the C++ /CX parts. Because there you are locked to VS2013 if you want to develop for Windows Phone 8. At least to my Knowledge. However I got the issue
Alternatively the Djinni could try to detect that its generating C++ /CLI Code and disable Forward declarations in that case. But to me thats not much better than using the command line switch. Maybe even worse because it also adds more complexity to the code.

@cfo82 can you give some more details on the type of errors you're getting?  Is this really a language difference with C++/CX and C++/CLI, or some underlying issue.  Do those languages require a full definition to declare a return type where C++ doesn't?
I'd certainly prefer to find a solution which doesn't require even more command-line options.  I'm also a bit concerned about going too deep down the road of claiming to support C++/CX and C++/CLI in Djinni, since I have no idea how deep that rabbit hole is likely to go, and it'll be difficult for most Djinni devs to test and validate that functionality when making changes.

@artwyman I really do understand the concerns about the command line Switch. However unfortunately I did not have a better idea in the time being. I'll post a few of the things I ran into. For better understanding here is my build configuration:

Static Library with all the Djinni generated C++ Interface sources
Static Library with the actual Business Code and the implementation of the Interface
A DLL compiled with C++ /CLI linking against the first two static libraries. The DLL Project contains only the Djinni generated C++ CLI files.

And just to say, it should not be missing the include file because I use precompiled Header files and the PCH file includes all the C++ Interface files.
These are the issues:

Not as important is the warning I get: warning C4400: 'const lc_interface::EventType &' : const/volatile qualifiers on this type are not supported

3>C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\type_traits(1791): error C3699: '&&' : cannot use this indirection on type 'lc_interface::DayType'
3>          F:\Projekte\github\LadyCycle\cpp\LCEngine\src\lcengine/interface/CalendarItemData.hpp(54) : see reference to function template instantiation 'lc_interface::DayType &&std::move<lc_interface::DayType&>(_Ty) throw()' being compiled
3>          with
3>          [
3>              _Ty=lc_interface::DayType &
3>          ]

which both are for the Enum type in this case. To get the error for the structs would be a bit more time consuming. I'd do that if necessary. Ideas on how to fix this without removing the forward declarations would be very welcome.
And speaking of precompiled Header files above... I could also create a pull request for the Addition of PCH files to the C++ Interface if you'd like.
And last but not least: I got some prototype Code working with C++ /CLI and /CX. However there are still bits missing (e.g. the sophisticated Proxy implementation you have and exceptions). For now I just implemented what I needed to get my Things running. And I did port the sample app to C++ /CX. C++ /CLI and C++ /CX are very important for me. The first release of the app will be for Windows Phone 8. And I use the /CLI for the automated tests of the C# Code on Windows.

Does the diff in this PR actually fix both of the warnings you listed?  I'm a bit confused, since they don't sound like warnings related to missing definitions, so much as cases where C++/CLI (or the compiler version) isn't supporting/understanding aspects of C++ (like the rvalue reference denoted by &&).  This might just be a case of unclear error messages, though.
Separately, I think adding generation of pch files might be a god feature, though I'm not educated enough on them to know if there are any compiler-specific details there.  I'm also not sure that most devs would want to pre-compile all of the Djinni headers, but that doesn't need to keep it from being available as a chioce.

Yes, this Pull-Request fixes all the issues. I got a working build without the Forward declarations. And I just ran Djinni with the compiler switch forward-declarations set to true. Setting it to false will fix the build. My guess is that the 2012 Compiler barely Supports those new C++ constructs and then it somehow is too much for it to generate C++ /CLI Code. But the earliest I got time to try on VS2015 would be the Weekend. Since this involves porting the entire codebase to VS2015...
My implementation of the PCH is currently to just have the Option to specify the Name of the PCH file. My addition to djinni then will insert the #include into every .cpp file. But it does nothing else apart from that. I created the pch.h and pch.cpp files manually. Of course generating these file automatically could be quite cool, but I think that would also include some more discussions because one might want to add more stuff to the PCH files than just the files generated by Djinni...

Oh, you're talking about a feature to insert the pch include into the generated files, not to generate the pch itself.  The former seems more obviously broadly applicable, while the latter is more specific to a particular use case, though both could be good features.  I'd suggest opening separate issues or PRs for either or both of those for discussion.
If the PCH is an alternative fix for your C++/CLI problem, I'd be happier to merge that, since it feels less specific, and more broadly useful.  I can see lots of other reasons for a pch to be desireable.  Since it sounds like you're still in the process of getting things to work with C++/CLI I'd suggest holding off on merging this PR until you have a better idea of what other issues might come up, since some of my hesitancy is because I feel like this might be just the first of many issues, not the only one.  You can gather up whatever fixes you end up needing in your own branch (in a forked repo) then look at merging them when things stabilize.  Let me know if that sounds reasonable.

Yes I was talking about inserting the #include Statement. Nothing more. I can create a separate PR for that one for the discussion. Thats fine.
But I think this PR and the PCH are not related. They are separate issues. The compiler issues above are really only fixed by removing the forward declarations.
As to C++ /CLI and /CX I was hoping that you would open a separate branch somewhen just like the Python implementation is done. My current prototype is just lacking some of the features. And there are some things which could be done in a nicer way. Question is how to proceed on that one? As I understand the mechanism of the pull requests I could just open another one for C++ CLI and CX for the discussion about them, right? And I think they should be part of the same branch/pull request because the implementations are quite similar.

Sorry if I'm misunderstanding again, since the effect of the command-line flag in this PR is to remove hte fortward-decls and include full definitions instead.  Does including the full definition via PCH not fix the problem?  I.e. the root of the problem appears to be the presence of the forward-decls, not the absence of the full definition?  That's even more confusing than before, since i'd expect a forward-declaration of an already-defined type to have no affect at all.
Regarding a branch for C++/CLI, I think that's a good idea, similar to the approach to Python.  If you're the owner/driver of that work, I think that branch belongs in a repo under github.com/cfo82 rather than Dropbox.  (Just click the Fork button at the top of the page to create that.)  That'll allow you to commit to it directly, accept pull requests from others, and resolve issues as you like without being blocked on Dropbox.  Then when it makes sense to merge upstream we can handle that as a pull-request into this repo.  The Python work might be a misleading precedent since it happens to be a forked project lead by Dropbox, who also owns the master Djinni repo.  There are other cases of sub-projects collaborating in other repos, though, like the work on adding a flags type.

I think you got it right now. When the forward declarations are gone the problem disappears. The type is fully defined by including the appropriate header file in both cases. That was confusing to me as well and it took a bit of time to find the Problem... The other interesting thing is that forward declaring classes works. Ist just an issue with the structs and the enums.
I am a bit new to GitHub and the collaboration through it I must admit...
I already forked Djinni into my separate repo as you suggested. Then created the branch for cx/cli (you can see its name). But I created the PR for the forward declarations from that branch and as I understand that branch is now blocked with that PR? I guess I need a separate branch for the C++/CLI implementation?
And how will people know that they can collaborate on C++ /CLI /CX on my fork instead of your main repo? I guess its quite hard to find it since there are so many forks. And would you as the drop box team collaborate on the discussion about the C++ /CLI /CX or am I on my own? To me the question comes down to how much time I invest on that implementation. I could either just keep it to the minimum work which I need for my own project. But that might just be a subset with features missing. Or I'd be willing to invest a bit more time and effort to get something more polished. But it seems that spending time on that is only worth it if there is also a chance that it gets used by other people/pulled into the main Djinni repo somewhen. Because else it would be kind of wasted time.

Weird.  Okay, I think I understand what's happening, but need to give up on trying to understand why, and just chalk it up to weirdness of MSVC or C++/CLI which is outside my expertise.
Hmm, I don't have a lot of experience with cross-repo collaboration in GitHub either so wasn't aware of the PR blocking behavior.  You can likely work around it by closing this PR (if it won't be merged immediately) or by having an "active dev" branch then creating a separate release/merge branch from it when it's time to send a PR.
We don't have a central list of ongoing projects, or coordination of them, though only because nobody has time to do it.  I'd encourage you to join the Slack community mentioned in the README as a place for discussion and to find other developers who might be interested in helping out.  In the abstract, I and Dropbox could give input on work on things like C++/CLI, but since we don't use that language, and have only one active part-time open-source maintainer (me), I don't think we'd have much to add to the process, other than validating its effects on the overall tool if/when it gets merged.  I think it's best to keep the work distributed and let you drive it to meet your needs, or broader needs as you see fit.
I'm not saying you should fork indefinitely.  Supporting more languages is a general goal for Djinni in the long term.  We just don't have a great answer yet to how to manage that, given the overhead each new language puts on maintenance of general features.  That's part of why Python isn't merged yet too.  And I'd like to put off figuring out the open questions there until any new language is a bit more mature.

Just out of curiosity (not sure you mentioned this already): does it work with forward decls but without precompiled headers and the stdafx.h include? Maybe it breaks because of precompiled headers not the decls. Forward declaring structs is certainly nothing new to C++11 (it is for enums but according to https://msdn.microsoft.com/en-us/library/hh567368(v=vs.110).aspx VS 2012 fully supports it).
On a side note: A detailed PCH discussion is certainly for a new issue, but just my short thoughts on it: Modules are just around the corner and they should make precompiled headers pretty much obsolete as the compiler has to include all that information in the module metadata. VS 2015 already has an experimental implementation and the Clang folks are actively working on it (don't know about GCC). The new standard comes out (hopefully) next year and by that time the compiler support should be pretty much immediately available. My instincts say we won't be seeing any PCHs after that, so adding anything related to Djinni seems of temporary value to me. Furthermore all compilers already have an option to "force include" headers before compiling a cpp, so a code change (which would be problematic for portability) is not necessary for a project-wide implicit include that doesn't serve correctness.

@artwyman: Thanks. What about if I open a new pull request about C++ /CX /CLI just for the discussion? That way there would be some connection but no need to pull/merge the changes immediately. And it would be visible for the public. And I'll see to join the slack community in the meantime.
@mknejp: I am quite sure that I also tested this without the precompiled header. It took me some time to figure out what the issue really was and I am quite sure that I tried all those combinations. But to be sure I would need to try again.
I guess the discussion with PCH should be in the other PR then. But one point "against" the temporary nature of PCH in relation to the concept of modules is that you would (to my knowledge) block out development of e.g. Windows Phone 8 apps when you lock Djinni onto only the most recent compiler. Since that development is still done through VS2012 and VS2013. I know that you seem to have a philosophy of going with the newest tech, but please know that this might be an issue for people relying on "older" things.

Structs are really exactly the same as classes in C++ (just with a different default visibility of members), so if there's a difference in the results of the forward-decl, it's probably tied to the fact that Djinni returns structs (records) by value, while it returns classes (interfaces) by pointer.
If you want a place just for discussion, but the changes aren't finalized yet, I'd suggest opening an issue rather than a PR.  And you can link to this PR in the issue so the discussion so far can be accessed.
I wouldn't count on modules to be widespread particularly soon, so I wouldn't hold off on useful features on their account.  I'm not familiar with the compiler options for auto-including headers, but I have found myself considering adding the ability to get Djinni-generated code to include a user-defined  header before, so I could do things like override the behavior of exception-catching macros.  It feels like enough of a generally useful feature that I'd support including it, if someone actually needs it enough to take the time to implement it.

Closing out the question of general C++/CLI support until that's had more discussion, and there's a new PR ready for more complete support.


Addresses issue DCOS-632. Documentation Updated

What are your changes?
Added following steps that are required to make custom Auth0 Work.

Changes that need to be done in the custom login page.
Mentioned to use Custom Social Provider API Keys.

Hosted a page on github pages as a helper to generate the encoded config string
What type of changes does your doc introduce?

[x] Bug fix
[ ] New feature

What is the urgency level of this change?

[ ] Blocker
[ ] High
[x] Medium

I have completed these items:

[x] I have tested all commands and code snippets.
[x] I have built locally and tested for broken links and formatting.
[x] I have made this change for all affected versions (e.g. 1.7, 1.8, and 1.9).
[x] My doc follows the style guide: https://github.com/dcos/dcos-docs#contributing.

@joel-hamill

Can one of the admins verify this patch?

@joel-hamill A community member just submitted a docs patch, can you shepherd it in for them? Thank you!

@alberts can you review this for technical accuracy?

lgtm. @jgehrcke for one last look.

@jgehrcke @joel-hamill @alberts I think I have implemented all your suggestions. Please verify the same.
Thanks.

@joel-hamill @jgehrcke this is ready to be merged, I hope.

@Rohithzr, thanks for the contribution!

There is no current documentation to achive this anymore, is changing the Auth0 client no longer possible?


refactor(*): add Warsaw cloud function location (europe-central2)

This PR should:

update firebase-admin to 9.8.0
update firebase-functions to 3.14.1
add Warsaw (europe-central2) to the list of available Cloud Function Locations for every extension.

Unable to install and test on PR.
Receiving errors similar to
error TS2430: Interface 'Response' incorrectly extends interface 'ServerResponse'.

To avoid build, dependency and doc formatting - moved to https://github.com/firebase/extensions/pull/677

Thanks @rosariopfernandes ! We've given you co-author credit on #677

Thanks for resolving the conflicts and the credits @dackers86 @jhuleatt


Feature request: Add CLI option that loads devnet config from JSON file.

Passing complicated configuration settings using CLI flags can become impractical, and since there is already /configendpoint that dumps configuration into JSON, it only would only make sense to have CLI flag that can read file of that format to spin up devnet instance with same configuration.

If we support specifying CLI params via env vars, as proposed in #482, this issue might not require a lot (or any) work. The user could simply source the env file (file with env vars), or specify the path to the env file, perhaps via a dedicated env var.
E.g. assuming the user has an env file at ./env_vars:
ACCOUNTS=3
SEED=42

One of the following could be implemented:
Using source
Relying on source wouldn't require doing any work to close this issue.
source ./env_vars && starknet-devnet

Alternatively, run in a subshell to prevent keeping the env vars set:
( source env_vars.sh && starknet-devnet )

Using an env var
Using a DEVNET_ENV env var would be simpler for the user, but would require adding some code logic.
DEVNET_ENV=./env_vars starknet-devnet


Fix snapshot

Looks like we had two PRs merged that changed the same thing around the same time
Release Note
NONE

/cherry-pick cloud

Cherry pick is scheduled.


External Edge proxy resets grpc-web server-to-client streams.

Title: External Edge proxy resets the connection
Description:
I am running a following setup: Internet ----> Edge Envoy proxy(L1) ----> Istio Ingress gateway (L2) ----> App (with envoy sidecar)
The app utilizes grpc-web (server-to-client long-lived streams). The only two things I want L1 to do is:

Route traffic based on the host header
TLS termination

It does both of the above perfectly, however, when it was introduced, our grpc-web streams started to timeout/reset at various intervals (typically 2-10 minutes), causing net::ERR_CONNECTION_RESET (chrome dev tools). These connection resets do not occur when we request the same host directly from ingress istio proxy (aka bypassing L1). Only when we request them thru edge proxy. The normal, non-long lived connections of static pages work fine
The few things that came to mind are:
L1 somehow modifies the headers, which leads L2 proxy to drop the connection. I got the idea from (https://www.envoyproxy.io/docs/envoy/latest/configuration/best_practices/level_two). However, i am not sure envoy allows to edit stream_error_on_invalid_http_message, and in addition, I don't think it actually solves the problem
L1 proxy introduces some timeouts that I am not aware of, and L1 after some time kills the long-lived connection. Though, I am pretty sure I have adjusted timeouts correctly, after reading: https://www.envoyproxy.io/docs/envoy/latest/configuration/best_practices/edge. Also, as mentioned, the timeouts are not consistent, which makes me think that it isn't some timeout option.
My understandings might be wrong, as I am still starting with the envoy, so any criticism is welcomed!
My config is as follows:
config.yaml
node:
  cluster: proxy-cluster
  id: proxy1
dynamic_resources:
  cds_config:
    resource_api_version: V3
    path: /var/lib/envoy/cds.yaml
  lds_config:
    resource_api_version: V3
    path: /var/lib/envoy/lds.yaml

lds.yaml:
resources:
  - "@type": type.googleapis.com/envoy.config.listener.v3.Listener
    name: secure_listener
    address:
      socket_address: { address: <IP_ADDRESS>, port_value: 443 }
    listener_filters:
      - name: envoy.filters.listener.tls_inspector
        typed_config: {}
    filter_chains:
      - filter_chain_match:
          server_names: [ "engine.ubnetdef.org" ]
          destination_port: 443
        transport_socket:
          name: envoy.transport_sockets.tls
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
            common_tls_context:
              tls_certificate_sds_secret_configs:
                name: engine
                sds_config:
                  resource_api_version: V3
                  path: /var/lib/envoy/sds-engine.yaml
        filters:
          - name: envoy.filters.network.http_connection_manager
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
              common_http_protocol_options:
                idle_timeout: 7200s
              http2_protocol_options:
                max_concurrent_streams: 100
                initial_stream_window_size: 65536 # 64 KiB
                initial_connection_window_size: 1048576 # 1 MiB
              stream_idle_timeout: 0s
              request_timeout: 0s
              codec_type: auto
              stat_prefix: ingress_http
              use_remote_address: true
              route_config:
                name: local_route
                virtual_hosts:
                  - name: engine
                    domains: ["engine.ubnetdef.org"]
                    routes:
                      - match:
                          prefix: "/"
                        route:
                          timeout: 0s
                          idle_timeout: 0s
                          cluster: kubernetes

              http_filters:
                - name: envoy.filters.http.router

cds.yaml:
resources:
  - "@type": type.googleapis.com/envoy.config.cluster.v3.Cluster
    name: kubernetes
    connect_timeout: 20s
    type: static
    typed_extension_protocol_options:
      envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
        "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
        explicit_http_config:
          http2_protocol_options:
            initial_stream_window_size: 65536 # 64 KiB
            initial_connection_window_size: 1048576 # 1 MiB
    lb_policy: round_robin
    load_assignment:
      cluster_name: kubernetes
      endpoints:
        - lb_endpoints:
            - endpoint:
                health_check_config:
                  port_value: 30080
                address:
                  socket_address:
                    address: <IP_ADDRESS>
                    port_value: 30080
            - endpoint:
                health_check_config:
                  port_value: 30080
                address:
                  socket_address:
                    address: <IP_ADDRESS>
                    port_value: 30080
            - endpoint:
                health_check_config:
                  port_value: 30080
                address:
                  socket_address:
                    address: <IP_ADDRESS>
                    port_value: 30080

Envoy logs, at the point when stream failed(running with -l trace, since -l debug did not output anything at that time interval):
[2021-04-26 22:06:27.133][20606][debug][main] [external/envoy/source/server/server.cc:209] flushing stats
[2021-04-26 22:06:28.165][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.165][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.165][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.165][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 13880
[2021-04-26 22:06:28.165][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.165][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 13880 bytes
[2021-04-26 22:06:28.165][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.166][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 13880 bytes
[2021-04-26 22:06:28.166][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:957] [C5] about to send frame type=8, flags=0
[2021-04-26 22:06:28.166][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:979] [C5] send data: bytes=13
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C5] writing 13 bytes, end_stream false
[2021-04-26 22:06:28.166][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:886] [C5] sent frame type=8
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 2
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:67] [C5] write returns: 13
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 2513
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.166][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 2513 bytes
[2021-04-26 22:06:28.166][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.166][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=16384 padding_length=0
[2021-04-26 22:06:28.166][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=16384 end_stream=false)
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 16392 bytes, end_stream false
[2021-04-26 22:06:28.166][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 2513 bytes
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 2
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C4] socket event: 2
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C4] write ready
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 16384
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 8
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 5552
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 2776
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 2776
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 5552
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 2789
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 6940
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 26385 bytes
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=16384 padding_length=0
[2021-04-26 22:06:28.167][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=16384 end_stream=false)
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 16392 bytes, end_stream false
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=3043 padding_length=0
[2021-04-26 22:06:28.167][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=3043 end_stream=false)
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 3050 bytes, end_stream false
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 26385 bytes
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 2
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C4] socket event: 2
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C4] write ready
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 16384
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 3058
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 16656
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 5552
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 5552
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 5552
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 33312 bytes
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=16384 padding_length=0
[2021-04-26 22:06:28.168][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=16384 end_stream=false)
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 16392 bytes, end_stream false
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=16384 padding_length=0
[2021-04-26 22:06:28.168][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=16384 end_stream=false)
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 16392 bytes, end_stream false
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 33312 bytes
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:957] [C5] about to send frame type=8, flags=0
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:979] [C5] send data: bytes=13
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C5] writing 13 bytes, end_stream false
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:886] [C5] sent frame type=8
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:67] [C5] write returns: 13
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 3371
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 3371 bytes
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=10828 padding_length=0
[2021-04-26 22:06:28.168][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=10828 end_stream=false)
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 10836 bytes, end_stream false
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 3371 bytes
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C4] socket event: 2
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C4] write ready
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 16384
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 16384
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 10852
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 9716
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 11104
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 5552
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 26372 bytes
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=16384 padding_length=0
[2021-04-26 22:06:28.169][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=16384 end_stream=false)
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 16392 bytes, end_stream false
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 26372 bytes
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:957] [C5] about to send frame type=8, flags=0
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:979] [C5] send data: bytes=13
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C5] writing 13 bytes, end_stream false
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:886] [C5] sent frame type=8
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:67] [C5] write returns: 13
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 11979
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 11979 bytes
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=16384 padding_length=0
[2021-04-26 22:06:28.169][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=16384 end_stream=false)
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 16392 bytes, end_stream false
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=5556 padding_length=0
[2021-04-26 22:06:28.169][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=5556 end_stream=false)
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 5564 bytes, end_stream false
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 11979 bytes
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C4] socket event: 2
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C4] write ready
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 16384
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 16384
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 5580
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 16656
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 5552
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 5552
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 27760 bytes
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=16384 padding_length=0
[2021-04-26 22:06:28.170][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=16384 end_stream=false)
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 16392 bytes, end_stream false
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 27760 bytes
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:957] [C5] about to send frame type=8, flags=0
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:979] [C5] send data: bytes=13
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C5] writing 13 bytes, end_stream false
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:886] [C5] sent frame type=8
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:67] [C5] write returns: 13
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 15854
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 15854 bytes
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=16384 padding_length=0
[2021-04-26 22:06:28.170][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=16384 end_stream=false)
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 16392 bytes, end_stream false
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=10819 padding_length=0
[2021-04-26 22:06:28.170][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=10819 end_stream=false)
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 10827 bytes, end_stream false
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 15854 bytes
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C4] socket event: 2
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C4] write ready
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 16384
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 16384
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 10843
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 259
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.171][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 259 bytes
[2021-04-26 22:06:28.171][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.171][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.171][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=250 padding_length=0
[2021-04-26 22:06:28.171][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=250 end_stream=false)
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 256 bytes, end_stream false
[2021-04-26 22:06:28.171][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 259 bytes
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C4] socket event: 2
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C4] write ready
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 256
[2021-04-26 22:06:32.137][20606][debug][main] [external/envoy/source/server/server.cc:209] flushing stats

Any ideas on what I might be missing are appreciated!
Perhaps telling the envoy to not modify traffic, and sending as is? Is there such an option, even if it is not efficient?
Envoy version: 1.18.2
[optional Relevant Links:]
https://www.envoyproxy.io/docs/envoy/latest/configuration/best_practices/edge
https://www.envoyproxy.io/docs/envoy/latest/configuration/best_practices/level_two

I do not see anything interesting in the attached log. It looks like Envoy proxying data normally. Are you sure these connection resets are caused by Envoy? You may want to collect TCP dump as well, to see if it gives any clues.

The TCP from L1 to L2 just has a continuous TCP stream(any ideas, on how I could get more insight into what is going on in there?)

The Connection from the client to L1 is encrypted, after some data there are retransmissions:

What happens after retransmissions? Do you see reset from L1? So far it looks like the issue is between L1 and client.

The way server-to-client stream works in our environment is it sends updates every 20 seconds,
Those are the only packets that were captured between the client, and L1 at the time of reset. On the client-side chrome reports net::ERR_CONNECTION_RESET after the 3rd retransmission packet (attached are the timestamps for Client and L1).

Hmm, I'm out of suggestions. You will need to diagnose the reason for network connection breaking down between Envoy and client. So far it does not look an Envoy problem.

I did not consider that there might be other networking issues, but I did forget to mention that the connection to L2 was accessed thru VPN, which put me on a local logical network as an L2 device, and L1 was accessed publically, which made the TCP connection for the client to L2 run thru our edge firewall directly.
After testing the client connection to L2 from VPN, the issue seemed to go away, which leads me to believe that there might be some setting in firewalls causing the issue.
I have retested and reproduced my previous results, envoy doesn't send those reset packets, yet the client sees them, which makes me think more that it is some sort of firewall up the stream.
Thanks for taking your time, and for your perspective.
Also, do you know if the envoy employs features that would allow long-lived server-to-client TCP sessions to overcome commonly implemented firewall TCP resets methods (I am not aware of any such methods, but if the envoy has some methods to overcome similar issues, please let me know)

Resolved


Add coming soon page for Tech Talk 7

Here's how it will look like
When someone visits the website, it should see Tech Talk 7.0 coming soon and then an email input to get notified when the event date get's fixed.
Then it will also have a link that leads to the current landing page we have now.

i created something on this  already but i'm having difficulties somewhere, can you help me out with it please
?


[EVENT] 19 Feb 2025 - Contributing to scikit-learn hack night @ WeWork

Head organizer: Maren
Support organizer: Jessica, Bita
Slides/Moderation: Maren, Adrin, Guillaume, Stefanie, Tamara
Mentor support: Maren
Location: Warschauer Pl. 11-13, 10245 Berlin
MONTH BEFORE

[x] Define Mentors
[ ] Announce event with mentors, location, gender policy, photo policy on meetup page
[x] Define hosts & collect host information
[ ] Send Host guidelines email @adrinjalali
[ ] Organise Food/ drinks @adrinjalali
[ ] Share event on social media when announced

TWO WEEKS BEFORE

[ ] Re-share event on social media
[ ] Check with mentors about installation instructions/reading material and a list of (beginner friendly) issues to work on
[ ] Update meetup announcement with agenda, networking breaks, if snacks or drinks will be available
[ ] Check-in with hosts and ask if support is needed for reception

WEEK BEFORE

[ ] Remind attendees to install requirements with comment and/or message on meetup
[ ] Send coaches the workshop/relevant material

WEEK OF THE EVENT

[ ] Ask host if attendees list is needed and/or special location directions
[ ] Double check with host: microphone (if needed), soft drinks, power plugs, internet, tables and chairs
[ ] Send to host to print PyLadies arrow signs
[ ] Print [feedback forms](feedback forms)
[ ] Prepare introduction slides past example

DAY OF THE EVENT
(arrive 30-60 minute before event starts)

[ ] Bring swag (stickers, T-shirts, other promotion material)
[ ] Check projector, microphone, table setup, power extensions, recording if available
[ ] Support mentor(s) to test equipment
[ ] Stick PyLadies signs to guide attendees the location
[ ] Hang up or put out print outs with the WIFI (or find a similar solution)
[ ] Manage reception, give name tags if available

DURING THE EVENT

[ ] Do introduction and Community announcements
[ ] Take photos of all the speakers and audience
[ ] Tweet about it (or after the event with photos)

AFTER THE EVENT

[ ] Tweet after event (if not done during the event)
[ ] Upload photos to google drive (you need to be part of the google group to access this)
[ ] Open PR with resources to this repository
[ ] Email sponsors & host to thank them
[ ] Copy feedback forms to feedback spreadsheet
[ ] Adjust guides if valuable feedback came up

I still need to check with WeWork regarding drinks.


⚠ AlphaRatio has degraded performance

In c63f811, AlphaRatio ($AR) experienced degraded performance:

HTTP code: 200
Response time: 11132 ms

Resolved: AlphaRatio performance has improved in c447984 after 5 minutes.


[Bug] can't load scss file

in my theme provider i have an import
import breakpoints from "../../sass/variables/_breakpoints.scss";
which has
`$_XXS: 320;
$_XS: 414;
$_XS_SM: 568;
$_SM: 768;
$_SM_MD: 960;
$_MD: 1024;
$_MD_LG: 1280;
$_LG: 1366;
$_XL: 1920;
$XXS: #{$_XXS}px;
$XS: #{$_XS}px;
$XS_SM: #{$_XS_SM}px;
$SM: #{$_SM}px;
$SM_MD: #{$_SM_MD}px;
$MD: #{$_MD}px;
$MD_LG: #{$_MD_LG}px;
$LG: #{$_LG}px;
$XL: #{$_XL}px;
:export {
XXS: $_XXS;
XS: $_XS;
XS_SM: $_XS_SM;
SM: $_SM;
SM_MD: $_SM_MD;
MD: $_MD;
MD_LG: $_MD_LG;
LG: $_LG;
XL: $_XL;
}
`
when i start storybook i get "Cannot read properties of undefined (reading 'XS')"
Is this addon supposed to fix this or where should i go?

{
name: '@storybook/addon-styling-webpack',
options: {
rules: [
{
test: /.scss$/,
use: [
'style-loader',
'css-loader',
{
loader: 'sass-loader',
options: {
implementation: require.resolve('sass'),
sassOptions: {
includePaths: ['node_modules'],
additionalData: @import "src/lib/styles/sass/theme.scss";
},
},
},
],
},
],
},
},

Hi @spider9375 👋
I don't have a lot of context on this :export { ... } syntax but it looks like an old form of css modules called icss which could be configured through the css-loader like so:
{
  loader: 'css-loader',
  options: {
    modules: {
      mode: 'icss',
    },
  },
},

You can read more about it in the css-loader documentation.
However, if you're up for a change, I'd recommend looking into style-dictionary.
It lets you define you design tokens in plain json files and then generates consumable files for scss and JS/TS to import and use.


Problem with visualization using Graph.plot()

When using pygsp2 and plotting in 3D, the axis doesn't autoscale. This problem is not present in pygsp so there must be some problem with the plot method of pygsp2. What we usually use to fix this is normalizing the position matrix, but this might be innecesary if the plot method is fixed.
For reference, the same graph using pygsp and pygsp2.

Also, this warning appears: UserWarning: No data for colormapping provided via 'c'. Parameters 'vmin', 'vmax' will be ignored
sc = ax.scatter(*G.coords.T,


feat(rum-oversight): unroll scoreCWV loop in util

The scoreCWV method is using a loop that can be unrolled to improve performance (as it doesn't gc as much)
Description
Since the method gets very hot, it seems to produce less gc if it doesn't keep creating a list for the values (the code looks a little more verbose).
Motivation and Context
Speedup the scoreCWV method
How Has This Been Tested?
Looking at the ui rendering speed in the console at
https://utilunroll--helix-website--karlpauls.hlx.page/tools/oversight/explorer.html?domain=aem.live&domainkey=

This is currently for the oversight, but it seems to be applicable to the Explorer. Can the patch be applied there too ?


Reproducing 2D Only results on the Replica dataset

Hi Phuc,
Thank you for the great work and deeply appreciate for providing a good code base to start with!
I am trying to run Open3DIS on the Replica dataset (the downsampled dataset you provided along with superpoints), but I could't reproduce your performance in the paper.
======== With code base based on commit 132fb694b9498cee03bf86e4a70bcaa7b68bb97c =========
I am using the following configs, and ran scripts for grounding, generating instances, refining, and generating again to get the final 2D based 3D proposals.
At the end, I ran evaluation with inst_run_replica.py file.

However, I was able to get this number below, which is underperforming your reported performance of 18.1 AP.

Would you let me know if there is any step I need to do for reproducing Replica performance?
or Is the performance not reproducible with this version of code?
========= With latest code: 4b05043095aff1dcbc9882799d25e0fb6f4c86a9 ==========
I was able to successfully run the grounding part, but I can't run the generate_inst_3d.py file since I don't have post_filter and depth_thresh values that are required for running agglomerative clustering without spp.
Would you provide which values you used for them? + According to configs, you didn't use spp for the Replica dataset.
Is my understanding correct?
Thank you, and looking forward to hearing from you soon!
Best,
Sanghun

Note: I found agglomerative clustering is not runnable for the Replica dataset since it does not return valid confidence (it returns None instead). But this confidence is necessary for getting point-wise CLIP embeddings. Would you also check this?
I also found several variable errors (visi, num_points, etc) :)

Hi @shjung13 ,
Thank you for your interest in our work and for bringing up these points. You're correct; there were some errors introduced during the refactoring of the codebase.

First, we indeed used superpoints on the Replica dataset. To replicate this, you can set the variable final_instance.spp_level to True. This will enable the model to run with superpoints as intended.

Second, we found that using standard pairwise-matching to group instances between frames produced better results compared to agglomerative clustering. Therefore, by default, we have set the falg cluster.iterative to False in the current codebase.

I hope this addresses your questions.
Best.

Hi @ngoductuanlhp
I appreciate for your quick response!
I just ran the code with spp_level set to True, and I got AP of 17.1 as below.
This is still 1% behind the reported number in the paper, but would this be within an error margin?
Thanks!
Best,
Sanghun

Hi, could you please provide how you get the split files? Thank you.


Added Nest cam sensor support.

This adds support for Nest camera sensors as well as any other camera's supported by Wink (Hopefully) also fixed some pylint errors that were introduced due to a new pylint version.

Coverage decreased (-0.06%) to 93.482% when pulling b456d0591f60687142a4ea55cb9c8ad320ddae63 on w1ll1am23:nest_cam_support into 8b3a630504a2cc091f83553f73e11f95429f5df7 on python-wink:master.

Coverage decreased (-0.06%) to 93.482% when pulling b456d0591f60687142a4ea55cb9c8ad320ddae63 on w1ll1am23:nest_cam_support into 8b3a630504a2cc091f83553f73e11f95429f5df7 on python-wink:master.


Error while passing dok matrix into joblib.Parallel

Hello!
I have one strange bug with scipy dok matrix when I'm trying to use it in multithread code. This bug occurs only with dok-matrix and on Python 2.7, 3.4, 3.5, 3.6. It says that dok-matrix hasn't attribute shape.
I've google a lot and found similar issue closed a few days ago: #1188.
If I replace dok-matrix with any other everything is OK.
Any thoughts?
Reproducing code example:
from scipy import sparse
from sklearn.externals.joblib import Parallel, delayed
from my_test import some_action
import numpy as np

test = np.eye(100)
test = sparse.dok_matrix(test)

tmp = Parallel(n_jobs=-1)(delayed(some_action)(test) for _ in range(3))

some_action is a function wraped into a module to avoid known problem with Python multiprocessing:
def some_action(sparse_X):
    return 42

Error message:
Process SpawnPoolWorker-2:
Traceback (most recent call last):
  File "C:\Program Files\Anaconda3\lib\multiprocessing\process.py", line 249, in _bootstrap
    self.run()
  File "C:\Program Files\Anaconda3\lib\multiprocessing\process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Program Files\Anaconda3\lib\multiprocessing\pool.py", line 108, in worker
    task = get()
  File "C:\Program Files\Anaconda3\lib\site-packages\sklearn\externals\joblib\pool.py", line 362, in get
    return recv()
  File "C:\Program Files\Anaconda3\lib\multiprocessing\connection.py", line 251, in recv
    return _ForkingPickler.loads(buf.getbuffer())
  File "C:\Program Files\Anaconda3\lib\site-packages\scipy\sparse\dok.py", line 244, in __setitem__
    if (isintlike(i) and isintlike(j) and 0 <= i < self.shape[0]
  File "C:\Program Files\Anaconda3\lib\site-packages\scipy\sparse\base.py", line 576, in __getattr__
    raise AttributeError(attr + " not found")
AttributeError: shape not found
Process SpawnPoolWorker-4:
Process SpawnPoolWorker-1:
Traceback (most recent call last):
  File "C:\Program Files\Anaconda3\lib\multiprocessing\process.py", line 249, in _bootstrap
    self.run()
  File "C:\Program Files\Anaconda3\lib\multiprocessing\process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Program Files\Anaconda3\lib\multiprocessing\pool.py", line 108, in worker
    task = get()
  File "C:\Program Files\Anaconda3\lib\site-packages\sklearn\externals\joblib\pool.py", line 362, in get
    return recv()
Traceback (most recent call last):
  File "C:\Program Files\Anaconda3\lib\multiprocessing\connection.py", line 251, in recv
    return _ForkingPickler.loads(buf.getbuffer())
  File "C:\Program Files\Anaconda3\lib\multiprocessing\process.py", line 249, in _bootstrap
    self.run()
  File "C:\Program Files\Anaconda3\lib\site-packages\scipy\sparse\dok.py", line 244, in __setitem__
    if (isintlike(i) and isintlike(j) and 0 <= i < self.shape[0]
  File "C:\Program Files\Anaconda3\lib\multiprocessing\process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Program Files\Anaconda3\lib\multiprocessing\pool.py", line 108, in worker
    task = get()
  File "C:\Program Files\Anaconda3\lib\site-packages\scipy\sparse\base.py", line 576, in __getattr__
    raise AttributeError(attr + " not found")
  File "C:\Program Files\Anaconda3\lib\site-packages\sklearn\externals\joblib\pool.py", line 362, in get
    return recv()
AttributeError: shape not found
  File "C:\Program Files\Anaconda3\lib\multiprocessing\connection.py", line 251, in recv
    return _ForkingPickler.loads(buf.getbuffer())
  File "C:\Program Files\Anaconda3\lib\site-packages\scipy\sparse\dok.py", line 244, in __setitem__
    if (isintlike(i) and isintlike(j) and 0 <= i < self.shape[0]
  File "C:\Program Files\Anaconda3\lib\site-packages\scipy\sparse\base.py", line 576, in __getattr__
    raise AttributeError(attr + " not found")
AttributeError: shape not found

Scipy/Numpy/Python version information:
scipy: 0.19.1
numpy: 1.13.1
All Python versions

This is due to the lack of pickle support for DOK matrices in Python3. There's an open PR (gh-7673) that should fix this bug.

Now that gh-7673 is in the code runs fine.


Fix method naming

get_ and set_ methods should have more information on if they are mutable or not instead of being used both ways.

pub struct S {
first: First,
second: Second,
}
impl S {
// Not get_first.
pub fn first(&self) -> &First {
&self.first
}
// Not get_first_mut, get_mut_first, or mut_first.
pub fn first_mut(&mut self) -> &mut First {
    &mut self.first
}

}


Tests for input validators

Add/complete tests for input validators.
Start w/ adding tests for following (blaze.expr.collections) that raise exceptions.

distinct
schema_concat: not sure how this is exposed to user
merge

merge tests are in test_collections.py - should validation test go there or in test_interactive?
_project() method raises error but haven't yet found how/when this is invoked

join: already exists in test_collections
concat: already exists in test_collections
isin: already exists in test_collections
shift: added a test in test_collections

Add tests to either test_interactive.py or test_collections.py

status

distinct
schema_concat - not sure how this is exposed to user
merge

merge tests are in test_collections.py - should validation test go there or in test_interactive?
_project() method raises error but haven't yet found how/when this is invoked

join already exists in test_collections
concat already exists in test_collections
isin already exists in test_collections
shift added a test in test_collections


fix(github): unthemed elements

🔧 What does this fix? 🔧

theme the bottom border of the selected navigation bar item with the accent color at /explore (and topic pages etc)

theme the --rgh-heat-color variable (which is used by refined github to highlight recent commits and most downloaded releases) with the peach color

🗒 Checklist 🗒

[x] I have read and followed Catppuccin's contributing guidelines.
[x] I have updated the version appropriately in the ==UserStyle== header of the catppuccin.user.css file.

Thanks!


Feature Request: Log on request and response

Please add option to log on both request and response.
With long running server-processes it would be useful to see both when a request arrived and when the response was sent. The immediate option allows the former and and default behaviour allows the latter, but not both at the same time.

Just add the middleware twice: one with immediate and one without.

Of course! Thankyou.

No problem! You can then have a different format for them. I do that as well in one of my projects :)

Would be handy to add this suggestion to the README as I don't think this is immediately obvious, but then my experience with Express middleware is minimal.

@Undistraction you may also be interested in https://github.com/glebec/volleyball which I wrote for this purpose. It not only logs on both req & res, but assigns each cycle a unique & color-coded ID to make it clear which responses are for which requests.
You can of course manually implement something similar for Morgan; also, Volleyball is a bit of a small simple toy and doesn't have nearly the feature set or support that Morgan does. So for production or special use cases I'd still use Morgan. But for small local dev you might enjoy Volleyball.


Horses invisible

What is the output link of /viaversion dump?
https://hastebin.com/wirasawura.json
Are you using any additional software like BungeeCord? If so, what software and version? (Please list your plugins as well)
Nop
How does this error happen? login? Using an item?
http://image.noelshack.com/fichiers/2018/30/6/1532802309-bug-viaversion.jpg
Is there an error in the console? Use pastebin.com. Is there a kick message?
Nop

I see this error when I'm connected with Minecraft 1.13. :)

Afaik it's the fault of your resource pack or a Minecraft vanilla bug itself (seen and also reported by others in singleplayer worlds)

See above :)


Installing via homebrew or pkg file via website doesn't work.

macOS Monterey, 12.1
MacBook Pro (13-inch, M1, 2020)
Chip, Apple M1
Memory, 16 GB
Expected Results:
Installing the cli works
What happened:
Installing the cli via homebrew or using the pkg link at the website doesn't install aptible correctly, aptible command can't be found in the terminal.
Explanation.
I don't think this is entirely an Aptible issue.. I'm not sure.. What is happening is after a fresh install of this OSX. /usr/local exists but not the /bin folder inside. Not sure if this competely normal behavior but I ran the CLI install anyway. Aptible CLI install does it's thing but it created a bin FILE (literally named bin) that is symlinked to the /opt/aptible-toolbelt/bin/aptible file.
Fix:
I instead manually created the /bin folder inside of /usr/local and symlinked the aptible file inside there and now it works as it should.

@UserNotFound does anyone from the aptible team monitor these issues?  It seems like the aptible CLI is collecting an increasing number of "new user" issues.
Downloads from the website are unsigned, and this issue has been left unanswered for nearly a year.
Is the aptible CLI dead?


Regenerate @azure/arm-compute to use @azure/core-http

This change is the first part of the work for #4226 where we're attempting to regenerate a subset of the management plane libraries with a version of autorest.typescript that's been updated to use @azure/core-http and @azure/core-arm.
NOTE: This PR won't be merged until an update has been shipped for autorest.typescript with the changes used to regenerate this library.  A PR is out for these changes here: https://github.com/Azure/autorest.typescript/pull/451

Another question for @amarzavery and @kpajdzik: what's the usual pattern for shipping updates to these packages?  Should we go ahead and release an update whenever changes have been made, or do we batch the updates somehow?
Also, I've heard theres an AutorestCI bot, how does that factor into the updates for management plane libraries?  Do I need to update it to use the new version of autorest.typescript once it's shipped?

Another question for @amarzavery and @kpajdzik: what's the usual pattern for shipping updates to these packages? Should we go ahead and release an update whenever changes have been made, or do we batch the updates somehow?

We do. We release a package when the service owners request a release through https://aka.ms/openapihub. This usually happens when a new api version is authored or there is a bug fix.

Also, I've heard theres an AutorestCI bot, how does that factor into the updates for management plane libraries? Do I need to update it to use the new version of autorest.typescript once it's shipped?

I believe it's going to use the newest autorest.typescript. @daschult to provide more details.

The version of the AutoRest TypeScript generator that SDK Automation uses is determined by this line in the SDK repository's swagger_to_sdk_config.json file: https://github.com/Azure/azure-sdk-for-js/blob/59eec86f2b6223dd5954de20c2cd8383c08f538b/swagger_to_sdk_config.json#L8.
If a version is specified in the package that is referenced in the "use" property (such as "<EMAIL_ADDRESS>then that specific version will be used. If a tag is used (such as "@microsoft.azure/autorest.typescript@latest"), then the tag will be resolved using the latest dist-tags information available from NPM. If a version range is specified (such as "@microsoft.azure/autorest.typescript@^4.1.1"), then SDK Automation just passes the version to AutoRest and let's AutoRest decide what it wants to do. I believe this means that AutoRest will use NPM to resolve to the latest version that matches that range, but your best bet is to just use tags if you want to use a non-specific version.

Thanks @daschult and @kpajdzik, that was really helpful!
Chatted with @ramya-a-rao and she had some solid ideas about how we should proceed with this change:

Skip the Rush integration (and package.json script changes) for now so that there isn't unnecessary change to how management plane libraries are built and released (helps to smooth the hand-off to the new team)
Create a branch called feature/arm-core to contain all of the management plane library migration work so that release requests from service owners won't pick up the new core-* integration until we're ready for it

OK, everything is now regenerated using the spec from which the library was generated last and I've changed the target branch to feature/core-arm.  @amarzavery, does everything look good?

Thanks all!


Add Navbar links to Cookbook repository

Have we selected on a Cookbook repository yet? We should add links to this both in the Navbar and the start learning sections.

Related, what should the navbar links be called?
I think we need to change "Gallery" (which links to our Pythia Resource Gallery) because once we have one or more galleries of Cookbooks this word will become ambiguous.
I suggest the navbar links should read: "Home", "Foundations", "Cookbooks", "Resources", "Community" where we renamed the existing "Gallery" to "Resources"

Also in foundations book here: https://github.com/ProjectPythia/pythia-foundations/pull/285


Vampirism perk only heals if blood is consumed by the client.

title, just had a run where we figured vampirism would only work for the host, but found it's the opposite. The host can see the hp increase and then be removed.
0.12.8, v2 worldsync

Should be fixed in v0.12.9


Move analysis_server package to own github repo

This issue was originally filed by @seaneagan

I understand that the dart repo will be moving to github soon anyways, but it will still make sense for the analysis server to have it's own repo there:
https://code.google.com/p/dart/source/browse/#svn%2Fbranches%2Fbleeding_edge%2Fdart%2Fpkg%2Fanalysis_server
This would make it much easier for me to add pubspec-related functionality from den to it, see:
https://github.com/seaneagan/den/issues/17

I think it's safe to say that we won't be doing this. Having code outside the sdk repo that is tightly coupled to code inside it reduces our velocity.


Sp4 345 language frontend

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 3 committers have signed the CLA.:white_check_mark: econesag:white_check_mark: capf4bbo:x: josuecapgeminiYou have signed the CLA already but the status is still pending? Let us recheck it.


Capacitated Vehicle Routing Problem with variable maximum capacity

Hi there! I'm very happy with OR-tools and I would in a later stage be glad to share the resulting webapp here! I have one question that keeps troubling me and hoped someone could answer it or assist.
So far it looks like OR-tools can only assign one maximum capacity to a vehicle routing problem as a whole, as can be read here: https://developers.google.com/optimization/routing/cvrp
routing.AddDimension(
        demand_evaluator,
        0, # null capacity slack
        data.vehicle.capacity, # vehicle maximum capacity
        True, # start cumul to zero
        capacity)

I wish to solve a problem with a variable max capacity. Since a fleet of vehicles do not always have the same size, this seems to be a very relevant feature. I couldn't find any issue about this so opening this one.
Is it possible to accomplish a variable capacity? If yes, how? If meh, is there a known workaround or will it be a feature in the future?

Do you mean a fleet of vehicles with different maximum capacities, or a fleet of vehicles that get smaller and larger during the route?
The first one is easy as shown here https://github.com/google/or-tools/blob/master/examples/python/cvrptw_plot.py#L603

And then use it in the function AddDimensionWithVehicleCapacity as seen on line 662:
routing.AddDimensionWithVehicleCapacity(dem_fn,  # demand callback
                                            null_capacity_slack,
                                            capacity,  # capacity array
                                            True,
                                            "Capacity")

Looks like that's it indeed; "a fleet of vehicles with different maximum capacities".


Implemented the logging functionality using log4cpp library

Hi Ryan,
I have implemented the logger on the main branch and written a small  snippet in the capture.cpp.
Before building log4cpp library needs to be installed. I'll check and see what changes need to be made to the dependencies script for the same. Meanwhile issue the following command to install it manually
$ sudo apt-get install liblog4cpp5v5
$ sudo apt-get install liblog4cpp5-dev
$ sudo apt-get install liblog4cpp-doc
Right now not sure if this will work for the android branch as i read somewhere last week that the library for android is different.
Please review and provide your comments.
Also i'm not sure if the $(LOGFLAGS) is absolutely necessary while compiling all the files.
I thought i'll push it before i break something while trying to optimize.
Will remove it later if not necessary.
Thanks
Sundaram

I am happy how modular you made your modifications, good job! It will make merging much easier with the number of modifications I have made around the project. I will not be able to test it until 5pm CT, but then I will let you know! Again, thank you  very much for your help!
As per your txt logging recommendations, I would like the system to record both an image of the last 3 frames which contain "information" such as focus points, borders, etc (not just ALL frames) and then also a corresponding text file listing the information contained in these images. The same should be done for the last 3 "previews." This will greatly help debugging in the future. Will this library make this easy?

Also, as I said previously, please upload your logging recommendations to the wiki for viewing and editing. Thanks again!

Yes .That is exactly what i had in mind when i designed the structure of the log files.  this information is supposed to be dumped into trace.log .trace.log will be a rolling log. We can limit the size of the log such that only 3 frames can be accommodated. So only information of the last 3 frames is stored in the trace.log file.Once the log file exceeds the size of the 3 frames.it'll roll over to a backup file with name trace.log.1 . We can have as many backup files as we want to. It can be just set in the properties file and no recompile is needed.
One assumption here is that the size of data written for each frame is the same. Is that a safe assumption to make ?
I'll try to implement it tomorrow .

Yes that assumption will be fine except for on the preview images (the output page varies it's size depending on the size of the area it takes up on the webcam).
Regards,Ryan Peach
Date: Tue, 8 Dec 2015 07:08:15 -0800
From<EMAIL_ADDRESS>To<EMAIL_ADDRESS>CC<EMAIL_ADDRESS>Subject: Re: [openscan] Implemented the logging functionality using log4cpp library (#22)
Yes .That is exactly what i had in mind when i designed the structure of the log files.  this information is supposed to be dumped into trace.log .trace.log will be a rolling log. We can limit the size of the log such that only 3 frames can be accommodated. So only information of the last 3 frames is stored in the trace.log file.Once the log file exceeds the size of the 3 frames.it'll roll over to a backup file with name trace.log.1 . We can have as many backup files as we want to. It can be just set in the properties file and no recompile is needed.
One assumption here is that the size of data written for each frame is the same. Is that a safe assumption to make ?
I'll try to implement it tomorrow .
—
Reply to this email directly or view it on GitHub.


Missing vars in modules/bootkube/assets.tf

Issue Report Template
Tectonic Version
1.7.1-tectonic.1 Terraform installer
Environment
darwin/aws
Expected Behavior
terraform apply -var-file=build/${CLUSTER}/terraform.tfvars platforms/aws should finish without error
Actual Behavior
Missing bootkube template vars cause error:

template_dir.bootkube: failed to render /Users/shamsundardileep/Code/hs-orchestration/tectonic/.terraform/modules/0391b25f8df845582a6b6a555d42296b/resources/manifests/kube-flannel.yaml: 48:18: unknown variable accessed: flannel_image

Reproduction Steps

Follow guide for setting up Terraform install prereqs https://coreos.com/tectonic/docs/latest/install/aws/aws-terraform.html
terraform apply -var-file=build/${CLUSTER}/terraform.tfvars platforms/aws
This can be fixed by adding flannel_image and flannel_cni_image to the template_dir.bootkube vars block

I was not able to reproduce this error. Is there a chance that you've made any mistakes customizing your deployment?


Add auth2 and acl authentication support.

Signed-off-by: Tingyu Zeng<EMAIL_ADDRESS>

@jpwhitemn The binary is not needed for the project. I have .gitingore to exclude the binaries but it seems they are not effective. I will take a look and make sure they are not checked in.

We should definitely be careful to not commit binaries into source code.
On Tue, Oct 9, 2018 at 3:02 PM tingyuz<EMAIL_ADDRESS>wrote:

@jpwhitemn https://github.com/jpwhitemn The binary is not needed for
the project. I have .gitingore to exclude the binaries but it seems they
are not effective. I will take a look and make sure they are not checked in.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/edgexfoundry/security-api-gateway/pull/23#issuecomment-428331069,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAj_q9SYxppI1zLFSYZNvpu7Xm3P79p1ks5ujQDOgaJpZM4XThMO
.

Removed the binary from the PR.


samples: net: gsm_modem: build fails if CONFIG_GSM_MUX=y

Describe the bug
Building of sample app gsm_modem fails if GSM muxing is enabled
by setting CONFIG_GSM_MUX=y.
To Reproduce
Steps to reproduce the behavior:

cd samples/net/gsm_modem
west build -b reel_board
-> OK, builds fine.

Now append to prj.conf:
CONFIG_GSM_MUX=y
Repeat build:

west build
-> build fails

Expected behavior
Build should succeed.
Impact
Showstopper - GSM muxing can not be used.
Logs and console output
...
../../../../include/sys/cbprintf_internal.h:183:19: error: invalid use of undefined type 'struct gsm_dlci'
183 |   *_Generic((arg) + 0,
...
Environment (please complete the following information):

OS: Linux
Toolchain: Zephyr SDK 0.11.2
Commit: zephyr-v2.5.0-3633-geaa2dba1a232

@hwilmers this appears fixed on the main tree.

Someone is working faster than me. Thanks ;-)


PLS HELP ME

Hello,
I installed the notion with scoop. And I'm having problems with notion enhancer. Please see the screenshot below. How do I fix it?

what's the output of running python cleaner.py?

what's the output of running python cleaner.py?

The directory path of notion is
C:\Users\TINY\scoop\apps\notion

try installing official windows app. the enhancer does not currently support installation with scoop.


adding the clone trait to matcher and UAParser

If the UA Parser is used as an extension in the tokio layer , it requires the object can be cloned for every request.  It is better to allow the clone trait or expose the Matcher object as a public object to allow others to implement the Clone Trait.

Sounds great to me, thanks for the contribution!


can search functionality box be implemented? Similar to this https://github.com/christianmatei/git-playbook

Hi @christianmatei , There is no plan to implement search functionality in makesite.py.  I want to keep this project as simple as possible as this project is only meant to be a quick-starter-kit for developers who want to develop their own static site generators. One is free to modify, enhance, and maintain it in their own repository. This project is meant for developers who may dive into the code and enhance it for their needs (say a search functionality). An example website source is provided to get started quickly and then modify it as necessary.


Support importing image (POSTing TAR to imageCreate API endpoint)

This API requires passing a valid TAR stream, so this likely depends on https://github.com/clue/php-tar-react/issues/2 (see also #15)

Depends on #33.


npm ERR! Missing script: "frontend-build-all"

RazorSvelte.csproj in the Carbon UI template
<PreBuildEvent>npm run frontend-build-all --color=always</PreBuildEvent>
should be changed to
<PreBuildEvent>npm run fe-build-all --color=always</PreBuildEvent>

I don't maintain the Carbon UI template anymore. It's just an example. The master branch contains a modified Bootstrap template which I do maintain.


LSP support for more languages

Currently only Go is supported and configured. Add support for more languages, like C, C++, bash, Dart, Kotlin, Rust, Assembly.

For VHDL there is already an open issue at Mason


Add RTL support

Fix keyboard navigation when in RTL
Add tests to cover navigation with left/right keys on RTL
Bump versions

Fix #706

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


[c++] C++ unification tracking (high-level/parent issue)

Goal of having a single copy of tiledb core via libtiledbsoma, eliminating all use of tiledb-py and tiledb-r:

Currently present in SOMAReader (as of 2023-02-13):

Arrays:

[x] read for arrays

supporting methods like set_dim_points, submit, results_complete, etc.

[x] nnz

[x] stats access

Reads:

Arrays

[x] Rename SOMAReader to SOMAArrayReader
[ ] Optimize CSR I/O (for Python) or CSC I/O (for R): see also #718
[x] shape #927
[ ] schema reads (as Arrow) #1121
[ ] metadata reads #926
[ ] open (for read) and close

Groups:

[ ] Make a SOMAGroupReader #1122
[ ] open (for read), and close
[ ] Get member name-to-URI map #1122

Writes:

Arrays:

[ ] Make a SOMAArrayWriter
[ ] open (for write), and close
[ ] update metadata
[ ] write bulk data

Groups:

[ ] Make a SOMAGroupWriter #1182
[ ] create #1182
[ ] open (for write), and close
[ ] add/delete members
[ ] update metadata

Query API:

[ ] Port query logic to C++

The current query logic (in somacore) uses only the API, with no direct implementation-level accesses.
This could almost all be translated into C++.
As pre-requisite work, we'll need SOMAArrayReader and SOMAGroupReader feature-complete (as building blocks) before we can implement this in C++
SOMAArrayWriter and SOMAGroupWriter development can proceed in parallel with this.

Feature completion:

[ ] Let SOMAReader use all supported types (not just int and string as currently) to index SOMADataFrame

https://github.com/single-cell-data/TileDB-SOMA/blob/0.5.0a11/libtiledbsoma/src/pyapi/libtiledbsoma.cc#L328-L350

Read performance, and in particular all of the zero-copy or ecosystem format paths (optmized CSC/CSR, etc)

[ ] in principle, we should consider at a zero-copy path for any format that the user will want to use from R or Python.

Large out-of-core / distributed processing:

[ ] Partitioning support

cc @gspowley @nguyenv @Shelnutt2 @eddelbuettel

See also #718 (and the R equivalent would be CSC reading)

Updated -- thanks @bkmartinjr !

Additional suggestion: there are multiple "themes" here that motivate the smaller items.  It would be helpful to identify those and group the small items by their epic/theme. I believe they are:

Link in a single instance of TileDB core:  this is the write path, schema, meta, and other small stuff
Read performance, and in particular all of the zero-copy or ecosystem format paths (optmized CSC/CSR, etc)
Large out-of-core / distributed processing - the partitioning of reads

Organizing around these would make it simpler to discuss prioritization.

@bkmartinjr done as requested

It sounds like @nguyenv will be duping this out on #1240

Tracking has been transferred to https://github.com/single-cell-data/TileDB-SOMA/issues/1240.


Update Readme.md

Fixes Issue

Closes #13
My PR closes #issue_number_here
Changes proposed
What were you told to do ?

What did you do ?

I have corrected the grammar to organization to an Organization.
Check List (Check all the applicable boxes)

[] My code follows the code style of this project.
[] This PR does not contain plagiarized content.
[] The title and description of the PR is clear and explains the approach.

Screenshots

Hi @itanand , it's been a week, if you are not working on it - do let us know.


about relabel dataset

A sample of relabel dataset has shape of [2,5,15,15]
Could you explain what each axis means?
I believe that [0, :] means prediction confidence and [1:,] means predicted class number.

Hi, are you looking at label_map?
https://github.com/naver-ai/relabel_imagenet/blob/6cd84dffe4ce8005395970b2938b3196d0958351/utils/relabel_functions.py#L15-L27
For the first dim of label_map,
label_map[0] is a tensor for the prediction scores, and label_map[1] is for the class indices as you saying.
The second dim indicates the top-k index because we only store the top-k label maps for storage efficiency.

This is a sample image from the Imagenet and Relabel dataset. Dominant pixel values of label map is 769 and I would like to know the class name of the number. Is there any way of converting this?

@SeungyounShin
You can use this JSON data.
https://gist.github.com/yrevar/942d3a0ac09ec9e5eb3a
769 is 'rule, ruler'