shuf command not found

[Daniel Lee]

Ben,

I don't have shuf on my mac and it's not available for windows. Can you back out the changes?


Daniel

---------- Forwarded message ----------
From: <mc.sta...@gmail.com>
Date: Tue, May 7, 2013 at 2:58 PM
Subject: Build failed in Jenkins: Stan Unit Tests #841
To: stan-b...@googlegroups.com


See <http://d1m1s1b1.stat.columbia.edu:8080/job/Stan%20Unit%20Tests/841/changes>

Changes:

[bg2382] fix make/models for llvm-g++-4.2 on linux

[bg2382] shuffle function_signatures*.stan in test-unit

[bg2382] add more shuffling to make/tests

[bg2382] calculate average n_eff in rstan/example/demo.R

------------------------------------------
Started by GitHub push by bgoodri
Building in workspace <http://d1m1s1b1.stat.columbia.edu:8080/job/Stan%20Unit%20Tests/ws/>
Checkout:workspace / <http://d1m1s1b1.stat.columbia.edu:8080/job/Stan%20Unit%20Tests/ws/> - hudson.remoting.LocalChannel@1da9b274
Using strategy: Default
Last Built Revision: Revision a126c7fb4d5bac40b0d56e323c6ea518dab5454a (origin/master)
Fetching changes from 1 remote Git repository
Commencing build of Revision d097e74c84857602ad6a7986120da6e1db866854 (origin/master)
Checking out Revision d097e74c84857602ad6a7986120da6e1db866854 (origin/master)
Run condition [Time] enabling prebuild for step [Execute Windows batch command]
Time condition: evaluating [06:25] <= 2:58 PM <= [06:35]
Run condition [Time] preventing perform for step [Execute Windows batch command]
[workspace] $ cmd /c call C:\Users\daniel\AppData\Local\Temp\hudson2618294774869831683.bat

<http://d1m1s1b1.stat.columbia.edu:8080/job/Stan%20Unit%20Tests/ws/>make> clean-all
uname: not found
uname: not found
shuf: not found
shuf: not found
shuf: not found
make: shuf: Command not found
rm -f
rm -f
rm -f -r doc/api
cd src/docs/stan-reference; rm -f *.brf *.aux *.bbl *.blg *.log *.toc *.pdf *.out *.idx *.ilg *.ind *.cb *.cb2 *.upa
rm -f -r models src/stan/model/model_header.hpp.gch src/stan/model/model_header.hpp.pch src/stan/model/model_header.hpp.d
rm -f -r test bin doc
rm -f
rm -f src/test/gm/model_specs/compiled/*.cpp src/test/gm/model_specs/compiled/*.o src/test/gm/model_specs/compiled/assignments.exe src/test/gm/model_specs/compiled/assignments_double_var.exe src/test/gm/model_specs/compiled/assignments_var.exe src/test/gm/model_specs/compiled/declarations.exe src/test/gm/model_specs/compiled/dims.exe src/test/gm/model_specs/compiled/function_signatures1.exe src/test/gm/model_specs/compiled/function_signatures6.exe src/test/gm/model_specs/compiled/function_signatures7.exe src/test/gm/model_specs/compiled/function_signatures_bernoulli.exe src/test/gm/model_specs/compiled/function_signatures_beta.exe src/test/gm/model_specs/compiled/function_signatures_beta_binomial.exe src/test/gm/model_specs/compiled/function_signatures_binomial.exe src/test/gm/model_specs/compiled/function_signatures_categorical.exe src/test/gm/model_specs/compiled/function_signatures_cauchy.exe src/test/gm/model_specs/compiled/function_signatures_chi_square.exe src/test/gm/model_specs/compiled/function_signatures_dirichlet.exe src/test/gm/model_specs/compiled/function_signatures_double_exponential.exe src/test/gm/model_specs/compiled/function_signatures_exp_mod_normal_0.exe src/test/gm/model_specs/compiled/function_signatures_exp_mod_normal_1.exe src/test/gm/model_specs/compiled/function_signatures_exp_mod_normal_2.exe src/test/gm/model_specs/compiled/function_signatures_exp_mod_normal_3.exe src/test/gm/model_specs/compiled/function_signatures_exponential.exe src/test/gm/model_specs/compiled/function_signatures_gamma.exe src/test/gm/model_specs/compiled/function_signatures_gumbel.exe src/test/gm/model_specs/compiled/function_signatures_hypergeometric.exe src/test/gm/model_specs/compiled/function_signatures_inv_chi_square.exe src/test/gm/model_specs/compiled/function_signatures_inv_gamma.exe src/test/gm/model_specs/compiled/function_signatures_logistic.exe src/test/gm/model_specs/compiled/function_signatures_lognormal.exe src/test/gm/model_specs/compiled/function_signatures_multinomial.exe src/test/gm/model_specs/compiled/function_signatures_neg_binomial.exe src/test/gm/model_specs/compiled/function_signatures_normal.exe src/test/gm/model_specs/compiled/function_signatures_ordered_logistic.exe src/test/gm/model_specs/compiled/function_signatures_pareto.exe src/test/gm/model_specs/compiled/function_signatures_poisson.exe src/test/gm/model_specs/compiled/function_signatures_rep.exe src/test/gm/model_specs/compiled/function_signatures_rep_param.exe src/test/gm/model_specs/compiled/function_signatures_scaled_inv_chi_square.exe src/test/gm/model_specs/compiled/function_signatures_skew_normal_0.exe src/test/gm/model_specs/compiled/function_signatures_skew_normal_1.exe src/test/gm/model_specs/compiled/function_signatures_skew_normal_2.exe src/test/gm/model_specs/compiled/function_signatures_student_t_0.exe src/test/gm/model_specs/compiled/function_signatures_student_t_1.exe src/test/gm/model_specs/compiled/function_signatures_student_t_2.exe src/test/gm/model_specs/compiled/function_signatures_student_t_3.exe src/test/gm/model_specs/compiled/function_signatures_uniform.exe src/test/gm/model_specs/compiled/function_signatures_weibull.exe src/test/gm/model_specs/compiled/illegal_generated_quantities.exe src/test/gm/model_specs/compiled/illegal_transformed_data.exe src/test/gm/model_specs/compiled/illegal_transformed_parameters.exe src/test/gm/model_specs/compiled/mat_assign.exe src/test/gm/model_specs/compiled/print_chars.exe src/test/gm/model_specs/compiled/rngs.exe
cd src/test/agrad/distributions/univariate/continuous; rm -f *_generated_test.cpp
cd src/test/agrad/distributions/univariate/discrete; rm -f *_generated_test.cpp
cd src/test/agrad/distributions/multivariate/continuous; rm -f *_generated_test.cpp
cd src/test/agrad/distributions/multivariate/discrete; rm -f *_generated_test.cpp

<http://d1m1s1b1.stat.columbia.edu:8080/job/Stan%20Unit%20Tests/ws/>make> test-unit -j4 O=0
uname: not found
uname: not found
shuf: not found
shuf: not found
shuf: not found
make: shuf: Command not found
uname: not found
uname: not found
shuf: not found
shuf: not found
shuf: not found
make: shuf: Command not found
make: Nothing to be done for `test-unit'.

<http://d1m1s1b1.stat.columbia.edu:8080/job/Stan%20Unit%20Tests/ws/>exit> 0
[WARNINGS] Parsing warnings in console log with parser GNU Make + GNU Compiler (gcc)
Recording test results
No test report files were found. Configuration error?
Build step 'Publish JUnit test result report' changed build result to FAILURE

--
You received this message because you are subscribed to the Google Groups "stan-buildbot" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stan-buildbo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ben Goodrich]

Does your sort function accept the -R argument?

[Daniel Lee]

No.

--
You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.

[Ben Goodrich]

Damnit. I just reverted those two commits but we've got to figure out something.

[Daniel Lee]

Thanks.

[Daniel Lee]

Ben, Bob just reminded me that we've already instrumented make to detect OS. If you want to shuffle iff you're on linux, feel free to do so.


Daniel

[Ben Goodrich]

On Tuesday, May 7, 2013 3:54:23 PM UTC-4, Daniel Lee wrote:

Ben, Bob just reminded me that we've already instrumented make to detect OS. If you want to shuffle iff you're on linux, feel free to do so.

The RAM spikes are a problem for everyone who might want to run test-unit. I'm trying to come up with a portable solution.

Ben

[Daniel Lee]

Thanks. I didn't seen any builtin make functions, but we might be able to write one? That's beyond my make skills.

An alternative could be creating a permuted list once. Adding additional things automatically in alphabetical order (using filter-out, etc).

[Ben Goodrich]

On Tuesday, May 7, 2013 4:45:40 PM UTC-4, Daniel Lee wrote:

Thanks. I didn't seen any builtin make functions, but we might be able to write one? That's beyond my make skills.

An alternative could be creating a permuted list once. Adding additional things automatically in alphabetical order (using filter-out, etc).

I think the simplest portable approach would be to shuffle the .stan files under src/test/gm/model_specs/compiled/ once on the disk with a sequence of

git mv foo.stan XXX_foo.stan

operations where XXX is some unique identifier. It would probably be fine to choose XXX randomly for each .stan file, but it would be slightly better in principle to choose XXX optimally. Then the question becomes should it be optimized to balance across for 4 or 8 cores and how to keep it optimal when new .stan files are added to that directory. And I don't know how to answer those questions.

Ben

[Marcus Brubaker]

Wouldn't this make it hard (impossible?) to track down what model failed?

Any chance of us having access to python on Windows? It would be
trivial to implement a shuffle in python and use that.

[Ben Goodrich]

On Wednesday, May 8, 2013 4:51:19 PM UTC-4, Marcus Brubaker wrote:

Wouldn't this make it hard (impossible?) to track down what model failed?

Not as far as I can tell. After the transition, stdout would just say something like

[  FAILED  ] src/test/gm/model_specs/compiled/135_mat_assign

instead of

[  FAILED  ] src/test/gm/model_specs/compiled/mat_assign

It would still be human readible if said human just ignores the random (or not random) number prefix and there would be a src/test/gm/model_specs/compiled/135_mat_assign.stan file to investigate.
 

Any chance of us having access to python on Windows?  It would be
trivial to implement a shuffle in python and use that.

It is trivial in bash, and yet BSD bash manages not to have it. I wouldn't be opposed to requiring python or java or something to run the tests, but it is a pretty heavy dependency in the unlikely event the machine didn't have it already.

Ben

 

[Bob Carpenter]

On 5/8/13 5:11 PM, Ben Goodrich wrote:
> On Wednesday, May 8, 2013 4:51:19 PM UTC-4, Marcus Brubaker wrote:

...

> Any chance of us having access to python on Windows? It would be
> trivial to implement a shuffle in python and use that.
>
>
> It is trivial in bash, and yet BSD bash manages not to have it. I wouldn't be opposed to requiring python or java or
> something to run the tests, but it is a pretty heavy dependency in the unlikely event the machine didn't have it already.

It's not ideal, but I'd be OK with a Java or Python dependency
for *testing*, as long as it's a standard version of Java or
Python. I have both on my Mac.


Especially if the test could be isolated away from our
basic unit tests.

As long as it's fairly portable and not dependent
on some arcane version of Java or Python. Here's what
I have:

~/stan(master)$ javac -version
javac 1.7.0_07

~/stan(master)$ python --version
Python 2.7.3 -- EPD_free 7.3-2 (32-bit)

I'd rather not have to depend on the Enthought Python; mine
is set up this way in a failed attempt to load PyMC (I never
did resolve their Python/Fortran dependency.)

- Bob

[Ben Goodrich]

On Wednesday, May 8, 2013 5:25:14 PM UTC-4, Bob Carpenter wrote:

On 5/8/13 5:11 PM, Ben Goodrich wrote:
> On Wednesday, May 8, 2013 4:51:19 PM UTC-4, Marcus Brubaker wrote:
...
>     Any chance of us having access to python on Windows?  It would be
>     trivial to implement a shuffle in python and use that.
>
>
> It is trivial in bash, and yet BSD bash manages not to have it. I wouldn't be opposed to requiring python or java or
> something to run the tests, but it is a pretty heavy dependency in the unlikely event the machine didn't have it already.

It's not ideal, but I'd be OK with a Java or Python dependency
for *testing*, as long as it's a standard version of Java or
Python.  I have both on my Mac.

We could even call R to shuffle them, but I still think shuffling (possibly optimally rather than randomly) them once on disk is the better way to go. We don't really care about the randomness of the shuffle, except that it has the effect of lowering the maximum RAM spike.

Ben

[Ben Goodrich]

Shuffling aside, maybe it would be better to reconsider our RAM usage for models? Making a precompiled header out of model_header.hpp with g++ runs about 250M, which apparently isn't really helping with compilation speed because it contains so much material that any particular model doesn't use. Now that the functions are pretty much in their own separate files, how hard would it be for the parser to consult a lookup table to see what to #include based on what functions are used by the .cpp file?

Ben

[Daniel Lee]

I don't think that would actually help compilation time. We are slowed down by the interactions between our templates classes, boost, and eigen.

If you have a few minutes, want to generate a model, then only include the headers it needs? That would be the best we could do without breaking out the definitions, implementations, and template instantiations. If you don't have time now, I can add that to my queue. I just want a comparison including the full header and pieces. My guess is that they would be very similar. 

Daniel

[Bob Carpenter]

Probably not too hard. We'd need a table that maps functions
to sets of includes. Or we'd need special include files for
each function that were just indirections to other includes. That's
because we often need agrad and regular implementations of a function
and will soon have forward-mode, too.

But before taking that step, would you mind running a simple test
by hand to see if it saves any time in compilation? If it's substantial,
it'll totally be worth doing. But my experience is that each model
compiles fast UNLESS it involves hairy matrix ops. So I'm not sure this'll
save a lot of time.

- Bob

[Ben Goodrich]

We still have somewhat outdated compile times at

https://code.google.com/p/stan/wiki/SpeedResults

which are usually in the mid to high 20s for simple models and in the 80s or 90s for multivariate models. But it is not just about speed; it is also about RAM and making it so that test-unit can be done quickly with less than 8GB. I'll try to do a test, but it's hard to figure out what is the minimal set of #includes. The iwyu program yields subminimal results in the sense that the model doesn't actually compile if you replace model_header.hpp with what it thinks model_header.hpp should be replaced with.

Ben

[Ben Goodrich]

On Wednesday, May 8, 2013 8:04:25 PM UTC-4, Ben Goodrich wrote:

We still have somewhat outdated compile times at

https://code.google.com/p/stan/wiki/SpeedResults

which are usually in the mid to high 20s for simple models and in the 80s or 90s for multivariate models. But it is not just about speed; it is also about RAM and making it so that test-unit can be done quickly with less than 8GB. I'll try to do a test, but it's hard to figure out what is the minimal set of #includes. The iwyu program yields subminimal results in the sense that the model doesn't actually compile if you replace model_header.hpp with what it thinks model_header.hpp should be replaced with.

OK, attached is a modified version of the (pretty simple logit) oxford model from bugs_examples/vol1. It is not quite optimal because I had to just #include "Eigen/Dense" to avoid some mistakes that iwyu made that I didn't want to actually figure out today.

Comparing the compilation times only saved a bit less than a second

time clang++ -I src -I lib/eigen_3.1.3 -I lib/boost_1.53.0 -Wall -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -Winvalid-pch -Wno-unused-function -Wno-uninitialized   -c -O3 -o models/bugs_examples/vol1/oxford/oxford2.o models/bugs_examples/vol1/oxford/oxford2.cpp

real    0m15.517s
user    0m15.248s
sys     0m0.186s
goodrich@CYBERPOWERPC:/opt/stan$ time clang++ -I src -I lib/eigen_3.1.3 -I lib/boost_1.53.0 -Wall -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -Winvalid-pch -Wno-unused-function -Wno-uninitialized   -c -O3 -o models/bugs_examples/vol1/oxford/oxford.o models/bugs_examples/vol1/oxford/oxford.cpp

real    0m16.373s
user    0m16.047s
sys     0m0.225s

but the RAM peaked at 5% for the modified version compared to 5.3% for the current version (of 8GB I think, i.e. excluding the swap). So, that is not huge savings, but I'm sure it would be a bit more if we actually narrowed the #includes from Eigen and did a multivariate or otherwise big model.

Ben

[Bob Carpenter]

Yup, compilation time's still pretty ugly. I just tested Rats
on my notebook, which has the advantage of a solid-state drive
and decent quad-core CPU and relatively fast memory:

g++ -O3 21s
g++ -O0 18s

clang++ -O3 13s
clang++ -O0 4s

This is way way too long. I'm just not sure the includes are
the source of the problem. For instance, the above indicates the
clang++ spends most of its time in optimization --- no idea what's
up with g++, so results are probably going to vary by compiler/assembler/linker.

We should be able to compile many more functions ahead of
time. I'm worried it may cut down on efficiency because we
won't be able to inline already compiled libs. But we can
measure it.

- Bob

[Bob Carpenter]

Thanks! That's exactly what I wanted to see.

Would you mind seeing what it looks like under -O0 and
under clang++ -O0 and -O3?

I think we're killing RAM when we instantiate templates.
This is only done for code we're using, not for all the
extra templates we read in.

It seems the recursion in the template metaprograms
is implemented very wastefully, especially on Windows,
where we had to break translation units apart so as not
to blow out memory during template expansion.

Anyway, this would probably be worth doing for even
a 10% speedup in compilation time at some point.
I think the bigger gains will come from compiling more
into our archive/library. We can do that with explicit
template instantiations the same way we do for the parser.
We can predict all the implementation types. The only
downside here is that the archive will be big (but
not necessarily the executables we generate from it).

- Bob

On 5/8/13 8:23 PM, Ben Goodrich wrote:
> On Wednesday, May 8, 2013 8:04:25 PM UTC-4, Ben Goodrich wrote:
>
> We still have somewhat outdated compile times at
>

> https://code.google.com/p/stan/wiki/SpeedResults <https://code.google.com/p/stan/wiki/SpeedResults>

[Marcus Brubaker]

If it seems like matrix ops are one of the big problems with
compilation time, it's unlikely that we'll loose much there by not
being able to inline functions since the functions themselves are
typically sufficiently complex.

That might be a good place to start.

Cheers,
Marcus

[Ben Goodrich]

On Wednesday, May 8, 2013 5:38:33 PM UTC-4, Ben Goodrich wrote:

We could even call R to shuffle them, but I still think shuffling (possibly optimally rather than randomly) them once on disk is the better way to go. We don't really care about the randomness of the shuffle, except that it has the effect of lowering the maximum RAM spike.

I have shuffling implemented locally via R now. Does

Rscript --version

work for everyone? The Rscript binary should have been installed with R, so it is just a question of whether it is on the PATH.

Ben

[Bob Carpenter]

R's an even better choice for this project than Python or Java.

Installing R put Rscript on my path.

- Bob

[Michael Betancourt]

Can we make this optional?  I don't have R installed on all of my machines and the call to RScript without any existence-checking spits out a ton of errors every time make is called.  Also basically makes a R a dependency of stan, which I'd be uneasy with.

--
You received this message because you are subscribed to the Google Groups "stan development mailing list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+unsubscribe@googlegroups.com.

[Ben Goodrich]

On Monday, May 13, 2013 5:59:04 AM UTC-4, Michael Betancourt wrote:

Can we make this optional?  I don't have R installed on all of my machines and the call to RScript without any existence-checking spits out a ton of errors every time make is called.  Also basically makes a R a dependency of stan, which I'd be uneasy with.

I reverted it again. But I don't think it makes R a dependency of Stan; it only makes R necessary to run test-unit. As it stands now, the requirement to run test-unit in a reasonable amount of time is that the machine has to have at least 10GB of RAM at -O0. And we do almost no testing with higher levels of compiler optimization.

Ben

[Michael Betancourt]

The issue is that the way the makefile is written it tries to call Rscript no matter the specific call to make; it doesn't kill compilation but it's really annoying and is bound to cause confusion.  I think it's fine to appeal to Rscript here provided you check for its existence first.  Hell, we could check for Rscript and if it's not there then try to to reorder with sort, and it that's not found try Python, etc.

--
You received this message because you are subscribed to the Google Groups "stan development mailing list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.

[Bob Carpenter]

Ben's shuffling is solving a real issue.

At the risk of exposing my ignorance of make, is there
a portable way to make R optional so that the shuffle
only happens if R is installed?

Overall, I don't like piling on the if-elses and
including optional components, but R seems rather benign
for us. At worst, I wouldn't even mind having all of
our devs have to install it.

As someone pointed out, it's only a dependency for
the tests. We can't have a true dependency on R because
of licensing issues.

- Bob

> stan-dev+unsubscribe@__googlegroups.com <mailto:stan-dev%2Bunsu...@googlegroups.com>.
> For more options, visit https://groups.google.com/__groups/opt_out <https://groups.google.com/groups/opt_out>.

>
>
>
> --
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.

[Michael Betancourt]

I'm fine with a dev dependency, just not a user dependency.  And, again, while Rscript is meant for the tests it gets evaluated everytime make is called, so either being more careful with the call (executing only if `which Rscript` is nonempty within the shell escape) or make (executing only if tests are being run) it would be very welcome.

To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "stan development mailing list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+unsubscribe@googlegroups.com.

[Ben Goodrich]

On Monday, May 13, 2013 12:08:07 PM UTC-4, Michael Betancourt wrote:

I'm fine with a dev dependency, just not a user dependency.  And, again, while Rscript is meant for the tests it gets evaluated everytime make is called, so either being more careful with the call (executing only if `which Rscript` is nonempty within the shell escape) or make (executing only if tests are being run) it would be very welcome.

Here is a patch that might work if the "which" binary is available. Someone please apply it on Windows.

Ben

[Jiqiang Guo]

I cannot find "which" on windows. 

--

Jiqiang

--
You received this message because you are subscribed to the Google Groups "stan development mailing list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.

[Bob Carpenter]

If it's not in RTools, you can get it in cygwin.
Just make sure to put the cygwin bin/ on your
path (the only way I know how to do this on Windows is
to use the GUI environment variable editor).

- Bob

> stan-dev+u...@googlegroups.com <mailto:stan-dev%2Bunsu...@googlegroups.com>.

[Bob Carpenter]

Sorry -- I meant to add that we really don't want to
have dependencies that aren't part of RTools. So if
"which" isn't in Rtools, we probably shouldn't use it.

- Bob

On 5/16/13 1:14 PM, Jiqiang Guo wrote:

> stan-dev+u...@googlegroups.com <mailto:stan-dev%2Bunsu...@googlegroups.com>.

[Ben Goodrich]

On Thursday, May 16, 2013 1:14:38 PM UTC-4, Jiqiang Guo wrote:

I cannot find "which" on windows. 

Just do

which which

:) . Or tell me how to test for existence on Windows.

Ben

[Jiqiang Guo]

'where' can do it.  

C:\Users\root\Desktop>where r.exe

c:\Program Files\R\R-3.0.0\bin\R.exe

C:\Users\root\Desktop>where r

c:\Program Files\R\R-3.0.0\bin\R.exe

C:\Users\root\Desktop>where Rscript

c:\Program Files\R\R-3.0.0\bin\Rscript.exe

--

Jiqiang 

[Ben Goodrich]

On Thursday, May 16, 2013 5:16:58 PM UTC-4, Jiqiang Guo wrote:

'where' can do it.  

Take nine attached that defines WH as where on Windows and as which on !Windows. I assume that is fine for Mac but I don't actually know that either.

Ben

[Bob Carpenter]

Yes, we have 'which' on the Mac And it looks
like 'where' is std on Windows.

- Bob

[Ben Goodrich]

On Thursday, May 16, 2013 11:32:10 PM UTC-4, Bob Carpenter wrote:

Yes, we have 'which' on the Mac   And it looks
like 'where' is std on Windows.

Sounds good. If you want to add the java case to the patch, go ahead.

Ben

[Jiqiang Guo]

I modified the file for a couple of reasons:

1. make of version 3.79.1, which does not support the idea of elseif

2. no quotes for string comparison in makefile (it took me a while to figure out it is reason that it was not working on windows). 

--

Jiqiang 

[Ben Goodrich]

On Friday, May 17, 2013 11:21:17 AM UTC-4, Jiqiang Guo wrote:

I modified the file for a couple of reasons:

1. make of version 3.79.1, which does not support the idea of elseif

2. no quotes for string comparison in makefile (it took me a while to figure out it is reason that it was not working on windows). 

Thanks. The revised version still works for me, so I guess Bob or Daniel can apply it now.

Ben