<stellar-slack>
<nelisky> @scott: regarding the orderbook
<stellar-slack>
<nelisky> it might be a personal opinion, not necessarily a bug, but shouldn't bids and asks follow the same denominator asset? it seems to me they are switched, i.e. asks in CHP/BEER and bids in BEER/CHP.
<stellar-slack>
<nelisky> (or I'm reading the DB wrong)
<stellar-slack>
<sacarlson> no you are correct nelisky, that's looks to be another bug. I see they fixed the amount and price to be correct in ask but bids price looks to still have denominator and numerator reversed
<stellar-slack>
<sacarlson> price for ask in this case should have been 100 not .01
<stellar-slack>
<sacarlson> oh no I think I'm wrong as the base for ask i s CHP and the base for bids is BEER I guess they should be reversed
de_henne_ has joined #stellar-dev
<stellar-slack>
<nelisky> sacarlson: yeah, that's what I'm reading but I have a history of reversing the logic on trading :)
de_henne has quit [Ping timeout: 260 seconds]
<stellar-slack>
<sacarlson> well that spread doesn't make sense at .01 price but it seems like if they were asking 95 .15 and biding 100 that the transaction would have already fired but that were the base part comes in the some how reverses the bid and ask so there is a spread of 4.85 I think
<stellar-slack>
<nelisky> yeah, either ask is inverted of bid+base/counter are all inverted
<stellar-slack>
<sacarlson> but I'm sure it's a bug
<stellar-slack>
<sacarlson> and looks like the only real bug is the reversed denomiator numurator. I guess the format of the final data would fix the base part as I guess you never know what base the final product will be in
<stellar-slack>
<nelisky> eno: how did you generate the python files in stellarxdr/ from the stellar-core xdr sources? They are outdated, but the 'Generated by rpcgen.py' is proving to be quite elusive, as the only rpcgen.py I found is from scons and I can't find any reference to using it to generate python, the only python generating tool I found doesn't parse the files and I'm running out of ideas.
<stellar-slack>
<sacarlson> nellsky I guess one alternative is to use ruby that to me is a bit similar to python. ruby base as far as I know have updated xdr support from stellar
TheSeven has quit [Disconnected by services]
[7] has joined #stellar-dev
de_henne_ has quit [Remote host closed the connection]
de_henne has joined #stellar-dev
<stellar-slack>
<eno> nelisky i did it manually,merge all these .x files , remove the `namespace stellar` blockquote ,and using a mod xdrgen.py ,:) i will update these files shortly.
<stellar-slack>
<eno> sacarlson yes ruby is official supported , enjoy my envy
<stellar-slack>
<dzham> an exercise in futility on my part though, since it probably would’ve been twenty times faster just to type the bloody thing
<stellar-slack>
<powderfan> :D But it makes me feel good to see other developers interacting with my code. Thx for that!
stellar-slack has quit [Remote host closed the connection]
stellar-slack has joined #stellar-dev
nivah has joined #stellar-dev
dch has joined #stellar-dev
dch has quit [Changing host]
pixelbeat has joined #stellar-dev
Trasp has joined #stellar-dev
<stellar-slack>
<nelisky> sacarlson: I like ruby fine, and the fact I know python by heart only plays a small part on my decision in reality. I actively code in multiple languages at any given point and have coded in over 20 by my last count throughout the years, some more exotic than others. But moving to ruby means either interfacing between multiple languages or rewriting a huge amount of code I already have in python, and honest
<stellar-slack>
learning tool to just port things over to python.
<stellar-slack>
<nelisky> and everyone wins, as others wanting to do python will have better support for it, like I had a huge jumpstart from eno's code.
<stellar-slack>
<raymens> where is the python xdr code located?
<stellar-slack>
<sacarlson> I had to beat you ha ha
<stellar-slack>
<nelisky> but python has xdr parsing support natively and you can just use that with the xdr files from stellar-core (in theory, haven't tested)
<stellar-slack>
<nelisky> but mine was more complete :)
<stellar-slack>
<sacarlson> more complete but I'm not sure correct as I don't think it's an "official" python client or it's not from Stellar I should add
<stellar-slack>
<raymens> that's okay. I didn't know python had native XDR support.
<stellar-slack>
<raymens> Thanks for the link
<stellar-slack>
<nelisky> you are correct sacarlson, there's no official python client and there's no endorsement from sdf at all
<stellar-slack>
<nelisky> that's what the quoting is there for, "official" as in one that you will be pointed to if you ask around here
<stellar-slack>
<nelisky> but it can be misleading, sorry
<stellar-slack>
<nelisky> np, raymens
<stellar-slack>
<sacarlson> it's more like the "only" python base code
<stellar-slack>
<raymens> Well, official is overrated ;)
<stellar-slack>
<fredolafritte> Is anything changed in the way transactions are sent to horizon ? Some 2 month old code were fine but with the new horizon says the transaction is invalid: code and error message is available at https://gist.github.com/FredericHeem/1c87a24885c06a635c0e
<stellar-slack>
<raymens> It's an invalid transaction by design?
<akuukis>
dont know about JS SDK, but it looks that tx sequence number is missing
<stellar-slack>
<fredolafritte> it is invalid but well formed
<stellar-slack>
<fredolafritte> cannot send transaction with js-stellar-sdk either
<stellar-slack>
<jed> fredolafritte: source and dest of the payment are the same account
<stellar-slack>
<jed> that is the problem with the gist tx
<stellar-slack>
<fredolafritte> same issue when the destination is different
<stellar-slack>
<scott> @nelisky: The view from the order book is by design. It’s meant, for example, to directly drive a client view of the order book, where you want both bids and asks priced in the counter currency (i.e. the “buying” currency). If you can provide some specific examples where the numbers look off, I can look into it, but the numbers appear correct to me.
<stellar-slack>
<scott> If you have some specific concerns about the usability, or some use cases where this form makes it particularly hard to perform some type of integration, I would love to hear it. This is just a best first guess at what most clients will need for driving the dashboard for an order book.
<stellar-slack>
<scott> Horizon isn’t really meant to support hardcore traders, but more for light weight tools like the legacy stellar client had.
<stellar-slack>
<scott> (at the moment, that is. always happy to accept PRs that beef up its capabilities)
<stellar-slack>
<nelisky> @scott, like I said, it was more of an opinion (although the ask and bid do seem inverted, as the ask is smaller than the bid in the example provided and the match wasn't done)
<stellar-slack>
<nelisky> basically when I ask for a pair, I ask for the pair in the order provided, I'm going to put the example here once again so I can explain better:
<stellar-slack>
<nelisky> I ask for CHP/BEER and I get the single ask at 95.15, In other words someone is asking 95.15 BEER per CHP
<stellar-slack>
<nelisky> The single bid, however, is priced at 0.01, which would read to me as someone offering 0.01 BEER per CHP, but that's not what we have on the DB
<stellar-slack>
<nelisky> someone is actually asking for 0.01 CHP per BEER, so this format, while correct, seems misleading
<stellar-slack>
<nelisky> (I may have the ask/bid logic inverted, I do that a lot)
<stellar-slack>
<nelisky> what I would expect to see is both asks and bids follow the same rule, use the same denominator
<stellar-slack>
<nelisky> so that would read a bid of 100 BEER per CHP (which would trigger the deal)
<stellar-slack>
<nelisky> what I think the correct format is then: ask is 100 BEER per CHP and bit is 95.15 BEER per CHP, for base CHP and counter BEER.
<stellar-slack>
<nelisky> will be afk for a while now, but I'll get back to you soon
<stellar-slack>
<scott> so, I’d like to point out that if you need to reverse the view, simply reverse the buying and the selling assets in the order book url.
<stellar-slack>
<scott> second. stellar-core encodes an offer to trade always as “selling base currency for counter currency”. The only way to specify “buying base currency for counter currency” is to “sell” with the assets inverted.
<stellar-slack>
<scott> in that sense, there are only “asks"
<stellar-slack>
<scott> I’m curious, in what sort of ways do you think people will be mislead with this form of the order book? It mirrors how most order book views I am familiar with behave… could you provide an example of how things go awry?
<stellar-slack>
<scott> Also, you mention the ask was smaller than the bid in the example you provided. According to what you just posted, the price for the ask was 95.15, and the bid was 0.01… could you elaborate on why you think the ask was smaller?
<stellar-slack>
<jed> fredolafritte: you are still getting malformed tx when the destination is different? can you paste the xdr of the blob?
<stellar-slack>
<fredolafritte> the xdr blob is in the gist
<stellar-slack>
<jed> that is the malformed one though
<stellar-slack>
<fredolafritte> it works by changing {tx:input} in `tx=${input}`
<stellar-slack>
<fredolafritte> still scratching my head why it used to work with just {tx:input}
<stellar-slack>
<fredolafritte> `tx=${input}` fells really non standard
<stellar-slack>
<scott> @fredolafritte: the ruby version of horizon supported json bodies by default. We’ve yet to extend to go port with support. I have an issue for it here: https://github.com/stellar/horizon/issues/132
<stellar-slack>
<fredolafritte> actually, the error is now different
<stellar-slack>
<fredolafritte> data.extra. envelope_xdr is filled at least
<stellar-slack>
<jed> yeah you are sending to yourself still
<stellar-slack>
<fredolafritte> indeed ! but still the same error when src != dest
<stellar-slack>
<bartek> @fredolafritte: you have spaces in your XDR blob, see: ``` AAAAADm k/suXdZytiI6hNmCm5TCwn0nxA5ch13ckVDRoe6QAAAAZAAAAAAAAAABAAAAAAAAAAAAAAABAAAAAAAAAAEAAAAA V9IqctiDHOceOW92n6OcqAJcZzN/Ht11XW0KaK2WSwAAAAAAAAAAAL68IAAAAAAAAAAAdGh7pAAAABAtPikpJMOHsD6ugM72QBfmeOzWhWbnhqFU8FYuSruYHo ```
<stellar-slack>
<bartek> space after `AAAAADm`
<stellar-slack>
<fredolafritte> that's weird
<stellar-slack>
<bartek> is the code in that gist the latest version of it?
<stellar-slack>
<fredolafritte> right now, I cannot see the space after `AAAAADm`
<stellar-slack>
<nelisky> scott: sorry, I read the DB wrong, was operating under the assumption that the bid was 100 BEER per CHP when in fact it is 100 CHP per BEER, or 0.01 BEER per CHP, so all is correct
<stellar-slack>
<nelisky> thumbs up on the order book entry response, for what that's worth
<stellar-slack>
<bartek> ok, I know what's the problem. you need urlencode your xdr blob. it contains `+` signs which are converted to spaces. btw. I fixed a bug in js-stellar-sdk (which actually is axios bug) and new release should be there soon.
<stellar-slack>
<fredolafritte> wow, thanks a lot
<stellar-slack>
<bartek> use `encodeURIComponent` function
<stellar-slack>
<fredolafritte> the payload is not an URL, that's why I have yet to see a reason why the post payload has to be encoded
akuukis is now known as zz_akuukis
<stellar-slack>
<bartek> it is urlencoded form, content type you're sending is `application/x-www-form-urlencoded`
<stellar-slack>
<scott> Any post payload has to be properly encoded according to your request’s content type. The “+” in your request body has not being properly encoded to `%2B`, expressed by the fact the server is interpreting it as a space.
<stellar-slack>
<scott> Seems to me that this is an axios issue/misuse
<stellar-slack>
<scott> I would be willing to bet that if you inspected the raw http request that was sent to horizon that it’ll have a `+` in it
<stellar-slack>
<fredolafritte> so the payload has to be encoded twice, first base64 and then URI ?
<stellar-slack>
<scott> yes. horizon at present expects the transaction payload to be transmitted to it as base64, regardless of the containing http requests encoding
<stellar-slack>
<scott> I’d be happy to have it accept several different content types, but we haven’t developed that support yet
<stellar-slack>
<bartek> @fredolafritte: I would recommend using `stellar-sdk` so you don't have to deal with encoding stuff.
<stellar-slack>
<fredolafritte> indeed, that's what I'll do next since the bug in *stellar-sdk* is now fixed