Stan's compiler doesn't build *under Windows* without optimization.
The problem with -O0 is that the debug info being generated blows
out the memory of their rather lame C++ toolchain. We've had to
implement several painful workarounds even to get the optimized
versions to compile under Windows.
None of the dev team uses Windows for development, so we use it
for our integration server just to make sure it's getting tested.
We're going to add continuous integration for Linux and Mac OS soon,
though it's never caused us a problem --- basically if something
can be made to work on Windows, it has worked everywhere else.
Everyone uses different debugging tactics. I'm still a fan of
debug-by-printf. I almost always find it easier than using
a step-through debugger. I do find debuggers really useful to
get a feel for the call chain in code I'm not familiar with.
I believe others use gdb, Xcode, and various memory profiling
tools for leaks. I think most of our profiling has been in Xcode,
though that's just because I don't know what the linux users use.
- Bob
> --
> You received this message because you are subscribed to the Google Groups "Stan users mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
stan-users+...@googlegroups.com.
> For more options, visit
https://groups.google.com/d/optout.
>