Re: How to implement Canceleable spawn() from parent

2020-06-29 Thread Ali Çehreli via Digitalmars-d-learn

On 6/29/20 4:34 PM, aberba wrote:

> So with this, without the Thread.sleep() to block main from exiting, the
> spawned thread  will terminate immediately.

You can call core.thread.thread_joinAll at the end of main.

Another way would be to wait for a worker's exit by looking for 
LinkTerminated but you need to start the thread with spawnLinked:


  http://ddili.org/ders/d.en/concurrency.html#ix_concurrency.LinkTerminated

Ali



Re: How to implement Canceleable spawn() from parent

2020-06-29 Thread aberba via Digitalmars-d-learn

On Sunday, 28 June 2020 at 14:23:01 UTC, Stanislav Blinov wrote:

On Sunday, 28 June 2020 at 13:29:08 UTC, aberba wrote:


   [...]



The error you're getting is because you're passing a pointer to 
a delegate instead of a delegate.


[...]


So with this, without the Thread.sleep() to block main from 
exiting, the spawned thread  will terminate immediately. How do I 
keep it from happening? Keep it running continuously?


From the docs, it says OwnerTerminated exception gets thrown when 
the sending thread (e.i. main) is terminated.


Thrown on calls to receive if the thread that spawned the 
receiving thread has terminated and no more messages exist.




scope guard question

2020-06-29 Thread Arjan via Digitalmars-d-learn

```
void main()
{
  import std.stdio;
  auto f = (){
string[] t;
{ // inner scope
  t ~= "hello";
  scope( exit ) t ~= "world";
} // inner scope exit
return t;
  };

  f().writeln; // ["hello", "world"]
}
```
removing the inner scope in f() gives ["hello"]

So when no inner scope is present, the scope exit 'runs' after 
the return? Is that indeed expected behavior according to the 
specification?


Re: scope guard question

2020-06-29 Thread Stanislav Blinov via Digitalmars-d-learn

On Monday, 29 June 2020 at 22:31:12 UTC, Arjan wrote:

So when no inner scope is present, the scope exit 'runs' after 
the return? Is that indeed expected behavior according to the 
specification?


Yes. A scope ends at the '}'. Destructors and scope guards 
execute then, after the return.


Re: scope guard question

2020-06-29 Thread Steven Schveighoffer via Digitalmars-d-learn

On 6/29/20 6:31 PM, Arjan wrote:

```
void main()
{
   import std.stdio;
   auto f = (){
     string[] t;
     { // inner scope
   t ~= "hello";
   scope( exit ) t ~= "world";
     } // inner scope exit
     return t;
   };

   f().writeln; // ["hello", "world"]
}
```
removing the inner scope in f() gives ["hello"]

So when no inner scope is present, the scope exit 'runs' after the 
return? Is that indeed expected behavior according to the specification?


Yes. The return statement is inside the scope of the function, so it 
runs before the scope is exited. Are you saying the spec doesn't say that?


-Steve


Re: How to implement Canceleable spawn() from parent

2020-06-29 Thread Johann Lermer via Digitalmars-d-learn
I'm doing this in an X11 application in order to send a timer 
event every 100 milliseconds to the main event queue.


class Application
{
  shared private bool s_tick;

  void clock_task (shared X11.Display* disp, X11.Atom atom, 
X11.Window win)

  {
for (;;)
{
  try
  {
receiveTimeout (100.msecs);

if (disp && atomicLoad(s_tick))
{
  // disable ticking until it is allowed again at the end 
of the event loop

  atomicStore(s_tick, false);

  X11.XClientMessageEvent event;
  event.type = X11.ClientMessage;
  event.window   = win;
  event.message_type = atom;
  event.format   = 32;
  event.data.l   = [0, 0, 0, 0, 0];

  X11.XSendEvent (cast (X11.Display*) disp, win, 0, 0,  
cast(X11.XEvent*));

  X11.XFlush (cast (X11.Display*) disp);
}
  }
  catch (Throwable)
  {
return;
  }
}
  }

  this ()
  {
...
spawn (_task, cast(shared)x11Display, x11SigClockAtom, 
_x11_proxyWindow);

  }

  run ()
  {
while (true)
{
...
  // event processing starts here: read in X11 event and 
convert it to a wit Event

  X11.XEvent x11_event;
  X11.XNextEvent (_x11.display, _event);
...
  atomicStore(s_tick, true);
}
  }
}


Linking D with C structs

2020-06-29 Thread Anthony via Digitalmars-d-learn

Hello,


I'm trying to hand write some bindings to mongo-c-driver. (For 
learning purposes and to get the latest bindings).


My binding code to convert  to mongoc/mongoc.d 
is:


= c interop file 
module mongoc/mongoc.d;
import core.stdc.stdint;

extern (c) {
struct {
uint domain;
uint code;
char[504] message; //when this exists, the code does not 
compile

}
}
===

= build script 

export 
LD_LIBRARY_PATH=mongo-c-driver/cmake-build/src/libmongoc:mongo-c-driver/cmake-build/src/libbson:$LD_LIBRARY_PATH


dmd hello_mongo.d \
-I=mongo-c-driver/src/libmongoc/src/ \
-I=mongo-c-driver/src/libbson/src/ \
-I=mongo-c-driver/cmake-build/src/libbson/src/bson/ \
-I=mongo-c-driver/cmake-build/src/libmongoc/src/mongoc \
-L=-Lmongo-c-driver/cmake-build/src/libmongoc \
-L=-Lmongo-c-driver/cmake-build/src/libbson \
-L=-lmongoc-1.0 \
-L=-lbson-1.0 \

./hello_mongo



However, when I add the message field in the struct, I cannot 
compile the code:


ld: hello_mongo.o: in function `_Dmain':
hello_mongo.d:(.text._Dmain[_Dmain]+0x1a): undefined reference to 
`_D6mongoc6mongoc13_bson_error_t6__initZ'



What does "__initZ" refer to?
Does this refer to automatic initialization like "this()"?


Re: [DIP1000] Something I don't quite understand regarding 'scope'

2020-06-29 Thread ag0aep6g via Digitalmars-d-learn

On 29.06.20 02:28, Stanislav Blinov wrote:

void local(Args...)(Args args)
{
}

void main() @safe
{
     import std.stdio;
     scope int* p;
     local(p);   // Ok
     writeln(p); // Error: scope variable p assigned to non-scope 
parameter _param_0 calling std.stdio.writeln!(int*).writeln

}

The signatures of `std.stdio.writeln` and `local` are the same (see 
`writeln` [1]). Yet, with '$ dmd -preview=dip1000' the call to `local` 
compiles, while the call to `writeln` doesn't.


Since `local` and `writeln` are templates, the attributes for their 
parameters are inferred from their bodies. `local!(int*)` doesn't do 
anything with the parameter, so it's inferred as `scope`. 
`writeln!(int*)` apparently does something that prevents `scope` from 
being inferred.


Re: Linking D with C structs

2020-06-29 Thread kinke via Digitalmars-d-learn

On Monday, 29 June 2020 at 06:29:38 UTC, Anthony wrote:

What does "__initZ" refer to?
Does this refer to automatic initialization like "this()"?


Almost, it's the static initializer for that struct, which is 
omitted because you apparently don't compile/link the module 
containing the struct declaration. Initialize the char array with 
zeros (= 0) to make the struct fully zero-initialized, preventing 
the need for that symbol. chars in D are initialized with 0xFF, 
unlike byte and ubyte.


Waiting on file descriptor/socket *AND* thread messages

2020-06-29 Thread ichneumwn via Digitalmars-d-learn

Dear all,

Is there some facility in D for a single statement/function call 
that will wait on both file descriptors, like Socket.select(), 
and will also wake up when there is something to be receive()'d?


One solution would be to have my main thread use receive() and a 
helper thread that does the select() call and sends a message to 
the main thread. That seems a bit of overkill however.


Apologies if this has been asked before, but my google search and 
search in this thread were fruitless (could be my searching 
skills)


Cheers



Re: [DIP1000] Something I don't quite understand regarding 'scope'

2020-06-29 Thread Stanislav Blinov via Digitalmars-d-learn

On Monday, 29 June 2020 at 06:21:43 UTC, ag0aep6g wrote:

Since `local` and `writeln` are templates, the attributes for 
their parameters are inferred from their bodies. `local!(int*)` 
doesn't do anything with the parameter, so it's inferred as 
`scope`. `writeln!(int*)` apparently does something that 
prevents `scope` from being inferred.


Thanks. It would appear indeed that inference fails for some 
reason. Explicitly marking args as 'scope' for `writeln` and 
`File.write` lets them compile. I wonder if there's a way to find 
exactly what it is in either of those that prevents the compiler 
from inferring 'scope'.


Re: Waiting on file descriptor/socket *AND* thread messages

2020-06-29 Thread Steven Schveighoffer via Digitalmars-d-learn

On 6/29/20 5:14 AM, ichneumwn wrote:

Dear all,

Is there some facility in D for a single statement/function call that 
will wait on both file descriptors, like Socket.select(), and will also 
wake up when there is something to be receive()'d?


Not in the standard library. Such things require an event framework, 
because there is no OS-agnostic provided mechanism to sleep on all these 
things at once.


I recommend looking through code.dlang.org. I found these:

https://code.dlang.org/packages/libasync
https://code.dlang.org/packages/eventcore
https://code.dlang.org/packages/mecca (this seems very underdocumented, 
but I know it provides such a system)




One solution would be to have my main thread use receive() and a helper 
thread that does the select() call and sends a message to the main 
thread. That seems a bit of overkill however.


I don't know the correct way to solve this, I've done it in the past by 
creating a file descriptor that can be waited on to wake up the target 
along with any other file descriptors being waited on.


-Steve


Re: Waiting on file descriptor/socket *AND* thread messages

2020-06-29 Thread ichneumwn via Digitalmars-d-learn
On Monday, 29 June 2020 at 12:25:16 UTC, Steven Schveighoffer 
wrote:

On 6/29/20 5:14 AM, ichneumwn wrote:

[...]


Not in the standard library. Such things require an event 
framework, because there is no OS-agnostic provided mechanism 
to sleep on all these things at once.


I recommend looking through code.dlang.org. I found these:

https://code.dlang.org/packages/libasync
https://code.dlang.org/packages/eventcore
https://code.dlang.org/packages/mecca (this seems very 
underdocumented, but I know it provides such a system)



[...]


I don't know the correct way to solve this, I've done it in the 
past by creating a file descriptor that can be waited on to 
wake up the target along with any other file descriptors being 
waited on.


-Steve


Thanks for the pointers Steve!


Re: Light-weight runtime

2020-06-29 Thread Kagamin via Digitalmars-d-learn

On Sunday, 28 June 2020 at 07:09:53 UTC, Виталий Фадеев wrote:

I want light-weight runtime !

How to ?


Runtime provides language features that rely on extra code. 
Removing that code from runtime means to give up on corresponding 
language features. This way you can implement only features you 
want or even reduce runtime to almost zero. You can start by not 
linking your code with druntime and see what's missing and see if 
you can evade or implement the feature.


Re: Calling C functions

2020-06-29 Thread Steven Schveighoffer via Digitalmars-d-learn

On 6/26/20 4:15 AM, Jacob Carlborg wrote:

On Friday, 26 June 2020 at 00:30:22 UTC, Denis wrote:

I have a two questions about calling C functions from D.

(1) When passing a D callback to a C function, is there a way to write 
the code without having to prefix the callback declaration with 
"extern(C)"?


It's not a big deal adding the prefix to the D function declaration. 
It just seems odd to me to prefix D code with "extern(C)". For 
example, the following code works:


  extern(C) void cfunc(void function(int));
  extern(C) void dcallback(int x) {...}    <-- Why extern(C)?
  cfunc();

Can this be rewritten, dropping the prefix from the second line? If 
not, it would be helpful to know why "extern(C)" is needed here too.


No, it cannot be dropped. `extern(C)` is required because C and D are 
using different calling conventions (D functions are also mangled). For 
example, D (at least DMD and LDC) are passing the arguments to the 
function in reverse.


Are you sure? On the ABI page [1] , it says "The extern (C) and extern 
(D) calling convention matches the C calling convention used by the 
supported C compiler on the host system."


I'm pretty sure you can use function pointers to D functions for C 
callbacks, and it should work.


-Steve

[1] https://dlang.org/spec/abi.html#function_calling_conventions


Re: Calling C functions

2020-06-29 Thread Jacob Carlborg via Digitalmars-d-learn
On Monday, 29 June 2020 at 16:34:33 UTC, Steven Schveighoffer 
wrote:


Are you sure? On the ABI page [1] , it says "The extern (C) and 
extern (D) calling convention matches the C calling convention 
used by the supported C compiler on the host system."


In that case the documentation is wrong. Here's an example 
showing the differences:


$ cat foo.c
#include 

void foo(int a, int b)
{
printf("a=%d b=%d\n", a, b);
}
$ clang -c foo.c
$ cat main.d
pragma(mangle, "foo") extern (D) void foo_extern_d(int, int);
pragma(mangle, "foo") extern (C) void foo_extern_c(int, int);

void main()
{
foo_extern_d(1, 2);
foo_extern_c(1, 2);
}
$ dmd main.d foo.o
$ ./main
a=2 b=1
a=1 b=2

This is on macOS.

--
/Jacob Carlborg


Re: Calling C functions

2020-06-29 Thread Steven Schveighoffer via Digitalmars-d-learn

On 6/29/20 1:50 PM, Jacob Carlborg wrote:

On Monday, 29 June 2020 at 16:34:33 UTC, Steven Schveighoffer wrote:

Are you sure? On the ABI page [1] , it says "The extern (C) and extern 
(D) calling convention matches the C calling convention used by the 
supported C compiler on the host system."


In that case the documentation is wrong. Here's an example showing the 
differences:


Yep, for sure. I'll file an issue. Anyone know why the calling 
convention would differ?


-Steve