date:20160517

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

Steven Schveighoffer  changed:

   What|Removed |Added

Summary|Compiler error when |Compiler crashes with
   |compiling specific union|inout, templates, and
   ||recursion

--

[Issue 16035] Compiler error when compiling specific union

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

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords|ice |ice-on-invalid-code

--- Comment #3 from Steven Schveighoffer  ---
It has something to do with inout, not with unions.

Reduced case:

struct Value {
auto toString() inout {
get!string;
}

T get(T)() {
a[0].toString();
}

const(Value)* a;
}


Remove inout, and this fails to compile:

testunion.d(7): Error: mutable method testunion.Value.toString is not callable
using a const object
testunion.d(3): Error: template instance testunion.Value.get!string error
instantiating

--

Re: Void pointers


On Tuesday, 17 May 2016 at 13:25:34 UTC, ag0aep6g wrote:

On 05/17/2016 03:14 PM, Alex wrote:
For a slice I surely need two numbers. But this should all be, 
what I
need for a slice. For a iota, I need a maximum, which is not 
provided
(at least at this moment) to the object containing the 
pointer/iota thing.


The slice's length is practically the same as iota's maximum. 
For slicing a pointer you need the minimum and the maximum, 
just as with iota. I don't see the difference.


ptr[5 .. 10] vs iota(5, 10) - Surely you need the number 10 in 
both cases?


Ok cool, maybe I oversee something myself. But let think in an 
example:
There are some objects which make slices. How they make a slice 
is unimportant here, so it makes either ptr[5 .. 10] or iota(5, 
10).
But, if the slicing is made by means of iota, there is no (at 
least no explicit) dependence between the slices, which could be 
made by different objects.
I'm ready to admit, that the process will work with independent 
slicing... In this case, I can omit my void* at all. So, the 
objects, which make slices, don't do this from some object, they 
do this just by calling iota. But this is little bit contra 
intuitive, as I imply a relationship between the sliced parts.
So... at the end of the day this implication exists in my head 
only...

[Issue 16035] Compiler error when compiling specific union

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

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords||ice
 CC||schvei...@yahoo.com
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #2 from Steven Schveighoffer  ---
I think it's an infinite recursion. I don't get any specific errors, just
segfault while compiling.

--

[Issue 16035] Compiler error when compiling specific union

2016-05-17 Thread Steven Schveighoffer via Digitalmars-d

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

--- Comment #1 from Márcio Martins  ---
Are there any known workarounds?

--

Re: PropertyType


On 5/17/16 10:50 AM, Edwin van Leeuwen wrote:

On Tuesday, 17 May 2016 at 14:24:09 UTC, Steven Schveighoffer wrote:

I have this little helper in my iopipe library:

template PropertyType(alias x)
{
static if(is(typeof(x) == function))
alias PropertyType = typeof(x());
else
alias PropertyType = typeof(x);
}



FYI: In painlesstraits we use a different approach, where we test
whether it is a function (with isSomeFunction) and then test for the
property attribute:

https://github.com/msoucy/painlesstraits/blob/master/source/painlesstraits.d#L173

```
static if (isSomeFunction!(T))
 {
 return (functionAttributes!(T) & FunctionAttribute.property);
 } else
 return false;
```



My code is less concerned as to whether it is a property or not. I just 
want to know the type of the expression :)


-Steve

Re: D's Auto Decoding and You

2016-05-17 Thread Jack Stouffer via Digitalmars-d-announce

On Tuesday, 17 May 2016 at 14:44:06 UTC, Steven Schveighoffer 
wrote:

...


Thanks, fixed all issues.


Like the article, pretty much sums up my thoughts too.


Thanks!

[Issue 16035] New: Compiler error when compiling specific union

2016-05-17 Thread Ola Fosheim Grøstad via Digitalmars-d

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

  Issue ID: 16035
   Summary: Compiler error when compiling specific union
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: marcio...@gmail.com

import std.conv;
struct Value {
auto toString() inout {
get!string;
}

T get(T)() {
storage_.a[0].to!T;
}

union Storage {
const(Value)* a;
}

Storage storage_;
}

--

Re: Always false float comparisons


On Monday, 16 May 2016 at 19:38:10 UTC, Joakim wrote:
Regarding floating-point, I'll go farther than you and say that 
if an algorithm depends on lower-precision floating-point to be 
accurate, it's a bad algorithm.


No. In system level programming a good algorithm is an effective 
and efficient algorithm on the hardware at hand.


A good system level programming language give you control at the 
hardware level. Including the floating point unit, in the 
language itself.


There are lots of algorithms that will break if you randomly 
switch precision of different expressions.


Heck, nearly all of the SIMD optimizations on differentials that 
I use will break if one lane is computed with a different 
precision than the other lanes. I don't give a rats ass about 
increased precision. I WANT THE DAMN LANES TO BE IN THE SAME 
PHASE (or close to it)!! Phase-locking is much more important 
than value accuracy.


Or to put it differently: It does not matter if all clocks are 
too slow, as long as they are running at the same speed. It is a 
lot worse if some clocks are too slow and others are too fast. 
That would lead to some serious noise in a time series.


Of course, no hardware vendor is crazy enough to randomly switch 
precision on their ALU. Hardware vendors do understand that this 
_WILL_ lead disaster. Sadly many in the D community don't. 
Presumably because they don't actually try to write performant 
floating point code, they are not system level programmers.


(Btw, many error correcting strategies break too if you randomly 
switch precision.)


Now, people can always make mistakes in their implementation 
and unwittingly depend on lower precision somehow, but that 
_should_ fail.


People WILL make mistakes, but if you cannot control precision 
then you cannot:


1. create a reference implementation to compare with

2. unit test floating point code in a reliable way

3. test for convergence/divergence in feedback loops (which can 
have _disastrous_ results and could literally ruin your 
speakers/hearing in the case of audio).


None of this is controversial to me: you shouldn't be comparing 
floating-point numbers with anything other than approxEqual,


I don't agree.

1. Comparing typed constants for equality should be 
unproblematic. In D that is broken.


2. Testing for zero is a necessity when doing division.

3. Comparing for equality is the same as subtraction followed by 
testing for zero.


So, the rule is: you shouldn't compare at all unless you know the 
error bounds, but that depends on WHY you are comparing.


However, with constants/sentinels and some methods you do know... 
Also, with some input you do know that the algorithm WILL fail 
for certain values at a _GIVEN_ precision. Testing for equality 
for those values makes a lot of sense, until some a**hole decides 
to randomly "improve" precision where it was typed to something 
specific and known.


Take this:

f(x) = 1/(2-x)

Should I not be able to test for the exact value "2" here? I 
don't see why "1.3" typed to a given precision should be 
different. You want to force me to a more than 3x more expensive 
test just to satisfy some useless FP semantic that does not 
provide any real world benefits whatsoever?



increasing precision should never bother your algorithm, and a 
higher-precision, common soft-float for CTFE will help 
cross-compiling and you'll never notice the speed hit.


Randomly increasing precision is never a good idea. Yes, having 
different precision in different code paths can ruin the quality 
of both rendering, data analysis and break algorithms.


Having infinite precision untyped real that may downgrade to say 
64 bits mantissa is acceptable. Or in the case of Go, a 256 bit 
mantissa. That's a different story.


Having single precision floats that randomly are turned into 
arbitrary precision floats is not acceptable. Not at all.

Re: Supporting musl libc

2016-05-17 Thread Steven Schveighoffer via Digitalmars-d-announce


On 2016-05-17 15:42, Wyatt wrote:


It's worth noting that musl does support a lot of GNU-isms, but the
debug stuff is probably not on the table.  Here's some background on
that from Rich Felker himself:

http://www.openwall.com/lists/musl/2015/04/09/3


Yeah, I saw that post.

--
/Jacob Carlborg

Re: PropertyType

2016-05-17 Thread Edwin van Leeuwen via Digitalmars-d

On Tuesday, 17 May 2016 at 14:24:09 UTC, Steven Schveighoffer 
wrote:

I have this little helper in my iopipe library:

template PropertyType(alias x)
{
static if(is(typeof(x) == function))
alias PropertyType = typeof(x());
else
alias PropertyType = typeof(x);
}



FYI: In painlesstraits we use a different approach, where we test 
whether it is a function (with isSomeFunction) and then test for 
the property attribute:


https://github.com/msoucy/painlesstraits/blob/master/source/painlesstraits.d#L173
```
static if (isSomeFunction!(T))
{
return (functionAttributes!(T) & 
FunctionAttribute.property);

} else
return false;
```

Re: D's Auto Decoding and You


Grammar:

"This will tie in later because the string types front has special behavior"

...because for string types, front has...

Content:
"For C style strings, you can use ubyte[] and call std.string.assumeUTF 
where necessary"


Actually, C style strings are ASCII, no? UTF8 includes ASCII. And D 
treats C strings as char *, not ubyte[]


Content:

D will look ahead in the string and combine things like e and U+0308 into ë

Nope :) This is a grapheme, and D does not decode these into one dchar.

Grammar:

"about it's inclusion"

it's -> its

Typo:

"Pared with the inability to turn it off,"

Pared -> Paired

Typo:

"Phobos String type would be the best option and a deprecation of the 
sting front function"


sting -> string

Like the article, pretty much sums up my thoughts too. IMO, the only 
path forward is something that aliases string to something that 
auto-decodes, but that is NOT a char array. Then you have to deprecate 
implicit access to the backing array, and make it explicit. Probably 
would take 2 years or so to migrate.


-Steve

Re: 2DRPG - Small console game

2016-05-17 Thread extrawurst via Digitalmars-d-announce

On Thursday, 12 May 2016 at 18:30:04 UTC, Vladimirs Nordholm 
wrote:

...


I have had lots of fun during the development of 2DRPG. There 
have been many difficulties, but I have learned much from 
making this game. Sadly this game is Windows only, meaning 
POSIX users cannot play it. This is due to technical 
limitations in my own console engine, scone 
(https://github.com/vladdeSV/scone), which cannot read input on 
POSIX terminals.



Please make it work on posix ;)

Re: D's Auto Decoding and You

2016-05-17 Thread Jack Stouffer via Digitalmars-d-announce

On Tuesday, 17 May 2016 at 14:16:48 UTC, Steven Schveighoffer 
wrote:

Starting to read it, see errors in your examples:

is(s[0] == immutable char) -> is(typeof(s[0]) == 
immutable(char))

is(s.front == dchar) -> is(typeof(s.front()) == dchar)


Thanks, fixed.

PropertyType

2016-05-17 Thread Steven Schveighoffer via Digitalmars-d


I have this little helper in my iopipe library:

template PropertyType(alias x)
{
static if(is(typeof(x) == function))
alias PropertyType = typeof(x());
else
alias PropertyType = typeof(x);
}

This is because when you have code like this:

x.foo

And you are introspecting some type, you can't tell whether this is a 
property function or a field.


If foo is a field, or a function marked as a @property, then 
typeof(x.foo) will be whatever x.foo returns. But if foo is a straight 
function, then typeof(x.foo) will be a function type.


As we all know, @property is not exactly popular, and having to mark 
functions @property just for introspection purposes (applying the tag 
actually has zero impact otherwise) seems incorrect.


But of course, if I want to know what type the expression x.foo will 
yield, I have to do the above.


Is there a use for this in Phobos? Is it already present somewhere? 
Where should it go if it's not there already?


-Steve

Re: Github names & avatars

2016-05-17 Thread Manu via Digitalmars-d

On 17 May 2016 at 23:08, Steven Schveighoffer via Digitalmars-d
 wrote:
> On 5/17/16 12:39 AM, Manu via Digitalmars-d wrote:
>>
>> On 14 May 2016 at 03:18, Steven Schveighoffer via Digitalmars-d
>>  wrote:
>>>
>>> On 5/13/16 1:02 PM, Walter Bright wrote:


 I'll ask again that the active Github users use their own name, and add
 to that if you could have a selfie as your github image.
>>>
>>>
>>>
>>> Sorry, this isn't going to happen :) @schveiguy is much better than
>>> @StevenSchveighoffer. Some of us are not so short-name-blessed. I
>>> actually
>>> don't mind if people call me schveiguy!
>>
>>
>> You know that github has separate records for your handle and your
>> name...? Both are presented on github.
>>
>
> Yes, I know. And to make matters worse, when I get github emails, the full
> name is used, but when I look at the PR comments, only the handle appears.
> So it's not always obvious the mapping between the two.
>
> It's unclear whether the request from Walter was for handles or names (his
> full name is used for both).

Right. It seems unreasonable to ask people to change their handles. In
most cases, people have been using the same handle for decades...

Re: unit-threaded v0.6.13 - tags, autotags and support for integration tests

2016-05-17 Thread Meta via Digitalmars-d-announce


On Tuesday, 17 May 2016 at 09:54:15 UTC, Marc Schütz wrote:

You surely mean "used to be destroy", right?


Good question... If I write this:

struct Test
{
~this() { writeln("destroying Test"); }
}

with (Test())
{
//Do stuff
}

Will Test's destructor be run once we exit the `with` scope?

Re: Issue with casting types

2016-05-17 Thread Thorsten Sommer via Digitalmars-d-learn

On Tuesday, 17 May 2016 at 13:13:54 UTC, Steven Schveighoffer 
wrote:

On 5/17/16 8:59 AM, Steven Schveighoffer wrote:

I think you need to avoid it for now. Please file an issue.


I see from ag0aep6g, that there is already an issue. I updated 
it.


-Steve


Thanks ag0aep6g and Steve for the fast help :) The D community is 
great :)

Re: D's Auto Decoding and You

2016-05-17 Thread Steven Schveighoffer via Digitalmars-d-announce


On 5/17/16 10:06 AM, Jack Stouffer wrote:

http://jackstouffer.com/blog/d_auto_decoding_and_you.html

Based on the recent thread in General, I wrote this blog post that's
designed to be part beginner tutorial, part objective record of the
debate over it, and finally my opinions on the matter.

When I first learned about auto-decoding, I was kinda miffed that there
wasn't anything in the docs or on the website that went into more
detail. So I wrote this in order to introduce people who are getting
into D to the concept, it's benefits, and downsides. When people are
confused in Learn why typeof(s.front) == dchar then this can just be
linked to them.

If you think there should be any more information included in the
article, please let me know so I can add it.


Starting to read it, see errors in your examples:

is(s[0] == immutable char) -> is(typeof(s[0]) == immutable(char))
is(s.front == dchar) -> is(typeof(s.front()) == dchar)

I'm not sure if you need the parens after front, but if it's not marked 
as @property, then this returns a function.


-Steve

D's Auto Decoding and You

2016-05-17 Thread Jack Stouffer via Digitalmars-d-announce


http://jackstouffer.com/blog/d_auto_decoding_and_you.html

Based on the recent thread in General, I wrote this blog post 
that's designed to be part beginner tutorial, part objective 
record of the debate over it, and finally my opinions on the 
matter.


When I first learned about auto-decoding, I was kinda miffed that 
there wasn't anything in the docs or on the website that went 
into more detail. So I wrote this in order to introduce people 
who are getting into D to the concept, it's benefits, and 
downsides. When people are confused in Learn why typeof(s.front) 
== dchar then this can just be linked to them.


If you think there should be any more information included in the 
article, please let me know so I can add it.

Re: Always false float comparisons

2016-05-17 Thread Wyatt via Digitalmars-d


On Monday, 16 May 2016 at 12:37:58 UTC, Walter Bright wrote:


7. 80 bit reals are there and they work. The support is mature, 
and is rarely worked on, i.e. it does not consume resources.


This may not be true for too much longer-- both Intel and AMD are 
slowly phasing the x86 FPU out.  I think Intel already announced 
a server chip that omits it entirely, though I can't find the 
corroborating link.


-Wyatt

Re: Always false float comparisons

2016-05-17 Thread Matthias Bentrup via Digitalmars-d

If you try to make compile-time FP math behave exactly like 
run-time FP math, you'd not only have to use the same precision 
in the compiler, but also the same rounding mode, denormal 
handling etc., which can be changed at run time 
(http://dlang.org/phobos/core_stdc_fenv.html), so the exact same 
piece of code can yield different results based on the run-time 
FP-context.

Re: Always false float comparisons

2016-05-17 Thread jmh530 via Digitalmars-d


On Tuesday, 17 May 2016 at 07:47:58 UTC, Ethan Watson wrote:


Unless you're doing game/graphics work ;-) 4x3 or 4x4 matrices 
are commonly used to represent transforms in 3D space in every 
3D polygon-based rendering pipeline I know of. It's even a 
requirement for fixed-function OpenGL 1.x.


Video games - also known around here as "The Exception To The 
Rule".


(Side note: My own preference is to represent transforms as a 
quaternion and vector. Inverting such a transform is a simple 
matter of negating a few components. Generating a matrix from 
such a transform for rendering purposes is trivial compared to 
matrix inversion.)


I don't know much about computer graphics, but if you're solving 
equations, then you can use the techniques mentioned above.


Nevertheless, I'm not really sure what would be the fastest 
approach to inverting small matrices. I would definitely try the 
LU or Cholesky approaches. It might be that for a small matrix a 
Gaussian reduction approach would be fast. There are some 
analytic tricks you could use if you have some information about 
them, like when you can represent them as blocks. If some of the 
blocks are zero or identity matrices, then it simplifies the 
calculations too.

DDT 1.0.0 released.

2016-05-17 Thread Bruno Medeiros via Digitalmars-d-announce

New DDT release out: dfmt support, performance improvements to semantic 
operations, more build command customization, fixes. Please see 
changelog for full list:


https://github.com/DDT-IDE/DDT/releases/tag/v1.0.0

Since DDT has generally been quite stable, and since the current release 
is very close to the end-game vision I had for a D IDE - at least as far 
as my free time would allow to create - I've decided to version this as 
1.0. I've been working for nearly 8 years on this project after all 
(with some intermission periods), so I guess 1.0 was a bit due... O.o'


I expect it will mainly be small updates from now on, not any major new 
features (other than perhaps DCD support).


--
Bruno Medeiros
https://twitter.com/brunodomedeiros

Re: Supporting musl libc

2016-05-17 Thread Wyatt via Digitalmars-d


On Tuesday, 17 May 2016 at 08:51:01 UTC, Jacob Carlborg wrote:


The issue is that musl doesn't support the functions defined by 
execinfo.h: backtrace, backtrace_symbols_fd and 
backtrace_symbols, since these are glibc extensions.


It's worth noting that musl does support a lot of GNU-isms, but 
the debug stuff is probably not on the table.  Here's some 
background on that from Rich Felker himself:


http://www.openwall.com/lists/musl/2015/04/09/3

-Wyatt

Re: Always false float comparisons

2016-05-17 Thread Ola Fosheim Grøstad via Digitalmars-d


On Monday, 16 May 2016 at 15:11:21 UTC, Daniel Murphy wrote:

On 16/05/2016 10:37 PM, Walter Bright wrote:

Some counter points:

1. Go uses 256 bit soft float for constant folding.



Then we should use 257 bit soft float!


Go uses at least 288 bits! (256 bits mantissa and 32 bits 
exponent).


But Go has a completely different take on constant expressions, 
and much better than the C family that D belongs to (but still 
far from ideal). From https://golang.org/ref/spec:


«
Numeric constants represent exact values of arbitrary precision 
and do not overflow. Consequently, there are no constants 
denoting the IEEE-754 negative zero, infinity, and not-a-number 
values.


Constants may be typed or untyped. Literal constants, true, 
false, iota, and certain constant expressions containing only 
untyped constant operands are untyped.


A constant may be given a type explicitly by a constant 
declaration or conversion, or implicitly when used in a variable 
declaration or an assignment or as an operand in an expression. 
It is an error if the constant value cannot be represented as a 
value of the respective type. For instance, 3.0 can be given any 
integer or any floating-point type, while 2147483648.0 (equal to 
1<<31) can be given the types float32, float64, or uint32 but not 
int32 or string.


An untyped constant has a default type which is the type to which 
the constant is implicitly converted in contexts where a typed 
value is required, for instance, in a short variable declaration 
such as i := 0 where there is no explicit type. The default type 
of an untyped constant is bool, rune, int, float64, complex128 or 
string respectively, depending on whether it is a boolean, rune, 
integer, floating-point, complex, or string constant.


Implementation restriction: Although numeric constants have 
arbitrary precision in the language, a compiler may implement 
them using an internal representation with limited precision. 
That said, every implementation must:


Represent integer constants with at least 256 bits.
Represent floating-point constants, including the parts of a 
complex constant, with a mantissa of at least 256 bits and a 
signed exponent of at least 32 bits.
Give an error if unable to represent an integer constant 
precisely.
Give an error if unable to represent a floating-point or complex 
constant due to overflow.
Round to the nearest representable constant if unable to 
represent a floating-point or complex constant due to limits on 
precision.
These requirements apply both to literal constants and to the 
result of evaluating constant expressions.

»

See also https://golang.org/ref/spec#Constant_expressions

Re: Void pointers

2016-05-17 Thread Steven Schveighoffer via Digitalmars-d


On 05/17/2016 03:14 PM, Alex wrote:

For a slice I surely need two numbers. But this should all be, what I
need for a slice. For a iota, I need a maximum, which is not provided
(at least at this moment) to the object containing the pointer/iota thing.


The slice's length is practically the same as iota's maximum. For 
slicing a pointer you need the minimum and the maximum, just as with 
iota. I don't see the difference.


ptr[5 .. 10] vs iota(5, 10) - Surely you need the number 10 in both cases?

Re: Interest in Boston area D meetups?

2016-05-17 Thread Andrea Fontana via Digitalmars-d

On Tuesday, 17 May 2016 at 13:17:35 UTC, Steven Schveighoffer 
wrote:
Is anyone interested in having D meetups in Boston area? I'm 
not familiar with really any other locals (well, there is one 
person I know of :)


-Steve


We should build a page with a map of "registered d developers". 
It would be funny :)

Interest in Boston area D meetups?

Is anyone interested in having D meetups in Boston area? I'm not 
familiar with really any other locals (well, there is one person I know 
of :)


-Steve

Re: Void pointers

2016-05-17 Thread Steven Schveighoffer via Digitalmars-d-learn


On Tuesday, 17 May 2016 at 12:24:58 UTC, ag0aep6g wrote:

On 05/17/2016 12:53 PM, Alex wrote:
2. If I want to be able to slice a iota, I have to initialize 
it with
the last number. But the object, which stores the pointer does 
not need
to know anything about this number. So, I rather would not 
like to pass

this number only for being able to instantiate the iota struct.


How do you make a slice without the last number? You need two 
numbers for iota, and you need two numbers for a slice.


For a slice I surely need two numbers. But this should all be, 
what I need for a slice. For a iota, I need a maximum, which is 
not provided (at least at this moment) to the object containing 
the pointer/iota thing.
On the other hand, I can't live without a "real" object which I 
slice, so I need either a iota or a pointer. This is due that all 
the slices I have are totally ordered.

Re: Issue with casting types


On 5/17/16 8:59 AM, Steven Schveighoffer wrote:

I think you need to avoid it for now. Please file an issue.


I see from ag0aep6g, that there is already an issue. I updated it.

-Steve

[Issue 16033] std.algorithm.sorting.sort should be possible with const/immutable object

2016-05-17 Thread Steven Schveighoffer via Digitalmars-d

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--

Re: Github names & avatars


On 5/17/16 12:39 AM, Manu via Digitalmars-d wrote:

On 14 May 2016 at 03:18, Steven Schveighoffer via Digitalmars-d
 wrote:

On 5/13/16 1:02 PM, Walter Bright wrote:


I'll ask again that the active Github users use their own name, and add
to that if you could have a selfie as your github image.



Sorry, this isn't going to happen :) @schveiguy is much better than
@StevenSchveighoffer. Some of us are not so short-name-blessed. I actually
don't mind if people call me schveiguy!


You know that github has separate records for your handle and your
name...? Both are presented on github.



Yes, I know. And to make matters worse, when I get github emails, the 
full name is used, but when I look at the PR comments, only the handle 
appears. So it's not always obvious the mapping between the two.


It's unclear whether the request from Walter was for handles or names 
(his full name is used for both).


-Steve

[Issue 16033] std.algorithm.sorting.sort should be possible with const/immutable object

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
> In my understanding elements can be immutable and const, but assigning
> elements isn't. So shouldn't it be possible to use emplace to swap them
> around?

Swapping stuff around means writing (to both locations). But you can't
overwrite immutable data, and you can't write through a const reference. So no,
you can't swap const or immutable elements. Doing so would break the guarantees
that const and immutable give.

Closing as invalid. Please reopen if I'm missing something. Or maybe make a
thread on D.learn if the details of immutable and const are not clear.
http://forum.dlang.org/group/learn

--

[Issue 6777] alias this + cast(void*) == bug

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com
   Severity|normal  |blocker

--- Comment #7 from Steven Schveighoffer  ---
This effectively disables dynamic casting, as Jakob says. Changing to blocker,
this is not a trivial bug to work around.

Came up again recently:

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

--

[Issue 6777] alias this + cast(void*) == bug

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

Steven Schveighoffer  changed:

   What|Removed |Added

   Hardware|Other   |All
 OS|Windows |All

--

[Issue 6777] alias this disables casting for classes

2016-05-17 Thread Bruno Medeiros via Digitalmars-d-announce

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

Steven Schveighoffer  changed:

   What|Removed |Added

Summary|alias this + cast(void*) == |alias this disables casting
   |bug |for classes

--

Re: mago-mi: GDB/MI compatible frontend for Mago debugger

On 17/05/2016 09:06, Vadim Lopatin wrote:

Hello,

I'm working on GDB/MI compatible interface for Mago debugger on Windows.

GDB/MI is line based machine interface for debugger. IDEs are using GDB
via this interface.

GDB/MI docs: https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html

Project page (mago fork) https://github.com/buggins/mago

Currently mago-mi supports subset of GDB commands enough for current
DlangIDE functionality.

Tested on DMD generated 32bit executables.

See readme details list of implemented commands:
https://github.com/buggins/mago/tree/master/MagoMI/mago-mi

Difference from baseline https://github.com/rainers/mago files are minimal:
- Static linking for MagoNatDE and MagoNatEE
- Disabled some Mago debug logging

Building mago-mi from source is easy. I've tried MS Visual Studio 2013
and 2015. Don't forget to edit properties in mago/PropSheets. Buld
mago-mi project.

Since DlangIDE v0.6.1, it includes prebuilt mago-mi.exe (it will be
copied into bin directory by dub build) and default Debugger settings
are changed from gdb to mago-mi by default on Windows. If you already
used DlangIDE on your computer, check Edit/Preferences/Debugger setting
- change to "mago-mi" if "gdb" is specified.

If you want to try mago-mi and DlangIDE which is using it, you can
download binaries from
https://sourceforge.net/projects/crengine/files/DlangUI/dlangide-v061-magomi-v010-x86.zip/download
(or just sync to latest dlangide and use `dub run`). Bundle includes
DlangIDE, mago-mi, dub, and sample workspaces (helloworld and tetris).
Download size is 5.4Mb (seems small enough for IDE+debugger).

I hope my work will be useful for other IDE developers who is targeting
on Windows.
(Any IDE which uses gdb/mi interface)
I tried gdb and lldb-mi before, but did not managed to find working
compiler + debugger configuration. (Best combination was gdb + gdc, but
it was showing global variables instead of locals. For lldb-mi, I
haven't managed to find compiler which produces compatible debug info).

Best regards,
Vadim

Interesting. I was about to ask what was the main advantage over GDB? I
reckon it is that Mago can debug executables with the COFF and/or OMF
formats, right? (as opposed to GDB's DWARF format)

--
Bruno Medeiros
https://twitter.com/brunodomedeiros

Re: Issue with casting types

2016-05-17 Thread Steven Schveighoffer via Digitalmars-d-learn


On 5/17/16 8:24 AM, Thorsten Sommer wrote:

Dear all,

I run into an issue with a simple cast:
https://dpaste.dzfl.pl/8e7f7c545eb1

I have a base class and a class A with inherit from that base class:
A <- BaseClass

If the base class contains an "alias this", any casting attempt fails
because the "alias this" type gets considered. Thus, I defined the
opCast() to solve this. But now, the program crashes without any error
or exception...


It's a stack overflow.

obj1.to!OtherObject is going to basically lower to 
cast(OtherObject)obj1. Which then invokes your opCast. Which then 
invokes to, ...



Why does the casting operation consider the "alias this" at all? I mean:
The "alias this" type is int. If I try to cast with to!A, obviously int
does not match A!?


It shouldn't. This is a bug in the language. alias this should only be 
considered if the expression is invalid for the actual type.



Is there any practical solution? Or should I stop using "alias this" for
my classes? I like the "alias this" concept. But it caused some issue
for me...


I think you need to avoid it for now. Please file an issue.

-Steve

Re: D mentioned and criticized

2016-05-17 Thread Chris via Digitalmars-d


On Tuesday, 17 May 2016 at 12:02:02 UTC, Guillaume Piolat wrote:

On Tuesday, 17 May 2016 at 12:00:53 UTC, Guillaume Piolat wrote:
Nim is much more interesting as a D alternative, in the sense 
that it is a.


I give up, kept pressing ENTER while typing a message.


"... in the sense that it is a" ???

[Issue 16034] map should be possible with a reference only

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
Underlying issue: isInputRange!(One[]) is false.

--

Re: Issue with casting types


On 05/17/2016 02:24 PM, Thorsten Sommer wrote:

Dear all,

I run into an issue with a simple cast:
https://dpaste.dzfl.pl/8e7f7c545eb1

I have a base class and a class A with inherit from that base class:
A <- BaseClass

If the base class contains an "alias this", any casting attempt fails
because the "alias this" type gets considered. Thus, I defined the
opCast() to solve this. But now, the program crashes without any error
or exception...


You've got an infinite recursion there.

`A a2 = to!A(b1);` calls `b1.opCast!A()` which calls `to!A(this)` which 
is the very same call as `to!A(b1)`, so it calls `opCast!A()` again, and 
so on until the stack is exhausted and the program crashes.



Why does the casting operation consider the "alias this" at all? I mean:
The "alias this" type is int. If I try to cast with to!A, obviously int
does not match A!?


There's an issue on this: https://issues.dlang.org/show_bug.cgi?id=6777

I don't know if there's a good reason for the current behavior. Looks 
silly to me.



Is there any practical solution? Or should I stop using "alias this" for
my classes? I like the "alias this" concept. But it caused some issue
for me...


You can use the reinterpreting style of cast to circumvent features like 
alias this and opCast:


A a2 = * cast(A*)

[Issue 16034] New: map should be possible with a reference only

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

  Issue ID: 16034
   Summary: map should be possible with a reference only
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

the following doesn't work:

void main()
{
struct One
{
int entry = 1;
@disable this(this);
}
One[] ones = [One(), One()];

import std.algorithm.iteration: map;
import std.algorithm.comparison: equal;
assert(ones.map!`a.entry + 1`.equal([2, 2]));
}

foo.d(12): Error: template std.algorithm.iteration.map!"a.entry + 1".map cannot
deduce function from argument types !()(One[]), candidates are:
/usr/include/dlang/dmd/std/algorithm/iteration.d(450):   
std.algorithm.iteration.map!"a.entry + 1".map(Range)(Range r) if
(isInputRange!(Unqual!Range))

(It doesn't matter whether string or real lambda are used)

--

Re: Void pointers

2016-05-17 Thread Thorsten Sommer via Digitalmars-d-learn


On 05/17/2016 12:53 PM, Alex wrote:

2. If I want to be able to slice a iota, I have to initialize it with
the last number. But the object, which stores the pointer does not need
to know anything about this number. So, I rather would not like to pass
this number only for being able to instantiate the iota struct.


How do you make a slice without the last number? You need two numbers 
for iota, and you need two numbers for a slice.

Issue with casting types


Dear all,

I run into an issue with a simple cast:
https://dpaste.dzfl.pl/8e7f7c545eb1

I have a base class and a class A with inherit from that base 
class:

A <- BaseClass

If the base class contains an "alias this", any casting attempt 
fails because the "alias this" type gets considered. Thus, I 
defined the opCast() to solve this. But now, the program crashes 
without any error or exception...


Why does the casting operation consider the "alias this" at all? 
I mean: The "alias this" type is int. If I try to cast with to!A, 
obviously int does not match A!?


Is there any practical solution? Or should I stop using "alias 
this" for my classes? I like the "alias this" concept. But it 
caused some issue for me...



Best regards,
Thorsten

Re: Void pointers


On 05/17/2016 10:16 AM, Rene Zwanenburg wrote:

Additionally, some people recommend never using -release. It depends on
that type of program you're writing, but the performance gain is often
not worth the loss in safety. Think of the number of exploits enabled by
C's lack of bounds checking.


Some more details on this: -release doesn't affect bounds checking in 
@safe code. It will still be done there. There is another switch that 
disables bounds checks even in @safe code: -boundscheck=off

Re: LDC 1.0.0-beta2 has been released!

2016-05-17 Thread Joakim via Digitalmars-d-announce


On Tuesday, 17 May 2016 at 10:15:28 UTC, Vadim Lopatin wrote:

On Tuesday, 17 May 2016 at 05:51:29 UTC, Kai Nacke wrote:

Hi everyone,

LDC 1.0.0-beta2, the LLVM-based D compiler, is available for 
download!
This BETA release is based on the 2.070.2 frontend and 
standard library and supports LLVM 3.5-3.8.


The 1.0 release will be a major milestone. Please help testing 
to make it the best release ever!
We provide binaries for Linux, OX X, Win32 & Win64, Linux/ARM 
(armv7hf). :-)


As usual, you can find links to the changelog and the binary 
packages over at digitalmars.D.ldc:

http://forum.dlang.org/post/yryvlznqafivqznwz...@forum.dlang.org

Regards,
Kai


Does it contain Android support patches?


Most, but not all.  Also, the Android support depends on a 
slightly patched llvm for emulated TLS, so you'd have to build 
that modified llvm yourself.  However, llvm 3.8 finally came with 
its own emulated TLS support for ELF, so the plan is to move over 
to that and have Android support baked into these official ldc 
releases at some point.

Re: Void pointers


On 05/17/2016 08:53 AM, Alex wrote:

the elements of the slice are accessible just for reading, right, but
with them I reference the data in other objects.


If the slice's pointer is invalid, then its elements are not accessible 
at all.

Re: D mentioned and criticized

2016-05-17 Thread Guillaume Piolat via Digitalmars-d


On Tuesday, 17 May 2016 at 12:00:53 UTC, Guillaume Piolat wrote:
Nim is much more interesting as a D alternative, in the sense 
that it is a.


I give up, kept pressing ENTER while typing a message.

Re: D mentioned and criticized

2016-05-17 Thread Guillaume Piolat via Digitalmars-d


On Tuesday, 17 May 2016 at 11:58:57 UTC, Guillaume Piolat wrote:

On Tuesday, 17 May 2016 at 01:29:15 UTC, Xinok wrote:
It seems to me that Loci is not a very "inspired" language 
meaning that it doesn't take inspiration from many other 
languages. The docs only ever refer to some classic mainstream 
languages including C++, Obj-C, Java, C#, with a hint of D. 
There are a few nice aspects such as modules, algebraic types, 
tuples, and concepts. But then I feel like it takes too much 
from C++ and mimics Java-esque OOP and concepts. I'm not 
saying these are bad things but there isn't much that makes 
Loci stand out as a programming language.


Nim is much more interesting as a D alternative, in the sense 
that it is a.

Re: D mentioned and criticized

2016-05-17 Thread Guillaume Piolat via Digitalmars-d


On Tuesday, 17 May 2016 at 01:29:15 UTC, Xinok wrote:

On Monday, 16 May 2016 at 18:25:23 UTC, Chris wrote:

I had a look at Loci, more specifically the language goals[1]:
...


I've been skimming through the docs and found one mention of D:

http://loci-lang.org/Exceptions.html#scope-exit-block

It seems to me that Loci is not a very "inspired" language 
meaning that it doesn't take inspiration from many other 
languages. The docs only ever refer to some classic mainstream 
languages including C++, Obj-C, Java, C#, with a hint of D. 
There are a few nice aspects such as modules, algebraic types, 
tuples, and concepts. But then I feel like it takes too much 
from C++ and mimics Java-esque OOP and concepts. I'm not saying 
these are bad things but there isn't much that makes Loci stand 
out as a programming language.


Nim is much more interesting a.

Re: Battle-plan for CTFE

2016-05-17 Thread deadalnix via Digitalmars-d-announce


On Sunday, 15 May 2016 at 10:29:21 UTC, Martin Nowak wrote:

On 05/10/2016 08:45 AM, Jacob Carlborg wrote:


I was listening to a discussion Don and Daniel had about the 
current implementation of CTFE. They talked about using a byte 
code interpreter. Even implementing a really crappy byte code 
interpreter would be a huge improvement.


No need for a byte-code interpreter, it mostly just adds 
overhead and complexity over an AST interpreter. If you want to 
go really fast you need some sort of JIT anyhow, but a proper 
interpreter will be orders of mangnitude faster than the 
current implementation.


I might refer you to
http://dconf.org/2013/talks/chevalier_boisvert.pdf
page 59 ff.


+1 . One need to walk the tree anyway to generate bytecode, which 
makes it impossible to make it faster for a one time execution.


For frequent executions, then a JIT is preferable, which let the 
bytecode the favorite choice for more than one, but not too many 
executions.

[Issue 16033] New: std.algorithm.sorting.sort should be possible with const/immutable object

2016-05-17 Thread Ola Fosheim Grøstad via Digitalmars-d

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

  Issue ID: 16033
   Summary: std.algorithm.sorting.sort should be possible with
const/immutable object
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

The following yields:

void main()
{
import std.algorithm.sorting : sort;
const(int)[] arr = [1, 2, 3];
arr.sort();
}


foo.d(6): Error: template std.algorithm.sorting.sort cannot deduce function
from argument types !()(const(int)[]), candidates are:
/usr/include/dlang/dmd/std/algorithm/sorting.d(1027):   
std.algorithm.sorting.sort(alias less = "a < b", SwapStrategy ss =
SwapStrategy.unstable, Range)(Range r) if ((ss == SwapStrategy.unstable &&
(hasSwappableElements!Range || hasAssignableElements!Range) || ss !=
SwapStrategy.unstable && hasAssignableElements!Range) &&
isRandomAccessRange!Range && hasSlicing!Range && hasLength!Range)

In my understanding elements can be immutable and const, but assigning elements
isn't. So shouldn't it be possible to use emplace to swap them around?

--

Re: D mentioned and criticized

On Tuesday, 17 May 2016 at 11:42:45 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 17 May 2016 at 08:29:22 UTC, Chris wrote:
Ola first mentioned Loci in a recent thread. I'm always in 
favor of new PLs and / or ways of thinking. But I don't think 
it's good style to mention D in this way while not giving at 
least some reasons for doing so.


I think he was more elaborate in an earlier version of the 
website. IIRC he was  a D user, but gave up on the language due 
to the design/development process that he felt was going 
nowhere.


I think the main feature in Loci compared to C++ is that you 
can dynamically add interfaces to existing libraries from other 
languages using structural typing. So you can add polymorphism 
layers to existing C frameworks just by having pointers.


http://loci-lang.org/StructuralTyping.html


Using fat pointers, one to the data and one to the interface:

http://loci-lang.org/DynamicDispatch.html

Re: Supporting musl libc


On 2016-05-17 11:27, Joakim wrote:


It is a runtime option on Windows, when choosing between the Digital
Mars C runtime and the MSVC runtime, which is why those are also
predefined version identifiers.  The one for Glibc was added as an
afterthought in that Windows PR, and Bionic was also reserved last fall,
though my PR to actually define it has been in limbo for a year.  That's
mostly my fault: I never got back to it when I focused on ldc and
Android/ARM.

There was a lot of debate among the core team when even the Windows
CRuntime support was finalized, with Walter wanting to minimize such
predefined versions and some of the core team arguing against it even
after it was merged.  Even the iOS predefined version took 5 months to
get in, because there was debate whether Darwin should be allowed as a
common version for all Apple platforms.

The reason I'm mentioning all this is that adding predefined versions is
a matter of much debate, but that's how you'll likely implement it as a
runtime option.  There is no good answer on this right now: I suggest
you just implement it and worry about run-time versus compile-time when
you're done.  Since you'll be doing the same work either way, ie adding
or separating out a bunch of version blocks for musl in druntime, do it
any way you like for now and you can worry about merging that last bit
about compile-time vs runtime at the end.


It depends. One approach would be to add an option to the druntime 
makefile, which would add -version CRuntime_Musl when compiling. In that 
case version(CRuntime_Musl) needs to come before version(CRuntime_Glibc) 
when declaring the imports. It doesn't sound like a good idea, to depend 
on the order of the version statements, but it's still a possibility.


--
/Jacob Carlborg

[Issue 15966] [REG 2.071] {public,protected} imports in base class ignored on symbol lookup

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

--- Comment #11 from Mathias Lang  ---
(In reply to Walter Bright from comment #8)
> (In reply to Mathias Lang from comment #6)
> > A base class in another module can
> > already override global imports by introducing new local symbols.
> 
> The problem is if symbols are added to that import, then they have an
> unintended side effect of overriding local symbols in the derived class code.
> 
> Again, this is exactly the kind of problem this change was designed to stop.

They will only override imported symbols from outer scopes, not local ones. So
it would override module imports, but not module aliases, for example.
The same problem exists for mixin template, and by extension any "non-final
scope" have this "issue", but the recent change are much more sane and easy to
work with.

If you don't want this behavior, then `import` from base classes should not be
visible at all (even within the same module), or we'll end up in a weird place
with 2 or more different rules.

There is a better description of how I thought it would / should work as part
of:
https://issues.dlang.org/show_bug.cgi?id=16004

--

Re: Supporting musl libc


On 2016-05-17 11:32, Joakim wrote:


Jacob, when you said "runtime option," you meant when running the
compiler, right?


Exactly.


That's how I took it: the C library is chosen either
when building the compiler or running the compiler.  On Windows, it's
when running the compiler.


We introduced CRuntime_Glibc specifically to separate libc from kernel
differences, e.g. to support android.
Have a look at how -mscoff32 and Android are implememted in dmd.


Android is not in dmd yet, as I mentioned, you can look at my small PR
though:

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


Looks like a "runtime" option. It's not hard to implement, just a 
question of which approach we would like to use.


--
/Jacob Carlborg

Berlin D Meetup May 2016

2016-05-17 Thread Ben Palmer via Digitalmars-d-announce


Hi All,

Apologies for the late notice but the May Berlin D Meetup will be 
happening at 19:30 on Friday the 20th at Berlin Co-Op 
(http://co-up.de/) on the fifth floor.


The basic idea is to have a hackathon on improving the First 5 
Minutes as was discussed at the conference. This will be the 
first in a series of meetups/hackathons for working on this topic 
along with some future meetups planned for working with dub.


Both alcoholic and non-alcoholic drinks will be available.

Details are also on the meetup page here: 
http://www.meetup.com/Berlin-D-Programmers/


Thanks,
Ben.

Re: Supporting musl libc

2016-05-17 Thread Stefan Koch via Digitalmars-d-announce


On 2016-05-17 11:26, Martin Nowak wrote:


Shouldn't be runtime detected, but a linktime/compile option.
We introduced CRuntime_Glibc specifically to separate libc from kernel
differences, e.g. to support android.
Have a look at how -mscoff32 and Android are implememted in dmd.
At best defining CRuntime_Glibc should move into dmd.conf, where you
could also select a different phobos library to link.


In this case when I said "runtime", I meant runtime for the compiler. 
-mscoff32 is a different object format that just happens to use a 
different C runtime as well. But I guess we could add a new flag, 
-cruntime=musl or something.


--
/Jacob Carlborg

Re: Does DUB create .dll files?

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

On Tuesday, 17 May 2016 at 05:30:33 UTC, WhatMeWorry wrote:

I just incorporated DerelictALURE into a project and it
compiled and linked fine, but when I ran the executable, it
aborted with:

derelict.util.exception.SharedLibLoadException@N:\DUB_Packages\DerelictOrg\DerelictUtil\source\derelict\util\exception.d(35):
Failed to load one or more sharedlibraries:
ALURE32.dll - The specified module could not be found.

So I went back to DerelictOrg\derelict-alure-master\lib and I
see a DerelictALURE.lib file that was created, but nothing else.

Am I supposed to get ALURE32.DLL from somewhere outside of DUB,
or did I miss a step or command when I built
derelict-alure-master?

thanks.

The Derelict packages all provide *bindings* to C libraries, not
the shared libraries they bind to. You link statically with
DerelictFoo.lib, which is what happens automatically when you use
dub to manage your project and provide derelict-foo as a
dependency, then load libfoo.dll/so/dylib dynamically at runtime
with DerelictFoo.load. In order for this to work, the libfoo
shared library must be somewhere on the system path. For Windows,
you generally want to keep it in the same directory as your
executable. It's up to you to obtain the C shared library, either
through downloading a prebuilt binary or getting the C source and
building it yourself

In your specific case, ALURE is available at [1]. A precompiled
Windows binary is provided for download at the bottom of that
page.

[1] http://kcat.strangesoft.net/alure.html

Re: Battle-plan for CTFE


On Tuesday, 17 May 2016 at 10:42:30 UTC, Don Clugston wrote:


TL;DR:  CTFE is actually a backend, so don't be afraid of 
creating a glue layer for it.


My point exactly.
The AST is not something I want to handle while inside the 
interpreter.

It introduces too much complexity.
There needs to be some kind of further lowering.

Re: Void pointers

2016-05-17 Thread Don Clugston via Digitalmars-d-announce


On Tuesday, 17 May 2016 at 08:45:44 UTC, Alex wrote:

so...
besides
void*, ubyte*, a pointer to a strange, not constructible 
struct, I could take a iota too...


a comment on my own:
even every type of the above mentioned is possible, there are 
slightly differences between them:
1. As I don't want to be able to instantiate the type itself, I 
would like to drop ubyte*.
2. If I want to be able to slice a iota, I have to initialize it 
with the last number. But the object, which stores the pointer 
does not need to know anything about this number. So, I rather 
would not like to pass this number only for being able to 
instantiate the iota struct.


So this leave me again with the void* and a pointer to a strange, 
not constructible struct...

Re: Battle-plan for CTFE


On Sunday, 15 May 2016 at 12:17:30 UTC, Daniel Murphy wrote:

On 15/05/2016 9:57 PM, Martin Nowak wrote:

On 05/15/2016 01:58 PM, Daniel Murphy wrote:
The biggest advantage of bytecode is not the interpreter 
speed, it's
that by lowering you can substitute VarExps etc with actual 
references

to memory without modifying the AST.

By working with something lower level than the AST, you 
should end up

with something much less complex and with fewer special cases.


Which is a bad assessment, you can stick variable indexes into
VarDeclaration (we already do that) and thereby access them in 
O(1).
Converting control flow and references into byte code is far 
from

trivial, we're talking about another s2ir and e2ir here.

-Martin



For simple types that's true.  For more complicated reference 
types...


Variable indexes are not enough, you also need heap memory, but 
slices and pointers (and references) can refer to values either 
on the heap or the stack, and you can have a slice of a member 
static array of a class on the stack, etc.  Then there are 
closures...


Neither e2ir or s2ir are actually that complex.  A lot of the 
mess there comes from the backend IR interface being rather 
difficult to work with.
 We can already save a big chunk of complexity by not having to 
translate the frontend types.  E.g.  implementing the logic in 
the interpreter to correctly unwind through destructors is 
unlikely to be simpler than lowering to an IR.


Exactly. I think the whole idea of trying to avoid a glue layer 
is a mistake.
CTFE is a backend. It really is. And it should be treated as one. 
A very simple one, of course.
Once you do this, you'll find all sorts of commonalities with the 
existing glue layers.
We should end up with at least 4 backends: DMD, GCD, LDC, and 
CTFE.


Many people here are acting like this is something complicated, 
and making dangerous suggestions like using Phobos inside the 
compiler. (I think everyone who has fixed a compiler bug that was 
discovered in Phobos, will know what a nightmare that would be. 
The last thing compiler development needs is another level of 
complexity in the compiler).


As I've tried to explain, the problems with CTFE historically 
were never with the CTFE engine itself. They were always with the 
interface between CTFE and the remainder of the compiler -- 
finding every case where CTFE can be called, finding all the 
bizarre cases (tuple variables, variables without a stack because 
they are local variables declared in comma expressions in global 
scope, local 'ref' variables, etc), finding all the cases where 
the syntax trees were invalid...


There's no need for grandiose plans, as if there is some 
almost-insurmountable problem to be solved. THIS IS NOT 
DIFFICULT. With the interface cleaned up, it is the well-studied 
problem of creating an interpreter. Everyone knows how to do 
this, it's been done thousands of times. The complete test suite 
is there for you. Someone just needs to do it.


I think I took the approach of using syntax trees about as far as 
it can go. It's possible, but it's really vile. Look at the code 
for doing assignments. Bleagh. The only thing in its favour is 
that originally it was the only implementation that was possible 
at all. Even the first, minimal step towards creating a ctfe 
backend -- introducing a syntax-tree-validation step -- 
simplified parts of the code immensely.


You might imagine that it's easier to work with syntax trees than 
to start from scratch but I'm certain that's not true. I'm pretty 
sure that the simplest approach is to use the simplest possible 
machine-independent bytecode that you can come up with. I had got 
to the point of starting that, but I just couldn't face doing it 
in C++.


TL;DR:  CTFE is actually a backend, so don't be afraid of 
creating a glue layer for it.

Re: SDLang-D on Github

2016-05-17 Thread Sönke Ludwig via Digitalmars-d


Am 17.05.2016 um 11:45 schrieb Chris:

@Nick, fyi, when I compile the library with dmd v2.071.0, I get the
following warning:

sdlang-d 0.9.5: building configuration "library"...
src/sdlang/lexer.d(13,8): Deprecation: module std.stream is deprecated -
It will be removed from Phobos in October 2016. If you still need it, go
to https://github.com/DigitalMars/undeaD


Nice, I just saw that opening files with non-ASCII characters on Windows 
was recently fixed for std.stdio. Using std.stream is, I think, only 
used to work around that. I'll switch back to std.stdio in DUB, which 
has the same warning.

Re: LDC 1.0.0-beta2 has been released!

2016-05-17 Thread Vadim Lopatin via Digitalmars-d-announce


On Tuesday, 17 May 2016 at 05:51:29 UTC, Kai Nacke wrote:

Hi everyone,

LDC 1.0.0-beta2, the LLVM-based D compiler, is available for 
download!
This BETA release is based on the 2.070.2 frontend and standard 
library and supports LLVM 3.5-3.8.


The 1.0 release will be a major milestone. Please help testing 
to make it the best release ever!
We provide binaries for Linux, OX X, Win32 & Win64, Linux/ARM 
(armv7hf). :-)


As usual, you can find links to the changelog and the binary 
packages over at digitalmars.D.ldc:

http://forum.dlang.org/post/yryvlznqafivqznwz...@forum.dlang.org

Regards,
Kai


Does it contain Android support patches?

Re: The Case Against Autodecode

2016-05-17 Thread Kagamin via Digitalmars-d


On Friday, 13 May 2016 at 21:46:28 UTC, Jonathan M Davis wrote:
The history of why UTF-16 was chosen isn't really relevant to 
my point (Win32 has the same problem as Java and for similar 
reasons).


My point was that if you use UTF-8, then it's obvious _really_ 
fast when you screwed up Unicode-handling by treating a code 
unit as a character, because anything beyond ASCII is going to 
fall flat on its face.


On the other hand if you deal with UTF-16 text, you can't 
interpret it in a way other than UTF-16, people either get it 
correct or give up, even for ASCII, even with casts, it's that 
resilient. With UTF-8 problems happened on a massive scale in 
LAMP setups: mysql used latin1 as a default encoding and almost 
everything worked fine.

Re: Should core.stdc.signal.signal be nothrow @nogc??

2016-05-17 Thread Joakim via Digitalmars-d


On Tuesday, 17 May 2016 at 09:24:50 UTC, Bottled Genie wrote:

Can someone help me?

How can I call core.sys.linux.execinfo:backtrace from a 
core.stdc.signal: signal handler? The problem is that signal 
has been declared with @nogc in druntime and backtrace does not 
have that attribute.


There is a problem in druntime with @nogc and nothrow not 
covering all the C declarations they should.  If you're 
comfortable with writing up a PR to fix this issue, it'll most 
likely be merged:


http://wiki.dlang.org/Starting_as_a_Contributor

Re: unit-threaded v0.6.13 - tags, autotags and support for integration tests

2016-05-17 Thread Marc Schütz via Digitalmars-d-announce


On Monday, 16 May 2016 at 14:39:22 UTC, Meta wrote:

On Monday, 16 May 2016 at 08:37:48 UTC, Atila Neves wrote:

with(immutable Sandbox()) {
writeFile("foo.txt", "foobarbaz\ntoto"); // can also pass 
string[] for lines

shouldExist("foo.txt");
shouldNotExist("bar.txt");
shouldEqualLines("foo.txt", ["foobarbaz", "toto"]);
}


That's a really neat trick and an interesting use of `with`. I 
remember that variables initialized in the argument list of 
`with` used to not be destroyed after exiting the scope, I'm 
guessing that's not the case anymore? I vaguely remember a PR 
that fixed that.


You surely mean "used to be destroy", right? Yes, that's been 
fixed.




Anyway, congratulations on the new release!

SDLang-D on Github

2016-05-17 Thread Chris via Digitalmars-d

@Nick, fyi, when I compile the library with dmd v2.071.0, I get 
the following warning:


sdlang-d 0.9.5: building configuration "library"...
src/sdlang/lexer.d(13,8): Deprecation: module std.stream is 
deprecated - It will be removed from Phobos in October 2016. If 
you still need it, go to https://github.com/DigitalMars/undeaD


Also, maybe you should update the copyright notice in dub.json. 
It still says "2015".

Re: My ACCU 2016 keynote video available online

2016-05-17 Thread Rory McGuire via Digitalmars-d-announce

On Tue, May 17, 2016 at 10:42 AM, Bill Hicks via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Monday, 16 May 2016 at 13:46:11 UTC, Andrei Alexandrescu wrote:
>
>> Uses D for examples, showcases Design by Introspection, and rediscovers a
>> fast partition routine. It was quite well received.
>> https://www.youtube.com/watch?v=AxnotgLql0k
>>
>> Andrei
>>
>
> Incidentally, 2_000_000 D users have been waiting 10 years for one guy,
> you, to complete the containers/allocators and many other things.
>
> Man, this sh*t writes itself.
>
> And here you go again with your borderline racist jokes.  Not very cool.
> If you honestly want to find out if it's "confusing to Africans", I suggest
> you go to a black neighborhood and ask them.
>
>
>

As a South African, I can only say that you are talking nonsense regarding
the horse/zebra joke. If you've been to Africa you will understand; there
really are a lot more Zebra than horses. Although I must admit I think of
horses or Monty Python when I hear hoofbeats.

Andrei: Really good talk, thanks for sharing!

Re: Supporting musl libc

2016-05-17 Thread Joakim via Digitalmars-d


On Tuesday, 17 May 2016 at 08:51:01 UTC, Jacob Carlborg wrote:
As an alternative to glibc there's a C standard library called 
musl [1]. This is the C standard library used by ELLCC [2], a 
cross-compiler based on Clang. This cross-compiler makes it 
very easy to target other platforms and can be used as the C 
compiler when building with LDC.


The issue is that musl doesn't support the functions defined by 
execinfo.h: backtrace, backtrace_symbols_fd and 
backtrace_symbols, since these are glibc extensions. As far as 
I can see, these functions are used in two places in druntime: 
src/rt/backtrace/dwarf.d [3] and src/core/runtime.d [4].


The imports of execinfo is guarded by version(CRuntime_Glibc). 
I see that CRuntime_Glibc is a predefined version identifier 
defined by the compiler on Linux.


I'm not sure how to best handle different C standard libraries 
when it comes to choosing which one to use. Is it best to 
choose that when building the compiler or when building 
druntime? Or can it be a runtime option?


[1] https://www.musl-libc.org
[2] http://ellcc.org
[3] 
https://github.com/dlang/druntime/blob/master/src/rt/backtrace/dwarf.d#L41
[4] 
https://github.com/dlang/druntime/blob/master/src/core/runtime.d#L433-L434


It is a runtime option on Windows, when choosing between the 
Digital Mars C runtime and the MSVC runtime, which is why those 
are also predefined version identifiers.  The one for Glibc was 
added as an afterthought in that Windows PR, and Bionic was also 
reserved last fall, though my PR to actually define it has been 
in limbo for a year.  That's mostly my fault: I never got back to 
it when I focused on ldc and Android/ARM.


There was a lot of debate among the core team when even the 
Windows CRuntime support was finalized, with Walter wanting to 
minimize such predefined versions and some of the core team 
arguing against it even after it was merged.  Even the iOS 
predefined version took 5 months to get in, because there was 
debate whether Darwin should be allowed as a common version for 
all Apple platforms.


The reason I'm mentioning all this is that adding predefined 
versions is a matter of much debate, but that's how you'll likely 
implement it as a runtime option.  There is no good answer on 
this right now: I suggest you just implement it and worry about 
run-time versus compile-time when you're done.  Since you'll be 
doing the same work either way, ie adding or separating out a 
bunch of version blocks for musl in druntime, do it any way you 
like for now and you can worry about merging that last bit about 
compile-time vs runtime at the end.

Re: Supporting musl libc

2016-05-17 Thread Martin Nowak via Digitalmars-d


On Tuesday, 17 May 2016 at 08:51:01 UTC, Jacob Carlborg wrote:
I'm not sure how to best handle different C standard libraries 
when it comes to choosing which one to use. Is it best to 
choose that when building the compiler or when building 
druntime? Or can it be a runtime option?


Shouldn't be runtime detected, but a linktime/compile option.
We introduced CRuntime_Glibc specifically to separate libc from 
kernel differences, e.g. to support android.

Have a look at how -mscoff32 and Android are implememted in dmd.
At best defining CRuntime_Glibc should move into dmd.conf, where 
you could also select a different phobos library to link.

[Issue 16032] New: extern(Windows) missing from core.sys.windows.wingdi

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

  Issue ID: 16032
   Summary: extern(Windows) missing from core.sys.windows.wingdi
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: johnch_a...@hotmail.com

All of the callback definitions in core.sys.windows.wingdi starting at line
3949 are missing the "extern(Windows)" attribute.

--

Re: Should core.stdc.signal.signal be nothrow @nogc??

2016-05-17 Thread Bottled Genie via Digitalmars-d


Can someone help me?

How can I call core.sys.linux.execinfo:backtrace from a 
core.stdc.signal: signal handler? The problem is that signal has 
been declared with @nogc in druntime and backtrace does not have 
that attribute.

Re: The D language online tour - tour.dlang.org

2016-05-17 Thread André via Digitalmars-d-announce


On Monday, 16 May 2016 at 20:39:26 UTC, Jack Stouffer wrote:
On Monday, 16 May 2016 at 18:02:29 UTC, Andrei Alexandrescu 
wrote:
This is great work, thanks! Please announce in social media as 
well! -- Andrei


Reddit: 
https://www.reddit.com/r/programming/comments/4jn6ks/the_online_d_language_tour/


Thanks!

Re: The D language online tour - tour.dlang.org

2016-05-17 Thread André via Digitalmars-d-announce


On Tuesday, 17 May 2016 at 08:52:57 UTC, Vadim Lopatin wrote:


It would be great to have translations of this tour to other 
languages.

Is it hard to add language selection?
I could help with Russian translation...


It shouldn't be hard, because the technical basis is there; it 
just needs to be made available to the user.


But I would suggest waiting until to start an effort to translate 
the tour into other languages until the content has gone through 
some rounds of reviewing and the number of pulls/errors in the 
content is very low.


Another more fundamental question: Is a translation really needed 
for the tour? I am not a native speaker but I still prefer 
reading technical stuff in English especially when English is the 
language of the original. It's hard for me to estimate the value 
of a translation..


Thanks & regards,
André

Supporting musl libc

As an alternative to glibc there's a C standard library called musl [1]. 
This is the C standard library used by ELLCC [2], a cross-compiler based 
on Clang. This cross-compiler makes it very easy to target other 
platforms and can be used as the C compiler when building with LDC.


The issue is that musl doesn't support the functions defined by 
execinfo.h: backtrace, backtrace_symbols_fd and backtrace_symbols, since 
these are glibc extensions. As far as I can see, these functions are 
used in two places in druntime: src/rt/backtrace/dwarf.d [3] and 
src/core/runtime.d [4].


The imports of execinfo is guarded by version(CRuntime_Glibc). I see 
that CRuntime_Glibc is a predefined version identifier defined by the 
compiler on Linux.


I'm not sure how to best handle different C standard libraries when it 
comes to choosing which one to use. Is it best to choose that when 
building the compiler or when building druntime? Or can it be a runtime 
option?


[1] https://www.musl-libc.org
[2] http://ellcc.org
[3] 
https://github.com/dlang/druntime/blob/master/src/rt/backtrace/dwarf.d#L41
[4] 
https://github.com/dlang/druntime/blob/master/src/core/runtime.d#L433-L434


--
/Jacob Carlborg

Re: Void pointers

2016-05-17 Thread Rene Zwanenburg via Digitalmars-d-learn


On Tuesday, 17 May 2016 at 08:16:15 UTC, Rene Zwanenburg wrote:

On Tuesday, 17 May 2016 at 06:55:35 UTC, Alex wrote:

with dmd test44.d -release
the results are:


You may want to pass '-O -inline' as well. -O enables general 
optimizations, -inline enables function inlining.


-release is for disabling bounds checks, invariants, asserts..

The -debug and -release switches influence the language's 
behavior. -O and -inline are optimization switches and should 
not change the behavior of your program, codegen bugs aside ^^


Additionally, some people recommend never using -release. It 
depends on that type of program you're writing, but the 
performance gain is often not worth the loss in safety. Think 
of the number of exploits enabled by C's lack of bounds 
checking.


ok... now the speed results are exact the same...
so...
besides
void*, ubyte*, a pointer to a strange, not constructible struct, 
I could take a iota too...

Re: D mentioned and criticized

2016-05-17 Thread Chris via Digitalmars-d


On Tuesday, 17 May 2016 at 01:20:16 UTC, Jonathan M Davis wrote:

On Monday, May 16, 2016 18:25:23 Chris via Digitalmars-d wrote:

Well, it's pretty easy to lump in C++ with D given that out of 
all of the successors to C++, D is the most similar to it. And 
while D is definitely simpler than C++, it's still a 
complicated language. So, I could easily see someone dismissing 
D as having C++'s problems if they didn't spend much time with 
it. But I have no idea what the case is with these folks. I'd 
never heard of Loci before you brought it up here.


- Jonathan M Davis


Ola first mentioned Loci in a recent thread. I'm always in favor 
of new PLs and / or ways of thinking. But I don't think it's good 
style to mention D in this way while not giving at least some 
reasons for doing so. To talk about C++'s problems instead is 
misleading. Given Loci's features, the complexity is or will soon 
be similar to D's. Just look at the templates. D also started out 
as a simple language, but as features are required and added, 
complexity increases. That's only natural.


I'll keep an eye on it anyway.

Re: Does DUB create .dll files?


On Tuesday, 17 May 2016 at 05:30:33 UTC, WhatMeWorry wrote:
Am I supposed to get ALURE32.DLL from somewhere outside of DUB, 
or did I miss a step or command when I built 
derelict-alure-master?


thanks.


You'll need to get the dll somewhere else and set up DUB to copy 
it to your output directory. The derelict packages don't include 
prebuilt binaries for the libraries they're binding to.


Here's how dlangui does it for example:

https://github.com/buggins/dlangui/blob/master/dub.json#L60

[Issue 16031] [REG2.071] dmd internal error when compiling druntime with PIC=1

2016-05-17 Thread rikki cattermole via Digitalmars-d-learn

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

Martin Krejcirik  changed:

   What|Removed |Added

Summary|[REG2.071.1] dmd internal   |[REG2.071] dmd internal
   |error when compiling|error when compiling
   |druntime with PIC=1 |druntime with PIC=1

--

Re: Always false float comparisons

2016-05-17 Thread Ethan Watson via Digitalmars-d


On Tuesday, 17 May 2016 at 02:00:24 UTC, Manu wrote:
If Ethan and Remedy want to expand their use of D, the compiler 
CAN
NOT emit x87 code. It's just a matter of time before a loop is 
in a

hot path.


I really need to see what the codegen for the latest DMD looks 
like, I have no idea what the current state is. But this isn't 
just true for Remedy, it's true for any engine programmer in 
another company thinking of using D.


In context of this entire discussion though, a compiler switch to 
give the codegen I want is my preference. I have no desire to 
dictate how other people should use D/DMD, I just want the option 
to use it the way I need to.

Re: Always false float comparisons

2016-05-17 Thread Ethan Watson via Digitalmars-d


On Monday, 16 May 2016 at 14:32:55 UTC, Andrei Alexandrescu wrote:

It is rare to need to actually compute the inverse of a matrix.


Unless you're doing game/graphics work ;-) 4x3 or 4x4 matrices 
are commonly used to represent transforms in 3D space in every 3D 
polygon-based rendering pipeline I know of. It's even a 
requirement for fixed-function OpenGL 1.x.


Video games - also known around here as "The Exception To The 
Rule".


(Side note: My own preference is to represent transforms as a 
quaternion and vector. Inverting such a transform is a simple 
matter of negating a few components. Generating a matrix from 
such a transform for rendering purposes is trivial compared to 
matrix inversion.)

Re: ISO/IEC standard?

2016-05-17 Thread Russel Winder via Digitalmars-d

On Mon, 2016-05-16 at 21:18 +, Rusty via Digitalmars-d wrote:
> […]
> 
> Why do people feel it is risky to develop a large project in D 
> but not in C++?
> 
Risk aversion and avoidance, conservatism, size of extant installed
base of application in the programming language, lack of programmer
pool, lack of thinking, "do what we did last time" attitude, sometimes
lack of bindings to dependencies, lack of sizable training content,
lack of courses in training company portfolio, blind panic about
garbage collection, lack of ambition, fear of being different,
assumption that you have to do things in C but C++ is acceptable.

I think that main training companies offer C, C++, Go, and even Rust
training but not D training is actually a very big issue.

[…]

--
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: Always false float comparisons

2016-05-17 Thread Marco Leise via Digitalmars-d

Am Tue, 17 May 2016 04:12:09 +
schrieb Era Scarecrow :

> I understand fixed floating point

Quote of the day :D

-- 
Marco

Re: How to find the content of core.sys.* ?


On 17/05/2016 6:55 PM, chmike wrote:

Hello,

The nice and handy documentation of dlang doesn't provide any info on
the core.sys. How can I find out all the things that are in there ?


https://github.com/dlang/druntime/tree/master/src/core/sys

Re: Void pointers


On Monday, 16 May 2016 at 23:01:44 UTC, ag0aep6g wrote:

On 05/17/2016 12:53 AM, Alex wrote:
Just as the reality (in my head) is: you can count something 
without

having written the natural numbers before you start to count...


iota does that, too. A iota struct doesn't store all the 
numbers it will emit. Just like a slice, a iota struct stores 
two numbers: the first and the amount of numbers. Iterating 
over it means counting, not reading pre-generated numbers from 
a list.


Especially, I don't have to create some strange structs 
containing just

a number, as I expect to have some millions of them.


Some million slices will take just as much space as some 
million iota structs. Storing a slice isn't free. If you create 
the slices on the fly, you can do that with iota too. No need 
to store them beforehand.


the space is the same, yes...
Added this to my test:

import std.conv : to;
import std.datetime;
size_t aM = 5; size_t bM = 80;
void f1() {auto io = iota(aM,bM);}
void f2() {auto sl = testFunc(arr, aM ,bM);}
auto r = benchmark!(f1, f2)(100_000);
auto f0Result = to!Duration(r[0]); // time f1 took to run 10,000 
times
auto f1Result = to!Duration(r[1]); // time f2 took to run 10,000 
times

writeln("f1: ", f0Result);
writeln("f2: ", f1Result);

with dmd test44.d -release
the results are:
f1: 692 μs and 7 hnsecs
f2: 379 μs and 1 hnsec

How to find the content of core.sys.* ?

2016-05-17 Thread chmike via Digitalmars-d-learn


Hello,

The nice and handy documentation of dlang doesn't provide any 
info on the core.sys. How can I find out all the things that are 
in there ?

Re: Void pointers

2016-05-17 Thread Saurabh Das via Digitalmars-d-announce


On Monday, 16 May 2016 at 22:54:31 UTC, ag0aep6g wrote:

On 05/17/2016 12:43 AM, Alex wrote:
The point is, that in my model the slice has a meaning itself. 
So, the

language provides one of a needed constructs...


Huh? As far as I understand, the pointer of the slice is 
invalid, and you never dereference it. What kind of additional 
meaning can the slice carry then? It's practically just a 
struct of two `size_t`s.


the elements of the slice are accessible just for reading, right, 
but with them I reference the data in other objects.

Re: D equivalent of C++ bind ?

2016-05-17 Thread chmike via Digitalmars-d-learn


On Monday, 16 May 2016 at 15:57:52 UTC, Dsby wrote:



you can remove "auto ref". and I remove the "auto ref" in my 
use.
if used the "alias T", It can not handle all while when the T 
is a delegate.


in C++ std::bind, the arguments order you can sort by used. in 
D I do not find how to enablement.


Yes this doesn't look easy. Maybe by using a mixin. Unfortunately 
this slows down compilation. I don't know the impact on 
optimization.


I'm not sure if converting a function to a delegate is a good 
thing. It is good for your use case where the bind functions are 
used as callbacks. But sometime, users may really want to create 
a function. The user should then use ToDelegate! If he wants to 
convert the function to a delegate. But from the the 
documentation, ToDelegate doesn't work with functions with the 
@safe attribute.

Re: The D language online tour - tour.dlang.org


On Monday, 16 May 2016 at 17:32:06 UTC, André wrote:

Hi,

after another round of polishing, bug fixing, very useful user 
contributions and suggestions, I'd like to present the new home 
of the D language online tour:


http://tour.dlang.org/

Thank you very much to the D foundation for hosting this 
service!


If you would like to report errors or have suggestions, please 
use GitHub:


https://github.com/stonemaster/dlang-tour

Thanks & regards,
André


This is really great! It is a good step into making D friendlier 
for new users.

Re: D mentioned but Rust wins

2016-05-17 Thread Joakim via Digitalmars-d


On Tuesday, 17 May 2016 at 05:54:29 UTC, Nick B wrote:

On Tuesday, 17 May 2016 at 05:39:41 UTC, Nick B wrote:

source: 
http://www.wired.com/2016/03/epic-story-dropboxs-exodus-amazon-cloud-empire/


also

But Go’s “memory footprint”—the amount of computer memory it 
demands while running Magic Pocket—was too high for the massive 
storage systems the company was trying to build. Dropbox needed 
a language that would take up less space in memory, because so 
much memory would be filled with all those files streaming onto 
the machine. So, in the middle of this two-and-half-year 
project, they switched to Rust on the Diskotech machines.


Yep, I posted that link in the forum months ago:

https://forum.dlang.org/thread/fnubtjzaiatrybvya...@forum.dlang.org

Re: [OT] A Rust tool for Cross-compilation