Re: Unexpected threads observed before main()

2021-02-28 Thread Keivan Shah via Digitalmars-d-learn

On Monday, 1 March 2021 at 06:50:42 UTC, rikki cattermole wrote:

Do you still get them when you call your app like this?

./app --DRT-gcopt=parallel:0


Wow, Not getting with "--DRT-gcopt=parallel:0", Thanks a lot, 
didn't know GC had a parallel option that can be 
controlled(https://dlang.org/spec/garbage.html#gc_parallel). If 
possible, Can you also help me understand that why are the 
threads not despawned once the GC is done collecting in this 
example?


Re: Unexpected threads observed before main()

2021-02-28 Thread rikki cattermole via Digitalmars-d-learn

Do you still get them when you call your app like this?

./app --DRT-gcopt=parallel:0


Unexpected threads observed before main()

2021-02-28 Thread Keivan Shah via Digitalmars-d-learn
I had recently updated my dmd version to latest, i.e from 2.076.1 
(I know, sorry) to 2.095.0 and suddenly my code has started 
spawning extra threads which were not there before with no 
obvious reasons, after trying to simplify and identify the cause 
as much as possible, I have come up with this snippet of code:


module test;
// PART 1
class SomeClass
{
}
static this() // Works in both cases, "static this" as well as 
"shared static this"

{
new SomeClass;
}

// PART 2
class TestThread
{
static this() // Works in both cases, "static this" as well 
as "shared static this"

{
import core.memory;
GC.collect;
}
}

void main() // Voila! Extra 5 threads before starting main!
{
import std;
import core.thread;
auto pid = getpid;
// Linux hack to prevent having to do `top` and check num of 
threads
writeln(" NumThreads: ", dirEntries("/proc/" ~ pid.to!string 
~ "/task/", SpanMode.shallow).array.length);
// writeln("PID: ", pid, " NumThreads: ", 
Thread.getAll.length); // This doesn't seem to give the right 
number

while(true){}
}

This when running on my local Linux machine with dmd-2.095.0 
shows that 6 threads are running but on running with dmd-2.076.1 
(Sorry, haven't tried on all other dmds in between) gives only 1 
thread. Something seems to be off here and to make it even more 
confusing, when running this on run.dlang.io, it seems to only 
give 1 thread. Is there something obviously wrong that I am doing 
or this could be a potential bug in D runtime?


Re: Does reserve() preallocate for futher appends too?

2021-02-28 Thread Jack via Digitalmars-d-learn

On Monday, 1 March 2021 at 03:12:42 UTC, Adam D. Ruppe wrote:

On Monday, 1 March 2021 at 03:07:19 UTC, Jack wrote:
isn't clear for me if reserve() does preallocate memory so 
that that operator like arr ~= x can use previously allocate 
memory by reserve() or it's just used in slices like b = arr[x 
.. y]?


Slicing never allocates memory. reserve extends the capacity 
for the ~= operator.


thanks


Re: Does reserve() preallocate for futher appends too?

2021-02-28 Thread Adam D. Ruppe via Digitalmars-d-learn

On Monday, 1 March 2021 at 03:07:19 UTC, Jack wrote:
isn't clear for me if reserve() does preallocate memory so that 
that operator like arr ~= x can use previously allocate memory 
by reserve() or it's just used in slices like b = arr[x .. y]?


Slicing never allocates memory. reserve extends the capacity for 
the ~= operator.


Does reserve() preallocate for futher appends too?

2021-02-28 Thread Jack via Digitalmars-d-learn
isn't clear for me if reserve() does preallocate memory so that 
that operator like arr ~= x can use previously allocate memory by 
reserve() or it's just used in slices like b = arr[x .. y]?


Re: How do I check if a type is assignable to null at compile time?

2021-02-28 Thread Jack via Digitalmars-d-learn

On Saturday, 27 February 2021 at 01:23:06 UTC, H. S. Teoh wrote:
On Sat, Feb 27, 2021 at 01:03:56AM +, Jack via 
Digitalmars-d-learn wrote:

On Friday, 26 February 2021 at 23:37:18 UTC, Murilo wrote:
> On Friday, 26 February 2021 at 05:25:14 UTC, Jack wrote:
> > I started with:
> > 
> > enum isAssignableNull(T) = is(T : Object) || isPointer(T);
> > 
> > but how do I cover all cases?
> 
> You can check if it's null with this `variable is null` and 
> you can test it with assert as in `assert(variable is null);`


I mean a give type T not variablee


Why not just:

enum isAssignableNull(T) = is(typeof((T t){ t = null; }));

?


T


works too, thanks but I ended up using Nathan S. solution which 
is quite fine too:

 enum bool isAssignableNull(T) = is(typeof(null) : T);




Re: Name mangling problem with tiny Windows 10 load-time DLL example

2021-02-28 Thread WhatMeWorry via Digitalmars-d-learn

On Sunday, 28 February 2021 at 22:10:21 UTC, Siemargl wrote:

On Sunday, 28 February 2021 at 18:29:11 UTC, WhatMeWorry wrote:
It seems pretty obvious the problem is with name mangling. But 
how to fix it?



fixing

   int numb = 1;


and your example work correct

ldc 1.24 / win10

P.S.I'm not recommend using such keywords as 'file', may cross 
with other modules.


I double checked my posting and of course works it now works!?!?  
I've been having trouble where it works and then it doesn't. I've 
been using examples with file.d, file1.d, file2.d, etc.  I also 
came across the note that Windows file system is not case 
sensitive. Or is that case in-sensitive?


This worked fine for Linux (Ubuntu) so you might be on to 
something.


Re: Name mangling problem with tiny Windows 10 load-time DLL example

2021-02-28 Thread Siemargl via Digitalmars-d-learn

On Sunday, 28 February 2021 at 18:29:11 UTC, WhatMeWorry wrote:
It seems pretty obvious the problem is with name mangling. But 
how to fix it?



fixing

   int numb = 1;


and your example work correct

ldc 1.24 / win10

P.S.I'm not recommend using such keywords as 'file', may cross 
with other modules.


Re: Name mangling problem with tiny Windows 10 load-time DLL example

2021-02-28 Thread Kagamin via Digitalmars-d-learn

mangleof should give _D4file6addOneFiZi, not _D6patron6addOneFiZi


Name mangling problem with tiny Windows 10 load-time DLL example

2021-02-28 Thread WhatMeWorry via Digitalmars-d-learn
It seems pretty obvious the problem is with name mangling. But 
how to fix it?


--
module file;
extern(D) export
{
int addOne(int i) { return (i + 1); }
}
--
module patron;
import file;
void main()
{
import std.stdio;
int n = 1;
writeln("mangled name of addOne is ", addOne.mangleof);
numb = addOne(numb);
}
--
ldc2 -m64 -c file.d
ldc2 -m64 -c patron.d

ldc2 -m64 -shared file.obj -ofloadTime.dll
   Creating library loadTime.lib and object loadTime.exp

Both dumpbin /exports loadTime.lib and dumpbin /exports 
loadTime.dll

shows:  _D4file6addOneFiZi  

ldc2 patron.obj loadTime.lib

patron.exe
mangled name of addOne is _D6patron6addOneFiZi

// and library function is never called. Does not abend though???

---

So the library function is named _D4file6addOneFiZi while the 
user wants to call _D6patron6addOneFiZi


So which name is "correct" and how do I get them to agree with 
each other?






Re: vibe.d selectively include attribute into tag using diet template

2021-02-28 Thread Steven Schveighoffer via Digitalmars-d-learn

On 2/28/21 12:29 AM, JG wrote:

On Saturday, 27 February 2021 at 19:12:55 UTC, Steven Schveighoffer wrote:


If you use an expression without quotes
in diet, it becomes an interpolation.


Would you mind explaining in more detail what this means? How could one 
use this, other than with booleans?


So if you have an expression as the right side of an attribute 
assignment, it is treated as a D expression, which is then evaluated and 
turned into string form.


So e.g. your original example:

tag(attribute='#{dexpression}')

can be written as:

tag(attribute=dexpression)

-Steve


Re: How can I make this work?

2021-02-28 Thread Adam D. Ruppe via Digitalmars-d-learn

On Sunday, 28 February 2021 at 07:05:27 UTC, Jack wrote:
I'm using a windows callback function where the user-defined 
value is passed thought a LPARAM argument type. I'd like to 
pass my D array then access it from that callback function. How 
is the casting from LPARAM to my type array done in that case?


The best way to do this is to put the array inside a struct and 
pass the address of the struct instead. This way both length and 
pointer are passed, and you have the option to add more things if 
you ended up needing it later, and there's fewer weird things to 
worry about.


int[] arr = [1, 2, 3];

struct MyMessage {
 int[] arr;
}

// this far is easy enough
MyMessage* messagePointer = new MyMessage(arr);

// but we do need to tell the GC we intend to pass this to the 
outside world
// failure to do this MIGHT lead to random crashes as the GC 
can't see it (it can't look inside the Windows message queue), 
assumes it is unused, and frees it out from under you.

import core.memory;
GC.addRoot(messagePointer);

// when the GC has a root, it will consider that pointer live 
until further notice and not collect it nor its member variables.


// so it is now cool to do this
PostMessage(hwnd, MSG_WHATEVER, 0, cast(LPARAM) messagePointer);


/* then on the other side */

switch(iMsg) {
   case MSG_WHATEVER:
   MyMessage* messagePointer = cast(MyMessage*) lParam;

   // need to tell the GC the pointer can be automatically 
managed normally again. failure to do this will lead to a memory 
leak

   import core.memory;
   GC.removeRoot(messagePointer);

   // now can use it
   foreach(item; messagePointer.arr) {
  // yada yada yada
   }
}



And it is the simplest thing, no missing length, no weird 
property casting. The GC handled with two simple add/remove calls.


Re: dub git dependencies

2021-02-28 Thread Andre Pany via Digitalmars-d-learn

On Sunday, 28 February 2021 at 11:11:27 UTC, bogdan wrote:

Hi,

I remember that I saw a while ago some PRs related to adding a 
git url for a dependency in the dub's package.json. I looked 
today in the docs and I can't find any info about this. What is 
the progress for this feature? Can we use it already?


https://dub.pm/package-format-json.html#version-syntax


Bogdan


Yes, it is there, whether it is already documented somewhere I do 
not know.


See an example here:
https://github.com/dlang/dub/blob/05165362127aadad088fd178622c83c03393411b/test/git-dependency/dub.json

Kind regards
Andre



dub git dependencies

2021-02-28 Thread bogdan via Digitalmars-d-learn

Hi,

I remember that I saw a while ago some PRs related to adding a 
git url for a dependency in the dub's package.json. I looked 
today in the docs and I can't find any info about this. What is 
the progress for this feature? Can we use it already?


https://dub.pm/package-format-json.html#version-syntax


Bogdan


Re: How can I make this work?

2021-02-28 Thread rikki cattermole via Digitalmars-d-learn

On 28/02/2021 11:05 PM, Max Haughton wrote:

Do the windows APIs expect the length in memory rather than as a parameter?


This sounds like its being sent via a user field to be passed to a callback.

I.e. event loop for a window.

In this sort of case you only get one parameter on the callback and it 
is only big enough for a pointer.


Re: How can I make this work?

2021-02-28 Thread Max Haughton via Digitalmars-d-learn

On Sunday, 28 February 2021 at 09:18:56 UTC, Rumbu wrote:

On Sunday, 28 February 2021 at 09:04:49 UTC, Rumbu wrote:

On Sunday, 28 February 2021 at 07:05:27 UTC, Jack wrote:
I'm using a windows callback function where the user-defined 
value is passed thought a LPARAM argument type. I'd like to 
pass my D array then access it from that callback function. 
How is the casting from LPARAM to my type array done in that 
case?


for example, I need something like this to work:

int[] arr = [1, 2, 3];
long l = cast(long) cast(void*) arr.ptr;
int[] a = cast(int[]) cast(void*) l;


LPARAM is not long on 32 bits, it's int. Use LPARAM instead of 
long.


And you are passing only the address of the first element this 
way, loosing the array/slice length. This should work, but keep 
in mind that you have no warranty that the array stays in 
memory and it is not garbage collected.


int[] arr = [1, 2, 3];
LPARAM l = cast(LPARAM)cast(void*)
int[] a = *cast(int[]*)(cast(void*)l);


Do the windows APIs expect the length in memory rather than as a 
parameter?


Also Rumbu can you check your email - I may have emailed you on 
an old email address by accident, but it's about the blog and it 
will be from mh240@...


Re: How can I make this work?

2021-02-28 Thread Rumbu via Digitalmars-d-learn

On Sunday, 28 February 2021 at 09:04:49 UTC, Rumbu wrote:

On Sunday, 28 February 2021 at 07:05:27 UTC, Jack wrote:
I'm using a windows callback function where the user-defined 
value is passed thought a LPARAM argument type. I'd like to 
pass my D array then access it from that callback function. 
How is the casting from LPARAM to my type array done in that 
case?


for example, I need something like this to work:

int[] arr = [1, 2, 3];
long l = cast(long) cast(void*) arr.ptr;
int[] a = cast(int[]) cast(void*) l;


LPARAM is not long on 32 bits, it's int. Use LPARAM instead of 
long.


And you are passing only the address of the first element this 
way, loosing the array/slice length. This should work, but keep 
in mind that you have no warranty that the array stays in memory 
and it is not garbage collected.


int[] arr = [1, 2, 3];
LPARAM l = cast(LPARAM)cast(void*)
int[] a = *cast(int[]*)(cast(void*)l);




Re: How can I make this work?

2021-02-28 Thread Rumbu via Digitalmars-d-learn

On Sunday, 28 February 2021 at 07:05:27 UTC, Jack wrote:
I'm using a windows callback function where the user-defined 
value is passed thought a LPARAM argument type. I'd like to 
pass my D array then access it from that callback function. How 
is the casting from LPARAM to my type array done in that case?


for example, I need something like this to work:

int[] arr = [1, 2, 3];
long l = cast(long) cast(void*) arr.ptr;
int[] a = cast(int[]) cast(void*) l;


LPARAM is not long on 32 bits, it's int. Use LPARAM instead of 
long.




Re: How can I make this work?

2021-02-28 Thread rikki cattermole via Digitalmars-d-learn

On 28/02/2021 8:05 PM, Jack wrote:

int[] arr = [1, 2, 3];

size_t l = cast(size_t)arr.ptr;

Okay, so far so good


int[] a = cast(int[]) cast(void*) l;


Umm, you haven't specified a length?

int[] a = (cast(int*)l)[0 .. 3];

If the callback is being called (in effect under the current stack frame 
and won't escape), I would wrap the data you need in a struct and pass 
that to it instead by pointer. No need for heap allocation and gives a 
way to pass more complex data should the need arise.