I added an issue at 
https://bitbucket.org/jendrikseipp/lab/issue/3/os-x-support. 
Let's continue the discussion there.

I think lab has a separate tracker; Jendrik will know.

It would be great then if lab could actually support Mac OS. Should we open 
another issue for that?

Hi Michael,

be warned that the new-scripts are being phased out. I think Jendrik would
rather delete them from the repository today than tomorrow. ;-)

If you still have a use case for them, maybe Jendrik can help you migrate to
another solution.

I do use new-scripts for relatively small local experiments, but I am okay with 
the work around.

Yes, I think this can be closed. Mac OS support in lab is by no means a priority, 
but if there's enough demand we can think about adding it.

We don't really use the new-scripts any more, so if anything, I guess this
should be a feature request for lab. Should we close this one?

Currently the new-scripts won't work on Mac OS X because the process group code
uses the /proc file system. It's possible to work around this, but at the cost
of less complete tracking of the time and memory limits. A correct solution
should implement the process group functionality properly for Mac OS.

Pasted from an email:
===========================================================================
Ah, the processgroup stuff. That was something I developed for the IPC
whose purpose was to enforce overall time and memory limits also for
planners that spawn off various processes, since we had to make
absolutely sure that we don't end up swapping on the machines of the
Barcelona cluster. (The problem is that you can enforce limits only per
process, so if you set a ulimit of 2 GB, the planner can then fork off
ten processes which together use 20 GB of memory.)

Unless you added any features that cause forks, this stuff is basically
unnecessary in Fast Downward. If you drop it, you lose some
memory-usage-tracking info in the driver.log file, but that is not
usually parsed anyway.

Try the following:

In new-scripts/calls/call.py, change the line

    def wait(self):

to

    def this_method_is_unused(self):

so that it will use the wait method of the base class instead. This will
make the enforcement of time and memory limits less strict, but for Fast
Downward it should still work, at least as long as you don't run a
portfolio configuration.

===========================================================================