Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

c stack usage #17

Open
blset opened this issue Jul 1, 2021 · 9 comments
Open

c stack usage #17

blset opened this issue Jul 1, 2021 · 9 comments

Comments

@blset
Copy link

blset commented Jul 1, 2021

this smple gen
gen.element(1:100) |> gen.c(of = 1400)

produces the error
Erreur : C stack usage 7972516 is too close to the limit

with

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0

locale:
 [1] LC_CTYPE=fr_FR.UTF-8       LC_NUMERIC=C               LC_TIME=fr_FR.UTF-8        LC_COLLATE=fr_FR.UTF-8    
 [5] LC_MONETARY=fr_FR.UTF-8    LC_MESSAGES=fr_FR.UTF-8    LC_PAPER=fr_FR.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C             LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] hedgehog_0.1   testthat_3.0.2

loaded via a namespace (and not attached):
[1] compiler_4.1.0 magrittr_2.0.1 R6_2.5.0       tools_4.1.0    rlang_0.4.11  
 
@HuwCampbell
Copy link
Member

Thanks for the report. IIRC, the implentation of gen.c was implented based on a early version of the haskell library.

Obviously, they're different languages, and Haskell's stack is on the heap and not the c stack, and is a bit lazier, so this wasn't the best choice.

Fortunately, there's been a bit on this front in our other implementations, so I think we should be able to relook at that, even if not everything applies.

You can also use a generator which doesn't shrink individual elements like this one.

@HuwCampbell
Copy link
Member

Try this: #18

@assignUser
Copy link
Contributor

@HuwCampbell I had this issue with more (overly?) complex gens and #18 fixed the issue!
There is a workaround with unix::rlimit_stack(cur = Inf) but it is good to have it solved in the "backend"

@HuwCampbell
Copy link
Member

Cool. I will endevour to make a release with these changes this week.

@assignUser
Copy link
Contributor

Correction, fixed it most of the time, in some sessions it still happens (there is some randomness in input size for my generators so that might be the reason why) but that is most likely more an issue with my gens and can be optimized.

@HuwCampbell
Copy link
Member

If you can give an example showing where the stack is being blown I can have a look.

@assignUser
Copy link
Contributor

It happens somewhere in here https://github.com/kgoldfeld/simstudy/blob/main/tests/testthat/test-define_data.R
but I'll have to take a closer look where exactly in the coming days.

@gregmuellegger
Copy link

I ran into the same problem, but using the current master (which includes #18) seems to fix the problem. (Installed with devtools::install_github("hedgehogqa/r-hedgehog")

Is that fix already part of the 0.1 release on CRAN?

@HuwCampbell
Copy link
Member

Looks like it's not.

I will have a go at getting a release up, I haven't touched this project for a while, so it's likely I'll need to kick a few dependencies; we'll see how I go.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants