Re: How to use dguihub package ?

2021-01-17 Thread Mike Parker via Digitalmars-d-learn
On Sunday, 17 January 2021 at 13:04:33 UTC, Vinod K Chandran 
wrote:




Do i miss something ?


Three of those messages include the solution to fix the errors. 
The fourth one is a missing import (`import std.conv : to`) in 
dguihub.core.utils. You could fix these yourself and submit a 
pull request to the project, or submit an issue.


Re: Why many programmers don't like GC?

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

On Friday, 15 January 2021 at 08:49:21 UTC, Imperatorn wrote:



Nice strategy, using GC and optimizing where you need it.


That's the whole point of being able to mix and match. Anyone 
avoiding the GC completely is missing it (unless they really, 
really, must be GC-less).


Re: any chance to get it working on windows xp?

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

On Tuesday, 12 January 2021 at 13:51:16 UTC, Imperatorn wrote:

On Tuesday, 12 January 2021 at 12:40:28 UTC, Mike Parker wrote:




Are you asking if anyone patched the binaries and made them 
available as a third-party download?


Yes, or if there are any plans for those changes to go upstream.


I'm unaware of anyone who has done that. And I wouldn't expect 
that sort of thing to make it upstream.


Re: any chance to get it working on windows xp?

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

On Tuesday, 12 January 2021 at 10:25:42 UTC, Imperatorn wrote:

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

On Saturday, 3 October 2020 at 23:14:57 UTC, Drone1h wrote:

On Monday, 18 May 2020 at 05:36:01 UTC, Mike Parker wrote:

[...]


This is not exactly a reply to the original thread, but maybe 
it helps someone who has searched for "Windows XP" in the 
forum and found this discussion.


[...]


Anyone knows if these changes where ever made?



Are you asking if anyone patched the binaries and made them 
available as a third-party download?


Re: Linux shared library loading/linking from C does not invoke (shared) static this

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

On Tuesday, 12 January 2021 at 09:31:08 UTC, ichneumwn wrote:



Follow on to my own question: on Linux, with gcc, I have 
created the following file "starter.c" that I inject into my D 
shared library:


  int rt_init(void);
  int rt_term(void);

  // should really check for errors!
  static void __attribute__((constructor)) Dstarter(void) {
rt_init();
  }

  static void __attribute__((destructor)) Dterminator(void) {
rt_term();
  }

That seems to do the trick. Not sure how clean this is?


You should be able to do the same in D with 
`pragma(crt_constructor)` and `pragma(crt_destructor)`:


https://dlang.org/spec/pragma.html#crtctor
https://dlang.org/spec/pragma.html#crtdtor
https://dlang.org/changelog/2.078.0.html#crt-constructor




Re: Are there an equivalent to C#'s List in D's stdlib?

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

On Friday, 8 January 2021 at 03:22:49 UTC, Jack wrote:

tedius, imo. Now, if I went to use filter, could I remove that 
item and somewhat get an array back, without perform a new 
array allocation? currently i'm with this, that as far i know, 
does perform memory allocation by array() call:


arr = arr.filter!(x => x != value).array;


See std.algorithm.mutation.remove. One overload takes an offset, 
but the other takes a predicate. Example from the docs:


```
static immutable base = [1, 2, 3, 2, 4, 2, 5, 2];

int[] arr = base[].dup;

// using a string-based predicate
writeln(remove!("a == 2")(arr)); // [1, 3, 4, 5]

// The original array contents have been modified,
// so we need to reset it to its original state.
// The length is unmodified however.
arr[] = base[];

// using a lambda predicate
writeln(remove!(a => a == 2)(arr)); // [1, 3, 4, 5]
```




Re: Are there an equivalent to C#'s List in D's stdlib?

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

On Friday, 8 January 2021 at 02:53:47 UTC, Jack wrote:
I coduln't find an equivalent in the documentation, I could see 
appender, Array, container etc but none of has a Remove(T item) 
method like C#'s [1]. Are there not such implementation and I 
do have to write one myself or I just couldn't find?




SList and DList both have a function called linearRemoveElement.

https://dlang.org/phobos/std_container_slist.html#.SList.linearRemoveElement
https://dlang.org/phobos/std_container_dlist.html#.DList.linearRemoveElement


Re: Tuple enumeration without integers or strings

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

On Sunday, 3 January 2021 at 13:36:57 UTC, Paul wrote:

Is there an easy way for me to know when code is assessed / 
generated at compile time?
For example, is indexing a constant compile time array compile 
time or run time?
Or how about functions? The hashOf documentation does not seem 
to hint to being done at compile time.


It's not what you do, but the context in which you do it. If a 
function must be evaluated at compile time, it will be.


```
string tellme() {
if(__ctfe) return "Compile Time";
else return "Run time";
}

void main()
{
writeln(tellme());
pragma(msg, tellme());
writeln(tellme());
}
```

Since the msg pragma is a compile-time construct, tellme *must* 
be evaluated at compile time. The calls to writeln are just 
normal function calls, therefore the calls to tellme happen at 
runtime.


So any context where you replace a compile-time constant with a 
function call, you'll have CTFE (as long as it's possible [1]). 
It's common to use enum to force CTFE:


enum s = tellme();

[1] https://dlang.org/spec/function.html#interpretation


Re: Reading files using delimiters/terminators

2020-12-27 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 27 December 2020 at 23:18:37 UTC, Rekel wrote:


Update;
Any clue why there's both "std.file" and "std.io.File"?
I was mostly unaware of the former.


The very first paragraph at the top of the `std.file` 
documentation explains it:


"Functions in this module handle files as a unit, e.g., read or 
write one file at a time. For opening files and manipulating them 
via handles refer to module std.stdio."


https://dlang.org/phobos/std_file.html


Re: visibility of private Class C in module named "C"; private variables in modules

2020-12-26 Thread Mike Parker via Digitalmars-d-learn

On Saturday, 26 December 2020 at 15:58:30 UTC, kdevel wrote:


package class Private {
   void foo () { __PRETTY_FUNCTION__.writeln; }
}




   import Private;
   auto p = new Private; // works, but Private.Private is 
private ?!?


You've declared `Private` as `package`.


Re: gdb + Windows 64: No debugging symbols found

2020-12-26 Thread Mike Parker via Digitalmars-d-learn
On Saturday, 26 December 2020 at 11:55:58 UTC, Виталий Фадеев 
wrote:




Problem is:
$ gdb ./app.exe
GNU gdb (GDB) 9.2
...
(No debugging symbols found in ./app.exe)

What is a right way to build .exe and debug with gdb ?


The version of gdb that ships with MSYS is probably going to 
expect debug info in a different format than what dmd puts out on 
Windows (I assume it expects DWARF2).


When using -m32(always the default on Windows when invoking dmd 
directly), it outputs debug info in an old version of the 
CodeView format (which you'll probably need an older version of 
WinDbg to work with). Otherwise (-m64, -m32mscoff), it creates a 
PDB file usable with the Visual Studio debugger and other 
debuggers that understand the PDB format (which is basically a 
wrapper for modern CodeView debug info). If there's a Windows 
version of gdb that supports CodeView/PDB, I'm unaware of it.


I know some people use Mago:
https://github.com/rainers/mago

Some docs on PDB & CodeView:
https://llvm.org/docs/PDB/index.html

DMD and debug info on Windows:
https://dlang.org/windbg.html




Re: How to store a pointer to class contructor

2020-12-24 Thread Mike Parker via Digitalmars-d-learn
On Thursday, 24 December 2020 at 11:15:28 UTC, Dmitriy Asondo 
wrote:


Is there any way, for example on compile step, to get class 
name from class pointer? To automate generation of factory via 
template


At compile time, you'd get it from the type, not the reference:

typeid(T).name;


Re: How to store a pointer to class contructor

2020-12-24 Thread Mike Parker via Digitalmars-d-learn
On Thursday, 24 December 2020 at 10:33:00 UTC, Dmitriy Asondo 
wrote:
The idea is to store somewhere services (classes) first and 
only when the app need - instantiate services for 
app/thread/http-request (as option) and provide values to 
constructors via DI


There's `Object.factory`, which constructs a class instance from 
a fully-qualified name:


https://dlang.org/phobos/object.html#.Object.factory

But IIRC there are issues with it in some cases and I believe 
it's supposed to be deprecated at some point.


I'd just give the classes an interface and use function pointers 
to construct them:


```
interface IService { ... }

alias ServiceMaker = IService function();

ServiceMaker[string] serviceRegistry;

class FooService : IService { ... }
IService makeFooService() { return new FooService(); }

void registerServices() {
serviceRegistry["FooService"] = 
}
```



Re: Can I output strings using core.stdc.stdio?

2020-12-23 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 23 December 2020 at 08:45:15 UTC, Godnyx wrote:

Yep and I find it out! It won't work with templates and/or 
variadic function parameters. It says that the variable can't 
be read at compile time (so I can't cast it) or it will work 
but it will give me a segmentation fault (lol hello C). Any 
idea why this is happening in those cases?


Please show the code that's causing the error. Without it, all 
anyone can do is keep making suggestions that *might* be the 
problem. With the code, someone can point to it exactly.


Re: Trying to understand multidimensional arrays in D

2020-12-22 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 22 December 2020 at 15:31:06 UTC, Rekel wrote:



Don't take that as a defence of changing pointer syntax by the 
way, just noting I think the argument pointers and arrays 
should be defined using a similar syntax is not consistent when 
thinking about indexing & dereferencing.


Besides, I think '[4]foo* foos;' is quite clear.
"array of foo pointers" seems very natural to me.


Ugh. No thanks :-) My brain would short circuit every time I see 
it.


Re: Trying to understand multidimensional arrays in D

2020-12-22 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 22 December 2020 at 13:59:54 UTC, Rekel wrote:



I am curious by the way, what do you think of the [][4]Row 
suggestion I gave? In a way you'd have your  & could eat it 
too, i think ^^

(Still a strange saying to me)


Currently, D's variable declaration syntax is consistent and, 
IMO, make sense:


Type Name | Extra Tokens | SymbolName
Foo   *   a;
Foo   [4] b;
(Foo  [4])[]  c;

[][4]Foo is completely backwards from and inconsistent with the 
pointer declaration syntax. We shouldn't want to intentionally 
introduce inconsistencies.


Re: Flag & byLine confusion.

2020-12-20 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 20 December 2020 at 15:18:44 UTC, Rekel wrote:



By the way, where can I see Flag is (/ will be?) deprecated? It 
doesn't show in the library reference, however I may be looking 
in the wrong place.


It hasn't been yet.


Re: Flag & byLine confusion.

2020-12-20 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 20 December 2020 at 14:07:56 UTC, Rekel wrote:

The template parameter serves to make Flag!"foo" a distinct 
type from Flag!"bar".

Does this mean other flag yes's will not be accepted?


Yes.




https://dlang.org/spec/operatoroverloading.html#dispatch
Also regarding the other examples given, why does Phobos use 
templating so heavily, in situation in which I am totally 
confused as to why generics would be necessary.
I seem to be totally confused as to how this template system 
works. It was introduced as a kind of generic, like in Java, 
but things like 'string s' seem to me like parameters.


Java's generics are good for what they do, bolted onto an 
existing language in a non-breaking way as they were, but they 
are a pale shadow of a real metaprogramming system. D's template 
metaprogramming is not anything like Java generics. It's more 
akin to C++ templates---much more powerful than what Java offers 
you.


If Java's generics are all you know, then breaking through your 
confusion and answering your questions is going to require more 
than a forum post. You'll want to read up and get some hands on.


I have an introductory post on the D blog which is the first in a 
series (that I'll have finally have time to continue in the new 
year). It goes over the very, very basics:


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

After you read that introduction, you should look into Ali's 
coverage of templates in 'Programming in D':


http://ddili.org/ders/d.en/

When you're ready for more, Phillippe Sigaud's tutorial is 
excellent (though several old, it's still mostly relevant):


https://github.com/PhilippeSigaud/D-templates-tutorial






Re: Flag & byLine confusion.

2020-12-19 Thread Mike Parker via Digitalmars-d-learn

On Saturday, 19 December 2020 at 23:16:00 UTC, Rekel wrote:



Most confusing was the way the documentation (website & 
in-editor) used;

1. Yes.keepTerminator
2. KeepTerminator.yes
3. Flag!"keepTerminator".yes


Your confusion arises from the fact that KeepTerminator is 
combining multiple distinct D features to achieve its goal.


As Paul said, std.typecons.Flag is a templated enum of type bool. 
It's declared to take a string as its template parameter, and it 
has two fields: yes, and no. Minus the documentation:


template Flag(string name) {
///
enum Flag : bool
{
no = false,
yes = true
}
}

The template parameter serves to make Flag!"foo" a distinct type 
from Flag!"bar".


Now, the goal of Flag is to make the purpose of a boolean 
function parameter more clear. Sometimes, we can misremember what 
a boolean parameter indicates. Does true mean do this extra thing 
or does it mean don't do this extra thing? Flag removes the doubt.


However, having to write Flag!"keepTerminator".yes all the time 
is more annoying that simply writing true, so functions that use 
Flag usually have a corresponding alias defined in the module 
scope to give it a less annoying syntax:


alias KeepTerminator = Flag!"keepTerminator";

Because of this, you can write KeepTerminator.yes and 
KeepTerminator.no.


std.typecons also has two structs: Yes and No. Both are 
implemented with a bit of template magic. D supports a feature 
called "Forwarding" in structs and classes and implements it via 
a special template called opDispatch:


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

The idea is that if you call a member function on a struct or 
class, and the class does not have a member function of that 
name, then the compiler will look for an opDispatch template 
implementation in that class or struct. If it finds one, it will 
call the template with the name of the missing function.


There are a number of use cases for this, if you look at the 
examples in the documentation of opDispatch, you'll find that 
there are two examples of implementing it as a function template 
and one that looks like this:


struct D
{
template opDispatch(string s)
{
enum int opDispatch = 8;
}
}

This impelemtation is an enum template that's essentially 
creating an enum with a single member, also called a "manifest 
constant" (a compile-time constant):


https://dlang.org/spec/enum.html#manifest_constants

This is an eponymous template, which means it can be accessed 
directly as opDispatch without using dot notation on the template 
name (opDispatch.opDispatch). So given `d` of type `D`, when the 
compiler sees `d.foo`, it looks for `foo` in the `D` struct. It 
doesn't find it, but it does find `opDisptach`, so it 
instantiated `d.opDispatch!"foo"` which, in this case, produces 
the number `8` as a compile-time constant.


Both the Yes and No structs use this technique:

struct Yes
{
template opDispatch(string name)
{
enum opDispatch = Flag!name.yes;
}
}

So when you call Yes.keepTerminator, you're getting 
Flag!"keepTerminator".yes as a result.


The point behind the structs is so that people who make use of 
Flag in their function parameter lists don't need to actually 
define an alias:


"The structs Yes and No are provided as shorthand for 
Flag!"Name".yes and Flag!"Name".no and are preferred for brevity 
and readability. These convenience structs mean it is usually 
unnecessary and counterproductive to create an alias of a Flag as 
a way of avoiding typing out the full type while specifying the 
affirmative or negative options."


So when implementing your function with a Flag!"foo", you can 
skip the alias and users can call the function with Yes.foo and 
No.foo.


However, I believe that the aliases for KeepTerminator in 
std.string (for splitLines and lineSplitter) and std.stdio (for 
byLine and byLineCopy) predate the implementation of the Yes and 
No structs in std.typecons, but were kept around so as not to 
break any code.


So, to summarize:


1. Yes.keepTerminator


This is because of Yes is a struct with an opDispatch template 
that "forwards" to Flag!"keepTerminator".yes. This is the 
preferred syntax and will work with any Flag parameter.



2. KeepTerminator.yes


This is because KeepTerminator is an alias to 
Flag!"keepTerminator". This syntax will only work on any given 
Flag parameter if the function implementer defines the alias.



3. Flag!"keepTerminator".yes


This is because Flag is a templated enum that takes a string 
parameter and has two members: yes and no. This always works, 
because it's the root feature for which the above two syntaxes 
were implemented as conveniences.


& Don't get me started on the autocomplete trying to get me to 
use KeepTerminator.Flag.yes (VSCode & code-d)


code-d uses DScanner to implement autocompletion. It can get 
confused in certain instances when compile-time features are 
involved. If there isn't 

Re: Getting the source text of an expression

2020-12-17 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 17 December 2020 at 21:40:09 UTC, Dave P. wrote:

Very cool! Where can I read about what an alias as a template 
parameter does?


https://dlang.org/spec/template.html#aliasparameters

https://github.com/PhilippeSigaud/D-templates-tutorial




Re: extern(C) and name mangling

2020-12-15 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 16 December 2020 at 04:45:34 UTC, Dave P. wrote:



Oh interesting, so I only need extern(C) for declaring symbols 
I’m linking to and
for symbols I want to export to C. I had sort of assumed that D 
might have
different calling conventions for different things, but that 
makes things a lot easier.




Not so fast! :-)

extern(C) does affect the calling convention on Windows x86. 
There's also extern(Windows), which changes a function to the 
stdcall calling convention used by the Win32 API (and OpenGL 
implementations on Windows, and a handful of other libraries). 
And there's no guarantee that as D moves to new platforms that 
there won't be other exceptions joining x86 Windows.


That's why I said I'm not sure I'd ever pass a templated function 
pointer to C. It isn't going to work on 32-bit Windows, or with 
any stdcall C function, right now, and possibly other platforms 
in the future.


So as a default, you should always be explicit with your 
extern(x) linkage attributes on functions even when you aren't 
actually linking with C, and only break that rule when it's 
necessary.


Re: extern(C) and name mangling

2020-12-15 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 15 December 2020 at 22:04:12 UTC, Dave P. wrote:
I can’t find this in the spec, but from experimentation it 
seems like extern(C) only affects name mangling of functions at 
the top level scope. Thus extern(C) function templates would be 
mangled differently, but still use the C calling convention. Is 
this right?  I want to pass some templated functions as 
function pointers to some C code and wanted to confirm that 
would work (and that different versions would be mangled 
differently).


Mangling does not play any role in passing and calling function 
pointers between D and C. It only plays a role in linking and 
loading. You can declare function pointers in D and C without any 
name whatsoever.


What matters is that both sides agree on the number and type of 
parameters accepted by the function that's pointed to, and that 
they both agree on the calling convention. I don't believe 
extern(C) has any effect on templated functions. However, the D 
calling convention is defined to be identical to the C calling 
convention on the host system for everything except Windows x86.


So theoretically, you should be able to pass a pointer to a 
templated free function to C as long as the types in the 
functions parameter list match those the C function expects. I 
don't know if I'd do that myself, though.




Also, is there any way to say you want the C calling 
convention, but don’t want C name mangling for top level 
functions?


There's no such thing as C name mangling. C functions are *not* 
mangled (though some platforms do prepend an underscore to symbol 
names). What extern(C) does is to turn off D name mangling.


So what you're asking for is a way to retain the D name mangling 
on an extern C function. The way to do that is with 
`pragma(mangle, "new_name")`. To match the original D function 
mangling, declare the function first without extern(C) and print 
`func.mangleof`. Use that as the parameter to pragma(mangle).


I can't imagine any benefit you'd get from doing that, though.


Re: UFCS functions with both pointers and refs

2020-12-15 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 13 December 2020 at 19:02:34 UTC, Dave P. wrote:

On Sunday, 13 December 2020 at 18:44:20 UTC, Mike Parker wrote:

On Sunday, 13 December 2020 at 18:31:54 UTC, Dave P. wrote:
Do I have to write both and have one forward to the other for 
more

complicated functions?


For free functions, yes.


Is there any way to write the function as a template that is 
generic over a parameter being a pointer or a reference, but 
does not allow passing a copy?


Even with a templated function, you'd still need to declare the 
first parameter to the function either as a pointer or as a `ref` 
parameter. I'm unaware of any way to get around that. Free 
functions and member functions are just different beasts


Based on you requirement to use pointers, I assume you're doing 
this for a type you get from a C library. I did the same thing 
for the SDL_Rect type when working with SDL. All I did was 
implement a pointer version of my "extension" functions. When I 
had an instance and not a pointer, I took its address when I 
called the function. If that's inconvenient (lots of generic 
code, perhaps), you can always have the pointer version forward 
to the ref version, but it seems to me like just having the one 
version is the way to go most of the time.






Re: UFCS functions with both pointers and refs

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

On Sunday, 13 December 2020 at 18:31:54 UTC, Dave P. wrote:
If I define a method on a type, then I can call it both through 
a pointer and

through a reference and the compiler does the right thing. Eg:

struct Foo {
int x;
void fooey(){
x++;
}
void report(){
printf("%d\n", x);
}
}

int main(){
Foo f;
f.fooey;
Foo* pf = 
pf.fooey;
f.report; // prints 2
return 0;
}

However, if I define it as a free function and try to invoke it 
via UFCS,

it seems like I have to define it twice.

struct Foo {
int x;
void report(){
printf("%d\n", x);
}
}

void fooey(Foo* f){
f.x++;
}
void fooey(ref Foo f){
f.x++;
}

int main(){
Foo f;
f.fooey;
Foo* pf = 
pf.fooey;
f.report; // prints 2
return 0;
}

Am I missing something or is this just how it has to work 
generally?


These are two very different concepts.

Member functions have a hidden 'this' parameter as the first 
function parameter. For structs, it's a reference to the 
instance. Whether you call it through a pointer or a reference, 
that never changes: there's only one implementation of the 
function, the first parameter is always a reference to the 
instance.


Free functions do not belong to any type (hence the "free"). UFCS 
doesn't change that. UFCS is simply a convenience that rewrites 
`foo.func` as `func(foo)`. You aren't calling "through" a pointer 
or a reference. So if the first parameter is a pointer, you can't 
give it a reference, and vice versa.


Do I have to write both and have one forward to the other for 
more

complicated functions?


For free functions, yes.



Re: How to unit-test a phobos module?

2020-11-25 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 25 November 2020 at 21:36:36 UTC, Q. Schroll wrote:



[1] https://wiki.dlang.org/Building_under_Windows


You might try Digger. That will hide all the tedious bits.

https://code.dlang.org/packages/digger


Re: why is "hello".writeln considered bad?

2020-11-20 Thread Mike Parker via Digitalmars-d-learn

On Friday, 20 November 2020 at 10:03:18 UTC, Daniel Kozak wrote:



I remember days when I liked UFCS too . Unfortunately  it is 
not so awesome when you use it with IDE. So I am now avoiding 
UFCS as much as possible and it is a much better experience for 
me.


Doesn't bother me. Auto-completion is a nice-to-have for me, not 
a must-have, and I don't miss it when I don't have it.


Re: why is "hello".writeln considered bad?

2020-11-19 Thread Mike Parker via Digitalmars-d-learn

On Friday, 20 November 2020 at 07:39:10 UTC, norm wrote:
I was reading some posts and this was presented as a snippet of 
code and was immediately flagged as bad practice.




Eh, I wouldn't quite put it that way. If we're thinking of the 
same thread, one person said he thought it was a bad idea. That 
doesn't make it bad practice. It's just his opinion. I think UFCS 
is an awesome feature. And it's widely used in D code.


I get some people don't like it but occasionally I prefer this 
syntax. It feels more declarative and fluent in style. Is there 
a good technical reason why it is bad practice, e.g. does it 
make it easier to write bugs? Or is it just what people are 
used to?


I think everyone has their own criteria for when to use UFCS. For 
example, I don't generally write "foo".writeln myself, because I 
don't think of writeln as being a property of strings. And that's 
the lens through which I view UFCS: this operation is akin to a 
property of this type. Other people might not see it that way, 
and one (not me) could make an argument that this specific usage 
is bad practice, but the feature itself rocks.







Re: betterC question

2020-11-18 Thread Mike Parker via Digitalmars-d-learn
On Thursday, 19 November 2020 at 00:20:50 UTC, Dibyendu Majumdar 
wrote:
On Thursday, 19 November 2020 at 00:18:54 UTC, rikki cattermole 
wrote:




You don't need the brackets to call a function (and with a 
little help from UFCS):


void main() {
import std.stdio;

"Hello!".writeln;
writeln;
}


Okay thanks. Bad idea IMO.


Imagine what range pipelines would look like without it. This is 
one of my favorite D features.


Re: Two "references" to dynamic array, why not change both when reallocating?

2020-11-11 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 11 November 2020 at 10:17:09 UTC, zack wrote:
I am new to D. Appending to an array can lead to reallocation, 
that's clear. But why is the "reference" b not changed 
accordingly to the new position and still points to "old" 
memory? Why is b not also changed when reallocating array a and 
the old data getting invalid/freed?


auto a = [55,10,20];
auto b = a;
a ~= [99,99,99,99,99,99];
a[0] = 1;
assert(b[0] == 1); // could fail

(similar to p.103-104 in "The D Programming language")


`b` is not a "reference" to `a`. Consider that under the hood, an 
array is a pointer/length pair. `b = a` means that `b` is 
initialized such that `b.length == a.length` and `b.ptr == 
a.ptr`. Now when you append to `a`, one of two things can happen:


1. there's no allocation, in which case `a.length != b.length` 
and `a.ptr == b.ptr`.
2. there's a reallocation, in which case `a.length != b.length` 
and `a.ptr != b.ptr`.


And when you append to `b`, it can also reallocate and `a` will 
not be affected.




Re: Return values from auto function

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

On Friday, 6 November 2020 at 15:06:18 UTC, Andrey Zherikov wrote:


To clarify my statement:
Yes, Result!void and Result!int are different types but I 
couldn't find a way to implicitly convert one to another.


You can't. Structs do not implicitly convert to each other, 
templated or otherwise.


Re: Source code folder naming convention?

2020-11-04 Thread Mike Parker via Digitalmars-d-learn
On Wednesday, 4 November 2020 at 11:15:33 UTC, Vladimirs Nordholm 
wrote:

Hello.

Is there a "best practice" of what the source folder should be 
called?


I commonly see either `source` or `src` in GitHub projects, but 
cannot find any formal best practice naming convention.


dub looks for both by default. Take your pick.


Re: What is the difference between enum and shared immutable?

2020-10-28 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 29 October 2020 at 00:55:29 UTC, matheus wrote:

On Wednesday, 28 October 2020 at 22:07:06 UTC, H. S. Teoh wrote:
... (This is why it's a bad idea to use enum with an array 
literal, because every time it's referenced you get a new copy 
of the array.)

...


Could you please give an example (Snippet) about this?



enum int[] arr = [1,2,3];
someFunc(arr);

This is identical to

someFunc([1,2,3]);

Manifest constants have no address. They are effectively aliases 
for their values.





Re: Getting Qte5 to work

2020-10-28 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 28 October 2020 at 07:50:27 UTC, Josh Dredge wrote:

developers would love to be working with! I will give Gtk a go 
too - I've never programmed with it, but I used Ubuntu alot 
back in the day and never really liked applications that used 
it, but maybe its more responsive on Windows or time has fixed 
the issues!




You can find a set of tutorials for gtkD here:

https://gtkdcoding.com/


Re: winapi, dll

2020-10-15 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 15 October 2020 at 20:59:10 UTC, Atmosfear wrote:



I use online DMD. I'll try VS 2019 with the VisualD.


That's the issue, then. The online versions of DMD run on Linux. 
You don't need VisualD for this. Just plain old dmd in a text 
editor will do.


Re: How to add an additional config dir in DUB under source?

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

On Tuesday, 13 October 2020 at 05:13:18 UTC, Mike Parker wrote:


not available. The very first restriction on CTFE is this:

"The function source code must be available to the compiler. 
Functions which exist in the source code only as extern 
declarations cannot be executed in CTFE."


Forgot the link:

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




Re: How to add an additional config dir in DUB under source?

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

On Monday, 12 October 2020 at 22:31:53 UTC, tastyminerals wrote:


I wonder why and what am I doing wrong?


This:

readText("conf.toml");

"stringImportPath" (dmd's -J command line option) is specifically 
for D's import expression (which is different from the import 
statement, e.g., `import std`):


https://dlang.org/spec/expression.html#import_expressions

It has no effect on arbitrary filesystem calls. And, in fact, 
filesystem calls cannot be called at compile-time because they 
ultimately depend on system calls for which the source code is 
not available. The very first restriction on CTFE is this:


"The function source code must be available to the compiler. 
Functions which exist in the source code only as extern 
declarations cannot be executed in CTFE."


So if you were to do something like, `enum foo = 
readText("foo.txt")`, you would get a compile time error. On 
Windows:


"Error: CreateFileW cannot be interpreted at compile time, 
because it has no available source code"


You're calling `readText` in a normal runtime context, so it's 
looking file at runtime relative to the current working directory.


What you need to do is something like this:

```
string config = import("config.toml");
void loadConfig() {
// parse config string here
}
```

I don't know where the `EmbeddedPNG` template comes from, but it 
has to be using the import expression internally, else it 
wouldn't work.


Re: It is possible to substract 5 from 3 unsigned integer

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

On Tuesday, 6 October 2020 at 12:24:56 UTC, Alaindevos wrote:

Is that the expected behavior of the programmer?
Opinions can differ. Feel free to elaborate.


It's expected behavior:

"If both operands are of integral types and an overflow or 
underflow occurs in the computation, wrapping will happen. For 
example, uint.max + 1 == uint.min, uint.min - 1 == uint.max, 
int.max + 1 == int.min, and int.min - 1 == int.max."


https://dlang.org/spec/expression.html#add_expressions


Re: question on dub and postgresql

2020-10-05 Thread Mike Parker via Digitalmars-d-learn

On Monday, 5 October 2020 at 15:08:54 UTC, Alaindevos wrote:



Yet it would be nice to know why i can't iterate directly over 
answer using foreach.


Looking at the implementation of the `Answer` type [1], I see no 
way to create a range or a slice, and no `opApply`. So you'll 
have to ask the maintainer about that.


[1] 
https://github.com/denizzzka/dpq2/blob/master/src/dpq2/result.d#L107


Re: question on dub and postgresql

2020-10-05 Thread Mike Parker via Digitalmars-d-learn

On Monday, 5 October 2020 at 09:05:16 UTC, Alaindevos wrote:


A name dependency solution is at least vage.
How do I install ,
https://github.com/denizzzka/dpq2
on unix so in the code i write the .d files of that library and 
after compilation linked to the libary shared objects. For that 
shared object must be installed. How ?


You don't need to install dpq2 if you are using dub to build your 
project. Add it as a dependency to your dub.json (or dub.sdl if 
you prefer that format). When you build your project, dub will 
download the version you configured as your dependency and 
compile it along with your project.


In your project root directory (where your dub.json/sdl is 
located), you should be able to run `dub add dpq2` and dub will 
add the dependency to your configuration. Or you can add it 
manually.


For dub.json:

"dependencies": {
"dpq2": "~>1.0.17"
}

For dub.sdl:

dependency "dpq2" version="~>1.0.17"

Make sure libpq is installed on your system and you should be 
good to go.


See:
https://code.dlang.org/packages/dpq2
https://dub.pm/package-format-json
https://dub.pm/package-format-sdl

If you aren't using dub to build your project, then you could 
potentially use `dub install dpq2` and it will install it in a 
cache folder which, IIRC, should be in ~/.dub. However, I would 
use `git clone` or `dub fetch` so that you can keep it in a 
specific folder. I have some instructions for using my old 
Derelict packages when you aren't using dub for your project. You 
can adapt that to dpq2:


http://derelictorg.github.io/building/without-dub/

Once you've pulled down dpq2, you'll need to build it, then when 
building your project you'll have to pass the dpq source path to 
the compiler (with the -Ipath) so it can find the imports, the 
path to the dpq library you built (with -L-Lpath), and the dpq 
library (-L-ldpq).


Re: Safe to remove AA elements while iterating over it via .byKeyValue?

2020-09-29 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 27 September 2020 at 13:02:04 UTC, Per Nordlöw wrote:
Is it safe to remove AA-elements from an `aa` I'm iterating 
over via aa.byKeyValue?


I'm currently doing this:

foreach (ref kv; aa.byKeyValue)
{
if (pred(kv.key))
aa.remove(kv.key); // ok?
}
if (aa.length == 0)
aa = null;

Is there a better way?


If you're okay with the allocation that comes with it:

foreach(k; aa.keys)
{
if(pred(key)) aa.remove(key);
}





Re: Any way to tell if an object is inside another class?

2020-09-28 Thread Mike Parker via Digitalmars-d-learn
On Monday, 28 September 2020 at 14:23:12 UTC, Ruby The Roobster 
wrote:
On Monday, 28 September 2020 at 14:22:34 UTC, Ruby The Roobster 
wrote:
I meant User Defined types. not UDAs. Anyways, the whole thing 
is me trying to find a hacky workaround that allows something 
similar to multiple alias this declarations(because multiple 
of these are not possible). And for this, I have to determine 
if a normal number is being passed, or if an user defined type 
is being passed through the parameter.


I mean type, not number


There's the `parent` trait. You can wrap it like this:

```
import std;
class Foo {
int x;
}
struct Bar {
Foo f;
}
Foo g;

enum hasParent(alias sym) = is(__traits(parent, sym) == class) || 
is(__traits(parent, sym) == struct);


void main() {
   writeln(hasParent!(Bar.f));   // true
   writeln(hasParent!(g));
}
```




Re: conflicting alias in package module

2020-09-26 Thread Mike Parker via Digitalmars-d-learn

On Saturday, 26 September 2020 at 22:43:10 UTC, 60rntogo wrote:



OK, sure. It's just that the motivation behind doing public 
imports in package.d is that I can write "import pack" instead 
of "import pack.foo". I guess it simply doesn't work within the 
package itself.


package.d is for your external interface.


Re: Why private methods cant be virtual?

2020-09-22 Thread Mike Parker via Digitalmars-d-learn
On Tuesday, 22 September 2020 at 14:19:09 UTC, Steven 
Schveighoffer wrote:

On 9/22/20 10:11 AM, Arafel wrote:




This is a very good guess. Specifically, I think classes (and 
the mechanisms for inner classes and anonymous classes) were 
added to D1 to allow porting of JWT to D.




Classes existed long before then. But yeah, the inner classes and 
anonymous classes were added for DWT, IIRC.


Re: How to implement fastcall ?

2020-09-21 Thread Mike Parker via Digitalmars-d-learn
On Monday, 21 September 2020 at 11:14:06 UTC, Виталий Фадеев 
wrote:

How to implement fastcall ?
( stdcall is calling convention for pass function arguments via 
registers )


The supported linkage attributes are here:

https://dlang.org/spec/attribute.html#linkage

`extern(Windows)` is stdcall, `extern(C)` is cdecl. Unless it's a 
hidden feature that I'm unaware of, fastcall is not supported.


Re: create and initialise array

2020-09-19 Thread Mike Parker via Digitalmars-d-learn

On Saturday, 19 September 2020 at 21:53:34 UTC, mw wrote:

On Thursday, 20 June 2019 at 07:57:25 UTC, KnightMare wrote:




imo NaN is useless, weird and unusual coz integrals and 
pointers are "all bits zeroes" but float and chars are "all 
bits ones". WTF? its strange that bool.init is false in such 
case.
.init = "all zeroes" can be faster initialize any block of 
memory.



I have the same question, why float/double are init to NaN, 
instead of 0? as other post-C++ language does? e.g Java, C# ...


What's the reason for this design decision?


The default init values in D are intended to stand out if you're 
looking at a printf dump or a debugger. NaN for float double, and 
invalid UTF values for char/wchar/dchar were intentionally 
chosen. For the integrals, there are no invalid values, so we're 
stuck with 0.


Re: DDoc generation

2020-09-19 Thread Mike Parker via Digitalmars-d-learn

On Friday, 18 September 2020 at 13:35:05 UTC, Russel Winder wrote:
On Fri, 2020-09-18 at 09:02 -0400, Steven Schveighoffer via 
Digitalmars-d- learn wrote:


[…]


it ddoc files, and compile those along with your application.

https://dlang.org/spec/ddoc.html#using_ddoc_for_other_documentation



Any small project examples anywhere?


https://github.com/dlang/dconf.org/tree/master/2019


Re: dub: Is it possible to have a library target and depend on it in the same dub config?

2020-09-18 Thread Mike Parker via Digitalmars-d-learn

On Friday, 18 September 2020 at 12:28:30 UTC, wjoe wrote:


2 issues though.
- It doesn't build the library automatically, and


You'll have to invoke dub once for each config. Just slap both 
commands in a script.



- Linking fails because error: ld: cannot find -llib

Built it manually via dub --config=lib and it lives inside the 
lib directory.
Then added lflags "-Llib" to the "app" configuration but that 
didn't help. ld still can't find the file.

Then I passed the absolute path and ld still complains.

Any ideas as to why ?


It's just a matter of getting the configuration right and making 
the linker happy. I don't think I've ever linked with anything 
other than system libraries on Linux, so I really don't know what 
it expects when linking with a custom shared library outside of 
the system path.


Make sure that your library foo.so is named `libfoo.so`, when you 
pass the lib path along in dflags via -L, then make sure to 
change `libs "lib/foo"` to `libs "foo"`.


The initial failure may be because of the path in the library 
name. I remember reading somewhere long ago that if you're 
passing a path in the library name (instead of using the -L 
flag), then you have to specify the full file name, e.g. 
lib/libfoo.so. I don't know if dub will pass that along correctly 
though.


Whatever the case, trying adding -v to your dub command line so 
you can see exactly what's dub is calling the compiler with. That 
may give you a hint.


Re: dub: Is it possible to have a library target and depend on it in the same dub config?

2020-09-18 Thread Mike Parker via Digitalmars-d-learn

On Friday, 18 September 2020 at 11:38:14 UTC, wjoe wrote:

Something like this:

configuration "lib" {
  targetType "dynamicLibrary"
  sourceDir "source/lib/"
}

configuration "app" {
  targetType "executable"
  sourceFiles "source/app.d"
  linkWith "lib"
}

I found subConfiguration in the docs but that seems to be 
related to external dependencies.


app.d merely provides a CLI to the library as well as an option 
to run as a server. I don't want to have the overhead of an 
entire git repo and such for something that is a single file 
and also closely related to the library.


Yes, this is possible. Should be something like this:

configuration "lib" {
   targetType "dynamicLibrary"
   targetPath "lib"
   sourcePaths "source/lib/"
   excludedSourceFiles "source/app.d"
}

configuration "app" {
   targetType "executable"
   mainSourceFile "source/app.d"
   excludedSourceFiles "source/lib/*.d"
   importPaths "source/lib"
   libs "lib/libName"
}



Re: enum and const or immutable ‘variable’ whose value is known at compile time

2020-09-17 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 17 September 2020 at 22:25:47 UTC, claptrap wrote:

If enum means manifiest constant, or compile time constant, 
then it makes more sense, as you allude to in a later post. But 
'enum' is a terrible name for that and I dont think my brain 
will ever stop finding it incongruous.


And in my mind, what is a single-member enum if not a 
compile-time constant? This is why naming is hard.


Re: enum and const or immutable ‘variable’ whose value is known at compile time

2020-09-17 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 17 September 2020 at 13:25:08 UTC, Mike Parker wrote:


Well, I was already using anonymous enums for compile-time


And, I should add, I have *never* seen C enums as an enumerated 
list of values. I've always seen them as an alternative for 
#defined constants because they're anonymous. It's *named* enums 
that I view as enumerated lists of values. So, in terms of 
vocabulary definitions, that was already a non-issue for me 
before I even discovered D.


Re: enum and const or immutable ‘variable’ whose value is known at compile time

2020-09-17 Thread Mike Parker via Digitalmars-d-learn
On Thursday, 17 September 2020 at 13:13:46 UTC, Simen Kjærås 
wrote:




To quote Bill Baxter from way back when
(https://forum.dlang.org/post/fjdc4c$2gft$1...@digitalmars.com):


> Why does:
> final int x = 3;
> make any more intuitive sense than:
> enum int x = 3;
> ?

There are these things called "words".  And they have 
"meanings"...

enum: (short for "enumeration", the noun form of "enumerate")
   "to specify one after another : list"
final:
   "not to be altered or undone "


To be clear: I don't mind 'enum' being used this way, but if I 
were to do things over again, I would have used 'alias'.




Well, I was already using anonymous enums for compile-time 
constants anyway. For example, when translating C headers with 
lots of #defined constants (OpenGL is the poster child), I was 
doing this in Derelict:


enum {
   GL_THIS = ...,
   GL_THAT = ...,
}

So enum for this has always made sense to me. I would have been 
fine with final, but it would have been a leap for me because of 
my Java background; I would have kept seeing it as a synonym for 
const. And I would never have liked the Alias approach.


But no matter what solution would have been implemented (final, 
Alias, new keyword), I would have looked it up then, put my head 
down and gotten right back to writing code. It just happens the 
one that's most intuitive to me was picked :-)




Re: enum and const or immutable ‘variable’ whose value is known at compile time

2020-09-17 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 17 September 2020 at 09:44:20 UTC, claptrap wrote:


Seriously how it's implemented is irrelevant.


And to be clear, my point wasn't about how it's implemented. My 
point was that:


enum { foo = 10; }

and

enum foo = 10;

Are effectively the same thing, whether it's implemented that way 
or not. So why on earth would a new keyword be necessary?




Re: enum and const or immutable ‘variable’ whose value is known at compile time

2020-09-17 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 17 September 2020 at 09:44:20 UTC, claptrap wrote:



Names are important, principle of least astonishment and all 
that, pretty much everyone coming to D is going be WTF in 
learning about that. And if you keep overloading existing 
keywords with more and more meanings the code gets harder and 
harder to grep at first glance.


I can attest that in the 17 years I've been hanging around here, 
the fact that enum is used to indicate a manifest constant has 
not been a serious source of WTF posts. So I think "pretty much 
everyone coming to D" have decided it's either perfectly fine or 
perfectly tolerable. It's the sort of thing that may not be 
obvious, but once you figure you absorb it and get down to 
coding. I know some people would prefer it were something else 
and some don't care. I'm squarely in the camp that thinks it 
makes perfect sense and it would be silly to create a new keyword 
for it.


Re: enum and const or immutable ‘variable’ whose value is known at compile time

2020-09-16 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 17 September 2020 at 00:32:40 UTC, Cecil Ward


So can the result of declaring certain things with enum ever 
have an _address_ then? (According to legit D code that is, 
never mind the underlying implementation details, which may not 
be observable)


No. Think of it as a named literal.

Given enum x = 10, then int num = x is the same as if you had 
typed int num = 10.


Thats’s why you have be careful with array enums if you care 
about allocations.




I actually really hate the way enum was bent out of shape 
and twisted from its original purpose so that finally we end up 
with a way of defining only one value, not the whole range of 
permissible values for a type as in the beginning.


I wish there were just a keyword ‘constant’ or something (yes, 
I know, you could just call that something ‘enum’, or 
‘const’)


enum foo is essentially a shortcut for enum { foo }. It’s neither 
bent out of shape nor twisted. Consider that C++ added the new 
keyword constexpr for the same thing. Why pollute the namespace 
with a new keyword when you already have one that fits?


Re: importing a symbol without specifying a subpackage name

2020-09-16 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 16 September 2020 at 13:30:57 UTC, 60rntogo wrote:



then saying "import foo : Bar;" yields an error "module foo is 
in file 'foo.d' which cannot be read". I'm curious, how is this 
behavior achieved in the standard library?


To expand on Adam's reply:

https://dlang.org/spec/module.html#package-module


Re: Problem with gfm.math.matrix (some gamedevs out there ?)

2020-09-03 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 3 September 2020 at 12:36:35 UTC, Thomas wrote:



My example code:
-
import std.stdio;

int main()
{

import gfm.math.matrix;

const int width = 800;
const int height = 600;

auto projectionMatrix = mat4!(float).identity();
auto ratio = cast(float)width / cast(float)height;

projectionMatrix = mat4!(float).perspective( 45.0f, ratio, 
0.0f, 100.0f );


writeln("projectionMatrix: ", projectionMatrix );

auto inversedMatrix = mat4!(float).identity();
inversedMatrix = projectionMatrix.inverse();  // <-- why 
this does not work ?

writeln("inversedMatrix: ", inversedMatrix );

return 0;
}


This is not the problem, but FYI these two lines are reduntant:

auto projectionMatrix = mat4!(float).identity();
auto inversedMatrix = mat4!(float).identity();

This is all you need:

auto projectionMatrix = mat4!(float).perspective( 45.0f, ratio, 
0.0f, 100.0f );

auto inversedMatrix = projectionMatrix.inverse();

`perspective` and `inverse` return new instances that overwrite 
the two identity matrices you initialized, so you're doing work 
you don't need to do.






The projection matrix will be calculated correctly with
[1.3, 0, 0, 0, 0, 1.79259, 0, 0, 0, 0, -1, -0, 0, 0, -1, 0] 
assuming that the screen size is 800x600.


But using the .inverse() function in gfm returns only a matrix 
with following values:
[-nan, -nan, -nan, -nan, -nan, -nan, -nan, -nan, -nan, -nan, 
-nan, -nan, -nan, -nan, inf, -inf]


I don't know what I am doing wrong here:
  - do I call the function wrong way ? (but there is no other 
way)
  - is there a bug in the function ? (I do not believe that 
because the library is battle proved)




My guess is the problem is in the `inverse` implementation:

https://github.com/d-gamedev-team/gfm/blob/master/math/gfm/math/matrix.d#L448

T invDet = 1 / det;

It doesn't check if det is 0.

This shows 1f / 0f results in `inf`:

import std;
void main()
{
float f = 0;
float i = 1 / f;
writeln(i);
}

https://run.dlang.io/is/ZyggRg

With all those zeroes in the perspective matrix and all the 
multiplications in the `inverse` function, I guess things are 
getting wonky.






Re: bindbc OpenGL ES

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

On Monday, 31 August 2020 at 14:04:19 UTC, Danny Arends wrote:
Don't know exactly where to post this, so I hope the bindbc 
team will see the post here in learn.


I was wondering if it would be possible to have bindbc OpenGL 
ES bindings ?




I can make time for it sometime this week.


Re: How do I statically build a project using DUB?

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

On Sunday, 30 August 2020 at 02:38:52 UTC, Kirill wrote:



I am trying to link the GTK library. I have the GTK Runtime 
installed on Windows 10 pc.



Unless things have changed in the last few years, GTK is not 
intended to be linked statically on Windows. You'll have to 
figure out how to compile it yourself as a static library. I 
recall reading about this a while back. IIRC, there were also 
some source changes required.


Then there's also the matter of licensing. GTK is released under 
the LGPL, which means if you statically link then your executable 
is considered a derivative work and must abide by the 
distribution terms of the LGPL.




Do I need to build the static GTK library from the source? Then 
how do I tell DUB to include that library?


DUB has a "libs" directive in the build settings:

https://dub.pm/package-format-sdl.html#build-settings
https://dub.pm/package-format-json.html#build-settings


Re: Installing D on Fresh Windows 10 machine is a pain

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

On Thursday, 27 August 2020 at 17:34:03 UTC, bachmeier wrote:



It would be nice to have a screencast of this for someone that 
doesn't work often with Windows.


There are screenshots in the VS docs, e.g.,

https://docs.microsoft.com/en-us/visualstudio/install/modify-visual-studio?view=vs-2019

And videos on YouTube.


Re: Installing D on Fresh Windows 10 machine is a pain

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

On Thursday, 27 August 2020 at 16:39:05 UTC, Mike Parker wrote:



Or maybe better, just go to the 'Individual components', select 
the latest Windows 10 SDK version, and install it.


Or just check the installation folder. For me, it's:

C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\ucrt\x64


Re: Installing D on Fresh Windows 10 machine is a pain

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

On Thursday, 27 August 2020 at 15:59:51 UTC, Jesse Phillips wrote:
Installing D isn't new to me but I haven't really had to do a 
fresh install for awhile and come from a time when I was 
installing VS from 2010 and up.


VS 2019 Professional is installed on the system.

I have installed the C++ desktop development for VS.

DMD installer still is unable to find "VS installed"

I've also installed the C++ 2010 redistributables to try and 
use the MinGW install path.


I've also utilized the developer command prompt
---

Upon compiling a 64bit hello world I get

helloworld> dmd -m64 .\hello.d
LINK : fatal error LNK1104: cannot open file 'libucrt.lib'
Error: linker exited with status 1104

This appears to have been a library moved around VS 2015 
release, and I don't want to do the copying around solution the 
internet suggests.


I understand that as a compiler it is important to support 
systems of an older nature and so updating to the latest C++ 
runtimes might hinder usage of D.


It is just sad that at one point the install really did just 
take care of things and now it can't find things.


It has worked for me every time I've installed it since VS 2015. 
libucrt.lib should have been installed by the VS installer. 
Something to check: run the installer again, click the checkbox 
in corner of the 'Desktop development with C++' box, then look 
under the 'Installation details' list that comes up and make sure 
a version of the Windows 10 SDK is installed. If you don't see 
one with a check next to it, then check the latest one and modify 
the installation.


Re: Installing D on Fresh Windows 10 machine is a pain

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

On Thursday, 27 August 2020 at 16:35:07 UTC, Mike Parker wrote:

It has worked for me every time I've installed it since VS 
2015. libucrt.lib should have been installed by the VS 
installer. Something to check: run the installer again, click 
the checkbox in corner of the 'Desktop development with C++' 
box, then look under the 'Installation details' list that comes 
up and make sure a version of the Windows 10 SDK is installed. 
If you don't see one with a check next to it, then check the 
latest one and modify the installation.


Or maybe better, just go to the 'Individual components', select 
the latest Windows 10 SDK version, and install it.


Re: Dub can't find and download packages

2020-08-06 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 5 August 2020 at 17:32:49 UTC, vanaur wrote:


My concern is thus the following: I can't add packages to my 
project, Dub warns me that they are not available.
For the example, I try to add this dependency 
(https://code.dlang.org/packages/pegged) with the following



command:  dub add pegged . Dub then returns an error:

Failed to get versions for package pegged on provider registry 
at https://code.dlang.org/ (fallbacks registry at 
https://codemirror.dlang.org/, registry at 
https://dub.bytecraft.nl/, registry at 
https://code-mirror.dlang.io/): Failed to download 
https://code.dlang.org/api/packages/infos?packages=%5B%22pegged%22%5D_dependencies=true=true

Could not find package 'pegged'.


My project was initialized correctly with Dub (dub init... + 
the whole procedure). I also tried to add the dependency 
manually, in dub.sdl:


  dependency "pegged" version="~>0.4.2"

But it doesn't change anything.
Why doesn't it work? What do I need to do to get Dub to 
download and add dependencies?


You're doing it right. It's possible that the servers were down 
(though it would be a rare circumstance for the fallbacks to be 
down). Or there might be an issue with pegged specifically. Have 
you tried it since? Does it work for other packages?




PS: how do you write blocks of code and insert links in forum 
posts? I've tried the makefile syntax, but it doesn't work.


This is a web frontend for plain-text newsgroups at 
nntp://news.digitalmars.com, which also has a mailing list 
frontend. So it doesn't support fancy code formatting. If you'd 
like, you can set the code off with Markdown-style backticks:


```
// Some code
```

It's a common idiom here. And, one day, the web frontend may get 
the ability to display such code blocks in a formatted manner.


As for links, just paste the plain-text link and the forum 
software will linkify it. It's common to use a Markdown-style 
footnote. So, for example, I might recommend like this that you 
visit dlang.org [1].


Alternatively, you could put the link on a new line:

https://dlang.org/

Up to you.

[1]: https://dlang.org/






Re: Static link of glfw3 library fails for me

2020-07-27 Thread Mike Parker via Digitalmars-d-learn

On Monday, 27 July 2020 at 07:30:42 UTC, John Burton wrote:


For reference I got this to work by doing the following :-

1) Installed visual studio build tools. I could not get this to 
work at all with the linker etc that comes with ldc2.
2) Copied the glfw3.lib vs2019 version file into my build 
directory (obviously could point the linker at it too which 
would be better)

3) Used the following dub.sdl

name "game"
description "Test Project"
authors "Me"
copyright "Copyright ┬® 2020, Me"
license "proprietary"
dependency "bindbc-glfw" version="~>0.10.0"
dflags "-mscrtlib=ucrt"
libs "glfw3"
versions "BindGLFW_Static"

The key seems to be using the dflags line to make it link with 
the "modern" C libraries, and using the microsoft linker.


I appear to have glfw3 statically linked and working :)


Cool. To be clear, you're still compiling with LDC, correct? I'm 
pretty sure DMD is using the universal C runtime out of the box 
when VS is installed.


Re: Static link of glfw3 library fails for me

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

On Sunday, 26 July 2020 at 08:28:29 UTC, John Burton wrote:


versions "BindGLFW_Static"
libs "glfw3"
lflags "-L..\\work\\3rdparty\\lib"




And by the way, you're going to need to link more libs than glfw3 
for a static link. You'll need all of its dependencies, as well 
(OpenGL32.lib, gdi32.lib, etc).


Re: Static link of glfw3 library fails for me

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

On Sunday, 26 July 2020 at 08:28:29 UTC, John Burton wrote:



And I get the following errors from the link :-

lld-link: error: undefined symbol: __GSHandlerCheck
lld-link: error: undefined symbol: __security_check_cookie
lld-link: error: undefined symbol: __security_cookie


I believe that's because the GLFW library was compiled with the 
Microsoft compiler's /GS option:


https://docs.microsoft.com/en-us/cpp/build/reference/gs-buffer-security-check?view=vs-2019

The __security_* functions are MS extensions to the C standard 
library. A quick search suggests you should try linking with 
bufferoverflowU.lib. Either that or compile GLFW with /GS- to 
turn off the security checks.


This is one reason I gave on on static linking pre-built C 
binaries long ago. I use the static bindings with import 
libraries, but I don't touch static libs unless I compile them 
myself.


Re: How DerelictCL works

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

On Tuesday, 21 July 2020 at 12:00:03 UTC, bioinfornatics wrote:

Dear,

I would like to use OpenCL in D. Thus I try to use DerelictCL.
But I fail to use it I encounter this error message:
--
/opt/jonathan/jonathan-dlang_ldc2092/root/usr/include/d/derelict/opencl/constants.di(835):
 Error: genCLVectorTypes cannot be interpreted at compile time, because it has 
no available source code
/opt/jonathan/jonathan-dlang_ldc2092/root/usr/include/d/derelict/opencl/constants.di-mixin-835(835):
 Error: declaration expected, not <
--


Looks like an issue in a code gen function. It might be due to 
changes in LDC. I'll ping Guillaume.


Re: Send empty assoc array to function

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

On Friday, 10 July 2020 at 03:59:37 UTC, Mike Parker wrote:

On Thursday, 9 July 2020 at 21:13:49 UTC, JN wrote:



Interesting. Often in D discussion, an argument pops up that 
the language should be protecting against hidden breakages 
from API changes. This would be an example of that happening.


void foo(int[int] bar), someone calls it with a null, suddenly 
the signature changes to void foo(int* bar) and you will be 
sending a null pointer and possibly breaking the app.


Meh. You could say the same about foo(int[]), or 
foo(SomeClass). AAs are reference types. Reference type 
instances can be null.


Besides, when it comes to breakage, the discussions I've seen are 
about breaking changes in the language/compiler. There are 
opportunities in most (if not all) programming languages to 
introduce silent breakage when a library maintainer changes a 
public-facing API. And when it happens, that's not the fault of 
the language, but the library maintainer.


Re: Send empty assoc array to function

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

On Thursday, 9 July 2020 at 21:13:49 UTC, JN wrote:



Interesting. Often in D discussion, an argument pops up that 
the language should be protecting against hidden breakages from 
API changes. This would be an example of that happening.


void foo(int[int] bar), someone calls it with a null, suddenly 
the signature changes to void foo(int* bar) and you will be 
sending a null pointer and possibly breaking the app.


Meh. You could say the same about foo(int[]), or foo(SomeClass). 
AAs are reference types. Reference type instances can be null.


Re: Translating C headers to D: How do I compile it?

2020-06-27 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 28 June 2020 at 04:59:12 UTC, Kirill wrote:
Hello. I am learning how to translate C headers to D. But how 
do I compile it? I am stuck with this.


I have 4 files in the same directory: main.d, something.d, 
some.h, some.c


some.h:
//header guards
int add(int a, int b);

some.c:
#include "some.h"
int add(int a, int b) { return a+b; }

something.d:
module something;
int add(int a, int b);


This should be extern(C) int add(int a, int b). The extern(C) 
tells the D compiler to use the standard C calling convention 
when calling that function.




main.d:
import std.stdio: writeln;
import something;

void main() { writeln("5+7=", add(5, 7); }

How do I compile this correctly?

Thank you for your time.


The C file and the header do not need to be (and arguably 
shouldn't be) in the same directory as the D files. Use a C 
compiler to compile the C file to an object file or into a static 
library. Assuming you're using DMD, then on Windows you'll want 
to use the Microsoft compiler (cl) which is part of the Microsoft 
Build Tools distribution and Visual Studio. Otherwise, you'll 
need the Digital Mars C and C++ compiler. On other platforms, GCC 
or clang will be fine. If you don't know how to compile C 
programs, there's plenty of information online for all the major 
compilers.



Then, when you compile your D program, you'll need to link with 
the object file or the static library you compiled with the C 
compiler. On Windows, if you used Digital Mars C (dmc), then you 
won't need to pass any special compiler flags if you are calling 
DMD directly. If you used the MS compiler, you'll need to pass 
either -m32mscoff for 32-bit, or -m64 for 64-bit.





Re: Garbage collection

2020-06-27 Thread Mike Parker via Digitalmars-d-learn

On Saturday, 27 June 2020 at 11:11:38 UTC, James Gray wrote:



I am measuring the memory usage using top from the command line.
GC.minimize() does seem to stop the leak. But it doesn't 
explain why
the program isn't releasing essentially all the memory between 
calls
to f (it using around 2GB ram all the time). Is there a way of 
achieving that?


It's not a leak. The GC allocates memory as it needs it and holds 
on to it. When something is collected, the GC can reuse then 
released memory when it needs it.


Re: Passing iterators into functions

2020-06-25 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 25 June 2020 at 03:35:00 UTC, repr-man wrote:



This seems to have to do with the fact that all iterators 
return their own unique type.  Could someone help me understand 
the reason behind this design and how to remedy my situation?


Ranges conform to well-defined interfaces. Given that the 
algorithms in Phobos are templates and use structs rather than 
classes, this means the interfaces are checked at compile time 
(see the `is*` templates in std.range.primitives [1]). It also 
means that there is no concrete range "type" returned by these 
functions. That's why all of them return `auto` instead of a 
specific type. You never need to know the specific type of a 
range.


Arrays are ranges only because of the free-function 
implementation of the range interfaces in std.range.primitives 
which all take an array as the first argument so that they may be 
called using UFCS in any templated range algorithm.


So when you input an array to a range algorithm, the algorithm 
has no idea it has an array. It just calls R.emtpy, R.front, 
etc., without ever caring what the actual type is. And you can 
chain them because each algorithm wraps the input range with 
custom range type that actually implements the algorithm (in 
e.g., `popFront`--that's also why ranges are lazy), and that's 
what is returned. In a chain of function calls, popFront is 
called on the outermost range, which calls popFront on its 
wrapped range, which calls popFront on its wrapped range, etc. So 
if you append std.array.array to the end of the chain, it will 
kick off execution of the whole chain of calls by making the 
first call to popFront in order to copy the result into a new 
array.


Chapter 6, "Understanding Ranges", from "Learning D" is available 
freely online [2]. You should give it a read.



[1] https://dlang.org/phobos/std_range_primitives.html
[2] https://hub.packtpub.com/understanding-ranges/


Re: When is exception throwing @nogc with -dip1008?

2020-06-22 Thread Mike Parker via Digitalmars-d-learn

On Monday, 22 June 2020 at 13:59:22 UTC, Per Nordlöw wrote:


I can't find any docs on DIP-1008. The link

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

given in the release notes here

Ref: https://dlang.org/changelog/2.079.0.html#dip1008

is broken.


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


Re: Some questions about strings

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

On Monday, 22 June 2020 at 04:08:10 UTC, Denis wrote:

On Monday, 22 June 2020 at 03:31:17 UTC, Ali Çehreli wrote:
:

string is char[]
wstring is wchar[]
dstring is dchar[]


Got it now. This is the critical piece I missed: I understand 
the relations between the char types and the UTF encodings 
(thanks to your book). But I mistakenly thought that the string 
types were different.




They're aliases in object.d:

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


Re: Mixin and imports

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

On Monday, 8 June 2020 at 02:55:25 UTC, jmh530 wrote:
In the code below, foo!fabs compiles without issue, but 
foo!"fabs" does not because the import is not available in the 
string mixin. If I move the import to the top of the module, 
then it works. However, then if I move foo to another module, 
then it will no longer compile since it is in different modules.


Is there any way I can make sure the mixin knows about the 
import?



The problem isn't the mixin. It's the template. Templates take 
the scope of their declaration, not their instantiation. So the 
mixin is getting the template's scope.


Anyway, this appears to work:

`double z = foo!"std.math.fabs"(x);`





Re: DMD 2.092 and DIP 25

2020-05-30 Thread Mike Parker via Digitalmars-d-learn
On Saturday, 30 May 2020 at 16:14:34 UTC, Steven Schveighoffer 
wrote:




This is not about const or not, it's about lifetime management.

For example, this would return a pointer to a stack frame that 
is about to go away:


const(char)* foo()
{
   ErrorInfo info;
   return info.message;
}

I know that you have already fixed the problem, but I wanted to 
make sure you understood why the compiler is complaining.


Yes, that was me having never actually read DIP 25 and 
misunderstanding what it was about. I've since been educated. 
Thanks!





Re: DMD 2.092 and DIP 25

2020-05-30 Thread Mike Parker via Digitalmars-d-learn

On Saturday, 30 May 2020 at 07:30:17 UTC, Max Samukha wrote:

On Saturday, 30 May 2020 at 07:00:07 UTC, Mike Parker wrote:


https://run.dlang.io/is/aOZqww

Since  2.067.1: Success and no output


Thanks, Max (and you, too, Seb). I had forgotten that 
run.dlang.io supports compilers going so far back.


Re: DMD 2.092 and DIP 25

2020-05-30 Thread Mike Parker via Digitalmars-d-learn

On Saturday, 30 May 2020 at 07:30:17 UTC, Max Samukha wrote:

On Saturday, 30 May 2020 at 07:00:07 UTC, Mike Parker wrote:

https://run.dlang.io/is/aOZqww

Since  2.067.1: Success and no output


Thanks! I forgot that run.dlang.io supports all those old 
compilers.


DMD 2.092 and DIP 25

2020-05-30 Thread Mike Parker via Digitalmars-d-learn

The following declarations now give a deprecation warning:

```d
struct ErrorInfo {
private:
char[32] _error;
char[96] _message;

public @nogc nothrow @property:
/**
Returns the string "Missing Symbol" to indicate a symbol 
load failure, and

the name of a library to indicate a library load failure.
*/
const(char)* error() const { return _error.ptr; }

/**
Returns a symbol name for symbol load failures, and a 
system-specific error

message for library load failures.
*/
const(char)* message() const { return _message.ptr; }
}
```

I find it rather annoying, as I'm returning `const(char)*` and 
not `char*`, but it is what it is. My question is, if I add 
`return` to the function declarations, will this compile all the 
way back to DMD 2.067 *without* `-preview=dip25`? It works on 
2.091.0. I always assumed a preview feature's syntax wasn't 
supported without the preview switch.


Re: What's the best way to find out which exceptions may be thrown ?

2020-05-27 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 27 May 2020 at 10:30:36 UTC, wjoe wrote:

On Wednesday, 27 May 2020 at 10:01:33 UTC, Mike Parker wrote:
Could you please elaborate why checked exceptions are more 
annoying?




For me, it's because they require all functions that touch them 
to either try/catch or include an exception specification in its 
declaration. In my Java days, I ended up just doing what so many 
others do and adding `throws Exception` or `catch(Exception)` to 
avoid having to handle multiple exception types. Most of the 
time, I didn't care what specific sort of exception was thrown.


Re: What's the best way to find out which exceptions may be thrown ?

2020-05-27 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 27 May 2020 at 09:56:07 UTC, wjoe wrote:


The problem with catch(Exception) is that it's run time whereas 
I'd like to know compile time which exception may possibly be 
thrown.


So I take it the only way to find out what may be thrown is to 
read the source code of the called function(s) and the rat tail 
that follows - and to rely on documentation to be accurate and 
complete if the source code isn't available.


That's sort of annoying.


Checked exceptions are much more annoying. And without them, 
there's no way (as far as I can see) the compiler can verify what 
a function may throw without parsing the source of every function 
a call chain touches. That's rather impractical.


Re: What's the best way to find out which exceptions may be thrown ?

2020-05-27 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 27 May 2020 at 09:42:58 UTC, Mike Parker wrote:

On Wednesday, 27 May 2020 at 09:40:08 UTC, wjoe wrote:



The compiler will complain that bar(int) isn't nothrow.

What's the best way to find out which Exceptions aren't 
handled inside of foo() for foo to be able to be nothrow 
without using a 'catch (Exception){}' catch-all?


`catch(Exception)`.


I should add that if you're only catching specific exceptions in 
a `nothrow` function, then it isn't `nothrow`. You have to catch 
Exception because D does not have exception specifications. I 
would expect the compiler to complain if you try to do otherwise.


Re: What's the best way to find out which exceptions may be thrown ?

2020-05-27 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 27 May 2020 at 09:40:08 UTC, wjoe wrote:



The compiler will complain that bar(int) isn't nothrow.

What's the best way to find out which Exceptions aren't handled 
inside of foo() for foo to be able to be nothrow without using 
a 'catch (Exception){}' catch-all?


`catch(Exception)`.


Re: How to target ldc compiler only in dub

2020-05-26 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 27 May 2020 at 01:41:47 UTC, data pulverizer wrote:

On Wednesday, 27 May 2020 at 01:06:48 UTC, mw wrote:

And you can use option

dub -v

to verify it's calling the correct compiler cmd.


Thanks. Is there anyway to verify that the flags I am passing 
to the compiler are being used?


dub -v

It shows you the full compiler command line.


Re: How to get the pointer of "this" ?

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

On Monday, 25 May 2020 at 16:26:31 UTC, Vinod K Chandran wrote:



Here is my full code. Please take a look.
https://pastebin.com/av3nrvtT


The error has nothing to do with taking a pointer to `this`. It's 
suggesting that somewhere in your code you're attempting to use 
the `this` reference like an lvalue, e.g. making an assignment to 
it. I don't see anywhere that you're doing that. Glancing through 
the code, I don't see anywhere that you're doing that (and 
unfortunately this is not a minimal example because of 
dependencies on some of your other modules, so I can't compile it 
myself).


What was the line number of the original error? Sometimes the 
line number reported isn't where the error actually occurs. Also, 
try to see if you can minimize it so that someone else can 
compile it.


A couple of points about your code unrelated to your error:

* `private static int btnNumber = 1;` -- `static` has no meaning 
at module scope. You'll see it in C code, but in D `private` 
provides the same functionality. You can delete `static` from 
those module scope declarations.


* `with(this){` -- you absolutely do not need to do this. `this` 
is never required as a prefix on any member unless, e.g., a 
member variable and another more locally scoped variable have the 
same name, like `this.x = x` in a setter function to distinguish 
the member variable from the function parameter. You're already 
using the convention of naming your member variables with a `m` 
prefix, so you won't run into that issue. `this.mFoo` is exactly 
the same as `mFoo`, and with(this) is pointless. I mean, if you 
want to use `this.mFoo` as a stylistic choice, that's your call 
(though the `m` makes it redundant really), but even then using 
`with(this)` serves no purpose.








Re: How to get the pointer of "this" ?

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

On Monday, 25 May 2020 at 08:39:23 UTC, John Burton wrote:


I believe that in D *this* is a reference to the
object and not a pointer like in C++.
So I think that writing  might be what you need?


No. A class reference is a pointer under the hood. Getting its 
address will result in a pointer to the reference variable 
itself, not to the class instance. When passing a reference to a 
C API, casting it directly to the C type is correct.


Re: Storing a reference to the calling object

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

On Saturday, 23 May 2020 at 09:27:46 UTC, Tim wrote:
Hi all, I'm a little new to D and I'm wondering how I can store 
a reference to the calling object. I want to create a reference 
to an object's parent so that each time I go to update the 
sprite, it is able to grab its position from the parent.


So if I have:

class Sprite{
/// Postional components of the sprite
int* x, y;
SDL_Surface* image_surface;
auto parent;

this(const char* path, auto parent){
writeln(*x);
this.parent = parent;
}

void update(){
// Copy loaded image to window surface
writeln("Sprites x: ",  *x);
SDL_Rect dstRect;
dstRect.x = parent.x;
dstRect.y = parent.y;
SDL_BlitSurface(image_surface, null, g_surface, 
);

}
}

And call it like so:

sprite = new Sprite(path, this);

How can I make this sort of thing work? Thanks a lot in advance 
for the help!


Since you're using classes, one way is to use a common base class 
or an interface. But assuming "parent" is the owner of the Sprite 
instance, you might eliminate the dependency on the parent and 
have it update the Sprite's position when it's updated instead of 
maintaining a position separately.


class Parent {
   private Sprite sprite;

   void updatePosition(int x, int y)
   {
   sprite.x = x;
   sprite.y = y;
   }
}


Re: RtlAdjustPrivilege and NtRaiseHardError

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

On Friday, 22 May 2020 at 19:19:19 UTC, Arsium wrote:
Just I tried to launch those functions from win32 api and seems 
doesn't work




"doesn't work" isn't very helpful. Are you seeing compiler 
errors? Linker errors? Runtime errors? Please describe your 
problem.


Re: How to use this forum ?

2020-05-20 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 20 May 2020 at 21:06:35 UTC, welkam wrote:
On Wednesday, 20 May 2020 at 20:49:52 This is not a forum but a 
frontend to a mailing list.


Both the forums and the mailing lists are interfaces to 
newsgroups at news.digitalmars.com.


Re: Why emsi containers have @disabled this(this) ?

2020-05-19 Thread Mike Parker via Digitalmars-d-learn

On Tuesday, 19 May 2020 at 20:51:01 UTC, Luis wrote:
So, I'm writing my own implementation of sparse sets, and I 
take as reference emsi_containers for allocator usage. I saw 
that they have disabled postblit operator... But i don't 
understand exactly why. In special, when they implement 
InputRange over the containers, but having disabled postblit, 
make nearly useless (at least as I see on this old post 
https://forum.dlang.org/thread/n1sutu$1ugm$1...@digitalmars.com?page=1 )


Taking a look to std.container.array, I see that it have 
postblit disabled, but here the range interface isn't 
implemented. Instead it's recommended to do a slice, where 
apply range algorithms.


In the source for the EMSI containers, they provide opSlice that 
returns an internal Range type. And not all of the containers 
implement InputRange. SList does, but HashSet does not.




I should take this way (ie. forgot to implement front and 
popFront)? I actually have postblit disabled and implemented 
InputForward, but as I say, this make it useless as range. I 
need, like std.container.array, to use slice for do a foreach 
or any range algorithm.


As a general rule of thumb, containers *should not* be used as 
InputRanges. And that includes ForwardRange, BidirectionalRange, 
and RandomAccessRange (each range interface builds upon the one 
before--simply implementing `save` does not make a ForwardRange 
unless the type also has the InputRange interface).


Input ranges are intended to be consumed. At the end of an 
iteration, they should be empty. The convention is to obtain a 
range by slicing the container. So your containers should 
implement opSlice and return an anonymous range type just like 
std.container.array, containers.hashset, containers.slist, etc. 
do. Then iteration becomes:



foreach(elem; container[]) {
}

// The range has been consumed, but the container still holds all 
the elements.





Re: any chance to get it working on windows xp?

2020-05-17 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 17 May 2020 at 22:30:22 UTC, a beginner wrote:

I have searched online for some info, indeed I found something, 
but not being familiar with the tools it hasn't been terribly 
useful. Only it confirms that windows support is somewhat 
disappointing in general, xp or not.


I've been using D on Windows since I first found it in 2003. From 
my perspective, Windows support is fairly solid.


It seems to me my best chance is to stay with dmd 2.085.1, try 
fix the cache problem in dub 1.11 myself (or give up on that 
and build "by hand"), probably wrestle some linking problems 
(pretty sure I wouldn't succeed with that) and be happy until I 
can upgrade. After all, these days programming is just a hobby 
for me. But honestly, all this is quite annoying for a 
beginner. In my experience, trouble getting the tools to work 
is often the biggest obstacle in learning a new language (well, 
unless it's something really weird...), which in many cases 
means giving up after some cursing.


Unfortunately, the minimum Windows version "officially" supported 
is Windows 7:


https://forum.dlang.org/post/ktfgps$2ghh$1...@digitalmars.com

With no testing on XP, you are bound to run into difficulties 
trying to use the tools there. So yeah, your best bet is using a 
compiler version that works and see if building dub from source 
makes a difference. If you can't get dub to work, then you'll 
want to look into using rdmd, which has shipped with dmd for 
years now, or perhaps makefiles.


Re: XMM Intrinsics

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

On Friday, 8 May 2020 at 20:14:05 UTC, Simen Kjærås wrote:



The intel-intrinsics dub package aims to provide a 
compiler-independent layer: 
https://code.dlang.org/packages/intel-intrinsics


TIL, thanks! :)

--
  Simen


DConf 2019: Not intrinsically about intrinsics -- Guillaume Piolat

https://youtu.be/cmswsx1_BUQ


Re: Building Win32 application via dub

2020-04-29 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 29 April 2020 at 11:55:54 UTC, Sam E. wrote:



I cannot find a D example using Win32 and the normal main 
function, and while it is working for simple message boxes, as 
soon as I want to do something slightly more complex (using a 
window), an hInstance has to be provided (as far as I 
understand, I'm not that knowledgeable with Win32).


FYI, a quick google turned up this example:

https://gist.github.com/caiorss/e8967d4d3dad522c82aab18ccd8f8304

It's C++ and not D, but the Win32 calls are the same. You should 
be able to adapt that to D fairly easily.


Re: Building Win32 application via dub

2020-04-29 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 29 April 2020 at 11:55:54 UTC, Sam E. wrote:

On Wednesday, 29 April 2020 at 10:46:30 UTC, Mike Parker wrote:

On Wednesday, 29 April 2020 at 10:44:48 UTC, Mike Parker wrote:


Yeah, it says "WinMain is needed", which has never been true.


THere's no need for the def file either.


What's the way to get the hInstance without the use of WinMain?

From Microsoft documentation:
hInstance is the handle to the application instance. Get this 
value from the hInstance parameter of wWinMain.


https://docs.microsoft.com/en-us/windows/win32/learnwin32/creating-a-window

I cannot find a D example using Win32 and the normal main 
function, and while it is working for simple message boxes, as 
soon as I want to do something slightly more complex (using a 
window), an hInstance has to be provided (as far as I 
understand, I'm not that knowledgeable with Win32).


auto hInstance = GetModuleHandleA(null);

It's documented to return HMODULE, but HINSTANCE is the same 
thing (all the HANDLE types are void*). Passing null causes it to 
return the handle associated with the process, so for the 
executable "module", that's what you want (e.g., the process 
handle is the module handle). In a DLL, it wouldn't be, as the 
DLL would have a different handle than the process.


https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulehandlea


Re: Building Win32 application via dub

2020-04-29 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 29 April 2020 at 10:44:48 UTC, Mike Parker wrote:

On Wednesday, 29 April 2020 at 10:26:40 UTC, Sam E. wrote:



I took the WinMain from https://wiki.dlang.org/D_for_Win32, 
should that documentation be updated to use a normal main 
function instead? Also the details regarding linker flags may 
be a good addition to that wiki page.


Yeah, it says "WinMain is needed", which has never been true.


THere's no need for the def file either.


Re: Building Win32 application via dub

2020-04-29 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 29 April 2020 at 10:27:35 UTC, Sam E. wrote:



To be honest, I haven't yet found the way to switch between 
-m32 and -m64 (or other) via dub :)


Pass the -a flag on the dub command line with the appropriate 
argument:


For -m32: -ax86
For -m32mscoff: -ax86_mscoff
For -m64: -ax86_64

Note that on 64-bit Windows, recent versions of dub will be 
calling the compiler with -m64 by default.


Re: Building Win32 application via dub

2020-04-29 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 29 April 2020 at 10:26:40 UTC, Sam E. wrote:



I took the WinMain from https://wiki.dlang.org/D_for_Win32, 
should that documentation be updated to use a normal main 
function instead? Also the details regarding linker flags may 
be a good addition to that wiki page.


Yeah, it says "WinMain is needed", which has never been true.


Re: Building Win32 application via dub

2020-04-29 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 29 April 2020 at 09:43:53 UTC, Sam E. wrote:

Though the program built with dub is now crashing at runtime 
when calling `writeln` within the `WinMain` block.


The exception error is:


Exception has occurred: W32/0xc096
Unhandled exception at 0x7FF643C5AFE4 in test-win32.exe: 
0xC096: Privileged instruction.


So it feels that something else is missing or wrong.

Any pointer would be helpful :)

Screenshot of the call site: https://postimg.cc/5YtY9PRQ
Screenshot of the expection: https://postimg.cc/K3vKz0pg


Most likely because you're calling writeln before initializing 
the runtime.


Also, when using WinMain, you aren't going to see any output from 
writeln because you won't have a console window. The linker will 
create a "Windows subsystem" app rather than a "Console 
subsystem".


Really, there's no reason at all to use WinMain. Just create a 
standard main function. Then you don't need to worry about 
manually initializing the runtime and you'll have a console 
window by default. You can always turn it off in anything you 
want to ship without the console by adding the appropriate dflags 
to your dub file:


-L/SUBSYSTEM:WINDOWS -L/ENTRY:mainCRTStartup

Conversely, you can get the console window in a WinMain app with:

-L/SUBSYSTEM:CONSOLE -L/ENTRY:WinMainCRTStartup

Though, again, there's really no reason to use WinMain.

The /SUBSYSTEM flag works with the default OPTLINK linker and 
Microsoft's link.exe. You don't need the /ENTRY flag with 
optlink. It will do the right thing based on the /SUBSYSTEM flag.


https://docs.microsoft.com/en-us/cpp/build/reference/entry-entry-point-symbol?view=vs-2019
https://docs.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=vs-2019


Re: DConf 2017 Videos

2020-04-24 Thread Mike Parker via Digitalmars-d-learn

On Saturday, 25 April 2020 at 04:11:02 UTC, Ali Çehreli wrote:
On 4/24/20 2:11 PM, Steven Schveighoffer wrote:> On 4/24/20 
4:24 PM, matheus wrote:


> whomever controlled the sociomantic youtube account took down
> all the videos.

I think it's unintentional because the same thing happened to 
my Weka account: After I stopped working there, the company 
naturally deleted my account and the videos that were 
associated with that account disappeared from YouTube after a 
grace period. I think it was one month at that time but nobody 
was aware until it was too late.





Well, this wasn't one person's account. It was the company 
account. I've since learned that, as part of Dunhumby's process 
of killing off the Sociomantic brand, someone in their marketing 
department took it down without realizing that we were relying on 
it. To their credit, they have since tried to recover the 
account, but apparently by then it was too late.


Re: DConf 2017 Videos

2020-04-24 Thread Mike Parker via Digitalmars-d-learn

On Friday, 24 April 2020 at 21:25:11 UTC, matheus wrote:
On Friday, 24 April 2020 at 21:11:48 UTC, Steven Schveighoffer 
wrote:
... and whomever controlled the sociomantic youtube account 
took down all the videos...


First of all thanks for replying and... Ouch! After that I hope 
D Foundation learned the lesson and keep the videos themselves 
instead of relying in third party next time.


2017 was the last time the Foundation did not obtain copies of 
the videos. The YouTube channel started in 2018 and from that 
time and on into the future the Foundation has hosted and will 
host all of the DConf videos. And we'll soon have our own copies 
of all of the 2015 videos in case the UVU channel goes away some 
day.




I think it's time to have a Wayback Machine version for videos.



A few of the 2013/14 videos are in the Internet Archive. They 
have to be uploaded manually. Someone created a D account for it 
and uploaded them there at some point. When I created the 
Foundation's channel, I downloaded those and ripped the rest of 
the 2013/14 videos from various YouTube accounts, then uploaded 
them to our channel.  So we have everything now except the 
2016/17 copies.


  1   2   3   4   5   6   7   8   9   10   >