[Issue 14193] Provide a way to mangle a D struct as a C++ class.

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

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

Walter Bright  changed:

   What|Removed |Added

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

--- Comment #5 from Walter Bright  ---
  extern (C++, class) struct ...

will mangle it as a class.

--

[Issue 15503] Namespace lookup not following scoping rules

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

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

Walter Bright  changed:

   What|Removed |Added

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

--- Comment #2 from Walter Bright  ---
(In reply to Walter Bright from comment #1)
> https://github.com/D-Programming-Language/dmd/pull/5330

And it was pulled!

--

[Issue 15611] DMD doesn't build with VS2015

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

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

Walter Bright  changed:

   What|Removed |Added

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

--- Comment #3 from Walter Bright  ---
(In reply to Manu from comment #2)
> https://github.com/D-Programming-Language/dmd/pull/5367
> 
> This fixes the compile error.

And it was pulled!

--

Re: Migrating an existing more modern GC to D's gc.d

[Dmitry Olshansky via Digitalmars-d]

On Tuesday, 10 April 2018 at 03:59:33 UTC, Ikeran wrote:

On Monday, 9 April 2018 at 19:43:00 UTC, Dmitry Olshansky wrote:

None of of even close to advanced GCs are pluggable


Eclipse OMR contains a pluggable GC, and it's used in OpenJ9,


Or rather Eclipse OMR is a toolkit for runtimes/VMs and GC plugs 
into that. I encourage you to try it to implement D-like 
semantics with this run-time and you’ll see just how pluggable it 
is.



which claims to be an enterprise-grade JVM.


I once used OpenJ9, which was IBM J9 I think, right beforce open 
sourcing.  It was about x2 slower then Hotspot, didn’t dig too 
deep as to preciese reason. The fact that it was on Power8 was 
especially surprising, I thought IBM would take advantage of 
their own hardware.

[Issue 17359] C++ Interfacing: function with 'static' array parameter cannot be linked (x64)

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

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

--- Comment #4 from Walter Bright  ---
To get the same results in C++ and D:

C++:
  void cppFunc(float ()[3]) { }

D:
  extern(C++) void cppFunc(ref float[3] color) { }

Both mangle to:
  ?cppFunc@@YAXAAY02M@Z

--

[Issue 17890] cpp_long is not declared for Posix 64bit

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

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #4 from Jonathan M Davis  ---
It's issues like that which make it so that I avoid long like the plague in
C/C++. Personally, I use int if I don't care about the size, and one of the
(u)int*_t types if I do, and I'm very glad that D mostly doesn't have the same
problem where the size of types varies from system to system (though we're kind
of stuck with regards to stuff like size_t due to how important it is that it
interact properly with the pointer size on the machine).

--

Re: Migrating an existing more modern GC to D's gc.d

[Dmitry Olshansky via Digitalmars-d]

On Monday, 9 April 2018 at 19:50:16 UTC, H. S. Teoh wrote:
On Mon, Apr 09, 2018 at 07:43:00PM +, Dmitry Olshansky via 
Digitalmars-d wrote:

On Monday, 9 April 2018 at 18:27:26 UTC, Per Nordlöw wrote:

[...]

> Which kinds of GC's would be of interest?

I believe we can get away with parallel mark-sweep + 
snapshot-based concurrency. It has some limitations but in D 
land with GC not being the single source of memory it should 
work fine.


> Which attempts have been made already?

I still think that mostly precise Immix style GC would also 
work, it won’t be 1:1 porting job though. Many things to 
figure out.


Last I remembered, you were working on a GC prototype for D?


Still there, but my spare time is super limited lately, the other 
project preempted that for the moment.



Any news on that, or have you basically given it up?


Might try to hack to the finish line in one good night, it was 
pretty close to complete. Debugging would be fun though ;)


Will likely try to complete it at DConf hackathon, I’d be glad 
should anyone want to help.




T

[Issue 17890] cpp_long is not declared for Posix 64bit

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

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

--- Comment #3 from Walter Bright  ---
(In reply to Илья Ярошенко from comment #0)
> ...
> BTW, why c_long is always 32 bit for windows?

Because `long` in 64 bit VC++ is 32 bits.

--

[Issue 17890] cpp_long is not declared for Posix 64bit

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/druntime/pull/2160

--

Re: Migrating an existing more modern GC to D's gc.d

[Ikeran via Digitalmars-d]

On Monday, 9 April 2018 at 19:43:00 UTC, Dmitry Olshansky wrote:

None of of even close to advanced GCs are pluggable


Eclipse OMR contains a pluggable GC, and it's used in OpenJ9, 
which claims to be an enterprise-grade JVM.

Re: Is std.variant.visit not @nogc?

[Paul Backus via Digitalmars-d-learn]

On Tuesday, 10 April 2018 at 00:22:18 UTC, helxi wrote:

On Monday, 9 April 2018 at 15:59:32 UTC, Paul Backus wrote:

On Monday, 9 April 2018 at 07:07:58 UTC, Chris Katko wrote:

[...]


I agree in general, but in this case it's actually completely 
doable. In fact, I've done it myself: check out 'sumtype' on 
code.dlang.org. You can replace 'Algebraic' with 'SumType' and 
'visit' with 'match' in helxi's example, and everything Just 
Works™:


[...]


This isn't boxed by any chance, is it?


Nope! It's just a tagged union, almost exactly the same as what 
you'd write by hand in C. You can take a look at the source 
yourself, if you're curious---it's actually pretty simple:


https://github.com/pbackus/sumtype/blob/master/src/sumtype.d#L27

Re: Migrating an existing more modern GC to D's gc.d

[Ali via Digitalmars-d]

On Monday, 9 April 2018 at 23:21:23 UTC, Nordlöw wrote:

Through allocators solely or will the GC adapt in some way?


Here is the relevant line from the vision document
"@nogc: Use of D without a garbage collector, most likely by 
using reference counting and related methods Unique/Weak 
references) for reclamation of resources. This task is made 
challenging by the safety requirement. We believe we have an 
attack in the upcoming allocators/collections combos."


And the link to the vision document 
https://wiki.dlang.org/Vision/2018H1


In general, I do recommend you read the document carefully, and 
it important to note that is in it, and what is not in it


Obviously, there is no mention on working on the GC
There is also no direct mention of changing Phobos or modifying 
Phobos


Also it might be important to read the vision document in order
priority number 1 is "1. Lock down the language definition"
this very much align with many comments I've seen here from 
Andrei or Walter
that they are more interested in seeing the existing features 
used, rather than adding new features


The vision document doesn't seem to introduce any new feature, 
mostly improvements to existing features, or making existing 
feature more usable

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

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

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

--- Comment #1 from Seb  ---
Just to clarify a bit more about this, this is spuriously happening on CircleCi
for dlang/phobos when it runs DScanner and apparently the GC finds some invalid
memory during its marking phase.

--

Re: Thoughts on Herb Sutter's Metaclasses?

[Chris Katko via Digitalmars-d]

One more note: It seems like this would be heaven for trying out 
new language features without having to "manually" add them into 
the compiler first. By hijacking the syntax to AST stage, we can 
add new constructs with real-functioning code, and have others 
evaluate themselves and unit test them without having to 
"imagine" whether the code would actually work. It'd be on a real 
binary, using a real (unmodified!) compiler.


And you can also have your own "in-house" specializations. Which 
is no different than expecting people to use your API. Some API's 
have method chaining, and you use it. Some have pass-by-name, and 
you use it.

Thoughts on Herb Sutter's Metaclasses?

[Chris Katko via Digitalmars-d]

https://www.youtube.com/watch?v=6nsyX37nsRs

I'm really happy with the way languages are finally progressing. 
I've said for years that we should be able to program the "rules" 
(e.g. code guidelines) that programmers then abide by, so that 
they are statically checked.


DScanner is an example. But the core flaw is... it's "rules of 
thumb". That's great. But what about "rules for MY projects" or 
"rules for THIS SPECIFIC CODE TEAM."


I love D's templates. I'm doing stuff I never thought possible 
like accidentally re-inventing Pass-by-Name / "Named Parameters" 
completely at compile-time / zero run-time overhead.


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

Anyhow, I wonder what the D community thinks about this kind of 
meta-programming, and how much D already can do without 
metaclasses, and whether D could possibly benefit from 
implementing them.


Thanks.

Re: Should the "front" range primitive be "const" ?

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, April 09, 2018 23:58:02 Drone1h via Digitalmars-d-learn wrote:
> On Monday, 19 March 2018 at 00:50:06 UTC, Jonathan M Davis wrote:
> > [...]
> > http://jmdavisprog.com/articles/why-const-sucks.html
>
> I have just read the reply and the article.
>
> I cannot believe you have written this article in response to
> this thread (perhaps I am mis-interpreting the date of the
> article). But even if not so, thank you for clarifications and
> for describing root causes.

I did not write the article in response to any thread. I'd been meaning to
write it for a while. It's just that it's relevant to this thread, and
pointing to the article rather than trying to explain everything that's in
there again saves me time.

- Jonathan M Davis

Re: Strange Thread Causing Duplicating `writeln`

[Jonathan via Digitalmars-d-learn]

On Monday, 9 April 2018 at 22:56:33 UTC, Jonathan wrote:

On Monday, 9 April 2018 at 22:53:31 UTC, Jonathan wrote:

On Monday, 9 April 2018 at 22:49:07 UTC, Cym13 wrote:
I don't know, but I can't reproduce either with dmd or ldc. 
What was your compilation line?


dmd -run file.d


I am on Window 10 btw.


Hum, LDC does not do it for me?

Re: Migrating an existing more modern GC to D's gc.d

[Jonathan M Davis via Digitalmars-d]

On Monday, April 09, 2018 23:21:23 Nordlöw via Digitalmars-d wrote:
> On Monday, 9 April 2018 at 20:20:39 UTC, Ali wrote:
> > On Monday, 9 April 2018 at 18:27:26 UTC, Per Nordlöw wrote:
> >> How difficult would it be to migrate an existing modern
> >> GC-implementation into D's?
> >>
> >> Which kinds of GC's would be of interest?
> >>
> >> Which attempts have been made already?
> >
> > I think the priority is not having pluggable GC's, or a better
> > GC, but to fully support @nogc and deterministic and manual
> > memory management
> > which as I understood is on the roadmap
>
> Through allocators solely or will the GC adapt in some way?

I don't think that there are any plans to fundamentally change how the GC
works from the language perspective. The implementation may be improved or
replaced, but the GC isn't going anywhere, and any code that uses the GC
should continue to be able to do so as it has. Certainly, we're not getting
rid of or marginalizing the GC. We just want to make sure that code doesn't
use the GC when it doesn't need to or doesn't seriously benefit from using
the GC. More of Phobos should be @nogc than is currently, but it's never
going to be the case that all of Phobos is @nogc. There are real benefits to
using the GC, and we don't want to throw that away. We just don't want to
rely on it when it doesn't make sense.

There has been some discussion of adding some sort of RC capabilities to the
language with the idea that a type could be designed to be RC-ed that way,
but I don't think that the details have been sorted out yet, and I'm not
sure that it's even clear whether that's going to involve anything other
than GC-allocated memory (e.g. if the GC is used, then it can take care of
circular references, whereas if it isn't, then we have to get into weak
references and all of the complications that go with that). I believe that
Walter started looking into it, but I don't know how far he got before he
got sidetracked.

In particular, as I understand it, Walter's work with scope and DIP 1000 was
primarily motivated by whatever he was trying to do with RC, because without
something like DIP 1000, it becomes much harder (if not impossible) to do RC
in a fully @safe manner. So, whatever we end up seeing with regards to RC
support in the language is going to have to wait until DIP 1000 has been
fully sorted out, which will probably be a while.

Also, any work that's done to improve the GC at this point isn't something
that's going to be done by Walter. So, improvement to the GC is the sort of
thing that's likely to happen in parallel to any language improvements like
adding better RC support.

- Jonathan M Davis

Re: Is std.variant.visit not @nogc?

[helxi via Digitalmars-d-learn]

On Monday, 9 April 2018 at 15:59:32 UTC, Paul Backus wrote:

On Monday, 9 April 2018 at 07:07:58 UTC, Chris Katko wrote:

[...]


I agree in general, but in this case it's actually completely 
doable. In fact, I've done it myself: check out 'sumtype' on 
code.dlang.org. You can replace 'Algebraic' with 'SumType' and 
'visit' with 'match' in helxi's example, and everything Just 
Works™:


[...]


This isn't boxed by any chance, is it?

[Issue 18751] chunkBy predicate cannot access local variable

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

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

--- Comment #2 from hst...@quickfur.ath.cx ---
This is related to issue #14909, but the PR only fixes this problem, not that
one, so I'm keeping the bug reports separate for now.

--

[Issue 18751] chunkBy predicate cannot access local variable

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

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=14909

--

[Issue 14909] Template argument of std.algoirthm.iteration.chunkBy cannot access a local variable

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

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=18751

--

[Issue 18751] chunkBy predicate cannot access local variable

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

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from hst...@quickfur.ath.cx ---
https://github.com/dlang/phobos/pull/6441

--

Re: Should the "front" range primitive be "const" ?

[Drone1h via Digitalmars-d-learn]

On Monday, 19 March 2018 at 00:50:06 UTC, Jonathan M Davis wrote:


[...]
http://jmdavisprog.com/articles/why-const-sucks.html


I have just read the reply and the article.

I cannot believe you have written this article in response to 
this thread (perhaps I am mis-interpreting the date of the 
article). But even if not so, thank you for clarifications and 
for describing root causes.


I will have to read it again, and then read the other replies to 
my question, because I am just beginning to understand what 
"head-const" and "tail-const" mean and to get an idea of the 
problems.


By this reply, I just wish to let you all know that your answers 
are really appreciated and that I believe they are very helpful 
for many programmers, even if they need time to understand them. 
Thank you Jonathan. Thank you all.

[Issue 18751] New: chunkBy predicate cannot access local variable

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

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

  Issue ID: 18751
   Summary: chunkBy predicate cannot access local variable
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

Code:
---
unittest
{
import std.algorithm.comparison : equal;
import std.algorithm.iteration : chunkBy;

string[] data = [ "abc", "abc", "def" ];
int[] indices = [ 0, 1, 2 ];

auto chunks = indices.chunkBy!((i, j) => data[i] == data[j]);
assert(chunks.equal!equal([ [ 0, 1 ], [ 2 ] ]));
}
---

Compiler output:
---
/usr/src/d/phobos/std/algorithm/iteration.d(1761): Error: function
test.__unittest_L9_C1.ChunkByImpl!(__lambda1, int[]).ChunkByImpl.Group.popFront
cannot access frame of function test.__unittest_L9_C1
/usr/src/d/phobos/std/range/primitives.d(884): Error: template instance
`std.range.primitives.isInputRange!(Group)` error instantiating
/usr/src/d/phobos/std/algorithm/iteration.d(1781):instantiated from
here: isForwardRange!(Group)
---

--

Re: Migrating an existing more modern GC to D's gc.d

[Nordlöw via Digitalmars-d]

On Monday, 9 April 2018 at 20:20:39 UTC, Ali wrote:

On Monday, 9 April 2018 at 18:27:26 UTC, Per Nordlöw wrote:
How difficult would it be to migrate an existing modern 
GC-implementation into D's?


Which kinds of GC's would be of interest?

Which attempts have been made already?


I think the priority is not having pluggable GC's, or a better 
GC, but to fully support @nogc and deterministic and manual 
memory management

which as I understood is on the roadmap


Through allocators solely or will the GC adapt in some way?

Re: Strange Thread Causing Duplicating `writeln`

[Jonathan via Digitalmars-d-learn]

On Monday, 9 April 2018 at 22:53:31 UTC, Jonathan wrote:

On Monday, 9 April 2018 at 22:49:07 UTC, Cym13 wrote:
I don't know, but I can't reproduce either with dmd or ldc. 
What was your compilation line?


dmd -run file.d


I am on Window 10 btw.

Re: Strange Thread Causing Duplicating `writeln`

[Jonathan via Digitalmars-d-learn]

On Monday, 9 April 2018 at 22:49:07 UTC, Cym13 wrote:
I don't know, but I can't reproduce either with dmd or ldc. 
What was your compilation line?


dmd -run file.d

Re: Strange Thread Causing Duplicating `writeln`

[Cym13 via Digitalmars-d-learn]

On Monday, 9 April 2018 at 22:28:45 UTC, Jonathan wrote:

I am totally lost on why this is happening.

I stripped the code down to what appears to be the most minimal 
code that still causes the problem.


---
import core.sync.mutex;
import core.thread;
import std.stdio;

__gshared Mutex m;//__gshared just for testing (;

void thread1() {
foreach (i;0..8) {
synchronized(m) {
writeln("a1-",i);
}
writeln("a2-",i);
}
}
void thread2() {
foreach (i;0..8) {
synchronized(m) {
writeln("b1-",i);
}
writeln("b2-",i);
}
}


void main() {
m = new Mutex();

new Thread().start;
new Thread().start;
}
---
The beginning of the output for this code is:
a1-0
a2-0
a2-0
b1-0
b2-0
b2-0
a1-1
a2-1
a2-1

Why is the "a2" and "b2" writeln being repeated?!


I don't know, but I can't reproduce either with dmd or ldc. What 
was your compilation line?

[Issue 18749] bt instruction using 64-bit register for 32-bit offset

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

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

ag0aep6g  changed:

   What|Removed |Added

 Blocks||18750


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18750
[Issue 18750] [Tracker] everything wrong with code generation for bt
instruction
--

[Issue 18730] dmd miscompiles core.bitop.bt with -O

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

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

ag0aep6g  changed:

   What|Removed |Added

 Blocks||18750


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18750
[Issue 18750] [Tracker] everything wrong with code generation for bt
instruction
--

[Issue 18750] New: [Tracker] everything wrong with code generation for bt instruction

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

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

  Issue ID: 18750
   Summary: [Tracker] everything wrong with code generation for bt
instruction
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com
Depends on: 18730, 18734, 18748, 18749

Code generation for the bt instruction has quite some bugs. This is a tracker
issue to have everything in one place.


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18730
[Issue 18730] dmd miscompiles core.bitop.bt with -O
https://issues.dlang.org/show_bug.cgi?id=18734
[Issue 18734] bitnum parameter of core.bitop.bt should be signed
https://issues.dlang.org/show_bug.cgi?id=18748
[Issue 18748] bt instruction with immediate offset uses 64-bit variant for
32-bit data
https://issues.dlang.org/show_bug.cgi?id=18749
[Issue 18749] bt instruction using 64-bit register for 32-bit offset
--

[Issue 18734] bitnum parameter of core.bitop.bt should be signed

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

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

ag0aep6g  changed:

   What|Removed |Added

 Blocks||18750


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18750
[Issue 18750] [Tracker] everything wrong with code generation for bt
instruction
--

[Issue 18748] bt instruction with immediate offset uses 64-bit variant for 32-bit data

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

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

ag0aep6g  changed:

   What|Removed |Added

 Blocks||18750


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18750
[Issue 18750] [Tracker] everything wrong with code generation for bt
instruction
--

[Issue 18749] New: bt instruction using 64-bit register for 32-bit offset

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

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

  Issue ID: 18749
   Summary: bt instruction using 64-bit register for 32-bit offset
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: wrong-code
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com


ulong f(ulong* p, uint shift)
{
return (*p >> shift) & 1;
}
ulong g(ulong* p, ulong shift)
{
return f(p, cast(uint) shift);
}
void main()
{
enum shift = uint.max + 1L;
assert(cast(uint) shift == 0);
ulong s = 1;
assert(g(, shift));
}


Compile with `-O`. Resulting program segfaults.

Generated code for f and g:


 <_D4test1fFPmkZm>:
   0:   55  push   rbp
   1:   48 8b ecmovrbp,rsp
   4:   48 0f a3 3e bt QWORD PTR [rsi],rdi
   8:   19 c0   sbbeax,eax
   a:   f7 d8   negeax
   c:   5d  poprbp
   d:   c3  ret

 <_D4test1gFPmmZm>:
   0:   55  push   rbp
   1:   48 8b ecmovrbp,rsp
   4:   e8 00 00 00 00  call   9 <_D4test1gFPmmZm+0x9>
5: R_X86_64_PLT32   _D4test1fFPmkZm-0x4
   9:   5d  poprbp
   a:   c3  ret


The bt instruction in f should use edi instead of rdi. The high bits of rdi are
garbage left over from the call to g.

The code for g is correct. It's only included to show what's going on: g
immediately calls f, without zeroing the high bits of rdi.

--

[Issue 18748] New: bt instruction with immediate offset uses 64-bit variant for 32-bit data

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

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

  Issue ID: 18748
   Summary: bt instruction with immediate offset uses 64-bit
variant for 32-bit data
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: wrong-code
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com


int bt_32_imm(in uint* p)
{
enum bitnum = 1;
return ((p[bitnum >> 5] & (1 << (bitnum & 31 != 0;
}
void main()
{
import core.sys.posix.sys.mman;
import core.sys.posix.unistd;
// Allocate two pages.
immutable sz = 2 * sysconf(_SC_PAGESIZE);
auto m = mmap(null, sz, PROT_READ, MAP_PRIVATE | MAP_ANON, -1, 0);
// Discard the higher page. It becomes unreadable.
munmap(m + sz / 2, sz / 2);
// Try looking at the last 4 bytes of the readable page.
uint* p = cast(uint*) (m + sz / 2 - uint.sizeof);
bt_32_imm(p);
munmap(m, sz / 2); // Free the readable page.
}


Compile with `-O`. Resulting program segfaults.

Generated code for bt_32_imm:


   0:   55  push   rbp
   1:   48 8b ecmovrbp,rsp
   4:   48 0f ba 27 01  bt QWORD PTR [rdi],0x1
   9:   19 c0   sbbeax,eax
   b:   f7 d8   negeax
   d:   5d  poprbp
   e:   c3  ret


The bt instruction should be the 32-bit variant (DWORD instead of QWORD). The
64-bit variant tries to load 8 bytes, but only 4 are accessible.

--

Strange Thread Causing Duplicating `writeln`

[Jonathan via Digitalmars-d-learn]

I am totally lost on why this is happening.

I stripped the code down to what appears to be the most minimal 
code that still causes the problem.


---
import core.sync.mutex;
import core.thread;
import std.stdio;

__gshared Mutex m;//__gshared just for testing (;

void thread1() {
foreach (i;0..8) {
synchronized(m) {
writeln("a1-",i);
}
writeln("a2-",i);
}
}
void thread2() {
foreach (i;0..8) {
synchronized(m) {
writeln("b1-",i);
}
writeln("b2-",i);
}
}


void main() {
m = new Mutex();

new Thread().start;
new Thread().start;
}
---
The beginning of the output for this code is:
a1-0
a2-0
a2-0
b1-0
b2-0
b2-0
a1-1
a2-1
a2-1

Why is the "a2" and "b2" writeln being repeated?!

Re: code-d 0.17.0 + serve-d 0.1.2

[Johannes Loher via Digitalmars-d-announce]

Am 04.04.2018 um 20:34 schrieb greatsam4sure:
> On Tuesday, 3 April 2018 at 23:02:42 UTC, WebFreak001 wrote:
>> 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.
> 
> Thanks a lot! It works fine for me now in windows 10
> 
> steps
> 
> * I delete  C:\Users\Greatsam\AppData\Roaming\code-d folder
> **Restart visual studio code at least twice with internet connect on to
> enable code-d serve-d to download DCD
> It shows dcd successfully installed with many deprecation message
> ***I used sdl in my dub project with the flags: dflags
> "-transition=intpromote" platform="dmd"
> 
> I don't know if this have any effect. This help me to avoid some errors
> from the compilers
> 
> 
> 
> Thanks all who make this a success on windows. It is a great achievement
> in moving D forward.
I just tried to get this to work, too, but I was not able to get it to
work correctly. It seems that running dub fails somehow:

2018-04-09T23:40:19.281:source\app.d:main:196 Setting language to de
2018-04-09T23:40:19.281:source\app.d:main:205 Features fulfilled
2018-04-09T23:40:19.283:source\app.d:main:211 Started reading from stdin
2018-04-09T23:40:19.283:source\app.d:main:215 RPC started
2018-04-09T23:40:19.294:source\app.d:main:226 Has Message
2018-04-09T23:40:19.294:source\app.d:main:228 Message: RequestMessage(0,
"initialize",
{"capabilities":{"textDocument":{"codeAction":{"dynamicRegistration":true},"codeLens":{"dynamicRegistration":true},"completion":{"completionItem":{"commitCharactersSupport":true,"snippetSupport":true},"dynamicRegistration":true},"definition":{"dynamicRegistration":true},"documentHighlight":{"dynamicRegistration":true},"documentLink":{"dynamicRegistration":true},"documentSymbol":{"dynamicRegistration":true},"formatting":{"dynamicRegistration":true},"hover":{"dynamicRegistration":true},"onTypeFormatting":{"dynamicRegistration":true},"rangeFormatting":{"dynamicRegistration":true},"references":{"dynamicRegistration":true},"rename":{"dynamicRegistration":true},"signatureHelp":{"dynamicRegistration":true},"synchronization":{"didSave":true,"dynamicRegistration":true,"willSave":true,"willSaveWaitUntil":true}},"workspace":{"applyEdit":true,"didChangeConfiguration":{"dynamicRegistration":true},"didChangeWatchedFiles":{"dynamicRegistration":true},"executeCommand":{"dynamicRegistration":true},"symbol":{"dynamicRegistration":true}}},"processId":7464,"rootPath":"c:\\Users\\Johannes
Loher\\Development\\fsical-management","rootUri":"file:\/\/\/c%3A\/Users\/Johannes%20Loher\/Development\/fsical-management","trace":"off"})
2018-04-09T23:40:19.306:source\app.d:__lambda10:234 Processing as request
2018-04-09T23:40:19.306:source\app.d:processRequest:50 Initializing
2018-04-09T23:40:19.306:source\served\extension.d:initialize:143
Initializing serve-d for c:\Users\Johannes
Loher\Development\fsical-management
2018-04-09T23:40:19.306:source\served\extension.d:initialize:156
Starting dub...
2018-04-09T23:42:07.144:source\served\extension.d:safe:52
object.Exception@..\..\AppData\Local\dub\packages\dub-1.8.0\dub\source\dub\project.d(600):
Could not resolve configuration for package fsical-management

0x015C51EF
0x015C4FA2

Re: Source expression passed to a lazy parameter

[Seb via Digitalmars-d-learn]

On Monday, 9 April 2018 at 13:03:38 UTC, Simen Kjærås wrote:

On Monday, 9 April 2018 at 11:33:56 UTC, Alex wrote:

On Monday, 9 April 2018 at 09:20:42 UTC, Simen Kjærås wrote:
Nope. Something along the lines of __traits(getSource, arg) 
has been discussed occasionally.


Is this available somehow? And/or do you have a link to the 
discussion, maybe?


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

https://github.com/dlang/dmd/pull/953


I'm pretty sure there have been other discussions too, but a 
brief search yielded too many irrelevant results.


--
  Simen


For reference, the most recent discussion and PR is 
https://github.com/dlang/dmd/pull/7821 (it's currently orphaned)

Re: Migrating an existing more modern GC to D's gc.d

[Ali via Digitalmars-d]

On Monday, 9 April 2018 at 18:27:26 UTC, Per Nordlöw wrote:
How difficult would it be to migrate an existing modern 
GC-implementation into D's?


Which kinds of GC's would be of interest?

Which attempts have been made already?


I think the priority is not having pluggable GC's, or a better 
GC, but to fully support @nogc and deterministic and manual 
memory management

which as I understood is on the roadmap

Re: Migrating an existing more modern GC to D's gc.d

[H. S. Teoh via Digitalmars-d]

On Mon, Apr 09, 2018 at 07:43:00PM +, Dmitry Olshansky via Digitalmars-d 
wrote:
> On Monday, 9 April 2018 at 18:27:26 UTC, Per Nordlöw wrote:
[...]
> > Which kinds of GC's would be of interest?
> 
> I believe we can get away with parallel mark-sweep + snapshot-based
> concurrency. It has some limitations but in D land with GC not being
> the single source of memory it should work fine.
> 
> > Which attempts have been made already?
> 
> I still think that mostly precise Immix style GC would also work, it
> won’t be 1:1 porting job though. Many things to figure out.

Last I remembered, you were working on a GC prototype for D?  Any news
on that, or have you basically given it up?


T

-- 
Life is complex. It consists of real and imaginary parts. -- YHL

Re: Migrating an existing more modern GC to D's gc.d

[Dmitry Olshansky via Digitalmars-d]

On Monday, 9 April 2018 at 18:27:26 UTC, Per Nordlöw wrote:
How difficult would it be to migrate an existing modern 
GC-implementation into D's?


Which one? None of of even close to advanced GCs are pluggable, 
most in addition to being hardwired to a runtime/VM codebase, 
also rely on things like:
- particular object layout as in object header (Java, Dart + many 
JavaScript engines certainly do this)

- safe points and custom stackmaps
- some use tagged pointers and forbid explicit pointer arithmetic
- most heavily rely on GC pointers not being mixed with non-GC 
pointers
- generational ones need write barriers (pieces of code that 
guard each assignment of reference)

- most concurrent ones use read-barriers as well


Which kinds of GC's would be of interest?


I believe we can get away with parallel mark-sweep + 
snapshot-based concurrency. It has some limitations but in D land 
with GC not being the single source of memory it should work fine.



Which attempts have been made already?


I still think that mostly precise Immix style GC would also work, 
it won’t be 1:1 porting job though. Many things to figure out.

Re: #include C headers in D code

[Atila Neves via Digitalmars-d-announce]

On Monday, 9 April 2018 at 18:15:33 UTC, kinke wrote:

On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
Here's my blog post about my project that allows directly 
#including C headers in D*


https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/


Certainly interesting. Is there a good reason why you didn't 
look into Calypso though? It's restricted to LDC, okay, but its 
approach of fusioning C++ and D parts at the AST and LLVM-IR 
level seems far more promising to me - no need to translate the 
C(++) parts to D and let the underlying D compiler parse & 
analyze all that generated code again. And Calypso's C++ 
support is apparently mature enough to interface with Qt5 (!)...


This whole idea came about because a couple of years ago I was in 
a team that was responsible for legacy code written in C which 
had no tests. To write tests, we needed both to write the tests 
themselves and some fakes/mocks/doubles for the code that we 
depended on - essentially a whole operating system. I wasn't 
going to write that in C, since life is too short for that.


I wanted to write it in D, and even tried running dstep on one of 
the dependency headers we had - to no avail. Manual conversion 
was out of the question - too many headers, all them as coupled 
together as possible. So I sighed and started writing some C++14. 
I hated to admit it, but that mess of headers was only really 
usable from C or C++ (Objective C wasn't in the running). I still 
feel bad I picked C++ over D, but it was the right choice.


Why not Calypso? It's a hard enough task to convince a team of C 
programmers who don't know C++ that C++ was a better choice than 
C. It's a herculean task to convince them of D, a language they 
know even less and that they've never heard about (the first 
question is always "but which companies are using D?").


If you add to all that "No, really, it's ok, there's this project 
that forked one of the compilers. No, it's not the reference 
compiler. There's just this bit of non-standard syntax to learn 
that's neither C nor D", then the chances of convincing any 
"normal" engineer are 0.


C++ got popular because it lowered the barrier of adoption to 0. 
I want that for D.  Because of psychological reasons, I don't 
think Calypso is the way to do it, however much it's succeeded 
technically. And the whole point of dpp is convince the average 
coder and their managers.

[Issue 17607] not an associative array initializer

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

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

--- Comment #5 from Andre  ---
(In reply to John Colvin from comment #3)
> My use case involves structures with these initialisers being used by people
> who aren't really D programmers, so it looks bad and is confusing to have
> the extra `( ... )` for me too.
> 
> Hopefully there is a solution. I don't think it's a case of needing improved
> syntax in the language, it's just a compiler bug.

I just have another look. The workaround is unfortunately not working but
causing a lot of errors:

struct PutItemRequest
{
AttributeValue[string] item;
}

struct AttributeValue
{
string S;
}

void main()
{
PutItemRequest request = {
item: ([
"field1": {S: "LALA"}
])
};
}

test2.d(15): Error: found } when expecting ; following statement
test2.d(16): Error: found ] instead of statement
test2.d(17): Error: found ; when expecting ,
test2.d(18): Error: expression expected, not }
test2.d(18): Error: key:value expected for associative array literal
test2.d(18): Error: found EOF when expecting ,
test2.d(14): Error: found EOF when expecting ]
test2.d(14): Error: found EOF when expecting )
test2.d(18): Error: found end of file instead of initializer
test2.d(18): Error: semicolon expected, not EOF
test2.d(18): Error: found EOF when expecting } following compound statement

--

Re: Parse .eml files

[bachmeier via Digitalmars-d-learn]

On Monday, 9 April 2018 at 19:17:20 UTC, Adam D. Ruppe wrote:

My understanding is .eml is the same MIME format the email 
itself and mbox and maildir all use.


Thanks. I didn't know that. I will try it using email.d.

[Issue 18747] [Structs, Unions]

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
PR https://github.com/dlang/dlang.org/pull/2337

--

Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted

[Timon Gehr via Digitalmars-d-announce]

On 07.04.2018 00:45, Timon Gehr wrote:

On 06.04.2018 19:36, H. S. Teoh wrote:
On Fri, Apr 06, 2018 at 05:02:54PM +, Adam D. Ruppe via 
Digitalmars-d-announce wrote:

On Friday, 6 April 2018 at 16:57:21 UTC, Jonathan M Davis wrote:

Now, if the contracts ended up in the documentation or something


My documentation generator supports contracts, but I found in
practice, most of them are so illegible it doesn't actually help any
to include them, so I never do.

But if they were simpler single expressions, it might make sense to
revisit that.


Yeah, I think having expression syntax will make contracts more
readable.  We'll just have to see.

When will this DIP be implemented? AIUI Timon already has an
implementation sitting around somewhere.  Can't wait for it to get
merged...


T



I'll rebase it against master and create a pull request ASAP.


I created a pull request: https://github.com/dlang/dmd/pull/8155

It took a while to rebase, as relevant parts of the compiler have been 
refactored in the meantime.

Re: SMTP Mail

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

On Monday, 9 April 2018 at 15:38:55 UTC, Vino.B wrote:
Thank you very much, I copied your folder arsd under the phobes 
folder in c:\D\... and the program was placed on my desktop and 
tried to execute it from the desktop via rdmd.



I don't think rdmd is seeing the dependency on htmltotext.d. Try 
importing it explicitly from your main:


import arsd.email;
import arsd.htmltotext;

/* the rest of your code */


Just that way rdmd will find it easier.

Re: Parse .eml files

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

On Monday, 9 April 2018 at 18:47:16 UTC, bachmeier wrote:
Is there a way to do this in D? The email libraries I've found 
don't appear to work with .eml.


My understanding is .eml is the same MIME format the email itself 
and mbox and maildir all use.


So any of those libraries are likely to work with it.

You should open the eml file in Notepad or whatever and see if 
there are more than one message in it. If so, my email.d can 
handle is mbox 
http://dpldocs.info/experimental-docs/arsd.email.processMboxData.html


just `cast(immutable(ubyte)[]) std.file.read` the file to get 
that array.


Otherwise, my email.d would do it as an individual message you 
can construct with this: 
http://dpldocs.info/experimental-docs/arsd.email.IncomingEmailMessage.this.1.html


just std.file.readText and splitLines to get the string[] array.

my email.d is here 
https://github.com/adamdruppe/arsd/blob/master/email.d it depends 
on dom.d htmltotext.d and characterencodings.d


or on dub http://code.dlang.org/packages/arsd-official%3Aemail

Re: code-d 0.17.0 + serve-d 0.1.2

[Samson via Digitalmars-d-announce]

On Sunday, 8 April 2018 at 07:40:34 UTC, Domain wrote:

On Wednesday, 4 April 2018 at 13:26:18 UTC, WebFreak001 wrote:

On Wednesday, 4 April 2018 at 11:08:09 UTC, Domain wrote:

On Tuesday, 3 April 2018 at 23:02:42 UTC, WebFreak001 wrote:

[...]


// >>> many Could not resolve location of module here <<<

Server: 
2018-04-04T19:04:39.205:..\..\..\..\Local\dub\packages\dsymbol-0.3.0\dsymbol\src\dsymbol\conversion\first.d:visit:418 Could not resolve location of module 'tango\io\device\File'


[...]


uh how much memory do you have? Also try the precompiled DCD 
on the serve-d release page now


8G RAM. I don't think that's memory problem. You can try DWT 
project.




Today I update code-d serve-d and vsc. After which I got the 
notification that
WebFreak001 has deprecate code-d serve-d beta and auto completion 
stop working. I saw code-d extension with the same icon as code-d 
serve-d beta so I install it. After which code hinting and auto 
completion don't still.


What is the solution to this problem?

Re: Space before parens in all function definitions

[Seb via Digitalmars-d]

On Monday, 9 April 2018 at 16:22:15 UTC, Andrei Alexandrescu 
wrote:

On 04/07/2018 07:01 AM, Sönke Ludwig wrote:

Am 07.04.2018 um 04:23 schrieb Andrei Alexandrescu:

Why is there a space before "(" in our /library/ docs?

https://dlang.org/library/std/stdio/file.tmpfile.html

The paren here has role similar to that in mathematics, not 
literary.



Thanks,

Andrei


Has been a regression during the diet-ng transition. Fix in 
DDOX:


https://github.com/rejectedsoftware/ddox/pull/203


Thanks! When will that be live?


Should happen soon -> https://github.com/dlang/dlang.org/pull/2335

Re: Migrating an existing more modern GC to D's gc.d

[Per Nordlöw via Digitalmars-d]

On Monday, 9 April 2018 at 18:39:11 UTC, Jack Stouffer wrote:

On Monday, 9 April 2018 at 18:27:26 UTC, Per Nordlöw wrote:
How difficult would it be to migrate an existing modern 
GC-implementation into D's?


Considering no one has done it, very.


What's the reason for this being so hard?

A too unstrict programming model that enables (has enabled) to 
much bit-fiddling with pointers (classes)?

Parse .eml files

[bachmeier via Digitalmars-d-learn]

I want to save all email messages related to a research project 
into a directory, call a D program to generate an index of all 
messages, and push it to the repo server. That way all coauthors 
have access to all email messages even if they joined a project 
after several years. My client is Thunderbird, which by default 
creates .eml files.


Is there a way to do this in D? The email libraries I've found 
don't appear to work with .eml.

Re: #include C headers in D code

[bachmeier via Digitalmars-d-announce]

On Monday, 9 April 2018 at 18:15:33 UTC, kinke wrote:

On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
Here's my blog post about my project that allows directly 
#including C headers in D*


https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/


Certainly interesting. Is there a good reason why you didn't 
look into Calypso though? It's restricted to LDC, okay, but its 
approach of fusioning C++ and D parts at the AST and LLVM-IR 
level seems far more promising to me - no need to translate the 
C(++) parts to D and let the underlying D compiler parse & 
analyze all that generated code again. And Calypso's C++ 
support is apparently mature enough to interface with Qt5 (!)...


Aren't there limitations on what Calypso can do? I thought I read 
that it can't be made to work with all C code, but maybe I'm 
wrong... Of course, only working with LDC is itself a big 
restriction.

Re: Migrating an existing more modern GC to D's gc.d

[Jack Stouffer via Digitalmars-d]

On Monday, 9 April 2018 at 18:27:26 UTC, Per Nordlöw wrote:
How difficult would it be to migrate an existing modern 
GC-implementation into D's?


Considering no one has done it, very.


Which kinds of GC's would be of interest?


There's been threads about this. I'd do a search for "precise GC" 
in general.



Which attempts have been made already?


https://github.com/dlang/druntime/pull/1603

Migrating an existing more modern GC to D's gc.d

[Per Nordlöw via Digitalmars-d]

How difficult would it be to migrate an existing modern 
GC-implementation into D's?


Which kinds of GC's would be of interest?

Which attempts have been made already?

Re: #include C headers in D code

[kinke via Digitalmars-d-announce]

On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
Here's my blog post about my project that allows directly 
#including C headers in D*


https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/


Certainly interesting. Is there a good reason why you didn't look 
into Calypso though? It's restricted to LDC, okay, but its 
approach of fusioning C++ and D parts at the AST and LLVM-IR 
level seems far more promising to me - no need to translate the 
C(++) parts to D and let the underlying D compiler parse & 
analyze all that generated code again. And Calypso's C++ support 
is apparently mature enough to interface with Qt5 (!)...

Re: that is bug?

[MattCoder via Digitalmars-d]

On Monday, 9 April 2018 at 15:20:58 UTC, Patrick Schluter wrote:

...
For me as a C programmer this is different. What happens in 
this case? It will be assign foo to either a or b?



Except that it is not allowed in standard C. gcc says
...


Yes I know, that's why I said, it's different... ("From where I 
came").


Matt.

Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted

[Zach Tollen via Digitalmars-d-announce]

On Saturday, 7 April 2018 at 16:10:41 UTC, Jacob Carlborg wrote:
What's the philosophy around accepted DIPs containing multiple 
suggestions/alternatives. For example, this DIP mentions three 
alternatives for the "out" syntax [1], it's not crystal clear 
which one was actually accepted.


I think the philosophy is just that it's good to record the 
thought process which led in the final suggestion. The DIP does 
recommend syntax option 3 for "out" contracts, which is also the 
only one described in the grammar. This could be clearer, but now 
I want to change the language spec, which obviously matters a 
whole lot more, now that the DIP has been accepted.

Re: =void in struct definition

[Johan Engelen via Digitalmars-d]

On Monday, 9 April 2018 at 11:06:50 UTC, Shachar Shemesh wrote:

struct S {
  int a;
  int[5000] arr = void;
}

void func() {
  S s;
}

During the s initialization, the entire "S" area is 
initialized, including the member arr which we asked to be = 
void.


Is this a bug?


Could be optimized, yes, provided that the spec is updated. We 
discussed this live at the end of my DConf talk last year, and 
Walter (in audience) agreed upon the needed spec change. I 
haven't had/taken the time to work on it yet :(


The optimization of simplifying the initialization isn't too 
hard. But it is a bit tricky, Johannes wrote down some good 
points here: https://issues.dlang.org/show_bug.cgi?id=15951
(note the padding bytes issue).  The good news is that there 
doesn't appear to be any spec about it, so technically there is 
no language breakage and currently it is an "accepts invalid" 
bug...


Over dinner me, deadalnix and some others discussed further 
optimization where emission of the large S.init could be 
eliminated. We worked out some details, but it's a little harder 
thing to do.


cheers,
  Johan

Re: Is it a bug that a parent class that access its own private members from derived classes gets deprecation warning?

[bauss via Digitalmars-d]

On Monday, 9 April 2018 at 17:05:45 UTC, martin wrote:

On Sunday, 8 April 2018 at 13:00:02 UTC, bauss wrote:
I think it's better demonstrated like this, because to me the 
behavior makes no sense.


Especially since you can just cast "Bar" to "Foo" and then 
you're allowed to do it.


Since we're inside Foo then it shouldn't care whether "_baz" 
is private or not.


I could understand if the function was located within Bar, but 
it's not.


It's perfectly normal in other languages that supports classes 
to access private members of parent's as long as you're within 
the parent's encapsulation.


// a.d
module a;

class Foo
{
private:
bool _baz;

public:
void handleBar(T : Foo)(T[] foos)
{
foreach (child; foos)
{
child._baz = true; // Not ok.
(cast(Foo)child)._baz = true; // Ok.
}
}
}

// b.d
module b;

import a;

class Bar : Foo
{

}

// main.d

module main;

import b;

void main()
{
auto bars = [new Bar, new Bar];
auto bar = new Bar;
bar.handleBar(bars);
}


Actually, this behaves as i would expect.
`_baz` is a private member of Foo (to be precise: it belongs to 
module `a`)

in handleBar(), you iterate `Bar[]` - which is in module `b`.
By casting it to Foo, you are accessing the wanted module (`a`) 
again.


but handleBar() is in a.

This behavior is allowed in ex. C#

[Issue 18747] New: [Structs, Unions]

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

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

  Issue ID: 18747
   Summary: [Structs, Unions]
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: trivial
  Priority: P3
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: vijay...@gmail.com

In the example for union initialisation, the variable y should be of type V
rather than type U.

--

Re: Is it a bug that a parent class that access its own private members from derived classes gets deprecation warning?

[martin via Digitalmars-d]

On Sunday, 8 April 2018 at 13:00:02 UTC, bauss wrote:
I think it's better demonstrated like this, because to me the 
behavior makes no sense.


Especially since you can just cast "Bar" to "Foo" and then 
you're allowed to do it.


Since we're inside Foo then it shouldn't care whether "_baz" is 
private or not.


I could understand if the function was located within Bar, but 
it's not.


It's perfectly normal in other languages that supports classes 
to access private members of parent's as long as you're within 
the parent's encapsulation.


// a.d
module a;

class Foo
{
private:
bool _baz;

public:
void handleBar(T : Foo)(T[] foos)
{
foreach (child; foos)
{
child._baz = true; // Not ok.
(cast(Foo)child)._baz = true; // Ok.
}
}
}

// b.d
module b;

import a;

class Bar : Foo
{

}

// main.d

module main;

import b;

void main()
{
auto bars = [new Bar, new Bar];
auto bar = new Bar;
bar.handleBar(bars);
}


Actually, this behaves as i would expect.
`_baz` is a private member of Foo (to be precise: it belongs to 
module `a`)

in handleBar(), you iterate `Bar[]` - which is in module `b`.
By casting it to Foo, you are accessing the wanted module (`a`) 
again.

Re: What are AST Macros?

[Cym13 via Digitalmars-d]

On Monday, 9 April 2018 at 15:30:33 UTC, Stefan Koch wrote:

On Friday, 6 April 2018 at 21:45:45 UTC, Zach Tollen wrote:


I think Walter's reason was that such macros would hide too 
many idiosyncrasies in how they were programmed, such that a 
lot of code which seems simple on the surface will actually 
obfuscate complicated and arbitrary macro-programming 
patterns. Thus, code that uses them will become much less 
maintainable, because it is liable to do so many different and 
hidden things. Also, the tasks for which AST-macros would 
typically be used are already largely accommodated by 
templates and other features. Thus, the real need for them 
isn't that high.


I think it's time to revisit this.

The reason being that templates are only well suited to very 
specific types of meta-programs which have a low degree of 
parameterization and a low degree of abstraction.


Using templates to introspect and manipulate types is like 
using a hammmer's flat back to remove a nail.

It _can_ be done but with an absurd amount of work.
You just have to remove all of the wall around the nail by 
pounding it until the wall has around the nail is disintegrated 
:)


This is not an exaggeration.

Templates used for introspection (or anything else really 
that's modestly complex) are equally hard to reason about for 
compilers and for programmers. I guess programmers have an 
advantage when it comes to _efficient_ pattern recognition.


Wouldn't AST macros require either to standardize (and freeze) 
AST representation within the compiler or to maintain an equally 
frozen alternate representation to be exposed? I can't see how 
that wouldn't make the compiler's development slower since all of 
a sudden changing the internal representation would impact user 
code, especially given the low number of breaking changes that 
are accepted today.


I have little experience with AST macros outside Lisp where its 
homoiconicity avoids the issue almost completely so pardon the 
naive question.

Re: Space before parens in all function definitions

[Andrei Alexandrescu via Digitalmars-d]

On 04/07/2018 07:01 AM, Sönke Ludwig wrote:

Am 07.04.2018 um 04:23 schrieb Andrei Alexandrescu:

Why is there a space before "(" in our /library/ docs?

https://dlang.org/library/std/stdio/file.tmpfile.html

The paren here has role similar to that in mathematics, not literary.


Thanks,

Andrei


Has been a regression during the diet-ng transition. Fix in DDOX:

https://github.com/rejectedsoftware/ddox/pull/203


Thanks! When will that be live?

Re: Is std.variant.visit not @nogc?

[Paul Backus via Digitalmars-d-learn]

On Monday, 9 April 2018 at 07:07:58 UTC, Chris Katko wrote:

On Monday, 9 April 2018 at 07:02:50 UTC, Hasen Judy wrote:
IMO, this is one more reason why sum-types should be built 
into the language compiler, instead of being implemented in 
user-space.


+1. Any time you have to "create" a fundamental feature in a 
language... from inside the language itself... you're going to 
have confusing error messages, and a huge uphill battle.


I agree in general, but in this case it's actually completely 
doable. In fact, I've done it myself: check out 'sumtype' on 
code.dlang.org. You can replace 'Algebraic' with 'SumType' and 
'visit' with 'match' in helxi's example, and everything Just 
Works™:


import sumtype;

import core.stdc.stdio;

SumType!(T, string) fib_nth(T)(T n)
{
return n % 15
? n % 5
? n % 3
? SumType!(T, string)(n)
: SumType!(T, string)("Fizz")
: SumType!(T, string)("Buzz")
: SumType!(T, string)("Fizzbuzz");
}

void main() @nogc
{
foreach (i; 1 .. 101)
{
fib_nth(i).match!(
(string s) => printf("%s\n", s.ptr),
(int n) => printf("%i\n", n)
);
}
}

[Issue 18746] function returning empty struct isn't called if used in equality expression

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

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

--- Comment #1 from RazvanN  ---
PR : https://github.com/dlang/dmd/pull/8153

--

Re: SMTP Mail

[Vino.B via Digitalmars-d-learn]

On Monday, 9 April 2018 at 13:02:06 UTC, Adam D. Ruppe wrote:

On Sunday, 8 April 2018 at 15:45:48 UTC, Vino wrote:
  I am trying your email.d programming, and i am getting the 
below errors, can you please help me, i just used these 
programs (characterencodings.d, color.d, dom.d, htmltotext.d, 
email.d)


What is your build command?

It looks like a module is just missing in the build.

If you are using rdmd, what is your directory layout too.

(I don't work Sundays btw so that's why I am so slow to 
respond.)


Hi Adam,

Thank you very much, I copied your folder arsd under the phobes 
folder in c:\D\... and the program was placed on my desktop and 
tried to execute it from the desktop via rdmd.


From,
Vino.B

Re: What are AST Macros?

[Stefan Koch via Digitalmars-d]

On Friday, 6 April 2018 at 21:45:45 UTC, Zach Tollen wrote:


I think Walter's reason was that such macros would hide too 
many idiosyncrasies in how they were programmed, such that a 
lot of code which seems simple on the surface will actually 
obfuscate complicated and arbitrary macro-programming patterns. 
Thus, code that uses them will become much less maintainable, 
because it is liable to do so many different and hidden things. 
Also, the tasks for which AST-macros would typically be used 
are already largely accommodated by templates and other 
features. Thus, the real need for them isn't that high.


I think it's time to revisit this.

The reason being that templates are only well suited to very 
specific types of meta-programs which have a low degree of 
parameterization and a low degree of abstraction.


Using templates to introspect and manipulate types is like using 
a hammmer's flat back to remove a nail.

It _can_ be done but with an absurd amount of work.
You just have to remove all of the wall around the nail by 
pounding it until the wall has around the nail is disintegrated :)


This is not an exaggeration.

Templates used for introspection (or anything else really that's 
modestly complex) are equally hard to reason about for compilers 
and for programmers. I guess programmers have an advantage when 
it comes to _efficient_ pattern recognition.

Re: that is bug?

[Patrick Schluter via Digitalmars-d]

On Monday, 9 April 2018 at 14:28:54 UTC, MattCoder wrote:

On Monday, 9 April 2018 at 03:35:07 UTC, Ali Çehreli wrote:

...
I don't have any problem with that part either. The following 
makes sense to me. I may have even used it in the past (likely 
in C++):


(cond ? a : b) = foo;
...


For me as a C programmer this is different. What happens in 
this case? It will be assign foo to either a or b?



Except that it is not allowed in standard C. gcc says

 error: lvalue required as left operand of assignment

to that.

[Issue 18746] function returning empty struct isn't called if used in equality expression

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

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com
   Assignee|nob...@puremagic.com|razvan.nitu1...@gmail.com

--

Re: How to destruct class instances allocated by a Region-allocator over a single GC block

[Per Nordlöw via Digitalmars-d-learn]

On Monday, 9 April 2018 at 13:51:47 UTC, Steven Schveighoffer 
wrote:
Well, you know the type, because make returned it no? The 
contract is, you call obj = make!X(args), then you have to call 
dispose(obj), where obj is of the type X. That's how it knows.


If you are thinking you want to destroy the whole block at once 
(typed as void[]), that's not how it works.


stdx.allocator is not going to help you with GC collection, 
it's not geared towards that purpose.


Ok, thanks!

Re: that is bug?

[Uknown via Digitalmars-d]

On Monday, 9 April 2018 at 14:28:54 UTC, MattCoder wrote:

On Monday, 9 April 2018 at 03:35:07 UTC, Ali Çehreli wrote:

...
I don't have any problem with that part either. The following 
makes sense to me. I may have even used it in the past (likely 
in C++):


(cond ? a : b) = foo;
...


For me as a C programmer this is different. What happens in 
this case? It will be assign foo to either a or b?


Matt.


Depending on the condition, foo will be assigned to either a or b

Re: that is bug?

[MattCoder via Digitalmars-d]

On Monday, 9 April 2018 at 03:35:07 UTC, Ali Çehreli wrote:

...
I don't have any problem with that part either. The following 
makes sense to me. I may have even used it in the past (likely 
in C++):


(cond ? a : b) = foo;
...


For me as a C programmer this is different. What happens in this 
case? It will be assign foo to either a or b?


Matt.

Re: =void in struct definition

[Stefan Koch via Digitalmars-d]

On Monday, 9 April 2018 at 14:11:35 UTC, jmh530 wrote:

On Monday, 9 April 2018 at 11:15:14 UTC, Stefan Koch wrote:


Not semantically, but you might consider it a performance bug.
This particular one could be fixed, put I cannot say how messy 
the details are.
There is potential for code that silently relies on the 
behavior and would break in very non-obvious ways if we fixed 
it.


If the fix causes non-obvious breakage, then why not a DIP for 
an opInit that overrides the default initialization and has the 
desired new functionality?


Though it would be annoying to have two ways of doing the same 
thing...


It's not worth a DIP.
You can write a static initializer function and pass it a 
GCAlloced pointer.

Re: =void in struct definition

[jmh530 via Digitalmars-d]

On Monday, 9 April 2018 at 11:15:14 UTC, Stefan Koch wrote:


Not semantically, but you might consider it a performance bug.
This particular one could be fixed, put I cannot say how messy 
the details are.
There is potential for code that silently relies on the 
behavior and would break in very non-obvious ways if we fixed 
it.


If the fix causes non-obvious breakage, then why not a DIP for an 
opInit that overrides the default initialization and has the 
desired new functionality?


Though it would be annoying to have two ways of doing the same 
thing...

Re: How to destruct class instances allocated by a Region-allocator over a single GC block

[Steven Schveighoffer via Digitalmars-d-learn]

On 4/7/18 10:57 AM, Per Nordlöw wrote:

On Saturday, 7 April 2018 at 07:50:37 UTC, Eduard Staniloiu wrote:

On Friday, 6 April 2018 at 21:49:37 UTC, Per Nordlöw wrote:

On Tuesday, 3 April 2018 at 09:14:28 UTC, Eduard Staniloiu wrote:

So, say `reg` is your allocator, your workflow would be

auto obj = reg.make!Type(args);
/* do stuff */
reg.dispose(obj); // If Type has a __dtor, it will call obj.__dtor
  // and then reg.deallocate(obj)


If I do sucessive calls to reg.make!X where X are different kinds of 
classes of different sizes how does reg.dispose(obj) figure out at 
which address(es) (where emplace filled in the data) the objects reside?


It can't figure out. With custom allocators you have to manually do
the memory management, so the responsibility of when and which object 
needs

to be destroyed falls on the user of the custom allocator.


IMHO, such a complexity should be wrapped in a typed allocation layer. 
Have Andrei spoken anything about `TypedAllocator`(s) to wrap this 
complexity?


Well, you know the type, because make returned it no? The contract is, 
you call obj = make!X(args), then you have to call dispose(obj), where 
obj is of the type X. That's how it knows.


If you are thinking you want to destroy the whole block at once (typed 
as void[]), that's not how it works.


stdx.allocator is not going to help you with GC collection, it's not 
geared towards that purpose.


-Steve

Re: =void in struct definition

[Steven Schveighoffer via Digitalmars-d]

On 4/9/18 7:06 AM, Shachar Shemesh wrote:

struct S {
   int a;
   int[5000] arr = void;
}

void func() {
   S s;
}

During the s initialization, the entire "S" area is initialized, 
including the member arr which we asked to be = void.


Is this a bug?


Not technically. It has to initialize `a` to 0. The only way we 
initialize structs is to copy the whole initializer with memcpy.


It would be possible to leave the "tail" uninitialized, and just store 
the initializer for the first members that have non-void initializers. 
But that's not how it works now.


If that were to happen, you'd still have the same issue with things like:

struct S {
   int[5000] arr = void;
   int a;
}

But maybe that's just something we would have to live with.

-Steve

Re: Source expression passed to a lazy parameter

[Stefan Koch via Digitalmars-d-learn]

On Monday, 9 April 2018 at 08:27:50 UTC, Per Nordlöw wrote:
Is it possible to get the source expression sent to a lazy 
function?


So that I can implement something like

show(Arg)(lazy Arg arg)
{
writeln(arg.sourceof, arg);
}

used as

show(1+2+3);

will print

1+2+3:6


Because of the way D works with a given piece of code may not 
have a source-location or even a representation which is valid D 
source code.


Note: There is a way to fix this but it's very involved.

Step 1: you use cow (copy-on-write) when modifying AST nodes in 
semantic() or you keep distinct trees.
Step 2: you sanitize implicitly generated code to make sure it's 
actually valid code.
Step 3: you write the generated code, to a well-defined location 
such that source-of can point to a valid location.


also note that support for sourceof at compiletime will bloat the 
executable since it needs to store the source-text.

[Issue 17167] dmd fails to write to file or create directory with more than 248 characters in the path

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

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

--- Comment #9 from Atila Neves  ---
Have you checked this page?

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

I filed this bug because dub was using relative paths and ended up trying to
link to
..\..\..\..\..\Users\%USERNAME%\AppData\Roaming\dub\packages\package-name-version\package-name.

Before the fix, if the dub path with several .. was too large (which happened
often), nothing would work. Now, it does.

It's possible that passing in an absolute path is different. I would still say
that it's a new bug.

--

Re: Source expression passed to a lazy parameter

[Simen Kjærås via Digitalmars-d-learn]

On Monday, 9 April 2018 at 11:33:56 UTC, Alex wrote:

On Monday, 9 April 2018 at 09:20:42 UTC, Simen Kjærås wrote:
Nope. Something along the lines of __traits(getSource, arg) 
has been discussed occasionally.


Is this available somehow? And/or do you have a link to the 
discussion, maybe?


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

https://github.com/dlang/dmd/pull/953


I'm pretty sure there have been other discussions too, but a 
brief search yielded too many irrelevant results.


--
  Simen

Re: SMTP Mail

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

On Sunday, 8 April 2018 at 15:45:48 UTC, Vino wrote:
  I am trying your email.d programming, and i am getting the 
below errors, can you please help me, i just used these 
programs (characterencodings.d, color.d, dom.d, htmltotext.d, 
email.d)


What is your build command?

It looks like a module is just missing in the build.

If you are using rdmd, what is your directory layout too.

(I don't work Sundays btw so that's why I am so slow to respond.)

Re: #include C headers in D code

[Colin via Digitalmars-d-announce]

On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
Here's my blog post about my project that allows directly 
#including C headers in D*


https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/

The summary is that, modulo bugs, things like this work:

#include 
void main() { printf("Hello world\n".ptr); }

So far it's successfully compiled whilst #including pthread, 
libcurl, openssl and others. The blog and the github README 
have more information, and feel free to reply to this with 
questions.


dub: http://code.dlang.org/packages/dpp
reddit: 
https://www.reddit.com/r/programming/comments/8axj53/include_c_headers_in_d_code/

hacker news: It's in there somewhere, search around.

Atila

* Technically, "D + #include directives + C macros"


This is very cool.

Gonna try it against gl.h tonight!

Re: SMTP Mail

[Vino via Digitalmars-d-learn]

On Sunday, 8 April 2018 at 15:45:48 UTC, Vino wrote:

On Friday, 25 August 2017 at 02:13:42 UTC, Adam D. Ruppe wrote:

[...]


Hi Adam,

  I am trying your email.d programming, and i am getting the 
below errors, can you please help me, i just used these 
programs (characterencodings.d, color.d, dom.d, htmltotext.d, 
email.d)


[...]


Hi All,

 Any help is much appreciated.

From,
Vino.B

Re: #include C headers in D code

[SrMordred via Digitalmars-d-announce]

On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
Here's my blog post about my project that allows directly 
#including C headers in D*


https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/

The summary is that, modulo bugs, things like this work:

#include 
void main() { printf("Hello world\n".ptr); }

So far it's successfully compiled whilst #including pthread, 
libcurl, openssl and others. The blog and the github README 
have more information, and feel free to reply to this with 
questions.


dub: http://code.dlang.org/packages/dpp
reddit: 
https://www.reddit.com/r/programming/comments/8axj53/include_c_headers_in_d_code/

hacker news: It's in there somewhere, search around.

Atila

* Technically, "D + #include directives + C macros"


This is awesome!
i´ll try soon as possible :)

Re: #include C headers in D code

[Cym13 via Digitalmars-d-announce]

On Monday, 9 April 2018 at 11:48:51 UTC, jmh530 wrote:

On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
Here's my blog post about my project that allows directly 
#including C headers in D*


[snip]


Fantastic.


This is so cool, I think it should be featured on the D blog as 
well (maybe when you get to your goal of having C++ features 
working consistently).


More exposure is better exposure.

[Issue 11331] Inefficient initialization of struct with members = void

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

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

Shachar Shemesh  changed:

   What|Removed |Added

 CC||shac...@weka.io

--

[Issue 16956] struct .init is generated even for void-initialized structs

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

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

Shachar Shemesh  changed:

   What|Removed |Added

 CC||shac...@weka.io

--

Re: Source expression passed to a lazy parameter

[Alex via Digitalmars-d-learn]

On Monday, 9 April 2018 at 09:20:42 UTC, Simen Kjærås wrote:
Nope. Something along the lines of __traits(getSource, arg) has 
been discussed occasionally.


Is this available somehow? And/or do you have a link to the 
discussion, maybe?

[Issue 8929] long.min is a Voldemort literal

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

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

Mitu  changed:

   What|Removed |Added

 CC||the.mail.of@gmail.com

--

Re: =void in struct definition

[Stefan Koch via Digitalmars-d]

On Monday, 9 April 2018 at 11:15:14 UTC, Stefan Koch wrote:

On Monday, 9 April 2018 at 11:06:50 UTC, Shachar Shemesh wrote:

[ ... ]
During the s initialization, the entire "S" area is 
initialized, including the member arr which we asked to be = 
void.


Is this a bug?

Shachar


[ ... ] {This could be fixed, but may break code} [ ... ]


So currently on initalizsation we do this:
---
structPtr = cast(StructType*) alloc(structSize);
memcpy(structPtr, StructType.static_struct_initializer, 
StructType.sizeof);


which we could change to
---
structPtr = cast(StructType*) alloc(structSize);
foreach(initializerSegment;StructType.InitializerSegments)
{
memcpy((cast(void*)structPtr) + 
initializerSegment.segmentOffset,

   (cast(void*) initializerSegment.segmentPtr),
   initializerSegment.segmentSize);
}
---

This will potentially remove quite a lot of binary bloat since 
void-members do no longer need to be stored in initializers, and 
initialization overhead.
In terms of implementation this _should_ be straight-forward but 
well ... runtime and compiler interaction can be a mess.

Re: =void in struct definition

[Jonathan M Davis via Digitalmars-d]

On Monday, April 09, 2018 14:06:50 Shachar Shemesh via Digitalmars-d wrote:
> struct S {
>int a;
>int[5000] arr = void;
> }
>
> void func() {
>S s;
> }
>
> During the s initialization, the entire "S" area is initialized,
> including the member arr which we asked to be = void.
>
> Is this a bug?

It looks like Andrei created an issue about it as an enhancement request
several years ago:

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

- Jonathan M Davis

[Issue 13762] -9223372036854775808L cause integer overflow error

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

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

Simen Kjaeraas  changed:

   What|Removed |Added

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

--- Comment #2 from Simen Kjaeraas  ---


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

--

[Issue 8929] long.min is a Voldemort literal

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

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

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

--

Re: =void in struct definition

[Simen Kjærås via Digitalmars-d]

On Monday, 9 April 2018 at 11:06:50 UTC, Shachar Shemesh wrote:

struct S {
  int a;
  int[5000] arr = void;
}

void func() {
  S s;
}

During the s initialization, the entire "S" area is 
initialized, including the member arr which we asked to be = 
void.


Is this a bug?


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

--
  Simen

Re: =void in struct definition

[Stefan Koch via Digitalmars-d]

On Monday, 9 April 2018 at 11:06:50 UTC, Shachar Shemesh wrote:

struct S {
  int a;
  int[5000] arr = void;
}

void func() {
  S s;
}

During the s initialization, the entire "S" area is 
initialized, including the member arr which we asked to be = 
void.


Is this a bug?

Shachar


Not semantically, but you might consider it a performance bug.
This particular one could be fixed, put I cannot say how messy 
the details are.
There is potential for code that silently relies on the behavior 
and would break in very non-obvious ways if we fixed it.

[Issue 13762] -9223372036854775808L cause integer overflow error

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

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

Mitu  changed:

   What|Removed |Added

 CC||the.mail.of@gmail.com

--

=void in struct definition

[Shachar Shemesh via Digitalmars-d]

struct S {
  int a;
  int[5000] arr = void;
}

void func() {
  S s;
}

During the s initialization, the entire "S" area is initialized, 
including the member arr which we asked to be = void.


Is this a bug?

Shachar

#include C headers in D code

[Atila Neves via Digitalmars-d-announce]

Here's my blog post about my project that allows directly 
#including C headers in D*


https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/

The summary is that, modulo bugs, things like this work:

#include 
void main() { printf("Hello world\n".ptr); }

So far it's successfully compiled whilst #including pthread, 
libcurl, openssl and others. The blog and the github README have 
more information, and feel free to reply to this with questions.


dub: http://code.dlang.org/packages/dpp
reddit: 
https://www.reddit.com/r/programming/comments/8axj53/include_c_headers_in_d_code/

hacker news: It's in there somewhere, search around.

Atila

* Technically, "D + #include directives + C macros"

Re: Spanish translation of DLang Tour page

[Chris via Digitalmars-d-announce]

On Monday, 9 April 2018 at 10:17:30 UTC, Diego Lago wrote:

Hello all,

I would like to announce the (almost[1]) completed Spanish 
translation [2] of the DLang Tour page:


http://tour.dlang.org/tour/es

Hope this helps to spread this fantastic and awesome 
programming language :)


Best regards.

--
Diego


---
[1] Almost because "D by Example" and "DUB Packages" are 
incomplete in the English version so they haven't been 
translated into Spanish.

[2] https://github.com/dlang-tour/spanish


¡Che! ¡Qué bueno!