Do I need to build `stanc` in BridgeStan v1.0 after a fresh install? about bridgestan

[WardBrian]

The first time you build a model with bridgestan it downloads stanc from GitHub. You can see some of that in the output you posted ( % Total % Received % Xferd Average Speed Time Time Time Current is output from curl).

It seems this is failing in your CI, perhaps GitHub is rate limiting you?

but that runs into path problems, e.g. in example.jl:

I believe the path set in the example assumes you’re running julia from within the julia/ directory, and you will need to change the path if this is not true. In general, it is probably best to use absolute paths on your own machine, to avoid this

[WardBrian]

Looking at the code you're using:

https://github.com/StanJulia/StanSample.jl/blob/0f3cfdc66ba0fa86b7343a8a0800a175c9cdfc23/src/stanmodel/SampleModel.jl#L132-L141

I believe that the issue may be that you're using make -f, which does not change the working directory. make -c does, which means the makefile will be in the context it expects.

Alternatively, you can use compile_model provided by BridgeStan rather than calling make directly

[goedman]

Hi Brian. Yes, I came yesterday and this morning to a similar conclusion as in your first response. Your second message is a clear pointer to something I'm doing wrong so that's next on my list!

That make construct is a leftover from earlier versions. Basically the same as I was using while I was "borrowing" stanc from cmdstan and didn't dig too much into that because it works on my Mac.

The 2nd route, fiddling with paths in Julia packages, is always tricky I find. I'm also considering a 3rd option, using BridgeStan completely outside StanSample, as its own package. Or the 4th option, treating it as cmdstan.

Thanks for looking into this!

[WardBrian]

I'm far from an expert on make files, but I think generally they can be quite tricky to use from outside the folder they're in. In Julia/Python we use the dir functionality to run the command in the bridgestan folder, make -c should have the same effect though.

I also tried to have all of the relative paths based off a variable called BS_ROOT, which is set to . by default, so in theory the following should be equivalent

Style we use ourselves:

Cmd(
        `make $output_file`,
        dir = abspath(bridgestan),
    )

Untested but should be exactly equivalent to the above:

Cmd(`make -c$(abspath(bridgestan)) $output_file`)

Closest to your current code, but importantly tells BridgeStan where it's own root directory is (since it is not where the command is invoked, like it is in the above two)

Cmd(`make -f $(abspath(bridgestan))/Makefile BS_ROOT=$(abspath(bridgestan)) $output_file`)

[goedman]

In the current setup of StanSample + BridgeStan, bridge_path holds the absolute path to the bridgestan directory. Setting BS_ROOT is fine on Mac but doesn't help on CI.

I'll try to figure out what exactly is downloaded on CI.

[goedman]

After inserting a couple of print statements, it seems the proper bin/stancbinary is currently not downloaded for testing by Github CI. Playing around with enabling and disabling the bin/* entry in .gitignore in BridgeStan seems to behave as expected but I can't test easily on Github if that would fix the issue (I think).

Probably because stanc is not installed, the bin directory in bridgestan is not created either.

The new optimization, not building stanc but downloading the correct binary the first time needed, do we know if that is in use in any other place using Github workflows?

I wonder if the best way out for me is

1. to go back to try "borrowing" stanc from cmdstan (maybe using STANC ?= $(CMDSTAN_HOME)/bin/stanc$(EXE) in make/local?) or,
2. at least for the time being, remove support for BridgeStan from StanSample.jl and see if I can get BridgeStan.jl as a package to work in setups using Github CI and Pluto.

With option 1 I'm a bit concerned about future maintenance work if stanc itself or flags for stanc might divert.

With option 2 I'm running into:

julia> smb = BS.StanModel(stan_file = p1, data = p2);
ERROR: could not load symbol "bs_construct":
dlsym(0x8adff880, bs_construct): symbol not found
Stacktrace:
 [1] dlsym(hnd::Ptr{Nothing}, s::String; throw_error::Bool)
   @ Base.Libc.Libdl ./libdl.jl:59

I'm just reporting these issues in the hope someone immediately sees the way out! Next up is borrowing stanc from cmdstan.

[WardBrian]

“Borrowing” stanc is only a good idea if the cmdstan version exactly matches the version of Stan used by bridgestan, which might be a bit difficult to check ahead of time.

We are using GitHub actions for our own CI, so I’m not sure why there would be anything specific to that environment which fails.

I am not sure how deeply you have integrated bridgestan into StanSample, but anything written pre-1.0 (especially if you have any cached builds or anything like that in Actions) should get a second look. The specific error you’ve shared looks like the one you would get if you tried to load a DSO compiled before #53 with the code from after that change

[goedman]

Thanks again Brian. In the case of StanSample.jl a user must have installed a version of cmdstan and every model compiled by that version of cmdstan would also run stansummary and create a model_so file. At least that was the plan.

I'll go over the CI workflows for BridgeStan to see if I do something different. I see the curl request and the chmod +x ../bin/stanc being successful.

Your 3rd point is spot on! I started from a new environment and installed StanSample and BridgeStan but forget I need to dev StanSample to get BridgeStan v1.0.

[WardBrian]

Please do let us know if it turns out we've done something which unnecessarily makes life harder!

If your use case is specific to models which are also used by CmdStan, you can use the STAN and STANC make variables to basically un-do #51 and have it so BridgeStan is pinned to the same code as the CmdStan install. This won't work too well if cmdstan is older than 2.31 though, due to some source incompatibilities.

[goedman]

Hi Brian,

A lot has gotten better in v1.0 and I need to figure out how I can make this work on CI.

The Github CI workflows for BridgeStan do show a correct curl command for a linux version of stanc and it looks like something being downloaded (additional lines compared to my earlier output lines).

Using BridgeStan as a package now works fine. Not sure how difficult it is to use this in Pluto as BridgeStan.jl is not registered.

For now I will test the "borrowing" stanc route next.

[goedman]

The 1st option ("borrowing STAN and STANC from cmdstan) fails with:

┌ Warning: BridgeStan compilation of model failed.
└ @ StanSample ~/work/StanSample.jl/StanSample.jl/src/stanmodel/SampleModel.jl:138
BridgeStan: Error During Test at /home/runner/work/StanSample.jl/StanSample.jl/test/runtests.jl:65
  Got exception outside of a @test
  LoadError: 
  Error when compiling SampleModel bernoulli:
  In file included from src/bridgestan.h:5,
                   from src/bridgestan.cpp:1:
  src/model_rng.hpp:4:10: fatal error: stan/model/model_base.hpp: No such file or directory
      4 | #include <stan/model/model_base.hpp>
        |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
  compilation terminated.
  make: *** [/home/runner/work/StanSample.jl/StanSample.jl/deps/data/bridgestan/Makefile:45: src/bridgestan_threads.o] Error 1

For the 2nd option, using BridgeStan.jl, I went back to the vanilla Julia example (example.jl) and attempted to get that to work in the StanSample.jl setting using a local copy of BridgeStan (in debs/data/bridgestan). That works fine on my Mac. But I got stuck on CI and also on AutoMerge:

1. Download of stanc definitely does not seem to happen or maybe is even not allowed. Maybe that is ok when testing within the repo but not across repos?

Testing: test_bridgestan/test_bridgestan.jl.

[ Info: /tmp/jl_EVYocJ/bernoulli.stan updated.
Warning: BridgeStan compilation of model failed.

Got exception outside of a @test
   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                   Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100     9  100     9    0     0     52      0 --:--:-- --:--:-- --:--:--    52

 ./bin/stanc: 1: Not: not found

2. Given that a developer makes changes to the cloned BridgeStan (e.g. stanc is down loaded in bin, maybe added a make/local file), it seems Julia's AutoMerge does not like that:

┌ Warning: tarball content does not match git-tree-sha1
└ @ Pkg.Operations /cache/build/default-amdci5-6/julialang/julia-release-1-dot-8/usr/share/julia/stdlib/v1.8/Pkg/src/Operations.jl:556
     Cloning [c1514b29-d3a0-5178-b312-660c88baa699] StanSample from https://github.com/StanJulia/StanSample.jl.git
ERROR: GitError(Code:ERROR, Class:Submodule, cannot get submodules without a working tree)

3. Not sure if this approach would work for Pluto. Untested.

All in all, my current conclusion is that an individual Julia user can certainly use a locally installed BridgeStan repo but including it in StanSample.jl is tricky and certainly difficult to maintain with my limited Github workflow and make knowledge.

As I want to go on with my project work, for now I'll remove BridgeStan support from StanSample.jl. But not giving up yet!

[WardBrian]

The 1st option ("borrowing STAN and STANC from cmdstan) fails with:

That error definitely has the flavor of "make thinks it is being run somewhere it is not so it's passing a nonsense include flag". Certainly possible to debug (running make print-STAN etc and making sure that directory is really the one you want) but make definitely is frustrating for things like this

Download of stanc definitely does not seem to happen or maybe is even not allowed. Maybe that is ok when testing within the repo but not across repos?

That seems so strange to me, since we're downloading it from stan-dev/stanc3, not this repo, so we shouldn't have any "special treatment" as it were. Is it possibly being downloaded but not in the right place? Have you tried printing out a ls -R of the entire folder structure?

All in all, my current conclusion is that an individual Julia user can certainly use a locally installed BridgeStan repo but including it in StanSample.jl is tricky and certainly difficult to maintain with my limited Github workflow and make knowledge.

Very glad to hear that it is working for end users, still. I think the best way forward would likely be treating it similarly to CmdStan - up to the user to install, rather than trying to ship it as part of a Julia package. I'm not too familiar with Julia, is there some way of checking if another package is installed at run time, and adding functionality to your own if so? In Python you can do this with something like

try:
    import bridgestan
    BRIDGESTAN_INSTALLED=True
except ImportError:
    BRIDGESTAN_INSTALLED=False

[WardBrian]

It seems like the Julia equivalent is available using something like Requires.jl. I think that is probably better than a submodule approach, all things considered.

I'm going to mark this as wontfix for now, but I'm happy to continue troubleshooting with you in this thread if you want to pick it back up in the future!

[goedman]

Yes, on your last suggestion, there is such an option using Requires.jl. I’ll check how that works with unregistered package.I’ll get a complete list of files downloaded but on my Mac it definitely ends up in the right bin directory.Sent from my iPhoneOn Dec 13, 2022, at 11:39, Brian Ward ***@***.***> wrote: The 1st option ("borrowing STAN and STANC from cmdstan) fails with: That error definitely has the flavor of "make thinks it is being run somewhere it is not so it's passing a nonsense include flag". Certainly possible to debug (running make print-STAN etc and making sure that directory is really the one you want) but make definitely is frustrating for things like this Download of stanc definitely does not seem to happen or maybe is even not allowed. Maybe that is ok when testing within the repo but not across repos? That seems so strange to me, since we're downloading it from stan-dev/stanc3, not this repo, so we shouldn't have any "special treatment" as it were. Is it possibly being downloaded but not in the right place? Have you tried printing out a ls -R of the entire folder structure? All in all, my current conclusion is that an individual Julia user can certainly use a locally installed BridgeStan repo but including it in StanSample.jl is tricky and certainly difficult to maintain with my limited Github workflow and make knowledge. Very glad to hear that it is working for end users, still. I think the best way forward would likely be treating it similarly to CmdStan - up to the user to install, rather than trying to ship it as part of a Julia package. I'm not too familiar with Julia, is there some way of checking if another package is installed at run time, and adding functionality to your own if so? In Python you can do this with something like try: import bridgestan BRIDGESTAN_INSTALLED=True except ImportError: BRIDGESTAN_INSTALLED=False —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>