On 30 Aug 2011, at 19:24, Alex Chaffee wrote:
> ...or grabbing and reassigning $stdout and $stderr, which is what
> "capturing" does.
>
> The basic idea is that Ruby is *already* decoupled from stdin/out/err
> via its dynamic nature and $globals. I get that by naming the inputs
> explicitly you'
> I've found this pattern useful as now that only files in my bin/ folder ever
> access ARGV, STDOUT etc, the code is more loosely coupled, but also I can see
> exactly where I'm talking to the outside world. Every time I want to send
> some output, I think- "Should I really be giving this objec
On 30 Aug 2011, at 14:45, Nikolay Sturm wrote:
> A single guard process is enough, it will start all guards defined in
> your Guardfile.
I did not know that! I'm still new to Guard, a recent convert from Autotest.
Thanks for the tip.
Cheers
Ash
--
http://www.patchspace.co.uk/
http://www.link
* Ash Moran [2011-08-30]:
> I never thought of that! Yes, that could also work, probably better in
> fact. It just involves running multiple Guard processes, although
> there's Terminitor[1] for that!
A single guard process is enough, it will start all guards defined in
your Guardfile.
cheers,
N
On 30 Aug 2011, at 07:01, Nikolay Sturm wrote:
> I have a similar situation with the slow specs being integration specs
> in a special directory. I tagged all those example groups and setup two
> guards. The first is for unit tests and ignores all examples tagged
> 'integration' and doesn't watch
On 30 Aug 2011, at 00:09, Alex Chaffee wrote:
> I do. So often that I wrote a helper and put it in Wrong.
Cool, and also… I really should try Wrong! I've just put it on my project TODO
list as something to investigate
> I don't quite get what "stream_bundle.captured_error" is in your
> example
