search for: max_num_dll

This is a request to increase MAX_NUM_DLLS in Rdynload.c in from 100 to 500. On line 131 of Rdynload.c, changing #define MAX_NUM_DLLS 100 to #define MAX_NUM_DLLS 500 In development of the mlr package, there have been several episodes in the past where we have had to break up unit tests because of the "maximum number of DLLs rea...

...ll try this out on our tests and see if gcDLLs() has a positive effect. mlr currently has tests broken down by learner type such as classification, regression, forecasting, clustering, etc.. There are 83 classifiers alone so even when loading and unloading across learner types we can still hit the MAX_NUM_DLLS error, meaning we'll have to break them down further (or maybe we can be clever with gcDLLs()?). I'm CC'ing Lars Kotthoff and Bernd Bischl to make sure I am representing the issue well. Regards, Steve Bronder Website: stevebronder.com Phone: 412-719-1282 Email: sbronder at stevebrond...

...() has a positive effect. | | > mlr currently has tests broken down by learner type such as classification, | > regression, forecasting, clustering, etc.. There are 83 classifiers alone | > so even when loading and unloading across learner types we can still hit | > the MAX_NUM_DLLS error, meaning we'll have to break them down further (or | > maybe we can be clever with gcDLLs()?). I'm CC'ing Lars Kotthoff and Bernd | > Bischl to make sure I am representing the issue well. | | This came up *here* in May 2015 | and then May 2016 ... did you not find...

On reason for hitting the MAX_NUM_DLLS (= 100) limit is because some packages don't unload their DLLs when they being unloaded themselves. In other words, there may be left-over DLLs just sitting there doing nothing but occupying space. You can remove these, using: R.utils::gcDLLs() Maybe that will help you get through your t...

...if gcDLLs() has a positive effect. > mlr currently has tests broken down by learner type such as classification, > regression, forecasting, clustering, etc.. There are 83 classifiers alone > so even when loading and unloading across learner types we can still hit > the MAX_NUM_DLLS error, meaning we'll have to break them down further (or > maybe we can be clever with gcDLLs()?). I'm CC'ing Lars Kotthoff and Bernd > Bischl to make sure I am representing the issue well. This came up *here* in May 2015 and then May 2016 ... did you not find it when go...

.... > | > | > mlr currently has tests broken down by learner type such as classification, > | > regression, forecasting, clustering, etc.. There are 83 classifiers alone > | > so even when loading and unloading across learner types we can still hit > | > the MAX_NUM_DLLS error, meaning we'll have to break them down further (or > | > maybe we can be clever with gcDLLs()?). I'm CC'ing Lars Kotthoff and Bernd > | > Bischl to make sure I am representing the issue well. > | > | This came up *here* in May 2015 > | and then May 20...

On Tue, Dec 20, 2016 at 7:04 AM, Henrik Bengtsson <henrik.bengtsson at gmail.com> wrote: > On reason for hitting the MAX_NUM_DLLS (= 100) limit is because some > packages don't unload their DLLs when they being unloaded themselves. I am surprised by this. Why does R not do this automatically? What is the case for keeping the DLL loaded after the package has been unloaded? What happens if you reload another version of...

Hello, My problem is that I hit the hard-coded MAX_NUM_DLLS (100) limit of the number of loaded DLLs. I have a number of custom packages which interface and integrate a lot of CRAN and Bioconductor packages. For example, on my installation: Rscript -e 'library(crlmm);print(length(getLoadedDLLs()))' gives 28 loaded DLLs. I am currently trying to...

...the number of DLLs, dynamically expanding the array if/when needed. On Tue, Dec 20, 2016 at 3:40 AM, Jeroen Ooms <jeroen.ooms at stat.ucla.edu> wrote: > On Tue, Dec 20, 2016 at 7:04 AM, Henrik Bengtsson > <henrik.bengtsson at gmail.com> wrote: >> On reason for hitting the MAX_NUM_DLLS (= 100) limit is because some >> packages don't unload their DLLs when they being unloaded themselves. > > I am surprised by this. Why does R not do this automatically? What is > the case for keeping the DLL loaded after the package has been > unloaded? What happens if you re...

...ray if/when needed. >> >> >> On Tue, Dec 20, 2016 at 3:40 AM, Jeroen Ooms <jeroen.ooms at stat.ucla.edu> wrote: >>> On Tue, Dec 20, 2016 at 7:04 AM, Henrik Bengtsson >>> <henrik.bengtsson at gmail.com> wrote: >>>> On reason for hitting the MAX_NUM_DLLS (= 100) limit is because some >>>> packages don't unload their DLLs when they being unloaded themselves. >>> >>> I am surprised by this. Why does R not do this automatically? What is >>> the case for keeping the DLL loaded after the package has been >&...

...mically expanding the array if/when needed. > > > On Tue, Dec 20, 2016 at 3:40 AM, Jeroen Ooms <jeroen.ooms at stat.ucla.edu> wrote: >> On Tue, Dec 20, 2016 at 7:04 AM, Henrik Bengtsson >> <henrik.bengtsson at gmail.com> wrote: >>> On reason for hitting the MAX_NUM_DLLS (= 100) limit is because some >>> packages don't unload their DLLs when they being unloaded themselves. >> >> I am surprised by this. Why does R not do this automatically? What is >> the case for keeping the DLL loaded after the package has been >> unloaded? Wh...

>>>>> Qin Zhu <qinzhu at outlook.com> >>>>> on Mon, 2 May 2016 16:19:44 -0400 writes: > Hi, > I?m working on a Shiny app for statistical analysis. I ran into this "maximal number of DLLs reached" issue recently because my app requires importing many other packages. > I?ve posted my question on stackoverflow

I have read both the historical r-devel threads and the most recent one regarding this. After reviewing the code, it would seem to beg for a linked-list implementation vs. an array implementation. This has several interesting consequences. Cons: 1) We pay for dynamic allocation every time we register a DLL. This isn't a problem in the grand scheme of things as registering a DLL results in

...bout this because this seems to be OS dependent and previous versions of my app are running on both windows and macs. Hmm, I thought that dyn.unload() would typically work on all platforms, but did not research the question now, and am happy to learn more by being corrected. Even if we increase MAX_NUM_DLL in the future, a considerable portion your app's will not use that future version of R yet, and so you should try to "fight" the problem now. > Any suggestions would be appreciated, and I?d appreciate if the MAX_NUM_DLLS can be increased. > Thanks, > Qin &...

On 05/04/2016 05:15 AM, Prof Brian Ripley wrote: > On 04/05/2016 08:44, Martin Maechler wrote: >>>>>>> Qin Zhu <qinzhu at outlook.com> >>>>>>> on Mon, 2 May 2016 16:19:44 -0400 writes: >> >> > Hi, >> > I?m working on a Shiny app for statistical analysis. I ran into >> this "maximal number of DLLs

Hi, I?m working on a Shiny app for statistical analysis. I ran into this "maximal number of DLLs reached" issue recently because my app requires importing many other packages. I?ve posted my question on stackoverflow (http://stackoverflow.com/questions/36974206/r-maximal-number-of-dlls-reached <http://stackoverflow.com/questions/36974206/r-maximal-number-of-dlls-reached>). I?m

...oad to unload whatever I think is associated with that package when the user?s done using it? I?m a little nervous about this because this seems to be OS dependent and previous versions of my app are running on both windows and macs. Any suggestions would be appreciated, and I?d appreciate if the MAX_NUM_DLLS can be increased. Thanks, Qin > On May 4, 2016, at 9:17 AM, Martin Morgan <martin.morgan at roswellpark.org> wrote: > > > > On 05/04/2016 05:15 AM, Prof Brian Ripley wrote: >> On 04/05/2016 08:44, Martin Maechler wrote: >>>>>>>> Qin Zhu <...

On 04/05/2016 08:44, Martin Maechler wrote: >>>>>> Qin Zhu <qinzhu at outlook.com> >>>>>> on Mon, 2 May 2016 16:19:44 -0400 writes: > > > Hi, > > I?m working on a Shiny app for statistical analysis. I ran into this "maximal number of DLLs reached" issue recently because my app requires importing many other packages.

...R_ReplDllinit() just before entering the do1-loop--- though perhaps this should be integrated into some part of the setup procedure for embedding apps. DllInfo* R_RegisterEmbeddedExecutable(HINSTANCE handle,char* path) { char* dpath,*name,DLLname[PATH_MAX], *p; DeleteDLL(path); if(CountDLL == MAX_NUM_DLLS) { strcpy(DLLerror,"unable to register embedded executable. too many libraries"); return 0; } dpath = malloc(strlen(path)+1); if(dpath == NULL) { strcpy(DLLerror,"Couldn't allocate space for 'path'"); return 0; } strcpy(dpath, path);...