[Issue 17705] std.math.isFinite cannot run at compile-time

[via Digitalmars-d-bugs]

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

--- Comment #1 from Infiltrator  ---

/opt/compilers/dmd2/include/std/math.d(5385): Error: cannot convert  to
ushort* at compile time /d948/f137.d(2): called from here: isFinite(15.)


--

[Issue 17706] New: std.math.isFinite does not compile for cdouble: "No traits support for cdouble"

[via Digitalmars-d-bugs]

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

  Issue ID: 17706
   Summary: std.math.isFinite does not compile for cdouble: "No
traits support for cdouble"
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: lt.infiltra...@gmail.com


import std.math : isFinite;

void main() {
cdouble foo = 3 + 3i;
assert(foo.isFinite);
}

/opt/compilers/dmd2/include/std/math.d(330): Error: static assert "No traits
support for cdouble" /opt/compilers/dmd2/include/std/math.d(5384): instantiated
from here: floatTraits!cdouble /d598/f163.d(5): instantiated from here:
isFinite!cdouble


This works fine for both cfloat and creal.

--

[Issue 17705] New: std.math.isFinite cannot run at compile-time

[via Digitalmars-d-bugs]

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

  Issue ID: 17705
   Summary: std.math.isFinite cannot run at compile-time
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: lt.infiltra...@gmail.com


import std.math : isFinite;
enum test = isFinite(15.0);


>From what I understand from ketmar, the issue is that the CTFE allows casting
of floating types only to the same size, but isFinite casts it to ushort.  This
can be solved for float and double by using uint and ulong, respectively; but I
do not know how to make it work real, unless we allow casting to a
struct/array.

--

[Issue 17697] Ddoc: automatically highlight URLs outside of macro arguments

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/f100182bbde9496063c223fab2880a901be29880
fix Issue 17697 - Ddoc: automatically highlight URLs outside of macro arguments

https://github.com/dlang/dmd/commit/d15072fc64c1d59ac107834a3c2738919a243002
Merge pull request #7043 from WalterBright/fix17697

fix Issue 17697 - Ddoc: automatically highlight URLs outside of macro…
merged-on-behalf-of: Walter Bright 

--

[Issue 17697] Ddoc: automatically highlight URLs outside of macro arguments

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Release D 2.075.0

[Joakim via Digitalmars-d-announce]

On Monday, 24 July 2017 at 13:18:01 UTC, Mike Parker wrote:

On Wednesday, 19 July 2017 at 15:36:22 UTC, Martin Nowak wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Glad to announce D 2.075.0.



I've published a post on the blog to announce the release 
there. For future releases, I'll be coordinating with Martin so 
that I can time the blog posts to go out on the same day as the 
forum announcements. This will give us something more 
redditable than the forum announcement or the changelog.


Blog:
https://dlang.org/blog/2017/07/24/new-d-compiler-release-dmd-2-075-0/

Reddit:
https://www.reddit.com/r/programming/comments/6p89zj/new_d_compiler_release_dmd_20750/


Looks like the blog post approach worked, a new all-time high in 
downloads, and still heading up: :D


http://erdani.com/d/downloads.daily.png

Re: DMD library available as DUB package

[Johan Engelen via Digitalmars-d-announce]

On Tuesday, 18 July 2017 at 12:07:27 UTC, Jacob Carlborg wrote:
During the dconf hackathon I set out to create a DUB package 
for DMD to be used as a library. This has finally been merged 
[1] and is available here [2]. It contains the lexer and the 
parser.


This is great news of course!

But I have some bad news ;-)
Now that the Lexer nicely separated, it is very easy for me to 
testdrive libFuzzer+AddressSanitizer on the lexer and... Expect 
many bug reports in the next days. I am testing this code:


```
void fuzzDMDLexer(const(char*) data, size_t length)
{
scope lexer = new Lexer("test", data, 0, length, false, 
false);

lexer.nextToken;

do  {
auto drop = lexer.token.value;
}
while (lexer.nextToken != TOKeof);
}
```

A short list of heap-overflow memory access bugs (params data and 
length are consistent):

1. length == 0
2. data == "\n" (line feed, 0xa)
3. data == "only_ascii*" (nothing following the "*" is the 
problem)

4. data == "%%"
5. data == "*ô"
6. data == "\nÜÜÜ"
7. data == 
"\x0a''"

8. data == ")\xf7"

`void scan(Token* t)` is to blame for most of the bugs I found so 
far. See e.g. line 980 that causes bug 3:

https://github.com/dlang/dmd/blob/154aa1bfd36333a8777d571e39690511e670bfcf/src/ddmd/lexer.d#L979-L980

Example of stacktrace (bug 8):
```
==11222==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x60200952 at pc 0x0001028915b5 bp 0x7fff5d3941f0 sp 
0x7fff5d3941e8

READ of size 1 at 0x60200952 thread T0
#0 0x1028915b4 in _D4ddmd5lexer5Lexer9decodeUTFMFZk 
lexer.d:2314
#1 0x102887cae in 
_D4ddmd5lexer5Lexer4scanMFPS4ddmd6tokens5TokenZv lexer.d:1019
#2 0x102875089 in 
_D4ddmd5lexer5Lexer9nextTokenMFZE4ddmd6tokens3TOK lexer.d:222
#3 0x1028c5d20 in _D9fuzzlexer12fuzzDMDLexerFxPhmZv 
fuzzlexer.d:31

 ```

I am very excited to see the fuzzer+asan working so nicely!
:-)
  Johan

[Issue 17676] [REG 2.075] bad inlining of functions with multiple return statements

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 17676] [REG 2.075] bad inlining of functions with multiple return statements

[via Digitalmars-d-bugs]

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

--- Comment #7 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/d48421509341bfb43ac48cd3b971948f4b55f57b
fix issue 17676: do not inline function with multiple return values as
statements

https://github.com/dlang/dmd/commit/95dba7d707437aa68a21f1e048dac6e18bde043a
Merge pull request #7029 from rainers/issue_17676

fix issue 17676:  [REG 2.075] bad inlining of functions with multiple return
statements
merged-on-behalf-of: Walter Bright 

--

Re: newCTFE Status July 2017

[Stefan Koch via Digitalmars-d]

On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:

[ ... ]


Hello Guys,

The bug preventing newCTFE from executing bf_ctfe[1] correctly  
(a peculiarity in which for for and if statement-conditions  
other then 32bit integers where ignored) is now fixed.


newCTFE is about 5.7 times faster compiling bf_ctfe.
(compiling bf_ctfe includes a test where a brainfuck interpreter 
written in brainfuck executes the brainfuck hello-world programm)


Here are the numbers:

uplink@uplink-desktop:~/d/dmd$ time src/dmd ../bf-ctfe/source/*.d 
-c -o- > x

Hello World!

Hello World!

real0m0.113s
user0m0.104s
sys 0m0.008s
uplink@uplink-desktop:~/d/dmd$ time dmd ../bf-ctfe/source/*.d -c 
> x

Hello World!

Hello World!

real0m0.633s
user0m0.600s
sys 0m0.028s

[1] https://github.com/UplinkCoder/bf_ctfe

[Issue 17704] Dont parse protocols as ddoc sections

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com
 Resolution|WORKSFORME  |DUPLICATE

--- Comment #1 from Walter Bright  ---


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

--

[Issue 17697] Ddoc: automatically highlight URLs outside of macro arguments

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||b2.t...@gmx.com

--- Comment #6 from Walter Bright  ---
*** Issue 17704 has been marked as a duplicate of this issue. ***

--

[Issue 17704] Dont parse protocols as ddoc sections

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--

Re: Is there a way to use x86 and x86_mscoff with dub simultaneously.

[ciechowoj via Digitalmars-d]

What do you think about adding an optional config value 
`defaultArch` to dub? It would be used when no arch is specified.


I could specify default arch as x86_64 and everything would be 
fine.

Re: Is std.xml seriously broken, or is it me?

[Joakim via Digitalmars-d-learn]

On Sunday, 30 July 2017 at 03:16:35 UTC, Mike wrote:

On Sunday, 30 July 2017 at 02:58:09 UTC, Mike wrote:


[...]


It appears `onStartTag` does not handle the root element.  For 
example, this code seems to work:


import std.xml;
import std.stdio;

void main()
{
	auto parser = new DocumentParser("encoding=\"utf-8\"?>");

parser.onStartTag["peripheral"] = (ElementParser parser)
{
writeln("peripheral");
};
parser.parse(); 
}

Mike


You may want to try the experimental candidate for Phobos 
instead, which was developed as a GSoC project but never finished:


http://code.dlang.org/packages/std-experimental-xml

Re: Struct Postblit Void Initialization

[Moritz Maxeiner via Digitalmars-d-learn]

On Sunday, 30 July 2017 at 19:22:07 UTC, Jiyan wrote:

Hey,
just wanted to know whether something like this would be 
possible sowmehow:


struct S
{
int m;
int n;
this(this)
{
m = void;
n = n;
}
}

So not the whole struct is moved everytime f.e. a function is 
called, but only n has to be "filled"


I'll assume you mean copying (as per the title) not moving 
(because moving doesn't make sense to me in this context); use a 
dedicated method:


struct S
{
int m, n;
S sparseDup()
{
S obj;
obj.n = n;
return obj;
}
}

Re: Struct Postblit Void Initialization

[Jiyan via Digitalmars-d-learn]

On Sunday, 30 July 2017 at 19:32:48 UTC, Eugene Wissner wrote:

On Sunday, 30 July 2017 at 19:22:07 UTC, Jiyan wrote:

Hey,
just wanted to know whether something like this would be 
possible sowmehow:


struct S
{
int m;
int n;
this(this)
{
m = void;
n = n;
}
}

So not the whole struct is moved everytime f.e. a function is 
called, but only n has to be "filled"


this(this) is called after the struct is copied. Doing 
something in the postblit constructor is too late. The second 
thing is that the struct is copied with memcpy. What you 
propose would require 2 memcpy calls to copy the first part of 
the struct and then the second part. Besides it is difficult to 
implement, it may reduce the performance of the copying since 
memcpy is optimized to copy memory chunks.


Ok thank you :)

Re: Struct Postblit Void Initialization

[Eugene Wissner via Digitalmars-d-learn]

On Sunday, 30 July 2017 at 19:22:07 UTC, Jiyan wrote:

Hey,
just wanted to know whether something like this would be 
possible sowmehow:


struct S
{
int m;
int n;
this(this)
{
m = void;
n = n;
}
}

So not the whole struct is moved everytime f.e. a function is 
called, but only n has to be "filled"


this(this) is called after the struct is copied. Doing something 
in the postblit constructor is too late. The second thing is that 
the struct is copied with memcpy. What you propose would require 
2 memcpy calls to copy the first part of the struct and then the 
second part. Besides it is difficult to implement, it may reduce 
the performance of the copying since memcpy is optimized to copy 
memory chunks.

Re: M:N thread multiplexing

[Bienlein via Digitalmars-d]

On Sunday, 30 July 2017 at 13:35:18 UTC, Poyeyo wrote:
Reading this article: 
http://www.evanmiller.org/why-im-learning-perl-6.html
makes me curious about the state of Dlang's M:N thread 
multiplexing.


Quoting the article:
"if you want M:N thread multiplexing your options today are 
precisely Erlang, Go, .NET, and Perl 6."


Is it possible to add D to this list of languages mentioned in 
that article?


Whenever I asked about CSP in D I got the answer to consider 
vibe.d. D has fibers. In addition to have something like green 
threads, it would need a mechanism that a fiber that is going to 
be blocked when taking from an empty channel is detached from 
that channel and assigned to one that is not empty.


Not sure I agree that .NET has m:n threads in sense of CSP/green 
threads. About Perl 6 I don't know. Java has it as well through 
Quasar (http://docs.paralleluniverse.co/quasar/) and the JVM in 
general through Coroutines in Kotlin 
(https://kotlinlang.org/docs/reference/coroutines.html)

Struct Postblit Void Initialization

[Jiyan via Digitalmars-d-learn]

Hey,
just wanted to know whether something like this would be possible 
sowmehow:


struct S
{
int m;
int n;
this(this)
{
m = void;
n = n;
}
}

So not the whole struct is moved everytime f.e. a function is 
called, but only n has to be "filled"

[Issue 17704] New: Dont parse protocols as ddoc sections

[via Digitalmars-d-bugs]

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

  Issue ID: 17704
   Summary: Dont parse protocols as ddoc sections
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: ddoc
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

"http:" and "https:" and "ftp:" should not be parsed as DDOC section.
Example showing why: https://dlang.org/phobos/ddmd_backend_code_x86.html

--

Re: D move semantics

[Moritz Maxeiner via Digitalmars-d-learn]

On Sunday, 30 July 2017 at 16:12:41 UTC, piotrekg2 wrote:

What is the idiomatic D code equivalent to this c++ code?


There's no direct equivalent of all your code to D using only 
druntime+phobos AFAIK.




class Block
{
[...]
};


Since you don't seem to be using reference type semantics or 
polymorphism this should be mapped to a struct, such as


---
import std.experimental.allocator;
import std.experimental.allocator.mallocator;

struct Block
{
public:
static Block create()
{
Block obj;
obj.data_ = Mallocator.instance.makeArray!char(4096);
return obj;
}

~this() nothrow
{
if (data_ !is null) {
Mallocator.instance.dispose(data_);
data_ = null;
}
}

@disable this(this); // Forbid copying
private:
char[] data_;
}
---



// What is the equivalent of std::vector, the closest thing I 
could find is

// std.container.array
std::vector blocks;

for (int i = 0; i < 100; ++i) {
  // NOTE: blocks are moved when relocation happens
  // because of move-ctor and move-assign-operator marked 
noexcept

  blocks.emplace_back();
}


That's the closest one in Phobos AFAIK. There are custom 
container implementations out there such as the emsi containers 
[1]. If you use one of them, the above should be as simple as


---
Array!Block blocks;

foreach (i; 0..100)
{
blocks ~= Block.create();
}
---

I've added your example as a unittest to my own dynamic array 
implementation, should you wish to have a look [2].


A little bit of background:

Classes are reference types, structs are value types i.e there's 
no copy/move mechanics for classes w.r.t. your code. The one for 
structs is roughly like this: Whenever the compiler sees a struct 
object `obj` being assigned a new value `other`, it will run the 
destructor for `obj` (should one exist), then copy `other` over 
`obj`, followed by calling the postblit constructor `this(this) { 
... }` (should it exist) on `obj`.


In some instances (such as return from function, or first 
assignment in constructor, i.e. initialization) the compiler may 
automatically optimize the copy to a move.
Assuming the compiler tries to do a copy, it will only work if 
`typeof(obj)` is copyable (doesn't have the postblit disabled via 
`@disable this(this)`), if it isn't, the compiler will error out;
you can force a move by using `std.algorithm : move`. There's 
also `std.algorithm : moveEmplace` in case you don't wish the 
target to be destroyed.


[1] https://github.com/economicmodeling/containers
[2] 
https://github.com/Calrama/libds/blob/83211c5d7cb866a942dc9dd8ba1c622573611ccd/src/ds/dynamicarray.d#L351

[Issue 17702] codemirror hangs firefox for several seconds

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 17702] codemirror hangs firefox for several seconds

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dlang.org/commit/fb777cdb28b81c07cf9343103c61fb6eeffccbd2
Fix Issue 17702 - codemirror hangs firefox for several seconds

https://github.com/dlang/dlang.org/commit/a9065a2dc39d60c028622a4de1c2e8ae4103757b
Merge pull request #1849 from wilzbach/fix-17702

Fix Issue 17702 - codemirror hangs firefox for several seconds
merged-on-behalf-of: Vladimir Panteleev 

--

Re: undefined reference to `rt_loadLibrary'

[Jean-Louis Leroy via Digitalmars-d]

On Sunday, 30 July 2017 at 16:44:52 UTC, Jean-Louis Leroy wrote:

Hello,

I am trying to dynamically load a shared object using 
core.runtime.Runtime.loadLibrary. The link fails with a 
undefined reference to `rt_loadLibrary' error. Indeed when I 
`nm /usr/lib/x86_64-linux-gnu/libphobos2.a` I don't see it 
there. Is an extra lib needed?


[...]


OK after more googling I found that adding `dflags 
"-defaultlib=phobos2` to my dub.sdl file solves this problem.

Re: Convert ResultSet to List of Associted Array

[Jshah via Digitalmars-d-learn]

On Sunday, 30 July 2017 at 16:39:05 UTC, Jshah wrote:

Hi

I am new to D writing a web service with vibe.

My webservice connect to mysql and return the result
as JSON.

How do I convert resultset to Array of Associated Array
[["col1" : value, "col2" : value], ]


I am using mysql-native

undefined reference to `rt_loadLibrary'

[Jean-Louis Leroy via Digitalmars-d]

Hello,

I am trying to dynamically load a shared object using 
core.runtime.Runtime.loadLibrary. The link fails with a undefined 
reference to `rt_loadLibrary' error. Indeed when I `nm 
/usr/lib/x86_64-linux-gnu/libphobos2.a` I don't see it there. Is 
an extra lib needed?


dub -v output:

openmethods:dynaload 0.0.9+commit.3.g6bc05eb: building 
configuration "application"...
dmd -c 
-ofexamples/dynaload/.dub/build/application-debug-linux.posix-x86_64-dmd_2075-F869A096DE167CDA3C339619B5A0C758/openmethods_dynaload.o -debug -g -w -version=Have_openmethods_dynaload -version=Have_openmethods -version=Have_openmethods_dynalib -Iexamples/dynaload/source/ -Isource/ -Iexamples/dynalib/source/ examples/dynaload/source/app.d -vcolumns

Linking...
dmd 
-ofexamples/dynaload/.dub/build/application-debug-linux.posix-x86_64-dmd_2075-F869A096DE167CDA3C339619B5A0C758/openmethods_dynaload examples/dynaload/.dub/build/application-debug-linux.posix-x86_64-dmd_2075-F869A096DE167CDA3C339619B5A0C758/openmethods_dynaload.o examples/dynalib/.dub/build/library-debug-linux.posix-x86_64-dmd_2075-A1AE604B4B5F4B4357215CE03CBCA526/libopenmethods_dynalib.a .dub/build/library-debug-linux.posix-x86_64-dmd_2075-906C07C721DFE17599071D69E200CEC8/libopenmethods.a -L--no-as-needed -g

examples/dynaload/.dub/build/application-debug-linux.posix-x86_64-dmd_2075-F869A096DE167CDA3C339619B5A0C758/openmethods_dynaload.o:
 In function `_D4core7runtime7Runtime17__T11loadLibraryZ11loadLibraryFxAaZPv':
/usr/include/dmd/druntime/import/core/runtime.d:222: undefined 
reference to `rt_loadLibrary'

collect2: error: ld returned 1 exit status

Convert ResultSet to List of Associted Array

[Jshah via Digitalmars-d-learn]

Hi

I am new to D writing a web service with vibe.

My webservice connect to mysql and return the result
as JSON.

How do I convert resultset to Array of Associated Array
[["col1" : value, "col2" : value], ]

D move semantics

[piotrekg2 via Digitalmars-d-learn]

What is the idiomatic D code equivalent to this c++ code?

class Block
{
public:
  Block()
: data_(new char[4096])
  {}

  ...

  // NOTE: both members marked noexcept
  Block(Block &) noexcept = default;
  Block& operator=(Block &) noexcept = default;

  ...

private:
  std::unique_ptr data_;
};

// What is the equivalent of std::vector, the closest thing I 
could find is

// std.container.array
std::vector blocks;

for (int i = 0; i < 100; ++i) {
  // NOTE: blocks are moved when relocation happens
  // because of move-ctor and move-assign-operator marked noexcept
  blocks.emplace_back();
}

Re: newCTFE Status July 2017

[Stefan Koch via Digitalmars-d]

On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:

[ ... ]


Hi Guys,

After getting the brainfuck to D transcompiler to work.
I now made it's output compatible with newCTFE.

See it here:
https://gist.github.com/UplinkCoder/002b31572073798897552af4e8de2024

Unfortunately the above code does seem to get mis-compiled,
As it does not output Hello World, but rather:




Re: M:N thread multiplexing

[Moritz Maxeiner via Digitalmars-d]

On Sunday, 30 July 2017 at 13:35:18 UTC, Poyeyo wrote:
Reading this article: 
http://www.evanmiller.org/why-im-learning-perl-6.html
makes me curious about the state of Dlang's M:N thread 
multiplexing.


Quoting the article:
"if you want M:N thread multiplexing your options today are 
precisely Erlang, Go, .NET, and Perl 6."


Is it possible to add D to this list of languages mentioned in 
that article?


There is std.parallelism, which maps M tasks to N threads [1]. 
Not sure how it deals with blocking I/O, though.


[1] https://dlang.org/phobos/std_parallelism.html

M:N thread multiplexing

[Poyeyo via Digitalmars-d]

Reading this article: 
http://www.evanmiller.org/why-im-learning-perl-6.html
makes me curious about the state of Dlang's M:N thread 
multiplexing.


Quoting the article:
"if you want M:N thread multiplexing your options today are 
precisely Erlang, Go, .NET, and Perl 6."


Is it possible to add D to this list of languages mentioned in 
that article?

Re: newCTFE Status July 2017

[Stefan Koch via Digitalmars-d]

On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:

[ ... ]


Hey Guys!

working on the ctfe brainfuck compiler I finally figured out what 
was going wrong.


consider this:

uint fn ()
{
  uint[1] pointlessArray = [0];
  foreach(0 .. 42)
  pointlessArray[0]++;
  return pointlessArray[0];
}

static assert(fn() == 42);

until a few minutes ago this would have failed and the output 
would have been 0;

can you guess why ?

Well, while the ++array[0] would lower to BinAssignExp (array[0] 
+= 1) which does correctly deal with references

++ is actually not lowerd but it's own special expression.
which is handled with the following code:


auto expr = genExpr(e.e1); // in x++ expr is the x
if (!canWorkWithType(expr.type) || 
!canWorkWithType(retval.type))

{
bailout("++ only i32 is supported not " ~ 
to!string(expr.type.type) ~ " -- " ~ e.toString);

return;
}
assert(expr.vType != BCValueType.Immediate,
"++ does not make sense as on an Immediate 
Value");


Set(retval, expr); // return a copy of the old 
value
// the following code adds one the the original 
value

if (expr.type.type == BCTypeEnum.f23)
{
Add3(expr, expr, BCValue(Imm23f(1.0f)));
}
else if (expr.type.type == BCTypeEnum.f52)
{
Add3(expr, expr, BCValue(Imm52f(1.0)));
}
else
{
Add3(expr, expr, imm32(1));
}

 of course arr[x]++ will load the value into a temporary and add 
one to that temporary

 never modifying the array.
Luckily I introduced a a way for rmw (read-modify-write) 
operations to be done on structs on arrays a while back.


if the expr is not normal local i.e. a stack-variable it will 
have heapRef which tells you to which pointer you have to write 
to modify the actual value rather then just modifying the 
temporary in which it was loaded.


so this was fixed by adding the following 3 lines.

if (expr.heapRef)
{
StoreToHeapRef(expr);
}

Which will work for array's slices and structs alike :)

Re: Accessing memory after destroy

[via Digitalmars-d]

On Sunday, 30 July 2017 at 07:45:27 UTC, Johan Engelen wrote:
On Saturday, 29 July 2017 at 23:09:38 UTC, Jonathan M Davis 
wrote:


[1] https://dlang.org/spec/class.html#deallocators


If destroy has been called on a class object, then it is a bug 
to access it at any point after that (IIRC, the expectation is 
that it will blow up in your face, because the vtable is gone 
- TDPL talks about this, I believe, but I don't know where my 
copy is at the moment, so I can't check). That being said, the 
memory is still valid. And as Moritz pointed out, if the 
memory is accessible, the GC won't free it. So, it's a bug to 
access the object, but it should be memory safe to do so.


If this is the case, then we really need to improve and 
pin-down the spec on this point.


So `destroy` only calls the destructor and puts the object in 
`T.initializer` (non-constructed) state, and is otherwise not 
related to memory deallocation.
May the destructor be called again when the GC collects the 
memory?

Why is the object put in `T.initializer` state?


rt_finalize2 zeroes the vptr out after assigning 
typeid(T).initializer, so calling the destructor more than once 
is not possible, unless someone manually saves the vptr and 
assigns it back to the object after the call to destroy / 
rt_finalize.


To make sure: My question is from a spec point of view. Not 
about what currently happens and what is "OK" with the current 
implementation.


I guess the spec needs to be updated to state explicitly that a 
class destructor is called only once, if that's not already the 
case.

Re: Static array * scalar is not working for me

[Temtaime via Digitalmars-d-learn]

On Sunday, 30 July 2017 at 08:18:07 UTC, Danni Coy wrote:

The following code is not working for me

float[3] f;
f[] = abs(f)[] * -1.0f;
where abs is a function that returns a float[3];

it complains that f should be attached to some memory.

Is it a bug or am I missing something?


This is unimplemented currently and no one cares about it.

You can do:

f[] = abs(f)[];
f[] *= -1;

Re: Accessing memory after destroy

[Temtaime via Digitalmars-d]

On Sunday, 30 July 2017 at 07:58:19 UTC, ketmar wrote:

Johan Engelen wrote:


[...]


afair, somewhere in the spec there is a mention that dtor will 
be called at most once for each initialized object. and object 
state doesn't have any sense after calling dtor, but D still 
has to put something there, so `.init` looks like a reasonable 
choice. althru i'm not sure that anything in specs says that 
runtime *must* clear destroyed objects (they aren't really 
usable after calling dtor anyway, it is at least a logical bug 
to use object after destroying it).


Seems that zeroing it out is better choice, maybe.

[Issue 14246] RAII - proper destruction of partially constructed objects/structs

[via Digitalmars-d-bugs]

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

Moritz Maxeiner  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||mor...@ucworks.org
 Resolution|FIXED   |---

--- Comment #9 from Moritz Maxeiner  ---
The fix for this has been reverted in [1] and testing Shachar Shemesh's example
with 2.075.0 shows that the destructor for A is not run.
That this issue has been fixed is also erroneously shown in the changelog for
2.075.0.

[1] https://github.com/dlang/dmd/pull/6913

--

Re: GC

[Moritz Maxeiner via Digitalmars-d-learn]

On Sunday, 30 July 2017 at 09:12:53 UTC, piotrekg2 wrote:

I would like to learn more about GC in D. [...]
It would be great if you could point me out to articles on this 
subject.


The primary locations to get information are the language 
specification [1] and the druntime documentation [2].
I also suggest reading the excellent GC series on the official 
language blog [3].
Additionally, in this [5] - despite being mostly about the Go GC 
- gives a good overview of garbage collection in general.




[1] https://dlang.org/spec/garbage.html
[2] https://dlang.org/phobos/core_memory.html
[3] https://dlang.org/blog/the-gc-series/
[4] 
http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html
[5] 
https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e?gi=78635e05a6ac#.6zz5an77a

Re: GC

[Marc Schütz via Digitalmars-d-learn]

On Sunday, 30 July 2017 at 09:12:53 UTC, piotrekg2 wrote:
I would like to learn more about GC in D. For example can 
anyone explain why do we need memset(0) here: 
https://github.com/dlang/phobos/blob/master/std/container/array.d#L356 , doesn't it assume a certain type of GC? What if there is a need to change the GC algorithm in the future?


The current GC is a conservative one, which means that it has at 
best an incomplete knowledge of the types in the memory it scans. 
Therefore, whenever it sees a value that, when interpreted as a 
pointer, points to a pool of memory owned by the GC, it needs to 
assume that it is indeed a pointer, which means it has to keep 
the referenced object alive.


A false pointer is one that only looks like a valid pointer but 
is in reality some other kind of data, or in this case data in a 
block of memory that's still allocated, but no longer actually in 
use. False pointers can keep GC-managed objects alive that could 
actually be freed, so they're something that should be avoided. 
The container overwrites the memory with zeroes because a zero 
value is never a valid pointer.


Changing the GC algorithm would do no harm here. The best we 
could hope for is that the GC at some pointer becomes fully 
precise (unlikely), so it can distinguish false from real 
pointers by itself. In this case, the memset would become 
unnecessary, but it wouldn't lead to wrong behaviour.

Re: Static array * scalar is not working for me

[Marc Schütz via Digitalmars-d-learn]

On Sunday, 30 July 2017 at 08:18:07 UTC, Danni Coy wrote:

The following code is not working for me

float[3] f;
f[] = abs(f)[] * -1.0f;
where abs is a function that returns a float[3];

it complains that f should be attached to some memory.

Is it a bug or am I missing something?


I cannot reproduce the error with the code you've given. It's 
either missing some import, or a definition of `abs()`. The one 
in std.math doesn't accept arrays at all.

Re: GC

[rikki cattermole via Digitalmars-d-learn]

On 30/07/2017 10:12 AM, piotrekg2 wrote:
I would like to learn more about GC in D. For example can anyone explain 
why do we need memset(0) here: 
https://github.com/dlang/phobos/blob/master/std/container/array.d#L356 , 
doesn't it assume a certain type of GC? What if there is a need to 
change the GC algorithm in the future?


It would be great if you could point me out to articles on this subject.


Basically instead of having possibly random data in the array, it forces 
it to be all 0.


What its protecting against is false pointers and stopping the GC seeing 
a reference to a block of memory that doesn't exist.


It's just general protection against GC's thinking that memory is alive 
when it isn't. More of a problem for 32bit than 64bit. Hasn't got much 
to do with the algorithm :)

GC

[piotrekg2 via Digitalmars-d-learn]

I would like to learn more about GC in D. For example can anyone 
explain why do we need memset(0) here: 
https://github.com/dlang/phobos/blob/master/std/container/array.d#L356 , doesn't it assume a certain type of GC? What if there is a need to change the GC algorithm in the future?


It would be great if you could point me out to articles on this 
subject.

Static array * scalar is not working for me

[Danni Coy via Digitalmars-d-learn]

The following code is not working for me

float[3] f;
f[] = abs(f)[] * -1.0f;
where abs is a function that returns a float[3];

it complains that f should be attached to some memory.

Is it a bug or am I missing something?

Re: Accessing memory after destroy

[ketmar via Digitalmars-d]

Johan Engelen wrote:

If this is the case, then we really need to improve and pin-down the spec 
on this point.


So `destroy` only calls the destructor and puts the object in 
`T.initializer` (non-constructed) state, and is otherwise not related to 
memory deallocation.

May the destructor be called again when the GC collects the memory?
Why is the object put in `T.initializer` state?

To make sure: My question is from a spec point of view. Not about what 
currently happens and what is "OK" with the current implementation.


afair, somewhere in the spec there is a mention that dtor will be called 
at most once for each initialized object. and object state doesn't have any 
sense after calling dtor, but D still has to put something there, so 
`.init` looks like a reasonable choice. althru i'm not sure that anything 
in specs says that runtime *must* clear destroyed objects (they aren't 
really usable after calling dtor anyway, it is at least a logical bug to use 
object after destroying it).

Re: Accessing memory after destroy

[Johan Engelen via Digitalmars-d]

On Saturday, 29 July 2017 at 23:09:38 UTC, Jonathan M Davis wrote:


[1] https://dlang.org/spec/class.html#deallocators


If destroy has been called on a class object, then it is a bug 
to access it at any point after that (IIRC, the expectation is 
that it will blow up in your face, because the vtable is gone - 
TDPL talks about this, I believe, but I don't know where my 
copy is at the moment, so I can't check). That being said, the 
memory is still valid. And as Moritz pointed out, if the memory 
is accessible, the GC won't free it. So, it's a bug to access 
the object, but it should be memory safe to do so.


If this is the case, then we really need to improve and pin-down 
the spec on this point.


So `destroy` only calls the destructor and puts the object in 
`T.initializer` (non-constructed) state, and is otherwise not 
related to memory deallocation.
May the destructor be called again when the GC collects the 
memory?

Why is the object put in `T.initializer` state?

To make sure: My question is from a spec point of view. Not about 
what currently happens and what is "OK" with the current 
implementation.

Re: Questions about dmd source

[ketmar via Digitalmars-d-learn]

Francis Nixon wrote:


I have two completely unrelated questions about the dmd source code.

1. What does the mtype.Type.dotExp method do? The documentation comment 
says that it "Accesses the members of the object e". I'm not sure exactly 
why I would want to do that? Is it for handling types specified using an 
identifier/template chain (aka foo.bar!(uint).c)?
types has some built-in properties, like `.length`, `.sizeof`, `.init` and 
so on. this method is used to access those properties.



2. I've noticed there are some rather long methods in the dmd source, 
involving more than one goto; parse.d is particularly bad. Is there a 
reason for this/is it being fixed?
it just was done this way. dmd parser was "evolved", so what you see is a 
result of evolution (it is not stopeed yet ;-), and evolution doesn't 
produce ideal results. there is no need to specifically "fix" working 
things, it doesn't do any good.

Re: Questions about dmd source

[Anton Fediushin via Digitalmars-d-learn]

On Sunday, 30 July 2017 at 06:18:16 UTC, Francis Nixon wrote:
I have two completely unrelated questions about the dmd source 
code.


2. I've noticed there are some rather long methods in the dmd 
source, involving more than one goto; parse.d is particularly 
bad. Is there a reason for this/is it being fixed?


It is impossible to write short parser, and goto operators are 
quite useful in such code.
Also, there is no need to rewrite anything unless it is slow or 
buggy, and parse.d probably isn't.