14:17 <stellar-slack1> <alexmelges> I generated a seed/key pair directly from stellar core and sent some lumens to this adress using the website’s account viewer. I entered the new account and everything appears to be fine. What happened here? Does the account viewer checks for the existence of the account, and if it doesn’t exist, it creates one? Or the Create Account operation is actually a genseed followed by a payment operation?

14:19 <stellar-slack1> <bartek> account viewer is checking whether the destination account exists and depending on it's state it submits create_account or payment operation.

14:19 <stellar-slack1> <alexmelges> ok, thanks!

16:10 <stellar-slack1> <influx6> Anyone got a good link about stellar-core API and the ideas?

16:10 <stellar-slack1> <influx6> Have not yet fully grasp the whole view of the API

16:12 <stellar-slack1> <bartek> @influx6: in most cases you won't connect to stellar-core directly. you will use horizon and here's it's full API reference: https://www.stellar.org/developers/reference/

16:12 <stellar-slack1> <jed> https://www.stellar.org/developers/learn/ Stellar-core doesn't have much of an API. it basically writes to a DB and you use horizon as an API server with that link bartek posted

16:13 <stellar-slack1> <influx6> Ah! Cool.

16:13 <stellar-slack1> <influx6> Thanks will definitely check it out.

16:13 <stellar-slack1> <influx6> A few ideas bubbling!

18:07 <stellar-slack1> <bartek> I created this sample SQLite DB so you can test federation server (for fun or in your integration tests) with a minimum effort: https://github.com/stellar/federation#sqlite-sample simply download a binary and db file, copy the config file from the README and start the server.

18:10 <stellar-slack1> <scott> +1

18:10 <stellar-slack1> <scott> nice

18:41 <stellar-slack1> <jlin> I've been running the tests for stellar-core (make check in INSTALL.md) on os x 10.11. At first there was a syntax error in selftest-pg that was incorrectly setting up postgres, but once I found out how to fix that - there was a test that failed in util/TimerTests.cpp (the timer cancels test) - what's a good way to ask someone if this is expected/known, or if it's something weird with the way I have my enviro

19:00 <stellar-slack1> <jed> jlin: was the first problem an issue with the instructions?

19:00 <stellar-slack1> <jed> Someone else reported an issue with the TimerTests. It is on our list to investigate.

19:07 <stellar-slack1> <jlin> the first one was an issue with the sed script in line 29 of selftest-pg - my shell complained that there was extra characters after the q command. I ended up just removing the "q" and the script started working

19:08 <stellar-slack1> <jlin> rather line 28 sorry

19:25 <stellar-slack1> <powderfan> @eno: resolution of `1EGeCvza3PuBo5hSGiG8fqidGY4iAMVYre*http://naobtc.com|naobtc.com` works fine now However as you require the memoType `id` I have some trouble building the memo out of the federation response. `StellarSdk.Memo.id(federationRecord.memo)' throws error `Expects a int64 as a string. Got 100001`

19:26 <stellar-slack1> <powderfan> ah ok it wants a string.

19:27 <stellar-slack1> <powderfan> Is the client supposed to do the conversion or should federation server already return a string so that clients don't have to take care?

19:42 <stellar-slack1> <powderfan> ok, the trx passed with the id converted to string before sending! If you look at https://horizon-testnet.stellar.org/transactions/3f83cc667bef89875c425b6298aa57e9fce19d128371df308de8ca0c0c8bda33 it seems thoug to be stored as string in stellar core. If that is true, then I don't see the whole point in the different memo types. Or is it just horizon displaying it as string?

19:42 <stellar-slack1> <jed> scott shouldn't the js-sdk accept either ?

19:43 <stellar-slack1> <jed> that is just horizon displaying it as a string

19:43 <stellar-slack1> <jed> it is an int in the core

19:43 <stellar-slack1> <powderfan> ah ok perfect

19:43 <stellar-slack1> <scott> yeah, we should accept either a number or a string of digits for an ID memo. The memo support in our libraries aren’t fully baked IMO

19:44 <stellar-slack1> <jed> ok I'll add an issue

19:44 <stellar-slack1> <scott> thanks

19:44 <stellar-slack1> <powderfan> yeah thanks!

20:09 <stellar-slack1> <graydon> jlin: I'm curious about the compiler and stdlib you're seeing the timer failure on

20:09 <stellar-slack1> <graydon> jlin: (I mean I can see a way it can possibly fail if the ordering isn't stable, it's not happening here, but that's possibly due to my using a new clang or libc++)

20:10 <stellar-slack1> <graydon> jlin: are you using g++ by any chance?

20:17 <stellar-slack1> <graydon> (or more to the point, libstdc++ rather than libc++?)

20:17 <stellar-slack1> <graydon> (totally no trying to shift blame; just trying to reproduce it so I can be sure I fix it!)

21:05 <stellar-slack1> <jlin> graydon as far as I know i'm using Apple LLVM version 7.0.2 (clang-700.1.81)

21:06 <stellar-slack1> <graydon> ok. well, I have a sort of .. forcibly-corrected version I can post if you want to give it a try. I still can't actually reproduce it but this should eliminate potential problems in event ordering.

21:07 <stellar-slack1> <jlin> thanks I'll be off line for a bit - back later on. I can post the actual error message if there's a better way / github issue? what's the prefered tracker?

21:08 <stellar-slack1> <graydon> https://github.com/stellar/stellar-core/pull/975