[ADMB Users] ABMD & DLLs

[dave fournier]

You could try unloading and reloading the the DLL before you call it
the second time.
A problem with ADMB is that a lot of global variables etc are
initialized when you
execute an exe or load it as a DLL. However when you leave the DLL and
then
reenter it the global variables are not reinitialized.  I think this
is the origin of most of the problems.  There may also be some other
more subtle issues.

       Dave



On Feb 21, 3:15 pm, Arni Magnusson <arn... at hafro.is> wrote:
> I had experimented with DLL compilation, but never enough to notice this
> bug. By the way, the assignment call does work if it's the first thing in
> the session,
>
>    x <- rep(0,100)
>    f <- 0
>    dyn.load("simpleDLL.dll")
>    res <- .C("simpleDLL", as.integer(length(x)), as.double(x),
>              as.double(f), "")
>
> but then a plain subsequent run will crash:
>
>    .C("simpleDLL", as.integer(length(x)), as.double(x), as.double(f), "")
>
> It is therefore conceivable that an R package would work fine, since
> package functions would always make an assignment call, and never make a
> plain call without assigning the result to an object name.
>
> R does not have this problem with non-ADMB DLLs I have tried, so it
> appears that all ADMB DLLs are at least half broken. I still believe this
> can be fixed by a skilled C++ programmer, with hints from Dave Fournier.
> Until then, Johnoel will probably tag this bug report with a number.
>
> Laurie, as an encouragement to improve ADMB in this area, can you describe
> the benefits of using DLLs as opposed to plain executables? I have only
> experimented with this a bit, and tried out the R package 'glmmADMB' which
> uses plain executables. I'm guessing DLLs are a tidier connection than
> passing text files to and from executables, but the latter approach can
> achieve the same goal by adding a couple of lines to the R function to
> take care of temporary files, right? The time penalty should be
> negligible; I just tried writing and reading a 5 column x 1000 row dataset
> in R,
>
>    write.table(quakes, "quakes.txt", row.names=FALSE)
>    quakes2 <- read.table("quakes.txt", header=TRUE)
>
> and it takes 0.06 sec on Windows and 0.02 sec on Linux 64, even when using
> the inefficient read.table and write.table functions. File handling on the
> ADMB side should be very fast as well.
>
> The benefit of using plain executables is of course that the same model
> can be used either as stand-alone or called by other software via text
> files. If the medium-term goal is to fix the ADMB DLLs, then a long-term
> goal could be to make it possible to compile both DLLs and executables
> without modifying the TPL code.
>
> Thanks for exploring this, and for improving the MSVC compilation scripts.
>
> Arni
>
> On Sun, 21 Feb 2010, Laurie Kell wrote:
> > I have managed to compile windows MSVC9 DLLs, both on the command line
> > and using the IDE with debugging info. I will update the adlink.bat for
> > MSVC9
>
> > However, using the simple example to create the DLL there is a problem
> > when calling the DLL from R for versions compiled in MSVC9 and GCC
> > (windows and linux).
>
> > The MSVC9 dll crashes at line
>
> > mp.computations(argc,argv);
>
> > While under GCC (both windows and linux) although the DLL runs i.e.
> > .C("simpleDLL", ...)
>
> > it crashes R if  you try to save the results i.e.
> > res<-.C("simpleDLL", ...)
>
> > I think this points to a memory allocation or a calling convention
> > problem in the ADMB code. I�ve had a quick look at the code on
> >http://code.google.com/p/admb-project
>
> > But think it might be easier if somebody who is more familar with the
> > source than me could have a look at this problem.
>
> > Laurie
>
>
>
> _______________________________________________
> Users mailing list
> Us... at admb-project.orghttp://lists.admb-project.org/mailman/listinfo/users