Presumably this is due to #19883
There isn't really any problem here, though. If you implement your own
version of malloc then, in some implementations, you'll need about as much
virtual memory as ram to do the accounting. It just uses your 128TB of
virtual memory space.
On a related note, 'u
On Monday, March 28, 2016 at 12:35:41 AM UTC-7, Volker Braun wrote:
>
> Presumably this is due to #19883
>
> There isn't really any problem here, though. If you implement your own
> version of malloc then, in some implementations, you'll need about as much
> virtual memory as ram to do the accoun
On Monday, 28 March 2016 09:54:34 UTC-6, Nils Bruin wrote:
>
> On Monday, March 28, 2016 at 12:35:41 AM UTC-7, Volker Braun wrote:
>>
>> Presumably this is due to #19883
>>
>> There isn't really any problem here, though. If you implement your own
>> version of malloc then, in some implementations,
On Monday, March 28, 2016 at 5:54:34 PM UTC+2, Nils Bruin wrote:
>
> It's a simple one to set, though, and in many contexts it protects
> against silly memory errors (e.g., on a multi-user machine
>
But it doesn't help when you have multiple processes, as its per-process
limit only.
> Perha
On Mon, Mar 28, 2016 at 10:15 AM, Volker Braun wrote:
> On Monday, March 28, 2016 at 5:54:34 PM UTC+2, Nils Bruin wrote:
>>
>> It's a simple one to set, though, and in many contexts it protects against
>> silly memory errors (e.g., on a multi-user machine
>
>
> But it doesn't help when you have mu
On Monday, March 28, 2016 at 8:16:36 PM UTC+2, William wrote:
>
> Another very common thing to ulimit is the number of processes.
> e.g., the default I think on Ubuntu is maybe 1000.
>
Yes, and 1000 * RLIMIT_AS is almost always enough to make things very
slw...
I'm really sad to see that g
Hello,
I got problems building the doc for "knots" (see attached log obtained
without parallel build). I am alone in that case?
Vincent
On 28/03/16 12:16, Volker Braun wrote:
As always, you can get the latest beta version from the "develop" git
branch. Alternatively, the self-contained sourc
I take it you haev CPLEX installed...
On Monday, March 28, 2016 at 11:20:01 PM UTC+2, vdelecroix wrote:
>
> Hello,
>
> I got problems building the doc for "knots" (see attached log obtained
> without parallel build). I am alone in that case?
>
> Vincent
>
> On 28/03/16 12:16, Volker Braun wro
Yes I do. I see. Having plot code that is sensitive to the LP solver is
bad. Is there already a ticket opened?
On 28/03/16 19:19, Volker Braun wrote:
I take it you haev CPLEX installed...
On Monday, March 28, 2016 at 11:20:01 PM UTC+2, vdelecroix wrote:
Hello,
I got problems building the d
Indeed, minimal failing example
sage: L = Link([[2,1,4,5], [5,6,7,3], [6,4,1,9], [9,2,3,7]])
sage: L.plot()
Traceback (most recent call last):
...
MIPSolverException: 'CPLEX: The primal has no feasible solution'
On 28/03/16 19:29, Vincent Delecroix wrote:
Yes I do. I see. Having plot code that
#20315
On 28/03/16 19:31, Vincent Delecroix wrote:
Indeed, minimal failing example
sage: L = Link([[2,1,4,5], [5,6,7,3], [6,4,1,9], [9,2,3,7]])
sage: L.plot()
Traceback (most recent call last):
...
MIPSolverException: 'CPLEX: The primal has no feasible solution'
On 28/03/16 19:29, Vincent Dele
On Monday, March 28, 2016 at 11:29:08 PM UTC+1, vdelecroix wrote:
>
> Yes I do. I see. Having plot code that is sensitive to the LP solver is
> bad. Is there already a ticket opened?
>
I always maintained that the design when installation of a solver makes it
default
is bad, but to no avail..
On 28/03/16 20:12, Dima Pasechnik wrote:
On Monday, March 28, 2016 at 11:29:08 PM UTC+1, vdelecroix wrote:
Yes I do. I see. Having plot code that is sensitive to the LP solver is
bad. Is there already a ticket opened?
I always maintained that the design when installation of a solver makes
13 matches
Mail list logo
