GML

Added a GML parser
Includes tests based on examples in GML documentation
Stuart

Thanks!  Just to be clear, this test suite is about the testing against graph-example-1.xml test data.  When I did GraphSONReader it was almost as simple as a cut-n-paste operation.  Makes me wonder sometimes if we shouldn't do this a different way.  I guess a common interface for each of these readers/writers may be in order some day...on the other hand, i'm not sure how well that would work.
I didn't drill into your code completely, but another thing I remember that I had to go back and do with the GraphSONReader/Writer was get the public method names matched up to GraphMLReader/Writer so that they stayed consistent.
Anyway, just some things for you to consider as you amend your commit. Thanks again for your contribution.

I've had a quick go at the writer - it's just about there but as GML ids have to be integers it uses generated ids and puts the blueprint id into another property (blueprintId). This is not treated as a special case in the reader but could be. Complex objects in properties are also not going to be recreated properly - most likely they'd come back as their toString.
I didn't have time to do the other test - I think it needs the standard graph written in the GML format unless I misunderstood. It seemed more sensible to create the writer first so I can write the standard graph out for use in the test. But I'll do that another day.
Stuart

PS Looks like my formatting is different - do you have a formatter I should be using?

Looking at this made me go back and review my work with the GraphSONReader.  I didn't do it right.  There was a bit more involved than I thought, namely, what you mentioned: you will need the GML format written out.
I just modified the test suite for the GraphSONReader.  It was easy to generate the file.  I just opened a Gremlin terminal and read in the example files then wrote them back out.  Harder from your end because you don't have the cool helper methods available in Gremlin.
I'm not sure what you mean by "formatter"...what did you mean by the "formatting" being different?

I see what you mean now about the "formatter".  Thanks for the update.  Please let me know when you're all ready for me to complete the pull request.  Thanks.

This is now ready, I've added the larger test suite and made some modification to the Reader to align the options with those on the GraphMLReader. I also added the larger example 2 though not used in the tests.
I've only tested this on the TinkerGraph implementation. There are slight differences on the tests due to the  integer encoding of the id value in the GML format. This leads to a slightly unexpected situation where
Vertex v = graph.getVertex(Object id) ;
assertFalse(v.getId().equals(id))
assertTrue(v.getId().equals(id.toString()))
because the getId returns the internal string representation and not the original id object. It's not clear that all implementations of Graph will work this way so I'm not sure it would pass as is for all implementations.
If getId() does not have to return the original id object a boolean hasId(Object id) would be a good addition. This would allow the internal representation to vary but the user not to worry about to (at leas in these tests).
Stuart

Thanks again.  We may choose to merge this change in after our stable release at the end of this month.  I'll let you know.
Stephen


add empty story for dashboard

Current dependencies on/for this PR:

main

PR #280   👈

This comment was auto-generated by Graphite.

Merge Activity

Sep 21, 1:40 AM: @Mause merged this pull request with Graphite.


⚠ Samsung has degraded performance

In fa49fcb, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2455 ms

Resolved: Samsung performance has improved in 2ccb4f9.


Setup for future payments with Google Pay and Apple Pay

Is your feature request related to a problem? Please describe.
In our Ionic 5 + Capacitor app, we can't seem to make Google Pay and Apple Pay work and have customers use those payment options to set up their account, using a setupIntent. It is possible to charge the customer an upfront amount and the payment method will get saved, but that is not feasible in our use case.
Describe the solution you'd like
We want to be able to provide our customers the option to set up their accounts using Google Pay and Apple Pay, without charging them an amount upfront and to have the ability to charge them after that, using those payment methods, when a certain event happens.
Describe alternatives you've considered
We tried Stripe Elements, embedded stripe form, and this capacitor-community/stripe plugin. We believe this plugin is the best way to eventually achieve what we want, but in case it's not, we are looking for any suggestions that could help us.

Also would love to see that feature.
If already possible, this could be added to the docs.

@rdlabo is this already possible or does it need to be implemented?

We are doing what you are describing using this plugin, but we had to slightly modify the Android part of the plugin. I submitted a PR #216 with the change required.
If that is merged, you can just pass your setup intent client secret as you would with a payment intent. Note that the setup intent passed to the functions below we create on the server side.
For Apple Pay:
async confirmApplePaySetup(setupIntent: SetupIntent, currency: string): Promise<SetupIntent> {
  await CapacitorStripe.createApplePay({
    paymentIntentClientSecret: setupIntent.client_secret,
    currency,
    countryCode: 'US', // Your Stripe account country
    merchantIdentifier: 'merchant.com.company.xyz', // Your merchant identifier
    paymentSummaryItems: [{ label: 'Payment verification', amount: 0 }],
  });

  const result = await CapacitorStripe.presentApplePay();

  if (result.paymentResult !== ApplePayEventsEnum.Completed) {
    throw new Error('Apple Pay failed');
  }

  return setupIntent;
}

And for Google Pay:
async confirmGooglePaySetup(setupIntent: SetupIntent, currency: string): Promise<SetupIntent> {
  await CapacitorStripe.createGooglePay({
    paymentIntentClientSecret: setupIntent.client_secret,
    currency,
  });

  const result = await CapacitorStripe.presentGooglePay();

  if (result.paymentResult !== GooglePayEventsEnum.Completed) {
    throw new Error('Google Pay failed');
  }

  return setupIntent;
}

@krisloekkegaard wow thank you for sharing this!

@krisloekkegaard Will absolutely give this a try and see if it solves the problem for us! Thanks a lot!

Thank you very much for your great work. Thanks to everyone, this plugin has taken a step forward. Have a great tomorrow everyone🎉


Will you add support for ASP.NET 5 + MVC 6?

@troygoode
I've done the conversion and I'm trying to decide whether to fork this repo or create a new one, and what version numbers to use. What would you suggest?

@glen-84 I haven't worked in Windows/.NET for years so I'm unlikely to make any further changes

@troygoode Okay, I will fork or create a new repo (not yet sure which). Thanks.

@troygoode Well then could you state that in bold on the homepage, so the rest of us know that this nuget package is unsupported? I made a PR which I now know won't ever be used. Thanks for this package it was truly great while it lasted, but do the decent thing and let others know to avoid it and choose something else.


Migrate command not working

Manually migrate command not working after modules created
It's shows bar table or view already exists
Is this issue cleared or not

There is no need of migrate command after module is generated via Module Manager.


geography[BUG]

Hi and thanks for this library
?$filter=geo.distance(location,geography'POINT(-1.702 48.113)') le 200
it case a bug.

sure, let me have a look

Hi @Mario-35,
Thanks your report, and your ID is really cute haha :)

in odata official APNF standard, the Point literal should have SRID literal as prefix, and the Point literal is not uppercase, but in some odata.org documents, they are differents.
I released a new version 0.2.12, its supported uppercase POINT literal and geography literal without SRID, but carefully use them on your risk, maybe its not compatible with other implementations

Thanks I go to test and report it.
It's my real name  :)

Ok, it works I searched but don't saw it was an uppercase problem :) I use your library for sensorThings Odata and you're right, it's confused BUT in fact, I think it's POSTGRES (POSGIS)  mhich have some problems with lowercase and uppercase name, so to  avoid these library problems transform all in uppercase.
sorry for my approximative english.
Thanks


May not work for China regions

I'm getting a token error on credentials that are known and working

The various AWS partitions (aws, aws-us-gov, and aws-cn) are completely separate, and used different sts endpoints.
I would like aws-console to interoperate with all of these, but only the aws partition is currently supported. This is primarily due to only having an aws account to test with... 😁


Typo on 16.2.3 (US & LA Site)

Hi @Brockfanning,
FYI I noticed a typo on 16.2.3 on the US site that carries over to the LA site... the indicator should read '...experienced sexual violence by age 18'  it currently reads 'by age 1'
US Site:

LA Site:

Thanks!
Dawn

@dawncomer I just put up a PR that should fix that: #35


Eventrouter chart is deprecated in https://github.com/helm/charts

From Nov 13, 2020 the eventrouter chart is deprecated.
Is there any alternative?
Can you please migrate to new chart version?

We previously used next repo
- helm repo add stable https://kubernetes-charts.storage.googleapis.com

The error message on install was:
Error: looks like "https://kubernetes-charts.storage.googleapis.com" is not a valid chart repository or cannot be reached: failed to fetch https://kubernetes-charts.storage.googleapis.com/index.yaml : 403 Forbidden

Changing repo to next one solved the issue.
- helm repo add stable https://charts.helm.sh/stable

Seems like this is similar to https://github.com/heptiolabs/eventrouter/issues/121.
Closing the issue.


Cleanup not-storage-explorer code & files

Choose something you know is still around which came from CE and is not used by storage explorer, timebox yourself, and delete as much of it as you can. Have fun!
Related: #5020, #5022

Done for 1.24.0, move to 1.25.0 for the next available person.

I don't think we need multiple copies to track this effort, so I'm going to close this.


Use readthedocs sphinx theme when building locally

See the RTD notes about this here.

LGTM - I have this same thing stashed on my local copy :P.

Yeah, the non-themed output made my eyes sad.

No merge button!


Suggest MIT License

Fixes #4

I would argue that since this is not "code", per se, it would fall better under something like an Open Document license or a Creative Commons license, but that's neither here nor there.


fix(node-exporter-rule): updated NodeFilesystemSpaceFillingUp

Description
Updated NodeFilesystemSpaceFillingUp rule to adequate the rule from  Prometheus operator's node exporter prometheus rule
Breaking Change

[ ] Yes
[x] No

Links
https://github.com/prometheus-operator/kube-prometheus/blob/main/manifests/nodeExporter-prometheusRule.yaml#L15

 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.Krish Poolo seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Hi @pkrishnath  - Thanks for this - Can you sign the CLA that assigns ownership to the CNCF ?
@BrendanGalloway @paddatrapper  I also created https://github.com/flanksource/karina/issues/1037 to handle this better long-term

Hi @pkrishnath - Thanks for this - Can you sign the CLA that assigns ownership to the CNCF ?
@BrendanGalloway @paddatrapper I also created #1037 to handle this better long-term

Done @moshloop


Not able to download 2019.1.2

Hello,
With the release of 2019.1.2 I want to upgrade our plug-in to the latest version, but it's seems it's not available yet for the plugin-in development ?
Could not find com.jetbrains.intellij.idea:ideaIC:2019.1.2.
Searched in the following locations:
  - file:/Users/xxxx/.m2/repository/com/jetbrains/intellij/idea/ideaIC/2019.1.2/ideaIC-2019.1.2.pom
  - file:/Users/xxxx/.m2/repository/com/jetbrains/intellij/idea/ideaIC/2019.1.2/ideaIC-2019.1.2.jar
  - http://repo.maven.apache.org/maven2/com/jetbrains/intellij/idea/ideaIC/2019.1.2/ideaIC-2019.1.2.pom
  - http://repo.maven.apache.org/maven2/com/jetbrains/intellij/idea/ideaIC/2019.1.2/ideaIC-2019.1.2.jar
  - https://cache-redirector.jetbrains.com/www.jetbrains.com/intellij-repository/releases/com/jetbrains/intellij/idea/ideaIC/2019.1.2/ideaIC-2019.1.2.pom
  - https://cache-redirector.jetbrains.com/www.jetbrains.com/intellij-repository/releases/com/jetbrains/intellij/idea/ideaIC/2019.1.2/ideaIC-2019.1.2.jar

thanks, fixed


Deploy stack failed on eu-central-1

Hello,
Problem when creating the stack on eu-central-1 frankfurt region (S3 bucket and Cloudformation stack in same region)
Like you can see I tried with public access open on s3 template bucket, but no way to make it working
Any idea please ?

Best Regards,
Loïc

Is the firewall-frankfurt-access bucket created? The cloud formation does not create it for you, you have to create it first. The bucket image you provided does not contain it, and yes other buckets.

Hello and thank you,
I have exactly the same problem when creating this bucket, and the same error if I set "Activate Scanner and Probe protection" to false and then without using this access bucket....
Any Idea ?
Best regards,
Loic

Hi @Loic-Hakisa ,
We were not able to reproduce this issue with given input parameter in Frankfurt region. Can you please share this addition information to troubleshoot this issue.
what version of waf-security-automations solution you are trying to install? Also please share the template url ?
Thanks,
Praveen

@Loic-Hakisa
Here is your issue, I think:
https://github.com/awslabs/aws-waf-security-automations/issues/154

Big thanks for this reply, I will check it soon !
Cordialement,
*Loïc EHRHART                             *
DevOps
Tél : +33 6 12 18 79 65
Value your digital communities
Le mar. 8 sept. 2020 à 16:17, Cameron McAuley<EMAIL_ADDRESS>a
écrit :

@Loic-Hakisa https://github.com/Loic-Hakisa
Here is your issue, I think:
#154 https://github.com/awslabs/aws-waf-security-automations/issues/154
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/awslabs/aws-waf-security-automations/issues/144#issuecomment-688906996,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APFWJ24G6A65JVVXCOVNV7DSEY4GXANCNFSM4POBSGTA
.


GH-3987 introduce InternedIRI for use in Vocabularies to improve performance

GitHub issue resolved: #3987
Briefly describe the changes proposed in this PR:

New (internalOnly) class InternedIRI which interns the stringValue and pre-calculates the hashCode
Use InternedIRI in Vocabularies and in CoreDatatype

PR Author Checklist (see the contributor guidelines for more details):

[ ] my pull request is self-contained
[ ] I've added tests for the changes I made
[ ] I've applied code formatting (you can use mvn process-resources to format from the command line)
[ ] I've squashed my commits where necessary
[ ] every commit message starts with the issue number (GH-xxxx) followed by a meaningful description of the change

I've changed both https://github.com/eclipse/rdf4j/pull/3990 and this PR to draft for the time being. They both definitely improve performance, but that was only really obvious when combined with #3933.

Hi just a quick thought. Will this really help at scale? I have had bad experiences with intern on string similar to https://shipilev.net/jvm/anatomy-quarks/10-string-intern/

Before

After
Benchmark                                                                                (param)  Mode  Cnt   Score   Error  Units
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencer                            moreRdfs::12180  avgt    3  11.611 ± 6.192  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencer                            longChain::5803  avgt    3   8.134 ± 0.454  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencer                                medium::544  avgt    3   0.882 ± 0.279  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencer                                simple::152  avgt    3   0.465 ± 0.091  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencerMultipleTransactions        moreRdfs::12180  avgt    3   8.428 ± 1.013  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencerMultipleTransactions        longChain::5803  avgt    3   8.121 ± 0.168  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencerMultipleTransactions            medium::544  avgt    3   0.759 ± 0.233  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencerMultipleTransactions            simple::152  avgt    3   0.461 ± 0.074  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencerMultipleTransactionsSchema  moreRdfs::12180  avgt    3   8.738 ± 0.843  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencerMultipleTransactionsSchema  longChain::5803  avgt    3   6.137 ± 0.426  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencerMultipleTransactionsSchema      medium::544  avgt    3   0.514 ± 0.056  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencerMultipleTransactionsSchema      simple::152  avgt    3   0.222 ± 0.033  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencerSchema                      moreRdfs::12180  avgt    3   9.325 ± 3.046  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencerSchema                      longChain::5803  avgt    3   6.213 ± 0.502  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencerSchema                          medium::544  avgt    3   0.503 ± 0.001  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencerSchema                          simple::152  avgt    3   0.220 ± 0.007  ms/op
ReasoningBenchmark.noReasoning                                                           moreRdfs::12180  avgt    3   3.979 ± 0.485  ms/op
ReasoningBenchmark.noReasoning                                                           longChain::5803  avgt    3   1.843 ± 0.124  ms/op
ReasoningBenchmark.noReasoning                                                               medium::544  avgt    3   0.297 ± 0.036  ms/op
ReasoningBenchmark.noReasoning                                                               simple::152  avgt    3   0.123 ± 0.005  ms/op
ReasoningBenchmark.noReasoningMultipleTransactions                                       moreRdfs::12180  avgt    3   3.841 ± 0.864  ms/op
ReasoningBenchmark.noReasoningMultipleTransactions                                       longChain::5803  avgt    3   1.838 ± 0.409  ms/op
ReasoningBenchmark.noReasoningMultipleTransactions                                           medium::544  avgt    3   0.294 ± 0.036  ms/op
ReasoningBenchmark.noReasoningMultipleTransactions                                           simple::152  avgt    3   0.124 ± 0.004  ms/op

Before
Benchmark                                                                                (param)  Mode  Cnt   Score   Error  Units
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencer                            moreRdfs::12180  avgt    5  12.385 ± 0.043  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencerMultipleTransactions        moreRdfs::12180  avgt    5   9.372 ± 0.072  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencerMultipleTransactionsSchema  moreRdfs::12180  avgt    5   9.447 ± 0.019  ms/op
ReasoningBenchmark.forwardChainingSchemaCachingRDFSInferencerSchema                      moreRdfs::12180  avgt    5   9.726 ± 0.029  ms/op
ReasoningBenchmark.noReasoning                                                           moreRdfs::12180  avgt    5   3.877 ± 0.016  ms/op
ReasoningBenchmark.noReasoningMultipleTransactions                                       moreRdfs::12180  avgt    5   3.858 ± 0.036  ms/op

After

This is showing a decent 10% performance improvement in the more complex RDFS reasoning benchmark.


Update amp-dailymotion.html

I signed it!
On Jul 27, 2016 11:44, googlebot<EMAIL_ADDRESS>wrote:Thanks for your pull request.  It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
📝 Please visit https://cla.developers.google.com/ to sign.
Once you've signed, please reply here (e.g. I signed it!) and we'll verify.  Thanks.
If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address.  Check your existing CLA data and verify that your email is set on your git commits.If you signed the CLA as a corporation, please let us know the company's name.
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or mute the thread.

LGTM. Thanks a lot!


LDS grpc-JSON not loaded

So I implemented Listener Discovery Service in need to access grpc via REST so I put grpc-JSON transcoder filter on it, and I created the listener object that LDS API can use it like below
{
   "listeners":[
      {
         "name":"new_listener",
         "address":"tcp://<IP_ADDRESS>:80",
         "filters":[
            {
               "type":"read",
               "name":"http_connection_manager",
               "config":{
                  "codec_type":"auto",
                  "stat_prefix":"ingress_http",
                  "access_log":[
                     {
                        "path":"/tmp/envoy.access.log"
                     }
                  ],
                  "rds":{
                     "cluster":"rds",
                     "route_config_name":"default-route",
                     "refresh_delay_ms":3000
                  },
                  "filters":[
                     {
                        "type":"both",
                        "name":"grpc_json_transcoder",
                        "config":{
                           "proto_descriptor":"/etc/out.pb",
                           "services":[
                              "garuda.Garuda",
                              "pertamina.Pertamina"
                           ],
                           "print_options":{
                              "add_whitespace":false,
                              "always_print_primitive_fields":false,
                              "always_print_enums_as_ints":false,
                              "preserve_proto_field_names":false
                           }
                        }
                     },
                     {
                        "type":"decoder",
                        "name":"router",
                        "config":{

                        }
                     }
                  ]
               }
            }
         ]
      }
   ]
}

so I put the transcoder filter in it and I put the descriptor file as well, but  when I access it via postman or curl it has no response at all.But it has a response when I put the listeners manually on envoy config like this below
{
    "listeners": [{
        "address": "tcp://<IP_ADDRESS>:80",
        "filters": [{
            "type": "read",
            "name": "http_connection_manager",
            "config": {
                "codec_type": "auto",
                "stat_prefix": "ingress_http",
                "access_log": [{"path": "/tmp/envoy.access.log"}],
		"rds": {
                  "cluster": "rds",
          	  "route_config_name": "route1",
                  "refresh_delay_ms": 3000
        	},
                "filters": [
                    {
  		    "type": "both",
                    "name": "grpc_json_transcoder",
                    "config": {
                      "proto_descriptor": "/etc/out.pb",
                      "services": ["garuda.Garuda","pertamina.Pertamina"],
                      "print_options": {
                      "add_whitespace": false,
                      "always_print_primitive_fields": false,
                      "always_print_enums_as_ints": false,
                      "preserve_proto_field_names": false
                   }

                 }
                },

                {
                    "type": "decoder",
                    "name": "router",
                    "config": {}
                }
            ]
            }
        }]
    }],
    "admin": {
        "access_log_path": "/tmp/admin_access.log",
        "address": "tcp://<IP_ADDRESS>:9901"
    },
    "cluster_manager": {
         "sds": {
            "cluster": {
                "name": "fooServiceDiscovery",
                "type": "static",
                "connect_timeout_ms": 250,
                "lb_type": "round_robin",
                "hosts": [
                    {
                        "url": "tcp://<IP_ADDRESS>:2045"
                    }
                ]
            },
            "refresh_delay_ms": 100
        },
        "cds": {
            "cluster": {
                "name": "ClusterDiscovery",
                "type": "static",
                "connect_timeout_ms": 250,
                "lb_type": "round_robin",
                "hosts": [
                    {
                        "url": "tcp://<IP_ADDRESS>:2045"
                    }
                ]
            },
            "refresh_delay_ms": 100
        },
        "clusters": [
           {
	      "name": "rds",
     	      "connect_timeout_ms": 250,
              "type": "static",
              "lb_type": "round_robin",
              "hosts": [{"url": "tcp://<IP_ADDRESS>:2045"}]
           }
      ]
    }
}

is there any additional configuration if I add it via LDS or should I put manually on envoy config?
Thank's in advance

This shouldn't be happening. Can you provide a log for the LDS situation generated with -l trace?

The problem may caused by the proto descriptor, which is loaded from envoy side, not LDS. Do you have the proto descriptor in Envoy side or LDS? We should consider providing the proto descriptor inline in the config.

@htuch OK, i'll try it

@lizan by the way, I run the envoy with the docker-compose and add the descriptor file as attached volume so I think the file is exist, and I define the file in LDS at the same location where the descriptor was stored in compose file. So I assume that the envoy run first, and then get the LDS object which is the listeners config. But when I reach grpc via REST it has no response at all.
Differently when I put the listeners config manually or in line with envoy config, I can reach the grpc via REST.

@syukur91 beyond debug/trace output, also seeing a dump of the /stats admin endpoint after you have loaded LDS and tried some requests would be useful.

@mattklein123 how can I debug the envoy running via docker?

@mattklein123  I got this log talk about my grpc_json_transcoder at line 3
{"log":"[2017-08-08 05:47:19.711][1][info][config] source/server/config/network/http_connection_manager.cc:171]     filter #0\n","stream":"stderr","time":"2017-08-08T05:47:19.71183742Z"}
{"log":"[2017-08-08 05:47:19.711][1][info][config] source/server/config/network/http_connection_manager.cc:172]       type: both\n","stream":"stderr","time":"2017-08-08T05:47:19.711839859Z"}
{"log":"[2017-08-08 05:47:19.711][1][info][config] source/server/config/network/http_connection_manager.cc:173]       name: grpc_json_transcoder\n","stream":"stderr","time":"2017-08-08T05:47:19.711841781Z"}
{"log":"[2017-08-08 05:47:19.712][1][info][config] source/server/config/network/http_connection_manager.cc:171]     filter #1\n","stream":"stderr","time":"2017-08-08T05:47:19.712771955Z"}
{"log":"[2017-08-08 05:47:19.712][1][info][config] source/server/config/network/http_connection_manager.cc:172]       type: decoder\n","stream":"stderr","time":"2017-08-08T05:47:19.712777063Z"}
{"log":"[2017-08-08 05:47:19.712][1][info][config] source/server/config/network/http_connection_manager.cc:173]       name: router\n","stream":"stderr","time":"2017-08-08T05:47:19.712781094Z"}
{"log":"[2017-08-08 05:47:19.712][1][info][config] source/server/listener_manager_impl.cc:147] add active listener: name=new_listener, hash=17958779688624395585, address=<IP_ADDRESS>:80\n","stream":"stderr","time":"2017-08-08T05:47:19.712856583Z"}
{"log":"[2017-08-08 05:47:19.712][1][info][upstream] source/server/lds_api.cc:54] lds: add/update listener 'new_listener'\n","stream":"stderr","time":"2017-08-08T05:47:19.712859218Z"}

it seems like no error message at all

@syukur91 The full log from -trace and /stats from the admin endpoint (as defined in the Envoy configuration file) would be useful to try and debug this in this ticket. In particular, it would be useful to see what happens when an incoming request is being processed. You can add additional trace/debug level log statements to the gRPC transcoder filter as well.

@htuch  the ``` -l trace `` like below
{"log":"[2017-08-09 04:35:02.504][1][debug][pool] source/common/http/http1/conn_pool.cc:61] creating a new connection\n","stream":"stderr","time":"2017-08-09T04:35:02.504512473Z"}
{"log":"[2017-08-09 04:35:02.504][1][info][client] source/common/http/codec_client.cc:21] [C5] connecting\n","stream":"stderr","time":"2017-08-09T04:35:02.504514325Z"}
{"log":"[2017-08-09 04:35:02.504][1][debug][connection] source/common/network/connection_impl.cc:420] [C5] connecting to <IP_ADDRESS>:2045\n","stream":"stderr","time":"2017-08-09T04:35:02.504516157Z"}
{"log":"[2017-08-09 04:35:02.504][1][debug][connection] source/common/network/connection_impl.cc:429] [C5] connection in progress\n","stream":"stderr","time":"2017-08-09T04:35:02.504519483Z"}
{"log":"[2017-08-09 04:35:02.504][1][debug][pool] source/common/http/http1/conn_pool.cc:87] queueing request due to no available connections\n","stream":"stderr","time":"2017-08-09T04:35:02.504521408Z"}
{"log":"[2017-08-09 04:35:02.504][1][info][config] source/server/config/network/http_connection_manager.cc:171]     filter #0\n","stream":"stderr","time":"2017-08-09T04:35:02.504645253Z"}
{"log":"[2017-08-09 04:35:02.504][1][info][config] source/server/config/network/http_connection_manager.cc:172]       type: both\n","stream":"stderr","time":"2017-08-09T04:35:02.504649723Z"}
{"log":"[2017-08-09 04:35:02.504][1][info][config] source/server/config/network/http_connection_manager.cc:173]       name: grpc_json_transcoder\n","stream":"stderr","time":"2017-08-09T04:35:02.504651743Z"}
{"log":"[2017-08-09 04:35:02.505][1][info][config] source/server/config/network/http_connection_manager.cc:171]     filter #1\n","stream":"stderr","time":"2017-08-09T04:35:02.505636256Z"}
{"log":"[2017-08-09 04:35:02.505][1][info][config] source/server/config/network/http_connection_manager.cc:172]       type: decoder\n","stream":"stderr","time":"2017-08-09T04:35:02.505649273Z"}
{"log":"[2017-08-09 04:35:02.505][1][info][config] source/server/config/network/http_connection_manager.cc:173]       name: router\n","stream":"stderr","time":"2017-08-09T04:35:02.505652014Z"}
{"log":"[2017-08-09 04:35:02.505][1][info][config] source/server/listener_manager_impl.cc:147] add active listener: name=new_listener, hash=11909575914846552672, address=<IP_ADDRESS>:80\n","stream":"stderr","time":"2017-08-09T04:35:02.505729261Z"}
{"log":"[2017-08-09 04:35:02.505][1][info][upstream] source/server/lds_api.cc:54] lds: add/update listener 'new_listener'\n","stream":"stderr","time":"2017-08-09T04:35:02.50573534Z"}

Can you provide a fuller log? The fragment you provide above is for the listener loading via LDS, not the actual request. Can you provide the /stats from admin as well?
It looks like Envoy will only 404 in the router, when it doesn't have a matching route or cluster (the gRPC transcoder filter sends 400 error codes). I notice in your config that you have RDS configured. Are you sure the route table is correctly loaded? I'm starting to wonder if this worked locally because you had both listeners/routes as static, but isn't working with xDS because RDS is the issue rather than LDS.

So here's the LDS,RDS,CDS,& SDS that I,ve been prepared so far. And here's the log that I get from docker container the file is too big so I uploaded it to dropbox
https://www.dropbox.com/s/s853vcfkf1rosj5/8533a6ef6e95f6391bda5221f06f606a658000d126e73570d5bfc7931f5faf45-json.log?dl=0
listeners object

{
    "listeners": [
        {
            "name": "new_listener",
            "address": "tcp://<IP_ADDRESS>:80",
            "filters": [
                {
                    "type": "read",
                    "name": "http_connection_manager",
                    "config": {
                        "codec_type": "auto",
                        "stat_prefix": "ingress_http",
                        "access_log": [
                            {
                                "path": "/tmp/envoy.access.log"
                            }
                        ],
                        "rds": {
                            "cluster": "rds",
                            "route_config_name": "default-route",
                            "refresh_delay_ms": 3000
                        },
                        "filters": [
                            {
                                "type": "decoder",
                                "name": "router",
                                "config": {}
                            },
                            {
                                "type": "both",
                                "name": "grpc_json_transcoder",
                                "config": {
                                    "proto_descriptor": "/etc/out.pb",
                                    "services": [
                                        "garuda.Garuda",
                                        "pertamina.Pertamina"
                                    ],
                                    "print_options": {
                                        "add_whitespace": false,
                                        "always_print_primitive_fields": false,
                                        "always_print_enums_as_ints": false,
                                        "preserve_proto_field_names": false
                                    }
                                }
                            }
                        ]
                    }
                }
            ]
        }
    ]
}

route object
{
    "virtual_hosts": [
        {
            "domains": [
              "*"
            ],
            "routes": [
                {
                    "prefix": "/garuda",
                    "cluster": "grpc1"
                },
                {
                    "prefix": "/pertamina",
                    "cluster": "grpc2"
                }
            ],
            "name": "grpc_service"
        }
    ]
}

cluster object

{
    "clusters": [
        {
            "name": "grpc1",
            "type": "sds",
            "connect_timeout_ms": 250,
            "lb_type": "round_robin",
            "service_name": "artoz",
            "features": "http2"
        },
        {
            "name": "grpc2",
            "type": "sds",
            "connect_timeout_ms": 250,
            "lb_type": "round_robin",
            "service_name": "artoz-2",
            "features": "http2"
        }
    ]
}

service objects

{
    "hosts": [
        {
            "ip_address": "<IP_ADDRESS>",
            "last_check_in": "22-08-2017",
            "port": 44434,
            "revision": "1",
            "service": "artoz-2",
            "service_repo_name": "node1",
            "tags": {}
        }
    ],
    "env": "production",
    "service": "artoz-2"
}

{
    "hosts": [
        {
            "ip_address": "<IP_ADDRESS>",
            "last_check_in": "22-08-2017",
            "port": 44433,
            "revision": "1",
            "service": "artoz",
            "service_repo_name": "node1",
            "tags": {}
        }
    ],
    "env": "production",
    "service": "artoz"
}

proto file sample
And I add a sample of proto file as well, using google api to produce REST API address for my grpc, RDS is not a problem when I don't use LDS and  add the listener in line  with the config.

syntax = "proto3";

package garuda;

import "annotations.proto";

service Garuda {
  rpc WeatherCall (Request) returns (Response) {

  option (google.api.http) = {
       get: "/garuda/v1/WeatherCall"
     };
  }
}

message Request {
  string query = 1;
  string language = 2;
}

message ResponseMeta {
  string place = 1;
}

message Response {
  ResponseMeta meta = 1;
  float temperature = 2;
  int32 pressure = 3;
  string description = 4;
}

stats output
cluster.ClusterDiscovery.internal.upstream_rq_200: 267
cluster.ClusterDiscovery.internal.upstream_rq_2xx: 267
cluster.ClusterDiscovery.lb_healthy_panic: 0
cluster.ClusterDiscovery.lb_local_cluster_not_ok: 0
cluster.ClusterDiscovery.lb_recalculate_zone_structures: 0
cluster.ClusterDiscovery.lb_zone_cluster_too_small: 0
cluster.ClusterDiscovery.lb_zone_no_capacity_left: 0
cluster.ClusterDiscovery.lb_zone_number_differs: 0
cluster.ClusterDiscovery.lb_zone_routing_all_directly: 0
cluster.ClusterDiscovery.lb_zone_routing_cross_zone: 0
cluster.ClusterDiscovery.lb_zone_routing_sampled: 0
cluster.ClusterDiscovery.max_host_weight: 0
cluster.ClusterDiscovery.membership_change: 0
cluster.ClusterDiscovery.membership_healthy: 1
cluster.ClusterDiscovery.membership_total: 1
cluster.ClusterDiscovery.update_attempt: 0
cluster.ClusterDiscovery.update_failure: 0
cluster.ClusterDiscovery.update_success: 0
cluster.ClusterDiscovery.upstream_cx_active: 1
cluster.ClusterDiscovery.upstream_cx_close_notify: 0
cluster.ClusterDiscovery.upstream_cx_connect_fail: 0
cluster.ClusterDiscovery.upstream_cx_connect_timeout: 0
cluster.ClusterDiscovery.upstream_cx_destroy: 0
cluster.ClusterDiscovery.upstream_cx_destroy_local: 0
cluster.ClusterDiscovery.upstream_cx_destroy_local_with_active_rq: 0
cluster.ClusterDiscovery.upstream_cx_destroy_remote: 0
cluster.ClusterDiscovery.upstream_cx_destroy_remote_with_active_rq: 0
cluster.ClusterDiscovery.upstream_cx_destroy_with_active_rq: 0
cluster.ClusterDiscovery.upstream_cx_http1_total: 1
cluster.ClusterDiscovery.upstream_cx_http2_total: 0
cluster.ClusterDiscovery.upstream_cx_max_requests: 0
cluster.ClusterDiscovery.upstream_cx_none_healthy: 0
cluster.ClusterDiscovery.upstream_cx_overflow: 0
cluster.ClusterDiscovery.upstream_cx_protocol_error: 0
cluster.ClusterDiscovery.upstream_cx_rx_bytes_buffered: 472
cluster.ClusterDiscovery.upstream_cx_rx_bytes_total: 126024
cluster.ClusterDiscovery.upstream_cx_total: 1
cluster.ClusterDiscovery.upstream_cx_tx_bytes_buffered: 0
cluster.ClusterDiscovery.upstream_cx_tx_bytes_total: 48861
cluster.ClusterDiscovery.upstream_rq_200: 267
cluster.ClusterDiscovery.upstream_rq_2xx: 267
cluster.ClusterDiscovery.upstream_rq_active: 0
cluster.ClusterDiscovery.upstream_rq_cancelled: 0
cluster.ClusterDiscovery.upstream_rq_maintenance_mode: 0
cluster.ClusterDiscovery.upstream_rq_pending_active: 0
cluster.ClusterDiscovery.upstream_rq_pending_failure_eject: 0
cluster.ClusterDiscovery.upstream_rq_pending_overflow: 0
cluster.ClusterDiscovery.upstream_rq_pending_total: 1
cluster.ClusterDiscovery.upstream_rq_per_try_timeout: 0
cluster.ClusterDiscovery.upstream_rq_retry: 0
cluster.ClusterDiscovery.upstream_rq_retry_overflow: 0
cluster.ClusterDiscovery.upstream_rq_retry_success: 0
cluster.ClusterDiscovery.upstream_rq_rx_reset: 0
cluster.ClusterDiscovery.upstream_rq_timeout: 0
cluster.ClusterDiscovery.upstream_rq_total: 267
cluster.ClusterDiscovery.upstream_rq_tx_reset: 0
cluster.fooServiceDiscovery.internal.upstream_rq_200: 537
cluster.fooServiceDiscovery.internal.upstream_rq_2xx: 537
cluster.fooServiceDiscovery.lb_healthy_panic: 0
cluster.fooServiceDiscovery.lb_local_cluster_not_ok: 0
cluster.fooServiceDiscovery.lb_recalculate_zone_structures: 0
cluster.fooServiceDiscovery.lb_zone_cluster_too_small: 0
cluster.fooServiceDiscovery.lb_zone_no_capacity_left: 0
cluster.fooServiceDiscovery.lb_zone_number_differs: 0
cluster.fooServiceDiscovery.lb_zone_routing_all_directly: 0
cluster.fooServiceDiscovery.lb_zone_routing_cross_zone: 0
cluster.fooServiceDiscovery.lb_zone_routing_sampled: 0
cluster.fooServiceDiscovery.max_host_weight: 0
cluster.fooServiceDiscovery.membership_change: 0
cluster.fooServiceDiscovery.membership_healthy: 1
cluster.fooServiceDiscovery.membership_total: 1
cluster.fooServiceDiscovery.update_attempt: 0
cluster.fooServiceDiscovery.update_failure: 0
cluster.fooServiceDiscovery.update_success: 0
cluster.fooServiceDiscovery.upstream_cx_active: 2
cluster.fooServiceDiscovery.upstream_cx_close_notify: 0
cluster.fooServiceDiscovery.upstream_cx_connect_fail: 0
cluster.fooServiceDiscovery.upstream_cx_connect_timeout: 0
cluster.fooServiceDiscovery.upstream_cx_destroy: 0
cluster.fooServiceDiscovery.upstream_cx_destroy_local: 0
cluster.fooServiceDiscovery.upstream_cx_destroy_local_with_active_rq: 0
cluster.fooServiceDiscovery.upstream_cx_destroy_remote: 0
cluster.fooServiceDiscovery.upstream_cx_destroy_remote_with_active_rq: 0
cluster.fooServiceDiscovery.upstream_cx_destroy_with_active_rq: 0
cluster.fooServiceDiscovery.upstream_cx_http1_total: 2
cluster.fooServiceDiscovery.upstream_cx_http2_total: 0
cluster.fooServiceDiscovery.upstream_cx_max_requests: 0
cluster.fooServiceDiscovery.upstream_cx_none_healthy: 0
cluster.fooServiceDiscovery.upstream_cx_overflow: 0
cluster.fooServiceDiscovery.upstream_cx_protocol_error: 0
cluster.fooServiceDiscovery.upstream_cx_rx_bytes_buffered: 802
cluster.fooServiceDiscovery.upstream_cx_rx_bytes_total: 216409
cluster.fooServiceDiscovery.upstream_cx_total: 2
cluster.fooServiceDiscovery.upstream_cx_tx_bytes_buffered: 0
cluster.fooServiceDiscovery.upstream_cx_tx_bytes_total: 96122
cluster.fooServiceDiscovery.upstream_rq_200: 537
cluster.fooServiceDiscovery.upstream_rq_2xx: 537
cluster.fooServiceDiscovery.upstream_rq_active: 0
cluster.fooServiceDiscovery.upstream_rq_cancelled: 0
cluster.fooServiceDiscovery.upstream_rq_maintenance_mode: 0
cluster.fooServiceDiscovery.upstream_rq_pending_active: 0
cluster.fooServiceDiscovery.upstream_rq_pending_failure_eject: 0
cluster.fooServiceDiscovery.upstream_rq_pending_overflow: 0
cluster.fooServiceDiscovery.upstream_rq_pending_total: 2
cluster.fooServiceDiscovery.upstream_rq_per_try_timeout: 0
cluster.fooServiceDiscovery.upstream_rq_retry: 0
cluster.fooServiceDiscovery.upstream_rq_retry_overflow: 0
cluster.fooServiceDiscovery.upstream_rq_retry_success: 0
cluster.fooServiceDiscovery.upstream_rq_rx_reset: 0
cluster.fooServiceDiscovery.upstream_rq_timeout: 0
cluster.fooServiceDiscovery.upstream_rq_total: 537
cluster.fooServiceDiscovery.upstream_rq_tx_reset: 0
cluster.grpc1.lb_healthy_panic: 0
cluster.grpc1.lb_local_cluster_not_ok: 0
cluster.grpc1.lb_recalculate_zone_structures: 0
cluster.grpc1.lb_zone_cluster_too_small: 0
cluster.grpc1.lb_zone_no_capacity_left: 0
cluster.grpc1.lb_zone_number_differs: 0
cluster.grpc1.lb_zone_routing_all_directly: 0
cluster.grpc1.lb_zone_routing_cross_zone: 0
cluster.grpc1.lb_zone_routing_sampled: 0
cluster.grpc1.max_host_weight: 1
cluster.grpc1.membership_change: 1
cluster.grpc1.membership_healthy: 1
cluster.grpc1.membership_total: 1
cluster.grpc1.update_attempt: 269
cluster.grpc1.update_failure: 0
cluster.grpc1.update_rejected: 0
cluster.grpc1.update_success: 269
cluster.grpc1.upstream_cx_active: 0
cluster.grpc1.upstream_cx_close_notify: 0
cluster.grpc1.upstream_cx_connect_fail: 0
cluster.grpc1.upstream_cx_connect_timeout: 0
cluster.grpc1.upstream_cx_destroy: 0
cluster.grpc1.upstream_cx_destroy_local: 0
cluster.grpc1.upstream_cx_destroy_local_with_active_rq: 0
cluster.grpc1.upstream_cx_destroy_remote: 0
cluster.grpc1.upstream_cx_destroy_remote_with_active_rq: 0
cluster.grpc1.upstream_cx_destroy_with_active_rq: 0
cluster.grpc1.upstream_cx_http1_total: 0
cluster.grpc1.upstream_cx_http2_total: 0
cluster.grpc1.upstream_cx_max_requests: 0
cluster.grpc1.upstream_cx_none_healthy: 0
cluster.grpc1.upstream_cx_overflow: 0
cluster.grpc1.upstream_cx_protocol_error: 0
cluster.grpc1.upstream_cx_rx_bytes_buffered: 0
cluster.grpc1.upstream_cx_rx_bytes_total: 0
cluster.grpc1.upstream_cx_total: 0
cluster.grpc1.upstream_cx_tx_bytes_buffered: 0
cluster.grpc1.upstream_cx_tx_bytes_total: 0
cluster.grpc1.upstream_rq_active: 0
cluster.grpc1.upstream_rq_cancelled: 0
cluster.grpc1.upstream_rq_maintenance_mode: 0
cluster.grpc1.upstream_rq_pending_active: 0
cluster.grpc1.upstream_rq_pending_failure_eject: 0
cluster.grpc1.upstream_rq_pending_overflow: 0
cluster.grpc1.upstream_rq_pending_total: 0
cluster.grpc1.upstream_rq_per_try_timeout: 0
cluster.grpc1.upstream_rq_retry: 0
cluster.grpc1.upstream_rq_retry_overflow: 0
cluster.grpc1.upstream_rq_retry_success: 0
cluster.grpc1.upstream_rq_rx_reset: 0
cluster.grpc1.upstream_rq_timeout: 0
cluster.grpc1.upstream_rq_total: 0
cluster.grpc1.upstream_rq_tx_reset: 0
cluster.grpc2.lb_healthy_panic: 0
cluster.grpc2.lb_local_cluster_not_ok: 0
cluster.grpc2.lb_recalculate_zone_structures: 0
cluster.grpc2.lb_zone_cluster_too_small: 0
cluster.grpc2.lb_zone_no_capacity_left: 0
cluster.grpc2.lb_zone_number_differs: 0
cluster.grpc2.lb_zone_routing_all_directly: 0
cluster.grpc2.lb_zone_routing_cross_zone: 0
cluster.grpc2.lb_zone_routing_sampled: 0
cluster.grpc2.max_host_weight: 1
cluster.grpc2.membership_change: 1
cluster.grpc2.membership_healthy: 1
cluster.grpc2.membership_total: 1
cluster.grpc2.update_attempt: 268
cluster.grpc2.update_failure: 0
cluster.grpc2.update_rejected: 0
cluster.grpc2.update_success: 268
cluster.grpc2.upstream_cx_active: 0
cluster.grpc2.upstream_cx_close_notify: 0
cluster.grpc2.upstream_cx_connect_fail: 0
cluster.grpc2.upstream_cx_connect_timeout: 0
cluster.grpc2.upstream_cx_destroy: 0
cluster.grpc2.upstream_cx_destroy_local: 0
cluster.grpc2.upstream_cx_destroy_local_with_active_rq: 0
cluster.grpc2.upstream_cx_destroy_remote: 0
cluster.grpc2.upstream_cx_destroy_remote_with_active_rq: 0
cluster.grpc2.upstream_cx_destroy_with_active_rq: 0
cluster.grpc2.upstream_cx_http1_total: 0
cluster.grpc2.upstream_cx_http2_total: 0
cluster.grpc2.upstream_cx_max_requests: 0
cluster.grpc2.upstream_cx_none_healthy: 0
cluster.grpc2.upstream_cx_overflow: 0
cluster.grpc2.upstream_cx_protocol_error: 0
cluster.grpc2.upstream_cx_rx_bytes_buffered: 0
cluster.grpc2.upstream_cx_rx_bytes_total: 0
cluster.grpc2.upstream_cx_total: 0
cluster.grpc2.upstream_cx_tx_bytes_buffered: 0
cluster.grpc2.upstream_cx_tx_bytes_total: 0
cluster.grpc2.upstream_rq_active: 0
cluster.grpc2.upstream_rq_cancelled: 0
cluster.grpc2.upstream_rq_maintenance_mode: 0
cluster.grpc2.upstream_rq_pending_active: 0
cluster.grpc2.upstream_rq_pending_failure_eject: 0
cluster.grpc2.upstream_rq_pending_overflow: 0
cluster.grpc2.upstream_rq_pending_total: 0
cluster.grpc2.upstream_rq_per_try_timeout: 0
cluster.grpc2.upstream_rq_retry: 0
cluster.grpc2.upstream_rq_retry_overflow: 0
cluster.grpc2.upstream_rq_retry_success: 0
cluster.grpc2.upstream_rq_rx_reset: 0
cluster.grpc2.upstream_rq_timeout: 0
cluster.grpc2.upstream_rq_total: 0
cluster.grpc2.upstream_rq_tx_reset: 0
cluster.lds.internal.upstream_rq_200: 1
cluster.lds.internal.upstream_rq_2xx: 1
cluster.lds.lb_healthy_panic: 0
cluster.lds.lb_local_cluster_not_ok: 0
cluster.lds.lb_recalculate_zone_structures: 0
cluster.lds.lb_zone_cluster_too_small: 0
cluster.lds.lb_zone_no_capacity_left: 0
cluster.lds.lb_zone_number_differs: 0
cluster.lds.lb_zone_routing_all_directly: 0
cluster.lds.lb_zone_routing_cross_zone: 0
cluster.lds.lb_zone_routing_sampled: 0
cluster.lds.max_host_weight: 0
cluster.lds.membership_change: 0
cluster.lds.membership_healthy: 1
cluster.lds.membership_total: 1
cluster.lds.update_attempt: 0
cluster.lds.update_failure: 0
cluster.lds.update_success: 0
cluster.lds.upstream_cx_active: 1
cluster.lds.upstream_cx_close_notify: 0
cluster.lds.upstream_cx_connect_fail: 0
cluster.lds.upstream_cx_connect_timeout: 0
cluster.lds.upstream_cx_destroy: 0
cluster.lds.upstream_cx_destroy_local: 0
cluster.lds.upstream_cx_destroy_local_with_active_rq: 0
cluster.lds.upstream_cx_destroy_remote: 0
cluster.lds.upstream_cx_destroy_remote_with_active_rq: 0
cluster.lds.upstream_cx_destroy_with_active_rq: 0
cluster.lds.upstream_cx_http1_total: 1
cluster.lds.upstream_cx_http2_total: 0
cluster.lds.upstream_cx_max_requests: 0
cluster.lds.upstream_cx_none_healthy: 0
cluster.lds.upstream_cx_overflow: 0
cluster.lds.upstream_cx_protocol_error: 0
cluster.lds.upstream_cx_rx_bytes_buffered: 884
cluster.lds.upstream_cx_rx_bytes_total: 884
cluster.lds.upstream_cx_total: 1
cluster.lds.upstream_cx_tx_bytes_buffered: 0
cluster.lds.upstream_cx_tx_bytes_total: 171
cluster.lds.upstream_rq_200: 1
cluster.lds.upstream_rq_2xx: 1
cluster.lds.upstream_rq_active: 0
cluster.lds.upstream_rq_cancelled: 0
cluster.lds.upstream_rq_maintenance_mode: 0
cluster.lds.upstream_rq_pending_active: 0
cluster.lds.upstream_rq_pending_failure_eject: 0
cluster.lds.upstream_rq_pending_overflow: 0
cluster.lds.upstream_rq_pending_total: 1
cluster.lds.upstream_rq_per_try_timeout: 0
cluster.lds.upstream_rq_retry: 0
cluster.lds.upstream_rq_retry_overflow: 0
cluster.lds.upstream_rq_retry_success: 0
cluster.lds.upstream_rq_rx_reset: 0
cluster.lds.upstream_rq_timeout: 0
cluster.lds.upstream_rq_total: 1
cluster.lds.upstream_rq_tx_reset: 0
cluster.rds.internal.upstream_rq_200: 9
cluster.rds.internal.upstream_rq_2xx: 9
cluster.rds.lb_healthy_panic: 0
cluster.rds.lb_local_cluster_not_ok: 0
cluster.rds.lb_recalculate_zone_structures: 0
cluster.rds.lb_zone_cluster_too_small: 0
cluster.rds.lb_zone_no_capacity_left: 0
cluster.rds.lb_zone_number_differs: 0
cluster.rds.lb_zone_routing_all_directly: 0
cluster.rds.lb_zone_routing_cross_zone: 0
cluster.rds.lb_zone_routing_sampled: 0
cluster.rds.max_host_weight: 0
cluster.rds.membership_change: 0
cluster.rds.membership_healthy: 1
cluster.rds.membership_total: 1
cluster.rds.update_attempt: 0
cluster.rds.update_failure: 0
cluster.rds.update_success: 0
cluster.rds.upstream_cx_active: 1
cluster.rds.upstream_cx_close_notify: 0
cluster.rds.upstream_cx_connect_fail: 0
cluster.rds.upstream_cx_connect_timeout: 0
cluster.rds.upstream_cx_destroy: 0
cluster.rds.upstream_cx_destroy_local: 0
cluster.rds.upstream_cx_destroy_local_with_active_rq: 0
cluster.rds.upstream_cx_destroy_remote: 0
cluster.rds.upstream_cx_destroy_remote_with_active_rq: 0
cluster.rds.upstream_cx_destroy_with_active_rq: 0
cluster.rds.upstream_cx_http1_total: 1
cluster.rds.upstream_cx_http2_total: 0
cluster.rds.upstream_cx_max_requests: 0
cluster.rds.upstream_cx_none_healthy: 0
cluster.rds.upstream_cx_overflow: 0
cluster.rds.upstream_cx_protocol_error: 0
cluster.rds.upstream_cx_rx_bytes_buffered: 1689
cluster.rds.upstream_cx_rx_bytes_total: 15201
cluster.rds.upstream_cx_total: 1
cluster.rds.upstream_cx_tx_bytes_buffered: 0
cluster.rds.upstream_cx_tx_bytes_total: 1638
cluster.rds.upstream_rq_200: 9
cluster.rds.upstream_rq_2xx: 9
cluster.rds.upstream_rq_active: 0
cluster.rds.upstream_rq_cancelled: 0
cluster.rds.upstream_rq_maintenance_mode: 0
cluster.rds.upstream_rq_pending_active: 0
cluster.rds.upstream_rq_pending_failure_eject: 0
cluster.rds.upstream_rq_pending_overflow: 0
cluster.rds.upstream_rq_pending_total: 1
cluster.rds.upstream_rq_per_try_timeout: 0
cluster.rds.upstream_rq_retry: 0
cluster.rds.upstream_rq_retry_overflow: 0
cluster.rds.upstream_rq_retry_success: 0
cluster.rds.upstream_rq_rx_reset: 0
cluster.rds.upstream_rq_timeout: 0
cluster.rds.upstream_rq_total: 9
cluster.rds.upstream_rq_tx_reset: 0
cluster_manager.cds.update_attempt: 267
cluster_manager.cds.update_failure: 0
cluster_manager.cds.update_success: 267
cluster_manager.cluster_added: 6
cluster_manager.cluster_modified: 0
cluster_manager.cluster_removed: 0
cluster_manager.total_clusters: 6
filesystem.flushed_by_timer: 5
filesystem.reopen_failed: 0
filesystem.write_buffered: 8
filesystem.write_completed: 4
filesystem.write_total_buffered: 0
http.admin.downstream_cx_active: 1
http.admin.downstream_cx_destroy: 1
http.admin.downstream_cx_destroy_active_rq: 0
http.admin.downstream_cx_destroy_local: 0
http.admin.downstream_cx_destroy_local_active_rq: 0
http.admin.downstream_cx_destroy_remote: 1
http.admin.downstream_cx_destroy_remote_active_rq: 0
http.admin.downstream_cx_drain_close: 0
http.admin.downstream_cx_http1_active: 1
http.admin.downstream_cx_http1_total: 2
http.admin.downstream_cx_http2_active: 0
http.admin.downstream_cx_http2_total: 0
http.admin.downstream_cx_idle_timeout: 0
http.admin.downstream_cx_protocol_error: 0
http.admin.downstream_cx_rx_bytes_buffered: 83
http.admin.downstream_cx_rx_bytes_total: 170
http.admin.downstream_cx_ssl_active: 0
http.admin.downstream_cx_ssl_total: 0
http.admin.downstream_cx_total: 2
http.admin.downstream_cx_tx_bytes_buffered: 0
http.admin.downstream_cx_tx_bytes_total: 123
http.admin.downstream_rq_2xx: 1
http.admin.downstream_rq_3xx: 0
http.admin.downstream_rq_4xx: 0
http.admin.downstream_rq_5xx: 0
http.admin.downstream_rq_active: 1
http.admin.downstream_rq_http1_total: 2
http.admin.downstream_rq_http2_total: 0
http.admin.downstream_rq_non_relative_path: 0
http.admin.downstream_rq_response_before_rq_complete: 0
http.admin.downstream_rq_rx_reset: 0
http.admin.downstream_rq_total: 2
http.admin.downstream_rq_tx_reset: 0
http.admin.failed_generate_uuid: 0
http.admin.tracing.tracing.client_enabled: 0
http.admin.tracing.tracing.health_check: 0
http.admin.tracing.tracing.not_traceable: 0
http.admin.tracing.tracing.random_sampling: 0
http.admin.tracing.tracing.service_forced: 0
http.async-client.no_cluster: 0
http.async-client.no_route: 0
http.async-client.rq_redirect: 0
http.async-client.rq_total: 814
http.ingress_http.downstream_cx_active: 1
http.ingress_http.downstream_cx_destroy: 0
http.ingress_http.downstream_cx_destroy_active_rq: 0
http.ingress_http.downstream_cx_destroy_local: 0
http.ingress_http.downstream_cx_destroy_local_active_rq: 0
http.ingress_http.downstream_cx_destroy_remote: 0
http.ingress_http.downstream_cx_destroy_remote_active_rq: 0
http.ingress_http.downstream_cx_drain_close: 0
http.ingress_http.downstream_cx_http1_active: 1
http.ingress_http.downstream_cx_http1_total: 1
http.ingress_http.downstream_cx_http2_active: 0
http.ingress_http.downstream_cx_http2_total: 0
http.ingress_http.downstream_cx_idle_timeout: 0
http.ingress_http.downstream_cx_protocol_error: 0
http.ingress_http.downstream_cx_rx_bytes_buffered: 474
http.ingress_http.downstream_cx_rx_bytes_total: 3321
http.ingress_http.downstream_cx_ssl_active: 0
http.ingress_http.downstream_cx_ssl_total: 0
http.ingress_http.downstream_cx_total: 1
http.ingress_http.downstream_cx_tx_bytes_buffered: 0
http.ingress_http.downstream_cx_tx_bytes_total: 679
http.ingress_http.downstream_rq_2xx: 0
http.ingress_http.downstream_rq_3xx: 0
http.ingress_http.downstream_rq_4xx: 7
http.ingress_http.downstream_rq_5xx: 0
http.ingress_http.downstream_rq_active: 0
http.ingress_http.downstream_rq_http1_total: 7
http.ingress_http.downstream_rq_http2_total: 0
http.ingress_http.downstream_rq_non_relative_path: 0
http.ingress_http.downstream_rq_response_before_rq_complete: 0
http.ingress_http.downstream_rq_rx_reset: 0
http.ingress_http.downstream_rq_total: 7
http.ingress_http.downstream_rq_tx_reset: 0
http.ingress_http.failed_generate_uuid: 0
http.ingress_http.no_cluster: 0
http.ingress_http.no_route: 7
http.ingress_http.rds.config_reload: 1
http.ingress_http.rds.update_attempt: 9
http.ingress_http.rds.update_failure: 0
http.ingress_http.rds.update_success: 9
http.ingress_http.rq_redirect: 0
http.ingress_http.rq_total: 7
http.ingress_http.tracing.client_enabled: 0
http.ingress_http.tracing.health_check: 0
http.ingress_http.tracing.not_traceable: 0
http.ingress_http.tracing.random_sampling: 0
http.ingress_http.tracing.service_forced: 0
listener.<IP_ADDRESS>_80.downstream_cx_active: 1
listener.<IP_ADDRESS>_80.downstream_cx_destroy: 0
listener.<IP_ADDRESS>_80.downstream_cx_proxy_proto_error: 0
listener.<IP_ADDRESS>_80.downstream_cx_total: 1
listener.admin.downstream_cx_active: 1
listener.admin.downstream_cx_destroy: 1
listener.admin.downstream_cx_proxy_proto_error: 0
listener.admin.downstream_cx_total: 2
listener_manager.lds.update_attempt: 1
listener_manager.lds.update_failure: 0
listener_manager.lds.update_success: 1
listener_manager.listener_added: 1
listener_manager.listener_create_failure: 0
listener_manager.listener_modified: 0
listener_manager.listener_removed: 0
listener_manager.total_listeners_active: 1
listener_manager.total_listeners_draining: 0
listener_manager.total_listeners_warming: 0
server.days_until_first_cert_expiring:<PHONE_NUMBER>
server.live: 1
server.memory_allocated: 2321320
server.memory_heap_size: 4194304
server.parent_connections: 0
server.total_connections: 1
server.uptime: 41
server.version: 8673095
server.watchdog_mega_miss: 0
server.watchdog_miss: 0
stats.overflow: 0

@syukur91 the order of the filters is wrong, router should be after grpc_json_transocder.

@lizan  I've changed the order of the filters to this, but it have no effect and still have no response at all
{
    "listeners": [
        {
            "name": "new_listener",
            "address": "tcp://<IP_ADDRESS>:80",
            "filters": [
                {
                    "type": "read",
                    "name": "http_connection_manager",
                    "config": {
                        "codec_type": "auto",
                        "stat_prefix": "ingress_http",
                        "access_log": [
                            {
                                "path": "/tmp/envoy.access.log"
                            }
                        ],
                        "rds": {
                            "cluster": "rds",
                            "route_config_name": "default-route",
                            "refresh_delay_ms": 3000
                        },
                        "filters": [
                            {
                                "type": "both",
                                "name": "grpc_json_transcoder",
                                "config": {
                                    "proto_descriptor": "/etc/out.pb",
                                    "services": [
                                        "garuda.Garuda",
                                        "pertamina.Pertamina"
                                    ],
                                    "print_options": {
                                        "add_whitespace": false,
                                        "always_print_primitive_fields": false,
                                        "always_print_enums_as_ints": false,
                                        "preserve_proto_field_names": false
                                    }
                                }
                            },
                            {
                                "type": "decoder",
                                "name": "router",
                                "config": {}
                            }
                        ]
                    }
                }
            ]
        }
    ]
}

These are the relevant lines where the 404 occurs:
{"log":"[2017-08-09 04:37:44.401][13][debug][http] source/common/http/conn_manager_impl.cc:400] [C6][S1] request headers complete (end_stream=true):\n","stream":"stderr","time":"2017-08-09T04:37:44.401769092Z"}
{"log":"[2017-08-09 04:37:44.401][13][debug][http] source/common/http/conn_manager_impl.cc:405] [C6][S1]   ':authority':'localhost'\n","stream":"stderr","time":"2017-08-09T04:37:44.401772782Z"}
{"log":"[2017-08-09 04:37:44.401][13][debug][http] source/common/http/conn_manager_impl.cc:405] [C6][S1]   'connection':'keep-alive'\n","stream":"stderr","time":"2017-08-09T04:37:44.401778287Z"}
{"log":"[2017-08-09 04:37:44.401][13][debug][http] source/common/http/conn_manager_impl.cc:405] [C6][S1]   'cache-control':'no-cache'\n","stream":"stderr","time":"2017-08-09T04:37:44.401782122Z"}
{"log":"[2017-08-09 04:37:44.401][13][debug][http] source/common/http/conn_manager_impl.cc:405] [C6][S1]   'x-postman-interceptor-id':'f6cff37e-3755-4dbf-7983-989867ea20c5'\n","stream":"stderr","time":"2017-08-09T04:37:44.401785725Z"}
{"log":"[2017-08-09 04:37:44.401][13][debug][http] source/common/http/conn_manager_impl.cc:405] [C6][S1]   'user-agent':'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36'\n","stream":"stderr","time":"2017-08-09T04:37:44.401789606Z"}
{"log":"[2017-08-09 04:37:44.401][13][debug][http] source/common/http/conn_manager_impl.cc:405] [C6][S1]   'postman-token':'bc0229d5-dad1-9a43-4e77-7d6cff93c5d6'\n","stream":"stderr","time":"2017-08-09T04:37:44.401794693Z"}
{"log":"[2017-08-09 04:37:44.401][13][debug][http] source/common/http/conn_manager_impl.cc:405] [C6][S1]   'accept':'*/*'\n","stream":"stderr","time":"2017-08-09T04:37:44.401801581Z"}
{"log":"[2017-08-09 04:37:44.401][13][debug][http] source/common/http/conn_manager_impl.cc:405] [C6][S1]   'accept-encoding':'gzip, deflate, sdch, br'\n","stream":"stderr","time":"2017-08-09T04:37:44.401805545Z"}
{"log":"[2017-08-09 04:37:44.401][13][debug][http] source/common/http/conn_manager_impl.cc:405] [C6][S1]   'accept-language':'en-US,en;q=0.8,id;q=0.6,ms;q=0.4'\n","stream":"stderr","time":"2017-08-09T04:37:44.401809297Z"}
{"log":"[2017-08-09 04:37:44.401][13][debug][http] source/common/http/conn_manager_impl.cc:405] [C6][S1]   ':path':'/pertamina/v1/WeatherCall?query=Makassar\u0026language=ru'\n","stream":"stderr","time":"2017-08-09T04:37:44.401813088Z"}
{"log":"[2017-08-09 04:37:44.401][13][debug][http] source/common/http/conn_manager_impl.cc:405] [C6][S1]   ':method':'GET'\n","stream":"stderr","time":"2017-08-09T04:37:44.401817305Z"}
{"log":"[2017-08-09 04:37:44.401][13][trace][http] source/common/http/conn_manager_impl.cc:504] [C6][S1] decode headers called: filter=0x25dc080 status=0\n","stream":"stderr","time":"2017-08-09T04:37:44.40182087Z"}
{"log":"[2017-08-09 04:37:44.401][13][debug][router] source/common/router/router.cc:165] [C6][S1] no cluster match for URL '/pertamina.Pertamina/WeatherCall'\n","stream":"stderr","time":"2017-08-09T04:37:44.401824801Z"}
{"log":"[2017-08-09 04:37:44.401][13][trace][http] source/common/http/conn_manager_impl.cc:658] [C6][S1] encode headers called: filter=0x25dc0c0 status=0\n","stream":"stderr","time":"2017-08-09T04:37:44.401828502Z"}
{"log":"[2017-08-09 04:37:44.401][13][debug][http] source/common/http/conn_manager_impl.cc:713] [C6][S1] encoding headers via codec (end_stream=true):\n","stream":"stderr","time":"2017-08-09T04:37:44.401836037Z"}
{"log":"[2017-08-09 04:37:44.401][13][debug][http] source/common/http/conn_manager_impl.cc:718] [C6][S1]   ':status':'404'\n","stream":"stderr","time":"2017-08-09T04:37:44.401843061Z"}
{"log":"[2017-08-09 04:37:44.401][13][debug][http] source/common/http/conn_manager_impl.cc:718] [C6][S1]   'content-type':'application/json'\n","stream":"stderr","time":"2017-08-09T04:37:44.401848644Z"}
{"log":"[2017-08-09 04:37:44.401][13][debug][http] source/common/http/conn_manager_impl.cc:718] [C6][S1]   'date':'Wed, 09 Aug 2017 04:37:44 GMT'\n","stream":"stderr","time":"2017-08-09T04:37:44.401854761Z"}
{"log":"[2017-08-09 04:37:44.401][13][debug][http] source/common/http/conn_manager_impl.cc:718] [C6][S1]   'server':'envoy'\n","stream":"stderr","time":"2017-08-09T04:37:44.401860762Z"}

If you replace just RDS with the fixed route table, does it work? For RDS are you positive you are returning the route table shown above? @junr03 and @ccaraman are working on code now that will dump the loaded route tables via admin endpoint which will make this much easier to debug. That should be done by early next week.
It's hard to tell if this is a regression in the router matching code or some issue with RDS, or just the wrong data being loaded by RDS.

This is very likely https://github.com/lyft/envoy/issues/1434. Closing this for now. Please watch that issue for fix. We can reopen if the issue is not the same. Thanks for reporting.


A lot of abandoned libraries used in portphp/doctrine

Package operations: 1 install, 0 updates, 0 removals
  - Downloading portphp/doctrine (1.1.0)
  - Installing portphp/doctrine (1.1.0): Extracting archive
Package container-interop/container-interop is abandoned, you should avoid using it. Use psr/container instead.
Package doctrine/mongodb is abandoned, you should avoid using it. No replacement was suggested.
Package doctrine/reflection is abandoned, you should avoid using it. Use roave/better-reflection instead.
Package fzaninotto/faker is abandoned, you should avoid using it. No replacement was suggested.
Package phpunit/php-token-stream is abandoned, you should avoid using it. No replacement was suggested.
Package sensiolabs/security-checker is abandoned, you should avoid using it. Use https://github.com/fabpot/local-php-security-checker instead.
Package zendframework/zend-config is abandoned, you should avoid using it. Use laminas/laminas-config instead.
Package zendframework/zend-escaper is abandoned, you should avoid using it. Use laminas/laminas-escaper instead.
Package zendframework/zend-http is abandoned, you should avoid using it. Use laminas/laminas-http instead.
Package zendframework/zend-hydrator is abandoned, you should avoid using it. Use laminas/laminas-hydrator instead.
Package zendframework/zend-json is abandoned, you should avoid using it. Use laminas/laminas-json instead.
Package zendframework/zend-loader is abandoned, you should avoid using it. Use laminas/laminas-loader instead.
Package zendframework/zend-stdlib is abandoned, you should avoid using it. Use laminas/laminas-stdlib instead.
Package zendframework/zend-uri is abandoned, you should avoid using it. Use laminas/laminas-uri instead.
Package zendframework/zend-validator is abandoned, you should avoid using it. Use laminas/laminas-validator instead.

portphp/doctrine 1.2.0 now supports doctrine/common 3.0, which should fix these warnings (https://github.com/portphp/doctrine/pull/18).


Feature-35 - Notifications on import and upload

Add notifications when people change checklist or upload answers, that they will loose any in progress state. They should first download their ongoing work.

I have in progress a notification, but I think yours is nicer. I will include this notification only when there are changes in the document.


chore: Replace 'yarn' with 'npm'

This PR migrates PRC workflows and scripts from yarn to npm. Public-facing docs continue to give usage examples with both tools, since our customers use both.
Fixes https://github.com/github/primer/issues/179
Merge checklist

[ ] Added/updated tests
[x] Added/updated documentation
[ ] Tested in Chrome
[ ] Tested in Firefox
[ ] Tested in Safari
[ ] Tested in Edge

I’m very surprised that—although the Tooltip test file hasn’t changed in months—swapping to npm appears to have uncovered an accessibility-related issue that yarn elided (presumably by updating an axe-related dependency in the tree):
 FAIL  src/__tests__/Tooltip.tsx (5.329 s)
  ● Tooltip › should have no axe violations

    expect(received).toHaveNoViolations(expected)

    Expected the HTML found at $('span') to have no violations:

    Received:

    "Elements must only use allowed ARIA attributes (aria-allowed-attr)"

    Fix all of the following:
      ARIA attribute cannot be used, add a role attribute or use a different element: aria-label

    You can find more information on this issue here:
    https://dequeuniversity.com/rules/axe/4.2/aria-allowed-attr?application=axeAPI

      18 |     const {container} = HTMLRender(<Tooltip text="hi" />)
      19 |     const results = await axe(container)
    > 20 |     expect(results).toHaveNoViolations()
         |                     ^
      21 |     cleanup()
      22 |   })
      23 |

      at Object.<anonymous> (src/__tests__/Tooltip.tsx:20:21)

From @smockle in https://github.com/primer/components/pull/1250#issue-652653038:

[x]  Tested in Safari

For verification, I opened every PRC component page on https://primer-components-1dot5xcvk-primer.vercel.app/ (the latest Vercel deployment) and interacted with interactive elements demoed therein.


Add SBT support via "sbt makePom"

Please have a look at the individual commit messages for the details.

This change is

Reviewed 1 of 1 files at r1, 1 of 1 files at r2, 4 of 4 files at r3, 7 of 7 files at r4, 1 of 1 files at r5.
Review status: all files reviewed at latest revision, 5 unresolved discussions.

appveyor.yml, line 17 at r4 (raw file):

  - npm install -g<EMAIL_ADDRESS><EMAIL_ADDRESS>  - pip install virtualenv==15.1.0
  - choco install sbt --version 1.0.2

Appveyor uses chocolatey, interesting.

analyzer/src/funTest/kotlin/SbtTest.kt, line 52 at r4 (raw file):

            val expectedResult = expectedOutputFile.readText()

            actualResult shouldBe expectedResult

Not a must have for me, but I like the readability of the AAA pattern in unit tests as we have it in at least most other tests.

analyzer/src/main/kotlin/managers/SBT.kt, line 100 at r4 (raw file):

    }

    override fun resolveDependencies(projectDir: File, definitionFiles: List<File>) =

Instead of opening this function, couldn't you instead forward to Maven in the other resolveDependencies function?

util/src/main/kotlin/ProcessCapture.kt, line 116 at r1 (raw file):

    val actualVersion = getCommandVersion(command, versionArgument, version.type, transform)
    if (!criterion(actualVersion, version)) {
        val message = "Unsupported $command version $actualVersion."

This doesn't tell me anymore what version is required. If I saw it correctly we currently only need it for the SBT check the check actualVersion >= expectedVersion. Maybe we could use semver version ranges for that together with satisfies(...):
https://github.com/vdurmont/semver4j#requirements
And then print the version expression in the error message.

util/src/main/kotlin/ProcessCapture.kt, line 134 at r2 (raw file):

        workingDir: File? = null,
        transform: (String) -> String = { it },
        semverType: Semver.SemverType = Semver.SemverType.LOOSE

Why switch the order of transfrom and semverType? If the function type is the last argument you can also use the nice syntax like getCommandVersion(...) {}.

Comments from Reviewable

Review status: all files reviewed at latest revision, 4 unresolved discussions.

analyzer/src/funTest/kotlin/SbtTest.kt, line 52 at r4 (raw file):
Previously, mnonnenmacher (Martin Nonnenmacher) wrote…
Not a must have for me, but I like the readability of the AAA pattern in unit tests as we have it in at least most other tests.

I've added comments why this doesn't work so well in this case.

util/src/main/kotlin/ProcessCapture.kt, line 134 at r2 (raw file):
Previously, mnonnenmacher (Martin Nonnenmacher) wrote…
Why switch the order of transfrom and semverType? If the function type is the last argument you can also use the nice syntax like getCommandVersion(...) {}.

Good point. I wanted to have variables roughly in the order they are used, but I'll revert that bit.

Comments from Reviewable

Review status: all files reviewed at latest revision, 4 unresolved discussions.

util/src/main/kotlin/ProcessCapture.kt, line 116 at r1 (raw file):
Previously, mnonnenmacher (Martin Nonnenmacher) wrote…
This doesn't tell me anymore what version is required. If I saw it correctly we currently only need it for the SBT check the check actualVersion >= expectedVersion. Maybe we could use semver version ranges for that together with satisfies(...):
https://github.com/vdurmont/semver4j#requirements
And then print the version expression in the error message.

Done.

Comments from Reviewable

Review status: all files reviewed at latest revision, 4 unresolved discussions.

analyzer/src/main/kotlin/managers/SBT.kt, line 100 at r4 (raw file):
Previously, mnonnenmacher (Martin Nonnenmacher) wrote…
Instead of opening this function, couldn't you instead forward to Maven in the other resolveDependencies function?

There would be basically two problems: 1) I already have multiple POM files but the other resolveDependencies() function takes only a single definitionFile, and 2) Maven's prepareResolution() would not get called.

Comments from Reviewable

Reviewed 1 of 11 files at r6, 1 of 1 files at r7, 3 of 4 files at r8, 8 of 8 files at r9.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Reviewed 1 of 1 files at r11, 3 of 4 files at r12, 8 of 8 files at r13.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Handle symlinks in loaders.

Problem: See #518
Solution: homogenize the reload-functions, store normalized paths (eg. without symlinks) and pass normalized filenames when reloading (which now needs just one autocommand, yay)
@leiserfg Could you take a look at this PR?
Any ideas what to use as the default now?
(Didn't spot this locally since I always run tests from within nvim, where the variable is ofc. set)

Crap, that's a breaking change, let's complain to @clason, if they can't give us luajit they can't take scriptnames from us without notification :smile:

I think the issue is not -u NONE as it 's always empty in that case, the problem is that when using  -u something.lua  the first script is not the user config anymore, isn't?

You can do nvim --clean -u myinit.lua (order matters).

I never understood why using -u does not set $MYSCRIPT.  if scriptnames does not work, we can only use vim.v.vargs and extract the value of -u from it.

I'll make a PR to implement it.

Concerning the failing test, it looks like scriptnames in nvim -u NONE now prints nothing.
Any ideas what to use as the default now?

nvim --clean (since a long time already -- NONE really means "none", not even builtin scripts!)

Weird that it only occurred just now, maybe there's more to it than just "scriptnames is empty".
I'll take another look at what went wrong later.

I'll make a PR to implement it.

👍👍

https://github.com/L3MON4D3/LuaSnip/pull/528


Exception in thread TCPConnectionHandler

Problem Description
lot of exceptions when running mitmproxy
Traceback (most recent call last):
  File "/usr/local/python36/lib/python3.6/threading.py", line 916, in _bootstrap_inner
    self.run()
  File "/usr/local/python36/lib/python3.6/threading.py", line 864, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/python36/lib/python3.6/site-packages/mitmproxy/net/tcp.py", line 602, in connection_thread
    self.handle_client_connection(connection, client_address)
  File "/usr/local/python36/lib/python3.6/site-packages/mitmproxy/proxy/server.py", line 66, in handle_client_connection
    self.channel
  File "/usr/local/python36/lib/python3.6/site-packages/mitmproxy/proxy/server.py", line 78, in __init__
    None)
  File "/usr/local/python36/lib/python3.6/site-packages/mitmproxy/connections.py", line 38, in __init__
    super().__init__(client_connection, address, server)
  File "/usr/local/python36/lib/python3.6/site-packages/mitmproxy/net/tcp.py", line 489, in __init__
    super().__init__(connection)
  File "/usr/local/python36/lib/python3.6/site-packages/mitmproxy/net/tcp.py", line 297, in __init__
    self.ip_address = connection.getpeername()
OSError: [Errno 107] Transport endpoint is not connected

System Information
Mitmproxy: 5.2 binary
Python:    3.7.8
OpenSSL:   OpenSSL 1.1.1g  21 Apr 2020
Platform:  Linux-4.9.0-0.bpo.6-amd64-x86_64-with-debian-8.11

Thanks, how can we reproduce this issue?

I am not very sure. May be raw tcp connection, one SYN packet and one RST+ACK packet follows.
Our mitmproxy is behind a load balance server, which will send tcp packets to check if real ip and port are alive continuously.

We just merged a brand new protocol implementation - if you can repeat the problem with the latest version from git-master, please re-open this issue.


[Python] Change .venv script to be more compatible with IDEs

Summary
Moves .venv to the Devbox Project Root, and adds some checks to ensure we warn the user if we are going to squash a user created venv. Moving .venv to the project root makes it more likely that Python Extensions and IDEs will pick up the devbox managed python, instead of a system python
Fixes DEV-105
How was it tested?

Question: Do we care about preserving a user's pre-existing .venv if they created it with a different tool? Or should we just always squash it.
Preserve it.


GUAC-1388 Allow LDAP role-based access control for guacConfigGroups

Saw the branch was out of date and rebased. Please let us know if you have any questions. Thanks!

Rebased again to keep the branch in sync with master. @mike-jumper, anything more you need on this PR?

@lorengordon - thanks. I don't have any input at present, but have not had the time to look over this with any depth recently. We are putting this in our next sprint, however, so review and comments from our side will commence very shortly.

Gotcha, thanks @mike-jumper. I admit to hoping this would make it into 0.9.9, but nbd. We'll just keep using a customized version of the plugin internally for now. Easy enough. Fyi, we've been using this idea with 0.9.7 for the last month or so and it's been solid (and super convenient for enabling role-based access to guac connections). Definitely let us know if you see any issues!

@lorengordon - results of first code review are above.
Looking at our records, we have a CLA on file for @richarpw, but not for yourself. The CLA covers a particular individual's contributions, so if you are both working for the same company (as looks to be the case), you would need to either (1) sign a CLA to cover your own contributions going forward (which would include whatever you have contributed on top of what @richarpw has already done) or (2) have someone with sufficient authority at your company sign a CLA to cover contributions on behalf of that company.
The CLA is here: http://glyptodon.org/cla.html

@mike-jumper, thanks for the review. I'm just tracking the issue because I deployed our implementation of Guacamole and needed this feature in the plugin. My only involvement on the code has been rebasing to keep the branch up-to-date. I'll defer to @richarpw for any of the code. Do you need a CLA from me even if I'm not actually contributing code?

@lorengordon - ah, OK. No, if you're not contributing any code, then no CLA is necessary, but then please either do not rebase or let @richarpw do the rebase. Otherwise, the source history will not jive with our own contributor records.
Currently, the git history shows both yourself and @richarpw as the contributors of the change, which could prove legally confusing.

@mike-jumper, take a look at the updated code when you get a chance and let me know if you need any other changes

Thanks, @richarpw. This looks excellent. I have some minor additional changes that I think should be made, but they're not worth additional back-and-forth. I will get these changes moved forward via #323.


Chap. <IP_ADDRESS> Eq. 5.145 line

Missing a log function around the partition function

fixed, thanks


Resurrect wasm unit test with new “OOB” wasm unit tests

We have a unit test that is #if 0ed (and some additional unit tests incoming) that attempt to access out of bounds memory. WAVM handles this cleanly by trapping the SEGV and then we retire the transaction as a failure.
However in chain_test the Boost Test framework by default tries to grab SEGV for itself. So depending on the tests that execute WAVM will be unable to trap the SEGV and instead it will be bubbled up to Boost Test as a test failure.
I tried a few approaches to resolve this cleanly but long story short nothing great came about. I need to set --catch_system_errors=no for operation in WAVM but I could not figure out an appropriate way of easily doing this at runtime via code. So.. adding it to ctest command.
But, I can’t have those troublesome tests run when someone just simply runs ‘chain_test’. Originally I tried to dynamically add/remove the oob tests based on if --catch_system_errors=no was set and/or we were running WAVM or not. But unfortunately disabled at runtime tests are considered “skipped” by Boost Test which actually results in a failure return code.
So instead require these OOB tests to be opted in to manually… Added in the ctest file.
Fixes #1823

This PR is in limbo because it appears WAVM on Linux is not cleanly catching the SEGV.

Superseded by #2420


Difficult to understand why "no fused attention kernel is available"

With the JAX API, I am getting this warning:
/usr/local/lib/python3.10/dist-packages/transformer_engine/jax/flax/transformer.py:477: UserWarning: Fused attention is not enabled. Because no fused attention kernel is available, fall back to unfused attention.
Which leads me to this code, which in turn leads me to this function with very complex boolean expressions.
Is there a recommended way to see what exactly is causing this function to return NVTE_Fused_Attn_Backend::NVTE_No_Backend?
A more informative warning for this case would be great.

@zlsh80826 @cyanguwa @denera FYI


V2515: Broken link

Hello @TerryGLee,
there is a broken link in the page in this string:
For a related video demonstration, see How do I: Automate PowerPoint from an Excel Add-in?.
Please review and merge the proposed file change to fix to target versions. If you make related fix in another PR  then share your PR number so we can confirm and close this PR.
Many thanks in advance.

@v-makoud : Thanks for your contribution! The author, @TerryGLee, has been notified to review your proposed change.

Hi @v-makoud - The changes in the PR should have been made via the private repository, azure-docs-pr. The private repo has better validation and QA, so Microsoft contributors are expected to use that channel. Please submit future updates through the private repo.
Read about authors working in the public repo for more information.
Thanks.

@v-makoud Thanks for your suggestion. As @ktoliver suggested, a request such as this from an internal-to-Microsoft person should be made through our private repo, visualstudio-docs-pr. We will close this public PR shortly.
@John-Hart - FYI.

#hold-off

new PR in pr: 3352


[Documentation comment] Looks like an interrupted sentence.

Here:
https://github.com/ytsaurus/ytsaurus/blob/1f519b59189e2d931f82ec6ae560be139b318c71/yt/cpp/mapreduce/interface/common.h#L714

Fixed in 0d05d39e74a82c70078055ceda0cb26a6182538f


Errors when trying to install p5.serialserver

I have tried everything I can think of to try and download p5.serialserver on a mac. I used all three methods suggested in the documentation. It keeps giving me errors that 3 arguments are required, but 2 were provided like below:
npm ERR! /path/path/path/node-gyp/17.4.0/include/node/v8-object.h:247:37: note: candidate function not viable: requires 3 arguments, but 2 were provided
npm ERR!   V8_WARN_UNUSED_RESULT Maybe Set(Local context, uint32_t index,
Then the following:
npm ERR!                                     ^
npm ERR! 4 errors generated.
npm ERR! make: *** [Release/obj.target/bindings/src/serialport.o] Error 1
npm ERR! gyp ERR! build error
npm ERR! gyp ERR! stack Error: make failed with exit code: 2
npm ERR! gyp ERR! stack     at ChildProcess.onExit (/path/path/path/.nvm/versions/node/v17.4.0/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:194:23)
npm ERR! gyp ERR! stack     at ChildProcess.emit (node:events:520:28)
npm ERR! gyp ERR! stack     at Process.ChildProcess._handle.onexit (node:internal/child_process:291:12)
npm ERR! gyp ERR! System Darwin 21.1.0
npm ERR! gyp ERR! command "/path/path/path/.nvm/versions/node/v17.4.0/bin/node" "/path/path/path/.nvm/versions/node/v17.4.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
npm ERR! gyp ERR! cwd /path/path/path/.nvm/versions/node/v17.4.0/lib/node_modules/p5.serialserver/node_modules/@serialport/bindings
npm ERR! gyp ERR! node -v v17.4.0
npm ERR! gyp ERR! node-gyp -v v8.4.1
npm ERR! gyp ERR! not ok
I assume this is because there are updated required and some of the packages required have changed, but I'm not sure which packages or how to resolve this. Any ideas would be helpful.

Same here

@montoyamoraga do you have thoughts?


Import liff object from default export of '@line/liff'

This change maybe resolves #333.

This patch must be apply after supporting @line/liff 2.14 or later.


-k doenst work.

Tested with 2003 and 2008R2.
freerdp doenst react to -k.
Tested with -k 0x0407 (german) / -k 0x0409 (US).
The Terminalserver has always US-Keyboard

@nerdstube: I just tried it, it actually works. What might be confusing though is that the server only accepts the keyboard settings for a new session and not an existing one. I am unware of a way to force the server to change the keyboard layout of an existing session, which I agree would be better behavior. Log out from your session, then use -k, and it should work.

Hey hey awakecoding,
ive tried it with new sessions.
After every test i´ve logout with the current user and reconnect complete.
But i think i try it tomorrow with a new installation of windows 2008r2 and a clean linux+xfreerdp.
Perhaps there confused Tempfiles?!

@nerdstube: this is weird, because the server should accept those settings on a new session. There are no temporary files involved for this. Maybe the server ignores client-side settings? Do you have any special configuration server-side? Just making sure, you are using the latest version of FreeRDP compiled from source, right?

Afaik there are no spezial configuration on server-side. But i dont know 100%. Thats the reason why i setup a new Win2k8r2
Yes ive build them today from git.

K .. a new Session on a new Server and all works great!


The depth iteration from the mouse wheel is not reseted when aborted

Changed the behavior. Now the depth is stored together with movement in the plane. So you can use them both together now.


Relative paths do not resolve ("~/" or "$HOME")

When opening a file using :e it appears that relative paths do not resolve at all, and will open a new blank file rather than the intended target.
:e ~/Projects/example/example.conf
:e $HOME/Projects/example/example.conf
Assuming that the file in this example existed, it would instead open an empty file with the same path being displayed. If I open pyvim in my user directory ($HOME) then I can traverse the paths normally, which is the workaround I've been using for the moment.
I suppose it's not too much trouble to type /home/user/ but it would be nice if relative paths would also work.

You can use os.path.abspath(os.path.expanduser(filename)) for evaluating the ~ (it will work for ~username as well as plain ~). Intelligently parsing out env vars before/after expanding ~ is going to be tougher to decide on but it's a start.

Thanks for reporting!
This commit should fix it: https://github.com/jonathanslenders/pyvim/commit/fb0f6956e6b8f8620c2fd3b31bef9697d59fd21c

Installed fresh from master, confirmed working with PyPy 5.0.1. Thanks!

@jonathanslenders That was quick! Looks like that has solved the issue of using ~/ when using long paths, great suggestion @therealfakemoot!

Closing for now


Increase weights for serial (en TN)

What does this PR do ?
Increase weights for serial (en TN)
PR Type:

[x] Bugfix - Resolves https://github.com/NVIDIA/NeMo-text-processing/issues/126

This test doesn't work correctly for me with the original weights. Not sure how it passed the tests.

From: Evelina @.>
Sent: Wednesday, November 22, 2023 2:01:50 AM
To: NVIDIA/NeMo-text-processing @.>
Cc: Anand Joseph @.>; Author @.>
Subject: Re: [NVIDIA/NeMo-text-processing] Increase weights for serial (en TN) (PR #128)
@ekmb requested changes on this pull request.

In tests/nemo_text_processing/en/data_text_normalization/test_cases_money.txthttps://github.com/NVIDIA/NeMo-text-processing/pull/128#discussion_r1401135535:

@@ -63,3 +63,4 @@ $1,925.21~one thousand nine hundred and twenty five dollars twenty one cents
$1,234.123~one thousand two hundred and thirty four point one two three dollars
US $76.3 trillion~US seventy six point three trillion dollars
US$76.3 trillion~seventy six point three trillion us dollars
+The price for each canned salmon is $5, each bottle of peanut butter is $3~The price for each canned salmon is five dollars, each bottle of peanut butter is three dollars

seems like the added test case was working w/o weight update. Could you please replace with the input from this issuehttps://github.com/NVIDIA/NeMo-text-processing/issues/126Thank you for the quantities. Now, lets talk about the pricing. The price for each canned salmon is $5, each bottle of peanut butter is $3
—
Reply to this email directly, view it on GitHubhttps://github.com/NVIDIA/NeMo-text-processing/pull/128#pullrequestreview-1743023126, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZICZSILKH6BOTWR65Y5SMLYFUFTNAVCNFSM6AAAAAA7QGHHRWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTONBTGAZDGMJSGY.
You are receiving this because you authored the thread.Message ID: @.***>