On 4/11/21 4:41 PM, Bastiaan Veelo wrote:
On Sunday, 11 April 2021 at 19:45:30 UTC, Ruby The Roobster wrote:
What am I doing wrong here? Is it the 'for' loop?
Yes, there is a `7` where there should be an `i` on this line:
```d
for(int i=7;7>=0;i--)
```
This will go on forever, so you get a
On Sunday, 11 April 2021 at 09:10:22 UTC, tchaloupka wrote:
Hi,
we're using vibe-d (on Linux) for a long running REST API
server and have problem with constantly growing memory until
system kills it with OOM killer.
Do you have a manual GC.free() in your code, maybe with a larger
array?
I should have added
https://dub.pm/package-format-json#build-types
profileGC as build option in your dub file
That will generate a profile_gc file once the program exit, a
table that lists all the allocations
On Sunday, 11 April 2021 at 13:50:12 UTC, tchaloupka wrote:
On Sunday, 11 April 2021 at 12:20:39 UTC, Nathan S. wrote:
One thing that comes to mind: is your application compiled as
32-bit? The garbage collector is much more likely to leak
memory with a 32-bit address space since it much more
On Thursday, 8 April 2021 at 18:06:25 UTC, Meta wrote:
On Thursday, 8 April 2021 at 18:01:56 UTC, Meta wrote:
On Thursday, 8 April 2021 at 12:19:29 UTC, WebFreak001 wrote:
```d
string to01String(int[] x) @safe
{
auto conv = x.to!(ubyte[]); // allocates new array, so
later cast to string i
On Sunday, 11 April 2021 at 19:45:30 UTC, Ruby The Roobster wrote:
What am I doing wrong here? Is it the 'for' loop?
Yes, there is a `7` where there should be an `i` on this line:
```d
for(int i=7;7>=0;i--)
```
This will go on forever, so you get a range error as soon as `i <
0`.
—Bastiaa
Hi,
I have a class with a reference to the parent object and a
constructor that has the parent as parameter
class foo {
this ( foo p /* , other params */ ) {
parent = p;
}
foo parent;
}
Of cause, the parent is almost always the object that creates the
Hi everyone, I'm trying to use a shared library created in
Cython. example.
*file run_cython.pyx**
cpdef int test(int x):
cdef int y = 1
cdef int i
for i in range(1, x+1):
y *= i
return y
***
On Sunday, 11 April 2021 at 19:45:30 UTC, Ruby The Roobster wrote:
What am I doing wrong here? Is it the 'for' loop?
Nevermind. I messed up what line it was. It was actually this
line:
```d
square[i][j] = new Square(Color.none, sColor.white);
```
So, here is the full code:
```d
enum Color {none=0,red=1,black=2};
enum sColor {black=0,white=1};
class Square {
public:
this(Color color, sColor Scolor) {
this.color = color;
this.Scolor = Scolor;
}
Color color;
sColor Scolor;
}
import std.stdio;
void cPrintboard(Square[8
Inside dmd source tree, under sub-directory test, I do
./run.d compilable/
. This errors as
```
... compilable/json.d -d -preview=dip1000 -o- -X
-Xf/home/per/Work/dmd/test/test_results/compilable/json.out
-fPIC ()==
Test 'compilable/json.d' fail
On Sunday, 11 April 2021 at 13:43:47 UTC, martinm wrote:
I'm trying to use wayland-d which depends on
derelict-util-2.0.6.
DUB can't download the zip and fails.
I download the zip to ~/.dub/packages/derelict-util folder,
unzip and build.
DUB builds **DerelictUtil.a ~master**.
That's not how
On Sunday, 11 April 2021 at 13:43:47 UTC, martinm wrote:
I'm trying to use wayland-d which depends on
derelict-util-2.0.6.
DUB can't download the zip and fails.
I download the zip to ~/.dub/packages/derelict-util folder,
unzip and build.
DUB builds **DerelictUtil.a ~master**.
Trying to rebuil
On Sunday, 11 April 2021 at 12:20:39 UTC, Nathan S. wrote:
One thing that comes to mind: is your application compiled as
32-bit? The garbage collector is much more likely to leak
memory with a 32-bit address space since it much more likely
for a random int to appear to be a pointer to the int
I'm trying to use wayland-d which depends on derelict-util-2.0.6.
DUB can't download the zip and fails.
I download the zip to ~/.dub/packages/derelict-util folder, unzip
and build.
DUB builds **DerelictUtil.a ~master**.
Trying to rebuild wayland-d, DUB can't find
**derelict-util-2.0.6** depend
On Sunday, 11 April 2021 at 09:10:22 UTC, tchaloupka wrote:
Hi,
we're using vibe-d (on Linux) for a long running REST API
server and have problem with constantly growing memory until
system kills it with OOM killer.
One thing that comes to mind: is your application compiled as
32-bit? The ga
Hi,
we're using vibe-d (on Linux) for a long running REST API server
and have problem with constantly growing memory until system
kills it with OOM killer.
First guess was some memory leak so we've added periodic call to:
```D
GC.collect();
GC.minimize();
malloc_trim(0);
```
And when called
17 matches
Mail list logo
