The open source thread

Discussion in 'Trading Software' started by bungrider, Mar 20, 2005.

  1. Saw these --


    ...and thought it would be key to have a thread on SW alternatives for those of us who can program and have found commercial software...unsatisfying.

    The other thing is if you have a free feed like IB, and aren't paying for quotes from somewhere else, like esignal, for instance, then you don't get ass-fucked by the exchanges getting billed 2x for market data fees.

    Anyone else have some links to open source SW for trading/charting ??
  2. Did you try this?
  3. IMHO one of the biggest impediments to open source trading platform on UNIX type systems (linux, Solaris, BSD etc) is the lack of available real time data feed.

    Interactive Brokers have been exemplary in supporting TWS on Linux, MAC etc, but the feed is still too limited eg 100 symbols (++ depending on commissions) and one day backfill in the upcoming release. Really what is needed is at least 500 bars of up to at least 60 minute intervals for for backfill (or some multiple thereof of higher frequency OHLCV data so that longer intervals can be constructed).

    I really don't know why IB can't provide say 500 symbols and this type of backfill, with some sort of billing structure depending on commissions. Unless you want full tick data, IB feed is probably better/faster/more reliable than any of the others. I'm sure that many customers would be agreeable to some sort of fee for extended facilities such as 500 symbols and sufficient history.

    If there are any other feeds that run natively on Linux/Solaris/BSD, I'd love to hear about them. I think Comstock has Java API, but it's too expensive.
  4. I had a quick look at eclipse trader. If any of the following comments are misleading, I apologise in advance.

    Overall it looks promising, but there is still a long way to go. The UI is quite nice, but it seems to be a kind of MDI arrangement. (I don't know anything about SWT so the terminology may be wrong). You don't seem to be able to move frames outside of the enclosing desktop frame. This might be OK for a single head display setup, but it's at best a nuisance on multihead displays and even worse for multihead displays that don't form a perfect rectangle eg comprised of monitors of different resolutions.

    There is only a handful of indicators provided. Not a big deal because most common indicators are fairly simple to code.

    All 'lower' indicators seem to plot on the price chart not on a subchart. I might have missed something here.

    No scripting etc, and alarms are very primitive.

    No Fib levels, if you believe in that sort of thing.

    Overall I think it's still has a long way to go.
  5. cable


    Here's a link to a similar thread from days of yore. Hope it helps.

    Not to sound rude, but it would be really nice if these guys could put their egos aside and work together on one really good trading app rather than multiple competing (and perpetually incomplete) efforts.
  6. You can find some source codes here It's not open source, but you can view some source codes anyway.

  7. i think quantlib also has a project page..
  8. Josh_h34


    Found it at
    It looks exactly like the thing I've been looking for.
    Now if can only find a fast c++ api to port my Java application to my new sun blade 2500/solaris10 workstation I'd be really happy. Java as it turns out is far too slow for what I am trying to achieve.
    I am looking for bounded realtime responsiveness and a c++ api that fulfills that requirement by design.
  9. I'm not saying Java isn't too slow for what you are doing, but I'm curious to know in what respect Java is too slow. I'll grant that Java start up times are excessive and Swing is undoubtedly slower than native GUIs but in some respects Java benchmarks as well as C++.

    As for bounded realtime response, you need a realtime OS. Can't be done with normal schedulers in Unix/Linux/Win. I recall that Unix SVR4 had a realtime scheduling class which presumably found it's way into Solaris. Out of the box Linux also has some real time scheduling I think and of course there are realtime variants available. Seems like a lot of trouble to me though. You probably just need a 'fast enough' box.
  10. Josh_h34


    You're right that I want to avail myself of the realtime scheduling class on solaris.
    The reason Java can't cut it for me is because I reduced the periodicity of my bars from 15 min to 1 min, now I have to monitor complex breadth indicators on about 800 highly liquid issues once a minute and the time series became 180,000 bars long per symbol.
    That's 140MB of raw data, not to mention multiple other blocks of memory used for sorting, indicator data etc.

    With all due respect for Java which I like a lot it takes more than a minute to do the number crunching and make some sense out of the new data. Even a minute of number crunching is too long for processing 1 min bars.
    Rather than try to parallelize computations I opted for a high end workstation with lots of RAM and a fast vectorizing FPU and now I am looking to rewrite the code in c++ for speed.
    Hopefully compiler optimizations will cut the processing time to 30 seconds or less.
    What's the best c++ api out there for order entry and management?
    #10     Oct 10, 2005