[ts-gen] Event-Driven Programming in Ruby Downstream

Richard Pruss boadie at gmail.com
Mon Sep 14 21:40:24 EDT 2009


>  Others?

I am using
http://github.com/mattup/ruleby
to parse and drive events.

CLIPS is the mother of all these Rete implementations.
http://clipsrules.sourceforge.net/

And reading up on Rete might be interesting to you:
http://en.wikipedia.org/wiki/Rete_algorithm

On 15/09/2009, at 10:55 AM, Ken Feng wrote:

> Thanks to everyone's help on this mailing list, I am finally doing
> some real testing/debugging on a paper account.
>
> One outstanding design issue for me has been Downstream Ruby Event- 
> Handling.
>
> Just in Ruby, there appears to be many approaches:
>
> 1. popen3() and select() (recommended by Bill)
> 2. popen3() and threads (my current setup)
> 3. Ruby/EventMachine
> 4. Ruby/ruby-event
> 5. Others?
>
> My 2. approach appears to work okay for me, but I am not 100%
> confident (it's hard to be with threads) until I can test some more.
> I had to upgrade from 1.8.7 (green threads) to  2.9.1 (OS threads), as
> I was getting some strange interactions and reliability issues between
> threads and gets()  in 1.8.7.  2.9.1 seems to be working more
> reliably.
>
> I am currently investigating 3. and 4. - there are some posts on the
> EventMachine website claiming that a tightly-optimized asynchronous
> loop is much more efficient than using threads or processes.  More
> importantly, besides efficiency improvements, I believe the code can
> become much cleaner/easier-to-maintain with an event-driven framework.
>
> I think picking a good event-driven model will be crucial in the last
> stage where we all need to code for the dreaded "hung out in left
> field states" where the line drops, TWS/IB loses exchange connections,
> etc...  I am not there yet, but I can definitely envision the
> nightmare of trying to write readable/maintainable code for all the
> strange states that the downstream client may have to face, not even
> considering how to ensure that the code works as expected.
>
> When I find out more, I will share my findings on the list.
>
> - Ken
>
> Updates on Past Issues:
>
> (Aside #1: thanks to Bill's tireless efforts to post detailed
> descriptions of the shim architecture, it looks like I was able to
> implement my "poor man's OCA order" in the downstream Ruby layer.  My
> approach was to keep track of OCA tags in my own orders table.  Upon
> receipt of a full or partial fill, I would SELECT all 'var's which
> have same OCA tag as the filled order, excluding the row for the
> filled order itself.  I would then Cancel all those orders via the
> 'var' order_tag.
>
> Aside #2: for those of you interested, it appears to be possible to
> keep TWS/IB and Shim up reliably for an entire week.  I had to switch
> from "select bars" to "select ticks" for data as I had problems with
> the historical data servers, but so far, "select ticks" seems to work
> much more reliably.  I still haven't handled the case where IB's
> exchange servers go down due to DNS/routing problems, because I
> haven't seen a case recently.  However, overall, it looks like keeping
> TWS/IB/Shim up for a week is doable.)
> _______________________________________________
> ts-general mailing list
> ts-general at trading-shim.org
> http://www.trading-shim.org/mailman/listinfo/ts-general



More information about the ts-general mailing list