devyn changed the topic of #elliottcable to: yorickpeterse is undergroin
Sgeo has joined #elliottcable
fwg has quit [Ping timeout: 240 seconds]
<alexgord_>
hi cuttle!
vil is now known as vilhalmer
vilhalmer is now known as vil
wudofyr has quit [Ping timeout: 260 seconds]
wudofyr has joined #elliottcable
yorick has quit [Remote host closed the connection]
eligrey has quit [Quit: Leaving]
<joelteon>
there are minecraft griefing teams
<joelteon>
let's just all take a second to think about that
alexgord_ has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
<whitequark>
so much misguided thoughts about gcs
<whitequark>
it makes my brain hurt ><
<whitequark>
devyn: hi!
<devyn>
hi whitequark
<devyn>
joelteon: Stephen Harper: "I AM YOUR FATHER!"
<devyn>
er,
<devyn>
jeannicolas:
<devyn>
you know what just forget it
<devyn>
>_<
<whitequark>
devyn: wanna continue?
<devyn>
whitequark: not tonight. I'm really tired; didn't get a great sleep and spent all day slaving over a hot postgres
<whitequark>
oh, sure
<devyn>
tomorrow
<devyn>
if you want to continue though, go ahead
<devyn>
maybe you could make a stream out of my indicators
* devyn
shrugs
<purr>
¯\(º_o)/¯
<whitequark>
I've been thinking more of two different fixes
<whitequark>
first, I still want to try the idea where units of measurement are added as phantom types
<whitequark>
second, I wanted to implement BTC-e's private API
<devyn>
first is cool, but I don't think the second is very high priority right now
<devyn>
we've got lots more to do before we're ready to start actually doing any trading
<whitequark>
well, technically, I already implemented serializing/deserializing, it's the easiest part
<whitequark>
it's more about being able to store account history, and, as a side effect, having a design to base mock accounts at
<devyn>
ah, ok
<whitequark>
what else comes to your mind?
<devyn>
getting an actual trading pipeline in with lua scripting as glue?
<whitequark>
heh, well
<whitequark>
I've been thinking about that as well. more specific tasks which need to be done:
<whitequark>
1) mock accounts, complete with history and order processing and some nice way to update their state manually
<whitequark>
2) event streams to have some results to display. they would need to integrate trading history and arbitrary output from the algorithm, and maybe more things
<whitequark>
3) ... well, duh, Lua API. I haven't even started on that
<devyn>
okay
<devyn>
just making sure we're not getting sidetracked, I mean
<whitequark>
we really need a nice interface, though
<devyn>
definitely
<devyn>
I want a better monospace font for it >_<
<devyn>
:p;
<devyn>
no, but really, we should have good event logging and stuff
<devyn>
we should be able to see exactly why the algorithms we script did what they did
<whitequark>
of course
<whitequark>
see, this is my personal issue
<whitequark>
I can do literally whatever you can imagine for the backend
<whitequark>
but I suck at guis :p
<devyn>
haha
<devyn>
honestly I can get equally stuck on either
<whitequark>
mhmm
<whitequark>
talking about GUIs, what I would want to see in the frontend is:
<devyn>
and working where I do has improved my ability to do web stuff quite a bit
<devyn>
because, well, that's basically what they expect me to do
<devyn>
even though I didn't really have those skills before
<devyn>
lol
<purr>
lol
<whitequark>
1) a flexible way to overlay graphs
<devyn>
you mean user-customizable?
<whitequark>
I mean, it should be easy to overlay whatever data points I have either on the main candle chart, or on an auxiliary one
<devyn>
oh ok
<whitequark>
well, user-customizable in a way. the algorithm may want to display some data it has just calculated
<whitequark>
EMAs, StochRSI... there's no reason they should be special
<whitequark>
or reason they should only be implementable in ocmal
<whitequark>
2) similarly, any debug output an algorithm may produce should be both presented as a log and overlaid on the chart
<whitequark>
in form of event
<whitequark>
right next to actual orders it will give, which also should be presented as events
<devyn>
ok, I suggest then that we provide a way for the user to make new streams based on input stream(s)
<devyn>
and then any "stream" can be charted in any way the user desires
<devyn>
the streams would be of JSON objects, as they are now
<whitequark>
that is one way to do it, but I was thinking of another
<devyn>
and the user can just pick what bit(s) of the JSON object to satisfy the inputs of the chart
<whitequark>
if you've seen my stream transform function, it's a combination of map_list and fold
<devyn>
yes, that's what I'm talking about
<devyn>
not direct mapping
<devyn>
but mapping with internal state
<devyn>
I suggested this anyway :p
<whitequark>
I thought about writing it right when I first wrote the ticker generator :p
<whitequark>
but, anyway, what I'm saying is:
<whitequark>
the trading algorithm, as a whole, is semantically a stream transformer.
<whitequark>
it transforms the inputs, i.e. a single stream of timestamped data (more on that later) into a stream of (mainly) orders, but also chart data points, debug events, and such.
<whitequark>
you could probably define several algorithms and allow to route output of one to input of another
<devyn>
well yes, and I totally got why you suggested the graphical dataflow programming type thing
<devyn>
it makes sense
<devyn>
it just
<devyn>
isn't that nice to work with
<devyn>
so, we're going to still basically do dataflow
<whitequark>
tbh what I meant by graphical dataflow is that it would be a high-level overview
<whitequark>
inside the blocks you would have some kind of expressions
<whitequark>
not "Add" blocks "Sub" blocks etc
<whitequark>
oh, single stream. the framework takes care of synchronizing input streams. for each unique timestamp in the input data, the algo will receive *all* relevant inputs, even if some of them didn't change from the previous point of time
<devyn>
oh yeah, ok, I'm cool with that
<whitequark>
(that) what?
<devyn>
high-level graphical dataflow
<whitequark>
ah. yes, I think it totally makes sense to program blocks in Lua
<whitequark>
but honestly, it's up to you whether this will be, because there's no way in hell I can write that GUI element :p
<devyn>
I can do it if it seems like it'll be worth it
<devyn>
I do think that the debug stream and such shouldn't be explicitly routed though
<devyn>
more of a side-effect
<whitequark>
oh, of course
<whitequark>
it's still pure though, just routed specially
<whitequark>
also, this has another advantage
<whitequark>
I can enforce strong typing on block boundaries
<devyn>
well yeah, that's why I think it's worth it
<devyn>
helps organize things
<whitequark>
plus you could mix blocks in Lua with blocks in OCaml easily
<whitequark>
(though you could probably do this with just functions...)
<devyn>
I also think that the Lua block should only receive whichever inputs have changed simultaneously in one invocation
<devyn>
if it needs to keep previous data
<devyn>
even just the most recent
<devyn>
it should do that itself
<whitequark>
to minimize communication cost?
<devyn>
(say, if I route three outputs from the ticker stream to three inputs of my block, that would be a "simultaneous" update)
<devyn>
well
<devyn>
as much as I'd like to keep the JSON message from the ticker intact
<devyn>
it probably makes more sense not to?
<devyn>
idk
<devyn>
anyway, in this case it would get it all at the same time so it would effectively be the JSON message again
<devyn>
nah
<devyn>
I don't like that
<whitequark>
oh, you mean dissect the messages?
<devyn>
best to just do JSON messages
<whitequark>
yep
<whitequark>
though not really JSON, just... messages
<whitequark>
serializing/deserializing is currently the biggest cost in the bot
<whitequark>
30% of cpu time
<devyn>
well, "JSON"
<devyn>
as in
<devyn>
a JSONable structure
<devyn>
because that's quite compatible with lua
<devyn>
lua tables are basically JS arrays and objects combined, with less overhead
<whitequark>
hmm
<devyn>
whitequark: it's possible to go with lua "userdata" and have functions that pull it apart, but the API wouldn't be nearly as nice
<whitequark>
I'll be thinking about it
<devyn>
whitequark: looks like you can give userdata a metatable so it actually wouldn't be so bad; you could do ticker:high() for example instead of high(ticker)
<devyn>
by providing a static metatable with some functions in it
<devyn>
that operate on the structure
<devyn>
ticker:high() btw is equivalent to ticker.high(ticker)
<devyn>
basically there's no implicit self/this in lua
<whitequark>
ticker.high no ? :)
<devyn>
so : is syntactic sugar for "pass self as first parameter"
<devyn>
whitequark: well, ticker.high but I thought you wanted to avoid serialization
<devyn>
whitequark: ticker:high() would avoid serialization
<whitequark>
but incur method call costs...
<devyn>
then just serialize
<devyn>
:p
<whitequark>
well I'll check out how to best do it
<devyn>
ok, I'm goin' to bed
<whitequark>
o/
fwg has joined #elliottcable
fwg has quit [Quit: gone]
fwg has joined #elliottcable
alexgord_ has joined #elliottcable
Sgeo has quit [Read error: Connection reset by peer]
fwg has quit [Ping timeout: 246 seconds]
yorick has joined #elliottcable
fwg has joined #elliottcable
gazoombo has quit [*.net *.split]
gazoombo has joined #elliottcable
gazoombo has quit [*.net *.split]
gazoombo has joined #elliottcable
fwg has quit [Ping timeout: 252 seconds]
fwg has joined #elliottcable
gazoombo has quit [Read error: Operation timed out]
gazoombo has joined #elliottcable
eligrey has joined #elliottcable
fwg has quit [Ping timeout: 245 seconds]
fwg has joined #elliottcable
joelteon has quit [Quit: I'm out]
joelteon has joined #elliottcable
fwg has quit [Ping timeout: 265 seconds]
fwg has joined #elliottcable
alexgord_ has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<cuttle>
god i hate everyone
<cuttle>
i want to just stop interacting with people
fwg has quit [Ping timeout: 252 seconds]
alexgord_ has joined #elliottcable
<joelteon>
what do you guys think of ansible
<joelteon>
I think it's a really good idea with a really weird and unsettling implementation
alexgord_ is now known as alexgordon
Sgeo has joined #elliottcable
<cuttle>
joelteon: what's the implmentation
<joelteon>
well it's not really the implementation, i misspoke
<joelteon>
it's the people who implemented it
<joelteon>
they encourage passwordless sudo
<cuttle>
joelteon: go over the concept again?
<joelteon>
it's like chef, but only uses yaml
<joelteon>
which in a way is really alluring because it removes all the logic from the recipes themselves, and instead delegates it to modules/ansible itself