Re: ImportC: Should this compile?

2021-12-18 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 19 December 2021 at 03:27:50 UTC, Tejas wrote:

Oh wow, the executable gets named `stuff` if that's the first 
file passed... always thought it would name it the same name as 
that file which contained `main`


If the name of the file with `main` were used, you'd have to have 
a different default for libraries. Executables and libraries get 
the name of the first source file passed on the command line by 
default. This can be overridden with -of.


Re: ImportC: Should this compile?

2021-12-18 Thread Mike Parker via Digitalmars-d-learn

On Saturday, 18 December 2021 at 22:31:38 UTC, bachmeier wrote:
I've been trying to get the stb header library to compile. 
There's a single remaining failure:


```
typedef struct
{
   unsigned char c[4];
} stb_easy_font_color;
stb_easy_font_color c = { 255,255,255,255 }; // use structure 
copying to avoid needing depending on memcpy()

```

LDC returns

```
stb_easy_font.c(892): Error: 3 extra initializer(s) for `struct 
__tag21`

```

Is this a bug in ImportC or is it correct that it doesn't 
compile? What's the best way to fix it while keeping the same 
behavior and performance?


Unless C11 has changed the rules about nested initializers, that 
should compile. You might try explicit nesting:


```d
stb_easy_font_color c = { {255,255,255,255} };
```

And please file an issue if there isn't one already.


(I don't know what struct __tag21 is. It's not anywhere in the 
source. Assuming that's just a bad error message.)


A "tag" is the name of a struct or union, which follows the 
keyword:


```c
struct Foo {};
```

Here, `Foo` is the tag. Instances of the struct must be declared 
as `struct Foo`. Think of it like this: `int` is required in 
declarations of instances of type `int`, so `struct` is required 
in declarations of type `struct`; the "tag" specifies which 
struct type, hence `struct Foo x`.


`typedef` introduces an alias:

```c
typedef struct Bar {} Bar;
```

So `Bar` is now an alias for `struct Bar`, and instances can be 
declared as `Bar x`.


Your example is like this:

```c
typedef struct {} stb_easy_font_color;
```

No tag is specified, so the compiler must generate one. In your 
case, it's `__tag21` and `stb_easy_font_color` is an alias for 
`struct __tag21`.


And yes, using the generated tag in the error message is not at 
all helpful without the alias. Please file an issue on this, too.


Re: Passing a derived class where base class is defined as ref parameter

2021-12-13 Thread Mike Parker via Digitalmars-d-learn

On Monday, 13 December 2021 at 22:06:45 UTC, chopchop wrote:

If I remove the ref, it works as expected, that is to say I can 
give a derived class as parameter. I have an idea why it does 
not work, but I think a c++ reference would work, ie incr(A& 
console) would accept a B as parameter. What the logic here?


TL:DR it's because there are two levels of indirection.

What's happening here is that `ref A` in D *is not* equivalent to 
`A&` in C++. That's because D classes are reference types like 
Java classes, not value types like C++ classes. Your `b` is a 
handle to an instance, not an instance itself. It's more akin to 
`B*` in C++. So that means that your `ref A` is like `A**` in 
C++. And I believe you'll find that `B**` in C++ is not 
implicitly convertible to `A**`.


Since `ref` in D is just a pointer under the hood, we can be more 
explicit like so:


```d
void incr(A* a)
{
writeln(a.i);
}

B b = new B();
incr();
```

In this case, compilation also fails. `B*` is not implicitly 
convertible to `A*`. Again, this is equivalent to `B**` and `A**` 
in C++.


In this case, you can explicitly do the conversion with a cast: 
`incr(cast(A*));`


But consider what happens in this case:

```d
void incr(A* a)
{
*a = new A;
}

B b = new B();
incr(cast(A*));
writeln(b.j);
```

Your `b` is no longer a `B`, but still thinks it is.

This is my understanding of why implicit conversion is disallowed 
when multiple levels of indirection are involved.


Re: A pass() identity range?

2021-12-02 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 2 December 2021 at 15:03:47 UTC, D Lark wrote:

Because it does not seem like that from the tone of responses I 
have gotten: I did my due diligence, I believe, before posting 
my original reply to the old question. I had looked at the docs 
and also searched the forum. There is no need for the 
patronizing tone you have taken.


No one has been patronizing to you. They were just explaining the 
informal custom in these forums. Please don't take it the wrong 
way.


The forum software is a web interface to a newsgroup server. The 
software could be enhanced to prevent posting to old threads, but 
there's never been a need to (and people would still be able to 
post through the newsgroup server anyway). It's a fairly common 
convention across the internet (and has been for years) that 
reviving old threads is frowned upon (the term often used is 
"necroposting"). Normally, the warning provided is enough.


So let's leave this thread to Rest in Peace. And next time you 
attempt to post an old thread here, please allow the forum 
software to do it's thing when it warns you. Thanks!


Re: How to deploy single exe application (?)

2021-11-28 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 28 November 2021 at 22:45:29 UTC, Willem wrote:


// load sdl
string uuid = randomUUID().toString();
string filename = format("SDL2-%s.dll", uuid);
string depacked = buildPath(tempDir(), filename);
std.file.write(depacked, sdlBytes);
DerelictSDL2.load(depacked);

// load curl
string uuid2 = randomUUID().toString();
string filename2 = format("libcurl-%s.dll", uuid2);
string depacked2 = buildPath(tempDir(), filename2);
std.file.write(depacked2, curlBytes);
DerelictSDL2.load(depacked2);



`DerelictSDL2.load()` cannot load curl. It is not a generic dll 
loader. It only loads SDL and doesn't know anything about curl or 
any other library.


In order to dynamically load curl like this, you need a binding 
that supports it, i.e., a binding that declares the curl API as 
function pointers and knows how to load them from the DLL.


Also, DerelictSDL2 is no longer maintained. Please use bindbc-sdl 
for new projects:


http://bindbc-sdl.dub.pm/


Re: Are templated functions always re-constructed?

2021-11-16 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 16 November 2021 at 21:14:50 UTC, rempas wrote:

Let's say that I have the following function:

```
void add(T)(T val, T val2) { return val + val2; } // Classic 
example, lol

```

Now let's say that I call the function passing an `int` 
parameter. The function will get built with an `int` type. What 
happens the second time that I will call it again? Will it get 
the already build function or will it make a new one? I suppose 
it re-uses it but still I wanted to ask just in case. Please 
only answer if you are sure and not be making guesses because 
it is really important! Thanks!


You might find this useful:

https://dlang.org/blog/2020/07/31/the-abcs-of-templates-in-d/


Re: D modules

2021-11-13 Thread Mike Parker via Digitalmars-d-learn

On Saturday, 13 November 2021 at 22:52:55 UTC, pascal111 wrote:
When I'm searching for "toUpper" and "toLower" functions that 
string type uses, I confused when I reached the module 
"std.string". In the first section of its page 
"https://dlang.org/phobos/std_string.html; I didn't found 
functions I'm searching for, but when I pressed ctrl+f and 
typed function names, I found 'em in another section of the 
page, but I didn't understand if I have to add something to 
module name "std.string" or not, and I don't know how modules 
divided nor its sections way in D. I hope someone clarifies 
this obscure point to me and how can I search correctly for 
sought functions.


Those functions used to be in `std.string` a long time ago and 
are no more. As did some others. The section where you found them 
in the `std.string` docs is a table listing their current 
location in `std.uni` and links to their documentation. It also 
says this just above the table:



The following functions are publicly imported:


This means if you are already importing `std.string`, you do not 
need to import `std.uni` for `toUpper` and `toLower`, as 
`std.string` publicly imports them, so they will be available for 
you to use. So you can use those functions by importing 
`std.string` or `std.uni`.


https://dlang.org/phobos/std_uni.html#.toLower
https://dlang.org/phobos/std_uni.html#.toUpper


Re: Average function using Variadic Functions method

2021-11-02 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 2 November 2021 at 16:35:40 UTC, pascal111 wrote:



"input..." seems nice, where can I get more information about 
it?


"Typesafe variadic functions"

https://dlang.org/spec/function.html#typesafe_variadic_functions



Re: Why do we have Dmain?

2021-10-22 Thread Mike Parker via Digitalmars-d-learn

On Friday, 22 October 2021 at 05:54:21 UTC, Kirill wrote:
I am not a compiler expert, but I genuinely would like to know 
why we have Dmain.


I've been looking at the generated assembly code recently and 
noticed the _Dmain function. I didn't notice it before. Then 
there is main, where Dmain is called.


Why is that?


The entry point for your program is a function `_start`. That's 
implemented in the C runtime, which all D programs depend on. It 
in turn calls `main`, as it does for C and C++ programs.


The D compiler generates an `extern(C) main` function that hands 
control off to DRuntime for initialization, then in turn calling 
your application `main` (a.k.a. `_DMain`).


See:
https://github.com/dlang/druntime/blob/master/src/rt/dmain2.d#L245

If you declare your main function as `extern(C)`, then the 
compiler does not generate one and you get handed control from 
the C runtime. Which in turn means you have to handle 
initialization of the D runtime yourself.





Re: problem with alias this and Tuple

2021-10-12 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 12 October 2021 at 15:55:40 UTC, Johann Lermer wrote:
Thanks, understood. But isn't this a deficiency in the library 
that should be fixed?


The problem extends to more than just `toHash`. Take a look at 
this DConf 2019 presentation by Eduard Staniloiu on ProtoObject 
(as proposed by Andrei Alexandrescu):


https://youtu.be/EcG5mnOzZ0s

Eduard is now mentoring a Symmetry Autumn of Code participant 
(Robert Aron) whose project is implementing `ProtoObject`. You 
can get a summary of the project from Robert's first weekly 
update thread here:


https://forum.dlang.org/post/wezzcgwbnaguawzfh...@forum.dlang.org


Re: Managing malloced memory

2021-10-11 Thread Mike Parker via Digitalmars-d-learn

On Monday, 11 October 2021 at 10:53:15 UTC, anon wrote:


S makeS(int x)
{
   return S(x); // no destructor called here.
}

void main()
{
   foo(S(1)); // no destructor called for this rvalue
   auto s = makeS(1);
   // destructor for s called here.
   foo(makeS(1)); // only one destructor called at the end of 
foo

}
```
Is there any reference for exactly how these rules apply, or is 
this implementation defined? The 
[specification](https://dlang.org/spec/struct.html#struct-destructor) says that destructors are called when objects go out of scope. Your examples seem to suggest that this is untrue in some cases.


For example, in `makeS` the initializer combined with the return 
triggers an optimization (return value optimization, or RVO)) 
that elides a copy of the struct, meaning there's nothing to 
destroy at the end of `makeS`. The destruction will occur in the 
scope into which the instance is moved.


Any time you have a named instance, like `S s = S(1)`, you can 
pretty much guarantee its destructor will be called. An exception 
is when `s` is returned immediately after the initialization, 
then NRVO (named return value optimization) can kick in to elide 
the copy and, therefore, the destruction again happens at the end 
of the scope into which the instance is moved.


Play around with a struct destructor that prints a message and 
you'll get a feel for when destructors are and aren't called. 
Like Steve said, it's once per copy. Sometimes you end up with 
temporaries that are destroyed, sometimes you don't depending on 
compiler optimizations.


Re: Traits in a template enum

2021-10-10 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 10 October 2021 at 12:56:30 UTC, Some Guy wrote:

But I did not understand what you meant by "enums hold values, 
not types". Aren't types values at compile time?


Types can be template arguments, if that's what you mean, but 
they aren't values.


Re: Dynamically binding to D code using extern(D)

2021-09-30 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 30 September 2021 at 22:30:30 UTC, jfondren wrote:

3. dynamic linking (option 2), performed arbitrarily at 
runtime, by your program. If linking fails, you can do whatever 
you want about that.


That's actually "dynamic loading".

https://en.wikipedia.org/wiki/Dynamic_loading


Re: Using D "rocket" logo in outside presentation

2021-09-28 Thread Mike Parker via Digitalmars-d-learn
On Wednesday, 29 September 2021 at 04:24:13 UTC, Chris Piker 
wrote:

Hi D

I'm to give a presentation to a combined NASA/ESA group in a 
few hours and would like to include a copy of the D "rocket" 
logo when mentioning new server side tools that I've written in 
D.  Is such use of this particular [D 
logo](https://i0.wp.com/dlang.org/blog/wp-content/uploads/2021/08/logo_256.png?w=750=1) permissible?


Thanks,


Yes!


Re: Loading assimp

2021-09-28 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 28 September 2021 at 16:30:09 UTC, Eric_DD wrote:

I am trying to use a newer version of Assimp.
I have found a assimp-vc140-mt.dll (v3.3.1) which I renamed to 
assimp.dll


When running my executable it throws a 
derelict.util.exception.SharedLibLoadException:


"Failed to load one or more shared libraries:
assimp.dll - %1 is not a valid Win32 application.
Assimp64.dll - The specified module could not be found"

Any idea what's going on? Are 64bit dlls not supported?


I'm not maintaining the package anymore, but this is an error 
from the system loader and has nothing to do with the binding 
itself. It's the sort of error that usually pops up when trying 
to load a 32-bit DLL into a 64-bit program, or vice versa. Are 
you sure it's a 64-bit DLL?


Re: Modules ... "import" vs. "compilation" ... what is the real process here?

2021-09-27 Thread Mike Parker via Digitalmars-d-learn
On Monday, 27 September 2021 at 17:38:29 UTC, james.p.leblanc 
wrote:

Dear D-ers,

I have trouble understanding "module imports" vs. "module 
compilations".


A module is implemented in a source file. Though we often use the 
term "module" to refer to both, it may help to think in terms of 
importing modules and compiling source files.


Given the source files `A.d` and `B.d`, which implement the 
modules A and B respectively, and given that module A uses 
symbols from module B, then we can say the following:


1. When the compiler is compiling `A.d`, it must be aware of 
which symbols from module B are accessible from module A. This is 
what imports are for and has no relation to the compilation 
status of `B.d`.
2. The compiler will produce a `A.o/obj` object file that it will 
then pass to the linker,  including references to the symbols in 
module B. At that point, the linker will also need an object file 
from a compiled `B.d` in order to fix up the symbol references 
and produce the final executable.


To achieve #1, the compiler needs to read either the source file 
`B.d` or a D interface file, `B.di`, in order to know which 
symbols are available to module A. There are a couple of ways 
this can happen:


```
dmd A.d B.d
```

Here, when the compiler encounters `import B` in `A.d`, it will 
recognize that `B.d` has been passed on the command line. If 
`B.d` has no module statement, then the file name `B` is used as 
the module name. If it has a module statement, it the file can be 
named anything when it's passed on the command line like this. It 
could be `foo.d`, but as long as it has a `module B` at the top, 
then `A.d` can `import B`.


```
dmd -c A.d
```

Here, when the compiler encounters `import B` in `A.d`, it will 
see that no `module B` declaration has been encountered in any 
other files on the command line, so it will search for `B.di` 
and, if it's not found, `B.d` on the import path (to which we can 
append directories with `-I`). I've included `-c` here, which 
will just compile `A.d` and not attempt to link it, because 
without it the linker will spew errors for every missing symbol 
from module B.


This is how D supports separate compilation. Assuming object 
files with the `.obj` extension on Windows, you could do this:


```
dmd -c B.d
dmd A.d B.obj
```

Now, the compiler uses the source of `B.d` to assess symbol 
accessibility as before, and it will pass both `A.obj` and 
`B.obj` to the linker to produce the executable.


Or you could compile `B.d` into `B.lib` and pass that on the 
command line as well.




Finally, there have been discussions about allowing new ways of 
"compiling a module" by including its name on the command line. 
 For example this from 2017:


https://forum.dlang.org/post/tcrdpvqvwxffnewzo...@forum.dlang.org


This is what resulted in the `-i` compiler switch. Modifying the 
example above:


```
dmd -i A.d
```

Now, when the compiler encounters `import B` in `A.d`, if there 
is no `B.di` and it finds `B.d`, it will compile `B.d` alongside 
`A.d`, just as if the command line had been `dmd A.d B.d`.


Does that help?




Re: MobI? Really?

2021-09-21 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 21 September 2021 at 16:14:52 UTC, Chris_D wrote:

Thanks for the replies.

jfondren: Sorry, but I am talking about documentation.  For me, 
online web pages don't qualify; they are in the cloud, unreal, 
with no substance.  Does anyone really read 300 pages online, 
in a web browser?  Of course not.


I do! As far as I know, that's how most D users read the D docs. 
The docs do ship with DMD, though. On Windows, there's an `html` 
folder in the installation tree. I don't know how they're 
installed on other platforms.


Re: How to simply parse and print the XML with dxml?

2021-09-10 Thread Mike Parker via Digitalmars-d-learn

On Friday, 10 September 2021 at 07:50:29 UTC, tastyminerals wrote:



As for the dxml, I believe adding a small quick start example 
would be very beneficial for the newcomers. Especially, ppl 
like me who are not aware of the XML parser types and just need 
to extract text from an XML file.


Submit a request:

https://github.com/jmdavis/dxml/issues

I don't know how active Jonathan is these days, but it won't get 
implemented at all if no one requests it.


Re: GDC - program runs in one thread, DMD - in 4 threads, why?

2021-09-10 Thread Mike Parker via Digitalmars-d-learn

On Friday, 10 September 2021 at 11:20:10 UTC, eugene wrote:



same picture with gdc 8.4.0 - one thread, no pthread_create() 
behind the scenes.


GDC is stuck on a much older version of D. Iain has backported 
some bugfixes and optimizations, but featurewise it's mostly D 
2.076. This is because that's the last version of the D frontend 
implemented in C++, and he needed that to get gdc into gcc. As 
bauss pointed out, the library feature you're talking about was 
implemented in 2.087. Iain is working on porting gdc over to the 
D version of the D frontend, at which point it will be much more 
up-to-date.


Re: Forum posting question ... how post a thread question with color syntax highlighting ??

2021-09-06 Thread Mike Parker via Digitalmars-d-learn
On Monday, 6 September 2021 at 13:23:21 UTC, Steven Schveighoffer 
wrote:




I will note though, that some people use the mechanism for 
links that puts the link at the bottom of the post, and this 
can be annoying when you reply, if you don't include the link 
definition, it doesn't render correctly.




Now that's interesting. I had assumed it would be less annoying 
than having them inline. Especially since people had already 
adopted a similar convention before we got Markdown support. I 
gave up on Thuderbird and went full-on with the web interface a 
couple of years ago, so I've had no view of the experience 
post-Markdown.





Re: Forum posting question ... how post a thread question with color syntax highlighting ??

2021-09-05 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 5 September 2021 at 23:24:16 UTC, someone wrote:


Slightly off-topic but ... while-we-are-the-subject:

I usually post with markdown enabled and enclose code within 
```d


Sometimes, I notice that replies to my posts came without 
markdown, and until now, I assumed not everyone likes markdown 
so when I reply once again I do it without markdown even while 
it is far more difficult to read the post (from my point of 
view, that is).


Question is: is it considered bad-etiquette within this forum 
to reply with markdown-enabled to someone using no-markdown at 
all ?


For example; IIRC Ali's posts are always no-markdown.


It doesn’t matter. Some people access the forums via the 
newsgroups or mailing lists, so they’re going to see the raw 
markdown in every post that uses it, whether it’s a direct reply 
to them or not.


Markdown support is mostly for the web interface, and is a 
minimally intrusive way to provide it so that it’s not too 
disruptive for people not using it.





Re: Dustmite and linking error

2021-09-04 Thread Mike Parker via Digitalmars-d-learn

On Saturday, 4 September 2021 at 08:19:53 UTC, JG wrote:

As a small comment regarding dub. I can't help wondering if it 
really the best idea for each configuration to include 
everything by default and then have to exclude things? This 
means that when you add another configuration and source files 
for it you very often have to modify all other existing ones. 
If instead you choose what to include this wouldn't happen. 
Wild cards support could be added for included files to make 
projects with a single configuration just as simple as now. 
Just some thoughts. (I feel the same way regarding gitignore, I 
would rather have the opposite.)


You should be able to do that now with "sourceFiles" and 
"sourcePaths". Just avoid the default "source" or "src" 
directories and specify the paths and/or files you want for each 
configuration.


Re: Question on Immutability

2021-08-31 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 31 August 2021 at 06:15:07 UTC, jfondren wrote:

On Tuesday, 31 August 2021 at 05:42:22 UTC, ag0aep6g wrote:

On 31.08.21 02:50, Mike Parker wrote:
Member functions marked as immutable can be called on both 
mutable and immutable instances.


That's not true.


Demonstrated:


Well I'm really on my A game lately.


Re: Question on Immutability

2021-08-30 Thread Mike Parker via Digitalmars-d-learn

On Monday, 30 August 2021 at 23:27:07 UTC, Merlin Diavova wrote:


```
After playing around the above works, Great! However I have 
some questions


First, why do the interfaces have to be defined as `immutable 
interface`?

The interfaces cannot be changed at runtime or instantiated.


It isn't required. And that's related to the answer to the next 
question.




Secondly, why does defining the return type for withName as 
`Project` give the `Error: 'immutable' method 
'winry.project.Project.name' is not callable using a mutable 
object`. However changing it to `immutable(Project)` works as 
expected.




Applying immutable to a class or interface does not make 
instances immutable. It makes member functions callable on 
immutable instances. Example:


```d
import std.stdio;

interface Foo {
void bar() immutable;
}

class Baz : Foo {
void bar() immutable { writeln("Boo!"); }
}

void main()
{
immutable(Baz) b = new Baz;
b.bar();

}
```

Notice my application of immutable on the declarations of the 
member functions. This means that the `bar` function is callable 
through immutable instances of `Foo`.


When you apply immutable to the interface declaration, it has the 
effect of applying it to every member function. You can see that 
from the compilation error output when we modify the above to 
this:


```d
import std;

immutable interface Foo {
void bar();
}

class Baz : Foo {
void bar() { writeln("Boo!"); }
}

void main()
{
immutable(Baz) b = new Baz;
b.bar();

}
```

```d
onlineapp.d(7): Error: class `onlineapp.Baz` interface function 
`void bar() immutable` is not implemented

```

Member functions marked as immutable can be called on both 
mutable and immutable instances. Member functions without it can 
only be called on mutable instances.


This applies to const as well.


Re: Labelled @nogc Working With Inner Scopes

2021-08-30 Thread Mike Parker via Digitalmars-d-learn

On Monday, 30 August 2021 at 20:26:46 UTC, Benoît Dubreuil wrote:



My question is:
In the source file `dummy.dummy.d`, why the first labelled 
attributes `@safe` and `@nogc` have no effect inside the 
struct's scope? In other words, why do I need to repeat 
labelled attributes statements in order to affect inner scopes?


To test this, simply remove in `dummy.dummy.d` the *TODO* 
comment and its following labelled attributes.


Attributes used to propagate into aggregate definitions, but it 
was changed a long time ago. I don't recall the reason why.


Re: Is it legal to remove a key from associative array while iterating over aa.keys if a foreach loop?

2021-08-29 Thread Mike Parker via Digitalmars-d-learn
On Sunday, 29 August 2021 at 11:09:28 UTC, Steven Schveighoffer 
wrote:




This is exactly the opposite!



Sorry about that. I can't believe I mixed those up.


Re: Is it legal to remove a key from associative array while iterating over aa.keys if a foreach loop?

2021-08-29 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 29 August 2021 at 08:55:44 UTC, realhet wrote:




Is it safe, or do I have to take a snapsot of the keys range 
like this? ->


You shouldn't remove anything when iterating over `.keys` or 
`.values`. Use `.byKey` and `.byValue` instead to get ranges that 
are independent of the aa.


Re: DUB: How to link an external library on Windows 10?

2021-08-27 Thread Mike Parker via Digitalmars-d-learn

On Friday, 27 August 2021 at 14:46:56 UTC, Ki Rill wrote:
On Friday, 27 August 2021 at 13:54:18 UTC, Steven Schveighoffer 
wrote:

[...]


How do I tell DUB where to look for `raylibdll.lib` and 
`raylib.dll`? Via `lflags` section? What if I put them in a 
different folder instead of the project's directory?


Yes. The path goes in the lflags directive using whatever the 
linker-specific flag is. I assume for lld it's `-Lpath`. For MS 
link it's `/LIBPATH:path`.


Re: DUB: How to link an external library on Windows 10?

2021-08-27 Thread Mike Parker via Digitalmars-d-learn

On Friday, 27 August 2021 at 13:41:56 UTC, Ki Rill wrote:



I have downloaded the pre-compiled binaries from the official 
[Raylib ](https://github.com/raysan5/raylib/releases/tag/3.7.0) 
repo.


I'm not using Visual Studio. Only dub and a text editor.


But assuming you are on a 64-bit system, the DMD will use Visual 
Studio's linker if you have it installed. If you don't, it will 
use the lld linker it ships with. Either way, you need to raylib 
to be compiled with he same version of the MS Build tools so that 
you don't have conflicts the the vs runtime.


Re: DUB: How to link an external library on Windows 10?

2021-08-27 Thread Mike Parker via Digitalmars-d-learn

On Friday, 27 August 2021 at 13:21:04 UTC, Ki Rill wrote:
I have a Raylib project on Windows using DUB. I've added 
raylib-d via `dub add`. But what I can't figure out is how to 
tell DUB to link against raylib library.


I have the following project structure:
```
-> source
---> app.d
-> libraylib.a
-> raylib.dll
-> etc...
```

I'd like to use either .a or .dll. Do you have any ideas?


raylib.a isn't going to get you anywhere. You'll run into issues 
mixing MinGW-compiled libraries.


If raylib doesn't ship precompiled VS binaries, then, assuming 
you have Visual Studio (or the MS Build tools) installed, you 
should compile Raylib with that same version. Then you'll have a 
new raylib.dll and a raylib.lib. Add raylib.lib to your dub 
config via the "libs" directive.





Re: dlang opengl / gl / glu /glut library.

2021-08-22 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 22 August 2021 at 12:22:41 UTC, Виталий Фадеев wrote:

https://forum.dlang.org/post/s5pvtq$2q83$1...@digitalmars.com

On Wednesday, 21 April 2021 at 19:54:35 UTC, rikki cattermole 
wrote:


On 22/04/2021 7:51 AM, Alain De Vos wrote:

import bindc.opengl;


bindbc


bindbc-opengl provides glu* functions ?
gluNewTess
gluTessCallback
gluTessProperty
gluTessNormal
gluDeleteTess

able?


No. As far as I know, glu isn’t maintained anymore.


Re: Non-consistent implicit function template specializations

2021-08-17 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 17 August 2021 at 09:59:53 UTC, Rekel wrote:

time in the future. Even bugs don't seem to get fixed in any 
timely manner (Not meant as an insult, just being realistic :/).


We do have a paid Issue/Pull-Request manager now (Razvan Nitu), 
and he's prioritizing issues for strike teams composed of 
volunteers willing to fix them. If you find a specific bug that 
is a blocker or a major headache, make a post about it here in 
the forums.


Sometimes, the reason a bug hasn't been fixed is simply that it 
hasn't caught the attention of the right person. With Razvan in 
place, it's more likely such issues will be resolved, or at least 
moved up on the priority list, if you let him know about them. A 
forum post is an easy way to do that while also bringing it to 
the attention of others who may be looking for something to work 
on.


Re: Non-consistent implicit function template specializations

2021-08-17 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 17 August 2021 at 09:59:53 UTC, Rekel wrote:
When using implicit function templates, identical 
specialization yield different results.

Example:

```d
template TFoo(T){ void foo(){writeln("1");} } // #1
template TFoo(T : T[])  { void foo(){writeln("2");} } // #2

void foo(T)(){
writeln("1");
}

void foo(T : T[])(){
writeln("1");
}

void main(string[] args) { // Works
TFoo!(int).foo();// "1"
TFoo!(double[]).foo();   // "2"
foo!(int)();// "1"
foo!(double[])();   // "1" !
}
```

I'm fairly certain the last call _should_ yield "2", yet it 
does not.


The error is in your code. Both of your `foo` templates are 
implemented to print `"1"`. Change the second one to print "2" 
and you will see the desired output.


At any rate, to specialize on arrays you should generally be 
using something like `T : U[], U`. Ditto for pointers: `T : U*, 
U`.


Re: how to import .lib library

2021-08-15 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 15 August 2021 at 10:40:36 UTC, jfondren wrote:



Yeah, that's not possible. You either need the source or a set 
of D interface files that declares all the symbols you need.


Meaning, it is possible. On Windows where I assume these .lib 
files are:


I mentioned C libraries in an earlier post. But the OP did not 
say whether the library is a C library or a D one. If it's a D 
library, then you can't simply declare the functions locally 
because the module name is part of the fully-qualifed name. You 
absolutely need the source or the interface files.


Declaring C functions locally where you need them is fine if you 
only need a handful of sybmols. But when you need multiple 
functions and types from the API, that's going to get unwieldy.


Re: how to import .lib library

2021-08-15 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 15 August 2021 at 10:12:17 UTC, Timofeyka wrote:


Thank you for your reply!
I wanted to link to my project another project without source 
code.


Yeah, that's not possible. You either need the source or a set of 
D interface files that declares all the symbols you need. The 
compiler *has* to be able to see the symbols to know what's 
available for you to use.


Re: how to import .lib library

2021-08-15 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 15 August 2021 at 09:49:39 UTC, Timofeyka wrote:

Hello!
I may have a very stupid question, but still.
How do I include a .lib library? How to use it in your code?


You don't import a .lib file. They are for the linker, not the 
compiler. How you make use of it depends on what sort of library 
it is and how you're building your project.


If this is all new to you, it will be easier just to specify here 
which library it is that you're wanting to use, then I or someone 
else can give you directions. But the general idea is as follows.


If it's a D library, you'll need access to the source code (or 
alternatively, D interface files that have a .di extension, but 
that's another topic). That's what you use at compile time via 
the `import` statement. When you import, for example, 
`std.stdio`, you are importing the module from the Phobos source 
tree that ships with the compiler.


If the library is registered with the dub repository, then you 
can use dub to manage and build your project to make life easier. 
The library's source will be available to import, and dub will 
build the library and make sure it's linked.


If the library is not registered with dub, you'll need to 
download the source somewhere, make sure it's on the import path 
(use the `-I` switch on the compiler command line with the source 
path, e.g., `-I/path/to/source`), you'll need to make sure the 
library is compiled separately from your project, and then you'll 
need to give the lib file to the compiler on the command line 
along with your source (e.g., `dmd app.d library.lib`).


If it's a C library, you'll need to translate the C API to D (not 
the source code, just the type and function declarations) if it 
hasn't been done already. Then you import the translated D files 
and give the .lib file to the compiler as above.


Re: What exactly are the String literrals in D and how they work?

2021-08-15 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 15 August 2021 at 08:11:39 UTC, rempas wrote:



I mean that in C, we can assign a string literal into a `char*` 
and also a `const char*` type without getting a compilation 
error while in D, we can only assign it to a `const char*` 
type. I suppose that's because of C doing explicit conversion. 
I didn't talked about mutating a string literal


The D `string` is an alias for `immutable(char)[]`, immutable 
contents of a mutable array reference (`immutable(char[])` would 
mean the array reference is also immutable). You don't want to 
assign that to a `char*`, because then you'd be able to mutate 
the contents of the string, thereby violating the contract of 
immutable. (`immutable` means the data to which it's applied, in 
this case the contents of an array, will not be mutated through 
any reference anywhere in the program.)


Assigning it to `const(char)*` is fine, because `const` means the 
data can't be mutated through that particular reference (pointer 
in this case). And because strings in C are quite frequently 
represented as `const(char)*`, especially in function parameter 
lists, D string literals are explicitly convertible to 
`const(char)*` and also NUL-terminated. So you can do something 
like `puts("Something")` without worry.


This blog post may be helpful:

https://dlang.org/blog/2021/05/24/interfacing-d-with-c-strings-part-one/



Re: Create alias of same name in inner scope, bug or feature?

2021-08-13 Thread Mike Parker via Digitalmars-d-learn

On Saturday, 14 August 2021 at 03:47:05 UTC, Tejas wrote:

```d
import std;
auto abc(T)(auto ref T a, auto ref T b){
return a+b;
}

auto def(T)(auto ref T a, auto ref T b){
return a*b;

}
alias macro_1 = abc;
void main()
{
writeln(macro_1(15, 20));
alias macro_1 = def;// is this NOT considered variable 
shadowing?

writeln(macro_1(100, 20));

}
```


Shadowing local symbols is illegal. But it's okay for local 
symbols to have the same name as module-scope symbols. You can 
disambigbuate with [the module scope operator][1]:


```d
void main()
   macro_1(); // the local symbol
   .macro_1(); // the external symbol
}
```

[1]: https://dlang.org/spec/module.html#module_scope_operators


Re: Help with Win32: PostQuitMessage(0) doesn't post WM_QUIT apparently, because the message loop is not exited.

2021-08-13 Thread Mike Parker via Digitalmars-d-learn
On Friday, 13 August 2021 at 21:36:35 UTC, Ruby The Roobster 
wrote:




Thank you very much.  The program runs successfully now.


You've got another potential issue you should be aware of. You've 
name a member of your `Skeleton` as `init`. This may cause issues 
at some point, as every type in D has a default `init` property, 
even structs. You shouldn't use that name in any type you define.


Re: Help with Win32: PostQuitMessage(0) doesn't post WM_QUIT apparently, because the message loop is not exited.

2021-08-13 Thread Mike Parker via Digitalmars-d-learn
On Friday, 13 August 2021 at 21:10:38 UTC, Steven Schveighoffer 
wrote:


Well, subtracting the length doesn't do much, you aren't 
actually accessing the array block, you are just changing the 
reference (which lives in thread-local storage). I kind of feel 
like the whole entity table thing is not correct anyway. Did 
you (Mike) also comment out the `did` call? Because that looks 
more suspicious to me. What it is doing is going through all 
the entities from the removed one on and setting their id to 1 
less. HOWEVER, it's not actually *moving* the entities down in 
the array.


I suspected the `did` function first, but the issue persisted 
when I commented out the call in the destructor. I didn't know 
what to think when I found that commenting out the `.length` 
deprecation eliminated it.





I suspect there is a memory access violation or some other 
issue that's causing it to crash rather than exit normally.


It's not crashing. It's hanging.



Re: Help with Win32: PostQuitMessage(0) doesn't post WM_QUIT apparently, because the message loop is not exited.

2021-08-13 Thread Mike Parker via Digitalmars-d-learn
On Friday, 13 August 2021 at 16:18:06 UTC, Ruby The Roobster 
wrote:


Context for this: I am creating a module of my  own, and this 
is a class contained in the module.  You will notice that after 
calling this class' constructor anywhere in a Win32 API 
program, that the program doesn't close after the window is 
closed.


You're hanging in `Runtime.terminate`. That's because of your 
`Entity` destructor, specifically this line:


entitytable.length -= 1;

Comment it out and the program exits successfully.

You aren't supposed to be manipulating GC-managed memory via 
class destructors. You can not rely on that memory being valid at 
the time that it's accessed in the destructor---the object may 
already have been destroyed. Nondeterministic destruction is the 
price you pay for letting the GC manager your object memory.


Of course, in this case, the problem will only crop up at 
termination since the array is declared at module scope so will 
be live up until the GC shuts down. But still, not something you 
should be doing.


The runtime will help you by throwing an error if you do anything 
that directly triggers an allocation, like calling `new` or 
performing an array append. But it won't help you with anything 
else.


Someone more versed than I with the GC innards may be able to 
answer whether an error should be thrown here as well, or if this 
goes under the undefined behavior category.


Re: Help with Win32: PostQuitMessage(0) doesn't post WM_QUIT apparently, because the message loop is not exited.

2021-08-12 Thread Mike Parker via Digitalmars-d-learn
On Friday, 13 August 2021 at 00:30:59 UTC, Ruby The Roobster 
wrote:




When I run the program and close the window, the program still 
runs in background mode.  I don't know why this happens nor how 
to fix it.  Does anybody know what's going on?


frame beat me to it, but it may well be that you're getting -1. 
[The documentation][1] says that a window that has already been 
destroyed will result in the `hWnd` parameter being invalid, 
which will cause the function to return -1.



[1]: 
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getmessage#return-value


Re: DUB "Error: only one `main` allowed."

2021-08-11 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 11 August 2021 at 09:38:13 UTC, tastyminerals wrote:



Hahaha, I fixed it by renaming the `my_script.d` to `app.d`. Oh 
boy.


What you want is the `mainSourceFile` entry. From the dub 
documentation, [under "Build Settings"][1]:


Determines the file that contains the main() function. This 
setting can be used by dub to exclude this file in situations 
where a different main function is defined (e.g. for "dub 
test") - this setting does not support platform suffixes


`app.d` has special significance to dub in that it automatically 
triggers the executable target type if it's present. I assume dub 
also considers it the main source file by default if you have one.


[1]: https://dub.pm/package-format-json.html#build-settings


Re: -L/SUBSYSTEM:windows Error when using -m64

2021-08-10 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 10 August 2021 at 19:03:06 UTC, Marcone wrote:

On Tuesday, 10 August 2021 at 19:01:42 UTC, Adam D Ruppe wrote:

On Tuesday, 10 August 2021 at 18:59:33 UTC, Marcone wrote:

Using -Lgdi32.lib -Luser32.lib? Same error.


The part after that:

If you want the Windows subsystem too, use 
-L/subsystem:windows -L/entry:mainCRTStartup.



Pass BOTH -L/subsystem:windows AND -L/entry:mainCRTStartup


Good! work very well! Thank you!


The difference is because DMD uses different linkers on Windows.

By default, it links 32-bit programs with OPTLINK. That linker 
only requires the subsystem flag---it will recognize that you 
have a `main` function.


When compiling with -m32mscoff or -m64, it uses the Microsoft 
linker. That linker requires that you also specify the program 
entry function---it always expects `WinMain`, and the 
`mainCRTStartup` tells it to look for `main` instead.


Re: Conditional compilation: Which version identifier for release code ? version(assert) ?

2021-08-05 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 5 August 2021 at 10:43:01 UTC, wjoe wrote:




Could you elaborate on ```version(assert)``` a bit more, please 
? Like I compiled with ```-release, -g``` and without the 2 
options but the ```assert``` branch was always taken. Could it 
be that ```-unittest``` has something to do with it ?


Yes, -unittest overrides -release and enables asserts. 
-check=assert=off overrides both.


I agree with Adam about avoiding -release. -debug is useful. 
-release, not so much since we have finer control over 
enabling/disabling checks these days.





Re: Conditional compilation: Which version identifier for release code ? version(assert) ?

2021-08-05 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 5 August 2021 at 09:18:08 UTC, wjoe wrote:
If it's to be determined whether or not the code is being 
compiled in debug or release mode, i.e. e.g. the dmd 
```-release``` or ```-g``` options, which version identifier is 
supposed to be used ?


There's no ```release``` identifier and ```-debug``` switch and 
```debug()``` condition are something else.


There's ```assert - Checks are being emitted for 
AssertExpressions```. With the exception for ```assert(0)```, 
those checks are omitted in release mode so this could be used 
for that purpose, right?


I don't think it would make much sense to have a 
`version(release)`, as there's really no such thing as a "release 
mode", or a "debug mode" either. -release is just a shorthand to 
disable certain features that you can also disable individually, 
and -debug means whatever you want it to mean.


Given that we have `version(assert)` and 
`version(D_NoBoundsChecks)`, it probably makes sense to also have 
equivalents to test if contracts are enabled, or if bounds 
checking is enabled only in safe code. Then you'd be able to 
cover all the bases that -release does. Sounds like a candidate 
for an enhancement request.


Re: alias using Complex!Double in module ... linker error??

2021-08-03 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 3 August 2021 at 21:40:09 UTC, james.p.leblanc wrote:

I am getting linker errors with this stripped-down example:

---
**my_main.d:**

import std.stdio;
import std.complex;
import my_module;


void main(){
  my_TYPE xxx;
  writeln(xxx);
}

---
**my_module.d:**

module my_module;

import std.complex;

alias my_TYPE = Complex!double;*// this causes link error: 
"undefined reference"*


/* alias my_TYPE = double; */  *// this works fine*

--

Why does the linker fail when I alias to the Complex!double ...
but would work fine when alias to the double ??

Any help to understand what is greatly appreciated.
James


The alias to Complex!double is a template instantiation. A 
template instantiation creates a symbol that needs to be linked. 
So you need to compile my_module.d along with my_main.d.


```
dmd my_main.d my_module.d
```

Or alternatively:

```
dmd -i my_main.d
```

double is a built-in type, so that alias doesn't create any 
symbols that need linking.


An alias in and of itself is a compile-time-only construct, but 
the symbols you assign it might require linking something.


Re: Name Mangling & its representation of D types

2021-08-03 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 3 August 2021 at 16:43:52 UTC, NonNull wrote:
how does it work for recursive types like a struct containing a 
pointer to a struct of the same type


A struct `S` with a member of type `S*` is still just a struct 
`S`. The pointer doesn't change anything about the type.




Re: Name Mangling & its representation of D types

2021-08-03 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 3 August 2021 at 16:43:52 UTC, NonNull wrote:
I'd like to understand how any D type is represented as a 
string by the name mangling done by the compilers.


Does this always have the desirable property that different 
types have different mangled names, so that a type is 
faithfully represented by its mangled string incorporated into 
a symbol name in an object file?


What is that representation of a type as a string, and how does 
it work for recursive types like a struct containing a pointer 
to a struct of the same type?


Please explain.


Name mangling applies to function parameters, as described here:

https://forum.dlang.org/thread/akshntlfahjpknsxd...@forum.dlang.org

Type names aren't mangled. They have a Fully Qualified Name (FQN) 
which is constructed from package(s), module, parent.


So for example:

```d
module mypack.mymod;

import std.stdio;

struct S
{
struct Is {}
}

void main()
{
writeln(typeid(S));
writeln(typeid(S.Is));
}
```

This prints:

```
mypack.mymod.S
mypack.mymod.S.Is
```


Re: D compiler equivilent of "gcc -E" for debug/view template instantiation(generated) code?

2021-07-30 Thread Mike Parker via Digitalmars-d-learn

On Friday, 30 July 2021 at 08:38:24 UTC, dangbinghoo wrote:



but, where's these switch option documented? it seems it not 
appears in dmd --help or man dmd, or online document 
https://dlang.org/dmd-linux.html





That's what he meant by "hidden" switch. I don't know why it 
isn't documented, but it probably should be.


Re: Raylib linking error

2021-07-29 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 29 July 2021 at 10:07:15 UTC, Ki wrote:

On Thursday, 29 July 2021 at 07:59:38 UTC, Ki wrote:

I tried to compile a new project with Raylib yesterday:
dub init => ... => dub add raylib-d.

My dub.json file does contain the "libs": ["raylib"] section, 
so the compiler links against raylib library. Then I built the 
project and got a linker error referencing a whole bunch of 
opengl, glfw functions.


Does anyone know what is the problem here?

I am a little puzzled on what to try next, but to build raylib 
myself from source (I use brew to manage packages).


It seems I need to link Cocoa and IOKit frameworks, but how do 
I tell this to DUB? I'm browsing the dub documentation and 
cannot find anything framework-related.


My answer on reddit:

The -framework flag on Mac is a linker flag. Linker flags are 
handled in DUB via the lflags entry. Assuming XLinker is being 
used, it should probably look something like this:


```
"flags": ["-framework", "CoreVideo", "-framework", "IOKit"]
```

In other words, a string for the -framework flag and the 
framework name for each of the frameworks you need. Because 
according to the forum thread below, passing them to DMD directly 
requires the -L switch (meaning, the library flag switch) for 
both -framework and the name.


(Ignore the bit about the link pragma in that thread... that's 
specific to an old build tool that's no longer around).


https://forum.dlang.org/post/gp3uk2$gnd$1...@digitalmars.com


Re: byKeyValue is not available at compilation-time right ?

2021-07-26 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 25 July 2021 at 17:38:23 UTC, someone wrote:


i.e. your AA initialization is copy-pasted into each use of 
it, which means your program is rebuilding this AA at runtime 
every time it comes up. You probably got to this point as a 
bare `immutable structureLocations` errored out to the 
non-constant expression.


Sounds bad, inefficient at least :(


The whole point of a manifest constant is that it is purely a 
compile-time entity that does not exist at runtime. It has no 
address. In other words, `enum a = 10` can be seen as an alias to 
the integer literal `10`. That means anywhere you use `a`, it's 
just like you typed in `10` instead. It is *not* the same as a 
`const` or `immutable` value.


Think of them as a way to avoid "magic literals". Instead of 
typing `10` or `[1, 2, 3]` in multiple initializers or function 
calls, you use an alias instead, then when you decide to use `20` 
or `[2, 4, 6]` instead, you can simply change the declaration of 
the manifest constant instead of at multiple locations. But 
you're *still* effectively passing a literal. So if at certain 
points in your code you want to avoid any allocations a literal 
would trigger, then you shouldn't be using manifest constants at 
those points either.


Re: Destructors can't be @nogc?

2021-07-24 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 25 July 2021 at 00:15:30 UTC, Jim wrote:



But I think `destroy()` not being @nogc even though the 
destructor is tagged @nogc is a bug, and it should be fixed. 
Because it is problematic behaviour even if we limit the usage 
of @nogc.


It's not a bug. The destructor being tagged has nothing to do 
with it. destroy can call @nogc destructors just fine. It just 
can't itself be called in @nogc functions.


As Paul described, the root reason is down to rt_finalize. Were 
it marked @nogc, then you could call destroy from @nogc code, but 
you wouldn't be able to call destructors that aren't @nogc---an 
even worse situation, IMO.


I think it's worth looking into how we can make destroy (or an 
alternative) available in @nogc functions as an enhancement. It's 
possible for extern(C) functions to be templated, so that might 
be a potential path. With a templated rt_finalize (or an 
alternative) then perhaps attribute inference could kick in and 
make destroy (or an alternative) callable in both @nogc functions 
and non.





Re: Destructors can't be @nogc?

2021-07-24 Thread Mike Parker via Digitalmars-d-learn

On Saturday, 24 July 2021 at 09:45:01 UTC, Jim wrote:



In that case, what should we use to check functions called from 
`main` are not using the garbage collector?


When compiling, you can pass -vgc to dmd and it will tell you 
where GC allocations are possible.




Because it seems like we can't use classes with `@nogc`. We can 
write `.deinit()` for all our classes but what about the 
existing ones?


You're trying to shoehorn a GC-based feature into a no-GC world. 
It's possible, but it takes consideration of your overall 
architecture. If you're wanting to prevent GC usage in the entire 
program, then the easiest way is to avoid features that normally 
rely on the GC.


Consider if you really need classes. Can you just use malloced 
structs instead? If you do need classes, perhaps for inheritance, 
then scoped classes can be allocated on the stack where possible; 
then you get automatic destruction like structs. If you want to 
allocate them from the heap as in your example, then you can wrap 
instances in a ref-counted struct that calls a custom destructor 
(like your .deinit). You could also try marking your classes as 
extern(C++), then the GC isn't involved anyway.


There are many options, but in bypassing D's built-in automatic 
memory management, you're going to have to work for each of them 
to one degree or another.


Personally, I think `@nogc` on main is a bad idea. `@nogc` should 
be used as far down the call stack as you can put it. The higher 
it is, the more difficulty you're going to run into. I recommend 
you apply it only on functions that run in the hottest parts of a 
program. Those are the areas where GC allocations triggering 
collections can obviously become an issue. So start there.


If, down the road, you find that you've got some GC performance 
troubles outside of @nogc code, -dvst can help you find areas 
where you may be calling it unexpectedly and you can refactor 
those parts as needed and still do so without applying @nogc.


You can also look into disabling the GC at specific points and 
renabling later, or manually run collections at certain points. 
These are tools that are available that may or may not help.


You might get some ideas from the GC series on the blog:

https://dlang.org/blog/the-gc-series/

But if you really want to zap GC from the entire program, you're 
better of with -betterC. You aren't going to be using any 
GC-based features anyway, so why worry about @nogc? Everything is 
@nogc by default in betterC as the GC doesn't exist.





Re: Destructors can't be @nogc?

2021-07-23 Thread Mike Parker via Digitalmars-d-learn

On Friday, 23 July 2021 at 20:24:02 UTC, Jim wrote:

What is the problem here? Should I not call `destroy`? If so, 
what should I call instead?


The problem is that you've marked main as `@nogc`, and `destroy` 
is not `@nogc`. Remove the annotation from main and it will 
compile.


Re: betterC shared static ctor

2021-07-21 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 21 July 2021 at 08:11:06 UTC, vit wrote:

Is it possible to call all shared static ctors in betterC?

```d
//-betterC

static immutable int i;

shared static this(){
i = 42;
}
extern(C) void main(){
assert(i != 42);

}
```


These rely on DRuntime, which is not linked in betterC mode. 
You'll need to use the `crt_constructor` and `crt_destructor` 
pragmas:


https://dlang.org/spec/pragma.html#crtctor

Apply them to any `extern(C) function for static ctor/dtor 
behavior.


Re: Not allowed to globally overload operators?

2021-07-20 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 20 July 2021 at 06:20:34 UTC, Tejas wrote:

Why isn't it working by default?

Initially, I was trying to create the spaceship operator of 
C++, but we aren't allowed to create new operators, it seems. 
Then I just wanted to verify whether we can even overload an 
operator globally, but even that seems to be failing, atleast 
for me.


From the docs:

Operator overloading is accomplished by rewriting operators 
whose operands are class or struct objects into calls to 
specially named members.


https://dlang.org/spec/operatoroverloading.html

Note the word "members".

See also:

https://dlang.org/articles/rationale.html#why-no-global-operator-functions



Re: Module import failing after $ dub add mypackage

2021-07-16 Thread Mike Parker via Digitalmars-d-learn

On Friday, 16 July 2021 at 17:14:12 UTC, Mike Parker wrote:

I haven't had occasion to make use of any serialization 
libraries myself, but you can start here:


https://wiki.dlang.org/Serialization_Libraries


Also:

https://code.dlang.org/search?q=serialization


Re: Module import failing after $ dub add mypackage

2021-07-16 Thread Mike Parker via Digitalmars-d-learn

On Friday, 16 July 2021 at 16:54:18 UTC, Scotpip wrote:

Yup - I have it running now but the code does seem to be a bit 
neglected and I'm seeing a depreciation warning too. I chose it 
because it's much the most downloaded serialisation package and 
is used in a couple of other popular packages. But it seems to 
be moribund...


The deprecation message is from the most recent dmd release:

https://dlang.org/changelog/2.097.0.html#body-deprecation

It's been a year since the last commit (which actually involved 
linking with winsock...), but I wouldn't write it off as near 
death just yet.




I simply need a fast binary serialisation lib to read and write 
a large list of structs to local disk - it's not for inter-app 
communication. The struct is simple and only contains primitive 
D data types. If you are aware of any package that would be a 
better bet I'd appreciate your advice. Or is there a more 
direct way to dump a list from memory to disk and read it back 
again? This is the kind of low-level stuff that's rather new to 
me...


I haven't had occasion to make use of any serialization libraries 
myself, but you can start here:


https://wiki.dlang.org/Serialization_Libraries


Re: Module import failing after $ dub add mypackage

2021-07-16 Thread Mike Parker via Digitalmars-d-learn

On Friday, 16 July 2021 at 16:44:31 UTC, Scotpip wrote:

Again, if this helps anyone my current setup is to have a 
single main() in app.d. I changed the main() in my sandboxes to 
runSandbox(), and I import and run from app.d rather than 
directly. Or with a couple of keystrokes I can switch to 
running the full app. This seems to be a practical workflow 
that plays properly with the build system.


If anyone has a better suggestion, I'd appreciate your tips.


You might look into dub configurations. The first configuration 
that matches the current platform is the default, and other can 
be specified on the command line with `dub -cConfigName` (or 
`--config=ConfigName`).


Here's are two configurations in SDLang format from one of my 
projects:


// Default library config.
configuration "dolce" {
targetType "staticLibrary"
targetPath "lib"
targetName "dolce"
excludedSourceFiles "source/dolce/dev/*"
}

// Development config for testing/experimenting.
configuration "dolceDev" {
targetType "executable"
targetPath "bin"
targetName "dolceDev"
}

Files for the executable are in `source/dolce/dev`, so I just 
exclude them from the library builds. In your case, you might 
have two mains and do something like this:


targetType "executable"

configuration "default" {
excludedSourceFiles "source/sandbox/*"
}
configuration "sandbox" {
exludedSourceFiles "source/app.d"
}

Or maybe the sandbox config could just add a version:

configuration "sandbox" {
versions "Sandbox"
}

Then you can conditionally compile as needed:

void main()
{
version(Sandbox) {
import sandbox : runSandbox;
runSandbox();
} else {
// Normal main stuff here
}
}







Re: Module import failing after $ dub add mypackage

2021-07-16 Thread Mike Parker via Digitalmars-d-learn

On Friday, 16 July 2021 at 15:31:49 UTC, Scotpip wrote:




I'm completely stuck till I can get this fixed, so any help 
would be very much appreciated!


I used the example from the readme at:

https://code.dlang.org/packages/msgpack-d

which I pasted into the generated `app.d`. And all the command 
lines were:


```
dub init myproject
cd myproject
dub add msgpack-d
dub
```

Compiled fine. I did encounter some missing symbols, though 
(`ntohl` and `ntohs`) as msgpack-d isn't linking with Ws2-32.lib. 
I added `pragma(lib, "Ws2_32")` to the top of the file to resolve 
it. (And I filed an issue: 
https://github.com/msgpack/msgpack-d/issues/120).


Once the linker issues were resolved, all was well.



Re: opIndexUnary post in-/decrement how to ?

2021-07-14 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 14 July 2021 at 12:35:07 UTC, wjoe wrote:

On Wednesday, 14 July 2021 at 11:31:36 UTC, Tejas wrote:


``` {auto a = i[1] , ++i[1] , a} //note the , not the ;```

Sorry I can't provide something even more concrete.


Yes I saw that, and I suppose it would work just fine if it 
were rewritten to just  ```++i[1]```.
What I'm struggling to understand is the ```{auto a = i[1], ... 
,a}``` part. I can't parse that. What's up with the assignment 
and the comma stuff ?


It's how the contract of post-inc/dec work---pre-inc/dec return 
the modified value, post-inc/dec return the original value.


```d
int i = 1;
assert(++i == 2);
int j = 1;
assert(j++ == 1);
```
The rewrite of the compiler is done in such a way that the result 
of the expression is the original value. That's what the commas 
are for.


```
So you can parse that rewrite example as it if were a function, 
with each expression separated by a comma, and the final 
expression the result:


```d
int postInc(ref int j)
{
auto a = j;
++j;
return a;
}
```

It doesn't actually create a function, but this demonstrates the 
effect.


So that's why you don't have to worry about postfix/prefix for 
these. The compiler handles that behind the scenes. All you need 
to worry about is returning the incremented value.


Re: No rdmd.exe in /bin64 on Windows - is this an issue?

2021-07-13 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 13 July 2021 at 11:23:38 UTC, Scotpip wrote:

Mike - thanks for responding!

You say that there wasn't a Windows 64 bit release "for good 
reason".


That sounds a bit ominous - I'd appreciate your insights into 
what was behind this.


Nothing ominous. It was just because of the state of the Windows 
development ecosystem when Walter started working on D 20 years 
ago and the desire for the out-of-box experience to *just work*.


He started with a backend for his C compiler and the optlink 
linker, neither of which supported 64-bit, and both of which only 
supported the OMF object file format. He had a license to ship 
the Win32 link libraries that he packaged with his C compiler, so 
he shipped those with dmd as well.


He put off 64-bit support for quite a while because (I believe, 
he can correct me if I'm wrong) there was no good way to get it 
implemented. On Linux and Mac, people had no problem installing 
the system build tools and development libraries. In the Windows 
ecosystem, the equivalent was ostensibly the Microsoft Build 
Tools and Windows SDK, but outside of serious Windows dev shops 
people were averse to installing them. It probably didn't help 
that VS was commercial (the first free version that eventually 
came along---can't remember what it was called, but it preceded 
the Community Edition---was limited in features and restricted by 
license).


When he finally got it done, he added support for Microsoft's 
version of the COFF object file format in the backend, but the 
ecosystem hadn't changed all that much in terms of attitudes. 
Requiring the MS stuff to be installed for an out-of-the-box 
experience on 64-bit systems would have really hindered adoption. 
So the 32-bit distribution remained the default.


Later on, in order to start providing an out-of-the-box 64-bit 
experience, the decision was made to ship lld-link (the LLVM 
linker). Walter tried to get the rights to distribute Microsoft's 
64-bit link libraries to go along with it, but MS said no. So 
instead, a system was set up to generate them from MinGW's 
libraries and ship the generated link libraries. But time was 
needed to ensure the new stuff worked as intended before throwing 
the switch on default 64-bit.


I guess the fact that the installer now includes 64-bit binaries 
means the time has almost come to pull the switch on 64-bit 
packages. So I expect not too far down the road we'll see 
installers that configure the 64-bit binaries on the system path 
on 64-bit systems.




Given the effort that's clearly gone into VisualD I was rather 
assuming that Windows was fully supported by the D community. 
As I'm pretty much stuck with Windows for this project, I hope 
I'm not mistaken?


Windows is supported just fine. I've been using it since I 
started with D in 2003. Walter is primarily a Windows user. The 
biggest issue has always been one of external tooling preventing 
an out-of-the-box 64-bit experience.


But you don't need the 64-bit binaries on the system path to 
build 64-bit. Just put the bin folder on the system path and pass 
-m64 to the compiler.




Also, you say that you don't use rdmd. As someone who hasn't 
used a standalone compiled language for decades, I'd be 
grateful if you could share your workflow, as at first sight 
rdmd looks rather useful. For a non-trivial personal project, 
is there a specific approach you would recommend?


I use dub, a build tool and package manager, which also ships 
with dmd. The docs start here:


https://dub.pm/getting_started

And the package repository is here:

https://code.dlang.org/

A little while back, dub was modified to start compiling 64-bit 
by default on 64-bit Windows systems, so it's kind of proving 
that the time has come to start making 64-bit the default.


Also, LDC, the LLVM-based D compiler, ships 64-bit Windows 
binaries and has for a long time.


https://github.com/ldc-developers/ldc/releases

Dub can be configured to compile with dmd, ldc, or gdc.





Re: mixin template's alias parameter ... ignored ?

2021-07-12 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 13 July 2021 at 02:22:46 UTC, Mike Parker wrote:

On Tuesday, 13 July 2021 at 01:03:11 UTC, someone wrote:


Being *local* to ... ain't imply visibility too regardless 
scope not being a visibility attribute ? I mean, scope is 
restricting the variable to be leaked outside the 
function/whatever and to me it seems like restricted to be 
seen from the outside.


And I meant to add... local variables are by default visible only 
inside the scope in which they are declared and, by extension, 
any inner scopes within that scope, and can never be visible 
outside.


```d
{
// Scope A
// x can never be visible here
{
// Scope B
int x;
{
// Scope C
// x is visible here
}
}
}
```

The only possible use for your concept of scope applying to 
visibility would be to prevent x from being visible in in Scope 
C. But since we already have the private attribute, it would make 
more sense to use that instead, e.g., `private int x` would not 
be visible in scope C.


I don't know of any language that has that kind of feature, or if 
it would even be useful. But at any rate, there's no need for a 
visibility attribute to prevent outer scopes from seeing a local 
variable, as that's already impossible.


Re: mixin template's alias parameter ... ignored ?

2021-07-12 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 13 July 2021 at 01:03:11 UTC, someone wrote:


Being *local* to ... ain't imply visibility too regardless 
scope not being a visibility attribute ? I mean, scope is 
restricting the variable to be leaked outside the 
function/whatever and to me it seems like restricted to be seen 
from the outside. *Please note* that I am not making an 
argument against the implementation, I am just trying to 
understand why it is not being classified as another visibility 
attribute given that more-or-less has the same concept as a 
local variable like in other languages.



OK. Specifically to integers nothing then. But, what about 
strings and whatever else ? I put them more-or-less as a 
general rule or so was the idea when I replaced the in's in the 
parameters app-wide.


Hopefully, my post above will shed some light on this.






Re: mixin template's alias parameter ... ignored ?

2021-07-12 Thread Mike Parker via Digitalmars-d-learn

On Monday, 12 July 2021 at 23:45:57 UTC, someone wrote:


Regarding -preview=dip1000 (and the explicit error description 
that could have helped me a lot back then) : DMD man page says 
the preview switch lists upcoming language features, so DIP1000 
is something like a D proposal as I glanced somewhere sometime 
ago ... where do DIPs get listed (docs I mean) ?


DIPs are handled in this repository:

https://github.com/dlang/DIPs

This is a list of every DIP that is going through or has gone 
through the review process:


https://github.com/dlang/DIPs/blob/master/DIPs/README.md

DIP1000 is here:

https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1000.md

But it doesn't describe the actual implementation, as described 
here:


https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1000.md#addendum

I don't know what all the differences are, as I haven't followed 
it.




So, every *local* variable within a chunk of code, say, a 
function, should be declared without anything else to avoid 
this type of behavior ? I mean, anything in code that it is not 
private/public/etc.


Not "without anything", but without scope---unless you're using 
-preview=dip1000, or unless you're applying it to class 
references (see below).




Or, as I presume, every *local* meaning *aux* variable that 
won't need to survive the function should be declared scope but 
*not* the one we are returning ... lstrSequence in my specific 
case ?


Can I declare everything *scope* within and on the last line 
using lstrSequence.dup instead ? dup/idup duplicates the 
variable (the first allowing mutability while the second not) 
right ?


Which one of the following approaches do you consider best 
practice if you were directed to explicitly state as much 
behavior as possible ?




Consider this example, which demonstrates the original purpose of 
scope prior to DIP 1000:


```d
import std.stdio;

class C {
int id;
this(int id) { this.id = id; }
~this() { writeln("C destructor #", id); }
}

struct S {
int id;
this(int id) { this.id = id; }
~this() { writeln("S destructor #", id); }
}

void main()
{
{
C c1 = new C(1);
scope c2 = new C(2);

S s1 = S(1);
S* s2 = new S(2);
scope s3 = new S(3);

writeln("The inner scope is exiting now.");
}
writeln("Main is exiting now.");
}

static ~this() { writeln("The GC will cleanup after this 
point."); }

```

Classes are reference types and must be allocated. c1 is 
allocated on the GC and lives beyond its scope. By applying the 
scope attribute to c2, its destructor is forced to execute when 
its scope exits. It is not allocated on the GC, but on the stack.


Structs are value types, so s1 is automatically allocated on the 
stack. Its destructor will be always be called when the scope 
exits. s2 is a pointer allocated on the GC heap, so its lifetime 
is managed by the GC and it exists beyond its scope. s3 is also 
of type S*. The scope attribute has no effect on it, and it is 
still managed by the GC. If you want stack allocation and RAII 
destructors for structs, you just use the default behavior like 
s1.


You can run it here:
https://run.dlang.io/is/iu7QiO

Someone else will have to explain what DIP 1000 actually does 
right now (if anyone really knows). What I'm certain about is 
that it prevents things like this:


```d
void func() {
int i = 10;
int* pi = 
return pi;
```

The compiler has always raised an error when it encountered 
something like `return `, but the above would slip by. With 
-preview=dip1000, that is also an error. But scope isn't needed 
on either variable for it to do so.


Beyond that, my knowledge of DIP 1000's implementation is 
limited. But I do know that scope has no effect on variables with 
no indirections. It's all about indirections (pointers & 
references).


At any rate, DIP 1000 is not yet ready for prime time. Getting it 
to that state is a current priority of the language maintainers. 
So for now, you probably just shouldn't worry about scope at all.




Re: No rdmd.exe in /bin64 on Windows - is this an issue?

2021-07-12 Thread Mike Parker via Digitalmars-d-learn

On Monday, 12 July 2021 at 23:57:37 UTC, Scotpip wrote:

Given that this will be the first encounter with the language 
for many users, you might want to consider addressing this to 
create a good first impression?


For a long time, the installer did not include 64-bit binaries on 
Windows for good reason. I didn't even realize they were now 
being distributed (and even if I had I wouldn't have noticed rdmd 
was missing, as I don't use it).


I see that someone already reported this in our Bugzilla database 
a few months back as an enhancement. Given that the installer 
still adds the bin folder to the system PATH and not the bin64 
folder, I wouldn't be surprised if very few people have been 
affected by this, meaning it likely hasn't caught the attention 
of anyone in a position to fix it. I'll bump the priority and 
make sure our pull-request manager knows about it.


Thanks for bringing it up here.


Re: Why I'm getting this "Range Violation" error?

2021-07-09 Thread Mike Parker via Digitalmars-d-learn

On Friday, 9 July 2021 at 07:21:06 UTC, rempas wrote:



When I execute it, I'm getting a range violation error. If I 
try to set "len" to be the length of the "prompt" minus 1, then 
it will work and it will print the "prompt" until the 
questionmark. So I cannot find where the error is...


Because you're indexing the prompt with i before you ensure that 
i is valid. Swap the operands in your if condition:


```
while (i < len && prompt[i] != '{')
```

Or better yet, use foreach, which exists to avoid this sort of 
mistake:


```
foreach(c; prompt) {
   if(c != '{') printf("%c", c);
}
```


Re: How to disable assigning a value to a property?

2021-07-06 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 6 July 2021 at 13:27:43 UTC, Jack Applegame wrote:


And that's sad. It should happen for properties only.


Totally disagree. This is one of my favorite D features.


Re: Find a char among string (string.findAmong.char)

2021-07-06 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 6 July 2021 at 11:35:14 UTC, BoQsc wrote:

I tried out .canFind method, and to test it I removed the 
letter 'o' from the Alphabet.
Weirdly enough .canFind method still found 'o' letter among the 
Alphabet.


https://run.dlang.io/is/2Fvenf


Looks like it has something to do with the alias. Static arrays 
aren't ranges, so you should really be seeing the same error you 
would if you passed `letters` directly.


Change the `canFind` call to take a slice of the array:

```d
if (letters[].canFind(letter)){
```

And it outputs the following as expected:

```
k letter is found among the alphabet.
```

This warrants a bug report with a minimized example.


Re: Remove array element within function

2021-07-05 Thread Mike Parker via Digitalmars-d-learn

On Monday, 5 July 2021 at 14:30:11 UTC, Mike Parker wrote:



You never copy the contents of a dynamic array/slice. That only 
comes into play with static arrays:


I should rephrase that. You aren't going to copy the contents of 
an array/slice just by passing it to a function.


Re: Remove array element within function

2021-07-05 Thread Mike Parker via Digitalmars-d-learn

On Monday, 5 July 2021 at 13:34:50 UTC, Rekel wrote:
Ah, ref, thanks, I didn't know if that would work as I was 
confused since arrays themselves are kind of already pointers.


Except they're not :-) Think of them as struct instances with 
length and pointer fields. That's actually what they are.





I believe for setting length it was both when I wanted to 
initialize the array to a certain length (instead of having 
that inline with the declaration)


```d
int[] arr;
arr = new int[](100);
```

& when I want to clear the array of all data. Though I also 
found threads in which people mentioned changing the length 
manually after calling remove.


You shouldn't need to adjust the length after remove as long as 
you assign the return value to the original array. And actually, 
I didn't pay close enough attention to your original function. 
You didn't do that. It should be:


```d
void removeItem(ref int[] a){
...
a = a.remove(index);
}
```

Or this:

```d
int[] removeElement(int[] a) {
...
return a.remove(index);
}

// Later
elems = removeElement(elems);
```

The copies were mostly at play in scenarios such as this one, 
but also when I'm appending lists to lists, in a 
`list.addAll(list2);` scenario. Though I guess I'm just not 
used to reassigning on the list variable after doing things 
with it.


You never copy the contents of a dynamic array/slice. That only 
comes into play with static arrays:


```d
void someFunc1(int[3] a) {}
void someFunc2(int[] a);

int[3] a = [1, 2, 3];
someFunc1(a);// This copies all the elements
someFunc2(a);// This implicitly slices the array
```

Here are some resources that may help:

https://ddili.org/ders/d.en/arrays.html
https://ddili.org/ders/d.en/slices.html
https://dlang.org/articles/d-array-article.html
https://dlang.org/blog/2017/03/20/dont-fear-the-reaper/

Pay particular attention to the append operator + reserve. That 
plus the ability to slice without copying is where the real power 
of D's arrays lies. Then look into `std.array.Appender` when you 
have lots of items to append:


https://dlang.org/phobos/std_array.html#Appender



Also, is my use of long correct? The documentation wasn't very 
clear on the return type of remove, just calling it a 'number'.


If you look in the function signature, it returns `ptrdiff_t`:

https://dlang.org/phobos/std_algorithm_searching.html#countUntil

Which is defined in `object.d`:

https://github.com/dlang/druntime/blob/master/src/object.d#L61

It's `long` on 64-bit systems and `int` on 32-bit. So you can use 
`ptrdiff_t` or just `auto`:


```d
auto index = countUntil(...);
```



Again thanks for your help 


That's why we're here :-)



Re: Remove array element within function

2021-07-05 Thread Mike Parker via Digitalmars-d-learn

On Monday, 5 July 2021 at 13:41:59 UTC, Rekel wrote:
I'm not sure if this is the place to talk about it, but on the 
same topic it's a little strange to me neither the Dlang Tour 
nor the arrays spec page mention removing elements. Even though 
basically everyone is going to use it sooner or later (most 
likely sooner).


Is that because it's part of the library? That's the only 
reason I could think of, while in a way I could make that 
argument for appending in the case it hadn't been given the `~` 
and `~=` operators.


I had no involvement in creating the Tour, so I could only guess 
why it isn't covered. But if you think it should be, you can 
always submit an issue:


https://github.com/dlang-tour/core/issues


Re: Remove array element within function

2021-07-05 Thread Mike Parker via Digitalmars-d-learn

On Monday, 5 July 2021 at 13:10:55 UTC, Rekel wrote:

Am I the only one slightly unamused by how arrays/ranges work? 
They keep backfiring on me, or require weird additions other 
languages wouldn't require such as manually changing .length, 
or worrying about what operation returns a copy etc. (Kind of 
jealous of java's ease here)


D's arrays are friggin' awesome. I don't think they're any more 
difficult than in Java.


In what situations do you need to manually change the length? 
Where do you worry about copies? It's possible there's something 
you're overlooking.


Re: Remove array element within function

2021-07-05 Thread Mike Parker via Digitalmars-d-learn

On Monday, 5 July 2021 at 13:10:55 UTC, Rekel wrote:




But what do you do when you have?:
```d
void function(int[] a){
. . .
long index = countUntil(a, element);
a.remove(index);
}
```



```d
void function(ref int[] a) {
...
}
```

An array is effectively a length/pointer pair that you are 
passing by value. If you want to do anything that affects either 
property, you need to pass by ref.




Re: Is there an alias for standard libraries to use in import statement?

2021-07-04 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 4 July 2021 at 07:40:44 UTC, BoQsc wrote:
I just started with a fresh look at the D language and would 
like to be able to rewrite this code:



import std;
void main()
{
writeln("Hello D");
}


Into more readable standard library name:


import system;
void main()
{
writeln("Hello D");
}


You can use named imports, but then you have to use the name as a 
namespace:


```
import system = std;
void main()
{
system.writeln("Hello D");
}
```



These were the examples that might feel more readable and 
natural than simply a three letter junction:

import std;



What do you think?


If you're worried about the readability of `std` by itself, don't 
use it by itself. Import the specific modules you want:


```
import std.algorithm, std.range, std.stdio;
```

or whatever. It's a non-issue, IMO. It's not like anyone using D 
doesn't know what std is.


Re: Are D classes proper reference types?

2021-06-28 Thread Mike Parker via Digitalmars-d-learn
On Monday, 28 June 2021 at 06:13:06 UTC, Ola Fosheim Grøstad 
wrote:




I don't have much time for chat, I prefer async communication.


Slack isn't like our IRC or Discord channels. It's more async 
like the forums.


Re: what is D's idiom of Python's list.extend(another_list)?

2021-06-21 Thread Mike Parker via Digitalmars-d-learn

On Monday, 21 June 2021 at 08:40:47 UTC, ag0aep6g wrote:



`~` works just fine with single elements:

void main()
{
import std.stdio;
int[] a = [2, 3, 4];
writeln(1 ~ a ~ 5); /* [1, 2, 3, 4, 5] */
}


Cool. I've had it in my head for many years now that this was not 
a thing.


Re: what is D's idiom of Python's list.extend(another_list)?

2021-06-21 Thread Mike Parker via Digitalmars-d-learn

On Monday, 21 June 2021 at 06:16:15 UTC, mw wrote:

Ha! great. I didn't know `~` works for both single elements and 
array!


`~` by itself is the concatenation operator and only works with 
two array operands. `~=` is the append operator and can append 
arrays or single elements.


Re: what is D's idiom of Python's list.extend(another_list)?

2021-06-21 Thread Mike Parker via Digitalmars-d-learn

On Monday, 21 June 2021 at 05:36:36 UTC, mw wrote:

i.e append an array of elements into another array:


```Python
x = [1, 2, 3]
x.extend([4, 5])
print(x)  # [1, 2, 3, 4, 5]
```

Thanks.


```d
x ~= [4, 5];
```


Re: Can not get struct member addresses at compile time

2021-06-16 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 16 June 2021 at 13:26:43 UTC, jfondren wrote:



Is this a bug?


Probably. Please file an issue if there isn't one already:

https://issues.dlang.org/




Re: Can not get struct member addresses at compile time

2021-06-16 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 16 June 2021 at 09:27:25 UTC, Doeme wrote:

Is there an alternative to get to this point? Static module 
initializers are not really an option, since the whole thing 
should be -betterC.




```D
import core.stdc.stdio;
struct Foo{
 ubyte bar;
}

__gshared Foo foo;
void* baz = 
void* bar;

extern(C):

pragma(crt_constructor)
void initialize() { bar =  }

void main()
{
*(cast(ubyte*)bar) = 10;
printf("%d", foo.bar);
}
```

https://dlang.org/spec/pragma.html#crtctor



Re: In general, who should do more work: popFront or front?

2021-06-15 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 15 June 2021 at 04:24:09 UTC, surlymoor wrote:


At the moment, I feel that as long as the stashed front element 
isn't too "big" (For some definition of big, I guess.), that 
built-in caching should be fine. But is this acceptable? What's 
the best practice for determining which range member should 
perform what work? (Other than iterating, of course.)


The "general rule" is that `front` should return the same result 
on multiple calls until after the next call to `popFront`. I 
don't know of any requirement that such an operation be O(1), but 
the expectation is certainly there. The implication then is that 
any necessary work should be carried out in `popFront` to advance 
the range (and additionally in a constructor if things need to be 
teed up first) and that `front` should just return the current 
element.




Re: There are some Feed RSS or mail alert for new Dlang compiler update?

2021-06-12 Thread Mike Parker via Digitalmars-d-learn

On Saturday, 12 June 2021 at 21:42:27 UTC, jfondren wrote:

On Saturday, 12 June 2021 at 21:20:23 UTC, Marcone wrote:

Becouse I can not find it.


https://dlang.org/blog/category/dmd-releases/rss

takes you to

https://feeds.feedburner.com/OfficialDBlog

which includes everything, but still has
``
to look for.


I don't write about every release on the blog. Only the major 
ones. And these days I usually wait until I have more than just 
the dmd release to write about. So probably not the best option.


Re: There are some Feed RSS or mail alert for new Dlang compiler update?

2021-06-12 Thread Mike Parker via Digitalmars-d-learn

On Saturday, 12 June 2021 at 21:20:23 UTC, Marcone wrote:

Becouse I can not find it.


Your best bet is to subscribe to the announce mailing list:

http://lists.puremagic.com/cgi-bin/mailman/listinfo/digitalmars-d-announce

Martin announces every compiler release using the title "Release 
D ", so you can use that to set up a filter.


Re: Problem with Exceptions in Constructor

2021-06-11 Thread Mike Parker via Digitalmars-d-learn

On Friday, 11 June 2021 at 20:09:22 UTC, Mike Brown wrote:



The error is flagged on the writeln(e.msg). Do I need to do 
something special to pass a string to an exception? dup?




No, that code is fine. You're passing a string literal, so 
there's no need for a dup.


Re: LNK2019 error in the C++ interface

2021-06-10 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 10 June 2021 at 13:19:34 UTC, dokutoku wrote:


I still haven't solved this problem.


Not sure if this is the issue, but you don't need `extern` on 
these. You already have the `extern(C++)` thing at the top of the 
file.


```d
extern void str_test(LPCSTR str1);

nothrow @nogc
extern void wstr_test(LPCWSTR str1);
```



Re: how do i fix this node_dlang error?

2021-06-07 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 8 June 2021 at 00:58:12 UTC, Jack wrote:

the dll which I was just build with dub command? how I have a 
version mismatch if they're the very same file?


Electron embeds node and does not use whatever you have on your 
system. So if there’s a mismatch between the embedded version and 
the one you linked against, you can see the error you’re seeing.


Re: how do i fix this node_dlang error?

2021-06-07 Thread Mike Parker via Digitalmars-d-learn

On Monday, 7 June 2021 at 22:24:03 UTC, Jack wrote:


I think the entry point function is ```void atStart(napi_env 
env) {}``` so there's no DllMain...


DLLMain is not strictly required. It's called by the system 
loader when the DLL is first loaded into the process. The 
MainFunction for node is just a means for having a cross-platform 
approach to initialization: node will load your shared library 
then call the MainFunction. So you can initialize the runtime in 
DLLMain or in your atStart function. Shouldn't matter.


Your problem may be unrelated to D, though. It appears to be a 
common error when developing native code for Electron. Googling 
for "electron {paste error message here}" or for "electron dll 
initialization" turns up several results.


Some cursory reading shows that the issue may be a version 
mismatch between the version of node the dll was linked with and 
that used by Electron.





Re: Receiving "pthread_mutexattr_init" during compilation when using FileLogger.

2021-06-07 Thread Mike Parker via Digitalmars-d-learn

On Monday, 7 June 2021 at 11:31:13 UTC, tastyminerals wrote:



It's interesting how there is no information about class 
instantiation at module level anywhere in the docs. Even the 
Ali's book does not explicitly say that you cannot instantiate 
a class this way. Maybe I totally missed it but just doing the 
key search on "scope", "global", "module" in class related 
chapters didn't give me any results.


It's covered by this:

https://dlang.org/spec/declaration.html#global_static_init

The Initializer for a global or static variable must be 
evaluatable at compile time. Runtime initialization is done 
with static constructors.


It obviously could be more explicit. I'll add a note to my todo 
list to make it so.


Re: Receiving "pthread_mutexattr_init" during compilation when using FileLogger.

2021-06-07 Thread Mike Parker via Digitalmars-d-learn

On Monday, 7 June 2021 at 09:29:08 UTC, tastyminerals wrote:

I getting
```
import/core/sync/mutex.d(87,36): Error: 
`pthread_mutexattr_init` cannot be interpreted at compile time, 
because it has no available source code

```
compile time error. One of those D exceptions which doesn't say 
where it happened in your code so you need to comment out the 
lines that might cause it one by one :D


I found that this was caused by the "FileLogger" which I create 
at the top of the file. But why?


You can't initialize classes at module scope. You can declare 
them, but then they must be initialized in a function or a module 
constructor. Normally for a type `MyClass` in module `foo`, you'd 
see an error like this:


```D
Error: variable `foo.MyClass` is a thread-local class and cannot 
have a static initializer. Use `static this()` to initialize 
instead.

```

I guess CTFE runs before the check that catches this, though, and 
the `FileLogger` constructor ultimately triggers the error your 
seeing.


Re: how do i fix this node_dlang error?

2021-06-06 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 6 June 2021 at 15:42:55 UTC, Jack wrote:
0.4.11\node_dlang\source\node_dlang.d(137,11): Error: none of the 
overloads of `this` are callable using argument types `(string, 
string, ulong, Throwable)`, candidates are:

C:\D\dmd2\windows\bin\..\..\src\druntime\import\object.d(2440,30):
`object.Exception.this(string msg, string file = __FILE__, uint line = 
cast(uint)__LINE__, Throwable nextInChain = null)`
C:\D\dmd2\windows\bin\..\..\src\druntime\import\object.d(2445,30):
`object.Exception.this(string msg, Throwable nextInChain, string file = 
__FILE__, uint line = cast(uint)__LINE__)`
C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1.
```


The error is from line 137 of node_dlang.d. Looking at it, we see 
this:


```d
super (message, file, line, nextInChain);
```

This is in the constructor of the `JSException` class, a subclass 
of `Exception`, calling the superclass constructor. According to 
the error message, one or more of the arguments in this list does 
not match any `Exception` constructor's parameter list.


Looking closer, we can see that the arguments to the super 
constructor are all declared in the `JSException` constructor 
like this:


```d
this (
napi_value jsException
, string message = `JS Exception`
, string file = __FILE__
, ulong line = cast (ulong) __LINE__
, Throwable nextInChain = null)
```

Compare that with the constructors in the `Exception` class and 
you should see that the problem is `ulong line`. The equivalent 
argument in the superclass is `size_t`. In 32-bit, `size_t` is 
defined as `uint`, not `ulong`. So it's passing a `ulong` to a 
`uint`, which is a no-no.


The `JSException` constructor should be modified to this:

```d
, size_t line = __LINE__
```

The README does say it hasn't been tested with 32-bit. So there 
may be more such errors.


Unrelated, but I recommend you use `--arch=x86_mscoff` so that 
you can use the same linker and object file format as `-m64` uses 
(MS link, or lld, and PE/COFF), rather than the default (which is 
OPTLINK and OMF). It may save you further potential headaches.


Re: how do i fix this node_dlang error?

2021-06-06 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 6 June 2021 at 04:25:39 UTC, Jack wrote:
I'm trying to use the node_dlang pakckage but the code example 
from [this 
repo](https://github.com/NotSpooky/node_dlang/tree/v0.4.11/examples) isn't working


the command ```dub build``` is fine but ```node example.js``` 
retuns an error saying the module.node is not a valid win32 
application. How do I fix this?


[1]: 
https://github.com/NotSpooky/node_dlang/tree/v0.4.11/examples


Looking at node_dlang's dub.json, it's building a DLL then 
renaming it to module.node. The JS script then causes node to 
load the DLL.


So I expect this error may be related to a 32-bit vs. 64-bit 
issue. I assume you are on 64-bit Windows, in which case recent 
versions of dub compile as 64-bit by default. So if that's the 
case, and your installation of node is 32-bit, you would see this 
error. Ditto when you're loading a 32-bit DLL in a 64-bit process.


Re: Schroedinger's Ranges

2021-06-03 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 3 June 2021 at 10:18:25 UTC, kdevel wrote:


a) What is the rationale behind not making byLineCopy the 
default?


byLine was the original implementation. byLineCopy was added 
later after the need for it became apparent.




Re: Schroedinger's Ranges

2021-06-03 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 3 June 2021 at 10:30:24 UTC, Mike Parker wrote:

On Thursday, 3 June 2021 at 10:18:25 UTC, kdevel wrote:


a) What is the rationale behind not making byLineCopy the 
default?


byLine was the original implementation. byLineCopy was added 
later after the need for it became apparent.


See:

https://forum.dlang.org/post/lg4l7s$11rl$1...@digitalmars.com


Re: wanting to try a GUI toolkit: needing some advice on which one to choose

2021-05-31 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 1 June 2021 at 03:18:22 UTC, someone wrote:

On Sunday, 30 May 2021 at 12:27:34 UTC, Siemargl wrote:

You forget semi-official DWT


For starters I was advised that it is in not good shape. 
Another one going down :(


But have you actually investigated it? It's being actively 
maintained.


https://github.com/d-widget-toolkit/dwt


Re: how to specify a default configuration in a library's dub.json? (i.e if the use doesn't not have subConfigurations)

2021-05-25 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 26 May 2021 at 00:19:23 UTC, mw wrote:

Hi,

I just did a build fix, and added two configurations to 
thrift's dub.json (whose   "targetType": "library")


https://github.com/apache/thrift/pull/2397/files

I want to know how to specify a default configuration in the 
library's dub.json? (i.e if the use doesn't not have 
subConfigurations).


Then the existing library user does not have to change his 
app's dub.json when he do `dub upgrade`.


Thanks.


The first configuration in the file is the default.


Re: ugly and/or useless features in the language.

2021-05-23 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 23 May 2021 at 14:13:36 UTC, Alain De Vos wrote:

This one compiles without any problem.
Maybe someone can enlighten us on the status of 
scope(d)-variables and dip-1000.

It is not fully clear for me.
```
import std.stdio;
void main() @trusted
{
int *q=null;
{
int a;
q=
}
*q=5;
}
```


You might find this helpful:

https://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/


Re: DUB doesn't seem to respect my config, am I doing something wrong?

2021-05-22 Thread Mike Parker via Digitalmars-d-learn

On Saturday, 22 May 2021 at 20:28:56 UTC, rempas wrote:

I'm compiling using `dub --config=development` and I'm getting 
the following line: `Performing "debug" build using 
/usr/bin/dmd for x86_64`. The same exactly happens when I'm 
trying to do the release config. If I disable the `targetType` 
option, it seems that it's creating a library and I can also 
manually change the compiler and the build-type so I don't know 
what's going on


I just looked in the dub documentation for "build" and "compiler" 
entries, which I had never heard of, and I see none now. As 
Jordan said, those have always been configured on the command 
line. Did you perhaps see something about those somewhere else?


FYI, the first configuration you define is always the default, so 
you don't need to specify it on the command line unless you 
really want to.


Re: How to import the types mapresult and filterresult

2021-05-18 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 18 May 2021 at 12:15:25 UTC, Alain De Vos wrote:

Something like:
import X.Y.Z:mapresult ;


You don't. The types returned by map, filter, and other 
algorithms are not public. They're "Voldemort", or anonymous, 
types. Instances aren't generally intended to be stored, but 
rather to be completely consumed at the end of a chain of 
function calls.


But if you need to store one in a local variable temporarily, you 
can use `auto`:


```d
auto result = map...
```


  1   2   3   4   5   6   7   8   9   10   >