00:55 <stellar-slack1> <jed> stellar-core on testnet was just reved to the latest master

00:55 <stellar-slack1> <jed> if you have a node connected to it you will have to upgrade it

00:56 <stellar-slack1> <jed> sacarlson ^

00:59 <stellar-slack1> <sacarlson> ok will do

02:35 <stellar-slack1> <lab> it's 0.3.0

04:07 <stellar-slack1> <jed> Lab live network can't go to it yet

04:07 <stellar-slack1> <lab> i saw overlay protocol changed

04:08 <stellar-slack1> <lab> we need an forcescp party again. :)

04:18 <stellar-slack1> <jed> Yeah Wednesday morning if all goes well

04:23 <stellar-slack1> <lab> ok. i will be ready for that. and it's also time for validators from sdf quit.

04:35 <stellar-slack1> <jed> Yeah

06:37 <stellar-slack1> <richiela> two really quick dumb questions... A) there is no real concept of confirmations with XLM now? We used to check valid or something. Are transactions on the chain good when we see them? B) there is a fee of "100" for each transaction.. what units is that in?

06:46 <stellar-slack1> <sacarlson> the fee of 100 is in stroops that is equivalent to XLM 0.0000100

06:50 <stellar-slack1> <sacarlson> for the transaction valid part I originally thought it was valid when I got a transaction valid return . but I'm a bit mistified by the meta data that I have been overlooking

06:52 <stellar-slack1> <sacarlson> if we checked the transaction 20 sec later and the balance was still there I guess we should be very confident as that time enuf for about 4 ledger updates

06:57 <stellar-slack1> <lab> 100 stroops (1 stroop = 1e-7 XLM)

11:59 <stellar-slack1> <raymens> @scott: is the inner type (e.g. int64 instead of Int64, byte[] instead of Hash) of the Discriminant known? (xdrgen)

12:08 <stellar-slack1> <raymens> or for any other member

12:44 <stellar-slack1> <powderfan> @bartek: It is solved for the moment. Think the above code was called too early (before cordova api has been fully initialized). Calling the same code again a little later works fine. So these are the tiny differences between browser and mobile webview. Thanks anyway!

15:10 <stellar-slack1> <regisg> I'm trying to submit a transaction to send a custom asset. The trustline is ok, but the transaction always fails. I've created a gist, if someone knows what's wrong with my code, any advice would be greatly appreciated. https://gist.github.com/Proxiweb/2e3df8c095203f72d543

15:31 <stellar-slack1> <jed> richiela: as soon as a tx shows up valid in a ledger you can trust it

15:33 <stellar-slack1> <raymens> @regisg: Not sure if it matters, but you can create refer to the asset like: `[:alphanum12, "PROXI", keyPairOfTheIssuer]`

15:33 <stellar-slack1> <jed> regisg:Yeah I think that is the issue. You can also add `console.log( transaction.toEnvelope().toXDR('base64') );` on line 20 and see what the blob looks like

15:34 <stellar-slack1> <jed> with https://stellar.github.io/xdr-viewer/

15:36 <stellar-slack1> <raymens> Lol, wish I had seen that xdr-viewer before :)

15:36 <stellar-slack1> <jed> https://www.stellar.org/developers/tools/ :)

15:38 <stellar-slack1> <raymens> Oh yeah now I remember I did see the mention, but as I use a direct connection to the core and not Horizon I didn't check it because it says: *Examine XDR messages that get returned from Horizon.*. My bad :(

15:38 <stellar-slack1> <fredolafritte> @regisg: the seed may be incorrect, try to use a local variable for the keyPair and display its address

15:38 <stellar-slack1> <jed> Ah good point we should change that

15:39 <stellar-slack1> <fredolafritte> also, don't forget to call `loadAccount` to get the sequence number

15:42 <stellar-slack1> <regisg> @raymens: just an array instead of new StellarSdk.Asset('PROXI',"GBR..") ?

15:43 <stellar-slack1> <raymens> @regisg: yeah, that's how it's done in the ruby-stellar-base examples too

15:46 <stellar-slack1> <jed> regisg: I bet `new Asset` defaults to alphanum4 and your code is too long

15:48 <stellar-slack1> <jed> regisg: put in that log line so you can see what it is generating out.

15:50 <stellar-slack1> <regisg> what's the js equivalent of ':alphanum12' ... it's not a string ?

15:52 <stellar-slack1> <jed> no it should be a string. It is just longer than the alphanum4

15:55 <stellar-slack1> <scott> @raymens: Provided the discriminant is an instance of `XdrGen::AST::Definitions::Typedef", you can call `resolved_type` to get the underlying type (it will work recursively if needed).

15:57 <stellar-slack1> <scott> the other subclasess for `Definitions::Base` don’t respond to that message, so you’ll have to check. Feel free to add stub definitions of `resolved_type` for the other subclasses to make things simpler if needed

15:57 <stellar-slack1> <raymens> @regisg: sorry it's not what I said. I've been spending too much time in the ruby SDK :P

15:58 <stellar-slack1> <raymens> @scott: I'll check, thanks. I've created a PR for my progress thus far at https://github.com/stellar/xdrgen/pull/20

15:58 <stellar-slack1> <scott> sweet! I’ll check it out today

15:59 <stellar-slack1> <bartek> @regisg it looks like you have outdated stellar-sdk, try to switch to the newest

16:24 <stellar-slack1> <regisg> @bartek : yes, it was outdated . I works fine now.

17:02 <stellar-slack1> <nelisky> I'm having some trouble setting options using python, so maybe you can help me out wrapping my head around what's expected:

17:03 <stellar-slack1> <nelisky> the XDR definition describes what is parsed as arrays of each option. Are the multiple options encoded as arrays of length 1? Is this used so they are optional?

17:05 <stellar-slack1> <scott> An optional field in XDR, when present in an struct being encoded, ends up encoded the same was a VarArray of length 1, yes

17:06 <stellar-slack1> <scott> it is used for optional fields, yes

17:06 <stellar-slack1> <scott> http://tools.ietf.org/html/rfc4506.html#section-4.19

17:09 <stellar-slack1> <nelisky> scott: ok, thanks. So there's no way around it, I'll have to wrap everything in lists :)

17:09 <stellar-slack1> <scott> I don’t understand the context. In our other languages we just use null

17:13 <stellar-slack1> <nelisky> that's the end result of the xdr parser we're using, I guess. The generated code looks like this:

17:15 <stellar-slack1> <nelisky> that's two problems in one, the check for None (should become empty array) and the size (bounded to 1, so it needs to come as an array even though it is a single optional value)

17:16 <stellar-slack1> <nelisky> I really don't want to deal with the code generation right now, so I'm fixing on the caller

17:16 <stellar-slack1> <scott> +1. That’s too bad in regards to xdrgen.py

17:16 <stellar-slack1> <nelisky> if I get the time I'll make it behave, just not now

17:20 <stellar-slack1> <nelisky> and now I get an invalid transaction, I wonder if the empty array isn't meant to be packed as a null value?

17:36 <stellar-slack1> <fim2> is the new stellar up and running?

18:02 <stellar-slack1> <scott> yep

18:02 <stellar-slack1> <scott> is there anything in particular you want to know about it?

18:02 <stellar-slack1> <scott> I’m happy to help

20:12 <stellar-slack1> <richiela> Ok we're finally done.. thanks for getting that bug fixed..

20:12 <stellar-slack1> <richiela> XLM back open here..

20:55 <stellar-slack1> <scott> +1

23:47 <stellar-slack> <garth> I am gearing up for another push with eQuid. I'm looking for help from a developer in the SF Bay Area. Dzham developed the first version and did an awesome job. Want to find someone local too. Let me know if you you are interested. Thanks.