Re: Vulkan

[rumbu via Digitalmars-d]

On Saturday, 17 February 2018 at 05:52:38 UTC, Jonathan M Davis 
wrote:


Well, in D-speak, C header definitions rewritten as D so that D 
can call the C functions are exactly what bindings are, whereas 
if bindings are wrapped in D code to make them more D-like, 
those are called wrappers. I don't know that there's a specific 
term for a case where marshalling is involved.




Dynamic binding?

Re: how to get typeid of extern(C++) classes?

[Stefan Koch via Digitalmars-d]

On Friday, 16 February 2018 at 00:42:02 UTC, Timothee Cour wrote:
is there a way to get typeid of extern(C++) classes (eg for 
ones in

dmd/astbase.d but not limited to that) ?
C++ exposes it via typeid so in theory all the info is there ;
I would need it at least for debugging (eg if RTTI is not 
enabled for

all compilers or in release mode that's fine so long there's a
documented way to get it for debugging)

[...]


look at the asttypename.d in the dmd source.
it can give you a sting which represnts the ast-type-name.

[Issue 17772] Wrong C++ mangled names for templated functions

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17772

--- Comment #1 from Walter Bright  ---
Partial fix: https://github.com/dlang/dmd/pull/7906

--

Re: Release D 2.078.2

[Eugene Wissner via Digitalmars-d-announce]

On Friday, 16 February 2018 at 11:25:42 UTC, Martin Nowak wrote:

On 02/10/2018 09:17 AM, Thomas Mader wrote:
https://github.com/dlang/dub/releases/latest doesn't point to 
1.7.2.


Out of curiosity, do you have a strong use-case to 
install/update dub separately of the compiler?


I'm shipping dub (as a part of d-tools package) separately from 
the compiler for Slackware Linux. This way it can be built with 
the compiler of choice: dmd, gdc or ldc. It doesn't always make 
sense to ship dub with every compiler since you can use 
--compiler option. And the compiler dub is built with, is the 
default compiler to build dub projects.

Re: Vulkan

[Jonathan M Davis via Digitalmars-d]

On Saturday, February 17, 2018 13:52:06 Danni Coy via Digitalmars-d wrote:
> On Wed, Feb 14, 2018 at 2:26 PM, rikki cattermole via Digitalmars-d <
>
> digitalmars-d@puremagic.com> wrote:
> > On 13/02/2018 10:54 PM, Danni Coy wrote:
> >> On Wed, Feb 14, 2018 at 8:20 AM, Ivan Trombley via Digitalmars-d <
> >>
> >> digitalmars-d@puremagic.com > 
wrote:
> >> I wanted to do some experimentation with Vulkan using D. None of
> >> the
> >> projects that I found (derelict-vulkan, d-vulkan and erupted) work.
> >>
> >> Are there D bindings to Vulkan that actually work?
> >>
> >> strictly speaking you don't need a binding, you can access C code
> >> directly as long as you write compatible header definitions for the
> >> parts
> >> of vulkan you are actually using in your code.
> >
> > Which is then called a binding ;)
>
> The programmers I work with like to differentiate between situations where
> you can call code directly and when you have to do stuff like marshalling
> to get code in one language to talk to code in another language so I tend
> not to think of writing header definitions as making bindings.

Well, in D-speak, C header definitions rewritten as D so that D can call the
C functions are exactly what bindings are, whereas if bindings are wrapped
in D code to make them more D-like, those are called wrappers. I don't know
that there's a specific term for a case where marshalling is involved.

- Jonathan M Davis

Re: Disk space used and free size of a Network share folder in Windows

[Vino via Digitalmars-d-learn]

On Thursday, 15 February 2018 at 20:43:32 UTC, Johan Engelen 
wrote:

On Wednesday, 14 February 2018 at 12:22:09 UTC, Vino wrote:

Hi All,

 Request your help on how to get the disk space used and free 
size of a Network share folder in Windows, tried with getSize 
but it return 0;


See: 
https://github.com/ldc-developers/ldc/blob/f5b05878de6df2ea4a77c37128ad2eae0266b690/driver/cache_pruning.d#L47-L71


and https://issues.dlang.org/show_bug.cgi?id=16487

cheers,
  Johan


Hi All,

  Thank you very much, was able to successfully use the windows 
function.


From,
Vino.B

Re: how to get typeid of extern(C++) classes?

[Jonathan M Davis via Digitalmars-d]

On Saturday, February 17, 2018 00:23:01 Meta via Digitalmars-d wrote:
> On Friday, 16 February 2018 at 00:42:02 UTC, Timothee Cour wrote:
> > C++ exposes it via typeid so in theory all the info is there ;
>
> It's been awhile since I've written any C++ code, but as I
> remember it, this type of type info is not available unless you
> enable it with a (C++) compiler switch.

I think that all that's required is #including . Certainly, I've
never used a compiler switch to get at it, but I have no clue what
 really does to make things work beyond making certain symbols
available. So, I don't know how easy it is to make it work from D code.

- Jonathan M Davis

Re: Tuple DIP

[Timon Gehr via Digitalmars-d]

On 16.02.2018 20:51, Martin Nowak wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/12/2018 11:44 PM, Timon Gehr wrote:

As promised [1], I have started setting up a DIP to improve tuple
ergonomics in D:

https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md


Pardon me if things have been said already, can't really read through
all the thread.

- - Regarding underscore as placeholder.

https://issues.dlang.org/show_bug.cgi?id=13522



Thanks! I'll add a link to the enhancement to the DIP.


- - Regarding the "limitation"

Maybe you want some auto-packing feature there? Doesn't seem too bad,
we could come up with sth. when this turns out to become a common
nuisance.
Have you considered to lower (1, 2, 3)[0 .. 2] to tuple(tuple(1, 2,
3)[0 .. 2]) or using a non-std.typecons tuple where slicing does not
expand?
...


I think this is technically a good idea, but there are drawbacks: (i) 
the language does not support this for user-defined types, ideally we 
avoid adding more built-in magic, and (ii) having two different types 
will be confusing to newcomers. ("Which of the two seemingly equivalent 
Tuple constructs should I use?")



- - closed tuples?

The reference to std.typecons.tuple implies contiguous struct memory
layout (closed tuples).
This is a bit subtle for unpacking assignments which lower to

AliasSeq!(x, y) = tuple(y, x)[];

so on the left-hand side of an assignment, the syntax refers to a
non-contiguous (open) tuple.
...


I don't think this is the best way to think about it. Syntactically, the 
left-hand side contains two non-contiguous variables x and y and uses 
their values to form a contiguous tuple, but as it is the left-hand side 
of an assignment, the operation is actually performed in the opposite 
direction. This is a bit as if D supported assignments of the form:


int a;
a + 1 = 3;
assert(a == 2); // computed using the inverse: a = 3 - 1

Of course, this is independent of the actual implementation strategy chosen.


Declarations like

auto (a, b) = (1, 2);

also seem to declare an open tuple (non-contiguous memory).
...


Yes, the idea is that this would declare multiple independent variables.


I assume that unpacking function arguments behaves similarly, i.e. on
ABI level, each argument is passed separately.
...


I think the ABI should be unaffected in this case (it is just syntax 
sugar for unpacking the tuple argument immediately at the start of the 
called function, i.e. it is a callee-site construct that happens to 
sometimes make the signature prettier for the caller also). I will 
clarify this point.




Overall looks really good. I think that would make for a great
addition to the language.
...


Thanks! I'll make sure to incorporate your points when I'll finally get 
around to updating the DIP based on the forum feedback.

Re: Tuple DIP

[Timon Gehr via Digitalmars-d]

On 16.02.2018 21:01, Martin Nowak wrote:

On 01/14/2018 12:21 AM, Timon Gehr wrote:

what would be the equivalent of this ?
` writeln(tuple!("x", "y", "z")(2, 3, 4).y); `


It would continue to work the same way.

I did consider adding a proposal for built-in named tuple syntax:

writeln((x: 2, y: 3, z: 4).y);

(int a, double b) t = (a: 1, b: 2.0);
int x = t.a;
double y = t.b;


Tuples are anonymous bundles, when you want a product type with field
names use a struct.



I agree, but Phobos does not.

Re: Tuple DIP

[Timon Gehr via Digitalmars-d]

On 16.02.2018 21:16, Jonathan M Davis wrote:

On Friday, February 16, 2018 21:01:02 Martin Nowak via Digitalmars-d wrote:

On 01/14/2018 12:21 AM, Timon Gehr wrote:

what would be the equivalent of this ?
` writeln(tuple!("x", "y", "z")(2, 3, 4).y); `


It would continue to work the same way.

I did consider adding a proposal for built-in named tuple syntax:

writeln((x: 2, y: 3, z: 4).y);

(int a, double b) t = (a: 1, b: 2.0);
int x = t.a;
double y = t.b;


Tuples are anonymous bundles, when you want a product type with field
names use a struct.


That's not necessarily unreasonable, but std.typecons.Tuple is frequently
used as a convenient way to return a group of values, and the trend has been
towards using named values, because those are easier to deal with as return
values, because they're somewhat self-documenting at that point, and they're
less error-prone. So, if we're talking about adding more complete tuples to
the language, if they don't have support for names, you then have the
problem of whether it's better to use the built-in tuples or something like
std.typecons.Tuple with named values, and there's a pretty strong argument
at that point that it's better to use the named tuples and lose whatever
benefits the built-in tuples might provide, because the named tuples result
in more maintainable code.

- Jonathan M Davis



This is not really problematic. Note that the /only/ improvement in the 
DIP that does not apply to library tuples is the tuple construction syntax.

Re: Tuple DIP

[Timon Gehr via Digitalmars-d]

On 16.02.2018 21:48, H. S. Teoh wrote:

On Fri, Feb 16, 2018 at 01:16:13PM -0700, Jonathan M Davis via Digitalmars-d 
wrote:

On Friday, February 16, 2018 21:01:02 Martin Nowak via Digitalmars-d wrote:

On 01/14/2018 12:21 AM, Timon Gehr wrote:

what would be the equivalent of this ?
` writeln(tuple!("x", "y", "z")(2, 3, 4).y); `


It would continue to work the same way.

I did consider adding a proposal for built-in named tuple syntax:

writeln((x: 2, y: 3, z: 4).y);

(int a, double b) t = (a: 1, b: 2.0);
int x = t.a;
double y = t.b;


Tuples are anonymous bundles, when you want a product type with
field names use a struct.


That's not necessarily unreasonable, but std.typecons.Tuple is frequently
used as a convenient way to return a group of values, and the trend has been
towards using named values, because those are easier to deal with as return
values, because they're somewhat self-documenting at that point, and they're
less error-prone. So, if we're talking about adding more complete tuples to
the language, if they don't have support for names, you then have the
problem of whether it's better to use the built-in tuples or something like
std.typecons.Tuple with named values, and there's a pretty strong argument
at that point that it's better to use the named tuples and lose whatever
benefits the built-in tuples might provide, because the named tuples result
in more maintainable code.

[...]

Tuples with named fields are essentially anonymous structs.  If we had
those, 60% of what this DIP addresses would already have been solved.
Cf.:

https://forum.dlang.org/post/kfbnuc$1cro$1...@digitalmars.com


T



You got that number a bit too high.
The DIP is mostly about tuple unpacking.

Appending to ddoc macros

[Jonathan M Davis via Digitalmars-d-learn]

Does anyone know if there's a way to append to a ddoc macro instead of
replacing it?

For instance, dlang.org has the EXTRA_HEADERS macro for adding extra stuff
to the header of a web page, and it uses that with several pages defining
EXTRA_HEADERS to add headers to that specific page. I have something similar
for my own project, but I need to be able to add EXTRA_HEADERS more than
once, and redefining EXTRA_HEADERS makes it so that only one of the values
of EXTRA_HEADERS takes effect. Ideally, I would have a way to add additional
values to EXTRA_HEADERS without replacing the original values, just like
when you do something like

PATH=~/bin/:$PATH

when setting your path, but I don't know of any way to do that in ddoc. Does
anyone know of such a way? Or does a feature need to be added to ddoc to
make such a thing possible?

At the moment, the best solution I have is to just define a second macro
for the second value I need to add to EXTRA_HEADERS so that I have
EXTRA_HEADERS and EXTRA_HEADERS2, but that doesn't scale very well.

- Jonathan M Davis

Re: Vulkan

[Danni Coy via Digitalmars-d]

On Wed, Feb 14, 2018 at 2:26 PM, rikki cattermole via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On 13/02/2018 10:54 PM, Danni Coy wrote:
>
>>
>> On Wed, Feb 14, 2018 at 8:20 AM, Ivan Trombley via Digitalmars-d <
>> digitalmars-d@puremagic.com > wrote:
>>
>> I wanted to do some experimentation with Vulkan using D. None of the
>> projects that I found (derelict-vulkan, d-vulkan and erupted) work.
>>
>> Are there D bindings to Vulkan that actually work?
>>
>>
>> strictly speaking you don't need a binding, you can access C code
>> directly as long as you write compatible header definitions for the parts
>> of vulkan you are actually using in your code.
>>
>
> Which is then called a binding ;)
>

The programmers I work with like to differentiate between situations where
you can call code directly and when you have to do stuff like marshalling
to get code in one language to talk to code in another language so I tend
not to think of writing header definitions as making bindings.

Re: New abstraction: Layout

[rikki cattermole via Digitalmars-d]

On 17/02/2018 12:04 AM, Andrei Alexandrescu wrote:
I've been long bothered that the builtin .tupleof and our own 
abstractions Fields and RepresentationTypeTuple in std.traits - all omit 
the essential information of field offsets. That makes types that use 
align() to have the same .tupleof, Fields, and RepresentationTypeTuple 
even though they shouldn't.


The right answer is Layout a tuple of (offset, type) pairs describing 
entirely the memory layout of a type. We need such for memory 
allocation, garbage collection, serialization, and more.


The implementation turned out to be quite compact - 81 lines including a 
compile-time mergesort. Destroy!


https://github.com/dlang/phobos/pull/6192


Andrei


Could use the name for the field as well. At the minimum useful for 
debugging purposes.

Re: Vulkan

[Rubn via Digitalmars-d]

On Friday, 16 February 2018 at 22:58:30 UTC, Ivan Trombley wrote:
On Wednesday, 14 February 2018 at 02:40:18 UTC, Mike Parker 
wrote:
What [does] it mean to say they don't work? Have you reported 
any issues? I don't see any in the DerelictVulkan repo. If 
something's broken, please report it so it can  be fixed.


Derelict-vulkan is Windows only ATM.


The only difference is the one specific function for creating the 
surface. You are better off using something like SDL2 for 
creating the window anyways, which takes care of the only OS 
specific code of vulkan.


None of the types also have default value set to the proper value.

https://github.com/Zoadian/DerelictVulkan/blob/master/source/derelict/vulkan/types.d#L1102

It's not that difficult to add though, the name of the struct 
name is pretty much the type enum name but with all caps and 
underscores. A simple regex replace and formatting easily adds 
most of them.

Re: Dub, Cargo, Go, Gradle, Maven

[Dmitry Olshansky via Digitalmars-d]

On Friday, 16 February 2018 at 22:48:55 UTC, H. S. Teoh wrote:
On Fri, Feb 16, 2018 at 07:31:37PM +, Dmitry Olshansky via 
Digitalmars-d wrote:

On Friday, 16 February 2018 at 18:16:12 UTC, H. S. Teoh wrote:

[...]
> If a dependent node requires network access, it forces 
> network access every time the DAG is updated.  This is slow, 
> and also unreliable: the shape of the DAG could, in theory, 
> change arbitrarily at any time outside the control of the 
> user.


Oh, come on. Immutable artifacts make this matter trivial - 
the first step is resolution, where you figure out what things 
you already have by looking at metadata only, followed by 
download the world (or part you do not have).  Since specific 
versions never change, nothing to worry about. Java folks had 
this for ages with Maven and its ilk.


This assumes that the upstream server (1) consistently serves 
the same data for the same version -- which in principle will 
be the case, but unforeseen problems could break this 
assumption;


Trivially enforced on public hubs such maven central.

 (2) stores all versions forever, which is unlikely

to be always true.



Is in fact true. After all github stores the whole git repo why 
would storing all distinct versions be too much.



In any case, dependence on network access for every invocation 
of a build is unacceptable to me.


Well, it is not in the scheme outlined. Only the clean build is.


[...]
Also most if not all build systems will inevitably integrate 
all of

the below in some way:
- compiler (internal as library or external as a build server)
- source code dependency resolution
- package dependency resolution
- package download or build
- execution of arbitrary tasks in form of plugins or external 
tools


Me personally in love with plugins and general purpose 
language available to define tasks. Scala’s SBT may have many 
faults but plugins and extensibility make it awesome.


Personally, I find that the most useful build systems are those 
that make no assumptions about how your products are built.


No thanks, I’d prefer convention then unique snowflake build 
scripts if there us a choice. Sometimes you have to do go beyound 
ghe basics but not too often.


SCons is a good example of this: for example, currently I have 
a website completely built from ground-up by SCons, which 
includes tasks like generating datasets, 3D models, using a PHP 
filter to generate HTML, running a raytracer to generate 
images, post-processing generated images, creating a dataset 
from revision history and rendering graphs, running LaTeX to 
generate PDF documentation, etc., and installing the products 
of all of the foregoing into a staging directory that then gets 
rsync'd to the remote


All of that can be done by any of modern tools with full language 
+ DSL at your disposal, eg Gradle or SBT. In a sense SCons is the 
same but without resolving packages.



Basically none of these steps involve the traditional 
invocation of a compiler or built-in source code dependency 
resolution. SCons has a very nice API for defining my own 
dependency resolver for custom data formats that can leverage 
all of the built-in scanning / depending resolving algorithms 
that come with SCons.


I would not even consider any build system incapable of this 
level of customization.



T

Re: Vulkan

[Zoadian via Digitalmars-d]

On Friday, 16 February 2018 at 22:58:30 UTC, Ivan Trombley wrote:
On Wednesday, 14 February 2018 at 02:40:18 UTC, Mike Parker 
wrote:
What [does] it mean to say they don't work? Have you reported 
any issues? I don't see any in the DerelictVulkan repo. If 
something's broken, please report it so it can  be fixed.


Derelict-vulkan is Windows only ATM.


Actually someone added posix support. Just forgot to flag a new 
release. (I did not test posix support myself yet).

If there are other issues please file them on GitHub.

Re: how to get typeid of extern(C++) classes?

[Meta via Digitalmars-d]

On Friday, 16 February 2018 at 00:42:02 UTC, Timothee Cour wrote:

C++ exposes it via typeid so in theory all the info is there ;


It's been awhile since I've written any C++ code, but as I 
remember it, this type of type info is not available unless you 
enable it with a (C++) compiler switch.

New abstraction: Layout

[Andrei Alexandrescu via Digitalmars-d]

I've been long bothered that the builtin .tupleof and our own 
abstractions Fields and RepresentationTypeTuple in std.traits - all omit 
the essential information of field offsets. That makes types that use 
align() to have the same .tupleof, Fields, and RepresentationTypeTuple 
even though they shouldn't.


The right answer is Layout a tuple of (offset, type) pairs describing 
entirely the memory layout of a type. We need such for memory 
allocation, garbage collection, serialization, and more.


The implementation turned out to be quite compact - 81 lines including a 
compile-time mergesort. Destroy!


https://github.com/dlang/phobos/pull/6192


Andrei

Re: Knowing the approach to solve a D challenge

[Jesse Phillips via Digitalmars-d]

On Friday, 16 February 2018 at 09:44:27 UTC, aberba wrote:
D has tone of features and library solutions. When you 
encounter a problem, how do you approach solving it in code?


1. Do you first write it in idiomatic D style or a more general 
approach before porting to idiomatic D?


Like always, it depends. Do I attribute up all my functions with 
const/@safe/nothrow... (is that even idiomatic) no. Do I build a 
range to process some data... sometimes. Do I utilize 
std.algorithm/std.range functions to process my data... when 
available.


Even my C# code tends to be more idiomatic D than others.

2. Do you find yourself mostly rolling out your own 
implementation first before using a library function?


I don't know. If a rolled my own I probably don't know of the 
library function/function combination that does the same thing.



3. Do the use of generics come out of first try or a rewrite?


Usually not. If I don't have another use-case I probably don't 
know what needs

to be generic.

4. What rough percentage of phobos knowledge is required for 
reasonable good problem solving efficiency?


I would guess average. The reason I say this because unlike 
popular languages search doesn't always provide a good example 
for every question so you kind of need to already know what 
you're looking for. It doesn't help that sometimes the answer is 
a combination of this (.reduce!max that isn't found in std.math)

Re: Vulkan

[Ivan Trombley via Digitalmars-d]

On Wednesday, 14 February 2018 at 00:22:25 UTC, flamencofantasy 
wrote:

Maybe these work, not sure;

https://github.com/Rikarin/VulkanizeD


Thanks, I'll check this out.

Re: Dub, Cargo, Go, Gradle, Maven

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 16, 2018 at 07:31:37PM +, Dmitry Olshansky via Digitalmars-d 
wrote:
> On Friday, 16 February 2018 at 18:16:12 UTC, H. S. Teoh wrote:
[...]
> > If a dependent node requires network access, it forces network
> > access every time the DAG is updated.  This is slow, and also
> > unreliable: the shape of the DAG could, in theory, change
> > arbitrarily at any time outside the control of the user.
> 
> Oh, come on. Immutable artifacts make this matter trivial - the first
> step is resolution, where you figure out what things you already have
> by looking at metadata only, followed by download the world (or part
> you do not have).  Since specific versions never change, nothing to
> worry about. Java folks had this for ages with Maven and its ilk.

This assumes that the upstream server (1) consistently serves the same
data for the same version -- which in principle will be the case, but
unforeseen problems could break this assumption; (2) stores all versions
forever, which is unlikely to be always true.

In any case, dependence on network access for every invocation of a
build is unacceptable to me.


[...]
> Also most if not all build systems will inevitably integrate all of
> the below in some way:
> - compiler (internal as library or external as a build server)
> - source code dependency resolution
> - package dependency resolution
> - package download or build
> - execution of arbitrary tasks in form of plugins or external tools
> 
> Me personally in love with plugins and general purpose language
> available to define tasks. Scala’s SBT may have many faults but
> plugins and extensibility make it awesome.

Personally, I find that the most useful build systems are those that
make no assumptions about how your products are built.  SCons is a good
example of this: for example, currently I have a website completely
built from ground-up by SCons, which includes tasks like generating
datasets, 3D models, using a PHP filter to generate HTML, running a
raytracer to generate images, post-processing generated images, creating
a dataset from revision history and rendering graphs, running LaTeX to
generate PDF documentation, etc., and installing the products of all of
the foregoing into a staging directory that then gets rsync'd to the
remote webserver.  Basically none of these steps involve the traditional
invocation of a compiler or built-in source code dependency resolution.
SCons has a very nice API for defining my own dependency resolver for
custom data formats that can leverage all of the built-in scanning /
depending resolving algorithms that come with SCons.

I would not even consider any build system incapable of this level of
customization.


T

-- 
Life begins when you can spend your spare time programming instead of watching 
television. -- Cal Keegan

Re: Vulkan

[Ivan Trombley via Digitalmars-d]

On Wednesday, 14 February 2018 at 02:40:18 UTC, Mike Parker wrote:
What [does] it mean to say they don't work? Have you reported 
any issues? I don't see any in the DerelictVulkan repo. If 
something's broken, please report it so it can  be fixed.


Derelict-vulkan is Windows only ATM.

Re: std.zip size limit of 2 GB?

[Steven Schveighoffer via Digitalmars-d-learn]

On 2/16/18 5:39 PM, Ali Çehreli wrote:

On 02/15/2018 01:57 PM, Steven Schveighoffer wrote:

 > Really, i should be size_t in all places

size_t or ulong? size_t would constrain 32-bit systems unless they can't 
handle files over 2G.


The code I linked to writes to an array. So it's constrained to size_t.

I think the zlib library itself doesn't support very well anything more 
than 4GB files.


-Steve

Re: std.zip size limit of 2 GB?

[Ali Çehreli via Digitalmars-d-learn]

On 02/15/2018 01:57 PM, Steven Schveighoffer wrote:

> Really, i should be size_t in all places

size_t or ulong? size_t would constrain 32-bit systems unless they can't 
handle files over 2G.


Ali

LDC 1.8.0-beta1

[kinke via Digitalmars-d-announce]

Hi everyone,

on behalf of the LDC team, I'm glad to announce the first beta 
for LDC 1.8. The highlights of this version in a nutshell:


* Based on D 2.078.3.
* New switch `-link-defaultlib-shared` to link against shared 
druntime/Phobos.

* Plugins support, compatible with existing Clang plugins.
* Support for LLVM IR-based PGO as alternative to existing 
(AST-based) PGO.

* Basic support for LLVM XRay instrumentation.

Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.8.0-beta1


Thanks to all contributors!

Re: how to get typeid of extern(C++) classes?

[Steven Schveighoffer via Digitalmars-d]

On 2/15/18 7:42 PM, Timothee Cour wrote:

is there a way to get typeid of extern(C++) classes (eg for ones in
dmd/astbase.d but not limited to that) ?
C++ exposes it via typeid so in theory all the info is there ;
I would need it at least for debugging (eg if RTTI is not enabled for
all compilers or in release mode that's fine so long there's a
documented way to get it for debugging)

a lot of extern(C++) classes in dmd use hacks like enum values to get
their type but it's unreliable and doesn't work for all AST classes.

at least having a way to expose typeid(instance).name() would be a start

also, that could be used to fix the bug I posted here:
https://forum.dlang.org/post/mailman.3138.1517949584.9493.digitalmar...@puremagic.com
cast overly permissive with extern(C++ ) classes; ( ie that `cast(A)
b` doesn't care that b is of dynamic type A)



typeid always returns a D TypeInfo object, which is a D-specific animal.

I don't think we can do this for C++ classes.

For D classes in particular, the typeid is a runtime type, gleaned from 
the embedded vtable. For structs, it is a compile-time defined 
reference. Neither of these things would exist for C++ classes.


-Steve

[Issue 18449] dmd allows to compile `extern(C++) class` even though it should be extern(C++) struct; should give error

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18449

Timothee Cour  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--

[Issue 18449] dmd allows to compile `extern(C++) class` even though it should be extern(C++) struct; should give error

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18449

--- Comment #2 from Timothee Cour  ---
reopening and changed title to:

dmd allows to compile `extern(C++) class` even though it should be extern(C++)
struct; should give error

is that fixable or fundamentally hard to detect when key method is defined ?

--

[Issue 18449] dmd allows to compile `extern(C++) class` even though it should be extern(C++) struct; should give error

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18449

Timothee Cour  changed:

   What|Removed |Added

Summary|extern(C++) class layout|dmd allows to compile
   |does not work   |`extern(C++) class` even
   ||though it should be
   ||extern(C++) struct; should
   ||give error

--

Re: Congrats to D / Vibe-D -- techempower Round 15

[Daniel Kozak via Digitalmars-d]

Hard to say, but I believe one of reasons is VibeManualMemoryManagement,
another one would be same fixes in vibe-core and eventcore

[Issue 18449] extern(C++) class layout does not work

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18449

Timothee Cour  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||timothee.co...@gmail.com
 Resolution|--- |INVALID

--- Comment #1 from Timothee Cour  ---
my bad: forgot to add `virtual ~A();`, closing

--

Re: Tuple DIP

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 16, 2018 at 01:16:13PM -0700, Jonathan M Davis via Digitalmars-d 
wrote:
> On Friday, February 16, 2018 21:01:02 Martin Nowak via Digitalmars-d wrote:
> > On 01/14/2018 12:21 AM, Timon Gehr wrote:
> > >> what would be the equivalent of this ?
> > >> ` writeln(tuple!("x", "y", "z")(2, 3, 4).y); `
> > >
> > > It would continue to work the same way.
> > >
> > > I did consider adding a proposal for built-in named tuple syntax:
> > >
> > > writeln((x: 2, y: 3, z: 4).y);
> > >
> > > (int a, double b) t = (a: 1, b: 2.0);
> > > int x = t.a;
> > > double y = t.b;
> >
> > Tuples are anonymous bundles, when you want a product type with
> > field names use a struct.
> 
> That's not necessarily unreasonable, but std.typecons.Tuple is frequently
> used as a convenient way to return a group of values, and the trend has been
> towards using named values, because those are easier to deal with as return
> values, because they're somewhat self-documenting at that point, and they're
> less error-prone. So, if we're talking about adding more complete tuples to
> the language, if they don't have support for names, you then have the
> problem of whether it's better to use the built-in tuples or something like
> std.typecons.Tuple with named values, and there's a pretty strong argument
> at that point that it's better to use the named tuples and lose whatever
> benefits the built-in tuples might provide, because the named tuples result
> in more maintainable code.
[...]

Tuples with named fields are essentially anonymous structs.  If we had
those, 60% of what this DIP addresses would already have been solved.
Cf.:

https://forum.dlang.org/post/kfbnuc$1cro$1...@digitalmars.com


T

-- 
Ignorance is bliss... until you suffer the consequences!

Re: Dub, Cargo, Go, Gradle, Maven

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 16 February 2018 at 19:40:07 UTC, H. S. Teoh wrote:
On Fri, Feb 16, 2018 at 07:40:01PM +, Ola Fosheim Grøstad 
via Digitalmars-d wrote:

On Friday, 16 February 2018 at 18:16:12 UTC, H. S. Teoh wrote:
> The O(N) vs. O(n) issue is actually very important once you

I understand what you are trying to say, but this usage of 
notation is
very confusing. O(n) is exactly the same as O(N) if N relates 
to n by

a given percentage.


N = size of DAG
n = size of changeset

It's not a fixed percentage.


Well, for this comparison to make sense asymptotically you have 
to consider how n grows when N grows towards infinity. Basically 
without relating n to N we don't get any information from O(n) vs 
O(N).


If you cannot bound n in terms of N (lower/upper) then O(n) is 
most likely either O(1)  or O(N) in relation to N... (e.g. there 
is a constant upper limit to how many files you modify manually, 
or you rebuild roughly everything)


Now, if you said that at most O(log N) files are changed, then 
you could have an argument in terms of big-oh.

Re: how to get typeid of extern(C++) classes?

[timotheecour via Digitalmars-d]

On Friday, 16 February 2018 at 00:42:02 UTC, Timothee Cour wrote:
is there a way to get typeid of extern(C++) classes (eg for 
ones in

dmd/astbase.d but not limited to that) ?


as a workaround, could the compiler insert (eg, depending on a 
version(insert_typeid)) a virtual method in each extern(C++) 
class eg:

`const(char)* __typeid()` ?

Re: Tuple DIP

[Jonathan M Davis via Digitalmars-d]

On Friday, February 16, 2018 21:01:02 Martin Nowak via Digitalmars-d wrote:
> On 01/14/2018 12:21 AM, Timon Gehr wrote:
> >> what would be the equivalent of this ?
> >> ` writeln(tuple!("x", "y", "z")(2, 3, 4).y); `
> >
> > It would continue to work the same way.
> >
> > I did consider adding a proposal for built-in named tuple syntax:
> >
> > writeln((x: 2, y: 3, z: 4).y);
> >
> > (int a, double b) t = (a: 1, b: 2.0);
> > int x = t.a;
> > double y = t.b;
>
> Tuples are anonymous bundles, when you want a product type with field
> names use a struct.

That's not necessarily unreasonable, but std.typecons.Tuple is frequently
used as a convenient way to return a group of values, and the trend has been
towards using named values, because those are easier to deal with as return
values, because they're somewhat self-documenting at that point, and they're
less error-prone. So, if we're talking about adding more complete tuples to
the language, if they don't have support for names, you then have the
problem of whether it's better to use the built-in tuples or something like
std.typecons.Tuple with named values, and there's a pretty strong argument
at that point that it's better to use the named tuples and lose whatever
benefits the built-in tuples might provide, because the named tuples result
in more maintainable code.

- Jonathan M Davis

[Issue 18434] BigInt gcd asserts when one argument is zero.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18434

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/fb66d07b769111664d648b5d4eb0a96d8c3e3101
Fix issue 18434: gcd(BigInt(0), BigInt(1)) fails

The special cases of `gcd(0,a)` and `gcd(a,0)` are not handled correctly
when `BigInt`s are involved.

https://github.com/dlang/phobos/commit/ffc96fd90dceb753b5066ca09524caa5fb1f3ffa
Merge pull request #6170 from quickfur/issue18434

Fix issue 18434: gcd(BigInt(0), BigInt(1)) fails
merged-on-behalf-of: Jack Stouffer 

--

[Issue 18434] BigInt gcd asserts when one argument is zero.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18434

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: Tuple DIP

[Martin Nowak via Digitalmars-d]

On 01/14/2018 12:21 AM, Timon Gehr wrote:
>> what would be the equivalent of this ?
>> ` writeln(tuple!("x", "y", "z")(2, 3, 4).y); `
> 
> It would continue to work the same way.
> 
> I did consider adding a proposal for built-in named tuple syntax:
> 
> writeln((x: 2, y: 3, z: 4).y);
> 
> (int a, double b) t = (a: 1, b: 2.0);
> int x = t.a;
> double y = t.b;

Tuples are anonymous bundles, when you want a product type with field
names use a struct.

Re: Tuple DIP

[Martin Nowak via Digitalmars-d]

On 01/14/2018 07:41 PM, Timothee Cour wrote:
> Should definitely be mentioned in the DIP to open that up for discussion;
> it breaks assumptions like sizeof(Tuple)=sum_i : tuple (sizeof(Ti));

That doesn't hold for all cases anyhow, as it seems were talking about
closed tuples that are contiguous in memory and follow struct layout and
alignment rules.

Re: Tuple DIP

[Martin Nowak via Digitalmars-d]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/12/2018 11:44 PM, Timon Gehr wrote:
> As promised [1], I have started setting up a DIP to improve tuple 
> ergonomics in D:
> 
> https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md

Pardon me if things have been said already, can't really read through
all the thread.

- - Regarding underscore as placeholder.

https://issues.dlang.org/show_bug.cgi?id=13522

- - Regarding the "limitation"

Maybe you want some auto-packing feature there? Doesn't seem too bad,
we could come up with sth. when this turns out to become a common
nuisance.
Have you considered to lower (1, 2, 3)[0 .. 2] to tuple(tuple(1, 2,
3)[0 .. 2]) or using a non-std.typecons tuple where slicing does not
expand?

- - closed tuples?

The reference to std.typecons.tuple implies contiguous struct memory
layout (closed tuples).
This is a bit subtle for unpacking assignments which lower to

AliasSeq!(x, y) = tuple(y, x)[];

so on the left-hand side of an assignment, the syntax refers to a
non-contiguous (open) tuple.

Declarations like

auto (a, b) = (1, 2);

also seem to declare an open tuple (non-contiguous memory).

I assume that unpacking function arguments behaves similarly, i.e. on
ABI level, each argument is passed separately.


Overall looks really good. I think that would make for a great
addition to the language.

- -Martin
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlqHNkgACgkQsnOBFhK7
GTka+A/9HVHrawW5XyqzpGnT+qkyaG3a4dZdVvHbs9gJ0x7SHDyBgjKs576dW7g5
GEfGFjPkEZqKGvbtWgSicRV01qNmyGfVsgmWestK59niQAHLMUYx8PBsmeX/1CP9
MxLPMx9a0Z+h0D1z8sCLjHV5NcVZLziP3lnuUUvVXLUEv/gBZV52Eu++/iJmqKaj
K9Boyv2+IrTTkv426PNxCy1iblMVi7B2bP44HErwij9+si8Zby3O8ExAh97MOBdH
eoPT6TzmJxpExUfdiXcJ26HFxa4V8WhB/YaS50uYoUUYbaj0njtLwLyCkzUsjGzb
JV32ZI7ncfHmMHCaJ09SGHfvh2dHKHa/VHU5ar3ivnzAXBLjdoe7MNi3QGH+zi6M
U+RtY6WBkiVnYcLmanmMJKhyRsj3k3qT1I4zmVm6kbrs/oBqegtQcFoiQxm/DNMc
LKLlNTEWuWIFquA6rd5OJ7kxhdbv5dE9vAgDNYcPP8GOB78sbZMQKxBTcI0a1EQC
JYYvICiI9+CqjIeOU0F/LDv48JIk5BGSrh8m0cjwUtq4ivGEKo4V6Oc+1smsXmAo
+XpSyyQi/t8pj037w0zSS0KA88qL4Fc4fvuujNnr5a9AkiV7zrMb9oyM00+F7cgo
UApw3Lpr9g8GBKKu8HcbzGQMq86TYq/unSsD3ZFJEA3PCz8/5aY=
=VB2T
-END PGP SIGNATURE-

Re: std.zip size limit of 2 GB?

[Andre Pany via Digitalmars-d-learn]

On Thursday, 15 February 2018 at 21:57:23 UTC, Steven 
Schveighoffer wrote:
Really, i should be size_t in all places, I can't see why it 
should ever be int.


Please file an issue.

-Steve


Issue created: https://issues.dlang.org/show_bug.cgi?id=18452
Thanks for the analysis.

Kind regards
André

Re: Dub, Cargo, Go, Gradle, Maven

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 16, 2018 at 07:40:01PM +, Ola Fosheim Grøstad via Digitalmars-d 
wrote:
> On Friday, 16 February 2018 at 18:16:12 UTC, H. S. Teoh wrote:
> > The O(N) vs. O(n) issue is actually very important once you
> 
> I understand what you are trying to say, but this usage of notation is
> very confusing. O(n) is exactly the same as O(N) if N relates to n by
> a given percentage.

N = size of DAG
n = size of changeset

It's not a fixed percentage.


T

-- 
He who does not appreciate the beauty of language is not worthy to bemoan its 
flaws.

[Issue 18452] New: std.zip has size limit of 2 GB

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18452

  Issue ID: 18452
   Summary: std.zip has size limit of 2 GB
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: an...@s-e-a-p.de

I just noticed that std.zip will throw an exception if the source files exceeds
2 GB. It seems an issue with std.zip as zlib has a limit of 4 GB.

Windows 10 with x86_64 architecture.

core.exception.RangeError@std\zip.d(808): Range violation

0x7FF7C9B1705C in d_arrayboundsp
0x7FF7C9B301FF in @safe void std.zip.ZipArchive.putUshort(int, ushort)
0x7FF7C9B2E634 in void[] std.zip.ZipArchive.build()

void zipFolder(string archiveFilePath, string folderPath)
{
import std.zip, std.file;

ZipArchive zip = new ZipArchive();
string folderName = folderPath.baseName;

foreach(entry; dirEntries(folderPath, SpanMode.depth))
{
if (!entry.isFile)
continue;

ArchiveMember am = new ArchiveMember();
am.name = entry.name[folderPath.length + 1..$];
am.expandedData(cast(ubyte[]) read(entry.name));
zip.addMember(am);
}

void[] compressed_data = zip.build(); // zip.build() will throw
write(archiveFilePath, compressed_data);
}

Comment from Steven Schveighoffer:
...And you are right. I looked into it a bit, this has nothing to do
(superficially) with zlib, it has to do with std.zip:

https://github.com/dlang/phobos/blob/0107a6ee09072bda9e486a12caa148dc7af7bb08/std/zip.d#L806

Really, i should be size_t in all places, I can't see why it should ever be
int.
--

And Stefan Koch:
...It was partially changed in this PR:
https://github.com/dlang/phobos/pull/2914/files
The the put methods where left at int must have been an oversight.
--

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

--

Re: Dub, Cargo, Go, Gradle, Maven

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 16 February 2018 at 18:16:12 UTC, H. S. Teoh wrote:

The O(N) vs. O(n) issue is actually very important once you


I understand what you are trying to say, but this usage of 
notation is very confusing. O(n) is exactly the same as O(N) if N 
relates to n by a given percentage.

Re: Dub, Cargo, Go, Gradle, Maven

[Dmitry Olshansky via Digitalmars-d]

On Friday, 16 February 2018 at 18:16:12 UTC, H. S. Teoh wrote:
On Mon, Feb 12, 2018 at 10:35:06AM +, Russel Winder via 
Digitalmars-d wrote:
In all the discussion of Dub to date, it hasn't been pointed 
out that JVM building merged dependency management and build a 
long time ago. Historically:


  Make → Ant → Maven → Gradle

and Gradle can handle C++ as well as JVM language builds.

So the integration of package management and build as seen in 
Go, Cargo, and Dub is not a group of outliers. Could it be 
then that it is the right thing to do. After all package 
management is a dependency management activity and build is a 
dependency management activity, so why separate them, just 
have a single ADG to describe the whole thing.


I have no problem with using a single ADG/DAG to describe the 
whole thing.  However, a naïve implementation of this raises a 
few issues:


If a dependent node requires network access, it forces network 
access every time the DAG is updated.  This is slow, and also 
unreliable: the shape of the DAG could, in theory, change 
arbitrarily at any time outside the control of the user.


Oh, come on. Immutable artifacts make this matter trivial - the 
first step is resolution, where you figure out what things you 
already have by looking at metadata only, followed by download 
the world (or part you do not have). Since specific versions 
never change, nothing to worry about. Java folks had this for 
ages with Maven and its ilk.


Some targets like deploy may indeed not have a cheap “check if 
its done” step. They may not realy need one. (though rsync does 
wonders at minimizing the work)


Also most if not all build systems will inevitably integrate all 
of the below in some way:

- compiler (internal as library or external as a build server)
- source code dependency resolution
- package dependency resolution
- package download or build
- execution of arbitrary tasks in form of plugins or external 
tools


Me personally in love with plugins and general purpose language 
available to define tasks. Scala’s SBT may have many faults but 
plugins and extensibility make it awesome.

Re: Congrats to D / Vibe-D -- techempower Round 15

[Johan Engelen via Digitalmars-d]

On Thursday, 15 February 2018 at 19:04:53 UTC, Benny wrote:

https://www.techempower.com/benchmarks/#section=data-r15=ph=plaintext
https://www.techempower.com/benchmarks/#section=data-r14=ph=json

D is finally showing up in the upper and middle parts of the 
tests. In some tests Vibe-D ( with LDC ) is showing a 10 to 80 
times improvement compared to Round 14 ( where D was stuck at 
the bottom of the tests ).


Does anybody know what exactly has changed to explain this large 
performance difference?

[Issue 17420] std.format.formatObject doesn't work with @safe toString specialization

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17420

Jack Stouffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jack Stouffer  ---
This was fixed with https://github.com/dlang/phobos/pull/5991

--

[Issue 10828] datetime toString functions should accept sink

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10828

Jack Stouffer  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||j...@jackstouffer.com
 Resolution|FIXED   |---

--

Re: Dub, Cargo, Go, Gradle, Maven

[H. S. Teoh via Digitalmars-d]

On Mon, Feb 12, 2018 at 10:35:06AM +, Russel Winder via Digitalmars-d wrote:
> In all the discussion of Dub to date, it hasn't been pointed out that
> JVM building merged dependency management and build a long time ago.
> Historically:
> 
>   Make → Ant → Maven → Gradle
> 
> and Gradle can handle C++ as well as JVM language builds.
> 
> So the integration of package management and build as seen in Go,
> Cargo, and Dub is not a group of outliers. Could it be then that it is
> the right thing to do. After all package management is a dependency
> management activity and build is a dependency management activity, so
> why separate them, just have a single ADG to describe the whole thing.

I have no problem with using a single ADG/DAG to describe the whole
thing.  However, a naïve implementation of this raises a few issues:

If a dependent node requires network access, it forces network access
every time the DAG is updated.  This is slow, and also unreliable: the
shape of the DAG could, in theory, change arbitrarily at any time
outside the control of the user.  If I'm debugging a program, the very
last thing I want to happen is that the act of building the software
also pulls in new library versions that cause the location of the bug to
shift, thereby ruining any progress I may have made on narrowing down
its locus. It would be nice to locally cache such network-dependent
nodes so that they are only refreshed on demand.

Furthermore, a malicious external entity can introduce arbitrary changes
into the DAG, e.g., hijack an intermediate DNS server so that network
lookups get redirected to a malicious server which then adds
dependencies on malware to your DAG.  The next time you update: boom,
your software now contains a trojan horse. (Even better if you have
integrated package dependencies with builds all the way to deployment:
now all your customers have a copy of the trojan deployed on their
machines, too.)  To mitigate this, some kind of security model would be
required (e.g., verifiable server certificates, cryptographically signed
package payloads).  Which adds to the cost of refreshing network nodes,
and hence is another big reason why this should be done on-demand, NOT
automatically every time you ask for a new software build.

Also, if the machine I'm working on happens to be offline, it would
totally suck to be unable to build my project just because of that.
The whole point of having a DAG is reliable builds, and having the graph
depend on remote resources over an inherently unreliable network defeats
the purpose.  That is why caching is basically mandatory, as is control
over when the network is accessed.

And furthermore, one always has to be mindful of the occasional need to
rollback.  Generally, source code control is used for the local source
code component -- if you need to revert a change, just checkout an
earlier revision from your repo.  But if a network resource that used to
provide library X v1.0 now has moved on to X v2.0, and has dropped all
support for v1.0 so that it is no longer downloadable from the server,
then rollback is no longer possible.  You are now unable to reproduce a
build you made 2 years ago.  (Which you might need to, if a customer
environment is still running the old version and you need to debug it.)
IOW, the network is inherently unreliable.  Some form of local caching /
cache revision control is required.


[...]
> Then, is a DevOps world, there is deployment, which is usually a
> dependency management task. Is a totally new tool doing ADG
> manipulation really needed for this?

My answer is: the ADG/DAG manipulation should be a *library*, a reusable
component that can be integrated into diverse systems that require it.
Multiple systems that implement functionality X is not necessarily a
valid reason to argue for merging said systems into a single monolithic
monster.  Rather, what it *does* suggest is to factor out functionality
X so that it can be reused across said systems.


[...]
> Merging ideas from Dub, Gradle, and Reggae, into a project management
> tool for D (with C) projects is relatively straightforward of plan
> albeit really quite a complicated project. Creating the core ADG
> processing is the first requirement. It has to deal with external
> dependencies, project build dependencies, and deployment dependencies.

Your last sentence already shows that such a project is ill-advised,
because while all of them in an abstract sense reduce to nothing but DAG
manipulation, that is not an argument for integrating all systems that
happen to use DAGs as a core algorithm into a single monolithic system.
Rather, it's an indication that DAG manipulation code ought to be a
common library that's reused across systems that require such
functionality, i.e., external dependencies, build dependencies, and
deployment dependencies.

It's really very simple.  If your code has function X and function Y,
and X and Y have a lot of code in common, it does not mean you should

Re: Faking a non-pure function as pure

[Ali Çehreli via Digitalmars-d-learn]

On 02/16/2018 09:58 AM, Nordlöw wrote:


void g() pure
{
     static assert(!__traits(compiles, { auto x = f(42); }));
     alias pureF = assumePure!(typeof());
     // TODO: how do I call pureF?
     // auto x = (*pureF)(42);
     // auto x = pureF(42);
}



auto pureF = assumePure();
pureF(42);

Ali

Faking a non-pure function as pure

[Nordlöw via Digitalmars-d-learn]

I'm struggling with my definition of assumePure that should make 
a non-pure function `f` callable as pure `pureF`.


I've copied the definition of assumePure from the Phobos docs at

https://dlang.org/phobos/std_traits.html#SetFunctionAttributes

and managed to define pureF using it but I cannot call `pureF` as 
either


auto x = (*pureF)(42);
auto x = pureF(42);

How do I do that?

import std.traits : isFunctionPointer, isDelegate, 
functionAttributes, FunctionAttribute, SetFunctionAttributes, 
functionLinkage;


/** Return `T` assumed to be `pure`.
Copied from 
https://dlang.org/phobos/std_traits.html#SetFunctionAttributes.

*/
auto assumePure(T)(T t)
if (isFunctionPointer!T || isDelegate!T)
{
enum attrs = functionAttributes!T | FunctionAttribute.pure_;
return cast(SetFunctionAttributes!(T, functionLinkage!T, 
attrs)) t;

}

int f(int x)
{
return x + 1;
}

void g() pure
{
static assert(!__traits(compiles, { auto x = f(42); }));
alias pureF = assumePure!(typeof());
// TODO: how do I call pureF?
// auto x = (*pureF)(42);
// auto x = pureF(42);
}

[Issue 18425] std.process environment["VAR"] = "NAME" does not always take effect

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18425

--- Comment #4 from Rainer Schuetze  ---
> Was this a hand-copied typo, or was there a typo in the original?

Ooops. Typo is in the test only. The result with DFLAGS is the same, though.

> I looked at the code, and it's very complex, so I don't know that it's worth 
> trying to fix.

We could do the same as for posix: call the C runtime instead of
SetEnvironmentVariable. Both dmc and VC have _wputenv

--

Re: static opSlice is not possible

[Alex via Digitalmars-d-learn]

On Friday, 16 February 2018 at 13:35:03 UTC, Basile B. wrote:


Technically iy's a multi dimensional slicing but there's a 
constraint on the number of dimension allowed so that it looks 
exactly like a normal opSlice.


By the way, i reduced too much. This shows more how it works:

struct Foo
{
static auto opSlice(int index)(size_t lo, size_t hi)
if (index == 0)
{
return 41;
}
static auto opIndex(A...)(A a)
{
return opSlice!0(0,0) + 1;
}
}

static assert(Foo[0..1337] == 42);


Hey, cool!
Thanks :)

[Issue 18451] [REG 2.076.1] In certain circumstances, calling remove on an array of delegates fails

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18451

--- Comment #1 from Steven Schveighoffer  ---
A couple more notes:

Putting a pragma(msg, isInputRange!(typeof(dgs))) before the remove line seems
to make it succeed to compile.

Removing the writeln after the remove also makes it succeed.

--

[Issue 18451] [REG 2.076.1] In certain circumstances, calling remove on an array of delegates fails

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18451

Steven Schveighoffer  changed:

   What|Removed |Added

Summary|rejects-valid since 2.076.1 |[REG 2.076.1] In certain
   ||circumstances, calling
   ||remove on an array of
   ||delegates fails

--

[Issue 18451] rejects-valid since 2.076.1

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18451

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||schvei...@yahoo.com
   Hardware|x86_64  |All
 OS|Linux   |All

--

Re: is this a bug with writeln / std.algorithm.remove?

[arturg via Digitalmars-d-learn]

On Friday, 16 February 2018 at 13:57:07 UTC, Steven Schveighoffer 
wrote:


You have a pretty good minimal test, put that in bugzilla along 
with the forum thread link and all the info we know. Mark it as 
a dmd bug, regression, along with the version where it 
regressed (2.076.1), and I would tag it as "rejects-valid"


-Steve


ok done
https://issues.dlang.org/show_bug.cgi?id=18451

[Issue 18451] New: rejects-valid since 2.076.1

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18451

  Issue ID: 18451
   Summary: rejects-valid since 2.076.1
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: var.spool.mail...@gmail.com

this code fails to compile:

void main(){
import std.algorithm;
void delegate(void*) dg;
void delegate(void*)[] dgs = [dg, dg, dg];
dgs.writeln;
dgs.remove(1).writeln();
}

if you comment out the line with dgs.writeln;
or if the delegate uses a different type it works as expected.

running all dmd version on run.dlang.io
gives me this output:

Up to  2.075.1: Success with output:
-
[void delegate(void*), void delegate(void*), void delegate(void*)]
[void delegate(void*), void delegate(void*)]
-

Since  2.076.1: Failure with output:
-
/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/algorithm/mutation.d(1929):
Error: template std.algorithm.mutation.moveAll cannot deduce function from
argument types !()(void delegate(void*)[], void delegate(void*)[]), candidates
are:
/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/algorithm/mutation.d(1455):
   std.algorithm.mutation.moveAll(InputRange1, InputRange2)(InputRange1
src, InputRange2 tgt) if (isInputRange!InputRange1 && isInputRange!InputRange2
&& is(typeof(move(src.front, tgt.front
onlineapp.d(7): Error: template instance
std.algorithm.mutation.remove!(cast(SwapStrategy)2, void delegate(void*)[],
int) error instantiating

forum discussion:
https://forum.dlang.org/post/p66nvj$1g0a$1...@digitalmars.com

--

Re: is this a bug with writeln / std.algorithm.remove?

[Steven Schveighoffer via Digitalmars-d-learn]

On 2/16/18 8:51 AM, arturg wrote:

On Friday, 16 February 2018 at 13:28:59 UTC, Steven Schveighoffer wrote:


Strictly speaking, this is not necessarily proof that it's in phobos, 
there could have been changes elsewhere that cause one of the 
conditions to fail.


However, testing this out, I found something very weird.

If you pragma(msg, isInputRange!(typeof(dgs))); inside your file, then 
it compiles (and prints true for that pragma).


Makes no sense at all. Definitely seems like a compiler bug. A 
pragma(msg) shouldn't affect the outcome.




ok so what should the bug report look like?


You have a pretty good minimal test, put that in bugzilla along with the 
forum thread link and all the info we know. Mark it as a dmd bug, 
regression, along with the version where it regressed (2.076.1), and I 
would tag it as "rejects-valid"


-Steve

Re: is this a bug with writeln / std.algorithm.remove?

[arturg via Digitalmars-d-learn]

On Friday, 16 February 2018 at 13:28:59 UTC, Steven Schveighoffer 
wrote:


Strictly speaking, this is not necessarily proof that it's in 
phobos, there could have been changes elsewhere that cause one 
of the conditions to fail.


However, testing this out, I found something very weird.

If you pragma(msg, isInputRange!(typeof(dgs))); inside your 
file, then it compiles (and prints true for that pragma).


Makes no sense at all. Definitely seems like a compiler bug. A 
pragma(msg) shouldn't affect the outcome.


-Steve


ok so what should the bug report look like?

[Issue 11098] template instance x cannot use local y as parameter to non-global template z

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11098

Simen Kjaeraas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||simen.kja...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #3 from Simen Kjaeraas  ---


*** This issue has been marked as a duplicate of issue 5710 ***

--

[Issue 5710] cannot use delegates as parameters to non-global template

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5710

Simen Kjaeraas  changed:

   What|Removed |Added

 CC||simend...@gmail.com

--- Comment #43 from Simen Kjaeraas  ---
*** Issue 11098 has been marked as a duplicate of this issue. ***

--

Re: static opSlice is not possible

[Basile B. via Digitalmars-d-learn]

On Friday, 16 February 2018 at 13:23:09 UTC, Basile B. wrote:

On Thursday, 15 February 2018 at 22:49:56 UTC, Alex wrote:

Hi all,
a short question about an old bug:
https://issues.dlang.org/show_bug.cgi?id=11877

Are there reasons, which speaks against this feature?

And maybe another one, more general:
Is there any place, where it is documented, which operators 
can work in static mode and which cannot?


There's a hack to make static slicing working actually.
I've used it once to make a kind of set of character. Reduced 
example:



```
struct Foo
{
static auto opSlice(int index)(size_t lo, size_t hi)
if (index == 0)
{
return 42;
}
static auto opIndex(A...)(A a)
{
return 42;
}
}

static assert(Foo[0..1337] == 42);
```

I don't know if it is possible by error, maybe they forgot to 
disable this form of slicing.


Technically iy's a multi dimensional slicing but there's a 
constraint on the number of dimension allowed so that it looks 
exactly like a normal opSlice.


By the way, i reduced too much. This shows more how it works:

struct Foo
{
static auto opSlice(int index)(size_t lo, size_t hi)
if (index == 0)
{
return 41;
}
static auto opIndex(A...)(A a)
{
return opSlice!0(0,0) + 1;
}
}

static assert(Foo[0..1337] == 42);

Re: is this a bug with writeln / std.algorithm.remove?

[Steven Schveighoffer via Digitalmars-d-learn]

On 2/16/18 8:16 AM, bauss wrote:

On Friday, 16 February 2018 at 13:08:09 UTC, bauss wrote:

On Friday, 16 February 2018 at 12:15:07 UTC, arturg wrote:

On Friday, 16 February 2018 at 11:45:21 UTC, arturg wrote:

this code fails to compile:

    void delegate(void*) dg;
    void delegate(void*)[] dgs = [dg, dg, dg];
    dgs.writeln;
    dgs.remove(1).writeln();

if you comment out dgs.writeln; it works as expected,
it works if you use other types then void*:

    void delegate(int*) dg;
    void delegate(int*)[] dgs = [dg, dg, dg];
    dgs.writeln;
    dgs.remove(1).writeln();


the compiler is DMD64 D Compiler v2.078.2 and the error message is:

/usr/include/dlang/dmd/std/algorithm/mutation.d(1929): Error: 
template std.algorithm.mutation.moveAll cannot deduce function from 
argument types !()(void delegate(void*)[], void delegate(void*)[]), 
candidates are:
/usr/include/dlang/dmd/std/algorithm/mutation.d(1455): 
std.algorithm.mutation.moveAll(InputRange1, InputRange2)(InputRange1 
src, InputRange2 tgt) if (isInputRange!InputRange1 && 
isInputRange!InputRange2 && is(typeof(move(src.front, tgt.front
empty.d(9): Error: template instance 
std.algorithm.mutation.remove!(cast(SwapStrategy)2, void 
delegate(void*)[], int) error instantiating


running all dmd version on run.dlang.io
gives me this output:

Up to  2.075.1: Success with output:
-
[void delegate(void*), void delegate(void*), void delegate(void*)]
[void delegate(void*), void delegate(void*)]
-

Since  2.076.1: Failure with output:
-
/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/algorithm/mutation.d(1929): 
Error: template std.algorithm.mutation.moveAll cannot deduce function 
from argument types !()(void delegate(void*)[], void 
delegate(void*)[]), candidates are:
/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/algorithm/mutation.d(1455):
std.algorithm.mutation.moveAll(InputRange1, InputRange2)(InputRange1 
src, InputRange2 tgt) if (isInputRange!InputRange1 && 
isInputRange!InputRange2 && is(typeof(move(src.front, tgt.front
onlineapp.d(7): Error: template instance 
std.algorithm.mutation.remove!(cast(SwapStrategy)2, void 
delegate(void*)[], int) error instantiating

-


It's definitely a bug, the question is what change has caused it.


Looking at "moveAll" which is the one that causes the error, no changes 
has been made to that which could cause this as within the last 3 months 
only changes made to it has been two asserts that has been inserted. 
Other than that has only been a documentation change a year ago and 
prior to that changes hasn't been made to it for 3 years.


So it's a bug in the compiler, rather than Phobos itself.



Strictly speaking, this is not necessarily proof that it's in phobos, 
there could have been changes elsewhere that cause one of the conditions 
to fail.


However, testing this out, I found something very weird.

If you pragma(msg, isInputRange!(typeof(dgs))); inside your file, then 
it compiles (and prints true for that pragma).


Makes no sense at all. Definitely seems like a compiler bug. A 
pragma(msg) shouldn't affect the outcome.


-Steve

Re: static opSlice is not possible

[Basile B. via Digitalmars-d-learn]

On Thursday, 15 February 2018 at 22:49:56 UTC, Alex wrote:

Hi all,
a short question about an old bug:
https://issues.dlang.org/show_bug.cgi?id=11877

Are there reasons, which speaks against this feature?

And maybe another one, more general:
Is there any place, where it is documented, which operators can 
work in static mode and which cannot?


There's a hack to make static slicing working actually.
I've used it once to make a kind of set of character. Reduced 
example:



```
struct Foo
{
static auto opSlice(int index)(size_t lo, size_t hi)
if (index == 0)
{
return 42;
}
static auto opIndex(A...)(A a)
{
return 42;
}
}

static assert(Foo[0..1337] == 42);
```

I don't know if it is possible by error, maybe they forgot to 
disable this form of slicing.

Re: is this a bug with writeln / std.algorithm.remove?

[bauss via Digitalmars-d-learn]

On Friday, 16 February 2018 at 13:08:09 UTC, bauss wrote:

On Friday, 16 February 2018 at 12:15:07 UTC, arturg wrote:

On Friday, 16 February 2018 at 11:45:21 UTC, arturg wrote:

this code fails to compile:

void delegate(void*) dg;
void delegate(void*)[] dgs = [dg, dg, dg];
dgs.writeln;
dgs.remove(1).writeln();

if you comment out dgs.writeln; it works as expected,
it works if you use other types then void*:

void delegate(int*) dg;
void delegate(int*)[] dgs = [dg, dg, dg];
dgs.writeln;
dgs.remove(1).writeln();


the compiler is DMD64 D Compiler v2.078.2 and the error 
message is:


/usr/include/dlang/dmd/std/algorithm/mutation.d(1929): Error: 
template std.algorithm.mutation.moveAll cannot deduce 
function from argument types !()(void delegate(void*)[], void 
delegate(void*)[]), candidates are:
/usr/include/dlang/dmd/std/algorithm/mutation.d(1455):
std.algorithm.mutation.moveAll(InputRange1, 
InputRange2)(InputRange1 src, InputRange2 tgt) if 
(isInputRange!InputRange1 && isInputRange!InputRange2 && 
is(typeof(move(src.front, tgt.front
empty.d(9): Error: template instance 
std.algorithm.mutation.remove!(cast(SwapStrategy)2, void 
delegate(void*)[], int) error instantiating


running all dmd version on run.dlang.io
gives me this output:

Up to  2.075.1: Success with output:
-
[void delegate(void*), void delegate(void*), void 
delegate(void*)]

[void delegate(void*), void delegate(void*)]
-

Since  2.076.1: Failure with output:
-
/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/algorithm/mutation.d(1929):
 Error: template std.algorithm.mutation.moveAll cannot deduce function from 
argument types !()(void delegate(void*)[], void delegate(void*)[]), candidates 
are:
/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/algorithm/mutation.d(1455):
std.algorithm.mutation.moveAll(InputRange1, InputRange2)(InputRange1 src, InputRange2 tgt) if 
(isInputRange!InputRange1 && isInputRange!InputRange2 && 
is(typeof(move(src.front, tgt.front
onlineapp.d(7): Error: template instance 
std.algorithm.mutation.remove!(cast(SwapStrategy)2, void 
delegate(void*)[], int) error instantiating

-


It's definitely a bug, the question is what change has caused 
it.


Looking at "moveAll" which is the one that causes the error, no 
changes has been made to that which could cause this as within 
the last 3 months only changes made to it has been two asserts 
that has been inserted. Other than that has only been a 
documentation change a year ago and prior to that changes hasn't 
been made to it for 3 years.


So it's a bug in the compiler, rather than Phobos itself.

Re: Knowing the approach to solve a D challenge

[Dukc via Digitalmars-d]

On Friday, 16 February 2018 at 09:44:27 UTC, aberba wrote:
1. Do you first write it in idiomatic D style or a more general 
approach before porting to idiomatic D?


In micro-level, it's usually fairly idiomatic from get-go. 
Usually no heap allocations at inner loops, for-looping, static 
variables etc. Sometimes if I get a bit desperate of frustated I 
might do this a bit.


But at larger level, I often find myself shifting work between 
functions, structs, modules and so. In other words, redesigning.


2. Do you find yourself mostly rolling out your own 
implementation first before using a library function?


No, the vast majority of my calls are from Phobos or other 
libraries I use. And in case of Phobos at least, it's stuff is so 
general that I don't need to design my own function often. An 
exception is std.algorithm.each, but just to get better error 
messages (template constraints don't tell why the call did not 
work).



3. Do the use of generics come out of first try or a rewrite?


Rewriting a lot, but that's the case with all coding. With 
generics, i often tend to forget ! before an alias parameter.


4. What rough percentage of phobos knowledge is required for 
reasonable good problem solving efficiency?


If we talk about experience of the language in general, it's more 
than with C-style programming, Java or C# but less than with C++ 
generics. I don't think you have to know Phobos throughout, but 
you have to know the language and understand the philosophy of 
ranges quite deeply.


Percentages aren't important, I think that as long as you know 
the general purpose of std.algorithm, std.range, std.stdio, 
std.conv and std.array that gets you started. Again, if you know 
the language and understand the range concept.

Re: is this a bug with writeln / std.algorithm.remove?

[bauss via Digitalmars-d-learn]

On Friday, 16 February 2018 at 12:15:07 UTC, arturg wrote:

On Friday, 16 February 2018 at 11:45:21 UTC, arturg wrote:

this code fails to compile:

void delegate(void*) dg;
void delegate(void*)[] dgs = [dg, dg, dg];
dgs.writeln;
dgs.remove(1).writeln();

if you comment out dgs.writeln; it works as expected,
it works if you use other types then void*:

void delegate(int*) dg;
void delegate(int*)[] dgs = [dg, dg, dg];
dgs.writeln;
dgs.remove(1).writeln();


the compiler is DMD64 D Compiler v2.078.2 and the error 
message is:


/usr/include/dlang/dmd/std/algorithm/mutation.d(1929): Error: 
template std.algorithm.mutation.moveAll cannot deduce function 
from argument types !()(void delegate(void*)[], void 
delegate(void*)[]), candidates are:
/usr/include/dlang/dmd/std/algorithm/mutation.d(1455):
std.algorithm.mutation.moveAll(InputRange1, 
InputRange2)(InputRange1 src, InputRange2 tgt) if 
(isInputRange!InputRange1 && isInputRange!InputRange2 && 
is(typeof(move(src.front, tgt.front
empty.d(9): Error: template instance 
std.algorithm.mutation.remove!(cast(SwapStrategy)2, void 
delegate(void*)[], int) error instantiating


running all dmd version on run.dlang.io
gives me this output:

Up to  2.075.1: Success with output:
-
[void delegate(void*), void delegate(void*), void 
delegate(void*)]

[void delegate(void*), void delegate(void*)]
-

Since  2.076.1: Failure with output:
-
/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/algorithm/mutation.d(1929):
 Error: template std.algorithm.mutation.moveAll cannot deduce function from 
argument types !()(void delegate(void*)[], void delegate(void*)[]), candidates 
are:
/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/algorithm/mutation.d(1455):
std.algorithm.mutation.moveAll(InputRange1, InputRange2)(InputRange1 src, InputRange2 tgt) if 
(isInputRange!InputRange1 && isInputRange!InputRange2 && 
is(typeof(move(src.front, tgt.front
onlineapp.d(7): Error: template instance 
std.algorithm.mutation.remove!(cast(SwapStrategy)2, void 
delegate(void*)[], int) error instantiating

-


It's definitely a bug, the question is what change has caused it.

Re: is this a bug with writeln / std.algorithm.remove?

[arturg via Digitalmars-d-learn]

On Friday, 16 February 2018 at 11:45:21 UTC, arturg wrote:

this code fails to compile:

void delegate(void*) dg;
void delegate(void*)[] dgs = [dg, dg, dg];
dgs.writeln;
dgs.remove(1).writeln();

if you comment out dgs.writeln; it works as expected,
it works if you use other types then void*:

void delegate(int*) dg;
void delegate(int*)[] dgs = [dg, dg, dg];
dgs.writeln;
dgs.remove(1).writeln();


the compiler is DMD64 D Compiler v2.078.2 and the error message 
is:


/usr/include/dlang/dmd/std/algorithm/mutation.d(1929): Error: 
template std.algorithm.mutation.moveAll cannot deduce function 
from argument types !()(void delegate(void*)[], void 
delegate(void*)[]), candidates are:
/usr/include/dlang/dmd/std/algorithm/mutation.d(1455):
std.algorithm.mutation.moveAll(InputRange1, 
InputRange2)(InputRange1 src, InputRange2 tgt) if 
(isInputRange!InputRange1 && isInputRange!InputRange2 && 
is(typeof(move(src.front, tgt.front
empty.d(9): Error: template instance 
std.algorithm.mutation.remove!(cast(SwapStrategy)2, void 
delegate(void*)[], int) error instantiating


running all dmd version on run.dlang.io
gives me this output:

Up to  2.075.1: Success with output:
-
[void delegate(void*), void delegate(void*), void delegate(void*)]
[void delegate(void*), void delegate(void*)]
-

Since  2.076.1: Failure with output:
-
/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/algorithm/mutation.d(1929):
 Error: template std.algorithm.mutation.moveAll cannot deduce function from 
argument types !()(void delegate(void*)[], void delegate(void*)[]), candidates 
are:
/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/algorithm/mutation.d(1455):
std.algorithm.mutation.moveAll(InputRange1, InputRange2)(InputRange1 src, InputRange2 tgt) if 
(isInputRange!InputRange1 && isInputRange!InputRange2 && 
is(typeof(move(src.front, tgt.front
onlineapp.d(7): Error: template instance 
std.algorithm.mutation.remove!(cast(SwapStrategy)2, void 
delegate(void*)[], int) error instantiating

-

is this a bug with writeln / std.algorithm.remove?

[arturg via Digitalmars-d-learn]

this code fails to compile:

void delegate(void*) dg;
void delegate(void*)[] dgs = [dg, dg, dg];
dgs.writeln;
dgs.remove(1).writeln();

if you comment out dgs.writeln; it works as expected,
it works if you use other types then void*:

void delegate(int*) dg;
void delegate(int*)[] dgs = [dg, dg, dg];
dgs.writeln;
dgs.remove(1).writeln();


the compiler is DMD64 D Compiler v2.078.2 and the error message 
is:


/usr/include/dlang/dmd/std/algorithm/mutation.d(1929): Error: 
template std.algorithm.mutation.moveAll cannot deduce function 
from argument types !()(void delegate(void*)[], void 
delegate(void*)[]), candidates are:
/usr/include/dlang/dmd/std/algorithm/mutation.d(1455):
std.algorithm.mutation.moveAll(InputRange1, 
InputRange2)(InputRange1 src, InputRange2 tgt) if 
(isInputRange!InputRange1 && isInputRange!InputRange2 && 
is(typeof(move(src.front, tgt.front
empty.d(9): Error: template instance 
std.algorithm.mutation.remove!(cast(SwapStrategy)2, void 
delegate(void*)[], int) error instantiating

Re: How to check if aggregate member is static templated method?

[bauss via Digitalmars-d-learn]

On Thursday, 15 February 2018 at 15:49:47 UTC, RazvanN wrote:

On Thursday, 15 February 2018 at 13:51:41 UTC, drug wrote:

15.02.2018 16:50, drug пишет:

https://run.dlang.io/is/zHT2XZ
I can check againts if member is either static function or 
template. But I failed to check if it both static and 
templated.


The best I could come up with is:

struct Foo
{
static staticMethod()
{
}

static templatedStaticMethod(T)(T t)
{
}
}

void main()
{
static if(__traits(isTemplate, Foo.templatedStaticMethod) &&
  __traits(isStaticFunction, 
Foo.templatedStaticMethod!int))

{
 writeln("win");
}
}

It seems like a templated method can be queried if it is static 
only after it's instantiation. Hope this helps.


Cheers,
RazvanN


I would kinda argue that it's a bug, because checking whether a 
template function is static can become very complex if the 
template also has constraints etc.

[Issue 18450] ICE without line numbers on templated struct constructor call

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18450

Simen Kjaeraas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Simen Kjaeraas  ---
Fixed in 2.078.3

--

Re: Release D 2.078.2

[Martin Nowak via Digitalmars-d-announce]

On 02/10/2018 09:17 AM, Thomas Mader wrote:
> https://github.com/dlang/dub/releases/latest doesn't point to 1.7.2.

Out of curiosity, do you have a strong use-case to install/update dub
separately of the compiler?

Release D 2.078.3

[Martin Nowak via Digitalmars-d-announce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Glad to announce D 2.078.3.

http://dlang.org/download.html

This point release fixes an ICE and an incorrect diagnostic warning,
see the changelog for more details.

http://dlang.org/changelog/2.078.3.html

- -Martin
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlqGwAMACgkQsnOBFhK7
GTm/oBAAqHDM9B1AvX8lfLaGoAxJFtk/kWWIgWHPg/95if97lG9h3KrPXp3iDbxP
KNDowZ1z9FgEyCbwBzRJdSDpCSTDu7W8Y9f3eS0tnYglMjXXiG9YS7UcU0TgXwS4
HmpxitSWeyp2F7Jk2u9VYd6IaIY/uhsDZFJf88pba48mMUtxuSYtmdSB5WwZHeJ7
a5+o6Iowu+dpXKVn/0RHxZ8tQNC2lrBA2LbgfsX3niJck3gclMl4uffQBsKDxkuZ
kuXbC7lXq1tuYtFtLe77XEwr4mktGpysUDR6j2LqD4U0srrATUPBJSrerAzYLFkO
ZN7qCn2YwSsIyXJBysmB9nspGdEHhO6hRE2i8EMdSxfNJER5xUicVWQFE5EUTAPi
9xxv2itGrPeSTvqSolxmU4YGtwj2CBRaDXDhP7aNeNZPWmjKWNQNjvlKB/JZwf9w
7Z2pEHtnRmIUJ+sfLTV32oUmzbq+1bBGNY9SZTHE0x9nMX1ih3jVfWbn228awRK4
YLDM/60MwqVlsV2JBfJqpJ+tCU2xanSEqsf4/SNzt94qzcDR/tlWYLRuFMDN3pLs
crTpOcwNSwwWU7QWq14uZOaNZK7L38WHaqC1WCUgKh14PYujF7sLtKE0K+tPoyrr
GKHiE9Xrk763VMuaEpeYneBhA7MDrkb02eKkFTiCj3+W7cQZyS4=
=ugv4
-END PGP SIGNATURE-

Re: Knowing the approach to solve a D challenge

[Chris via Digitalmars-d]

On Friday, 16 February 2018 at 09:44:27 UTC, aberba wrote:
D has tone of features and library solutions. When you 
encounter a problem, how do you approach solving it in code?


1. Do you first write it in idiomatic D style or a more general 
approach before porting to idiomatic D?


As idiomatic as possible. But it depends on how big and/or 
important the method/function is. The more important and/or 
bigger, the more idiomatic. Sometimes a `foreach` will do in a 
small function.


But D makes it easy to write idiomatic code straight away, 
although sometimes it can be a bit annoying when you get messages 
like "cannot implicitly convert x of type y to z". So you have to 
keep track of what you are chaining.


2. Do you find yourself mostly rolling out your own 
implementation first before using a library function?


I usually start to roll out my own for a few minutes until I say 
"Hold on, maybe the library already has a function that does 
exactly that!" And it often does. That's because I get a better 
understanding of what I need, when I roll my own for a while. 
Using the library straight away can sometimes result in shooting 
yourself in the foot. So it's a mix of both.



3. Do the use of generics come out of first try or a rewrite?


Depends on the problem at hand. I you know you will have to 
handle several types down the road, it's a minimal generic that 
accepts only one type to begin with but that can be extended to 
others. It's a bit "play by ear". If I'm dealing with HTML and I 
know that JSON or CSV will be needed later, I write the function 
in a way that it can easily be extended. If a function returns 
the user name as a `string`, I won't bother with generics. That's 
just normal, I think.


4. What rough percentage of phobos knowledge is required for 
reasonable good problem solving efficiency?


You cannot know every function, of course, and new functions are 
being added all the time. What you need to know is what Phobos 
can do in general and where to look for it. The cheat sheet 
should be the first port of call. You can save a lot of time by 
skimming through the library regularly. Also, it's worth looking 
at other people's code in the "learn" section. What often happens 
to me, when I see a solution, I go "Jesus, that's clever, I'll 
keep that in mind!" The learn section is good because it focuses 
on one (small) problem at a time.

Re: getSymbolsByUDA does not take private symbols under consideration. Should I file a bug?

[bauss via Digitalmars-d-learn]

On Friday, 16 February 2018 at 09:26:47 UTC, Piotr Mitana wrote:

Hello,

The code below:


import std.traits;

enum Attr;

class MyClass
{
private @Attr int a;
static assert(getSymbolsByUDA!(typeof(this), 
MyClass).length == 1);

}


does not compile as static assertion fails. Making the filed a 
public makes it compile properly. Should I file a bug or is by 
design?


It's definitely a bug!

Re: Knowing the approach to solve a D challenge

[Joakim via Digitalmars-d]

I don't write much D code, but here are my answers for _any_ 
language.


On Friday, 16 February 2018 at 09:44:27 UTC, aberba wrote:
D has tone of features and library solutions. When you 
encounter a problem, how do you approach solving it in code?


1. Do you first write it in idiomatic D style or a more general 
approach before porting to idiomatic D?


The style in my head, which sometimes is D function chains, for 
example, this chain I put in Phobos:


https://github.com/dlang/phobos/blob/master/std/datetime/timezone.d#L2501

Compare it to the previously-written non-Android version just 
below, which could probably be written as such a chain but might 
be too unwieldy if done that way.


2. Do you find yourself mostly rolling out your own 
implementation first before using a library function?


Look for a library function, and if nothing works, write your own.


3. Do the use of generics come out of first try or a rewrite?


I don't really need them for my own functions, so can't say.

4. What rough percentage of phobos knowledge is required for 
reasonable good problem solving efficiency?


Just hunt for something when you need it.  Knowing Phobos well is 
like indexing your data beforehand, you'll find something much 
quicker.


The reason D supports so many styles is so you don't have to 
force yourself to use only one style.  The D idioms are there if 
you need them though, and you may find using them gives you 
better code.

Re: Knowing the approach to solve a D challenge

[rikki cattermole via Digitalmars-d]

On 16/02/2018 9:44 AM, aberba wrote:
D has tone of features and library solutions. When you encounter a 
problem, how do you approach solving it in code?


1. Do you first write it in idiomatic D style or a more general approach 
before porting to idiomatic D?


2. Do you find yourself mostly rolling out your own implementation first 
before using a library function?


3. Do the use of generics come out of first try or a rewrite?

4. What rough percentage of phobos knowledge is required for reasonable 
good problem solving efficiency?


A: Do it any way possible

If it needs a rewrite then yes more idiomatic and better designed :)

Knowing the approach to solve a D challenge

[aberba via Digitalmars-d]

D has tone of features and library solutions. When you encounter 
a problem, how do you approach solving it in code?


1. Do you first write it in idiomatic D style or a more general 
approach before porting to idiomatic D?


2. Do you find yourself mostly rolling out your own 
implementation first before using a library function?


3. Do the use of generics come out of first try or a rewrite?

4. What rough percentage of phobos knowledge is required for 
reasonable good problem solving efficiency?

Re: getSymbolsByUDA does not take private symbols under consideration. Should I file a bug?

[Anonymouse via Digitalmars-d-learn]

On Friday, 16 February 2018 at 09:26:47 UTC, Piotr Mitana wrote:

Hello,

The code below:


import std.traits;

enum Attr;

class MyClass
{
private @Attr int a;
static assert(getSymbolsByUDA!(typeof(this), 
MyClass).length == 1);

}


does not compile as static assertion fails. Making the filed a 
public makes it compile properly. Should I file a bug or is by 
design?


getSymbolsByUDA seems to have some visibility thing going on. 
Related to https://issues.dlang.org/show_bug.cgi?id=17973 
perhaps? Though that only gives deprecation warnings, not errors.

getSymbolsByUDA does not take private symbols under consideration. Should I file a bug?

[Piotr Mitana via Digitalmars-d-learn]

Hello,

The code below:


import std.traits;

enum Attr;

class MyClass
{
private @Attr int a;
static assert(getSymbolsByUDA!(typeof(this), MyClass).length 
== 1);

}


does not compile as static assertion fails. Making the filed a 
public makes it compile properly. Should I file a bug or is by 
design?

Re: Congrats to D / Vibe-D -- techempower Round 15

[Daniel Kozak via Digitalmars-d]

https://tfb-status.techempower.com/raw/results.2018-02-09-10-22-34-441.json

On Fri, Feb 16, 2018 at 1:01 AM, Petar via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On Thursday, 15 February 2018 at 20:59:53 UTC, Ali wrote:
>
>> On Thursday, 15 February 2018 at 20:43:41 UTC, Daniel Kozak wrote:
>>
>>> Unfortunately they have use wrong results.  They have selected run from
>>> 31.1.2018. But If they use the other one from february, it would be better.
>>> But still is nice
>>>
>>>
>>
>> Can you post the numbers from Feb, for us here? :)
>>
>
> My guess is that newer results can be found here:
> https://tfb-status.techempower.com
>
> (Sorry for not posting the exact results, but I'm on the phone. I think we
> need to run some of their scripts to generate a nice graph from the json.)
>

[Issue 18441] Add comments to GC page about tradeoffs in design and impl of GC (garbage collector)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18441

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #3 from greenify  ---
There is also this nice GC series: https://dlang.org/blog/the-gc-series/

We should probably link to it from the front page.

--

[Issue 18450] New: ICE without line numbers on templated struct constructor call

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18450

  Issue ID: 18450
   Summary: ICE without line numbers on templated struct
constructor call
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Keywords: ice
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: simen.kja...@gmail.com

DMD 2.078.2 on Windows.

This code:

struct S2(T) {
T arr;
}

unittest {
const S2!(int) b;
S2!(const(int)) c = b; // Line 7
}

Gives this error:

foo.d(7): Error:
object.Error@(0): Access Violation

0x0065445A
0x006548FE
0x0064DBD3
0x004B0B90
0x0043FC26
0x004C794B
0x01162110
0x011623E0

With a little wiggling of the types:

struct S2(T) {
T arr;
}

unittest {
const S2!(int[]) b;
S2!(const(int[])) c = b;
}

I get an even more interesting:

foo.d(7): Error:
object.Error@(0): Access Violation

0x0065445A
0x006548FE
0x0064DBD3
0x004B0B90
0x0043FC26
0x004C794B
0x773A8B88 in RtlFreeHeap
0x005797E2
0x00594C94
0x773A73F7 in RtlAllocateHeap
0x3F5011A9
0x05F6122D
0x175102F7
0x01CE5388
0x007201EF
0x01220042
0x047700C6
0x0021035A
0x0504
0x001A0129
0x000106B4
0x00400063
0x001C00C6
0x00820021
0x00620063

--

[Issue 18441] Add comments to GC page about tradeoffs in design and impl of GC (garbage collector)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18441

--- Comment #2 from anonymous4  ---
https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e GC
questionnaire, may be interesting to fill.

--

[Issue 17747] extern(C) shared static module constructor should be called in betterC programs

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17747

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |FIXED

--- Comment #18 from Walter Bright  ---
resolved by https://github.com/dlang/dmd/pull/7182

--