<stellar-slack1>
<lab> thank you for jed's double check.
<stellar-slack1>
<lab> i miss read it
<stellar-slack1>
<lab> so the minimal for failure safty 1 is still 4.
<stellar-slack1>
<lab> :$
<stellar-slack1>
<jed> yeah
TheSeven has quit [Disconnected by services]
[7] has joined #stellar-dev
nivah has quit [Ping timeout: 260 seconds]
de_henne has joined #stellar-dev
nivah has joined #stellar-dev
bit2017 has joined #stellar-dev
bit2017 has quit [Max SendQ exceeded]
bit2017 has joined #stellar-dev
nivah has quit [Ping timeout: 255 seconds]
stellar-slack1 has quit [Remote host closed the connection]
stellar-slack has joined #stellar-dev
bit2017 has quit [Ping timeout: 260 seconds]
pixelb has joined #stellar-dev
<stellar-slack>
<raymens> ``` struct ChangeTrustOp { Asset line; // if limit is set to 0, deletes the trust line int64 limit; }; ``` Seems to me there's no way to set a trustline's limit to *unlimited*?
<stellar-slack>
<raymens> Well, setting it to `MAX(int64)` is actually it's limit. Which is technically even more correct. But in this case the SDKs must know about the limits of the `int64` used in the core. Wouldn't it also be better if it was unsigned?
<stellar-slack>
<sacarlson> maybe expecting debt as well as positive assets?
<stellar-slack>
<sacarlson> but the number is big enuf that's for sure
<stellar-slack>
<raymens> Could be yeah
<stellar-slack>
<gleb> Hey guys, could you help with a pretty simple question: [Create Account](https://www.stellar.org/developers/learn/concepts/list-of-operations.html#create-account) method expects the ID of a new account as a parameter, so that ID should be generated before calling the create account. Is that part covered by the docs somewhere? What is the proper way to generate new keys?
<stellar-slack>
<sacarlson> var new_keypair = StellarSdk.Keypair.random();
<stellar-slack>
<sacarlson> but it's in german, what did it do charge there stellar account from that rist strap id?
<stellar-slack>
<dzham> danish actually… Not sure what they did, but you should hook something like that up to accept BEER
robins has joined #stellar-dev
robinsmidsrod has quit [*.net *.split]
pixelb has quit [*.net *.split]
ggherdov` has quit [*.net *.split]
robins is now known as robinsmidsrod
pixelb has joined #stellar-dev
ggherdov` has joined #stellar-dev
zz_akuukis is now known as akuukis
<stellar-slack>
<brian.ebert> My eventsource stream watching payments stopped working on testnet. Is anything changing over there?
<stellar-slack>
<donovan> Well, I had a lot of fun learning about recursive descent parsers and playing around with code generation, but I’m going to have to admit defeat and conclude that XDR matched with complex nested structs and unions is a poor match for the Go language, which is a shame. It feels like XDR is almost too dynamic and powerful, being a subset of C, and this makes it difficult to efficiently map to the static typ
<stellar-slack>
languages (with the possible exception of Rust!), which perhaps explains why there is so little available tooling for it after it has been around for so long. If I’d had a say early on, I’d have voted for Canonical JSON (i.e. sorted keys) with well defined validation rules for each type. A bit of decoding/encoding inefficiency traded for simple human readable/creatable messages that would probably compress just a
<stellar-slack>
below is the PEG grammar I came up with. The main problem was processing the AST to generate a sane Go type system that respected the multiple layers of nested structs and unions.
<stellar-slack>
<scott> @donovan: I’m curious, did you do any exploration around representing a union as an interface where each value the union could contain was a separate type? This would allow, for example, the use of `switch` and type assertions for a more idiomatic feel.
<stellar-slack>
<scott> @brian.ebert: I wouldn’t expect your script to start failing, although code did get released on friday to testnet. Could you provide some more context? How is it failing? Any error messages in your js console?
<stellar-slack>
<donovan> Yep, but if you had an interface for each union, you’d need to extract the common fields from each nested struct to make it any better that an anonymous interface{}. In fact there are very few common fields between most of the Stellar message that use unions.
<stellar-slack>
<scott> better than `interface{}` in what sense? ease of use?
<stellar-slack>
<donovan> Well you can do ```type PaymentResult interface{}``` and then you know a value is a PaymentResult, but if you want the fields for the particular type, you’ll still have a do another type switch to get the subtype and its fields.
<stellar-slack>
<donovan> In other words, Go interfaces work well when there is shared functionality between types.
dobson has quit [Ping timeout: 240 seconds]
<stellar-slack>
<donovan> TLDR: Stellar makes possibly too much use of "dynamic nesting”.
<stellar-slack>
<scott> In this instance, I imagine an interface not be used to provide shared functionality, but rather to inform what underlying types that can be assigned to a union of a given type
<stellar-slack>
<monsieurnicolas> Also, you could imagine having PaymentResult be a specialized derived class from the generic one, if you really wanted strong typing
<stellar-slack>
<scott> so, you can do something like `var x OperationBody = CreateAccountOp{}` and have it work
<stellar-slack>
<scott> (OperationBody being the nested union type for the field `body` on the `Operation` struct)
<stellar-slack>
<monsieurnicolas> I think the problem is that we're using anonymous structs in some places
<stellar-slack>
<donovan> Asset is common to two types of PathPaymentResult, but there are 13 different possible types :)
<stellar-slack>
<scott> So your concern is against the use of tagged unions, not necessarily XDR?
<stellar-slack>
<donovan> Another way of looking at it is that there are much more efficient ways of structuring the messages that cannot be derived from the XDR definitions.
<stellar-slack>
<donovan> Well, tagged unions are the part which could map to Go interfaces, but don’t, given their usage in Stellar.
<stellar-slack>
<scott> The core guys can probably answer with more authority, but I don’t think efficiency of structure was high priority, instead (IMO at least) choices were made to prioritize explicitness of the messages. i.e. the fewer implicit rules needed to validate or interpret messages correctly, the better. Rather than having a shared `Asset` field on a struct that is only valid when another field contains a certain v
<stellar-slack>
enforce that validity, we use tagged unions to do the work for us.
<stellar-slack>
<donovan> Well, that would make perfect sense if there wasn’t also optional pointer fields present in the messages :) I guess a decision has been made to combine canonical encoding with message validation. In my opinion, it’s easier to separate the two out… I’d be willing to place a wager that if stellar-core hadn’t been written in C++, XDR wouldn’t have been top of the serialization format list :) Anyway
<stellar-slack>
<scott> :) sure! Yeah, I’m not trying to argue, just trying to understand where your thoughts are. We’re hitched to the XDR wagon, so it’s my goal to make it as pleasant as possible and am trying to gather insight from anywhere I can :)
<stellar-slack>
<brian.ebert> @scott: I instantiate the event source with this code:
<stellar-slack>
<brian.ebert> but readyState remains 0
<stellar-slack>
<brian.ebert> This was connecting reliably before.
<stellar-slack>
<brian.ebert> Also, over the weekend I asked where I should set the option Accept: 'text/event-stream' when using a stellar-sdk payments endpoint. I'd still like to migrate to that interface. Where should that command go when opening the sdk payments endpoint?
<stellar-slack>
<scott> I’ve got to head into a couple of meetings… I’ll be back in a bit.
<stellar-slack>
<brian.ebert> OK. Another datum for you: I added an sdk payment endpoint call and when I did I got a 404 error.
<stellar-slack>
<brian.ebert> It's behaving as if friendbot isn't funding the account.
<stellar-slack>
<scott> aright, I’m back. Regarding friendbot… it looks like it got drained. I’ll refund it shortly.
<stellar-slack>
<scott> alright, friendbot is funded again.
<stellar-slack>
<scott> @brian.ebert, regarding your other question: All of the “call builder” objects support a `stream()` method to get a streamable response from horizon. Let me write up a little example for you
<stellar-slack>
<brian.ebert> @scott: Thank you. It looks like the .stream() method call replaces the .call() method in the example on https://www.stellar.org/developers/horizon/reference/payments-for-account.html. Am I correct? Can the attributes in your example be left empty and replaced with .then(function(p){console.log(p);}) and .catch(function(err){console.error(err);})? Is the server class documented somewhere? I've been