On Friday, 25 June 2021 at 03:27:24 UTC, jfondren wrote:
On Friday, 25 June 2021 at 02:55:50 UTC, Utk wrote:
Please help me to resolve this issue.
Try stracing your program to see exactly what it's doing
with the socket, and try std.socket's lastSocketError
I tried using
On Friday, 25 June 2021 at 02:55:50 UTC, Utk wrote:
Please help me to resolve this issue.
Try stracing your program to see exactly what it's doing
with the socket, and try std.socket's lastSocketError
Not sure if you want build interprocess communication utility all
by yourself, I'm currently using
https://code.dlang.org/packages/apache-thrift
and there is also
https://code.dlang.org/packages/symmetry_thrift_d
BTW grpc is not quiet working
https://code.dlang.org/packages/grpc
Hello!
I'm trying to establish a connection between a python server and
a d client. The data is been transferred properly only once and
then the d client doesn't wait for any further data and returns
an error ```Socket.ERROR``` and exists and doesn't wait for
further incoming data from the
On 6/24/21 1:41 PM, seany wrote:
> Is there any way to control the number of CPU cores used in
> parallelization ?
Yes. You have to create a task pool explicitly:
import std.parallelism;
void main() {
enum threadCount = 2;
auto myTaskPool = new TaskPool(threadCount);
scope (exit) {
On Thursday, 24 June 2021 at 20:56:26 UTC, Ali Çehreli wrote:
On 6/24/21 1:33 PM, Bastiaan Veelo wrote:
> distributes the load across all cores (but one).
Last time I checked, the current thread would run tasks as well.
Ali
Indeed, thanks.
— Bastiaan.
On Thursday, 24 June 2021 at 21:05:28 UTC, Bastiaan Veelo wrote:
On Thursday, 24 June 2021 at 20:41:40 UTC, seany wrote:
Is there any way to control the number of CPU cores used in
parallelization ?
E.g : take 3 cores for the first parallel foreach - and then
for the second one, take 3 cores
On Thursday, 24 June 2021 at 20:41:40 UTC, seany wrote:
On Thursday, 24 June 2021 at 20:33:00 UTC, Bastiaan Veelo wrote:
By the way, nesting parallel `foreach` does not make much
sense, as one level already distributes the load across all
cores (but one). Additional parallelisation will
On 6/24/21 1:33 PM, Bastiaan Veelo wrote:
> distributes the load across all cores (but one).
Last time I checked, the current thread would run tasks as well.
Ali
On Thursday, 24 June 2021 at 20:33:00 UTC, Bastiaan Veelo wrote:
By the way, nesting parallel `foreach` does not make much
sense, as one level already distributes the load across all
cores (but one). Additional parallelisation will likely just
add overhead, and have a net negative effect.
—
On Thursday, 24 June 2021 at 18:23:01 UTC, seany wrote:
I have seen
[this](https://forum.dlang.org/thread/akhbvvjgeaspmjntz...@forum.dlang.org).
I can't call break form parallel foreach.
Okey, Is there a way to easily call .stop() from such a case?
Yes there is, but it won’t break the
On Thursday, 24 June 2021 at 20:08:06 UTC, seany wrote:
On Thursday, 24 June 2021 at 19:46:52 UTC, Jerry wrote:
On Thursday, 24 June 2021 at 18:23:01 UTC, seany wrote:
[...]
Maybe I'm wrong here, but I don't think there is any way to do
that with parallel.
What I would do is negate
On Thursday, 24 June 2021 at 19:46:52 UTC, Jerry wrote:
On Thursday, 24 June 2021 at 18:23:01 UTC, seany wrote:
[...]
Maybe I'm wrong here, but I don't think there is any way to do
that with parallel.
What I would do is negate someConditionCheck and instead only
do work when there is work
On Thursday, 24 June 2021 at 18:23:01 UTC, seany wrote:
I have seen
[this](https://forum.dlang.org/thread/akhbvvjgeaspmjntz...@forum.dlang.org).
I can't call break form parallel foreach.
Okey, Is there a way to easily call .stop() from such a case?
Here is a case to consider:
outer:
I have seen
[this](https://forum.dlang.org/thread/akhbvvjgeaspmjntz...@forum.dlang.org).
I can't call break form parallel foreach.
Okey, Is there a way to easily call .stop() from such a case?
Here is a case to consider:
outer: foreach(i, a; parallel(array_of_a)) {
foreach(j, b;
On Thursday, 24 June 2021 at 12:31:08 UTC, Stefan Koch wrote:
On Thursday, 24 June 2021 at 07:28:56 UTC, kinke wrote:
On Thursday, 24 June 2021 at 06:50:44 UTC, Ola Fosheim Grøstad
wrote:
[...]
(I don't think I've ever seen one); with `scope c = new
Object`, you can have the compiler
On Thursday, 24 June 2021 at 05:39:22 UTC, jfondren wrote:
- ok, it's useful that it's like this
Albeit (the grumbling and) the weirdness of it, this is exactly
the reason why I am not complaining on such behavior -time will
show me.
On Thursday, 24 June 2021 at 14:06:11 UTC, seany wrote:
void f() {
a[] * rd;
// DO SOME WORK HERE
this.dataSet = & rd_flattened;
rd = cast (a [] *) dataSet;
write("length of rd is : "); writeln((*rd).length); // <---
this works..
// do some work
I have a struct :
struct a {
int i;
// some more stuff ...
}
In a Class, I define public global `void * dataSet; `
In a function `f`, of the same class: i call :
void f() {
a[] rd_flattened;
a[] * rd;
// DO SOME WORK HERE
this.dataSet =
On Thursday, 24 June 2021 at 07:28:56 UTC, kinke wrote:
On Thursday, 24 June 2021 at 06:50:44 UTC, Ola Fosheim Grøstad
wrote:
[...]
(I don't think I've ever seen one); with `scope c = new
Object`, you can have the compiler allocate a class *instance*
on the stack for you, but `c` is still a
On Thursday, 24 June 2021 at 07:28:56 UTC, kinke wrote:
*scope* classes are deprecated (I don't think I've ever seen
one);
I used it for my database thing where it is supposed to be
destroyed reliably but also uses runtime polymorphism.
I now suggest people just stick `scope(exit)
On Thursday, 24 June 2021 at 06:50:44 UTC, Ola Fosheim Grøstad
wrote:
[...]
Yes, class *refs* are always pointers. *scope* classes are
deprecated (I don't think I've ever seen one); with `scope c =
new Object`, you can have the compiler allocate a class
*instance* on the stack for you, but
D classes are distinct from structs because they are intended to
be bound to a reference (pointer) and not addressed as a value
(inline/copying).
But for efficiency reasons, scoped classes can stack-allocate,
but my understanding is that the compiler can still allocate it
on the GC heap? So
23 matches
Mail list logo
