Re: PR duty

[rikki cattermole via Digitalmars-d]

On 04/04/2018 5:31 PM, Andrei Alexandrescu wrote:

Hi folks, I was thinking of the following.

To keep the PR queue trim and in good shape, we'd need at least one 
full-time engineer minding it. I've done that occasionally, and the 
queue size got shorter, but I couldn't do much else during that time.


I was thinking, we can't afford a full-time engineer, and even if we 
did, we'd probably have other important matters for that engineer as 
well. However, what we can afford - and indeed already benefit from - is 
a quantum of time from each of many volunteers. By organizing that time 
better we may be able to get more output. Here's what I'm thinking.


Let's define a "PR duty" role that is one week long for each of a pool 
of volunteers. During that week, the person on PR duty focuses on 
minding github queues - merge trivial PRs, ping authors of old PRs, 
email decision makers for specific items in PRs, etc. Then the week ends 
and the role is handed off to the next person in the pool.


A calendar maintained by an impartial person - maybe we can ask Mike - 
would keep track of everything.


The most obvious candidates for PR duty engineers would be the most 
prolific contributors in the respective repositories.


One question would be how many distinct pools/tracks we should have. 
Presumably someone fluent with phobos is not necessarily fluent with 
dmd. So probably we need at least two tracks:


* dmd
* everything else (druntime, phobos, tools, site)


Compiler specific stuff, system specific and finally general e.g. 
bindings may need to be separated roles for druntime.


Compiler specific can merge with dmd, that just leaves system and 
"other" which probably can be merged.

PR duty

[Andrei Alexandrescu via Digitalmars-d]

Hi folks, I was thinking of the following.

To keep the PR queue trim and in good shape, we'd need at least one 
full-time engineer minding it. I've done that occasionally, and the 
queue size got shorter, but I couldn't do much else during that time.


I was thinking, we can't afford a full-time engineer, and even if we 
did, we'd probably have other important matters for that engineer as 
well. However, what we can afford - and indeed already benefit from - is 
a quantum of time from each of many volunteers. By organizing that time 
better we may be able to get more output. Here's what I'm thinking.


Let's define a "PR duty" role that is one week long for each of a pool 
of volunteers. During that week, the person on PR duty focuses on 
minding github queues - merge trivial PRs, ping authors of old PRs, 
email decision makers for specific items in PRs, etc. Then the week ends 
and the role is handed off to the next person in the pool.


A calendar maintained by an impartial person - maybe we can ask Mike - 
would keep track of everything.


The most obvious candidates for PR duty engineers would be the most 
prolific contributors in the respective repositories.


One question would be how many distinct pools/tracks we should have. 
Presumably someone fluent with phobos is not necessarily fluent with 
dmd. So probably we need at least two tracks:


* dmd
* everything else (druntime, phobos, tools, site)

If there are a dozen of us in each pool, each would be on duty one week 
every three months. Even with eight, we'd be on duty a manageable week 
every other month.


Please share your thoughts.


Thanks,

Andrei

[Issue 15206] [REG2.077] ICE on optimized build, tym = x1d Internal error: backend\cgxmm.c 547

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com
Summary|ICE on optimized build, tym |[REG2.077] ICE on optimized
   |= x1d Internal error:   |build, tym = x1d Internal
   |backend\cgxmm.c 547 |error: backend\cgxmm.c 547
   Severity|critical|regression

--- Comment #8 from Seb  ---
Yep, can reproduce the test case from John too  e.g.
https://run.dlang.io/is/REkj3X

BTW digger says that this PR https://github.com/dlang/dmd/pull/7175 introduced
this. 
so I'm re-labelling this as a regression.

And also I can confirm that https://github.com/dlang/dmd/pull/8034 fixes this.

--

Re: DIP in making: ProtoObject

[Jonathan M Davis via Digitalmars-d]

On Wednesday, April 04, 2018 00:49:10 Andrei Alexandrescu via Digitalmars-d 
wrote:
> I'm working on a simple older idea to get it out of the way in
> preparation for the more difficult DIPs to come:
>
> https://github.com/andralex/DIPs/blob/ProtoObject/DIPs/DIP.md
>
> This is not officially reviewable yet, but conveys the gist and could
> use some early feedback. Any insight will be appreciated.

Two things I can think of after quickly going over it:

1. While issues with attributes and Object are discussed, the fact that
Object.opEquals requires casting away const and effectively puts a hole in
the type system is not mentioned. I don't know that it's all that critical
to mention it given all of the other issues, but it certainly affects how
overloading opEquals is going to need to be implemented for ProtoObject.
Presumably, the free function version of opEquals will need to be templated
with an overload that takes classes which are not derived from Object,
allowing opEquals to use whatever attributes are appropriate.

2. What happens if you put synchronized on a member function when the class
is not derived from ProtoObjectWithMonitor? I would assume that it would be
an error, but the DIP doesn't say.

- Jonathna M Davis

Taming templates and mixin magic: type inpector helper in D/Phobos?

[Carlos Navarro via Digitalmars-d-learn]

As a newbie in D (and making a lots of mistakes), I've found 
myself relying heavily in the use of a rudimentary type inspector 
to visualize my templated code instantiations.
It's simple and incomplete as hell but good enough to see what 
happens under the hood quickly.


QUESTION: Is there a function like that already in D?


//real-life example
goodEnoughTypeInspector!Human;
goodEnoughTypeInspector!(Database!Human);

//compile-time output
Inspecting type: Human
 - public string name
 - public string address
 - public bool active

Inspecting type: Database!(Human)
 - private string[] name
 - private string[] address
 - private bool[] active
 - public pure nothrow @nogc @safe ulong() count
 - public void insert

[Issue 18718] ICE in dmd/traits.d:417

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

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

--- Comment #1 from Seb  ---
A start - https://github.com/dlang/dmd/pull/8125 (<- needs more work)

--

Re: Learning D - modules packages and the package.d

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, April 04, 2018 04:54:50 Ali via Digitalmars-d-learn wrote:
> I am going through the Learning D book by Michael Parker
> So every now and then I will make post about the book
> either critics of the book, book content or questions
>
>
> First critic
> chapter 2 - the special package module
>
> this small section, suggest an idiom to create a package which
> can have any name
> the book suggest somepack
> and inside it add a module package.d , so you will end up
> somepack/package.d
> inside the file add
>
> > module somepack; //notice this named after the folder
> > //then public import std.stdio, somepack.one, somepack.two;
> > //etc
>
> at first i though package.d is special name, as in i must call
> the file package.d or this trick or idiom to work
> also it felt weird that the module name, is named after the
> folder name, which previously was referred to as the package name
>
> anyway, i started playing with this, and renaming everything
> and my conclusion is
>
> i not really sure, if D really support or have packages
> as in D is aware that some modules are together in a package
>
> it seems to me at this time D only support modules
> modules can have names with . in them
> you can use the . in module names to make it seem as if its
> packages
>
> > import io = long.module.name
>
> also seem as a trick that complements having modules with long
> names with dots in them
>
> and it seems you really need to match file and module names
>
> my critic of the chapter 2 so far, the book doesn't really help
> clarify this situation
> i am relieved though to learn that D doesnt treat special
> file/module names as special

In general, modules correspond to files, and packages correspond to folders.
That can be played with by naming modules with names that don't match their
file names, but it tends to cause problems with build tools. In general,
modules and packages should match their corresponding file and folder names
if you don't want problems.

package.d is a special case. package is not a legal module name, so when the
package.d feature was added to the language, the odds of it conflicting with
any existing files were very low. What happens with package.d is that when
you try to import a package rather than a module, the compiled looks for a
package.d file within the package that you're trying to import, and it
imports that module. The typical thing to do is to have the module name
within that module match the package name. I don't know what happens if you
try to do otherwise, but I wouldn't expect it to work, because in this case,
the compiler is specifically looking for package.d and not the module with
with matching module declaration. _That_ is all that's special about
package.d - it's what's imported you try to import a package.

Now, if there is a package.d, it's typically the case that it has public
import statements for the modules inside the package so that importing the
package will then import all of the modules within the package, but what
actually gets imported when importing the package is entirely dependent on
what's in package.d. It can define symbols of its own, and it doesn't _have_
to publicly import anything. And since public imports can be used in any
module, there's nothing really special about them in package.d. It's just
that using them in package.d makes it possible to have it be the case that
importing a package imports all of the modules within that package.

The entire reason that the package.d feature was added to the language was
so that a module could be broken up into multiple modules within a package
with the same name without breaking code in the process - e.g.
std.algorithm, std.container, std.datetime, and std.range were all
originally modules, but now, they're all packages. Personally, I don't think
that it's great practice to use package.d if you don't have to (and
importing that many symbols at once can negatively impact compilation
times), but some folks like to use it for their libraries so that you can
import everything at once.

- Jonathan M Davis

Re: Learning D - modules packages and the package.d

[Ali via Digitalmars-d-learn]

On Wednesday, 4 April 2018 at 04:54:50 UTC, Ali wrote:
at first i though package.d is special name, as in i must call 
the file package.d or this trick or idiom to work


the trick was to have one module that public import all the 
modules you import as group in other modules


so instead of importing a dozen or so modules, you only import 
one module that imports everything you need

Learning D - modules packages and the package.d

[Ali via Digitalmars-d-learn]

I am going through the Learning D book by Michael Parker
So every now and then I will make post about the book
either critics of the book, book content or questions


First critic
chapter 2 - the special package module

this small section, suggest an idiom to create a package which 
can have any name

the book suggest somepack
and inside it add a module package.d , so you will end up 
somepack/package.d

inside the file add


module somepack; //notice this named after the folder
//then public import std.stdio, somepack.one, somepack.two; 
//etc


at first i though package.d is special name, as in i must call 
the file package.d or this trick or idiom to work
also it felt weird that the module name, is named after the 
folder name, which previously was referred to as the package name


anyway, i started playing with this, and renaming everything
and my conclusion is

i not really sure, if D really support or have packages
as in D is aware that some modules are together in a package

it seems to me at this time D only support modules
modules can have names with . in them
you can use the . in module names to make it seem as if its 
packages



import io = long.module.name


also seem as a trick that complements having modules with long 
names with dots in them


and it seems you really need to match file and module names

my critic of the chapter 2 so far, the book doesn't really help 
clarify this situation
i am relieved though to learn that D doesnt treat special 
file/module names as special

DIP in making: ProtoObject

[Andrei Alexandrescu via Digitalmars-d]

I'm working on a simple older idea to get it out of the way in 
preparation for the more difficult DIPs to come:


https://github.com/andralex/DIPs/blob/ProtoObject/DIPs/DIP.md

This is not officially reviewable yet, but conveys the gist and could 
use some early feedback. Any insight will be appreciated.



Thanks,

Andrei

[Issue 18723] New: std.exception.ErrnoException@std/stdio.d(1012): Enforcement failed (Bad file descriptor) when running the simplified benchmark

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

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

  Issue ID: 18723
   Summary: std.exception.ErrnoException@std/stdio.d(1012):
Enforcement failed (Bad file descriptor) when running
the simplified benchmark
   Product: D
   Version: D2
  Hardware: All
OS: FreeBSD
Status: NEW
  Severity: major
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

Comes from running the simplified benchmark.
Maybe this is related to / fixed by:

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


--
std.exception.ErrnoException@std/stdio.d(1012): Enforcement failed (Bad file
descriptor)
gmake -C test/typeinfo MODEL=64 OS=freebsd
DMD=/usr/home/braddr/sandbox/at-client/pull-3102365-FreeBSD_64_64/dmd/generated/freebsd/release/64/dmd
BUILD=debug \
   
DRUNTIME=/usr/home/braddr/sandbox/at-client/pull-3102365-FreeBSD_64_64/druntime/generated/freebsd/debug/64/libdruntime.a
DRUNTIMESO=/usr/home/braddr/sandbox/at-client/pull-3102365-FreeBSD_64_64/druntime/generated/freebsd/debug/64/libdruntime.so
LINKDL= \
QUIET= TIMELIMIT='timelimit -t 10 ' PIC=-fPIC

??:? @safe void
std.exception.bailOut!(std.exception.ErrnoException).bailOut(immutable(char)[],
ulong, const(char[])) [0x457555]
??:? @safe bool
std.exception.enforce!(std.exception.ErrnoException).enforce!(bool).enforce(bool,
lazy const(char)[], immutable(char)[], ulong) [0xcd6625]
??:? @safe ubyte[] std.stdio.File.rawRead!(ubyte).rawRead(ubyte[]) [0xd28dd3]
??:? void std.stdio.File.ByChunkImpl.prime() [0xd26875]
??:? ref std.stdio.File.ByChunkImpl
std.stdio.File.ByChunkImpl.__ctor(std.stdio.File, ubyte[]) [0xd269ca]
??:? ref std.stdio.File.ByChunkImpl
std.stdio.File.ByChunkImpl.__ctor(std.stdio.File, ulong) [0xd268f5]
??:? std.stdio.File.ByChunkImpl std.stdio.File.byChunk(ulong) [0xd26d1b]
??:? std.typecons.Tuple!(int, "status", immutable(char)[], "output").Tuple
std.process.executeImpl!(std.process.pipeShell(const(char[]),
std.process.Redirect, const(immutable(char)[][immutable(char)[]]),
std.process.Config, const(char[]), immutable(char)[]), const(char)[],
immutable(char)[]).executeImpl(const(char)[],
const(immutable(char)[][immutable(char)[]]), std.process.Config, ulong,
const(char[]), immutable(char)[]) [0xd1ea69]
??:? @trusted std.typecons.Tuple!(int, "status", immutable(char)[],
"output").Tuple std.process.executeShell(const(char[]),
const(immutable(char)[][immutable(char)[]]), std.process.Config, ulong,
const(char[]), immutable(char)[]) [0xd1b00a]
??:? std.regex.internal.ir.MatcherFactory!(char).MatcherFactory
std.regex.internal.ir.defaultFactory!(char).defaultFactory(ref
const(std.regex.internal.ir.Regex!(char).Regex)).thompsonFactory [0x4555a5]
??:? int runbench.runTests(runbench.Config).__foreachbody4(ref
immutable(char)[]) [0x45656c]
??:? void
std.parallelism.ParallelForeach!(immutable(char)[][]).ParallelForeach.opApply(scope
int delegate(ref immutable(char)[])).doIt() [0x489403]
??:? void std.parallelism.run!(void delegate()).run(void delegate()) [0xd159af]
??:? void std.parallelism.Task!(std.parallelism.run, void
delegate()).Task.impl(void*) [0xd154eb]
??:? void std.parallelism.AbstractTask.job() [0xd13e66]
??:? void std.parallelism.TaskPool.doJob(std.parallelism.AbstractTask*)
[0xd1403f]
??:? void std.parallelism.TaskPool.executeWorkLoop() [0xd14199]
??:? void std.parallelism.TaskPool.startWorkLoop() [0xd14140]
??:? void core.thread.Thread.run() [0xe134c3]
??:? thread_entryPoint [0xe1264c]
??:? pthread_create [0x11f1bc4]
??:? ??? [0x]
---

--

Re: std.variant Is Everything Cool About D

[Meta via Digitalmars-d-announce]

On Wednesday, 4 April 2018 at 03:09:22 UTC, helxi wrote:

On Thursday, 29 March 2018 at 14:10:39 UTC, Mike Parker wrote:
Jared Hanson (a.k.a Meta and MetaLang around these parts) was 
inspired by an article titled "std::visit is everything wrong 
with modern C++" to contrast it with D's std.variant.visit. 
The result is this well-written post for the D Blog.


The blog:
https://dlang.org/blog/2018/03/29/std-variant-is-everything-cool-about-d/

Reddit:
https://www.reddit.com/r/programming/comments/881hmi/stdvariant_is_everything_cool_about_d/


What is the difference between 
https://dlang.org/phobos/std_typecons.html#Nullable and 
Algebraic!(T, typeof(null))?


Nullable is specifically specialized to this particular use-case 
and only has to store a boolean in addition the wrapped data (and 
there is a template "overload" that allows you to specify a 
specific value for the `null` state, which removes even that 
boolean). Also, with Nullable your data is guaranteed to not be 
boxed, whereas it's a possibility with Variant/Algebraic if the 
types you're working with are large enough.

[Issue 18722] New: runnable/test13666.sh has magic failures on Windows

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

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

  Issue ID: 18722
   Summary: runnable/test13666.sh has magic failures on Windows
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

---
Test runnable/test13666.sh failed. The logged output:
test_results\runnable\test13666.lib: Error: MS-Coff object module
`lib13666.obj` has magic = 5ac3, should be 8664
test_results\runnable\test13666.lib: Error: MS-Coff object module
`lib13666_1_144.obj` has magic = 5ac3, should be 8664
test_results\runnable\test13666.lib: Error: MS-Coff object module
`lib13666_2_520.obj` has magic = 5ac3, should be 8664
==
Test runnable/test13666.sh failed. The xtrace output:
+ source runnable/test13666.sh
++ libname=test_results/runnable/test13666.lib
++ ../generated/windows/release/32/dmd.exe -m64 -Irunnable/extra-files
-oftest_results/runnable/test13666.lib -lib 'runnable/extra-files\lib13666.d'
---

--

Re: std.variant Is Everything Cool About D

[helxi via Digitalmars-d-announce]

On Thursday, 29 March 2018 at 14:10:39 UTC, Mike Parker wrote:
Jared Hanson (a.k.a Meta and MetaLang around these parts) was 
inspired by an article titled "std::visit is everything wrong 
with modern C++" to contrast it with D's std.variant.visit. The 
result is this well-written post for the D Blog.


The blog:
https://dlang.org/blog/2018/03/29/std-variant-is-everything-cool-about-d/

Reddit:
https://www.reddit.com/r/programming/comments/881hmi/stdvariant_is_everything_cool_about_d/


What is the difference between 
https://dlang.org/phobos/std_typecons.html#Nullable and 
Algebraic!(T, typeof(null))?

[Issue 18721] New: ICE in dmd/cond.d(378) when compiling static foreach with -D

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

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

  Issue ID: 18721
   Summary: ICE in dmd/cond.d(378) when compiling static foreach
with -D
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: ice, ice-on-valid-code
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

>From https://github.com/dlang/phobos/pull/6402

Reduced:

> dmd -D

---
///
template allSameType()
{
static foreach (idx; T)
enum allSameType ;
}

---


---
core.exception.AssertError@dmd/cond.d(378): Assertion failure

??:? _d_assertp [0x74903d]
dmd/cond.d:378 pure nothrow @nogc @safe void
dmd.cond.StaticForeach.prepare(dmd.dscope.Scope*).__require() [0x51392f]
dmd/cond.d:377 void dmd.cond.StaticForeach.prepare(dmd.dscope.Scope*)
[0x5137dc]
dmd/attrib.d:1083 _ZN24StaticForeachDeclaration7includeEP5Scope [0x50c2df]
dmd/doc.d:1042 _ZN11emitComment11EmitComment5visitEP17AttribDeclaration
[0x55811b]
dmd/parsetimevisitor.d:75
_ZN16ParseTimeVisitorI10ASTCodegenE5visitEP24StaticForeachDeclaration
[0x6437f2]
dmd/attrib.d:1143 _ZN24StaticForeachDeclaration6acceptEP7Visitor [0x50c48d]
dmd/doc.d:1091 void dmd.doc.emitComment(dmd.dsymbol.Dsymbol,
dmd.root.outbuffer.OutBuffer*, dmd.dscope.Scope*) [0x557798]
dmd/doc.d:796 void dmd.doc.emitMemberComments(dmd.dsymbol.ScopeDsymbol,
dmd.root.outbuffer.OutBuffer*, dmd.dscope.Scope*) [0x55767c]
dmd/doc.d:916 _ZN11emitComment11EmitComment4emitEP5ScopeP7DsymbolPKc [0x557c57]
dmd/doc.d:960 _ZN11emitComment11EmitComment5visitEP11Declaration [0x557ded]
dmd/parsetimevisitor.d:47
_ZN16ParseTimeVisitorI10ASTCodegenE5visitEP16AliasDeclaration [0x643492]
dmd/declaration.d:929 _ZN16AliasDeclaration6acceptEP7Visitor [0x535d61]
dmd/doc.d:1091 void dmd.doc.emitComment(dmd.dsymbol.Dsymbol,
dmd.root.outbuffer.OutBuffer*, dmd.dscope.Scope*) [0x557798]
dmd/doc.d:796 void dmd.doc.emitMemberComments(dmd.dsymbol.ScopeDsymbol,
dmd.root.outbuffer.OutBuffer*, dmd.dscope.Scope*) [0x55767c]
dmd/doc.d:439 _Z10gendocfileP6Module [0x556783]
dmd/mars.d:911 int dmd.mars.tryMain(ulong, const(char)**) [0x5f8097]
dmd/mars.d:1098 _Dmain [0x5f8d92]
---

--

Re: code-d 0.17.0 + serve-d 0.1.2

[Mike Franklin via Digitalmars-d-announce]

On Tuesday, 3 April 2018 at 23:50:24 UTC, Arredondo wrote:
I could not get this to work for me in the past (I'm using 
Windows 10). I saw this announcement so I decided to try again.


I have a little more experience to share...

std.process.ProcessException@std\process.d(753): Failed to 
spawn new process (The system cannot find the file specified.)


0x00384D1F
0x00384AD2
0x00382ADD


This seems to appear due to the import timing feature.  You can 
disable it in your settings with `"d.enableDMDImportTiming": 
false`


Moreover, the extension is completely SPAMMING the output 
console, making it pop up constantly with endless messages like:


The spam to the output console is normal (I think).  It's 
actually quite useful when troubleshooting, and I don't think the 
popup window should show up uninvited.  It doesn't for me, anyway.


Mike

[Issue 18720] New: Segfault in src/gc/impl/conservative/gc.d:1990

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

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

  Issue ID: 18720
   Summary: Segfault in src/gc/impl/conservative/gc.d:1990
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

>From https://circleci.com/gh/dlang/phobos/7257

---
Program received signal SIGSEGV, Segmentation fault.
0x00b17fec in gc.impl.conservative() (this=..., ptop=0x608f670,
pbot=0x608f630) at src/gc/impl/conservative/gc.d:1990
1990auto p = *p1;
#0  0x00b17fec in gc.impl.conservative() (this=..., ptop=0x608f670,
pbot=0x608f630) at src/gc/impl/conservative/gc.d:1990
#1  0x00b188f1 in gc.impl.conservative() (this=0x7fff9b70,
__applyArg0=...) at src/gc/impl/conservative/gc.d:2188
#2  0x00b23d5d in rt.util.container.treap() (this=0x7fff9b30,
e=...) at src/rt/util/container/treap.d:47
#3  0x00b24135 in rt.util.container.treap() (dg=..., node=0x5d5c210) at
src/rt/util/container/treap.d:221
#4  0x00b24161 in rt.util.container.treap() (dg=..., node=0x5ef5950) at
src/rt/util/container/treap.d:224
#5  0x00b24161 in rt.util.container.treap() (dg=..., node=0x5ef4ec0) at
src/rt/util/container/treap.d:224
#6  0x00b24161 in rt.util.container.treap() (dg=..., node=0x5ef45b0) at
src/rt/util/container/treap.d:224
#7  0x00b24161 in rt.util.container.treap() (dg=..., node=0x5783e90) at
src/rt/util/container/treap.d:224
#8  0x00b24161 in rt.util.container.treap() (dg=..., node=0x5607660) at
src/rt/util/container/treap.d:224
#9  0x00b24161 in rt.util.container.treap() (dg=..., node=0x5905eb0) at
src/rt/util/container/treap.d:224
#10 0x00b24161 in rt.util.container.treap() (dg=..., node=0x2c35530) at
src/rt/util/container/treap.d:224
#11 0x00b24161 in rt.util.container.treap() (dg=..., node=0x1a85a40) at
src/rt/util/container/treap.d:224
#12 0x00b23d93 in rt.util.container.treap() (this=..., dg=...) at
src/rt/util/container/treap.d:52
#13 0x00b23d2f in rt.util.container.treap() (this=..., dg=...) at
src/rt/util/container/treap.d:47
#14 0x00b18870 in gc.impl.conservative() (this=..., nostack=false) at
src/gc/impl/conservative/gc.d:2185
#15 0x00b19336 in gc.impl.conservative() (this=..., nostack=false) at
src/gc/impl/conservative/gc.d:2417
#16 0x00b17479 in gc.impl.conservative() (this=..., bits=0,
alloc_size=@0x7fff9e08: 32, bin=1 '\001') at
src/gc/impl/conservative/gc.d:1711
#17 0x00b1730a in gc.impl.conservative() (this=..., bits=0,
alloc_size=@0x7fff9e08: 32, size=32) at src/gc/impl/conservative/gc.d:1676
#18 0x00b152a1 in gc.impl.conservative() (this=0xf4a250, ti=0xeb0300
,
alloc_size=@0x7fff9e08: 32, bits=0, size=32) at
src/gc/impl/conservative/gc.d:517
#19 0x00b1b35e in gc.impl.conservative() (this=0xf4a250,
_param_3=@0x7fff9e28: 0xeb0300
,
_param_2=@0x7fff9e08: 32, _param_1=@0x7fff9e30: 0,
_param_0=@0x7fff9e38: 32) at src/gc/impl/conservative/gc.d:390
#20 0x00b15343 in gc.impl.conservative() (this=0xf4a250,
__HID11=0x7fff9ee8, ti=0xeb0300
,
bits=0, size=32) at src/gc/impl/conservative/gc.d:543
#21 0x00ac8957 in gc_qalloc (__HID9=0x7fff9ee8, sz=32, ba=0,
ti=0xeb0300
)
at src/gc/proxy.d:144
#22 0x00ac8163 in core.memory.GC.qalloc() (__HID2=0x7fff9ee8,
ti=0xeb0300
,
ba=0, sz=32) at src/core/memory.d:406
#23 0x00b1eab6 in _d_newitemU (_ti=0xeb0300
)
at src/rt/lifetime.d:1102
#24 0x00acc0f9 in _d_newitemiT (_ti=0xeb0300
)
at src/rt/lifetime.d:1124
#25 0x0099c31c in std.array() (this=..., arr=...) at
/home/circleci/dmd/generated/linux/debug/64/../../../../../phobos/std/array.d:2884
#26 0x0099c21c in std.array() () at
/home/circleci/dmd/generated/linux/debug/64/../../../../../phobos/std/array.d:3406
#27 0x009a8a9c in std.array() (r=...) at
/home/circleci/dmd/generated/linux/debug/64/../../../../../phobos/std/array.d:133
#28 0x00a9f3f0 in
dscanner.analysis.mismatched_args.MismatchedArgumentCheck.visit()
(this=0x77fda7c0, fce=0x1683be8) at

Re: D compiles fast, right? Right??

[Jonathan M Davis via Digitalmars-d]

On Tuesday, April 03, 2018 21:08:48 Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 04/03/2018 05:53 PM, bachmeier wrote:
> > On Tuesday, 3 April 2018 at 21:17:35 UTC, Rubn wrote:
> >> I feel that's probably the case for any comparisons across two
> >> languages, you are going to have a person that is more knowledgeable
> >> in one language than another. Mistakes are going to be made, but I
> >> think it should be blatantly obvious that one language is going to
> >> compiler slower if it is compiling all the unittests for a library
> >> compared to one that isn't. That's just blatant bias against D, not a
> >> mistake from misunderstanding Go.
> >
> > Yeah, I don't understand that either. Unit tests can be arbitrarily
> > large, so no matter how fast the compiler, it would always be possible
> > to make it take longer than any other language.
>
> Exactly, which is why I'm insisting this - and not compiler
> benchmarking, let alone idle chattaroo in the forums - is where we need
> to hit. What we have here, ladies and gentlemen, is a high-impact
> preapproved item of great general interest. Shall we start the auction?

Steven already said somewhere in here that he's planning to work on this
during the dconf hackathon. So, at least one person has stepped forward and
said that they'll look into it.

- Jonathan M Davis

[Issue 18688] Constructors shouldn't have implicit super call if it throws

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---
   Severity|enhancement |normal

--- Comment #3 from Walter Bright  ---
The real problem is that delegating constructor calls are not allowed after
labels, and the case and default statements are labels. The compiler should
detect those.

The trouble with labels is the primitive flow analysis done by the compiler
cannot handle them. So they are just disallowed. Maybe a future enhancement
could cover it.

--

Re: D compiles fast, right? Right??

[Andrei Alexandrescu via Digitalmars-d]

On 04/03/2018 05:53 PM, bachmeier wrote:

On Tuesday, 3 April 2018 at 21:17:35 UTC, Rubn wrote:
I feel that's probably the case for any comparisons across two 
languages, you are going to have a person that is more knowledgeable 
in one language than another. Mistakes are going to be made, but I 
think it should be blatantly obvious that one language is going to 
compiler slower if it is compiling all the unittests for a library 
compared to one that isn't. That's just blatant bias against D, not a 
mistake from misunderstanding Go.


Yeah, I don't understand that either. Unit tests can be arbitrarily 
large, so no matter how fast the compiler, it would always be possible 
to make it take longer than any other language.


Exactly, which is why I'm insisting this - and not compiler 
benchmarking, let alone idle chattaroo in the forums - is where we need 
to hit. What we have here, ladies and gentlemen, is a high-impact 
preapproved item of great general interest. Shall we start the auction?

CPUblit v0.1.0

[solidstate1991 via Digitalmars-d-announce]

https://github.com/ZILtoid1991/CPUblit

I have put the rendering functions of my engine to an external 
library for general use in other applications where image 
composing is needed.


I can add functions on request, currently I'm planning more 
functions for drawing and higher-level functions, with no much 
plans on direction with the latter one other than minimizing 
external dependencies and avoiding the use of the garbage 
collector and even possibly classes.

Re: D compiles fast, right? Right??

[Jonathan Marler via Digitalmars-d]

On Tuesday, 3 April 2018 at 23:29:34 UTC, Atila Neves wrote:

On Tuesday, 3 April 2018 at 19:07:54 UTC, Jonathan Marler wrote:

On Tuesday, 3 April 2018 at 10:24:15 UTC, Atila Neves wrote:
On Monday, 2 April 2018 at 18:52:14 UTC, Jonathan Marler 
wrote:






You still missed my point.


I got your point. I'm disagreeing.



I don't know why you keep saying you are "disagreeing" with me.  
It looks like we agree.  You're example is showing that DLANG's 
std.path compiles slower than GO's path library.  I agree.  All I 
was saying is that this example doesn't show that GO code 
compiles faster than D.  That was my one and only point.

Re: code-d 0.17.0 + serve-d 0.1.2

[Mike Franklin via Digitalmars-d-announce]

On Tuesday, 3 April 2018 at 23:50:24 UTC, Arredondo wrote:
I could not get this to work for me in the past (I'm using 
Windows 10). I saw this announcement so I decided to try again.


I'm using it in Windows 10 right now, but I did have trouble 
trying to upgrade an existing installation.  To remedy that, try 
to first delete the %appdata%\code-d directory, and then open VS 
Code again.  It should try to re-install serve-d, and I believe 
it will then succeed.


mike

Re: D compiles fast, right? Right??

[Jonathan M Davis via Digitalmars-d]

On Tuesday, April 03, 2018 16:15:35 H. S. Teoh via Digitalmars-d wrote:
> On Tue, Apr 03, 2018 at 10:59:13PM +, Atila Neves via Digitalmars-d 
wrote:
> > On Tuesday, 3 April 2018 at 20:47:48 UTC, Kagamin wrote:
> > > On Friday, 30 March 2018 at 16:12:44 UTC, Atila Neves wrote:
> > > > * Building a whole project in C++ still takes a lot longer since D
> > > > scales much better, but that's not my typical worflow, nor should
> > > > it be anyone else's.
> > >
> > > I can write code for days without even saving :)
> >
> > That sentence might as well be fingernails on a blackboard for me! I
> > save compulsively. Whenever I stop typing, C-x C-s it is for me.
>
> [...]
>
> Yeah, after having lost valuable work more often than I'd care to admit
> due to unexpected power outages and other hardware problems, I've
> developed a compulsive twitch in my fingers that automatically saves my
> file every other minute.  It has become so automatic that it's basically
> unconscious now.  I can't imagine not saving for long periods of time.

LOL. I save probably closer to every ten seconds, though I'm not sure
exactly how often it is because of how automatic it is. It's highly
dependent on when I finish a set of commands in vim, so with code, I tend to
save _very_ frequently, whereas with text, it's a lot less frequent, because
there, I often stay in insert mode for while. In addition to just generally
being a good idea, it eliminates the need for vim's swap files, and I hate
it when programs create files like that (be it to restore what you didn't
save when the program crashes or as a backup file every time you save). The
file is what is on disk, and I don't want the program trying to keep track
of unsaved data or old data and make it easy for me to restore it when my
computer crashes. That's what saving is for, and if I want older versions,
I'll use source control. But I guess that there are folks who do a lot of
typing without saving. I sure couldn't though.

Now, it is true that I frequently write a lot of code before bothering to
compile anything - not days worth at a time though.

- Jonathan M Davis

Re: code-d 0.17.0 + serve-d 0.1.2

[Arredondo via Digitalmars-d-announce]

I could not get this to work for me in the past (I'm using 
Windows 10). I saw this announcement so I decided to try again. 
After reinstalling code-d I got this in the OUTPUT console:


Installing DCD
Installing into C:\Users\Wulfrick\AppData\Roaming\code-d\bin
 > git clone --recursive --depth=1 
https://github.com/Hackerpilot/DCD.git DCD

Failed to install DCD
std.process.ProcessException@std\process.d(753): Failed to spawn 
new process (The system cannot find the file specified.)


0x00384D1F
0x00384AD2
0x00382ADD

The syntax coloring seems wrong, go to definition doesn't work, 
and there are no completition suggestions (Ctr+Space just 
displays "Loading...").


Moreover, the extension is completely SPAMMING the output 
console, making it pop up constantly with endless messages like:



2018-04-04T01:33:46.184:source\served\jsonrpc.d:send:66 
{"id":27,"jsonrpc":"2.0","result":{"command":{"arguments":[],"command":"","title":"~30ms for importing this"},"data":{"code":"import std.algorithm.iteration : sum;","module":"std.algorithm.iteration","type":"importcompilecheck"},"range":{"end":{"character":4,"line":245},"start":{"character":4,"line":245

2018-04-04T01:33:46.184:source\app.d:main:226 Has Message
2018-04-04T01:33:46.184:source\app.d:main:228 Message: 
RequestMessage(28, "codeLens/resolve", {"data":{"code":"import 
std.algorithm.comparison : 
max;","module":"std.algorithm.comparison","type":"importcompilecheck"},"range":{"end":{"character":4,"line":250},"start":{"character":4,"line":250}}})
2018-04-04T01:33:46.200:source\app.d:__lambda10:234 Processing as 
request
2018-04-04T01:33:46.200:source\app.d:processRequest:77 Calling 
resolveCodeLens
2018-04-04T01:33:46.200:source\app.d:__lambda10:236 Responding 
with: ResponseMessage(28, 
{"command":{"arguments":[],"command":"","title":"~280ms for 
importing this"},"data":{"code":"import std.algorithm.comparison 
: 
max;","module":"std.algorithm.comparison","type":"importcompilecheck"},"range":{"end":{"character":4,"line":250},"start":{"character":4,"line":250}}}, null(ResponseError))
2018-04-04T01:33:46.200:source\served\jsonrpc.d:send:66 
{"id":28,"jsonrpc":"2.0","result":{"command":{"arguments":[],"command":"","title":"~280ms for importing this"},"data":{"code":"import std.algorithm.comparison : max;","module":"std.algorithm.comparison","type":"importcompilecheck"},"range":{"end":{"character":4,"line":250},"start":{"character":4,"line":250

2018-04-04T01:33:46.200:source\app.d:main:226 Has Message
2018-04-04T01:33:46.200:source\app.d:main:228 Message: 
RequestMessage(29, "codeLens/resolve", {"data":{"code":"import 
std.range : 
iota;","module":"std.range","type":"importcompilecheck"},"range":{"end":{"character":4,"line":251},"start":{"character":4,"line":251}}})
2018-04-04T01:33:46.216:source\app.d:__lambda10:234 Processing as 
request
2018-04-04T01:33:46.216:source\app.d:processRequest:77 Calling 
resolveCodeLens
2018-04-04T01:33:46.216:source\app.d:__lambda10:236 Responding 
with: ResponseMessage(29, 
{"command":{"arguments":[],"command":"","title":"~290ms for 
importing this"},"data":{"code":"import std.range : 
iota;","module":"std.range","type":"importcompilecheck"},"range":{"end":{"character":4,"line":251},"start":{"character":4,"line":251}}}, null(ResponseError))






... and it goes like this for a while. This is at the very bottom:





[Info  - 1:33:54 AM] Connection to server got closed. Server will 
restart.

[Error - 1:33:54 AM] Request textDocument/codeLens failed.
Error: Connection got disposed.
	at Object.dispose 
(C:\Users\Wulfrick\.vscode\extensions\webfreak.code-d-0.17.0\node_modules\vscode-jsonrpc\lib\main.js:825:25)
	at Object.dispose 
(C:\Users\Wulfrick\.vscode\extensions\webfreak.code-d-0.17.0\node_modules\vscode-languageclient\lib\client.js:57:35)
	at LanguageClient.handleConnectionClosed 
(C:\Users\Wulfrick\.vscode\extensions\webfreak.code-d-0.17.0\node_modules\vscode-languageclient\lib\client.js:1864:38)
	at LanguageClient.handleConnectionClosed 
(C:\Users\Wulfrick\.vscode\extensions\webfreak.code-d-0.17.0\node_modules\vscode-languageclient\lib\main.js:106:15)
	at closeHandler 
(C:\Users\Wulfrick\.vscode\extensions\webfreak.code-d-0.17.0\node_modules\vscode-languageclient\lib\client.js:1852:18)
	at CallbackList.invoke 
(C:\Users\Wulfrick\.vscode\extensions\webfreak.code-d-0.17.0\node_modules\vscode-jsonrpc\lib\events.js:71:39)
	at Emitter.fire 
(C:\Users\Wulfrick\.vscode\extensions\webfreak.code-d-0.17.0\node_modules\vscode-jsonrpc\lib\events.js:135:36)
	at closeHandler 
(C:\Users\Wulfrick\.vscode\extensions\webfreak.code-d-0.17.0\node_modules\vscode-jsonrpc\lib\main.js:221:26)
	at CallbackList.invoke 
(C:\Users\Wulfrick\.vscode\extensions\webfreak.code-d-0.17.0\node_modules\vscode-jsonrpc\lib\events.js:71:39)
	at Emitter.fire 
(C:\Users\Wulfrick\.vscode\extensions\webfreak.code-d-0.17.0\node_modules\vscode-jsonrpc\lib\events.js:135:36)

[Error - 1:33:54 AM] Request textDocument/codeAction failed.
Error: 

Re: D compiles fast, right? Right??

[Marco Leise via Digitalmars-d]

Am Tue, 3 Apr 2018 16:15:35 -0700
schrieb "H. S. Teoh" :

> On Tue, Apr 03, 2018 at 10:59:13PM +, Atila Neves via Digitalmars-d wrote:
> > That sentence might as well be fingernails on a blackboard for me! I
> > save compulsively. Whenever I stop typing, C-x C-s it is for me.  
> 
> […] I can't imagine not saving for long periods of time.

Me too, but for me it was Delphi 2005/2006 with frequent IDE
crashes that had me start doing this and dmd eating into swap
memory when I write messy CTFE code that keeps me doing
Ctrl+S before before any action that has any likelihood to
stall the system. I also don't trust my own code.

-- 
Marco

Re: D compiles fast, right? Right??

[H. S. Teoh via Digitalmars-d]

On Tue, Apr 03, 2018 at 11:09:10PM +, burjui via Digitalmars-d wrote:
[...]
> H. S. Teoh is not the only one here cringing at "fast code fast" on
> the main page. I use D from time to time for over 10 years now, and
> even used it at work and it was a relatively positive experience,
> thanks to vibe.d. But compilation times are just horrible - minimum 3
> seconds for a 1500 lines project (on a 8-core 4GHz CPU with 16 GB
> RAM), and that's after I ditched std.regex, made all imports qualified
> (didn't help that much, though) and switched to ld.gold.

3 seconds for 1500 lines?  Is that because you're using dub with its
unbearably slow compulsive network lookups?  Or because you imported
monsters like std.format?  Or because you have heavily-templated code?
Vibe.d is pretty heavy on templates (Diet templates, while pretty cool
from a geekiness POV, also slow things down like a hog because of heavy
template + CTFE usage).

Also, which compiler version did you use?  If you use nested templates
heavily (like UFCS chains of ranges), in older releases you may have run
into the exponential symbol size problem, where most of the compilation
time is spent generating, looking up, and reading symbols that are tens
of megabytes long.  After Rainers' symbol compression PR was merged,
compilation times on such code was hugely improved. As of a release or
two ago, this is no longer a problem.

I've noticed that if I don't use certain slow things, dmd is actually
lightning fast at compiling up to several thousand LOCs.  But as soon as
std.format enters the picture, or if you have recursive templates or
heavy CTFE, it rapidly deteriorates.  (Note, though, that relatively
simple template code doesn't significantly slow things down; it's when
you start doing things like manipulating type tuples AKA AliasSeq's,
recursive templates, compile-time loops like static foreach over
introspection, heavy CTFE, that things start grinding. Simple
parametrized types are still lightning fast, and last time I checked a
lot faster than, say, equivalent C++ code compiled with g++.)


> And I would be ok with slow compilation if DMD was smart enough, doing
> some graph magic, like extensive control flow analysis, and insane
> optimizations, but it doesn't. For example, Rust compilation times are
> no picnic either, but it's obvious why - you get nice good-looking
> error messages, tons of useful warnings and very fast programs free of
> memory corruption bugs. It's not the case with DMD, though. The
> language may be better than C++, but it's fastest compiler is slower
> and produces worse code? I'd rather not boast about speed at the main
> page in this situation.  And god save us from ridicule by Goers.

These days, I don't even look at benchmarks of dmd-compiled code
anymore.  For anything even remotely performance-related, I look at
gdc/ldc.  They do compile noticeably slower than dmd, but with the huge
benefit of far superior backends that gives me top runtime performance.

If Andrei & Walter are serious about this "fast code fast" thing, then
we'd better get our act together and do some serious optimization work,
both on the compiler itself, and on the quality of its codegen.


T

-- 
Bomb technician: If I'm running, try to keep up.

Re: D compiles fast, right? Right??

[Atila Neves via Digitalmars-d]

On Tuesday, 3 April 2018 at 19:07:54 UTC, Jonathan Marler wrote:

On Tuesday, 3 April 2018 at 10:24:15 UTC, Atila Neves wrote:

On Monday, 2 April 2018 at 18:52:14 UTC, Jonathan Marler wrote:





You still missed my point.


I got your point. I'm disagreeing.


You're post was saying that "D does not compile as fast as GO".


Please show me where in my post where you think I said that.


But the libraries you're comparing are vastly different.


Their sizes are different. I disagree that they're vastly 
different.


If you're post was saying, "dlang's std.path compiles much 
slower than GO's" then you would be fine.


That is exactly what I said.

However, you're post was misleading saying the Go compile's 
faster than D in general,


I never said that.

and I was pointing out that the use case you provided doesn't 
apply in the general case,


Maybe it applies in the general case, maybe it doesn't. I have no 
idea.


it only applies to a library with the same name/type of 
functionality.


I don't know about “only".


You're totally misunderstanding me.  I was just saying that if 
you want to compare the compile speed of D vs GO (IN THE 
GENERAL CASE), you should not include the unittests in D's 
performance because you weren't including them in your GO 
example.


Include what? The Go standard library's own tests? libstdc++'s?

All the code I compiled was in that post. The only reason the Go 
file isn't just a one liner is because the silly opinionated 
language won't let me.


I showed how long it takes to compile the minimum amount of code 
necessary to import the part of the standard library responsible 
for paths in 3 languages. Then I showed how much slower it got in 
D with -unittest on the exact same one liner.


There isn't an equivalent in Go or C++. And yet one can write 
tests in them. And when one does, the compile-time penalty is 0.


What I am arguing against is that your example is not evidence 
that GO compiles faster than D in general.


I have no idea why you're arguing against something I never 
stated.


You're example is comparing 2 different libraries in 2 
different languages, not about the languages themselves.


No, I compared importing path functionality in files that did 
nothing else (except for some dummy code in Go) in *3* different 
languages. Then I showed that compiling the one liner in D with 
-unittest was slower than C++ by just a bit and nearly 50 slower 
than Go. With no actual tests in sight.

Re: D compiles fast, right? Right??

[H. S. Teoh via Digitalmars-d]

On Tue, Apr 03, 2018 at 10:59:13PM +, Atila Neves via Digitalmars-d wrote:
> On Tuesday, 3 April 2018 at 20:47:48 UTC, Kagamin wrote:
> > On Friday, 30 March 2018 at 16:12:44 UTC, Atila Neves wrote:
> > > * Building a whole project in C++ still takes a lot longer since D
> > > scales much better, but that's not my typical worflow, nor should
> > > it be anyone else's.
> > 
> > I can write code for days without even saving :)
> 
> That sentence might as well be fingernails on a blackboard for me! I
> save compulsively. Whenever I stop typing, C-x C-s it is for me.
[...]

Yeah, after having lost valuable work more often than I'd care to admit
due to unexpected power outages and other hardware problems, I've
developed a compulsive twitch in my fingers that automatically saves my
file every other minute.  It has become so automatic that it's basically
unconscious now.  I can't imagine not saving for long periods of time.


T

-- 
All men are mortal. Socrates is mortal. Therefore all men are Socrates.

[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.

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

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

--- Comment #26 from Artem Borisovskiy  ---
Buckle up for celebration of 10 year anniversary and don't forget flowers for
Walter.

--

Re: D compiles fast, right? Right??

[burjui via Digitalmars-d]

Atila laid it out pretty clear: he doesn't care about the 
differences, he wants the work to be done. And I'm with him on 
that. Go and it's standard library may be way simpler, but it 
get's the job done (which is trivial in both cases, by the way) 
almost instantaneously, which is a much bigger deal than it seems 
to be. When your edit-compile cycle is that fast, it changes the 
way you write code, you develop a habit of writing smaller pieces 
of code and testing them more frequently. Remember that Linus 
Torvalds' talk about Git at Google?

https://www.youtube.com/watch?v=4XpnKHJAok8=3025

H. S. Teoh is not the only one here cringing at "fast code fast" 
on the main page. I use D from time to time for over 10 years 
now, and even used it at work and it was a relatively positive 
experience, thanks to vibe.d. But compilation times are just 
horrible - minimum 3 seconds for a 1500 lines project (on a 
8-core 4GHz CPU with 16 GB RAM), and that's after I ditched 
std.regex, made all imports qualified (didn't help that much, 
though) and switched to ld.gold. And I would be ok with slow 
compilation if DMD was smart enough, doing some graph magic, like 
extensive control flow analysis, and insane optimizations, but it 
doesn't. For example, Rust compilation times are no picnic 
either, but it's obvious why - you get nice good-looking error 
messages, tons of useful warnings and very fast programs free of 
memory corruption bugs. It's not the case with DMD, though. The 
language may be better than C++, but it's fastest compiler is 
slower and produces worse code? I'd rather not boast about speed 
at the main page in this situation. And god save us from ridicule 
by Goers.

code-d 0.17.0 + serve-d 0.1.2

[WebFreak001 via Digitalmars-d-announce]

new code-d (D extension for vscode) and serve-d (Language Server 
Protocol server for it) release


See the CHANGELOG in vscode, or on 
https://github.com/Pure-D/code-d/blob/master/CHANGELOG.md


Today massive improvements towards windows installation have been 
made and it should be a lot more painless now.


Big thanks to Mike Franklin for helping me debug the windows 
installation, making this available very quickly and to p0nce for 
compiling the windows release because my VM wasn't working for 
this anymore.


As now the extension is in stable and no longer requires the beta 
branch a lot of issues have been fixed and old ones which are 
probably no longer valid closed. If you find any issue please 
create a new one or reopen if you have an old issue.


Here are some of my personal highlights:

https://wfr.moe/fmEfTw.png - documentation inside autocompletion
https://wfr.moe/fmq4Da.png - import timing
https://wfr.moe/fmqCNt.png https://wfr.moe/fmqh3H.png - simple 
implement interface action
n/a - everything compiles and installs without reloads or 
cumbersome dialogs, just install from marketplace, wait for the 
installation which should be very quick, especially with prebuilt 
binaries and start coding without any distractions!

https://wfr.moe/fmzcS8.png - dub dependency browser
n/a - automatic insertion of a module statement on rename and 
file creation


code-d beta and code-d are therefore on the same release right 
now, but code-d beta will still be continuing to get features 
early.


eager to hear your feedback, though gonna go to sleep for now.

Planned for next release is internationalizing the final few 
messages which are in the code-d part, all serve-d parts have 
already been translated to German and Japanese and are determined 
by vscode language.

Re: D compiles fast, right? Right??

[Atila Neves via Digitalmars-d]

On Tuesday, 3 April 2018 at 21:53:35 UTC, bachmeier wrote:

On Tuesday, 3 April 2018 at 21:17:35 UTC, Rubn wrote:
I feel that's probably the case for any comparisons across two 
languages, you are going to have a person that is more 
knowledgeable in one language than another. Mistakes are going 
to be made, but I think it should be blatantly obvious that 
one language is going to compiler slower if it is compiling 
all the unittests for a library compared to one that isn't. 
That's just blatant bias against D, not a mistake from 
misunderstanding Go.


Yeah, I don't understand that either. Unit tests can be 
arbitrarily large, so no matter how fast the compiler, it would 
always be possible to make it take longer than any other 
language.


There were 0 tests in my example.

Re: D compiles fast, right? Right??

[Atila Neves via Digitalmars-d]

On Tuesday, 3 April 2018 at 20:47:48 UTC, Kagamin wrote:

On Friday, 30 March 2018 at 16:12:44 UTC, Atila Neves wrote:
* Building a whole project in C++ still takes a lot longer 
since D scales much better, but that's not my typical worflow, 
nor should it be anyone else's.


I can write code for days without even saving :)


That sentence might as well be fingernails on a blackboard for 
me! I save compulsively. Whenever I stop typing, C-x C-s it is 
for me.



What's the point to compile code that's not supposed to work?


TDD.

[Issue 15621] std.file.rename does not allow moving files to a different drive

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

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

Jonathan Marler  changed:

   What|Removed |Added

 CC||johnnymar...@gmail.com

--

Re: D compiles fast, right? Right??

[bachmeier via Digitalmars-d]

On Tuesday, 3 April 2018 at 21:17:35 UTC, Rubn wrote:
I feel that's probably the case for any comparisons across two 
languages, you are going to have a person that is more 
knowledgeable in one language than another. Mistakes are going 
to be made, but I think it should be blatantly obvious that one 
language is going to compiler slower if it is compiling all the 
unittests for a library compared to one that isn't. That's just 
blatant bias against D, not a mistake from misunderstanding Go.


Yeah, I don't understand that either. Unit tests can be 
arbitrarily large, so no matter how fast the compiler, it would 
always be possible to make it take longer than any other language.

Re: Need a fancy domain for your project? .dub.pm has you covered!

[Seb via Digitalmars-d-announce]

On Tuesday, 3 April 2018 at 21:28:01 UTC, Tony wrote:
Not a big deal since the same table is on code.dlang.org, but 
on the https://dub.pm/index.htm table, the headings "Name", 
"Registered" and "Score" are all active links, but the sort is 
not currently working.


Yes, that's expected.
dub.pm is a __static__ page and we are currently in the progress 
of splitting up the documentation from code.dlang.org to dub.pm


See e.g. https://github.com/dlang/dub-registry/pull/308

Re: Deprecating this(this)

[ag0aep6g via Digitalmars-d]

On 04/03/2018 10:51 PM, Steven Schveighoffer wrote:

On 4/3/18 4:26 PM, ag0aep6g wrote:

[...]
If there's a problem with running two postblits on the same field, 
then I think constructors probably have similar issue. I'm having a 
hard time finding a good example, though. One where we could break 
immutable in an obvious way or some such.


You may NOT want to run a postblit on the member. If all you are going 
to do, for example, is reassign a variable, then running the postblit, 
and then the destructor, just so you can overwrite it is pointless.


Same with class constructors: You may not want to run `super` when 
you're just going to overwrite what it did. But the language doesn't 
give you a choice. It'll be called one way or another.


I'm not saying that imitating how constructors work will make the best 
possible copying mechanism. Something else might be superior in every 
way. It's just that so far the arguments against a constructor-like 
postblit also seem to apply to constructors as they are implemented.


So I'm thinking that a postblit modeled after constructors could work as 
well as they do. But maybe the real takeaway is that constructors don't 
work very well, and shouldn't be imitated.


But more importantly, if the postblit of the member does something crazy 
like stores a reference to itself as an immutable elsewhere, and then 
the compiler allows overwriting, we now have problems.


I'd love to see an example of this in code. The best I can come up with 
would be something like this (doesn't compile):



import std.stdio;

immutable(int)* p;

struct S
{
int x;
this(this) immutable
{
x = 42; /* First write. */
.p = 
writeln(p, " ", *p); /* Prints some address and 42. */
}
}

struct T
{
S s;
this(this) immutable
{
s = S(13); /* Second write. Breaking immutable? */
writeln(p, " ", *p); /* Same address, but 13. */
}
}

void main()
{
immutable T foo;
immutable bar = foo;
}


But that's essentially the same as the class example I posted. `*p` 
would only change values during the postblit run. Just like a 
constructor chain can write to the same field multiple times.


That's kinda iffy, but I can't find a way to demonstrate some real, 
obvious damage.


I think the better mechanism for immutable copying would be to have a 
copy constructor that starts off with T.init, and is passed the object 
to copy from. That seems to be a direction Andrei is considering.


No objection from me. If Andrei et al. can find a better solution, great.

Re: Need a fancy domain for your project? .dub.pm has you covered!

[Tony via Digitalmars-d-announce]

Not a big deal since the same table is on code.dlang.org, but on 
the https://dub.pm/index.htm table, the headings "Name", 
"Registered" and "Score" are all active links, but the sort is 
not currently working.

Re: D compiles fast, right? Right??

[Rubn via Digitalmars-d]

On Tuesday, 3 April 2018 at 19:07:54 UTC, Jonathan Marler wrote:

On Tuesday, 3 April 2018 at 10:24:15 UTC, Atila Neves wrote:

On Monday, 2 April 2018 at 18:52:14 UTC, Jonathan Marler wrote:
My point was that if you want to compare "compile-time" 
performance, you should not include the unittests in D's time 
since Go does not include unittests.


"Go does not include unittests"? Under some interpretations I 
guess that could be viewed as correct, but in practical terms 
I can write Go tests without an external library 
(https://golang.org/pkg/testing/)/ Whether it's a language 
keyword or not is irrelevant.


What _is_ relevant (to me) is that I can write Go code that 
manipulates paths and test it with everything building in less 
time that it takes to render a frame in a videogame, whereas 
in D...


You're totally misunderstanding me.  I was just saying that if 
you want to compare the compile speed of D vs GO (IN THE 
GENERAL CASE), you should not include the unittests in D's 
performance because you weren't including them in your GO 
example.


I feel that's probably the case for any comparisons across two 
languages, you are going to have a person that is more 
knowledgeable in one language than another. Mistakes are going to 
be made, but I think it should be blatantly obvious that one 
language is going to compiler slower if it is compiling all the 
unittests for a library compared to one that isn't. That's just 
blatant bias against D, not a mistake from misunderstanding Go.

Re: Deprecating this(this)

[Andrei Alexandrescu via Digitalmars-d]

On 04/03/2018 04:29 PM, ag0aep6g wrote:
But if postblit goes away for other reasons anyway (like the atomic copy 
thing, or another mechanism being simply superior), then there's no 
point in pursuing this, of course.


The DIP will definitely need to make a solid case supporting whatever it 
proposes.

Re: Deprecating this(this)

[Andrei Alexandrescu via Digitalmars-d]

On 04/03/2018 04:26 PM, ag0aep6g wrote:

On 04/03/2018 05:13 PM, Steven Schveighoffer wrote:
Unfortunately, I found out that it's not just "pre-filled with some 
values". Member postblits are run before the containing postblit.


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

So this means, the data that is available to the postblit has already 
been processed.


There's a similar situation with constructors: A constructor can call 
another constructor, which can lead to double initialization of fields.


Example:


class C
{
     int x;
     this() immutable
     {
     this(42); /* Initializes x. */
     x = 13; /* Breaking immutable, or ok? */
     }
     this(int x) immutable
     {
     this.x = x;
     }
}



Let's replace "int" with an UDT:

struct S
{
int x = -1;
this(int y) immutable { x = y; }
void opAssign(int) immutable;
}

class C
{
S x;
this() immutable
{
this(42); /* Initializes x. */
x = 13; /* Breaking immutable, or ok? */
}
this(int x) immutable
{
this.x = x;
}
}

This code compiles, and calls the constructor twice for the same object. 
Clearly that shouldn't be allowed to pass. I've submitted 
https://issues.dlang.org/show_bug.cgi?id=18719 - thanks! (The problem 
seems to occur even without immutable, it's endemic to forwarding 
constructors.)


Andre

[Issue 18719] New: Doubly-called constructor against member when using forwarding constructors

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

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

  Issue ID: 18719
   Summary: Doubly-called constructor against member when using
forwarding constructors
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

Consider:

struct S
{
int x = -1;
this(int y) immutable
{
x = y;
import std.stdio;
writeln("Ctor called with ", y);
}
void opAssign(int) immutable;
}

class C
{
S x;
this() immutable
{
this(42); /* Initializes x. */
x = 13; /* Breaking immutable, or ok? */
}
this(int x) immutable
{
this.x = x;
}
}

void main()
{
new immutable C;
}

The code prints:

Ctor called with 42
Ctor called with 13

Constructor should not be called twice against the same object.

--

Re: Deprecating this(this)

[Steven Schveighoffer via Digitalmars-d]

On 4/3/18 4:26 PM, ag0aep6g wrote:

On 04/03/2018 05:13 PM, Steven Schveighoffer wrote:
Unfortunately, I found out that it's not just "pre-filled with some 
values". Member postblits are run before the containing postblit.


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

So this means, the data that is available to the postblit has already 
been processed.


There's a similar situation with constructors: A constructor can call 
another constructor, which can lead to double initialization of fields.


Example:


class C
{
     int x;
     this() immutable
     {
     this(42); /* Initializes x. */
     x = 13; /* Breaking immutable, or ok? */


IMO, breaking immutable.


     }
     this(int x) immutable
     {
     this.x = x;
     }
}


If there's a problem with running two postblits on the same field, then 
I think constructors probably have similar issue. I'm having a hard time 
finding a good example, though. One where we could break immutable in an 
obvious way or some such.


You may NOT want to run a postblit on the member. If all you are going 
to do, for example, is reassign a variable, then running the postblit, 
and then the destructor, just so you can overwrite it is pointless.


But more importantly, if the postblit of the member does something crazy 
like stores a reference to itself as an immutable elsewhere, and then 
the compiler allows overwriting, we now have problems.


I think the better mechanism for immutable copying would be to have a 
copy constructor that starts off with T.init, and is passed the object 
to copy from. That seems to be a direction Andrei is considering.


-Steve

Re: D compiles fast, right? Right??

[Kagamin via Digitalmars-d]

On Friday, 30 March 2018 at 16:12:44 UTC, Atila Neves wrote:
* Building a whole project in C++ still takes a lot longer 
since D scales much better, but that's not my typical worflow, 
nor should it be anyone else's.


I can write code for days without even saving :)
What's the point to compile code that's not supposed to work?

Re: is this even possible? newbie + mixin template + foreach (allMembers)

[Seb via Digitalmars-d-learn]

On Tuesday, 3 April 2018 at 18:49:00 UTC, Carlos Navarro wrote:

QUESTION:

Obviously I'm no geting mixins/templates nor traits and I'm 
failing miserably to find/identify the right examples or 
documentation to help me tackle this thing. What is wrong in 
this code? is this pattern sintactically possible? what I'm 
getting wrong?


[...]


ICEs (compiler segfault) should _always_ be reported on Bugzilla. 
The compiler should never ever segfault - even on invalid code.


I just did so for you: 
https://issues.dlang.org/show_bug.cgi?id=18718

[Issue 18718] New: ICE in dmd/traits.d:417

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

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

  Issue ID: 18718
   Summary: ICE in dmd/traits.d:417
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: ice, ice-on-invalid-code
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

Reduced example (from
https://forum.dlang.org/post/uulshsgxovbrrctvd...@forum.dlang.org)

---
struct World {
mixin BuildStuff;
}

template BuildStuff() {
static foreach(elem; __traits(allMembers, typeof(this))) {

}
}
---

Stacktrace:

---
0x558ba0eb in semanticTraits(TraitsExp*, Scope*) (e=0x0, sc=0x0) at
dmd/traits.d:417
417 extern (C++) Expression semanticTraits(TraitsExp e, Scope* sc)
#0  0x558ba0eb in semanticTraits(TraitsExp*, Scope*) (e=0x0, sc=0x0) at
dmd/traits.d:417
#1  0x55824dbd in ExpressionSemanticVisitor::visit(TraitsExp*)
(this=0x7f7ff238, e=0x76971ad0) at dmd/expressionsem.d:3791
#2  0x55812c32 in TraitsExp::accept(Visitor*) (this=0x76971ad0,
v=0x7f7ff238) at dmd/expression.d:4743
#3  0x55834f4f in expressionSemantic(Expression*, Scope*)
(e=0x76971ad0, sc=0x76857e40) at dmd/expressionsem.d:9367
#4  0x5578ec45 in
_D3dmd4cond13StaticForeach7prepareMFPSQBk6dscope5ScopeZv (this=0x769719e0,
sc=0x76857e40) at dmd/cond.d:385
#5  0x55787714 in StaticForeachDeclaration::include(Scope*)
(this=0x76971940, sc=0x76857d10) at dmd/attrib.d:1083
#6  0x557de39b in
_D3dmd7dsymbol12ScopeDsymbol8_foreachFPSQBm6dscope5ScopePSQCe4root5array__T5ArrayTCQDdQDc7DsymbolZQxMDFmQwZiPmZi
(pn=0x7f7ff3c8, dg=..., members=0x76971920, sc=0x76857d10) at
dmd/dsymbol.d:1666
#7  0x557de3ef in
_D3dmd7dsymbol12ScopeDsymbol8_foreachFPSQBm6dscope5ScopePSQCe4root5array__T5ArrayTCQDdQDc7DsymbolZQxMDFmQwZiPmZi
(pn=0x0, dg=..., members=0x77e9f500, sc=0x76857d10) at
dmd/dsymbol.d:1668
#8  0x558bc8c1 in semanticTraits(TraitsExp*, Scope*) (e=0x76971ad0,
sc=0x76857d10) at dmd/traits.d:1335
#9  0x55824dbd in ExpressionSemanticVisitor::visit(TraitsExp*)
(this=0x7f7ffcc8, e=0x76971ad0) at dmd/expressionsem.d:3791
#10 0x55812c32 in TraitsExp::accept(Visitor*) (this=0x76971ad0,
v=0x7f7ffcc8) at dmd/expression.d:4743
#11 0x55834f4f in expressionSemantic(Expression*, Scope*)
(e=0x76971ad0, sc=0x76857d10) at dmd/expressionsem.d:9367
#12 0x5578ec45 in
_D3dmd4cond13StaticForeach7prepareMFPSQBk6dscope5ScopeZv (this=0x769719e0,
sc=0x76857d10) at dmd/cond.d:385
#13 0x55787714 in StaticForeachDeclaration::include(Scope*)
(this=0x76971940, sc=0x76857be0) at dmd/attrib.d:1083
#14 0x557de39b in
_D3dmd7dsymbol12ScopeDsymbol8_foreachFPSQBm6dscope5ScopePSQCe4root5array__T5ArrayTCQDdQDc7DsymbolZQxMDFmQwZiPmZi
(pn=0x7f7ffe58, dg=..., members=0x76971920, sc=0x76857be0) at
dmd/dsymbol.d:1666
#15 0x557de3ef in
_D3dmd7dsymbol12ScopeDsymbol8_foreachFPSQBm6dscope5ScopePSQCe4root5array__T5ArrayTCQDdQDc7DsymbolZQxMDFmQwZiPmZi
(pn=0x0, dg=..., members=0x77e9f500, sc=0x76857be0) at
dmd/dsymbol.d:1668
---

--

Re: Better way to append to array than ~= ?

[Alex via Digitalmars-d-learn]

On Tuesday, 3 April 2018 at 20:02:46 UTC, Vladimirs Nordholm 
wrote:

On Tuesday, 3 April 2018 at 19:53:11 UTC, Meta wrote:
On Tuesday, 3 April 2018 at 19:02:25 UTC, Vladimirs Nordholm 
wrote:

[...]


In this specific case, since you know the length of `Args`, 
you can pre-allocate an array of that size and loop through it 
doing your initialization.


However, if you want really performant code, you should 
allocate a static array on the stack outside of the function 
and pass it in as a buffer.


I don't think I know the size of the arguments.

If I pass in "123" and MySpecialType('a'), the result should be:

assert(foo("123", MySpecialType('a')) == 
[MySpecialType('1'), MySpecialType('2'), MySpecialType('3'), 
MySpecialType('a')]);


What should the length of the pre-allocated array be?


In my try, I iterate the args twice. The first time to calculate 
the number of elements, then preallocate and then iterate them 
again and constructing the proper objects.


It is not nice, but about 1/3 of time, compared to original 
version, compiled in release mode.


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

[Issue 11938] "Ifti!T" for std.traits

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--

Re: Better way to append to array than ~= ?

[Meta via Digitalmars-d-learn]

On Tuesday, 3 April 2018 at 20:02:46 UTC, Vladimirs Nordholm 
wrote:

On Tuesday, 3 April 2018 at 19:53:11 UTC, Meta wrote:
On Tuesday, 3 April 2018 at 19:02:25 UTC, Vladimirs Nordholm 
wrote:

[...]


In this specific case, since you know the length of `Args`, 
you can pre-allocate an array of that size and loop through it 
doing your initialization.


However, if you want really performant code, you should 
allocate a static array on the stack outside of the function 
and pass it in as a buffer.


I don't think I know the size of the arguments.

If I pass in "123" and MySpecialType('a'), the result should be:

assert(foo("123", MySpecialType('a')) == 
[MySpecialType('1'), MySpecialType('2'), MySpecialType('3'), 
MySpecialType('a')]);


What should the length of the pre-allocated array be?


You know the static types of the arguments, so it is not 
impossible. However, the more flexible you need to be, the more 
complex your code will have to be, and it probably won't be worth 
the added complexity. Anyway, sorry for derailing a bit. That's 
not really your question.


Using Appender!MySpecialType might be marginally faster than ~=, 
but from the looks of it you are already using Appender. I don't 
know if there's much more you can do to speed up appending 
without just rolling your own solution or restructuring your code.

Re: Deprecating this(this)

[ag0aep6g via Digitalmars-d]

On 04/03/2018 08:57 PM, Andrei Alexandrescu wrote:
Well... not really. This is because .init is really an inert state - 
null indirections, no state allocated etc.


.init can have non-null indirections:

struct S { int[] a = [1, 2, 3]; }
static assert(S.init.a.ptr !is null); /* passes */

But maybe it shouldn't. It leads to problems with immutable, because the 
same .init with the same `a` is used for both mutable and immutable 
objects. https://issues.dlang.org/show_bug.cgi?id=10376


As far as I see, a const/immutable postblit working like a constructor 
wouldn't have that particular problem, because the copy is always made 
from another const/immutable object, so there wouldn't be aliasing with 
mutable data.


But there might of course be other problems with indirections, which I 
don't see right now. I'd love to see any examples, though. They probably 
reveal weaknesses in .init/constructors, too.


Makes typechecking easy, and 
calling constructor on top of .init is what happens already. In 
contrast, the postblit situash is very different - the fields already 
contain "interesting" data, allocated resources etc. Calling a 
constructor on top of that is not defined.


Well, the idea would be to define it. But if postblit goes away for 
other reasons anyway (like the atomic copy thing, or another mechanism 
being simply superior), then there's no point in pursuing this, of course.

Re: Deprecating this(this)

[ag0aep6g via Digitalmars-d]

On 04/03/2018 05:13 PM, Steven Schveighoffer wrote:
Unfortunately, I found out that it's not just "pre-filled with some 
values". Member postblits are run before the containing postblit.


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

So this means, the data that is available to the postblit has already 
been processed.


There's a similar situation with constructors: A constructor can call 
another constructor, which can lead to double initialization of fields.


Example:


class C
{
int x;
this() immutable
{
this(42); /* Initializes x. */
x = 13; /* Breaking immutable, or ok? */
}
this(int x) immutable
{
this.x = x;
}
}


If there's a problem with running two postblits on the same field, then 
I think constructors probably have similar issue. I'm having a hard time 
finding a good example, though. One where we could break immutable in an 
obvious way or some such.


It would only make sense to allow const postblits to have the same 
constructor mechanism if the members all had no postblits.


Less drastically, we could also disallow writing to those fields that 
have their own postblit.


The analog with constructors would be disallowing writing to fields that 
have already been initialized by an implicit `super` call. Actually, 
that seems to be how it works, kinda-sorta:



class C
{
int x;
}

class D : C
{
int y;
this() immutable
{
y = 1; /* accepted */
x = 2; /* Error: cannot modify this.x in immutable function */
}
}


Obviously, DMD doesn't check what C's constructor actually does (because 
it generally can't check that). It just considers initializing x to be 
C's responsibility.

Re: Better way to append to array than ~= ?

[Vladimirs Nordholm via Digitalmars-d-learn]

On Tuesday, 3 April 2018 at 19:53:11 UTC, Meta wrote:
On Tuesday, 3 April 2018 at 19:02:25 UTC, Vladimirs Nordholm 
wrote:

[...]


In this specific case, since you know the length of `Args`, you 
can pre-allocate an array of that size and loop through it 
doing your initialization.


However, if you want really performant code, you should 
allocate a static array on the stack outside of the function 
and pass it in as a buffer.


I don't think I know the size of the arguments.

If I pass in "123" and MySpecialType('a'), the result should be:

assert(foo("123", MySpecialType('a')) == [MySpecialType('1'), 
MySpecialType('2'), MySpecialType('3'), MySpecialType('a')]);


What should the length of the pre-allocated array be?

Re: mixin break; in switch containing static foreach

[Vladimirs Nordholm via Digitalmars-d-learn]

On Tuesday, 3 April 2018 at 19:41:54 UTC, Alex wrote:
On Tuesday, 3 April 2018 at 19:31:50 UTC, Vladimirs Nordholm 
wrote:

[...]


Would labelling help?
https://run.dlang.io/is/vE1KyD


Ah! Okay, now I see.

Thanks Alex and Adam!

[Issue 15206] ICE on optimized build, tym = x1d Internal error: backend\cgxmm.c 547

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

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

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com

--- Comment #7 from John Colvin  ---
I found a different piece of code that triggers the same error:

% cat test.d:
alias A = Complex!double;

struct Complex(T)
{
double re, im;

Complex!double baz()
{
return Complex!double(re).blah;
}

ref Complex!double blah()
{
im = re;
return this;
}
}

% dmd -c -inline -O -m64 test.d
tym = x1d
Internal error: dmd/backend/cgxmm.c 684

Walter, I can produce the error for both this and the original example on both
macOS and linux (haven't tried windows). -m32 avoids the bug.

--

Re: Better way to append to array than ~= ?

[Meta via Digitalmars-d-learn]

On Tuesday, 3 April 2018 at 19:02:25 UTC, Vladimirs Nordholm 
wrote:

Hello people.

I currently have a function which multiple times per second 
takes in arguments, and appends the argument as my special 
type. The following code should explain what I do more properly:


struct MySpecialType { char c; }

auto foo(Args...)(Args args)
{
MySpecialType[] bar;

foreach(ref arg; args)
{
static if(is(typeof(arg) == MySpecialType))
{
bar ~= arg;
}
else
{
foreach(c; to!string(arg))
{
bar ~= MySpecialType(c);
}
}
}

// do more stuff
}

Now, from my trace.log, some of the topmost things on the 
timing list are `std.array.Appender!(immutable(char).stuff>`. I also remember reading some years ago that ~= isn't 
optimal for speed.


So my question is: Is there a better and/or faster way of doing 
this, or is this the best approach?


In this specific case, since you know the length of `Args`, you 
can pre-allocate an array of that size and loop through it doing 
your initialization.


However, if you want really performant code, you should allocate 
a static array on the stack outside of the function and pass it 
in as a buffer.

Re: mixin break; in switch containing static foreach

[Adam D. Ruppe via Digitalmars-d-learn]

On Tuesday, 3 April 2018 at 19:31:50 UTC, Vladimirs Nordholm 
wrote:

switch(foo)


Put the label on the switch

whatever: switch(foo)



mixin(format("
case Foo.%s:bar = Bar.%s;break;
", f, f));


then use the label here

break whatever;

Re: mixin break; in switch containing static foreach

[Alex via Digitalmars-d-learn]

On Tuesday, 3 April 2018 at 19:31:50 UTC, Vladimirs Nordholm 
wrote:
My base problem is that I want to mixin `break` into a switch 
statement, but the mixin is within a static foreach. Take a 
look at the following code:


switch(foo)
{
static foreach(f; EnumMembers!Foo)
{
mixin(format("
case Foo.%s:bar = Bar.%s;break;
", f, f));
}

default: /* do stuff */; break;
}

The above code returns the error "Error: must use labeled 
`break` within `static foreach`". For a more complete example, 
take a look att this sample code: 
https://dpaste.dzfl.pl/f3ab6d9679fc


I also attempted this solution, but I got the error that the 
label didn't exist. (And it looks pretty ugly)


mixin(format("%s: case Foo.%s: abc = Foo.X%s; break %s;", 
f, f, f, f));


Any of you have a solution for this problem?

Best regards,
Vladimirs Nordholm


Would labelling help?
https://run.dlang.io/is/vE1KyD

mixin break; in switch containing static foreach

[Vladimirs Nordholm via Digitalmars-d-learn]

My base problem is that I want to mixin `break` into a switch 
statement, but the mixin is within a static foreach. Take a look 
at the following code:


switch(foo)
{
static foreach(f; EnumMembers!Foo)
{
mixin(format("
case Foo.%s:bar = Bar.%s;break;
", f, f));
}

default: /* do stuff */; break;
}

The above code returns the error "Error: must use labeled `break` 
within `static foreach`". For a more complete example, take a 
look att this sample code: https://dpaste.dzfl.pl/f3ab6d9679fc


I also attempted this solution, but I got the error that the 
label didn't exist. (And it looks pretty ugly)


mixin(format("%s: case Foo.%s: abc = Foo.X%s; break %s;", f, 
f, f, f));


Any of you have a solution for this problem?

Best regards,
Vladimirs Nordholm

Re: is this even possible? newbie + mixin template + foreach (allMembers)

[Alex via Digitalmars-d-learn]

On Tuesday, 3 April 2018 at 18:57:29 UTC, WebFreak001 wrote:


you need to use a static foreach for this. You can insert a 
static foreach basically where you can insert a function 
definition like void foo() {}


foreach is more like a function call like foo(), so you can't 
put it in the mixin template.


A mixin template is basically expected to be mixin-able in 
global scope or in a class/struct so it can't have any things 
like function calls because that would be the same as writing 
`foo();` at global level instead of in the main function.


static foreach on the other hand allows exactly that because it 
literally unrolls the contents and inserts it multiple times, 
so you can also put it in mixin templates if the content of the 
loop is valid in mixin templates.


If you need to support older compilers you can use normal 
foreach with ctfe by generating a code string or do recursive 
templates, but I would really encourage you to use static 
foreach instead, it is cleaner and faster.


I think, the OP has something other in mind. Look at this:

´´´
void main(){}

struct World
{
floatrotation;
bool active;

//mixin BuildStuff!();
}

mixin BuildStuff!();

mixin template BuildStuff()
{
static foreach(elem; __traits(allMembers, World))
{
pragma(msg, elem);
}
}
´´´

While the outer mixin works as expected, the inner one results in 
a seg fault.

No idea why, however, too...

Re: Deprecating this(this)

[jmh530 via Digitalmars-d]

On Saturday, 31 March 2018 at 23:38:06 UTC, Andrei Alexandrescu 
wrote:

[snip]

* immutable and const are very difficult, but we have an attack 
(assuming copy construction gets taken care of)




Would it be easier if the const/immutable containers were 
considered separate types? For instance, in the code below, there 
is InoutFoo and then Foo takes InoutFoo as an alias this (you 
could do the same thing with immutable, but then you’d have to 
include two get functions). This would be like inheriting the 
InoutFoo.


With better syntax, InoutFoo would be something like inout(Foo) 
and the compiler could recognize that the mutable constructor is 
also defined and to call that when appropriate.


struct InoutFoo
{
int a;

this(int b) inout
{
this.a = b;
}

int get() inout
{
return a;
}
}

struct Foo
{
InoutFoo inoutfoo;
alias inoutfoo this;

this(int b)
{
a = b;
}

void set(int b)
{
a = b;
}
}


void main()
{
auto x = immutable InoutFoo(1);
auto y = Foo(1);

assert(is(typeof(y) : typeof(x)));

//x.a++; //not allowed
y.a++;

assert(x.a == 1);
assert(y.a == 2);

assert(x.get == 1);
y.set(3);
assert(y.get == 3);
}

Re: D compiles fast, right? Right??

[Jonathan Marler via Digitalmars-d]

On Tuesday, 3 April 2018 at 10:24:15 UTC, Atila Neves wrote:

On Monday, 2 April 2018 at 18:52:14 UTC, Jonathan Marler wrote:

My point was that GO's path library is very different from 
dlang's std.path library.  It has an order of magnitude less 
code so the point was that you're comparing a very small 
library with much less functionality to a very large one.


I understood your point. I'm not sure you understood mine, 
which is: I don't care. I want to get work done, and I don't 
want to wait for the computer.


You still missed my point.  You're post was saying that "D does 
not compile as fast as GO". But the libraries you're comparing 
are vastly different.  If you're post was saying, "dlang's 
std.path compiles much slower than GO's" then you would be fine.  
However, you're post was misleading saying the Go compile's 
faster than D in general, and I was pointing out that the use 
case you provided doesn't apply in the general case, it only 
applies to a library with the same name/type of functionality.





I didn't say anything about whether it was advantageous, the 
point was that it's more code so you should take that into 
account when you evaluate performance.  You're post was 
misleading because it was assuming that both libraries were 
comparable when in reality they appear to be very different.


I disagree. They're very similar in the sense that, if I want 
to build a path and want to rely on the standard library, it 
takes vastly different amounts of time to compile my code in 
one situation vs the other.




I refer to my previous answer.  Your example shows that dlang's 
std.path compiles slower than GO's, but that doesn't say anything 
about the compile performance for both languages in the general 
case.  To make such a claim you should compare the exact same 
"functionality" implemented in both languages.





My point was that if you want to compare "compile-time" 
performance, you should not include the unittests in D's time 
since Go does not include unittests.


"Go does not include unittests"? Under some interpretations I 
guess that could be viewed as correct, but in practical terms I 
can write Go tests without an external library 
(https://golang.org/pkg/testing/)/ Whether it's a language 
keyword or not is irrelevant.


What _is_ relevant (to me) is that I can write Go code that 
manipulates paths and test it with everything building in less 
time that it takes to render a frame in a videogame, whereas in 
D...


You're totally misunderstanding me.  I was just saying that if 
you want to compare the compile speed of D vs GO (IN THE GENERAL 
CASE), you should not include the unittests in D's performance 
because you weren't including them in your GO example.


This is a problem that should be fixed but still doesn't 
change the fact that not taking this into consideration would 
be an unfair comparison.


No, no, no, a thousand times more no.

We can't make a marketing point of D compiling so fast it might 
as well be a scripting language when it's not even true. I get 
a better edit-compile-test cycle in *C++*, which is embarassing.


Atila


You totally misunderstood what I was saying once again.  I agree 
with what you said here, but it has nothing to do with what I was 
saying.


If your point is that it takes too long to access std.path's 
functionality then I completely agree. What I am arguing against 
is that your example is not evidence that GO compiles faster than 
D in general. You're example is comparing 2 different libraries 
in 2 different languages, not about the languages themselves.

Better way to append to array than ~= ?

[Vladimirs Nordholm via Digitalmars-d-learn]

Hello people.

I currently have a function which multiple times per second takes 
in arguments, and appends the argument as my special type. The 
following code should explain what I do more properly:


struct MySpecialType { char c; }

auto foo(Args...)(Args args)
{
MySpecialType[] bar;

foreach(ref arg; args)
{
static if(is(typeof(arg) == MySpecialType))
{
bar ~= arg;
}
else
{
foreach(c; to!string(arg))
{
bar ~= MySpecialType(c);
}
}
}

// do more stuff
}

Now, from my trace.log, some of the topmost things on the timing 
list are `std.array.Appender!(immutable(char).`. I 
also remember reading some years ago that ~= isn't optimal for 
speed.


So my question is: Is there a better and/or faster way of doing 
this, or is this the best approach?

[Issue 18716] [ICE] type const(char)[] can not be mapped to C++

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

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

--- Comment #1 from Jacob Carlborg  ---
Pull request: https://github.com/dlang/dmd/pull/8120.

--

Re: Deprecating this(this)

[Andrei Alexandrescu via Digitalmars-d]

On 04/03/2018 10:21 AM, ag0aep6g wrote:

On Tuesday, 3 April 2018 at 12:52:00 UTC, Andrei Alexandrescu wrote:

On 04/03/2018 07:36 AM, ag0aep6g wrote:
For constructors, we say that the first assignment is actually 
initialization. The compiler might or might not put the .init value 
down before calling the constructor. Doesn't matter, because the 
constructor will overwrite it anyway, and nothing of value is lost.


What happens in fact is you are guaranteed the .init value is there. 
Much later, well after semantic checking, the backend optimizer 
removes dead assignments on primitive data.


So constructors, including const/immutable ones, basically work the same 
as postblit already? You get an object pre-filled with some values, and 
then you can "initialize" the fields some more if you want.


Well... not really. This is because .init is really an inert state - 
null indirections, no state allocated etc. Makes typechecking easy, and 
calling constructor on top of .init is what happens already. In 
contrast, the postblit situash is very different - the fields already 
contain "interesting" data, allocated resources etc. Calling a 
constructor on top of that is not defined.

Re: is this even possible? newbie + mixin template + foreach (allMembers)

[WebFreak001 via Digitalmars-d-learn]

On Tuesday, 3 April 2018 at 18:49:00 UTC, Carlos Navarro wrote:

QUESTION:

Obviously I'm no geting mixins/templates nor traits and I'm 
failing miserably to find/identify the right examples or 
documentation to help me tackle this thing. What is wrong in 
this code? is this pattern sintactically possible? what I'm 
getting wrong?


CONTEXT:
I'm a newbie trying to extend a struct using a mixin template 
like this one:


struct World {
floatrotation;
bool active;
mixin BuildStuff;
}

mixin template BuildStuff() {
foreach(elem; __traits(allMembers, typeof(this))) {
//pragma(msg, elem);
}
} //full example here: https://run.dlang.io/is/OeXS4j

COMPILER OUTPUT:

2.067.1 to 2.071.2: Failure with output:
-
onlineapp.d(18): Error: declaration expected, not 'foreach'
onlineapp.d(18): Error: declaration expected, not '__traits'
onlineapp.d(22): Error: template member expected
-

2.072.2 to 2.075.1: Failure with output:
-
onlineapp.d(18): Error: declaration expected, not 'foreach'
onlineapp.d(18): Error: declaration expected, not '__traits'
onlineapp.d(22): Error: matching '}' expected, not EOF
-

Since  2.076.1: Segfault and no output


you need to use a static foreach for this. You can insert a 
static foreach basically where you can insert a function 
definition like void foo() {}


foreach is more like a function call like foo(), so you can't put 
it in the mixin template.


A mixin template is basically expected to be mixin-able in global 
scope or in a class/struct so it can't have any things like 
function calls because that would be the same as writing `foo();` 
at global level instead of in the main function.


static foreach on the other hand allows exactly that because it 
literally unrolls the contents and inserts it multiple times, so 
you can also put it in mixin templates if the content of the loop 
is valid in mixin templates.


If you need to support older compilers you can use normal foreach 
with ctfe by generating a code string or do recursive templates, 
but I would really encourage you to use static foreach instead, 
it is cleaner and faster.

[Issue 18717] Segfault in BitManip

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

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

--- Comment #1 from Cédric Picard  ---
Forgot to mention that this may be related to
https://issues.dlang.org/show_bug.cgi?id=12458 although I do not the issues are
the same.

--

[Issue 18717] New: Segfault in BitManip

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

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

  Issue ID: 18717
   Summary: Segfault in BitManip
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: cpic...@openmailbox.org

The following program segfaults with dmd v2.079.0 when compiled with no
arguments in x86_64:

```
import std.bitmanip;

void main(string[] args) {
auto barray   = BitArray();
ulong evilVal = 2534886795;
barray.length = evilVal + 1;
barray[evilVal];
}
```

The segfault happens there:


╭ (fcn) sym._D4core5bitop2btFNaNbNixPmmZi 13
│   sym._D4core5bitop2btFNaNbNixPmmZi ();   
│   0x5558709cde6c  55 push rbp 
│   0x5558709cde6d  488bec mov rbp, rsp 
|   ;-- rip:
│   0x5558709cde70  0fa33e bt dword [rsi], edi  
│   0x5558709cde73  19c0   sbb eax, eax 
│   0x5558709cde75  f7d8   neg eax  
│   0x5558709cde77  5d pop rbp  
╰   0x5558709cde78  c3 ret  
0x5558709cde79     add byte [rax], al   
0x5558709cde7b  ~   005548 add byte [rbp + 0x48], dl


At that point we have:
rsi = 0x7f40163e2010   -> our BitArray
rdi = 0x97174d8b   -> "evilVal"

A look at /proc/*/maps shows that the call falls into that section:

0x7f40163e2000 # 0x7f4032928000 - usr 453.3M s -rw- unk1 unk1

IIUC this is what was allocated for our BitArray. However this isn't enough as
0x7f4032928000 - 0x7f40163e2000 < 2534886795.

Therefore my understanding is that not enough memory was allocated to hold the
BitArray even though we specified a length strictly greater than the index we
are accessing.

--

Re: @property for simple methods?

[Vladimirs Nordholm via Digitalmars-d-learn]

On Monday, 2 April 2018 at 15:05:04 UTC, Seb wrote:
On Monday, 2 April 2018 at 14:51:57 UTC, Vladimirs Nordholm 
wrote:

On Monday, 2 April 2018 at 14:20:49 UTC, Dennis wrote:

[...]


Ah! First time I read the docs I didn't understand the 
typeof(exp) explanation, but yours made me understand that 
part.


Do you think I should I omit the @property tag, if the only 
wanted behaviour is to set a value (`foo.bar = "baz";`) ?


Yes I would omit @proporty if you don't need it as it isn't 
really useful at the moment.

There's a DIP to fix it and make it more powerful though:

https://github.com/dlang/DIPs/pull/97

And if you are looking for @read, @write limitations the 
accessors library might be interesting to you:


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


Nice read, and the library seems interesting 

is this even possible? newbie + mixin template + foreach (allMembers)

[Carlos Navarro via Digitalmars-d-learn]

QUESTION:

Obviously I'm no geting mixins/templates nor traits and I'm 
failing miserably to find/identify the right examples or 
documentation to help me tackle this thing. What is wrong in this 
code? is this pattern sintactically possible? what I'm getting 
wrong?


CONTEXT:
I'm a newbie trying to extend a struct using a mixin template 
like this one:


struct World {
floatrotation;
bool active;
mixin BuildStuff;
}

mixin template BuildStuff() {
foreach(elem; __traits(allMembers, typeof(this))) {
//pragma(msg, elem);
}
} //full example here: https://run.dlang.io/is/OeXS4j

COMPILER OUTPUT:

2.067.1 to 2.071.2: Failure with output:
-
onlineapp.d(18): Error: declaration expected, not 'foreach'
onlineapp.d(18): Error: declaration expected, not '__traits'
onlineapp.d(22): Error: template member expected
-

2.072.2 to 2.075.1: Failure with output:
-
onlineapp.d(18): Error: declaration expected, not 'foreach'
onlineapp.d(18): Error: declaration expected, not '__traits'
onlineapp.d(22): Error: matching '}' expected, not EOF
-

Since  2.076.1: Segfault and no output

Re: @property for simple methods?

[Vladimirs Nordholm via Digitalmars-d-learn]

On Monday, 2 April 2018 at 15:15:05 UTC, Dennis wrote:
On Monday, 2 April 2018 at 14:51:57 UTC, Vladimirs Nordholm 
wrote:
Do you think I should I omit the @property tag, if the only 
wanted behaviour is to set a value (`foo.bar = "baz";`) ?


You're probably fine either way, it's mostly for making your 
intention clear. Jonathan M Davis made a great explanation:

(https://forum.dlang.org/post/mailman.709.1481234980.9448.digitalmars-d-le...@puremagic.com)


His reasoning is the same as mine. I only have the @property as 
documentation :)

[Issue 18716] New: [ICE] type const(char)[] can not be mapped to C++

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

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

  Issue ID: 18716
   Summary: [ICE] type const(char)[] can not be mapped to C++
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: d...@me.com

The following code:

extern (C++) void foo(const(char)[]) {}

Gives the following error:

Error: Internal Compiler Error: type const(char)[] can not be mapped to C++

--

Second Language Acquisition - Dogme & Direct Method

[markmst via Digitalmars-d-learn]

The Dogme method, based on the writing of Scott Thornbury, 
“considers language learning to be a process where language 
emerges rather than one where it is acquired”. The entire method 
is based on conversation and the teaching (or in group lessons 
‘moderation’) as such does not follow specific syllabus. While 
there is considerable criticism on this method (especially if 
followed strictly avoiding all text-material), interestingly it 
represents an excellent example of point (B) highlighted above – 
tapping into “Primary Language Acquisition Process Methods”. Also 
in Children Primary Language Acquisition very little 
text-material is used. (Picture-)Books are material to support a 
learning process entirely based on conversation. Almost every 
person went through this apparently highly effective process; the 
efficiency of this approach for Adult Education depends on the 
overall curriculum (eg intensity of program, frequency of 
lessons, setup of lessons). To elaborate on the efficiency it has 
to be noted that Children follow this approach over 1-2 years 
fulltime (in the “direct method”, see below). Furthermore the 
method was developed with very specific (e.g. non-tonal) 
languages in mind. Learning for example Chinese without basic 
graphical illustrations of tones or letters might be challenging.


www.language-school.sg

Re: Quora: Why hasn't D started to replace C++?

[12345swordy via Digitalmars-d]

On Tuesday, 3 April 2018 at 16:21:18 UTC, Joakim wrote:

On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:

On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote:

[...]


Not sure why that's a bad thing. They all have their ups and 
downs:


[...]


Since some want Quora engagement, I thought I'd mention this 
thread I just stumbled upon, while doing an unrelated google 
search for Nim, that had some mentions of D:


https://www.quora.com/in/Of-the-emerging-systems-languages-Rust-D-Go-and-Nim-which-is-the-strongest-language-and-why

May be worth reading, or someone here might want to add their 
own answer.


There is quite a number of rust fans.

Re: How to Stay Away From Faux Pas in a Foreign Language?

[Timoses via Digitalmars-d-learn]

On Tuesday, 3 April 2018 at 15:02:34 UTC, markmst wrote:

Why Pay For Learning a Foreign


I actually read this until "Why Pay For Learning a Foreign 
Language". I didn't get the joke... Go figure..

Re: Quora: Why hasn't D started to replace C++?

[Joakim via Digitalmars-d]

On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:

On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote:

[...]


Not sure why that's a bad thing. They all have their ups and 
downs:


[...]


Since some want Quora engagement, I thought I'd mention this 
thread I just stumbled upon, while doing an unrelated google 
search for Nim, that had some mentions of D:


https://www.quora.com/in/Of-the-emerging-systems-languages-Rust-D-Go-and-Nim-which-is-the-strongest-language-and-why

May be worth reading, or someone here might want to add their own 
answer.

Re: D compiles fast, right? Right??

[H. S. Teoh via Digitalmars-d]

On Tue, Apr 03, 2018 at 10:24:15AM +, Atila Neves via Digitalmars-d wrote:
[...]
> We can't make a marketing point of D compiling so fast it might as
> well be a scripting language when it's not even true. I get a better
> edit-compile-test cycle in *C++*, which is embarassing.
[...]

+1.  And this is why our "fast code fast" slogan makes me cringe.  We
need to do some serious work on delivering that "fast" promise.


T

-- 
Caffeine underflow. Brain dumped.

Re: Deprecating this(this)

[Steven Schveighoffer via Digitalmars-d]

On 4/3/18 10:21 AM, ag0aep6g wrote:

On Tuesday, 3 April 2018 at 12:52:00 UTC, Andrei Alexandrescu wrote:

On 04/03/2018 07:36 AM, ag0aep6g wrote:
For constructors, we say that the first assignment is actually 
initialization. The compiler might or might not put the .init value 
down before calling the constructor. Doesn't matter, because the 
constructor will overwrite it anyway, and nothing of value is lost.


What happens in fact is you are guaranteed the .init value is there. 
Much later, well after semantic checking, the backend optimizer 
removes dead assignments on primitive data.


So constructors, including const/immutable ones, basically work the same 
as postblit already? You get an object pre-filled with some values, and 
then you can "initialize" the fields some more if you want.


Unfortunately, I found out that it's not just "pre-filled with some 
values". Member postblits are run before the containing postblit.


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

So this means, the data that is available to the postblit has already 
been processed.


It would only make sense to allow const postblits to have the same 
constructor mechanism if the members all had no postblits.


-Steve

How to Stay Away From Faux Pas in a Foreign Language?

[markmst via Digitalmars-d-learn]

Many language learners will have a similar story to narrate. They 
have often used a foreign word accidentally, which may sound 
similar in the English as well as in the target language and yet 
are completely different in their meanings, Such linguistic 
goof-ups are referred to as "false friends". When you are 
learning a new language, there is hardly a strategic way to 
identify your false friends.


The reason for that is they occur without any set patterns and 
mostly due to coincidence. For instance, in the Portuguese 
language, when your superior volunteers to assist in your office 
presentation, it signifies that they will not assist but observe 
it.


On several occasions, certain words of a foreign language may 
appear funny to a person who is not aware of it, especially on a 
menu at a restaurant. But it is still important to resist the 
temptation of laughing out loud Why Pay For Learning a Foreign 
Language at that local language. The reason for that is the 
locals around you will consider it extremely rude.


Try to speak at a slow and measured pace, especially when you are 
travelling between two countries. You need to give adequate time 
between your mouth and brain to ensure that you are not using the 
wrong language in the wrong country. When you learn to avoid 
these common mistakes while speaking a foreign language, you can 
enjoy a fabulous time. Plus, you can pick up quite a few lingo 
while not offending the locals.


More information on :

www.language-school.hk

Re: Deprecating this(this)

[ag0aep6g via Digitalmars-d]

On Tuesday, 3 April 2018 at 12:52:00 UTC, Andrei Alexandrescu 
wrote:

On 04/03/2018 07:36 AM, ag0aep6g wrote:
For constructors, we say that the first assignment is actually 
initialization. The compiler might or might not put the .init 
value down before calling the constructor. Doesn't matter, 
because the constructor will overwrite it anyway, and nothing 
of value is lost.


What happens in fact is you are guaranteed the .init value is 
there. Much later, well after semantic checking, the backend 
optimizer removes dead assignments on primitive data.


So constructors, including const/immutable ones, basically work 
the same as postblit already? You get an object pre-filled with 
some values, and then you can "initialize" the fields some more 
if you want.


[...]

What if the user code reads the value?

* Often people use this(this) to bump a reference count a la 
"if (pcnt) ++*pcnt;"


Because of the indirection, that can only be done in a mutable 
`this(this)`. Otherwise you violate the const/immutable guarantee 
of the original object.


* People may pass the field by reference to an opaque function. 
What type does the field have?


Fully const. Same as in a constructor.

[...]

In case (1) things can get quite confusing. Inside a postblit,

field = TypeOfField(100);

is a call to the constructor, whereas

field = TypeOfField(field.x + 100);

is a call to the assignment operator.


A const constructor currently accepts both of those. So the 
second one can apparently be considered "initialization" as well? 
Or should a const constructor not be allowed to do that?

Re: Why toUTF8 not accept wchar[] as argument?

[Timoses via Digitalmars-d-learn]

On Tuesday, 3 April 2018 at 13:12:05 UTC, Timoses wrote:

On Tuesday, 3 April 2018 at 05:20:55 UTC, Seb wrote:
Better diagnostics and error messages is a key goal in 2018 
for dmd ;-)


Awesome! How about telling the user which of the template 
constraints failed? Would be so awesome. Currently, there's a 
need to check every single one (as mentioned by bauss) which 
can sometimes be a hassle.


I guess related issues are:
https://issues.dlang.org/show_bug.cgi?id=9626
https://issues.dlang.org/show_bug.cgi?id=4970

Re: Why toUTF8 not accept wchar[] as argument?

[Timoses via Digitalmars-d-learn]

On Tuesday, 3 April 2018 at 05:20:55 UTC, Seb wrote:
Better diagnostics and error messages is a key goal in 2018 for 
dmd ;-)


Awesome! How about telling the user which of the template 
constraints failed? Would be so awesome. Currently, there's a 
need to check every single one (as mentioned by bauss) which can 
sometimes be a hassle.

Re: What is the equivalent of C++'s std::optional and std::nullopt in D?

[Timoses via Digitalmars-d-learn]

On Tuesday, 3 April 2018 at 02:10:09 UTC, helxi wrote:
For reference: 
https://en.cppreference.com/w/cpp/utility/optional


See also this topic recently discussed:
https://forum.dlang.org/post/p9qvb8$1j1n$1...@digitalmars.com

Re: Deprecating this(this)

[Andrei Alexandrescu via Digitalmars-d]

On 04/03/2018 07:36 AM, ag0aep6g wrote:
For constructors, we say that the first assignment is actually 
initialization. The compiler might or might not put the .init value down 
before calling the constructor. Doesn't matter, because the constructor 
will overwrite it anyway, and nothing of value is lost.


What happens in fact is you are guaranteed the .init value is there. 
Much later, well after semantic checking, the backend optimizer removes 
dead assignments on primitive data.


We can do the same with the postblit function: First assignment is 
actually initialization. When the compiler sees that the postblit 
function initializes a field, it can skip that field when blitting.


What if the user code reads the value?

* Often people use this(this) to bump a reference count a la "if (pcnt) 
++*pcnt;"


* People may pass the field by reference to an opaque function. What 
type does the field have?


But 
it can also just blit the whole struct, because it doesn't matter if the 
value just gets overwritten.


In other words, a postblit function can either:

1) use the blitted value as a starting point, like a constructor can use 
the .init value, or it can

2) initialize the field itself.

Would make perfect sense to me.


In case (1) things can get quite confusing. Inside a postblit,

field = TypeOfField(100);

is a call to the constructor, whereas

field = TypeOfField(field.x + 100);

is a call to the assignment operator.


Andrei

Re: Deprecating this(this)

[Andrei Alexandrescu via Digitalmars-d]

On 04/02/2018 02:47 PM, Marco Leise wrote:

Am Mon, 2 Apr 2018 11:57:55 -0400
schrieb Andrei Alexandrescu :


Problem is we don't have head-mutable in the language. Yes, for built-in
slices the mechanism is simple - just change qualifier(T[]) to
qualifier(T)[]. For a struct S, there is no way to convert from
qualifier(S) to tailqualifier(S).

I plan to attack this directly in the DIP - provide a way for structs to
express "here's what implicit conversion should be applied when doing
template matching".

Andrei


You are hitting a prominent type system flaw here. What may
look like a hurdle on the path to fix this(this) is also at
the core of getting "shared" into a good shape and probably
affects how we will discuss "immutable destructors" and their
kin in the future. The question is "How transitive is a
qualifier when we strip it top-level on an aggregate?"


Roger. My hope is to solve that for primitive types, then use that to 
typecheck constructors and destructors, then use the signatures of 
(typechecked) constructors and destructors to address composition. 
Ideally we'd get away without defining another kind of qualifier - 
@tail(const) or whatever. That would complicate the language a great deal.



Andrei

[Issue 18715] Non-documented unittests should not use unpredictableSeed or default Random alias

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

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

--- Comment #1 from Nathan S.  ---
Pull request: https://github.com/dlang/phobos/pull/6414

--

[Issue 18715] New: Non-documented unittests should not use unpredictableSeed or default Random alias

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

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

  Issue ID: 18715
   Summary: Non-documented unittests should not use
unpredictableSeed or default Random alias
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

Rationale:

https://github.com/dlang/phobos/pull/6410#discussion_r178660995
>Use a fixed seed and a fixed engine, everything else might lead to random 
>coverage changes.

Exceptions are made for public unittests that may be meant to demonstrate use
of unpredictableSeed and/or the default Random.

--

Re: What's up with ddoc on dlang.org?

[Andrei Alexandrescu via Digitalmars-d]

On 04/02/2018 06:13 PM, ag0aep6g wrote:

On 04/02/2018 11:36 PM, Steven Schveighoffer wrote:
Was just perusing dlang's library documentation, and here is the 
description it has for std.experimental.allocator.make:


Dynamically allocates (using ) and then creates in the memory 
allocated an object of type T, using (if any) for its initialization. 
Initialization occurs in the memory allocated and is otherwise 
semantically the same as T(). (Note that using .!(T[]) creates a 
pointer to an (empty) array of Ts, not an array. To use an allocator 
to allocate and initialize an array, use .makeArray!T described below.)


Seems there's a few things missing here? What's happening?


Looks like a mistake that happened with this change:
https://dlang.org/changelog/2.079.0.html#fix18361

PR to fix it:
https://github.com/dlang/dlang.org/pull/2326


Thanks, I'd just found that too.

Re: Deprecating this(this)

[ag0aep6g via Digitalmars-d]

On 04/03/2018 09:39 AM, Kagamin wrote:

On Monday, 2 April 2018 at 14:42:17 UTC, ag0aep6g wrote:
The way it works in a const constructor is that `this.foo = bar;` is 
considered initialization, not assignment.


Do you mean the spec? Andrei complained about implementation.


Andrei complained about both, no? His words: "Too many bugs in design 
and implementation." Design = spec.


I'm also talking about the implementation. `this.foo = bar;` in a 
constructor is at least not normal assignment. If foo has opAssign, that 
won't be called.



Const constructors are already implemented as needed for postblit.


Maybe. But we can't explain the special assignment semantics with it 
being initialization.


Or can we?

For constructors, we say that the first assignment is actually 
initialization. The compiler might or might not put the .init value down 
before calling the constructor. Doesn't matter, because the constructor 
will overwrite it anyway, and nothing of value is lost.


We can do the same with the postblit function: First assignment is 
actually initialization. When the compiler sees that the postblit 
function initializes a field, it can skip that field when blitting. But 
it can also just blit the whole struct, because it doesn't matter if the 
value just gets overwritten.


In other words, a postblit function can either:

1) use the blitted value as a starting point, like a constructor can use 
the .init value, or it can

2) initialize the field itself.

Would make perfect sense to me.

Re: D compiles fast, right? Right??

[Stefan Koch via Digitalmars-d]

On Sunday, 1 April 2018 at 02:40:26 UTC, Walter Bright wrote:

On 3/30/2018 1:17 PM, Andrei Alexandrescu wrote:

Could be faster.


It's been a fair amount of time since somebody has done 
profiling of dmd. It needs to be done. There's probably plenty 
of low hanging fruit. Speculating about why it is slow is 
pointless without data.


Well Surprisingly enough the biggest function in a profile for 
sane code, (no templates) is called spellerY.

Re: [OT] Unity migrating parts of their engine from C++ into High Performace C# (HPC#)

[Meta via Digitalmars-d]

On Tuesday, 3 April 2018 at 04:50:15 UTC, rumbu wrote:

On Monday, 2 April 2018 at 22:55:58 UTC, Meta wrote:

On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:




void foo(IRange someRange)
{
   //do something with someRange even it's a struct
   //this includes code completion and other IDE specific 
stuff.

}


In D, template constrains are not very clean and they not 
have IDE support:


void foo(T)(T someRange) if (isInputRange!T)
{

}


Worth mentioning is that doing this necessarily causes the 
struct to be boxed. I would not be surprised if they ban 
structs inheriting from interfaces.


HPC# allows interface inheritance, but does not box structs. 
It's clearly stated in the video (15:30). In fact, boxing would 
bring up the GC, and GC is not allowed in HPC#.


Oh, that's really neat (was on mobile and could not watch the 
video).

Re: D compiles fast, right? Right??

[Atila Neves via Digitalmars-d]

On Monday, 2 April 2018 at 18:52:14 UTC, Jonathan Marler wrote:

My point was that GO's path library is very different from 
dlang's std.path library.  It has an order of magnitude less 
code so the point was that you're comparing a very small 
library with much less functionality to a very large one.


I understood your point. I'm not sure you understood mine, which 
is: I don't care. I want to get work done, and I don't want to 
wait for the computer.


I didn't say anything about whether it was advantageous, the 
point was that it's more code so you should take that into 
account when you evaluate performance.  You're post was 
misleading because it was assuming that both libraries were 
comparable when in reality they appear to be very different.


I disagree. They're very similar in the sense that, if I want to 
build a path and want to rely on the standard library, it takes 
vastly different amounts of time to compile my code in one 
situation vs the other.



My point was that if you want to compare "compile-time" 
performance, you should not include the unittests in D's time 
since Go does not include unittests.


"Go does not include unittests"? Under some interpretations I 
guess that could be viewed as correct, but in practical terms I 
can write Go tests without an external library 
(https://golang.org/pkg/testing/)/ Whether it's a language 
keyword or not is irrelevant.


What _is_ relevant (to me) is that I can write Go code that 
manipulates paths and test it with everything building in less 
time that it takes to render a frame in a videogame, whereas in 
D...


In practicality, D should not be compiling in the standard 
library unittest by default.


I think everyone is in agreement here.

This is a problem that should be fixed but still doesn't change 
the fact that not taking this into consideration would be an 
unfair comparison.


No, no, no, a thousand times more no.

We can't make a marketing point of D compiling so fast it might 
as well be a scripting language when it's not even true. I get a 
better edit-compile-test cycle in *C++*, which is embarassing.


Atila

Re: Vtable for virtual functions in D

[Kagamin via Digitalmars-d]

On Wednesday, 7 March 2018 at 22:02:17 UTC, sarn wrote:
When I wrote Xanthe a year ago, I rolled my own classes using 
alias this and explicit vtables:

https://gitlab.com/sarneaud/xanthe/blob/master/src/game/rigid_body.d#L15
(I did this because normal D classes use the druntime library, 
and Xanthe was an experiment in not using the D runtime at all.)


You can use address of vtable as type id. Unique and doesn't need 
CTFE.


alias TypeId=immutable(VTable*);
alias type_id=_vtable;

Re: Vtable for virtual functions in D

[Kagamin via Digitalmars-d]

On Monday, 2 April 2018 at 07:02:07 UTC, sarn wrote:
I decided to pull some basic background info about vtables, 
etc, into its own post.  I'll write about taking advantage of 
alias this and template metaprogramming in a later post.

https://theartofmachinery.com/2018/04/02/inheritance_and_polymorphism.html


You can use COM interfaces. You'll still need to build vtable by 
hand, but at least you'll have some syntax sugar at the call site 
if you don't have multiple inheritance.

Re: Need a fancy domain for your project? .dub.pm has you covered!

[WebFreak001 via Digitalmars-d-announce]

On Thursday, 23 February 2017 at 14:16:35 UTC, Seb wrote:

Hey all,

As I own dub.pm since a year and it hasn't been used much, I 
have just configured automatic sub-domain rewriting, s.t. 
everyone can have nice and fancy URLs. All sub-domains get 
redirected to their respective DUB package page, so now you can 
browse e.g.


[...]


would be cool if you could set the page it redirects to in the 
dub project settings, like set it to package page or 
documentation page or github page or website page.

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

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

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

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

https://github.com/dlang/phobos/commit/0dc7ea22b08b317e4e5bda07d298996ecb9efa0f
Fix Issue 18452 - std.zip has size limit of 2 GB

https://github.com/dlang/phobos/commit/861e65ac5f590dd8bc12c99d07492728573a5d91
Merge pull request #6378 from johnsilver97/Issue_18452

Fix Issue 18452 - std.zip has size limit of 2 GB

--

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

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

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

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

   What|Removed |Added

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

--

Re: [OT] Unity migrating parts of their engine from C++ into High Performace C# (HPC#)

[aliak via Digitalmars-d]

On Tuesday, 3 April 2018 at 07:57:36 UTC, rikki cattermole wrote:

On 03/04/2018 7:43 PM, aliak wrote:
On Tuesday, 3 April 2018 at 05:24:02 UTC, rikki cattermole 
wrote:
Shame we don't have signatures, then we'd have similar 
functionality only better!


https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md


Is there an eta on this being submitted for consideration? Or 
has it already or?


Cheers


No ETA, it is a major addition comparable to classes and I want 
to get it right.


Ok. Really looking forward to it! :)

[Issue 18714] Phobos calls localtime, which is not threadsafe

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

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

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

   What|Removed |Added

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

--

[Issue 18714] Phobos calls localtime, which is not threadsafe

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

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

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

https://github.com/dlang/phobos/commit/5d6bf2bdd2fac4ba5da71893d50306963326eedb
Do not call localtime. It is not threadsafe. You will randomly return wrong
times in threaded apps. Fixes Issue 18714.

--