Suraj N. Kurapati wrote:
I published the new rb_thread_create() & mailbox based
implementation to the project repository, but I'm seeing major
problems running it with NCSim and glitches with VCS.
The general issue seems to be that we have to be very careful where
we initialize the Ruby interpreter's stack. The previous
implementation worked pretty well because I initialized the stack
inside a pthread, so we were essentially shielded from the Verilog
simulator's choice of stack size / threading implementation.
I'm now trying to follow this technique to see if it solves the
problems running with NCSim and VCS and hopefully even VSIM.
I've been keeping an eye on the ruby-core discussions .. as far as I'm
concerned, you're a wizard and this is all more then a little bit black
magic ;)
I've been doing some playing around with Gecode/R as a constraint engine
and early results are pretty promising. It's nicely integrated into
the language, installable as a gem, and has a syntax that doesn't
require you to instantiate ">=" objects and other such sillyness.
Sounds good. I wonder how we will integrate this constraint engine
into the Test::Unit and RSpec libraries: will the engine supply
random inputs which can be verified by a specification? Or will the
specification invoke the constraint engine to do something useful?
I'm currently leaning more towards the latter approach. The
specification could use the constraint engine to generate 'random'
stimulus, perhaps via a .randomize! method on a self-contained
transaction/data object. The transaction object could contain a basic
set of constraints, and a specific test could inject additional
constraints by executing those constraints in the object's namespace.
That still leaves the issue of disabling constraints, which all but
requires the constraints to have names (from the Gecode/R examples I've
seen, constraints are anonymous expressions..)
--Mike
