gRPC Python GA API (Draft)

Lots of minutia to discuss here, but of course the most important question for this is whether or not it has all the growth surfaces that are needed and whether or not future changes are going to be as disruptive as past feature growth was to the alpha and beta APIs.
(Security (mostly) not part of this code review.)
Changes from Beta:

Channel construction now takes a single string rather than separate host and port.
RPC timeout now optional.
Server-side timeout removed - if applications don't trust the RPC caller and want to time out according to their own schedule, they'll have to set their own alarm clock.

Questions:

What about Future? The problems with concurrent.futures.Future that motivated grpc.framework.foundation.future.Future haven't been solved. "Maximizing compatibility" with concurrent.futures.Future would mean compounding its design flaw and violating the public API of concurrent.futures - please no? Is it a problem putting our Future interface where it is currently drafted in this API? Should Future appear as a code element of grpc, or should only code elements that we expect to be used in application code be code elements of grpc?
The MultiCallable interfaces are how we support asynchronous invocation on the same code element as synchronous invocation, but with the current semantics they're only needed for response-unary RPCs. Should we keep all four anyway with future growth in mind? If we want to support async/await, they'd be the right place, right?
Should the Channel have the RPC invocation convenience methods depicted here or is it just enough to have the MultiCallable methods? How much do we expect users to make direct use of Channels? How hard (and/or weird) are we making their lives if we make them write my_response = my_channel.unary_unary(my_method_name)(my_request) instead of my_response = my_channel.blocking_unary_unary(my_method_name, my_request)?
How should this API's documentation refer to connectivity and status code integers? Do we just say "go look at connectivity_state.h and status.h to see what the integer returned to you means"?
Is it too clever making the raised RpcError also a Call object? Should the RpcError have a Call object instead?
Should the required Channel construction parameter be named "target" or "address" or... something else? What exact wording would we like describing it?
What about "channel args"? How do we document them? At least one of them is only appropriate for use in tests - are we worried about it being passed via the non-test API?
Servicing RPCs requires a thread pool (right?). Should the server's thread pool be required of the application, optional, or entirely obscured? Should the application be allowed to pass thread pool size?
How do we want to support generic service of arbitrary RPCs? (This was present in beta; the question isn't coming out of nowhere.) By accepting a function that looks like a stream-stream handler, but that takes the method name as well and operates on bytes in and bytes out?
Where in the API do we want to allow applications to pass native strings as opposed to byte strings? (If we want to support my_response = my_stub.my_method(my_request) at the read-eval-print loop, we're going to have to support native strings in at least one place.)
Can we do away with the metadata_transformer present in alpha and beta and make security entirely done with the plug-in API? (I suspect yes?)
The host is a stub option in the beta API; should it remain a stub option or become a channel option or per-call option?
Where in the documentation do we want to say "metadata" and where do we want to say "headers"? What three terms do we want to say where the beta API said "invocation metadata", "initial metadata", and "terminal metadata"?
In the beta API there is a CallOptions class that can be passed on RPC invocation and that encapsulates disable_compression, subcall_of, and per-call credentials. Do we want to do away with this aggregate object and just have those values as keyword arguments on each RPC invocation (as is drafted here)? If so, is there any need to worry about every future feature being added as yet another keyword argument and eventually having an unmanageable number?
Are "normal termination of the RPC" and "abnormal termination of the RPC" the right terms to use?

@soltanmm and @jtattermusch please also look? Thanks much.

status code and connectivity magic numbers
I'm strongly opposed to flattening our magic numbers. We have two separate documented and enforced-by-convention discriminants that are conceptually distinct. They should remain in separate enumerations (although, they perhaps should acquire their values from the Cython layer as those values will always be in sync with the core).
flattening the package structure
I feel like this swings the pendulum a bit too far in the opposite direction in terms of package hierarchy. Yes, before we had to go 5+ package/modules deep to find interface definitions that the user would regularly interact with, and yes that was a problem. However, I think there's a happy balance between an entirely flat hierarchy and what we had before.
The Python community appears to tend towards organizing packages first by concept or idea and then by implementation detail. I wouldn't be against having something like a module for user-facing invocation-side things, and a module for user-facing service-side things, and a module for common things, for example. Without bikeshedding too much quite, I'd like something akin to:
     top-level
        / \
      concepts
      /     \
specialized concepts
    /         \
implementation details
  /             \

where concepts would include the separation of stubs from services from transports and handshakes (all the most basic elements required to get something up and running), specialized concepts would include codes and security plugins...
tl;dr: If someone were to take our package hierarchy and draw any arbitrary path from root to (public) leaf, I'd want that path to describe a useful tutorial for the project.

Some answers/opinions (I haven't yet read code):

'target' is sort-of standardized across stacks for the channel construction string: it's not necessarily a single address
at least C++ channel args are wrapped a little bit: common things get a first class interface, uncommon things get to be set via a side channel interface by searching for the string name. That allows us to bubble up documentation to a place that C++ authors will find it.
I'd like to see names for status codes exposed in Python.
Suspect RpcError should have-a Call
There's room for some debate in servicing RPCs, but I suspect some flavor of thread pool is appropriate here.
Generic API's: they're definitely needed in C++ land, and they're a useful stand-in for someone getting a first version of a non-proto based stack up - that said, I could be convinced to pass on it for the Python API this round (and add it back when it's important for someone)
Suspect yes on metadata_transformer
I want to make host a stub option for C++; setting a default for a channel makes sense (and is expressible to core), allowing per-call override isn't crazy but also probably isn't required if there's a stub option
Suspect we want to refer to metadata and not headers in all non-wire format documentation

Lots more here to discuss and review now.
Highlights:

Blocking unary-unary invocation is single-threaded and single-batch which should address all the glaring, obvious performance improvements for the use case and further gains would have to be measurement-based.
Asynchronous invocation uses a single shared-channel-wide completion queue so N asynchronously-invoked RPCs spawn one thread rather than N (or N times a constant) threads.
A started server runs one thread. Servicing RPCs consumes one thread per active RPC, taken from a thread pool supplied by the application.
I think the tests cover a lot.

Details is neither used nor verified.
Custom status codes are neither used nor verified.
Metadata is used but not yet verified.
I could stand to write some stream-length-zero tests in addition to the stream-length-many tests
But other than that...

Questions:

Do we (gRPC Python) have to make a call to Core for every call that the application invokes on us? In the current draft if the application invokes a request-unary RPC and passes a request object that fails to serialize we fake having called (and we conform to status code semantics for the case) without ever touching Core. Is this legitimate?
The current draft of the server is one-completion-queue-per-server-plus-one-completion-queue-per-active-RPC. I had wanted to go full-on one-completion-queue-per-server, but after the discussion in issue 6597 I now believe it's impossible to write a multithreaded server with a single completion queue (I have an analysis written up elsewhere if it's not obvious why). Am I wrong? If I'm not wrong, am I the only one who cares? If I'm the only one who cares I'll just get over myself.
Is there too much code here (@jtattermusch rightly brought this question up with me about the beta implementation a while back)? The __init__.py file can be as long as it needs to be because it's mostly documentation, but are seven hundred lines for _channel.py and six hundred lines for _server.py in line with the weight of the features being added? Are there obvious opportunities for reduction that I've overlooked?
GenericHandler and ParticularHandler are terrible names, but for the moment they get the point across, and we don't have anything more proper listed in either glossary. RpcHandler and MethodHandler, maybe?
In the server code I saw some memory leaks clear up when I moved the polling on the per-RPC completion queue inside the per-RPC lock. Why was that? Shouldn't any thread be able to poll on any completion queue? (I'm also open to being wrong about what I saw.)
Four of my test methods still leak memory, according to what the Core prints at the end of the test run - the ones that use asynchronous invocation (and thus on the client side a completion queue on a different thread) and complete with non-OK status. What could be going on there?
My apologies that at the moment the implementation comments are sparse and the specification comments are absent, but what's unexpected in the code? Where have I gotten "creative" in ways that are dangerous or defective?

Completely legit not to invoke core on serialization failure. You may want
some monitoring hooks eventually.
It's not obvious to me that one can't write a multi threaded server with
one completion queue. I've certainly done so. Suspect a flawed analysis...
let's chat to find the flaw. Likely documentation needs fixing.
Need specifics for memory leaks.
Hope to dig into the code later today.
On Mon, May 16, 2016, 6:09 AM Nathaniel Manista<EMAIL_ADDRESS>wrote:

Lots more here to discuss and review now.
Highlights:

Blocking unary-unary invocation is single-threaded and single-batch
which should address all the glaring, obvious performance improvements for
the use case and further gains would have to be measurement-based.
Asynchronous invocation uses a single shared-channel-wide completion
queue so N asynchronously-invoked RPCs spawn one thread rather than N (or N
times a constant) threads.
A started server runs one thread. Servicing RPCs consumes one thread
per active RPC, taken from a thread pool supplied by the application.
I think the tests cover a lot.

Details is neither used nor verified.
Custom status codes are neither used nor verified.
Metadata is used but not yet verified.
I could stand to write some stream-length-zero tests in addition
to the stream-length-many tests
But other than that...

Questions:

Do we (gRPC Python) have to make a call to Core for every call
that the application invokes on us? In the current draft if the application
invokes a request-unary RPC and passes a request object that fails to
serialize we fake having called (and we conform to status code
semantics for the case
https://github.com/grpc/grpc/blob/master/doc/statuscodes.md) without
ever touching Core. Is this legitimate?
The current draft of the server is
one-completion-queue-per-server-plus-one-completion-queue-per-active-RPC. I
had wanted to go full-on one-completion-queue-per-server, but after the
discussion in issue 6597 https://github.com/grpc/grpc/issues/6597 I
now believe it's impossible to write a multithreaded server with a single
completion queue (I have an analysis written up elsewhere if it's not
obvious why). Am I wrong? If I'm not wrong, am I the only one who cares? If
I'm the only one who cares I'll just get over myself.
Is there too much code here (@jtattermusch
https://github.com/jtattermusch rightly brought this question up
with me about the beta implementation a while back)? The init.py
file can be as long as it needs to be because it's mostly documentation,
but are seven hundred lines for _channel.py and six hundred lines for
_server.py in line with the weight of the features being added? Are
there obvious opportunities for reduction that I've overlooked?
GenericHandler and ParticularHandler are terrible names, but for the
moment they get the point across, and we don't have anything more proper
listed in either glossary. RpcHandler and MethodHandler, maybe?
In the server code I saw some memory leaks clear up when I moved the
polling on the per-RPC completion queue inside the per-RPC lock. Why was
that? Shouldn't any thread be able to poll on any completion queue? (I'm
also open to being wrong about what I saw.)
Four of my test methods still leak memory, according to what the
Core prints at the end of the test run - the ones that use asynchronous
invocation (and thus on the client side a completion queue on a different
thread) and complete with non-OK status. What could be going on there?
My apologies that at the moment the implementation comments are
sparse and the specification comments are absent, but what's unexpected in
the code? Where have I gotten "creative" in ways that are dangerous or
defective?

—
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub
https://github.com/grpc/grpc/pull/6327#issuecomment-219420661

Whoops, I left out the "without the server maintaining bookkeeping on what RPCs are active and what tags are due". The Python beta server is another example of a single-completion-queue multithreaded server so my having forgotten the qualification is even more glaring. Here's what I wrote the other day for issue 6597 (but wound up not posting because in the course of trying to prove "I think the workaround is to carry forward the bookkeeping present in the beta server" I went in the plus-completion-queue-per-active-RPC direction instead):
Let's ask a precise question: must a core-wrapping server implemented as one thread looping over a completion queue and application code run in separate threads maintain its own records of what RPCs are in progress and what events are "due" from the completion queue?
I would like the answer to be "no", but the following scenario suggests to me that it might be "yes".

Control Thread
Server Loop Thread
Application Thread

start server: request call and spawn server loop thread
(spawned here)
(not running)

call event: spawn application thread to handle call, request receive-close-on-server event for call, and request next call
(spawned here)

shut down server

cancel all calls

no-call call event

server shutdown event: break from loop and exit thread

(not running)
attempt to read message: request receive-message event and then wait on condition

This leaves the application thread hung waiting for notification on its condition that will never come. Changing the semantics of the server's loop to "call completion queue shutdown when handling the server shutdown tag" just defers the problem:

Control Thread
Server Loop Thread
Application Thread

start server: request call and spawn server loop thread
(spawned here)
(not running)

call event: spawn application thread to handle call, request receive-close-on-server event for call, and request next call
(spawned here)

shut down server

cancel all calls

no-call call event

server shutdown event: call completion queue shutdown but keep looping to drain completion queue

attempt to read message: request receive-message event and then crash with !cc->shutdown_called

So if the right time to call completion queue shutdown isn't when processing the server shutdown event, when is it? I don't think I can tell without full bookkeeping.
So what seems to me right now to be the case is that I can't rely solely on events coming out of the completion queue to determine whether or not it is safe for the application to take actions like request a read or request sending status because the event alerting the application to cancellation of the RPC is sitting in "completion queue limbo" having been made available to the server loop thread but not yet obtained by the server loop thread.
So I think the workaround is to carry forward the bookkeeping present in the beta server: each RPC keeps track of what events are due for it, and the server maintains a record of all active RPCs and in the course of handling an event related to an RPC "asks" the RPC if the event concludes the RPC and removes the RPC from its records if the event does conclude the RPC, and the server also maintains a record of which of new-RPC and server-shutdown events are due from the queue as well, and the server exits its loop after all of its shutdown, it completion of all RPCs, and its having secured its last new-RPC event and its shutdown event.
@ctiller: what am I missing, and where have I erred?

As for the memory leaks:
(1) Taking the current draft and removing the @unittest.skip('memory leak!') the test "succeeds" (so far as Python is concerned) but includes
OK
E0516 09:23:23.504743511  777844 tcp_client_posix.c:191]     failed to connect to 'ipv4:<IP_ADDRESS>:36297': timeout occurred
E0516 09:23:23.504785540  777844 tcp_client_posix.c:191]     failed to connect to 'ipv6:[::1]:36297': timeout occurred
D0516 09:23:24.505524749  777844 iomgr.c:99]                 Waiting for 4 iomgr objects to be destroyed
D0516 09:23:25.506244438  777844 iomgr.c:99]                 Waiting for 4 iomgr objects to be destroyed
D0516 09:23:26.506978213  777844 iomgr.c:99]                 Waiting for 4 iomgr objects to be destroyed
D0516 09:23:27.507732080  777844 iomgr.c:99]                 Waiting for 4 iomgr objects to be destroyed
D0516 09:23:28.508496078  777844 iomgr.c:99]                 Waiting for 4 iomgr objects to be destroyed
D0516 09:23:29.509252437  777844 iomgr.c:99]                 Waiting for 4 iomgr objects to be destroyed
D0516 09:23:30.509989604  777844 iomgr.c:99]                 Waiting for 4 iomgr objects to be destroyed
D0516 09:23:31.511965050  777844 iomgr.c:99]                 Waiting for 4 iomgr objects to be destroyed
D0516 09:23:32.512671909  777844 iomgr.c:99]                 Waiting for 4 iomgr objects to be destroyed
D0516 09:23:33.513403748  777844 iomgr.c:117]                Failed to free 4 iomgr objects before shutdown deadline: memory leaks are likely
D0516 09:23:33.513431448  777844 iomgr.c:80]                 LEAKED OBJECT: tcp-client:ipv6:[::1]:42765 fd=42 0x7fa13c00e000
D0516 09:23:33.513445883  777844 iomgr.c:80]                 LEAKED OBJECT: tcp-client:ipv6:[::1]:41981 fd=58 0x7fa130005cb0
D0516 09:23:33.513451683  777844 iomgr.c:80]                 LEAKED OBJECT: tcp-client:ipv6:[::1]:40179 fd=74 0x7fa13c0143d0
D0516 09:23:33.513458426  777844 iomgr.c:80]                 LEAKED OBJECT: tcp-client:ipv6:[::1]:46817 fd=90 0x7fa1400215b0
D0516 09:23:33.513543067  777844 metadata.c:235]             WARNING: 1 metadata elements were leaked
D0516 09:23:33.513558144  777844 metadata.c:235]             WARNING: 1 metadata elements were leaked
D0516 09:23:33.513591742  777844 metadata.c:235]             WARNING: 2 metadata elements were leaked
D0516 09:23:33.513600102  777844 metadata.c:235]             WARNING: 1 metadata elements were leaked
D0516 09:23:33.513609920  777844 metadata.c:235]             WARNING: 1 metadata elements were leaked
D0516 09:23:33.513623083  777844 metadata.c:235]             WARNING: 1 metadata elements were leaked
D0516 09:23:33.513631414  777844 metadata.c:235]             WARNING: 1 metadata elements were leaked
D0516 09:23:33.513641220  777844 metadata.c:235]             WARNING: 1 metadata elements were leaked
D0516 09:23:33.513652460  777844 metadata.c:235]             WARNING: 1 metadata elements were leaked
D0516 09:23:33.513661631  777844 metadata.c:235]             WARNING: 1 metadata elements were leaked
D0516 09:23:33.513673933  777844 metadata.c:235]             WARNING: 2 metadata elements were leaked
D0516 09:23:33.513680678  777844 metadata.c:248]             WARNING: 2 metadata strings were leaked
D0516 09:23:33.513685200  777844 metadata.c:252]             LEAKED: FailedStreamRequestFutureUnaryResponse
D0516 09:23:33.513689173  777844 metadata.c:252]             LEAKED: /test/UnaryUnary
D0516 09:23:33.513694222  777844 metadata.c:248]             WARNING: 2 metadata strings were leaked
D0516 09:23:33.513698283  777844 metadata.c:252]             LEAKED: Deadline Exceeded
D0516 09:23:33.513702299  777844 metadata.c:252]             LEAKED: localhost:40179
D0516 09:23:33.513706328  777844 metadata.c:248]             WARNING: 1 metadata strings were leaked
D0516 09:23:33.513710253  777844 metadata.c:252]             LEAKED: FailedUnaryRequestFutureUnaryResponse
D0516 09:23:33.513714532  777844 metadata.c:248]             WARNING: 1 metadata strings were leaked
D0516 09:23:33.513718325  777844 metadata.c:252]             LEAKED: test
D0516 09:23:33.513723226  777844 metadata.c:248]             WARNING: 1 metadata strings were leaked
D0516 09:23:33.513727175  777844 metadata.c:252]             LEAKED: Exception calling application:
D0516 09:23:33.513731015  777844 metadata.c:248]             WARNING: 1 metadata strings were leaked
D0516 09:23:33.513734940  777844 metadata.c:252]             LEAKED: grpc-c/0.14.0-dev (linux)
D0516 09:23:33.513739118  777844 metadata.c:248]             WARNING: 1 metadata strings were leaked
D0516 09:23:33.513743125  777844 metadata.c:252]             LEAKED: localhost:42765
D0516 09:23:33.513747123  777844 metadata.c:248]             WARNING: 2 metadata strings were leaked
D0516 09:23:33.513751300  777844 metadata.c:252]             LEAKED: 4S
D0516 09:23:33.513755083  777844 metadata.c:252]             LEAKED: localhost:41981
D0516 09:23:33.513758996  777844 metadata.c:248]             WARNING: 1 metadata strings were leaked
D0516 09:23:33.513763186  777844 metadata.c:252]             LEAKED: /test/StreamUnary
D0516 09:23:33.513767521  777844 metadata.c:248]             WARNING: 2 metadata strings were leaked
D0516 09:23:33.513771403  777844 metadata.c:252]             LEAKED: localhost:46817
D0516 09:23:33.513775257  777844 metadata.c:252]             LEAKED: ExpiredStreamRequestFutureUnaryResponse
D0516 09:23:33.513779274  777844 metadata.c:248]             WARNING: 1 metadata strings were leaked
D0516 09:23:33.513783276  777844 metadata.c:252]             LEAKED: ExpiredUnaryRequestFutureUnaryResponse

in its output. This clearly has to do with the initial metadata from the client, but given that I've checked and rechecked and superchecked that the associated tags are getting pulled off their completion queues on each side of the connection, I'm not sure what.
(2) Hmm; I'm having trouble reproducing the other one right now. Should have made a more detailed note...

I've dropped the DO NOT MERGE label; I think this is mergeable.
I think I've answered all questions asked up to this point; please come at me with more? Lots more? I'd much rather have approval than consent.
Happy to break it up if you'd like as well.

Oh, and the memory leak question did find an answer: accidental object retention counter to the design of the (Future) class that was doing it. Took less than ten minutes to find once I sat down with a clear head to look at it.

@ctiller: now would be a good time for that link you promised me about "target" - right now I just have "the target to which to connect" in my specification; that could definitely be fleshed out.

Quick question about the ServicerContext interface: as currently drafted it has

invocation_metadata() which returns the metadata sent from the client,
initial_metadata(metadata) which sends the service-side application's metadata to the client, and
terminal_metadata(metadata) which sets the service-side application's metadata to be sent to the client when the application's function returns

. What's bothering me is that I don't think invocation_metadata is a term used anywhere else in gRPC. Should these method names be changed to

initial_metadata (or client_initial_metadata),
send_initial_metadata, and
set_trailing_metadata

?

Needs resolving.

On Wed, Apr 27, 2016 at 9:31 PM, Nathaniel Manista<EMAIL_ADDRESS>
wrote:

Lots of minutia to discuss here, but of course the most important question
for this is whether or not it has all the growth surfaces that are needed
and whether or not future changes are going to be as disruptive as past
feature growth was to the alpha and beta APIs.
(Security (mostly) not part of this code review.)
Changes from Beta:

Channel construction now takes a single string rather than separate
host and port.
RPC timeout now optional.
Server-side timeout removed - if applications don't trust the RPC
caller and want to time out according to their own schedule, they'll have
to set their own alarm clock.

Questions:

What about Future
https://github.com/grpc/grpc/blob/master/src/python/grpcio/grpc/framework/foundation/future.py?
The problems with concurrent.futures.Future that motivated
grpc.framework.foundation.future.Future haven't been solved.
"Maximizing compatibility" with concurrent.futures.Future would mean
compounding its design flaw and violating the public API of
concurrent.futures - please no? Is it a problem putting our Future
interface where it is currently drafted in this API? Should Future
appear as a code element of grpc, or should only code elements that we
expect to be used in application code be code elements of grpc?
The MultiCallable interfaces are how we support asynchronous
invocation on the same code element as synchronous invocation, but with the
current semantics they're only needed for response-unary RPCs. Should we
keep all four anyway with future growth in mind? If we want to support
async/await https://github.com/grpc/grpc/issues/6046, they'd be the
right place, right?
Should the Channel have the RPC invocation convenience methods
depicted here or is it just enough to have the MultiCallable methods? How
much do we expect users to make direct use of Channels? How hard
(and/or weird) are we making their lives if we make them write my_response
= my_channel.unary_unary(my_method_name)(my_request) instead of my_response
= my_channel.blocking_unary_unary(my_method_name, my_request)?
How should this API's documentation refer to connectivity and status
code integers? Do we just say "go look at connectivity_state.h and status.h
to see what the integer returned to you means"?

It seems that returning integers to represent enum values and relying on
user doing the conversion is really user-hostile. We really should not do
that.

Is it too clever making the raised RpcError also a Call object?
Should the RpcError have a Call object instead?

Yes it seems counterintuitive. Being able to access a "call" field on
RpcError instance seems reasonable.

Should the required Channel construction parameter be named "target"
or "address" or... something else? What exact wording would we like
describing it?

I think it's call "target" in the C core api, so let's stick with that.

What about "channel args"? How do we document them? At least one of
them is only appropriate for use in tests - are we worried about it being
passed via the non-test API?

C# allows passing in the raw channel arguments to allow finetuning some
expert settings that we don't want to expose through the basic API. For
commonly used channel args (and there should be as few as possible, ideally
none), I plan to provide factory methods later.
I think the philosophy is one should be able to set arbitrary channel
arguments if needed, but the API for doing that doesn't really have to be
super-well polished.

Servicing RPCs requires a thread pool (right?). Should the server's
thread pool be required of the application, optional, or entirely obscured?
Should the application be allowed to pass thread pool size?

For C# I construct a default thread pool and I expose some api for setting
the parameters of it, but I clearly state this api is experimental and for
expert use case only. For performance testing, these knobs can be useful.
We shouldn't publish an official API for these setting before doing some
extensive experiments with what the default values should be and after
making sure that's actually the right set of knobs to expose (it might be
completely different things that matter the most for performance)

How do we want to support generic service of arbitrary RPCs? (This
was present in beta; the question isn't coming out of nowhere.) By
accepting a function that looks like a stream-stream handler, but that
takes the method name as well and operates on bytes in and bytes out?

The simplest approach seems to be exposing a stream-stream handler with
bytes in and bytes out. I think we should eventually have good generic
service API, but let's focus on the other APIs more because most of GA
users wouldn't need to use generic methods.

Where in the API do we want to allow applications to pass native
strings as opposed to byte strings? (If we want to support my_response
= my_stub.my_method(my_request) at the read-eval-print loop, we're
going to have to support native strings in at least one place.)
Can we do away with the metadata_transformer present in alpha and
beta and make security entirely done with the plug-in API? (I suspect yes?)

Yes, security should be done entirely using the metadata credentials
plug-in. Setting the metadata on the call manually to perform auth is an
antipattern that we really should get rid of.

The host is a stub option in the beta API; should it remain a stub
option or become a channel option or per-call option?

Per stub is the choice that makes the most sense. Optionally, we could
expose a per-call option, but it's definitely not a requirement.

Where in the documentation do we want to say "metadata" and where do
we want to say "headers"? What three terms do we want to say where the beta
API said "invocation metadata", "initial metadata", and "terminal metadata"?

I think officially the names  are initialMetadata  and trailingMetadata,
if the distinction of responseInitialMetadata and requestInitialMetadata is
not clear from the API without saying "response" or "request" explicitly,
the long names become pretty annoying.

C# is actually using terms  requestHeaders   responseHeaders and trailers
(I am not sure if that's 100% compliant with our metadata policy, but I
think those are reasonble names).

In the beta API there is a CallOptions class that can be passed on
RPC invocation and that encapsulates disable_compression, subcall_of, and
per-call credentials. Do we want to do away with this aggregate object and
just have those values as keyword arguments on each RPC invocation (as is
drafted here)? If so, is there any need to worry about every future feature
being added as yet another keyword argument and eventually having an
unmanageable number?

I'm sure that sooner of later we'll need to add some new options that we
didn't quite anticipate, so having an object that can encapsulate different
call options seems like a very good idea.  Btw, one of the callOptions that
is getting added is "failFast".

here's what's C#'s doing:
There's a CallOptions struct that encapsulates all the existing call
options (and provides a constructor with optional parameters). That way,
adding a new advanced options is guaranteed not to break the public api an
is a purely additive change.
For the most commonly used options (like deadline), there's also an
overload that allows you to pass the option directly as an optional
parameter when invoking the call  - that's to prevent users from always
needing to type   new CallOptions(deadline: blahblah)...

Are "normal termination of the RPC" and "abnormal termination of the
RPC" the right terms to use?

@soltanmm https://github.com/soltanmm and @jtattermusch
https://github.com/jtattermusch please also look? Thanks much.
You can view, comment on, or merge this pull request online at:
https://github.com/grpc/grpc/pull/6327
Commit Summary

gRPC Python GA API (Draft)

File Changes

M src/python/grpcio/grpc/init.py
https://github.com/grpc/grpc/pull/6327/files#diff-0 (712)

Patch Links:

https://github.com/grpc/grpc/pull/6327.patch
https://github.com/grpc/grpc/pull/6327.diff

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/grpc/grpc/pull/6327

On Tue, May 24, 2016 at 8:48 AM, Nathaniel Manista<EMAIL_ADDRESS>
wrote:

Quick question about the ServicerContext interface: as currently drafted
it has

invocation_metadata() which returns the metadata sent from the
client,
initial_metadata(metadata) which sends the service-side
application's metadata to the client, and
terminal_metadata(metadata) which sets the service-side
application's metadata to be sent to the client when the application's
function returns

. What's bothering me is that I don't think invocation_metadata is a term
used anywhere else in gRPC. Should these method names be changed to

initial_metadata (or client_initial_metadata),
send_initial_metadata, and
set_trailing_metadata

?

send_initial_metadata and set_trailing_metadata SGTM.   initial_metadata
for request initial metadata would work, you can also consider
request_metadata.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/grpc/grpc/pull/6327#issuecomment-221258028

Gonna strongly nix request_metadata. There's natural language ambiguity for request being an attributive noun vs. a verb in that identifier.

All outstanding discussion threads addressed and I've broken up the code so that this pull request is just the GA API interfaces. Please everyone review and come forward with any last concerns - it would be nice if this could go in today before the long weekend.
@soltanmm, @jtattermusch: okay, back to invocation_metadata in the ServicerContext object. I was on the request_metadata bandwagon until I saw your nix.

Also since trailing metadata, details, and status code are fellow-travelling objects, I've changed the ServicerContext method names code and details to set_code and set_details to match the change of trailing_metadata to set_trailing_metadata.

One last question for @ctiller, @jtattermusch, and maybe @ejona86: the current draft shows GenericRpcHandler taking a method name as a string and using that as the only means by which to decide whether to handle the method or to defer to some other GenericRpcHandler further down the list - is that sufficient or do we foresee a use case in which GenericRpcHandlers will want to decide whether or not to service an RPC based on peer, metadata, or some other available-when-call-reaches-server values?

re GenericRpcHandler: aside from marginally simplified signatures (for which any future addition to would be a breaking change), do we gain anything by not exposing all information conveyed in the client's RPC prologue...?

@soltanmm: not exposing all information available at call time would save us one interface (call it a ServicerCallDetails?). So it's not that heavy a burden. What I'm looking for from @jtattermusch, @ctiller, and maybe @ejona86 is something along the lines of "of course a generic handler would never need anything more than method name to decide whether or not to service an RPC; most forecast use-cases of generic handlers are of objects that handle every RPC and won't even need the method name to decide" or "of course a generic handler should be able to see not only method name but invocation metadata, peer, timeout, and probably a few other to-be-added-in-the-future values when deciding whether or not to handle an RPC". Or some answer in between; no particular answer to the question will be hard to implement.
I just don't want to proceed without information and implement something different from the other languages that then has us either missing support for use cases that other gRPC languages support or missing simplicity for the use cases that other gRPC languages support because we've got a larger API able to serve complex use cases are unlikely to ever come to pass.

the current draft shows GenericRpcHandler taking a method name as a string and using that as the only means by which to decide whether to handle the method or to defer to some other GenericRpcHandler further down the list

@nathanielmanistaatgoogle, in general, routing should be based solely on the the method (which is the path in HTTP) and, if supported, "virtual hosting" based on the :authority (equivalent of HTTP 1's Host header). I would strongly discourage routing on anything but those two pieces of data.
I don't know if/when/how various languages support different message content types for the same service (e.g., a single service supporting both JSON and protobuf encodings), but it's possible that may be implemented as separate handlers that do some conversion into a common format and then call the "real" handler. There's multiple alternatives though.
In Java, we just pass the method name and authority when looking up a handler. For different message content types, in Java we would mostly likely improve our marshaller interface and not touch method lookup/handlers at all.

+1 to @ejona86's reply.

How important is it that the :authority be pulled out of the invocation metadata (that is how it emerges from the core, right?) and passed to the GenericRpcHandler? Can we pass the GenericRpcHandler a HandlerCallDetails object that has method and invocation_metadata attributes? Or are we absolutely certain that we'll only ever want to pass those two values that we just pass them individually rather than wrapping them in an expandable type?
Since ↑ is the last ongoing discussion in this review, is someone prepared to LGTM once it is resolved? Who?

Instances where we would want to expand this are very rare, but exist. One
is on the horizon: is this request idempotent or not?
One is being talked about: is this request allowed to mutate server state
or not?
Both will have implications for how the request should be routed and
handled if we adopt them.
Would advise having some expandable type available in the interface,
although splitting out method and maybe authority as first class is also
possibly worthwhile.
On Tue, May 31, 2016 at 10:56 AM Nathaniel Manista<EMAIL_ADDRESS>wrote:

How important is it that the :authority be pulled out of the
invocation metadata (that is how it emerges from the core, right?) and
passed to the GenericRpcHandler? Can we pass the GenericRpcHandler a
HandlerCallDetails object that has method and invocation_metadata
attributes? Or are we absolutely certain that we'll only ever want to pass
those two values that we just pass them individually rather than wrapping
them in an expandable type?
Since ↑ is the last ongoing discussion in this review, is someone
prepared to LGTM once it is resolved? Who?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/grpc/grpc/pull/6327#issuecomment-222768356, or mute
the thread
https://github.com/notifications/unsubscribe/AJpudQKgvdCu9FQxCf6E88Ndyt3NAb_2ks5qHHZggaJpZM4IRgVV
.

HandlerCallDetails interface added with room for future expansion.
Back over to y'all.

lgtm

@jtattermusch: the MacOS failure is beyond the scope of this pull request; please merge or toss back to me with action items.

The macOS failures seemed unrelated, so I just merged.
Thanks, Nathaniel.


Add flowtype / typescript definition files.

Would there be any interest in adding seperate flowtype or typescript definitions files?

It’d be great if someone wants to do it, but I don’t have the bandwidth to maintain Flow or TypeScript definition files, so I’d prefer them to live in another repository (e.g., DefinitelyTyped for TypeScript).


chore(ngMessageFormat): rename angular-messageFormat to angular-message-format

Closes #11595

Note that this will conflict with PR 11576 that improves the i18n docs.  However, the conflict is just two lines related to angular-messageFormat.js so it should be an easy resolution.
I think it is more correct to land this PR first followed by PR 11576.


Test merge

It's able to merge even after setting up workflows?! Will try merging and see if it bring the site down...


Added Tower of Hanoi

This is a classic DSA problem. I have added the question regarding Tower of Hanoi and its solution!

Hi there!
Although this repo is not part of Hacktoberfest 2024, we have some great alternatives for you. Welcome to SkillShow, a repository focused on skill enhancement!
Guidelines:

Please adhere to the existing guidelines.
No additional rules, thanks!
Check it out here: SkillShow.

Note: Start by creating an issue. Once it’s assigned to you, feel free to open a pull request (PR). Directly opening a PR will lead to an invalid label.
Looking forward to your contributions!


basedirectory_for_attachments not set at install?

It seems that basedirectory_for_attachments is not set at install, but in getAttachmentFilename is the fallback if attachmentUploadDir is not a directory (that by default is not).
See also:
https://github.com/OpenImporter/openimporter/issues/75
I tend to think it should be either set or not a fallback... and maybe both.

Deeper thought on this: I was looking at the code, and I feel this is indeed a bug. But.
I would make it into a kind of enhancement and drop entirely the "single directory" way to store attachments. This would be for 1.1 of course.
I would even go as far as to have just one way to store attachments, either "time based" (months) or "amount based" (number of attachments in each directory).
For the actual bug here... hmm... I'm too sleepy to think how fix it...

I start feeling I was drunk when I wrote this bug report.
It is correct that basedirectory_for_attachments is not set at install, how could it be?
I'm closing this and open a new one for 2.0 regarding dropping the single directory.


Get:1 http://us.archive.ubuntu.com/ubuntu/ trusty/universe iptables-persistent all 0.5.7 [10.2 kB]
Preconfiguring packages ...
Fetched 10.2 kB in 0s (14.0 kB/s)
Selecting previously unselected package iptables-persistent.
(Reading database ... 57500 files and directories currently installed.)
Preparing to unpack .../iptables-persistent_0.5.7_all.deb ...
Removing any system startup links for /etc/init.d/iptables-persistent ...
Unpacking iptables-persistent (0.5.7) ...
Processing triggers for ureadahead (0.100.0-16) ...
Setting up iptables-persistent (0.5.7) ...

Loading iptables rules...
IPv4...
IPv6...
...done.
Processing triggers for ureadahead (0.100.0-16) ...
Saving rules...
IPv4...
IPv6...
...done.

Reading package lists...
Building dependency tree...
Reading state information...
The following extra packages will be installed:
binutils build-essential cpp cpp-4.8 dpkg-dev fakeroot g++ g++-4.8 gcc
gcc-4.8 gcc-4.8-base libalgorithm-diff-perl libalgorithm-diff-xs-perl
libalgorithm-merge-perl libasan0 libatomic1 libc-dev-bin libc6 libc6-dev
libcloog-isl4 libdpkg-perl libfakeroot libfile-fcntllock-perl libgcc-4.8-dev
libgmp10 libgomp1 libisl10 libitm1 libmpc3 libmpfr4 libquadmath0
libsqlite3-0 libstdc++-4.8-dev libstdc++6 libtsan0 linux-libc-dev make
manpages-dev python-chardet-whl python-colorama python-colorama-whl
python-distlib python-distlib-whl python-html5lib python-html5lib-whl
python-pip-whl python-pkg-resources python-requests-whl python-setuptools
python-setuptools-whl python-six-whl python-urllib3-whl python-wheel
python3-pkg-resources
Suggested packages:
binutils-doc cpp-doc gcc-4.8-locales debian-keyring g++-multilib
g++-4.8-multilib gcc-4.8-doc libstdc++6-4.8-dbg gcc-multilib autoconf
automake1.9 libtool flex bison gdb gcc-doc gcc-4.8-multilib libgcc1-dbg
libgomp1-dbg libitm1-dbg libatomic1-dbg libasan0-dbg libtsan0-dbg
libquadmath0-dbg glibc-doc libstdc++-4.8-doc make-doc python-genshi
python-lxml python-distribute python-distribute-doc python3-setuptools
sqlite3-doc
Recommended packages:
python-dev-all
The following NEW packages will be installed:
binutils build-essential cpp cpp-4.8 dpkg-dev fakeroot g++ g++-4.8 gcc
gcc-4.8 libalgorithm-diff-perl libalgorithm-diff-xs-perl
libalgorithm-merge-perl libasan0 libatomic1 libc-dev-bin libc6-dev
libcloog-isl4 libdpkg-perl libfakeroot libfile-fcntllock-perl libgcc-4.8-dev
libgmp10 libgomp1 libisl10 libitm1 libmpc3 libmpfr4 libquadmath0
libstdc++-4.8-dev libtsan0 linux-libc-dev make manpages-dev
python-chardet-whl python-colorama python-colorama-whl python-distlib
python-distlib-whl python-html5lib python-html5lib-whl python-pip
python-pip-whl python-pkg-resources python-requests-whl python-setuptools
python-setuptools-whl python-six-whl python-urllib3-whl python-wheel
python3-pkg-resources sqlite3
The following packages will be upgraded:
gcc-4.8-base libc6 libsqlite3-0 libstdc++6
4 upgraded, 52 newly installed, 0 to remove and 171 not upgraded.
Need to get 46.8 MB of archives.
After this operation, 120 MB of additional disk space will be used.

Fetched 46.8 MB in 8s (5,553 kB/s)
(Reading database ... 57506 files and directories currently installed.)
Preparing to unpack .../gcc-4.8-base_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking gcc-4.8-base:amd64 (4.8.4-2ubuntu1~14.04.1) over (4.8.2-19ubuntu1) ...
Setting up gcc-4.8-base:amd64 (4.8.4-2ubuntu1~14.04.1) ...
(Reading database ... 57506 files and directories currently installed.)
Preparing to unpack .../libstdc++6_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking libstdc++6:amd64 (4.8.4-2ubuntu1~14.04.1) over (4.8.2-19ubuntu1) ...
Preparing to unpack .../libc6_2.19-0ubuntu6.7_amd64.deb ...
Unpacking libc6:amd64 (2.19-0ubuntu6.7) over (2.19-0ubuntu6) ...
Setting up libc6:amd64 (2.19-0ubuntu6.7) ...
Setting up libstdc++6:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Processing triggers for libc-bin (2.19-0ubuntu6) ...
(Reading database ... 57519 files and directories currently installed.)
Preparing to unpack .../libsqlite3-0_3.8.2-1ubuntu2.1_amd64.deb ...
Unpacking libsqlite3-0:amd64 (3.8.2-1ubuntu2.1) over (3.8.2-1ubuntu2) ...
Selecting previously unselected package libasan0:amd64.
Preparing to unpack .../libasan0_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking libasan0:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Selecting previously unselected package libatomic1:amd64.
Preparing to unpack .../libatomic1_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking libatomic1:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Selecting previously unselected package libgmp10:amd64.
Preparing to unpack .../libgmp10_2%3a5.1.3+dfsg-1ubuntu1_amd64.deb ...
Unpacking libgmp10:amd64 (2:5.1.3+dfsg-1ubuntu1) ...
Selecting previously unselected package libisl10:amd64.
Preparing to unpack .../libisl10_0.12.2-1_amd64.deb ...
Unpacking libisl10:amd64 (0.12.2-1) ...
Selecting previously unselected package libcloog-isl4:amd64.
Preparing to unpack .../libcloog-isl4_0.18.2-1_amd64.deb ...
Unpacking libcloog-isl4:amd64 (0.18.2-1) ...
Selecting previously unselected package libgomp1:amd64.
Preparing to unpack .../libgomp1_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking libgomp1:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Selecting previously unselected package libitm1:amd64.
Preparing to unpack .../libitm1_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking libitm1:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Selecting previously unselected package libmpfr4:amd64.
Preparing to unpack .../libmpfr4_3.1.2-1_amd64.deb ...
Unpacking libmpfr4:amd64 (3.1.2-1) ...
Selecting previously unselected package libquadmath0:amd64.
Preparing to unpack .../libquadmath0_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking libquadmath0:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Selecting previously unselected package libtsan0:amd64.
Preparing to unpack .../libtsan0_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking libtsan0:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Selecting previously unselected package libmpc3:amd64.
Preparing to unpack .../libmpc3_1.0.1-1ubuntu1_amd64.deb ...
Unpacking libmpc3:amd64 (1.0.1-1ubuntu1) ...
Selecting previously unselected package binutils.
Preparing to unpack .../binutils_2.24-5ubuntu14_amd64.deb ...
Unpacking binutils (2.24-5ubuntu14) ...
Selecting previously unselected package libc-dev-bin.
Preparing to unpack .../libc-dev-bin_2.19-0ubuntu6.7_amd64.deb ...
Unpacking libc-dev-bin (2.19-0ubuntu6.7) ...
Selecting previously unselected package linux-libc-dev:amd64.
Preparing to unpack .../linux-libc-dev_3.13.0-85.129_amd64.deb ...
Unpacking linux-libc-dev:amd64 (3.13.0-85.129) ...
Selecting previously unselected package libc6-dev:amd64.
Preparing to unpack .../libc6-dev_2.19-0ubuntu6.7_amd64.deb ...
Unpacking libc6-dev:amd64 (2.19-0ubuntu6.7) ...
Selecting previously unselected package cpp-4.8.
Preparing to unpack .../cpp-4.8_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking cpp-4.8 (4.8.4-2ubuntu1~14.04.1) ...
Selecting previously unselected package cpp.
Preparing to unpack .../cpp_4%3a4.8.2-1ubuntu6_amd64.deb ...
Unpacking cpp (4:4.8.2-1ubuntu6) ...
Selecting previously unselected package libgcc-4.8-dev:amd64.
Preparing to unpack .../libgcc-4.8-dev_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking libgcc-4.8-dev:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Selecting previously unselected package gcc-4.8.
Preparing to unpack .../gcc-4.8_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking gcc-4.8 (4.8.4-2ubuntu1~14.04.1) ...
Selecting previously unselected package gcc.
Preparing to unpack .../gcc_4%3a4.8.2-1ubuntu6_amd64.deb ...
Unpacking gcc (4:4.8.2-1ubuntu6) ...
Selecting previously unselected package libstdc++-4.8-dev:amd64.
Preparing to unpack .../libstdc++-4.8-dev_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking libstdc++-4.8-dev:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Selecting previously unselected package g++-4.8.
Preparing to unpack .../g++-4.8_4.8.4-2ubuntu1~14.04.1_amd64.deb ...
Unpacking g++-4.8 (4.8.4-2ubuntu1~14.04.1) ...
Selecting previously unselected package g++.
Preparing to unpack .../g++_4%3a4.8.2-1ubuntu6_amd64.deb ...
Unpacking g++ (4:4.8.2-1ubuntu6) ...
Selecting previously unselected package make.
Preparing to unpack .../make_3.81-8.2ubuntu3_amd64.deb ...
Unpacking make (3.81-8.2ubuntu3) ...
Selecting previously unselected package libdpkg-perl.
Preparing to unpack .../libdpkg-perl_1.17.5ubuntu5.5_all.deb ...
Unpacking libdpkg-perl (1.17.5ubuntu5.5) ...
Selecting previously unselected package dpkg-dev.
Preparing to unpack .../dpkg-dev_1.17.5ubuntu5.5_all.deb ...
Unpacking dpkg-dev (1.17.5ubuntu5.5) ...
Selecting previously unselected package build-essential.
Preparing to unpack .../build-essential_11.6ubuntu6_amd64.deb ...
Unpacking build-essential (11.6ubuntu6) ...
Selecting previously unselected package libfakeroot:amd64.
Preparing to unpack .../libfakeroot_1.20-3ubuntu2_amd64.deb ...
Unpacking libfakeroot:amd64 (1.20-3ubuntu2) ...
Selecting previously unselected package fakeroot.
Preparing to unpack .../fakeroot_1.20-3ubuntu2_amd64.deb ...
Unpacking fakeroot (1.20-3ubuntu2) ...
Selecting previously unselected package libalgorithm-diff-perl.
Preparing to unpack .../libalgorithm-diff-perl_1.19.02-3_all.deb ...
Unpacking libalgorithm-diff-perl (1.19.02-3) ...
Selecting previously unselected package libalgorithm-diff-xs-perl.
Preparing to unpack .../libalgorithm-diff-xs-perl_0.04-2build4_amd64.deb ...
Unpacking libalgorithm-diff-xs-perl (0.04-2build4) ...
Selecting previously unselected package libalgorithm-merge-perl.
Preparing to unpack .../libalgorithm-merge-perl_0.08-2_all.deb ...
Unpacking libalgorithm-merge-perl (0.08-2) ...
Selecting previously unselected package libfile-fcntllock-perl.
Preparing to unpack .../libfile-fcntllock-perl_0.14-2build1_amd64.deb ...
Unpacking libfile-fcntllock-perl (0.14-2build1) ...
Selecting previously unselected package manpages-dev.
Preparing to unpack .../manpages-dev_3.54-1ubuntu1_all.deb ...
Unpacking manpages-dev (3.54-1ubuntu1) ...
Selecting previously unselected package python3-pkg-resources.
Preparing to unpack .../python3-pkg-resources_3.3-1ubuntu2_all.deb ...
Unpacking python3-pkg-resources (3.3-1ubuntu2) ...
Selecting previously unselected package python-chardet-whl.
Preparing to unpack .../python-chardet-whl_2.2.1-2~ubuntu1_all.deb ...
Unpacking python-chardet-whl (2.2.1-2~ubuntu1) ...
Selecting previously unselected package python-colorama.
Preparing to unpack .../python-colorama_0.2.5-0.1ubuntu2_all.deb ...
Unpacking python-colorama (0.2.5-0.1ubuntu2) ...
Selecting previously unselected package python-colorama-whl.
Preparing to unpack .../python-colorama-whl_0.2.5-0.1ubuntu2_all.deb ...
Unpacking python-colorama-whl (0.2.5-0.1ubuntu2) ...
Selecting previously unselected package python-distlib.
Preparing to unpack .../python-distlib_0.1.8-1ubuntu1_all.deb ...
Unpacking python-distlib (0.1.8-1ubuntu1) ...
Selecting previously unselected package python-distlib-whl.
Preparing to unpack .../python-distlib-whl_0.1.8-1ubuntu1_all.deb ...
Unpacking python-distlib-whl (0.1.8-1ubuntu1) ...
Selecting previously unselected package python-html5lib.
Preparing to unpack .../python-html5lib_0.999-3~ubuntu1_all.deb ...
Unpacking python-html5lib (0.999-3~ubuntu1) ...
Selecting previously unselected package python-html5lib-whl.
Preparing to unpack .../python-html5lib-whl_0.999-3~ubuntu1_all.deb ...
Unpacking python-html5lib-whl (0.999-3~ubuntu1) ...
Selecting previously unselected package python-six-whl.
Preparing to unpack .../python-six-whl_1.5.2-1ubuntu1_all.deb ...
Unpacking python-six-whl (1.5.2-1ubuntu1) ...
Selecting previously unselected package python-urllib3-whl.
Preparing to unpack .../python-urllib3-whl_1.7.1-1ubuntu4_all.deb ...
Unpacking python-urllib3-whl (1.7.1-1ubuntu4) ...
Selecting previously unselected package python-requests-whl.
Preparing to unpack .../python-requests-whl_2.2.1-1ubuntu0.3_all.deb ...
Unpacking python-requests-whl (2.2.1-1ubuntu0.3) ...
Selecting previously unselected package python-setuptools-whl.
Preparing to unpack .../python-setuptools-whl_3.3-1ubuntu2_all.deb ...
Unpacking python-setuptools-whl (3.3-1ubuntu2) ...
Selecting previously unselected package python-pip-whl.
Preparing to unpack .../python-pip-whl_1.5.4-1ubuntu3_all.deb ...
Unpacking python-pip-whl (1.5.4-1ubuntu3) ...
Selecting previously unselected package python-pkg-resources.
Preparing to unpack .../python-pkg-resources_3.3-1ubuntu2_all.deb ...
Unpacking python-pkg-resources (3.3-1ubuntu2) ...
Selecting previously unselected package python-setuptools.
Preparing to unpack .../python-setuptools_3.3-1ubuntu2_all.deb ...
Unpacking python-setuptools (3.3-1ubuntu2) ...
Selecting previously unselected package python-pip.
Preparing to unpack .../python-pip_1.5.4-1ubuntu3_all.deb ...
Unpacking python-pip (1.5.4-1ubuntu3) ...
Selecting previously unselected package python-wheel.
Preparing to unpack .../python-wheel_0.24.0-1~ubuntu1_all.deb ...
Unpacking python-wheel (0.24.0-1~ubuntu1) ...
Selecting previously unselected package sqlite3.
Preparing to unpack .../sqlite3_3.8.2-1ubuntu2.1_amd64.deb ...
Unpacking sqlite3 (3.8.2-1ubuntu2.1) ...
Processing triggers for man-db (<IP_ADDRESS>-1) ...
Setting up libsqlite3-0:amd64 (3.8.2-1ubuntu2.1) ...
Setting up libasan0:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Setting up libatomic1:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Setting up libgmp10:amd64 (2:5.1.3+dfsg-1ubuntu1) ...
Setting up libisl10:amd64 (0.12.2-1) ...
Setting up libcloog-isl4:amd64 (0.18.2-1) ...
Setting up libgomp1:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Setting up libitm1:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Setting up libmpfr4:amd64 (3.1.2-1) ...
Setting up libquadmath0:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Setting up libtsan0:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Setting up libmpc3:amd64 (1.0.1-1ubuntu1) ...
Setting up binutils (2.24-5ubuntu14) ...
Setting up libc-dev-bin (2.19-0ubuntu6.7) ...
Setting up linux-libc-dev:amd64 (3.13.0-85.129) ...
Setting up libc6-dev:amd64 (2.19-0ubuntu6.7) ...
Setting up cpp-4.8 (4.8.4-2ubuntu1~14.04.1) ...
Setting up cpp (4:4.8.2-1ubuntu6) ...
Setting up libgcc-4.8-dev:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Setting up gcc-4.8 (4.8.4-2ubuntu1~14.04.1) ...
Setting up gcc (4:4.8.2-1ubuntu6) ...
Setting up libstdc++-4.8-dev:amd64 (4.8.4-2ubuntu1~14.04.1) ...
Setting up g++-4.8 (4.8.4-2ubuntu1~14.04.1) ...
Setting up g++ (4:4.8.2-1ubuntu6) ...
update-alternatives: using /usr/bin/g++ to provide /usr/bin/c++ (c++) in auto mode
Setting up make (3.81-8.2ubuntu3) ...
Setting up libdpkg-perl (1.17.5ubuntu5.5) ...
Setting up dpkg-dev (1.17.5ubuntu5.5) ...
Setting up build-essential (11.6ubuntu6) ...
Setting up libfakeroot:amd64 (1.20-3ubuntu2) ...
Setting up fakeroot (1.20-3ubuntu2) ...
update-alternatives: using /usr/bin/fakeroot-sysv to provide /usr/bin/fakeroot (fakeroot) in auto mode
Setting up libalgorithm-diff-perl (1.19.02-3) ...
Setting up libalgorithm-diff-xs-perl (0.04-2build4) ...
Setting up libalgorithm-merge-perl (0.08-2) ...
Setting up libfile-fcntllock-perl (0.14-2build1) ...
Setting up manpages-dev (3.54-1ubuntu1) ...
Setting up python3-pkg-resources (3.3-1ubuntu2) ...
Setting up python-chardet-whl (2.2.1-2~ubuntu1) ...
Setting up python-colorama (0.2.5-0.1ubuntu2) ...
Setting up python-colorama-whl (0.2.5-0.1ubuntu2) ...
Setting up python-distlib (0.1.8-1ubuntu1) ...
Setting up python-distlib-whl (0.1.8-1ubuntu1) ...
Setting up python-html5lib (0.999-3~ubuntu1) ...
Setting up python-html5lib-whl (0.999-3~ubuntu1) ...
Setting up python-six-whl (1.5.2-1ubuntu1) ...
Setting up python-urllib3-whl (1.7.1-1ubuntu4) ...
Setting up python-requests-whl (2.2.1-1ubuntu0.3) ...
Setting up python-setuptools-whl (3.3-1ubuntu2) ...
Setting up python-pip-whl (1.5.4-1ubuntu3) ...
Setting up python-pkg-resources (3.3-1ubuntu2) ...
Setting up python-setuptools (3.3-1ubuntu2) ...
Setting up python-pip (1.5.4-1ubuntu3) ...
Setting up python-wheel (0.24.0-1~ubuntu1) ...
Setting up sqlite3 (3.8.2-1ubuntu2.1) ...
Processing triggers for libc-bin (2.19-0ubuntu6) ...
Downloading/unpacking pip from https://pypi.python.org/packages/py2.py3/p/pip/pip-8.1.1-py2.py3-none-any.whl#md5=22db7b6a517a09c29d54a76650f170eb
Installing collected packages: pip
Found existing installation: pip 1.5.4
Not uninstalling pip at /usr/lib/python2.7/dist-packages, owned by OS
Successfully installed pip
Cleaning up...
Collecting docker-compose
/usr/local/lib/python2.7/dist-packages/pip/vendor/requests/packages/urllib3/util/ssl.py:315: SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certificate, which can cause validation failures. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning.
SNIMissingWarning
/usr/local/lib/python2.7/dist-packages/pip/vendor/requests/packages/urllib3/util/ssl.py:120: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
InsecurePlatformWarning
Downloading docker-compose-1.7.0.tar.gz (141kB)
Collecting cached-property<2,>=1.2.0 (from docker-compose)
Downloading cached_property-1.3.0-py2.py3-none-any.whl
Collecting docopt<0.7,>=0.6.1 (from docker-compose)
Downloading docopt-0.6.2.tar.gz
Collecting PyYAML<4,>=3.10 (from docker-compose)
Downloading PyYAML-3.11.tar.gz (248kB)
Collecting requests<2.8,>=2.6.1 (from docker-compose)
Downloading requests-2.7.0-py2.py3-none-any.whl (470kB)
Collecting texttable<0.9,>=0.8.1 (from docker-compose)
Downloading texttable-0.8.4.tar.gz
Collecting websocket-client<1.0,>=0.32.0 (from docker-compose)
Downloading websocket_client-0.37.0.tar.gz (194kB)
Collecting docker-py<2,>1.7.2 (from docker-compose)
Downloading docker_py-1.8.0-py2.py3-none-any.whl (41kB)
Collecting dockerpty<0.5,>=0.4.1 (from docker-compose)
Downloading dockerpty-0.4.1.tar.gz
Requirement already satisfied (use --upgrade to upgrade): six<2,>=1.3.0 in /usr/lib/python2.7/dist-packages (from docker-compose)
Collecting jsonschema<3,>=2.5.1 (from docker-compose)
Downloading jsonschema-2.5.1-py2.py3-none-any.whl
Collecting enum34<2,>=1.0.4 (from docker-compose)
Downloading enum34-1.1.3-py2.py3-none-any.whl (61kB)
Collecting backports.ssl-match-hostname (from websocket-client<1.0,>=0.32.0->docker-compose)
Downloading backports.ssl_match_hostname-<IP_ADDRESS>.tar.gz
Collecting py2-ipaddress>=3.4.1 (from docker-py<2,>1.7.2->docker-compose)
Downloading py2-ipaddress-3.4.1.tar.gz
Collecting functools32 (from jsonschema<3,>=2.5.1->docker-compose)
Downloading functools32-3.2.3-2.tar.gz
Building wheels for collected packages: docker-compose, docopt, PyYAML, texttable, websocket-client, dockerpty, backports.ssl-match-hostname, py2-ipaddress, functools32
Running setup.py bdist_wheel for docker-compose: started
Running setup.py bdist_wheel for docker-compose: finished with status 'done'
Stored in directory: /root/.cache/pip/wheels/dd/76/fb/1ac77a863ae8c358460476b85b70265929f39654ca6644992a
Running setup.py bdist_wheel for docopt: started
Running setup.py bdist_wheel for docopt: finished with status 'done'
Stored in directory: /root/.cache/pip/wheels/0d/5c/a7/cb986749520c1950217b5d8405def5c18541322dbc411a80d1
Running setup.py bdist_wheel for PyYAML: started
Running setup.py bdist_wheel for PyYAML: finished with status 'done'
Stored in directory: /root/.cache/pip/wheels/fa/db/f6/dee55793d344f1706dc4a5a693298f0115241d1085cc212364
Running setup.py bdist_wheel for texttable: started
Running setup.py bdist_wheel for texttable: finished with status 'done'
Stored in directory: /root/.cache/pip/wheels/ab/74/7f/2b7fc041492ad26d80779955f8fbc596c948f13e2dbb33bf6d
Running setup.py bdist_wheel for websocket-client: started
Running setup.py bdist_wheel for websocket-client: finished with status 'done'
Stored in directory: /root/.cache/pip/wheels/3e/82/ad/d941b5ca7bb6a0b613baed947cb099d6f68f5d3b84024ac0c7
Running setup.py bdist_wheel for dockerpty: started
Running setup.py bdist_wheel for dockerpty: finished with status 'done'
Stored in directory: /root/.cache/pip/wheels/05/8c/84/a3085d476576abe6b39eddd7886f14eea7f346321a98e6c3fd
Running setup.py bdist_wheel for backports.ssl-match-hostname: started
Running setup.py bdist_wheel for backports.ssl-match-hostname: finished with status 'done'
Stored in directory: /root/.cache/pip/wheels/ca/e4/ff/d57f7b2052ddfcf76644f59ad355808f8584d79d4d922601e1
Running setup.py bdist_wheel for py2-ipaddress: started
Running setup.py bdist_wheel for py2-ipaddress: finished with status 'done'
Stored in directory: /root/.cache/pip/wheels/67/27/9d/03c7c02d09d59460280a824af941f7ebd0c9fb69c429f54cd2
Running setup.py bdist_wheel for functools32: started
Running setup.py bdist_wheel for functools32: finished with status 'done'
Stored in directory: /root/.cache/pip/wheels/38/c6/c7/ee17acd621120c302e25c2fa8b3a8b235d5d1137c6ab4c9728
Successfully built docker-compose docopt PyYAML texttable websocket-client dockerpty backports.ssl-match-hostname py2-ipaddress functools32
Installing collected packages: cached-property, docopt, PyYAML, requests, texttable, backports.ssl-match-hostname, websocket-client, py2-ipaddress, docker-py, dockerpty, functools32, jsonschema, enum34, docker-compose
Found existing installation: requests 2.2.1
DEPRECATION: Uninstalling a distutils installed project (requests) has been deprecated and will be removed in a future version. This is due to the fact that uninstalling a distutils project will only partially uninstall the project.
Uninstalling requests-2.2.1:
Successfully uninstalled requests-2.2.1
Successfully installed PyYAML-3.11 backports.ssl-match-hostname-<IP_ADDRESS> cached-property-1.3.0 docker-compose-1.7.0 docker-py-1.8.0 dockerpty-0.4.1 docopt-0.6.2 enum34-1.1.3 functools32-3.2.3-2 jsonschema-2.5.1 py2-ipaddress-3.4.1 requests-2.7.0 texttable-0.8.4 websocket-client-0.37.0
/usr/local/lib/python2.7/dist-packages/pip/vendor/requests/packages/urllib3/util/ssl.py:120: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
InsecurePlatformWarning
Collecting dnspython (from -r /opt/netflix-proxy/auth/requirements.txt (line 1))
/usr/local/lib/python2.7/dist-packages/pip/vendor/requests/packages/urllib3/util/ssl.py:315: SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certificate, which can cause validation failures. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning.
SNIMissingWarning
/usr/local/lib/python2.7/dist-packages/pip/vendor/requests/packages/urllib3/util/ssl.py:120: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
InsecurePlatformWarning
Downloading dnspython-1.12.0.zip (230kB)
Collecting web.py (from -r /opt/netflix-proxy/auth/requirements.txt (line 2))
Downloading web.py-0.37.tar.gz (90kB)
Collecting passlib (from -r /opt/netflix-proxy/auth/requirements.txt (line 3))
Downloading passlib-1.6.5-py2.py3-none-any.whl (317kB)
Building wheels for collected packages: dnspython, web.py
Running setup.py bdist_wheel for dnspython: started
Running setup.py bdist_wheel for dnspython: finished with status 'done'
Stored in directory: /root/.cache/pip/wheels/e0/58/e2/981145033fb65602c3c004d5dd92fb360c02f3b05ba654a336
Running setup.py bdist_wheel for web.py: started
Running setup.py bdist_wheel for web.py: finished with status 'done'
Stored in directory: /root/.cache/pip/wheels/4c/5b/21/80edc384b01b28f4c3f6a310b4aa27f50feafe4a97327fdfd4
Successfully built dnspython web.py
Installing collected packages: dnspython, web.py, passlib
Successfully installed dnspython-1.12.0 passlib-1.6.5 web.py-0.37
proxy / localhost:43867 {
except /static
proxy_header Host {host}
proxy_header X-Forwarded-For {remote}
proxy_header X-Real-IP {remote}
proxy_header X-Forwarded-Proto {scheme}
}
Pulling reverse-proxy (abiosoft/caddy:latest)...
latest: Pulling from abiosoft/caddy
Digest: sha256:3946e9e66aff4dd35fe1c782f448a46b6c151463ade45e45c70eaa09fdad5000
Status: Downloaded newer image for abiosoft/caddy:latest
Pulling bind (ab77/bind:latest)...
latest: Pulling from ab77/bind
Digest: sha256:235b0707e21e92bb01d6db5bbe7029a3aa5ce98506010a7c05e52af5a0d60267
Status: Downloaded newer image for ab77/bind:latest
Pulling dnsmasq (andyshinn/dnsmasq:latest)...
latest: Pulling from andyshinn/dnsmasq
Digest: sha256:8b765ee9ba2e6bed56728f7c2ff7c2a40ce049dda98cd454e59f1f8386cd50dd
Status: Downloaded newer image for andyshinn/dnsmasq:latest
Pulling sniproxy (ab77/sniproxy:latest)...
latest: Pulling from ab77/sniproxy
Digest: sha256:191fdc8d7ef978c8cbb65fac04643496bbe47efd55891a3f032834130d0b8e6f
Status: Downloaded newer image for ab77/sniproxy:latest
Creating caddy
Creating bind
Creating sniproxy
Creating dnsmasq
Creating caching-resolver
docker stop/waiting
docker start/running, process 11297
netflix-proxy-admin start/running, process 11322
ndp-proxy-helper start/running, process 11332

Loading iptables rules...
IPv4...
 Retrying in 10..
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 1999 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G3
verify return:1
depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 Secure Server CA - G4
verify return:1
depth=0 C = US, ST = CALIFORNIA, L = Los Gatos, O = "Netflix, Inc.", OU = Operations, CN = www.netflix.com
verify return:1
CONNECTED(00000003)
Certificate chain
0 s:/C=US/ST=CALIFORNIA/L=Los Gatos/O=Netflix, Inc./OU=Operations/CN=www.netflix.com
i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G3
Server certificate
-----BEGIN CERTIFICATE-----
MIIFijCCBHKgAwIBAgIQQ9vZa/gIJmgo9kj2egocUjANBgkqhkiG9w0BAQsFADB+
MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd
BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLzAtBgNVBAMTJlN5bWFudGVj
IENsYXNzIDMgU2VjdXJlIFNlcnZlciBDQSAtIEc0MB4XDTE1MDQxNDAwMDAwMFoX
DTE3MDQxMjIzNTk1OVowfTELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNBTElGT1JO
SUExEjAQBgNVBAcMCUxvcyBHYXRvczEWMBQGA1UECgwNTmV0ZmxpeCwgSW5jLjET
MBEGA1UECwwKT3BlcmF0aW9uczEYMBYGA1UEAwwPd3d3Lm5ldGZsaXguY29tMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuahXKETW08vuetLrBeK6Ldf5
SssEHYoJDTkj/CNX+h9jCkJLuU35kYpHHeIBSQFM1nOf6VTLBI6EwRSoaJYZeUfL
kjV/0SSFLpCyxWIeiqRxoZPJi8e+GyAedP8//B6pgJEX/Xqv0twe3OG2IQ1vVX0J
vbzTWl7in6xOUfN0XN6H9blqCSWJdRnIQE511xnJn8GfjbHm2hVbeuPBoogqTvoa
8/8n30BlEFG3GVi9sn2/O+HBsShrfgvmWk91dlH77Jg8koE0L9Qigv8VGltQmpbd
bWt39re8AQ8i52wlsp5tudhO9q+lWwMN3PrX14PZqKk3sjsOxUa8nDU5Uq63sQID
AQABo4ICAzCCAf8wgbQGA1UdEQSBrDCBqYITYWNjb3VudC5uZXRmbGl4LmNvbYIO
Y2EubmV0ZmxpeC5jb22CCm5ldGZsaXguY2GCC25ldGZsaXguY29tghJzaWdudXAu
bmV0ZmxpeC5jb22CDnd3dy5uZXRmbGl4LmNhgg93d3cubmV0ZmxpeC5jb22CEHd3
dzEubmV0ZmxpeC5jb22CEHd3dzIubmV0ZmxpeC5jb22CEHd3dzMubmV0ZmxpeC5j
b20wCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUH
AwEGCCsGAQUFBwMCMGUGA1UdIAReMFwwWgYKYIZIAYb4RQEHNjBMMCMGCCsGAQUF
BwIBFhdodHRwczovL2Quc3ltY2IuY29tL2NwczAlBggrBgEFBQcCAjAZGhdodHRw
czovL2Quc3ltY2IuY29tL3JwYTAfBgNVHSMEGDAWgBRfYM9hkFXfhEMUimAqsvV6
9EMY7zArBgNVHR8EJDAiMCCgHqAchhpodHRwOi8vc3Muc3ltY2IuY29tL3NzLmNy
bDBXBggrBgEFBQcBAQRLMEkwHwYIKwYBBQUHMAGGE2h0dHA6Ly9zcy5zeW1jZC5j
b20wJgYIKwYBBQUHMAKGGmh0dHA6Ly9zcy5zeW1jYi5jb20vc3MuY3J0MA0GCSqG
SIb3DQEBCwUAA4IBAQCjzCPCZ0QQFwU/ehGm970LQVN/CXtuFI6UvJCMsFXeAaS1
8qDkl9tW/9ihpaUvy7GabfCEglBnnhYlWhcu1jGYVdoJH6fBYWKH6cKGS/NQpRu/
647cpvCVS1STW0vYJF5beKDeP0Rik9YMbiDAOjK3/z0bBxpNFf/xTRlbTOfJeJJa
ZkLvqIuRidMdyvZ6Pw4FkpYLyqSrTA49fs6zutp76ek+KhvHr9nGylKWWm+mg2RP
DM880iAq7A0VQY/eHt3PJCmPyEdO5Q0UG2UQ12OhYXIwpr8ZnwjhtxPMYY/eYdGE
DWkrV+u0kzRIg6UcDlgT44Avd56+e5v7Z8IM+ZTU
-----END CERTIFICATE-----
subject=/C=US/ST=CALIFORNIA/L=Los Gatos/O=Netflix, Inc./OU=Operations/CN=www.netflix.com
issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
No client certificate CA names sent
SSL handshake has read 3400 bytes and written 463 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1.2
Cipher    : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: DF27EE827CA936E0B3CD8F3C15285FD271B0977EEEC6BCBB521CB3D97D453F17
Session-ID-ctx:
Master-Key: C48E7EA868DC97DBE385809897DE618984F2C090915A213964551B49470074488B03C66AE246BB708C8987ED15D1B906
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 41 e8 f4 d8 a4 42 0c 6b-e4 8b b9 65 05 eb 2c f2   A....B.k...e..,.
0010 - 74 94 50 27 45 a3 58 15-44 1b 6f c8 b1 e5 d0 0e   t.P'E.X.D.o.....
0020 - e6 25 95 c0 bd 0b 7a 4e-38 85 aa 13 6c f3 0e 48   .%....zN8...l..H
0030 - 59 c8 3c 00 69 bb ff 38-4c 93 6c d1 21 59 d2 b5   Y.<.i..8L.l.!Y..
0040 - f5 d8 3a 43 aa 5a e8 4d-ba 96 52 49 4b 8b 86 fb   ..:C.Z.M..RIK...
0050 - e3 68 6e 23 6d 7b 60 dc-7d 53 db 4d 11 9c e1 37   .hn#m{.}S.M...7     0060 - 00 55 6f 0c 44 ee 19 5d-13 e9 1d 44 0a e4 c4 97   .Uo.D..]...D....     0070 - 31 4f e4 02 a0 f2 88 ad-96 7b 2d 75 1f 85 00 dd   1O.......{-u....     0080 - 27 c7 a4 d6 6d 93 62 e9-5a 0c 1e cd de 4b 7e 45   '...m.b.Z....K~E     0090 - d1 d6 46 01 b8 c7 a8 3f-4d 0d 42 9b f8 8b 73 47   ..F....?M.B...sG     00a0 - aa 60 47 0b cd 9c 9d df-b6 2f 74 77 cd f3 be 6b   .G....../tw...k
Start Time:<PHONE_NUMBER>
Timeout   : 300 (sec)
Verify return code: 0 (ok)

DONE
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
0     0    0 91551    0     0   131k      0 --:--:-- --:--:-- --:--:--  204k
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
/opt/netflix-proxy

https://help.github.com/articles/basic-writing-and-formatting-syntax/

net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6=1
net.ipv6.conf.eth0.disable_ipv6 = 1
Reading package lists...
Building dependency tree...
Reading state information...
The following extra packages will be installed:
  libauthen-sasl-perl libencode-locale-perl libfile-listing-perl
  libfont-afm-perl libhtml-form-perl libhtml-format-perl libhtml-parser-perl
  libhtml-tagset-perl libhtml-tree-perl libhttp-cookies-perl
  libhttp-daemon-perl libhttp-date-perl libhttp-message-perl
  libhttp-negotiate-perl libio-html-perl libio-socket-inet6-perl
  libio-socket-ssl-perl liblwp-mediatypes-perl liblwp-protocol-https-perl
  libmailtools-perl libnet-http-perl libnet-smtp-ssl-perl libnet-ssleay-perl
  libsocket6-perl liburi-perl libwww-perl libwww-robotrules-perl
  libxml-parser-perl
Suggested packages:
  libdigest-hmac-perl libgssapi-perl libdata-dump-perl libcrypt-ssleay-perl
  libauthen-ntlm-perl
The following NEW packages will be installed:
  libauthen-sasl-perl libencode-locale-perl libfile-listing-perl
  libfont-afm-perl libhtml-form-perl libhtml-format-perl libhtml-parser-perl
  libhtml-tagset-perl libhtml-tree-perl libhttp-cookies-perl
  libhttp-daemon-perl libhttp-date-perl libhttp-message-perl
  libhttp-negotiate-perl libio-html-perl libio-socket-inet6-perl
  libio-socket-ssl-perl liblwp-mediatypes-perl liblwp-protocol-https-perl
  libmailtools-perl libnet-http-perl libnet-smtp-ssl-perl libnet-ssleay-perl
  libsocket6-perl liburi-perl libwww-perl libwww-robotrules-perl
  libxml-parser-perl libxml-xpath-perl
0 upgraded, 29 newly installed, 0 to remove and 175 not upgraded.
Need to get 1,766 kB of archives.
After this operation, 5,762 kB of additional disk space will be used.

(Reading database ... 56796 files and directories currently installed.)
Preparing to unpack .../libencode-locale-perl_1.03-1_all.deb ...
Unpacking libencode-locale-perl (1.03-1) ...
Selecting previously unselected package libhttp-date-perl.
Preparing to unpack .../libhttp-date-perl_6.02-1_all.deb ...
Unpacking libhttp-date-perl (6.02-1) ...
Selecting previously unselected package libfile-listing-perl.
Preparing to unpack .../libfile-listing-perl_6.04-1_all.deb ...
Unpacking libfile-listing-perl (6.04-1) ...
Selecting previously unselected package libfont-afm-perl.
Preparing to unpack .../libfont-afm-perl_1.20-1_all.deb ...
Unpacking libfont-afm-perl (1.20-1) ...
Selecting previously unselected package liburi-perl.
Preparing to unpack .../liburi-perl_1.60-1_all.deb ...
Unpacking liburi-perl (1.60-1) ...
Selecting previously unselected package libhtml-tagset-perl.
Preparing to unpack .../libhtml-tagset-perl_3.20-2_all.deb ...
Unpacking libhtml-tagset-perl (3.20-2) ...
Selecting previously unselected package libhtml-parser-perl.
Preparing to unpack .../libhtml-parser-perl_3.71-1build1_amd64.deb ...
Unpacking libhtml-parser-perl (3.71-1build1) ...
Selecting previously unselected package libio-html-perl.
Preparing to unpack .../libio-html-perl_1.00-1_all.deb ...
Unpacking libio-html-perl (1.00-1) ...
Selecting previously unselected package liblwp-mediatypes-perl.
Preparing to unpack .../liblwp-mediatypes-perl_6.02-1_all.deb ...
Unpacking liblwp-mediatypes-perl (6.02-1) ...
Selecting previously unselected package libhttp-message-perl.
Preparing to unpack .../libhttp-message-perl_6.06-1_all.deb ...
Unpacking libhttp-message-perl (6.06-1) ...
Selecting previously unselected package libhtml-form-perl.
Preparing to unpack .../libhtml-form-perl_6.03-1_all.deb ...
Unpacking libhtml-form-perl (6.03-1) ...
Selecting previously unselected package libhtml-tree-perl.
Preparing to unpack .../libhtml-tree-perl_5.03-1_all.deb ...
Unpacking libhtml-tree-perl (5.03-1) ...
Selecting previously unselected package libhtml-format-perl.
Preparing to unpack .../libhtml-format-perl_2.11-1_all.deb ...
Unpacking libhtml-format-perl (2.11-1) ...
Selecting previously unselected package libhttp-cookies-perl.
Preparing to unpack .../libhttp-cookies-perl_6.00-2_all.deb ...
Unpacking libhttp-cookies-perl (6.00-2) ...
Selecting previously unselected package libhttp-daemon-perl.
Preparing to unpack .../libhttp-daemon-perl_6.01-1_all.deb ...
Unpacking libhttp-daemon-perl (6.01-1) ...
Selecting previously unselected package libhttp-negotiate-perl.
Preparing to unpack .../libhttp-negotiate-perl_6.00-2_all.deb ...
Unpacking libhttp-negotiate-perl (6.00-2) ...
Selecting previously unselected package libsocket6-perl.
Preparing to unpack .../libsocket6-perl_0.25-1_amd64.deb ...
Unpacking libsocket6-perl (0.25-1) ...
Selecting previously unselected package libio-socket-inet6-perl.
Preparing to unpack .../libio-socket-inet6-perl_2.71-1_all.deb ...
Unpacking libio-socket-inet6-perl (2.71-1) ...
Selecting previously unselected package libnet-ssleay-perl.
Preparing to unpack .../libnet-ssleay-perl_1.58-1_amd64.deb ...
Unpacking libnet-ssleay-perl (1.58-1) ...
Selecting previously unselected package libio-socket-ssl-perl.
Preparing to unpack .../libio-socket-ssl-perl_1.965-1ubuntu1_all.deb ...
Unpacking libio-socket-ssl-perl (1.965-1ubuntu1) ...
Selecting previously unselected package libnet-http-perl.
Preparing to unpack .../libnet-http-perl_6.06-1_all.deb ...
Unpacking libnet-http-perl (6.06-1) ...
Selecting previously unselected package libwww-robotrules-perl.
Preparing to unpack .../libwww-robotrules-perl_6.01-1_all.deb ...
Unpacking libwww-robotrules-perl (6.01-1) ...
Selecting previously unselected package libwww-perl.
Preparing to unpack .../libwww-perl_6.05-2_all.deb ...
Unpacking libwww-perl (6.05-2) ...
Selecting previously unselected package liblwp-protocol-https-perl.
Preparing to unpack .../liblwp-protocol-https-perl_6.04-2ubuntu0.1_all.deb ...
Unpacking liblwp-protocol-https-perl (6.04-2ubuntu0.1) ...
Selecting previously unselected package libnet-smtp-ssl-perl.
Preparing to unpack .../libnet-smtp-ssl-perl_1.01-3_all.deb ...
Unpacking libnet-smtp-ssl-perl (1.01-3) ...
Selecting previously unselected package libmailtools-perl.
Preparing to unpack .../libmailtools-perl_2.12-1_all.deb ...
Unpacking libmailtools-perl (2.12-1) ...
Selecting previously unselected package libxml-parser-perl.
Preparing to unpack .../libxml-parser-perl_2.41-1build3_amd64.deb ...
Unpacking libxml-parser-perl (2.41-1build3) ...
Selecting previously unselected package libxml-xpath-perl.
Preparing to unpack .../libxml-xpath-perl_1.13-7_all.deb ...
Unpacking libxml-xpath-perl (1.13-7) ...
Selecting previously unselected package libauthen-sasl-perl.
Preparing to unpack .../libauthen-sasl-perl_2.1500-1_all.deb ...
Unpacking libauthen-sasl-perl (2.1500-1) ...
Processing triggers for man-db (<IP_ADDRESS>-1) ...
Setting up libencode-locale-perl (1.03-1) ...
Setting up libhttp-date-perl (6.02-1) ...
Setting up libfile-listing-perl (6.04-1) ...
Setting up libfont-afm-perl (1.20-1) ...
Setting up liburi-perl (1.60-1) ...
Setting up libhtml-tagset-perl (3.20-2) ...
Setting up libhtml-parser-perl (3.71-1build1) ...
Setting up libio-html-perl (1.00-1) ...
Setting up liblwp-mediatypes-perl (6.02-1) ...
Setting up libhttp-message-perl (6.06-1) ...
Setting up libhtml-form-perl (6.03-1) ...
Setting up libhtml-tree-perl (5.03-1) ...
Setting up libhtml-format-perl (2.11-1) ...
Setting up libhttp-cookies-perl (6.00-2) ...
Setting up libhttp-daemon-perl (6.01-1) ...
Setting up libhttp-negotiate-perl (6.00-2) ...
Setting up libsocket6-perl (0.25-1) ...
Setting up libio-socket-inet6-perl (2.71-1) ...
Setting up libnet-ssleay-perl (1.58-1) ...
Setting up libio-socket-ssl-perl (1.965-1ubuntu1) ...
Setting up libnet-http-perl (6.06-1) ...
Setting up libwww-robotrules-perl (6.01-1) ...
Setting up libnet-smtp-ssl-perl (1.01-3) ...
Setting up libmailtools-perl (2.12-1) ...
Setting up libauthen-sasl-perl (2.1500-1) ...
Setting up libwww-perl (6.05-2) ...
Setting up liblwp-protocol-https-perl (6.04-2ubuntu0.1) ...
Setting up libxml-parser-perl (2.41-1build3) ...
Setting up libxml-xpath-perl (1.13-7) ...
source-directory interfaces.d
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   323  100   323    0     0   1200      0 --:--:-- --:--:-- --:--:--  1205
<?xml version="1.0" encoding="UTF-8"?>
<tunnels>
 <tunnel id="332600">
  <description></description>
  <serverv4><IP_ADDRESS></serverv4>
  <clientv4><IP_ADDRESS></clientv4>
  <serverv6>2001:470:1f18:ca::1</serverv6>
  <clientv6>2001:470:1f18:ca::2</clientv6>
  <routed64>2001:470:1f19:ca::/64</routed64>
 </tunnel>
</tunnels>auto he-ipv6
iface he-ipv6 inet6 v4tunnel
        address 2001:470:1f18:ca::2
        netmask 64
        endpoint <IP_ADDRESS>
        local <IP_ADDRESS>
        ttl 255
        gateway 2001:470:1f18:ca::1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:02 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:03 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:04 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:05 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:06 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:07 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:08 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:09 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:10 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:11 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:12 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:13 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:14 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:15 --:--:--     0


Papers, Datasets that use this repo

Recently the paper for CulturaX a dataset utilizing text-dedup has been released.
I am sure there are many more including the stack.
Would it be valuable to have some mentions regarding these kind of use cases in the README.md?
I'll prepare a PR if there is interest.

@ChenghaoMou, maybe zenodo would be an option to you, so that researcher can cite you in their work using a DOI.

Citations and https://github.com/ChenghaoMou/awesome-data-deduplication have been created. Thanks for all the comments.


Component error with multiple Moon instances [v0.11.0]

Instantiating multiple Moon instances produces a cannot redefine property error on the component.
const Moon = require("moonjs");
require("./components/app.moon")(Moon);

...

new Moon({
    el: "#element-1",
    template: `<app/>`
});

new Moon({
    el: "#element-2",
    template: `<app/>`
});

Seems like the same instance of app is being used in both root instances.
Any tips?

This is a restriction that isn't documented (will be added in v1 docs), but basically, a component cannot have another component as it's direct child. This is because Moon cannot track both of them.
In this case, the root element will be replaced with a component, and there isn't really a way to handle this correctly. Should both components be kept? If the root component's data changes, how should it go about updating the DOM?
You need a wrapper element, like
<app/>
, to prevent the root Moon instance from sharing the same DOM element with the component.

@kbrsh Thanks for the explanation. I'm not sure if this addresses the error though.
FYI this works perfectly fine for me. According to your comment this shouldn't work?
const Moon = require("moonjs");
require("./components/app.moon")(Moon);

...

new Moon({
    el: "#element-id",
    template: `<app/>`
});

I tried putting in a wrapper for the component as below and am seeing the same error.
const Moon = require("moonjs");
require("./components/app.moon")(Moon);

...

new Moon({
    el: "#element-1",
    template: `<div><app/></div>`
});

new Moon({
    el: "#element-2",
    template: `<div><app/></div>`
});

More specifically this is happening in initComputed when it tries to define a computed property but somehow is doing it on an existing instance.

That's really weird. Are you sure data is a function is those components? (If you want helpful errors, be sure to use const Moon = require("moonjs/dist/moon.js") to load the development version of Moon).

@kbrsh You're spot on. Somehow when I read the docs I was under the impression this is where Moon differs from Vue. Turns out it's exactly the same...my bad. Closing issue now.

Haha no problem. The reason this is done is because Moon caches all options of components, including data. So when a new component is created, the same data property is shared. When a there is a function, the data of each instance is set to the output, instead of sharing the same data.


Massive refactor

This one got a little intense but I think it sets us up better for some future improvements.
Highlights:

observatory not really being maintained anymore so switching to listr for task reporting
Isolate more logic in the util folder. Task setup/running now much simpler and easier to test
Remove webpack and make it a dependency of the generated project
The generated webpack config now can build all the functions instead of just one. a CLI flag can be used to filter what is built by webpack.
Removes concurrency option. Might be nice to get this back at some point, but hard to do with how the new webpack config works.
Remove dependency on the entire lodash package.

Everything works here except run which needs a few tweaks. Ideally I can keep it backwards compatible while still supporting the new AWS lambda proxy style integration.

todo:

[ ] run test
[ ] run console output improvements

@southpolesteve Thoughts on this output formatting?


There is no links.

If you know obsidian, there is links like in Zettelkästen. It will be good if your app will open-source and free alternative to obsidian.

So, and it will be good if this app will have dark mode.

Hi @EndiFox
thanks for checking out the app and creating the issue, it's great to know that you're finding the app useful 😀
I will add dark mode very soon. I will see about adding links feature too in the future.
I want this app to be minimal and simple as much as possible instead of adding tons of features
but if you find app useful and want some other features, let me know as well.
I will definitely consider it 😀

Hi @EndiFox thanks for checking out the app and creating the issue, it's great to know that you're finding the app useful 😀 I will add dark mode very soon. I will see about adding links feature too in the future.
I want this app to be minimal and simple as much as possible instead of adding tons of features but if you find app useful and want some other features or encounter any bugs, let me know as well. I will definitely consider it 😀

I don’t want to say that you need to make a complete copy of Obsidian, do what you see fit, it’s just a little difficult without links
Moreover, the minimalism strategy is good, because I can offer an idea that I have not seen in any Zettelkasten program - multilink. This is when one link can refer to several notes at once
I have repeatedly encountered situations where there should be multiple links behind a link mask in Obsidian (for example, [[example|something]], where something is a link mask), and when several notes need to be applied at once for the same link context.

Hi @EndiFox thanks for checking out the app and creating the issue, it's great to know that you're finding the app useful 😀 I will add dark mode very soon. I will see about adding links feature too in the future.
I want this app to be minimal and simple as much as possible instead of adding tons of features but if you find app useful and want some other features or encounter any bugs, let me know as well. I will definitely consider it 😀

I don’t want to say that you need to make a complete copy of Obsidian, do what you see fit, it’s just a little difficult without links Moreover, the minimalism strategy is good, because I can offer an idea that I have not seen in any Zettelkasten program - multilink. This is when one link can refer to several notes at once
I have repeatedly encountered situations where there should be multiple links behind a link mask in Obsidian (for example, [[example|something]], where something is a link mask), and when several notes need to be applied at once for the same link context. And yea, thank you for this app.

thanks for the suggestions, I totally agree with you that it will surely improve user experience with the app.
I will defintely take a look on implementing this feature, thanks a lot!!


Upgrade Mixpanel Android SDK to 5.8.5

This upgrades Mixpanel Android from 5.6.8 to 5.8.5 which includes a number of fixes and push notifications enhancements.
https://github.com/mixpanel/mixpanel-android/releases

Not able to receive push notifications on Android at all after this upgrade


Declarations for shared library in Windows.

When trying to use cppformat in a shared library I have found that it does not compile in Windows (tested with MinGW32-w64). The reason for this is a lack fo __declspec(dllimport) and __declspec(dllexport) declaration. This PR solves this issue: when compiling shared library, one needs to add definition FMT_EXPORTS and skip it when using the library.
I hope this small improvement can help to make this great library even better.

Thanks for the PR. I think this could be useful, but I have some comments/questions (above).

Concerning your comments, I have made several improvements to the patch. I hope it will now allow to use cppformat as dynamic library in Windows.

Merged with very minor adjustments in https://github.com/cppformat/cppformat/commit/1cba0aea27915c06192b47f2d4429c8ddaad3aa8. Thanks for contributing to the library!


Bitfinex order failures

I have setup blackbird with Bitfinex + Gemini. The buy orders in Gemini are executed right however short sell orders in Bitfinex fail with the following error message :

 Trying to send a "sell" limit order<EMAIL_ADDRESS> Error with response: This pair cannot be traded on margin.
 Done (order ID: 0)
Waiting for the two orders to be filled...
Done
WARNING: 9 second(s) too late at 05/14/2017 17:22:51

I get the same thing too. Are you in the US? That's likely the reason.

Yes. I am in the US.

Indeed: link here.

placing an "exchange limit" order works in the US still.  "limit" order points to the margin account.

Yes @nborggren, but you won't be able to margin trade with exchange limit orders.


Without quotes within class tag challenge still works

Challenge Create a Bootstrap Row has an issue.
User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
My code:

jQuery Playground

When I submit this challenge, it is successful, but I think there should be quotes ("") around "row", right? I think it should not work without this quotes. Possibly a bug?

Is this happening only with class=row, or are you noticing it with multiple classes?

I actually went back and tested this - this bug also happens in the next lesson as well: Split your Bootstrap Row
The challenge accepts this as an answer:

jQuery Playground

It seems like the regex might possibly be only looking for the classes as strings, not accounting for the wrapping quotes.
I only tested the next lesson, but is this happening across all challenges?
Anyone else care to chime in?

Most of our HTML/CSS tests are not done with regex but by looking for the given piece of HTML/CSS with jQuery. The reason this works is because it's perfectly valid HTML. Best practice is to include quotes all the time, but if there's no spaces in the thing you're assigning to that attribute they're actually not required. Thanks and happy coding!

Wow, i didn't know that! Thanks @ltegman!

Wow, i didn't know that! Thanks @ltegman!


Use cvxpy for quadratic programing?

Hi, I wonder if cvxpy can be used for modeling quadratic programing and how to fomulate it . For instance, is there something like quad_form in cvx? or Can I express qp into a equavelent form? (in matrix form)
Thank you very much

@echu Could you please expand a bit on what is ||Ax||^x? Does || . || mean the norm of matrix-vector product?
Can I do this quadratic from to Cholesky decomposition to put it as constraint?
So far, when trying to put quadratic form xPx as a constraint gives me DCPError: Cannot multiply two non-constants.

There is an atom called quad_form now.


Please Merge Ebeam_C_Adikarige.gds

your second design 'openEBL_CAdikarige.gds' does not have opt_in labels. Please add unique labels and change the name to EBeam please. Thanks! Also, if you could de-embed  the MZIs in the cascaded filter it'd be useful later analyzing the data.

Hi, I don't want to use the older design, i changed them in the new one which does have the opt-in labels. I'm not sure what is a cascaded filter? are you talking about making imbalnce bigger and spiral like?

Error checker says:
Error: opt_in label: missing: Automated test opt_in labels are required for measurements on the Text layer.

read the error messages:
https://github.com/SiEPIC/openEBL-2024-05/actions/runs/9140955668/job/25134881026?pr=152

read the error messages: https://github.com/SiEPIC/openEBL-2024-05/actions/runs/9140955668/job/25134881026?pr=152

Hi, I'm pretty new to github, i think it keeps asking about the older file which had no opt in labels. I only want to submit the new one with the fixes called "C_Adikarige_final". Its uploaded in my own repository but i dont see it in submissions in the main. I also cant seem to delete the old one.


Add apache-bench image for testing

The image includes the ApacheBench ("ab") HTTP benchmark utility program
from Apache. We actually install the entire apache2-utils package but we
only care about ApacheBench for testing. We may rename the image in the
future if appropriate.

/skip-e2e


Workshop

Think I might have got the connection & pull request to synch from my IDE.

@BigBossRabbit i am not involved with submissions but I will try and check with the organizers to see if they got yours

Oh, my apologies. I thought that I was supposed to submit it this way. Thank you for any assistance and for a wonderful project which has taught me a great deal about Bitcoin LN integration.

glad you found it useful!

I really did. Going to work at understanding how to replace the QR code with a Lightning Address integration, as I'm trying to learn how to do this on websites and almost any app through practical examples.


15 vulnerabilities when installing

I see that some of the libs got updated a few weeks ago, but there was no release and there are still some PRs with dependency updates. I'll see if I can solve some of them?

This is concerning, is there a plan to keep on top of security vulnerabilities in consumed packages? As @Florian-Schoenherr  points out, the security issue relating to trim-newlines was fixed nearly three months ago now and no release has been made.

It's been almost 3 months and there's still 15 vulnerabilities, I wanted to develop a few VS Code extensions (VS Code uses yo to create a new extension project), but I'm a little concerned after seeing 15 vulnerabilities and a few deprecated warnings

I have same issue


Read an account from the service

As a developer
I need to read customer account details from the service
So that I can fetch specific customer information by their ID
Details and Assumptions:
The database has existing customer data.
Endpoint: GET /customers/{id}.
Acceptance Criteria:
Given a customer with ID exists, when I send a GET request to /customers/{id}, then I receive the customer's details in the response.
Given a customer with ID does not exist, when I send a GET request to /customers/{id}, then I receive a 404 error response.


Fatal error: Maximum execution time of 30 seconds exceeded in sentry-php-master/lib/Raven/Serializer.php on line 73

Hi, I'm not sure what causes this error. Maybe a cyclic reference in an object?

The line reported in the error may not be the culprit itself, it's just the line where the script stopped due to a timeout.
Cyclic references shouldn't matter here, since the serialize() method has a max dept argument. If you didn't alter the limit, the only possibility is that you were serializing a very large object.

Indeed it was a very large object caused by another bug. Let's close ticket unless you think there should be a sane limit to the size of the object serialized.

I am not sure if there is very much we can do about is unless indeed limiting it. However that would also depend on how big you memory limit is and if the error we are dealing with is an memory limit error since there will be less memory available.
IMHO this is an edge case, but happy to discuss ideas on how to prevent this possibly if needed.