On Thu, Dec 15, 2016 at 07:37:31AM -0600, Dirk Eddelbuettel wrote:
>
> On 15 December 2016 at 14:26, Andreas Tille wrote:
> | This was discussed before. The output above is from a previous package
> | version where I simply forgot to actually use xvfb. Since this error
> | of mine the package
On 12/15/2016 03:03 PM, Dirk Eddelbuettel wrote:
>
> On 15 December 2016 at 14:42, Christian Seiler wrote:
> | On 12/15/2016 02:37 PM, Dirk Eddelbuettel wrote:
> | > On 15 December 2016 at 14:26, Andreas Tille wrote:
> | > | Sorry, but I have no idea how since I'm totally clueless currently and
>
On 15 December 2016 at 14:42, Christian Seiler wrote:
| On 12/15/2016 02:37 PM, Dirk Eddelbuettel wrote:
| > On 15 December 2016 at 14:26, Andreas Tille wrote:
| > | Sorry, but I have no idea how since I'm totally clueless currently and
| > | upstream also did not yet responded to this after the
On 15 December 2016 at 14:26, Andreas Tille wrote:
| This was discussed before. The output above is from a previous package
| version where I simply forgot to actually use xvfb. Since this error
| of mine the package was build without RGL - thus the warning. Later I
| was using xvfb correctly
On 12/15/2016 02:37 PM, Dirk Eddelbuettel wrote:
> On 15 December 2016 at 14:26, Andreas Tille wrote:
> | Sorry, but I have no idea how since I'm totally clueless currently and
> | upstream also did not yet responded to this after the initial idea that
> | it might be some ape related issue was
Hi,
On Wed, Dec 14, 2016 at 03:57:13PM -0600, Dirk Eddelbuettel wrote:
> | RGL: unable to open X11 display
> | Warning: 'rgl_init' failed, running with rgl.useNULL = TRUE
> | Error: segfault from C stack overflow
> | * removing
>
On 14 December 2016 at 16:44, Christian Seiler wrote:
| Hi,
|
| On 12/14/2016 04:16 PM, Dirk Eddelbuettel wrote:
| > One quick thought: does it die in _compilation_ which we have seen with
other
| > (C++-heavy) packages?
|
| No, g++ works fine here. (The C++ file itself is trivial if you
|
Hi,
On 12/14/2016 04:16 PM, Dirk Eddelbuettel wrote:
> One quick thought: does it die in _compilation_ which we have seen with other
> (C++-heavy) packages?
No, g++ works fine here. (The C++ file itself is trivial if you
look at it.)
Current package in Debian:
On 14 December 2016 at 15:59, Andreas Tille wrote:
| Hi Christian,
|
| thanks a lot for your extensive analysis about of the stack problem. I
| admit I have no idea why this large stack is needed on those
| architectures with stable kernel. I also have no idea why everything
| went fine with
Hi Andreas,
On 12/14/2016 03:59 PM, Andreas Tille wrote:
> thanks a lot for your extensive analysis about of the stack problem. I
> admit I have no idea why this large stack is needed on those
> architectures with stable kernel. I also have no idea why everything
> went fine with treescape
Hi Christian,
thanks a lot for your extensive analysis about of the stack problem. I
admit I have no idea why this large stack is needed on those
architectures with stable kernel. I also have no idea why everything
went fine with treescape version 1.10.17. Since I personally fell
totally
Hi again,
On 12/14/2016 03:00 PM, Christian Seiler wrote:
> If I had to guess what was going on in the backtrace, I'd suspect
> an infinite recursion in R code, which translates to infinite
> recursion of the underlying C code. But I'm really not sure here.
Interestingly enough, my initial guess
12 matches
Mail list logo
