Re: Downloading files over TLS

[User via Digitalmars-d-learn]

On Friday, 26 June 2020 at 10:12:09 UTC, Jacob Carlborg wrote:


Windows:
I don't know that much of this platform.

* std.net.curl and basically all other options already 
mentioned relies on OpenSSL, which is not provided by the 
platform


* SChannel. As far as I know, this the the platform provided 
implementation of TLS on Windows.


* Are there any high level APIs, like NSURLSession, on Windows 
that can be used to download files?




It is possible to statically link libcurl into your application. 
No need to use OpenSSL as libcurl can be built with SChannel.

Convert program to 2020: replace foreach loop with map, filter and friends

[User via Digitalmars-d-learn]

I'd like to convert the following program to 2020 standards (i.e, 
replace the foreach block with a one-line code). I've tried much 
and I failed.


This is the code that works (1990s style)

--
import std;

void main()
{
immutable URL = 
r"https://raw.githubusercontent.com/CSSEGISandData/COVID-19/master/csse_covid_19_data/csse_covid_19_time_series/time_series_covid19_confirmed_global.csv;;

immutable LOCAL = r"local-file";
immutable country = "Poland";

download(URL, LOCAL);

auto file = File(LOCAL, "r");
int i = 0;

foreach(rec; file.byLine())
{
auto x = rec.splitter(',').array;

if (i == 0)
{
// Print Header
writeln(x);
}
else if (x[1] == country)
{
// Print Country Line
writeln(x);
break;
}

i++;
}
}
--

Re: exporting function from betterc to windows dll

[User via Digitalmars-d-learn]

On Saturday, 14 March 2020 at 20:53:45 UTC, Abby wrote:
I would like to export some functions from my bettec dll for 
dotnet core application in windows.


[...]


It is the calling convention.

Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64

[user via Digitalmars-d-announce]

On Tuesday, 5 November 2019 at 02:16:28 UTC, Mathias Lang wrote:

```
apk --no-cache add -X 
http://dl-cdn.alpinelinux.org/alpine/edge/testing ldc 
ldc-static dtools-rdmd dub

```


A hello world vibe project doesn't build for me using a 
Dockerfile using your template. I tried to add missing deps, but 
I couldn't really figure out what's missing.


I get an error during the `dub build` step:

```
eventcore 0.8.48: building configuration "epoll"...
/root/.dub/packages/eventcore-0.8.48/eventcore/source/eventcore/drivers/posix/processes.d(316,10):
 Error: module `core.sys.posix.sys.wait` import `idtype_t` not found`
```

My full Dockefile:

```
FROM alpine:edge as builder

RUN apk --no-cache add build-base git
RUN apk --no-cache add -X 
http://dl-cdn.alpinelinux.org/alpine/edge/testing ldc ldc-static 
dtools-rdmd dub
RUN apk --no-cache add -X 
http://dl-cdn.alpinelinux.org/alpine/edge/testing libevent 
ibevent-dev


WORKDIR /tmp/app

ADD source ./source
ADD dub.json ./

RUN dub build  --compiler=ldc2
```

Re: Thread names in Visual Studio and Mago

[Random D user via Digitalmars-d-debugger]

On Wednesday, 18 September 2019 at 07:30:21 UTC, Rainer Schuetze 
wrote:



On 15/09/2019 20:11, Random D user wrote:
I've been trying to set thread names for debugging, but it 
seems Mago just ignores all names.


SetThreadDescription works for me (in VS2019).

If you are using the visualdproj project, do not use "Mago" as 
the debugger, the "Visual Studio" debugger work better and have 
D support through a mago based expression evaluator extension.


Yes, I'm using VS2019.
Interesting. I indeed have been using Mago (pretty old project 
files too).
I did not know that "Mago" was the wrong debugger to use. I think 
it used to be so that it was the preferred and more feature 
complete (i.e. correct) debugger.


Thanks.
And what it's worth, I think you're doing high value work with 
Visual D, much appreciated.

Thread names in Visual Studio and Mago

[Random D user via Digitalmars-d-debugger]

I've been trying to set thread names for debugging, but it seems 
Mago just ignores all names.


Using WinAPI function SetThreadDescription() I can get thread 
name to show up in other programs (such as the very sleepy 
profiler), but not in Visual Studio and Mago debugger. I also 
tried the exception method as described here:

https://docs.microsoft.com/en-us/visualstudio/debugger/how-to-set-a-thread-name-in-native-code?view=vs-2019

core.thread.Thread also seems broken in terms of thread name. It 
seems to just set a local name for the thread, but not 
communicate that to the os. I suppose threads in Windows are 
nameless outside of debugging, so perhaps that was just a poor 
d-runtime design choice.

Anyway, Mago doesn't seem to look up the d-runtime name either.

Is there a way to show thread names in Visual Studio Mago? or is 
it just unsupported.


Also it would be cool if the d runtime would name it's threads, 
so that it would be easier and faster to pick the correct one.

Re: I had a bad time with slice-in-struct array operation forwarding/mimicing. What's the best way to do it?

[Random D user via Digitalmars-d-learn]

On Saturday, 4 May 2019 at 15:36:51 UTC, Nicholas Wilson wrote:

On Saturday, 4 May 2019 at 15:18:58 UTC, Random D user wrote:
I wanted to make a 2D array like structure and support D slice 
like operations,

but I had surprisingly bad experience.


The de facto multi dimensional array type in D is mir's ndslice

https://github.com/libmir/mir-algorithm/blob/master/source/mir/ndslice/slice.d#L479


Thanks. I'll take a look.

Re: I had a bad time with slice-in-struct array operation forwarding/mimicing. What's the best way to do it?

[Random D user via Digitalmars-d-learn]

On Saturday, 4 May 2019 at 16:10:36 UTC, Adam D. Ruppe wrote:

On Saturday, 4 May 2019 at 15:18:58 UTC, Random D user wrote:

But array copy and setting/clearing doesn't:
int[] bar = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 
14, 15 ];

foo[] = bar[];
Generally speaking, opIndex is for getting, opIndexAssign is 
for setting.


Thanks a lot for a very detailed answer. Sorry about the late 
reply.


But for 2d and 3d and more arrays, the number of functions 
explodes really fast.


Yeah, tastes like C++, but I guess I'll bite.
I value debuggability and I only have the 2D case, so I think 
templates are out.

I had a bad time with slice-in-struct array operation forwarding/mimicing. What's the best way to do it?

[Random D user via Digitalmars-d-learn]

I wanted to make a 2D array like structure and support D slice 
like operations,

but I had surprisingly bad experience.

I quickly copy pasted the example from the docs: 
https://dlang.org/spec/operatoroverloading.html#array-ops


It's something like this:
struct Array2D(E)
{
E[] impl;
int stride;
int width, height;

this(int width, int height, E[] initialData = [])
ref E opIndex(int i, int j)
Array2D opIndex(int[2] r1, int[2] r2)
auto opIndex(int[2] r1, int j)
auto opIndex(int i, int[2] r2)
int[2] opSlice(size_t dim)(int start, int end)
@property int opDollar(size_t dim : 0)()
@property int opDollar(size_t dim : 1)()
}

So basic indexing works fine:
Array2D!int foo(4, 4);
foo[0, 1] = foo[2, 3];

But array copy and setting/clearing doesn't:
int[] bar = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 
15 ];

foo[] = bar[];

And I get this very cryptic message:
(6): Error: template `example.Array2D!int.Array2D.opSlice` cannot 
deduce function from argument types `!()()`, candidates are:
(51):`example.Array2D!int.Array2D.opSlice(ulong dim)(int 
start, int end) if (dim >= 0 && (dim < 2))`


1. WTF `!()()` and I haven't even called anything with opSlice 
i.e. `a .. b`?


Anyway, it doesn't overload [] with opIndex(), so fine, I add 
that.

T[] opIndex() { return impl; }

Now I get:
foo[] = bar[]; // or foo[] = bar;
Error: `foo[]` is not an lvalue and cannot be modified

Array copying docs say:
When the slice operator appears as the left-hand side of an 
assignment expression, it means that the contents of the array 
are the target of the assignment rather than a reference to the 
array. Array copying happens when the left-hand side is a slice, 
and the right-hand side is an array of or pointer to the same 
type.


2.WTF I do have slice operator left of assignment.
So I guess [] is just wonky named getter (and not an operator) 
for a slice object and that receives the = so it's trying to 
overwrite/set the slice object itself.


Next I added a ref to the E[] opIndex():
ref E[] opIndex() { return impl; }

Now foo[] = bar[] works as expected, but then I tried
foo[] = 0;
and that fails:
Error: cannot implicitly convert expression `0` of type `int` to 
`int[]`


3. WTF. Didn't I just get reference directly to the slice and 
array copy works, why doesn't array setting?


The ugly foo[][] = 0 does work, but it's so ugly/confusing that 
I'd rather just use a normal function.


So I added:
ref E[] opIndexAssign(E value) { impl[] = value; return impl; }

And now foo[] = 0; works, but foo[0, 1] = foo[2, 3] doesn't.

I get:
Error: function `example.Array2D!int.Array2D.opIndexAssign(int 
f)` is not callable using argument types `(int, int, int)`

expected 1 argument(s), not 3

4. WTF. So basically adding opIndexAssign(E value) disabled ref E 
opIndex(int i, int j). Shouldn't it consider both?


I'm surprised how convoluted this is. Is this really the way it's 
supposed to work or is there a bug or something?



So what is the best/clear/concise/D way to do these for a custom 
type?


I was planning for:
foo[] = bar; // Full copy
foo[] = 0; // Full clear
foo[0 .. 5, 1] = bar[ 0 .. 5]; // Row/Col copy
foo[1, 0 .. 5] = 0; // Row/Col clear
foo[0 .. 5, 2 .. 4] = bar[ 1 .. 6, 0 .. 2 ]; // Box copy
foo[0 .. 5, 2 .. 4] = 0; // Box clear

Anyway, this is not a huge deal breaker for me, I was just 
surprised and felt like I'm missing something.
I suppose I can manually define every case one by one and not 
return/use any references etc.
or use alias this to forward to impl[] (which I don't want to do 
since I don't want to change .length for example)

or just use normal functions and be done with it.

And it's not actually just a regular array I'm making, so that's 
why it will be mostly custom code, except the very basics.

Re: D IDE

[User via Digitalmars-d]

On Monday, 3 September 2018 at 19:31:58 UTC, Jonathan M Davis 
wrote:


Because they can't hold a candle to vim. As far as text editing 
goes, there simply is no comparison.




All these arguments, especially the above, makes me sad.

May be this is the nature of open source that volunteers will 
work only on things that they like and may not always be aligned 
with all the users needs.


D was born almost two decades ago when IDEs and tools that make 
user experience smooth as defined by current standards didn't 
exist that freely. Major competition then was c++ and Java.


D was a breath of fresh air. It was as fast as c++ and as clean 
as Java. No wonder many people loved D.


Nowadays the programming language landscape is much different. 
With Go, Rust, etc the competition is not only catching up but 
even surpassing D in popularity. I wonder why. I sometimes feel D 
is still stuck in the previous era.


At least in my experience this smoothness factor has a heavy 
weight. I abandoned Java wonderful ecosystem for D's native and 
fast compilation and fast startup. I wrote D programs in 
notepad++ etc. I endured lack of so many wonderful features of a 
mature IDE like eclipse or netbeans.


Now after 20ish years still a mature and smooth ecosystem is no 
where in sight. D did find some success with expert programs,  
good for them, but I couldnt take it any more.


Funnily, I went back to Java. The improvements in java language, 
JVM and hardware in general lessened the pain of java very much. 
It was amazing how much easy and smooth experience matters to 
increase the productivity.


I still keep an eye on D, the ecosystem seems to be getting 
better although at glacial pace. Everytime I read a comment like 
above, this comes to my mind


https://imgs.xkcd.com/comics/supported_features.png

Re: SysTime comparesin - dropMiliseconds

[User via Digitalmars-d-learn]

On Sunday, 12 August 2018 at 19:50:44 UTC, User wrote:
I have to synchronize a directory. If remote file is newer I 
copy to local. If local file is newer I copy it to remote 
server. For some reason remote timestamp does not contain 
milliseconds, so comparison (localFileTime < remoteFileTime, 
etc) fails. I need help to drop milliseconds from local file 
timestamp.


auto m = dur!("seconds")(1);
if ((remote - local) > m)

SysTime comparesin - dropMiliseconds

[User via Digitalmars-d-learn]

I have to synchronize a directory. If remote file is newer I copy 
to local. If local file is newer I copy it to remote server. For 
some reason remote timestamp does not contain milliseconds, so 
comparison (localFileTime < remoteFileTime, etc) fails. I need 
help to drop milliseconds from local file timestamp.

Re: How about implementing SPMD on SIMD for D?

[Random D user via Digitalmars-d]

On Saturday, 7 July 2018 at 13:26:10 UTC, Guillaume Piolat wrote:

On Friday, 6 July 2018 at 23:08:27 UTC, Random D user wrote:
Especially, since D doesn't even attempt any 
auto-vectorization (poor results and difficult to implement) 
and manual loops are quite tedious to write (even std.simd 
failed to materialize), so SPMD would be nice alternative.


I think you are mistaken, D code is autovectorized often when 
using LDC.


That is good to know.
I haven't looked that much into LDC (or clang). I mostly use dmd 
for fast edit-compile cycle. Although, plan is to use LDC for 
"release"/optimized build eventually.


Anyway, I would just want to code some non-trivial loops in SIMD, 
but I wouldn't want to fiddle with intrinsics. Or write a higher 
level wrapper for them.


In my experience, you can only get the real benefits out of SIMD 
if you carefully handcraft your hot loops to fully use it. 
Sprinkling some SIMD here and there with a SIMD vector type, 
doesn't really seem to yield big benefits.




Sometimes it's not and it's hard to know why.


Exactly.
In my experience compilers (msvc) often don't.

A pragma we could have is the one in the Intel C++ Compiler 
that says "hey this loop is safe to autovectorize".



What do you think?


I think that ispc is like OpenCL on the CPU, but can't work on 
the GPU, FPGA or other OpenCL implementation. OpenCL is so fast 
because caching is explicit (several levels of memory are 
exposed).


Yeah, it should be similar. The point is not run it on GPU, you 
can do CUDA, OpenCL, compute shader etc. for that.
CPU code is much easier to debug, and sometimes you're already 
doing things on the GPU, but your CPU side has more room for 
computation. And you don't have to copy your data between the GPU 
and CPU or deal with latency.
Of course, OpenCL runs on CPU too, but I think there's quite a 
bit of code required to set it up and to use it.


I guess my point was that I would like to do CPU SIMD code easily 
without intrinsics (or manually trying to trick the compiler to 
vectorize the code). SPMD stuff seems to solve these issues. It 
would also be a forward looking step for D.


Ideally, just write your loop normally, debug it and add an 
annotation to get it to run fast on SIMD. Done.

How about implementing SPMD on SIMD for D?

[Random D user via Digitalmars-d]

TL;DR
Would want to run your code 8x - 32x faster? SPMD (Single Program 
Multiple Data) on SIMD (Single Instruction Multiple Data) might 
be the answer you're looking for.
It works by running multiple iterations/instances of your loop at 
once on SIMD and the compiler could do that automatically for you 
and your normal loop & array code.


---

I'm a bit late to the party, but I recently was reading this ( 
http://pharr.org/matt/blog/2018/04/30/ispc-all.html ), a highly 
interesting blog post series about how one guy did what the Intel 
compiler team wouldn't or couldn't do.
He wrote a C like language and compiler on top of LLVM which 
transforms normal scalar code into "parallel" SIMD code.
That compiler is called the ISPC ( 
https://ispc.github.io/perf.html ).


It basically works the similarly as GPU shaders, but the code 
runs on the CPU SIMD.
You write your code for one thread/lane and the compiler then 
runs N instances of that code simultaneously in lockstep.
For example, loop 8x (c.xyzw = a.xyzw + b.xyzw) would become 2x 
(x. = x. + x.; y. = y. + y.; z. = 
z. + z.; w. = w. + w.) (the notation here is 
a bit weird, but I was trying to keep it short).
Branches are done using masking, so the code runs both sides of 
the branch, but masks away the wrong results.
All of this is way better described in the paper they wrote about 
it ( http://pharr.org/matt/papers/ispc_inpar_2012.pdf ). I 
recommend reading it.


I was also looking at some videos from Unity (game 
engine/framework) about their new "Performance by default" 
initiative.
They are building a custom subset of C# with their own compiler 
to native code. It looks like the subset is just C# with structs, 
functions, slices and annotations (no classes).

That reminded me of D :).
One thing they touched was pointer aliasing and how slices and 
custom compiler tech (that knows about the other engine systems) 
allows them to avoid aliasing and produce more optimal code.
However the interesting part was that the compiler does similar 
things as the ISPC when specific annotations are given by the 
programmer.
Video about the tech/compiler is here ( 
https://www.youtube.com/watch?v=NF6kcNS6U80=youtu.be?list=PLX2vGYjWbI0S8ujCJKYT-mIZf7YCuF-Ka ).


It occurred to me that SPMD on SIMD would be really nice addition 
to D's arsenal.
Especially, since D doesn't even attempt any auto-vectorization 
(poor results and difficult to implement) and manual loops are 
quite tedious to write (even std.simd failed to materialize), so 
SPMD would be nice alternative.
D also has some existing vector syntax and specialization, so 
there's a precedent for vector programing. This could be 
considered as an extension to that.
The SPMD should be easy to implement (I'm not a compiler expert) 
since it's only a code transformation and not an optimization.


Finally, I don't think any serious systems/performance oriented 
language can ignore that kind of performance-increase figures for 
too long.


I had something like this in mind:

@spmd  //or @simd  // NOTE: just removing @spmd would mean it's a 
normal loop, great for debugging

foreach( int i; 0 .. 100 )
{
c[i] = a[i] + b[i];
}

or

void doSum( float4[] a, float4[] b, float4[] c ) @spmd  //or @simd
{
c = a + b;  // NOTE: c[i] = a[i] + b[i], array index is 
implicit because of @spmd, it's just some index of 0 .. a.length

}

What do you think?

Re: Sign the installers

[User via Digitalmars-d]

It's all about removing resistance and raising the level of 
professionalism.  D isn't a hobby project and shouldn't act 
like one. This is an obvious barrier that's worth removing.  In 
this day and age of rampant actively dangerous software, it's 
an obvious improvement to sign it and make the strong claim 
that this is produced and vended by the d foundation and we 
vouch for it's contents.  We already do for some (all?) of the 
posix distribution bundles.



Well said, thanks.

Re: Deleting a file with extsion *.FIFO in Windows

[Dlang User via Digitalmars-d-learn]

On 6/1/2018 12:06 AM, vino.B wrote:

On Thursday, 24 May 2018 at 11:31:15 UTC, bauss wrote:

On Thursday, 24 May 2018 at 06:59:47 UTC, Vino wrote:

Hi All,

  Request your help on how to delete a file which has the extension 
.fifo (.javast.fifo) in Windows.


From,
Vino.B


What exactly is your issue with it?


Hi Bauss,

  We have a java program which creates a file with extension .fifo and 
we have another program written in D to clean up the old file, so the D 
code is not able to delete these files using any of the D function 
provided it states "Access Denied" we tried to provide the full access 
manually even then it is not able to delete such files.


From,
Vino.B


Are the files by chance marked as read only (when you right click on a 
.fifo file and select properties)?

Re: Why is 64-bit dmd not built as part of the Windows release?

[Dlang User via Digitalmars-d]

On 5/23/2018 3:20 PM, Vladimir Panteleev wrote:

On Wednesday, 23 May 2018 at 20:17:04 UTC, Dlang User wrote:

I tried adding bootstrap option for 64 bit:

digger -c build.components.dmd.dmdModel=64 -c 
build.components.dmd.bootstrap.ver=v2.075.0 build --model=64 v2.080.0


Which didn't work (totally different error):


Looks like more DMD bugs. Try more host versions, e.g. v2.079.0 or 
v2.080.0.




Thank you. I had success with using v2.080.0 as the bootstrap:

digger -c build.components.dmd.dmdModel=64 -c 
build.components.dmd.bootstrap.ver=v2.080.0 build --model=64 v2.080.0

Re: Why is 64-bit dmd not built as part of the Windows release?

[Dlang User via Digitalmars-d]

On 5/23/2018 12:42 PM, Vladimir Panteleev wrote:

On Wednesday, 23 May 2018 at 17:35:28 UTC, Dlang User wrote:
I too am looking for 64-bit on Windows 10.  Not just DMD but ideally 
everything.


When I try the command exactly as above, or a slightly modified 
version (on a second run show after this run), I hit an error on my 
machine:


Internal error: dmd\backend\cod3.c 6830


Hmm, that looks like a DMD bug/regression. I think that should have been 
caught by the auto-tester. In any case, try adding --model=64 to your 
command to also build a 64-bit Phobos, as that seems to be what you're 
after anyway. You could also try specifying a different (newer?) host 
DMD version with e.g. `-c build.components.dmd.bootstrap.ver=v2.075.0`.




Thanks for looking at this, I actually did try adding --model=64, in the 
second run that I was referring to in my original post, but that 
resulted in the same error.


Some additional things I realized when trying to use digger on my machine:

Digger is only failing when trying to use the 
build.components.dmd.dmdModel=64 switch, so when trying to build 64 bit 
DMD.


digger -c build.components.dmd.dmdModel=64 build --model=64 v2.080.0

The first time the error is this (so this is probably the real error):

FLunde  Internal error: dmd\backend\cod3.c 5488

The second time, the error is (this is probably due to the previous 
failed run):


Internal error: dmd\backend\cod3.c 6830


I tried adding bootstrap option for 32 bit, and that worked fine:

digger -c build.components.dmd.dmdModel=32 -c 
build.components.dmd.bootstrap.ver=v2.075.0 build --model=32 v2.080.0


I tried adding bootstrap option for 64 bit:

digger -c build.components.dmd.dmdModel=64 -c 
build.components.dmd.bootstrap.ver=v2.075.0 build --model=64 v2.080.0


Which didn't work (totally different error):

C:\DProj\digger\work\dl\dmd-2.075.0\dmd2/windows/bin\dmd.exe 
-of..\generated\windows\release\64\dmd.exe -vtls 
-J..\generated\windows\release\64 -J../res -L/STACK:8388608 -O -release 
-inline -m64  -wi -version=MARS -L/delexe/la dmd/access.d 
dmd/aggregate.d dmd/aliasthis.d dmd/apply.d dmd/argtypes.d dmd/arrayop.d 
dmd/arraytypes.d dmd/astcodegen.d dmd/attrib.d dmd/builtin.d 
dmd/canthrow.d dmd/cli.d dmd/clone.d dmd/compiler.d dmd/complex.d 
dmd/cond.d dmd/constfold.d dmd/cppmangle.d dmd/cppmanglewin.d 
dmd/ctfeexpr.d dmd/ctorflow.d dmd/dcast.d dmd/dclass.d 
dmd/declaration.d dmd/delegatize.d dmd/denum.d dmd/dimport.d 
dmd/dinifile.d dmd/dinterpret.ddmd/dmacro.d dmd/dmangle.d 
dmd/dmodule.d dmd/doc.d dmd/dscope.d dmd/dstruct.d dmd/dsymbol.d 
dmd/dsymbolsem.d dmd/lambdacomp.d dmd/dtemplate.d 
dmd/dversion.d dmd/escape.ddmd/expression.d 
dmd/expressionsem.d dmd/func.d dmd/hdrgen.d dmd/id.d dmd/imphint.d 
dmd/impcnvtab.d dmd/init.d dmd/initsem.d dmd/inline.d dmd/inlinecost.d 
dmd/intrange.d dmd/json.d dmd/lib.d dmd/link.d   dmd/mars.d dmd/mtype.d 
dmd/nogc.d dmd/nspace.d dmd/objc.d dmd/opover.d dmd/optimize.d 
dmd/parse.ddmd/sapply.d dmd/sideeffect.d dmd/statement.d 
dmd/staticassert.d dmd/target.d   dmd/safe.d dmd/blockexit.d 
dmd/permissivevisitor.d dmd/transitivevisitor.d dmd/parsetimevisitor.d 
dmd/printast.d dmd/typesem.d  dmd/traits.d dmd/utils.d dmd/visitor.d 
dmd/libomf.d dmd/scanomf.d dmd/templateparamsem.d dmd/typinf.d 
dmd/libmscoff.d dmd/scanmscoff.d dmd/statement_rewrite_walker.d 
dmd/statementsem.d dmd/staticcond.d  dmd/semantic2.d dmd/semantic3.d 
dmd/irstate.d dmd/toctype.d dmd/glue.d dmd/gluelayer.d dmd/todt.d 
dmd/tocsym.d dmd/toir.d dmd/dmsc.d  dmd/tocvdebug.d dmd/s2ir.d 
dmd/toobj.d dmd/e2ir.d dmd/objc_glue.d dmd/eh.d dmd/iasm.d 
dmd\backend/bcomplex.d dmd\backend/cc.d dmd\backend/cdef.d 
dmd\backend/cgcv.d dmd\backend/code.d dmd\backend/cv4.d dmd\backend/dt.d 
dmd\backend/el.d dmd\backend/global.d  dmd\backend/obj.d 
dmd\backend/oper.d dmd\backend/outbuf.d dmd\backend/rtlsym.d 
dmd\backend/code_x86.d dmd\backend/iasm.d  dmd\backend/ty.d 
dmd\backend/type.d dmd\backend/exh.d dmd\backend/mach.d 
dmd\backend/md5.d dmd\backend/mscoff.d dmd\backend/dwarf.d 
dmd\backend/dwarf2.d dmd\backend/xmm.d dmd\tk/dlist.d dmd\root/aav.d 
dmd\root/array.d dmd\root/ctfloat.d dmd\root/file.d  dmd\root/filename.d 
dmd\root/man.d dmd\root/outbuffer.d dmd\root/port.d  dmd\root/response.d 
dmd\root/rmem.d dmd\root/rootobject.d  dmd\root/speller.d 
dmd\root/stringtable.d dmd\root/hash.d 
..\generated\windows\release\64\newdelete.obj 
..\generated\windows\release\64\backend.lib 
..\generated\windows\release\64\lexer.lib


object.Error@(0): Access Violation

0x004CF5B7
0x004987C7
0x77B716B7 in RtlAllocateHeap
0x00441CCD
0x0064DE30
0x0044E40A
0x00405B42

--- errorlevel 1

--- errorlevel 1

--- errorlevel 1
digger: Saving to cache.
digger: Clearing temporary cache

object.Exception@C:\Users\dlang.user\AppData\Local\dub\packages\ae-0.0.2177\ae\sys\d\manager.d(850): 
Command ["make", "-f", "win64.mak", "MODEL=64", 

Re: Why is 64-bit dmd not built as part of the Windows release?

[Dlang User via Digitalmars-d]

On 5/22/2018 10:03 AM, Atila Neves wrote:

On Tuesday, 22 May 2018 at 13:30:02 UTC, Vladimir Panteleev wrote:

On Tuesday, 22 May 2018 at 13:11:00 UTC, Atila Neves wrote:

On Thursday, 17 May 2018 at 03:28:33 UTC, Vladimir Panteleev wrote:

digger build --model=64

If you don't have Digger yet, you can run it straight from Dub:

dub fetch digger
dub run digger -- build --model=64


I keep forgetting about digger for some reason. Unfortunately the 
command above produced a 32-bit dmd. 64-bit druntime and phobos, but 
32-bit dmd.


Atila


Apologies, that indeed is the wrong command.

This should work:

dub run digger -- -c build.components.dmd.dmdModel=64 build


Thanks!

That was pretty confusing though - and I consulted the documentation 
before trying --model=64 myself.


In any case, I seem to have gotten a working 64-bit version of dmd.


I too am looking for 64-bit on Windows 10.  Not just DMD but ideally 
everything.


When I try the command exactly as above, or a slightly modified version 
(on a second run show after this run), I hit an error on my machine:


Internal error: dmd\backend\cod3.c 6830


Does anyone have any suggestions?  It could be something simple, as I am 
relitivly new to D.  I have windows 10 64 bit and I have v2.080.0 of D 
installed and I have VS2017 installed and I am able to complile D code 
to create a 64bit apps. I have tried compiling digger as both 32bit and 
64bit, and that made no difference.


If I run digger to build 32 bit DMD, then it succeeds with or without 
the --model=64 switch:


digger build v2.080.0
digger build v2.080.0 --model=64





In the case of the original command I see this:

digger -c build.components.dmd.dmdModel=64 build

C:\DProj\digger\work\build\bin\dmd.exe -lib -oflib\druntime.lib 
-Xfdruntime.json -m32 -conf= -O -release -dip1000 -inline -w -Isrc 
-Iimport src\object.d   src\core\atomic.d  src\core\attribute.d 
src\core\bitop.d  src\core\checkedint.d  src\core\cpuid.d 
src\core\demangle.d  src\core\exception.d  src\core\math.d 
src\core\memory.d  src\core\runtime.d  src\core\simd.d 
src\core\thread.d  src\core\time.d  src\core\vararg.d 
src\core\internal\abort.d  src\core\internal\arrayop.d 
src\core\internal\convert.d  src\core\internal\hash.d 
src\core\internal\parseoptions.d  src\core\internal\spinlock.d 
src\core\internal\string.d  src\core\internal\traits.d 
src\core\stdc\assert_.d  src\core\stdc\complex.d  src\core\stdc\config.d 
 src\core\stdc\ctype.d  src\core\stdc\errno.d  src\core\stdc\fenv.d 
src\core\stdc\float_.d  src\core\stdc\inttypes.d  src\core\stdc\limits.d 
 src\core\stdc\locale.d  src\core\stdc\math.d  src\core\stdc\signal.d 
src\core\stdc\stdarg.d  src\core\stdc\stddef.d  src\core\stdc\stdint.d 
src\core\stdc\stdio.d  src\core\stdc\stdlib.d  src\core\stdc\string.d 
src\core\stdc\time.d  src\core\stdc\wchar_.d   src\core\sync\barrier.d 
src\core\sync\condition.d  src\core\sync\config.d 
src\core\sync\exception.d  src\core\sync\mutex.d 
src\core\sync\rwmutex.d  src\core\sync\semaphore.d 
src\core\sys\darwin\netinet\in_.d   src\core\sys\freebsd\dlfcn.d 
src\core\sys\freebsd\execinfo.d  src\core\sys\freebsd\netinet\in_.d 
src\core\sys\freebsd\sys\_bitset.d  src\core\sys\freebsd\sys\_cpuset.d 
src\core\sys\freebsd\sys\cdefs.d  src\core\sys\freebsd\sys\elf_common.d 
src\core\sys\freebsd\sys\elf.d  src\core\sys\freebsd\sys\elf32.d 
src\core\sys\freebsd\sys\elf64.d  src\core\sys\freebsd\sys\event.d 
src\core\sys\freebsd\sys\link_elf.d  src\core\sys\freebsd\sys\mman.d 
src\core\sys\freebsd\time.d   src\core\sys\dragonflybsd\dlfcn.d 
src\core\sys\dragonflybsd\execinfo.d 
src\core\sys\dragonflybsd\netinet\in_.d 
src\core\sys\dragonflybsd\sys\_bitset.d 
src\core\sys\dragonflybsd\sys\_cpuset.d 
src\core\sys\dragonflybsd\sys\cdefs.d 
src\core\sys\dragonflybsd\sys\elf_common.d 
src\core\sys\dragonflybsd\sys\elf.d 
src\core\sys\dragonflybsd\sys\elf32.d 
src\core\sys\dragonflybsd\sys\elf64.d 
src\core\sys\dragonflybsd\sys\event.d 
src\core\sys\dragonflybsd\sys\link_elf.d 
src\core\sys\dragonflybsd\sys\mman.d  src\core\sys\dragonflybsd\time.d 
src\core\sys\linux\netinet\in_.d  src\core\sys\linux\netinet\tcp.d 
src\core\sys\linux\stdio.d  src\core\sys\linux\tipc.d 
src\core\sys\linux\sys\inotify.d  src\core\sys\linux\sys\mman.d 
src\core\sys\linux\sys\signalfd.d  src\core\sys\linux\sys\socket.d 
src\core\sys\linux\sys\sysinfo.d  src\core\sys\linux\sys\time.d 
src\core\sys\linux\sys\xattr.d   src\core\sys\posix\dirent.d 
src\core\sys\posix\signal.d  src\core\sys\posix\netdb.d 
src\core\sys\posix\netinet\in_.d  src\core\sys\posix\arpa\inet.d 
src\core\sys\posix\sys\ioctl.d  src\core\sys\posix\sys\ipc.d 
src\core\sys\posix\sys\mman.d  src\core\sys\posix\sys\resource.d 
src\core\sys\posix\sys\select.d  src\core\sys\posix\sys\shm.d 
src\core\sys\posix\sys\socket.d  src\core\sys\posix\sys\stat.d 
src\core\sys\posix\sys\statvfs.d  src\core\sys\posix\sys\time.d 
src\core\sys\posix\sys\types.d  src\core\sys\posix\sys\uio.d 

Re: Sealed classes - would you want them in D?

[dlang user via Digitalmars-d]

On 05/15/2018 04:05 PM, Jonathan M Davis wrote:

On Tuesday, May 15, 2018 12:21:23 Dlang User via Digitalmars-d wrote:

On 5/15/2018 10:17 AM, aliak wrote:

On Tuesday, 15 May 2018 at 13:16:55 UTC, 12345swordy wrote:

The way you use the word "leak" make is sounds that this is
unintentional, while in reality it is intentional by design. That why
reading the specification is important!

Alexander


Ya I guess you be right - but a leak is what it is to people who expect
private to mean private. Which is not a small number of people ;)

And while I agree reading a spec is important. Language specs are not
known for being trivial to go through and it's not really something you
read but more of something you refer to, and that also probably for more
advanced developers. This is not something you can expect newcomers or
even intermediate level devs to go through. And the less you need to
refer to a spec the better (i.e. more intuitive) a language is.


I concur with that.  When I first started learning D (coming from a C#
background), I figured that I already knew all of the OOP stuff and
didn't dig too deeply into it, figuring that it worked pretty close to
the same as C#.  It did catch me off guard when I first realized how it
really worked in D.  But the work around (putting it in its own module),
seemed pretty trivial and is what I typically do in C# anyways, so it
didn't bother me too much.


I think that if there's an actual problem here, it's the fact that how
private works in D is surprising to folks coming from languages like C++,
C#, or Java. IMHO, D's approach works extremely well, but if you don't
understand what it is, you risk problems, just like with any other feature
that you don't understand properly. And to better deal with that, we
probably need more in the way of documentation geared towards teaching
newbies. The "spec" is pretty poor in that it's not precise enough to be a
spec, meaning that it doesn't really do its job in that respect, but it's
also not really written with the idea that it's teaching someone, so it
doesn't do a great job teaching the language either. There's a lot of great
information there, but it's ultimately not all that accessible for many
folks.

Though if someone expects to be able to just jump into any language and use
it without reading up on how it works, they're just shooting themselves in
the foot. And surprisingly often, that seems to be how many folks operate.

Ultimately, if newcomers don't want to be tripped up on stuff like this,
their best bet is probably to read books like Andrei's "The D Programming
Language" and Ali's "Programming in D."

https://wiki.dlang.org/Books

- Jonathan M Davis



To clarify myself a little bit, the main points that I was agreeing with 
were:


1. I think there are significant number of people coming from other 
languages that are going to get tripped up by D's module level 
encapsulation, mainly because it happened to me.


2. The spec is hard to use as a training resource, because I tried to 
use it and didn't have a good experience with it.


I ended up reading all of the free material that I could find (including 
the Programming in D book).


I also wasn't trying say anything about D's encapsulation being right or 
wrong, just that it tripped me up initially, and that now that I know 
how it works, it isn't a big deal for me.

Re: Sealed classes - would you want them in D?

[Dlang User via Digitalmars-d]

On 5/15/2018 10:17 AM, aliak wrote:

On Tuesday, 15 May 2018 at 13:16:55 UTC, 12345swordy wrote:
The way you use the word "leak" make is sounds that this is 
unintentional, while in reality it is intentional by design. That why 
reading the specification is important!


Alexander


Ya I guess you be right - but a leak is what it is to people who expect 
private to mean private. Which is not a small number of people ;)


And while I agree reading a spec is important. Language specs are not 
known for being trivial to go through and it's not really something you 
read but more of something you refer to, and that also probably for more 
advanced developers. This is not something you can expect newcomers or 
even intermediate level devs to go through. And the less you need to 
refer to a spec the better (i.e. more intuitive) a language is.






I concur with that.  When I first started learning D (coming from a C# 
background), I figured that I already knew all of the OOP stuff and 
didn't dig too deeply into it, figuring that it worked pretty close to 
the same as C#.  It did catch me off guard when I first realized how it 
really worked in D.  But the work around (putting it in its own module), 
seemed pretty trivial and is what I typically do in C# anyways, so it 
didn't bother me too much.

Re: property += operator

[Dlang User via Digitalmars-d-learn]

On 5/10/2018 3:18 PM, Ali Çehreli wrote:

On 05/10/2018 01:03 PM, Dlang User wrote:

 >> this didn´t work either.
 >> note that 'f.data+= 2;' don't call the write property
 >
 > That's odd, it works on my machine (Windows 10 with V2.079.0 DMD 
compiler).


Try putting writeln expressions in the two functions to see which one 
gets called. ;)


Ali



Now, I see the problem. Sorry for the noise.

Re: property += operator

[Dlang User via Digitalmars-d-learn]

On 5/10/2018 2:50 PM, SrMordred wrote:

On Thursday, 10 May 2018 at 19:41:41 UTC, Dlang User wrote:

On 5/10/2018 1:43 PM, SrMordred wrote:

[...]


I am relatively new to D and I was under the impression that that was 
a limitation of @property functions.


But, re-reading the language reference, it gave this example (it 
returns something from the write property, which seems odd), I 
modified to add refs, and then it seems to work, but I am not sure if 
it is correct or not:


import std.stdio;

struct Foo
{
    @property ref int data() { return m_data; } // read property

    @property ref int data(int value) { return m_data = value; } // 
write property


  private:
    int m_data;
}

void main()
{
Foo f;
f.data = 5;
f.data++;
f.data+= 2;
writeln(f.data);

}


this didn´t work either.
note that 'f.data+= 2;' don't call the write property


That's odd, it works on my machine (Windows 10 with V2.079.0 DMD 
compiler).


I changed main to this:

void main()
{
Foo f;
writeln(f.data);
f.data = 5;
writeln(f.data);
f.data++;
writeln(f.data);
f.data+= 2;
writeln(f.data);
}


and then I get this output:

0
5
6
8

Re: property += operator

[Dlang User via Digitalmars-d-learn]

On 5/10/2018 1:43 PM, SrMordred wrote:

struct T
{
     int x;
     @property ref X(){ return x; }
     @property X(int v)
     {
     x = v;
     }
}

T t;
t.X += 10;

The setter 'x = v' are not executed because i´m returning the reference 
of x.

And without the 'ref' the compiler complains because 'x' is not a lvalue.

Any solution to make it work like native arr.length+=10 works?

( I Thought on returning a struct with "+=" operator but it is a strange 
solution )


I am relatively new to D and I was under the impression that that was a 
limitation of @property functions.


But, re-reading the language reference, it gave this example (it returns 
something from the write property, which seems odd), I modified to add 
refs, and then it seems to work, but I am not sure if it is correct or not:


import std.stdio;

struct Foo
{
@property ref int data() { return m_data; } // read property

@property ref int data(int value) { return m_data = value; } // 
write property


  private:
int m_data;
}

void main()
{
Foo f;
f.data = 5;
f.data++;
f.data+= 2;
writeln(f.data);

}

Re: dub search

[Dlang User via Digitalmars-d]

On 5/8/2018 10:50 AM, Nicholas Wilson wrote:
I was searching for zmq-d on code.dlang.org to find the git page for it 
( to differentiate it from the other ama wrappers) and was greeted with


500 - Internal Server Error

Internal Server Error

Internal error information:
vibe.db.mongo.connection.MongoDriverException@../vibe.d/mongodb/vibe/db/mongo/cursor.d(304): 
Query failed. Does the database exist?


??:? [0xa7bbee]
??:? [0xa825de]
exception.d:421 [0x50aa93]
exception.d:388 [0x50116d]
cursor.d:304 [0x517adc]
dbcontroller.d:393 [0x518643]
...

OK, i thought, I'll try searching for "z"


Found 30 packages.


^f z

one match:

Search results for: z

That does not bode well for people searching for code on dub.

Nic


I am seeing the same thing, apparently it crashes for anything that 
contains a "-d" in the search.  "-dd" doesn't crash.

Re: Favorite GUI library?

[User via Digitalmars-d]

I write lot of small utilities on Windows and prefer to have a 
gui.


Gtkd is nice. Glade is awsome. but the runtime dlls are about 
20mb, too much for a 1mb tool. For some reason the theming on 
Windows didnt work well for me.


Dwt is nice, but no glade like gui editor.  when using dwt, I 
build gui manually.


Html css looks too different from native app. Opening and saving 
files is painful, nok.


Most of the time java, swing, netbeans works very well. Startup 
time sucks, so i just added an intrresting splash screen and 
people seemed to like it.


I have high hopes for dlangui, but it's still beta and has some 
bugs that's blocking me.


In conclusion, if startup time is important i use dwt. Otherwise 
java with netbeans.

Re: Building is slow!

[Dlang User via Digitalmars-d]

On 4/16/2018 3:27 PM, Ivan Trombley wrote:

I want to revisit this issue.

Building 64 bit on Linux, release or debug, is fast. However, building 
64 bit release on Windows 10 is super slow. I have a cross platform app 
that uses gtk-d. Today, I updated DMD to 2.079.1 and the gtk-d lib to 
3.8.0. When I performed a debug build on Windows 10, it only took a few 
seconds to build gtk-d. I attempted to build release but canceled the 
build after a couple of hours. I tried building 32 bit release on 
Windows and while it took a lot longer than debug, it still completed in 
a reasonable amount of time (it wouldn't link, though, probably because 
I'm missing some 32 libraries).


Does anyone have any idea why 64 bit release builds on Windows would 
take so long?




I have no idea why, but I can confirm that I am seeing something similar 
on Windows 10.  I have tried it both with anti-virus enabled and 
disabled, with the same results.


Compiler Version:  2.079.1 (-m64 switch set in the sc.ini file)
Using a gtkd project (tried two versions 3.8.0 and 3.8.1)

Attempts:

1. plain build

It succeeds with this output (build time is 21 seconds, including fetching):

C:\DProj\gtktest>dub build -b plain --force
Fetching gtk-d 3.8.1 (getting selected version)...
Performing "plain" build using C:\D\dmd2\windows\bin\dmd.exe for x86_64.
gtk-d:gtkd 3.8.1: building configuration "library"...
gtk-d:gstreamer 3.8.1: building configuration "library"...
gtk-d:peas 3.8.1: building configuration "library"...
gtk-d:sv 3.8.1: building configuration "library"...
gtk-d:vte 3.8.1: building configuration "library"...
gtktest ~master: building configuration "application"...
Linking...


2. debug build

It succeeds with a linker warning (build time is 23 seconds, already 
fetched):


C:\DProj\gtktest>dub build -b debug --force
Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe for x86_64.
gtk-d:gtkd 3.8.1: building configuration "library"...
gtk-d:gstreamer 3.8.1: building configuration "library"...
gtk-d:peas 3.8.1: building configuration "library"...
gtk-d:sv 3.8.1: building configuration "library"...
gtk-d:vte 3.8.1: building configuration "library"...
gtktest ~master: building configuration "application"...
Linking...
gtkd-3.lib(functions.obj) : warning LNK4255: library contain multiple 
objects of the same name; linking object as if no debug info
gtkd-3.lib(functions.obj) : warning LNK4255: library contain multiple 
objects of the same name; linking object as if no debug info
gtkd-3.lib(functions.obj) : warning LNK4255: library contain multiple 
objects of the same name; linking object as if no debug info
gtkd-3.lib(functions.obj) : warning LNK4255: library contain multiple 
objects of the same name; linking object as if no debug info
gtkd-3.lib(functions.obj) : warning LNK4255: library contain multiple 
objects of the same name; linking object as if no debug info
gtkd-3.lib(functions.obj) : warning LNK4255: library contain multiple 
objects of the same name; linking object as if no debug info
gtkd-3.lib(functions.obj) : warning LNK4255: library contain multiple 
objects of the same name; linking object as if no debug info
gtkd-3.lib(functions.obj) : warning LNK4255: library contain multiple 
objects of the same name; linking object as if no debug info
gtkd-3.lib(ActionIF.obj) : warning LNK4255: library contain multiple 
objects of the same name; linking object as if no debug info



3. release build

This hangs (I killed it after 10 minutes):

C:\DProj\gtktest>dub build -b release --force
Performing "release" build using C:\D\dmd2\windows\bin\dmd.exe for x86_64.
gtk-d:gtkd 3.8.1: building configuration "library"...

Re: signbit question

[Dlang User via Digitalmars-d-learn]

On 3/15/2018 12:39 PM, Miguel L wrote:

On Thursday, 15 March 2018 at 17:31:38 UTC, rumbu wrote:

On Thursday, 15 March 2018 at 17:18:08 UTC, Miguel L wrote:

On Thursday, 15 March 2018 at 16:31:56 UTC, Stefan Koch wrote:

On Thursday, 15 March 2018 at 15:28:16 UTC, Miguel L wrote:

[...]


integers don't have a sign-bit.
since they are not necessarily singed.
However if an integer is signed and using 1-complement
you can either do sign = var < 0 or
sign = (var & (1 << (sizeof(var)*8 - 1));
though I cannot tell which one is faster you have to experiment.


Thanks. Just one more question:

Is this code correct? I don't care about +0 or -0 as the calculations 
on f guarantee it cannot be 0 at all.


int a;
float f;

if((a<0)==signbit(f)) {}
else {...}


If you are comparing with an integer, please avoid signbit. It will 
return 1 also for -0.0, -inf and -nan.


Don't bother also with signbit for integer types. The compiler usually 
outsmarts the programmer in finding the best way to compare an integer 
with 0.


You can simply write:

if (a < 0 && f < 0) {...}

This will cover the [-inf..0) but not the NaN case. You can test it in 
a separate branch


if (isNaN(f)) {...}


There are various in my code there are more than two variables, and i'd 
like to check when their signs differ.I am trying to avoid this, maybe 
there is no point in it:


if(!((a>=0 && f>=0) || (a<0 && f<0))){
//signs are different

}

Thanks, anyway


You could simplify that to this:

if ((a < 0) != (f < 0))
{

}

Or if you have more than two variables you could do something like this:

bool AllSameSign(double[] args ...)
{
  //Only need to check if there are more than one of them
  if (args.length > 1)
  {
//Compare arg[0] to all the other args.
for (int i = 1; i < args.length; i++)
{
  if ((args[0] < 0) != (args[i] < 0))
  {
return false;
  }
}
  }
  return true;
}

Which you could call like this, with as many variables as you like:

AllSameSign(a,f);

Re: Release D 2.079.0

[Random D user via Digitalmars-d-announce]

On Monday, 5 March 2018 at 23:40:35 UTC, Atila Neves wrote:
I'd have a snowball's chance in hell convincing anyone at a 
"regular" company of adopting D if anyone there even imagined 
any of the above could happen.


We have to do better than this.

Atila


I don't think this is unusual even outside of D.
At least Microsoft seems to be willing to break your build if it 
moves things forward. For example, there are projects that worked 
fine on MSVC 15.4 (VS2017), but broke if you installed the update 
to 15.5 (or auto-updated in Visual Studio).

You can't test everything.

A lot of the "regular" companies, that desire high stability, 
typically use very old compilers and just workaround the bugs 
they know.
For a D example, I think Sociomantic was using D1 for a long time 
just because it was stable for them.


And if you need stability, why would you update the compiler 
without local testing and reserving time to fix any issues?

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

[user via Digitalmars-d]

When i hear Go, you hear uniformal, fast, simple syntax 
language.

When i hear Rust, you hear safe, manual memory management.
When i hear D, you hear ... ... ... ...


I usually hear awesome meta-programming and ranges.

I think D community had put lot of effort in making these things 
work because (1) these are cool (2) increases expressive power. 
Unfortunately at the detriment of tooling and libraries.


I think we should put a stop to adding new features in D2 at some 
point and focus on stability, libraries and tools.


Can't wait to see how the road map looks like for 18H1.

Re: Some Observations on the D Development Process

[Random D user via Digitalmars-d]

On Friday, 5 January 2018 at 03:28:10 UTC, Walter Bright wrote:

On 1/4/2018 2:34 AM, Mike Franklin wrote:
Walter seems to pop in daily, and occasionally reviews PRs, 
and his PRs of late are mostly just refactorings rather than 
fixing difficult bugs.

There's a lot of technical debt I've been trying to fix


While not directly applicable to 'technical debt', has anyone 
ever written a fuzzer for dmd?


Basically a testing software that generates valid or almost valid 
(negative case) input (code using grammar rules) and tries to run 
it through the application (compiler) to see what happens. These 
things usually reveal tons of easy to fix bugs at the application 
interface level and some hard to fix corner cases that no one 
thought. Best of all, you will get easy to use test cases that 
some else can try to fix. Unfortunately fuzzers often get stuck 
in local maximums, so you need to spend some time with app 
coverage using the generated data and modify the fuzzer 
accordingly. But once it has been built and it tests large code 
coverage, it's an awesome tool to reveal bugs and test changes. 
Just make a change, run tests, run fuzzer for 5-15 mins, 1h or 
days if you want extra coverage.


I think there's also a variant of this that takes valid code and 
replace existing code constructs with equivalent but unusual 
constructs.

Re: structs inheriting from and implementing interfaces

[Random D user via Digitalmars-d-learn]

On Friday, 29 December 2017 at 12:03:59 UTC, Mike Franklin wrote:

In C#, structs can inherit from and implement interfaces.
Is that simply because it hasn't been implemented or suggested 
yet for D, or was there a deliberate design decision?


Thanks for your insight,

Mike


I think it's deliberate, structs are just plain dumb value types.

If I remember correctly I think Remedy's Binderoo C++ bindings 
implemented C++ inheritance on top of structs. You might want to 
look at that.


Or you could do C-style "inheritance" and slap some D magic on 
top of that.


Some pseudo code:
struct Base
{
  enum SubType subtype;

  int someBaseField;
}

struct Child1
{
  Base base; // Must be first
  int foo;
}

struct Child2
{
  Base base;
  float bar;
}


Base b;
Child1 c1;
Child2 c2;

base_doSomething(Base* b);
child1_doSomething(Child1* c1);
child2_doSomething(Child2* c2);


base_doSomething(cast(Base*));

switch(base.subtype)
{
  case Child1:
child1_doSomething(cast(Child1*)); break;
  case Child2:
child2_doSomething(cast(Child2*)); break;
}

// add some alias this and other d things to smooth things out.

Re: .LIB pagesize exceeds 512

[user via Digitalmars-d-learn]

On Sunday, 10 December 2017 at 21:51:37 UTC, Mike Wey wrote:

On 10-12-17 16:57, user wrote:

Could someone please list some workarounds?

I am trying to compile a demo app from gtkd. I tried compiling 
gtkd using dub with --build=plain option and still got that 
error when compiling the demo app. Using the latest dmd.


Thanks in advance.


As far as i know the error is caused by the debug information, 
and using `--build=plain` for dub used to fix that, but that 
might have changed.


You could try building gtkD with the windows build script: 
`rdmd Build.d`


Or if possible build the 64bit version witch doesn't use 
optlink.


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


I ended up downloading LDC and it worked after downloading MS C++ 
build tools. But now I am get errors compiling vibe.d, I simply 
added vibe-d as dependency to the 'dub init'.



C:\vibe_test>dub
Performing "debug" build using ldc2 for x86.
memutils 0.4.9: target for configuration "secure" is up to date.
libasync 0.8.3: target for configuration "regular" is up to date.
vibe-d:utils 0.8.1: target for configuration "library" is up to 
date.
vibe-d:data 0.8.1: target for configuration "library" is up to 
date.
vibe-d:core 0.8.1: target for configuration "libasync" is up to 
date.
vibe-d:crypto 0.8.1: target for configuration "library" is up to 
date.

diet-ng 1.4.3: target for configuration "library" is up to date.
vibe-d:stream 0.8.1: target for configuration "library" is up to 
date.
vibe-d:textfilter 0.8.1: target for configuration "library" is up 
to date.
vibe-d:inet 0.8.1: target for configuration "library" is up to 
date.
vibe-d:tls 0.8.1: target for configuration "openssl-mscoff" is up 
to date.
vibe-d:http 0.8.1: target for configuration "library" is up to 
date.
vibe-d:mail 0.8.1: target for configuration "library" is up to 
date.
vibe-d:mongodb 0.8.1: target for configuration "library" is up to 
date.
vibe-d:redis 0.8.1: target for configuration "library" is up to 
date.
vibe-d:web 0.8.1: target for configuration "library" is up to 
date.

vibe-d 0.8.1: target for configuration "libasync" is up to date.
vibe_test ~master: building configuration "application"...
Warning: no Visual C++ installation detected
C:\Users\user\AppData\Roaming\dub\packages\libasync-0.8.3\libasync\ws2_32_ex.
lib : fatal error LNK1136: invalid or corrupt file
Error: C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\BIN\link.exe faile

d with status: 1136
ldc2 failed with exit code 1136.


:-(

.LIB pagesize exceeds 512

[user via Digitalmars-d-learn]

Could someone please list some workarounds?

I am trying to compile a demo app from gtkd. I tried compiling 
gtkd using dub with --build=plain option and still got that error 
when compiling the demo app. Using the latest dmd.


Thanks in advance.

Unable to compile GtkD on windows

[user via Digitalmars-d-learn]

I tried compiling GtkD, I get the error message:


rdmd Build.d

Error: more than 32767 symbols in object file


1. How to work around this?

2. Is D still unfriendly to newbies? I am disappoint :-(

Using:
DMD 2.077
GtkD 3.7.1
gtk3-runtime_3.22.24-1, 32bit

Re: So why double to float conversion is implicit ?

[User via Digitalmars-d]

Is there a list of such quirks or gotchas in dlang?

The ones I know of are

1. Implicit conversion from double to float

2. Integer division results in integer result truncation the 
fractional part.


3. ??

Re: My two cents

[Random D user via Digitalmars-d]

On Friday, 20 October 2017 at 02:20:31 UTC, Adam D. Ruppe wrote:

On Friday, 20 October 2017 at 00:26:19 UTC, bauss wrote:

return foo ?? null; would be so much easier.

return getOr(foo, null);


I guess with UFCS you could get:
return foo.PP(null); // vs.
return foo ?? null;

:D

Re: My first experience as a D Newbie

[Random D user via Digitalmars-d]

On Friday, 13 October 2017 at 13:14:39 UTC, Steven Schveighoffer 
wrote:

I don't know what the expectations of a Windows user are.


In my exprience 80% of mainly Windows devs (in professional 
environment) use Visual Studio + plugins (e.g. Visual 
Assist/Dpack etc.). Most of the remaining 20% use Visual Studio 
with vim keybindings/emulation or they code with vim/emacs, but 
use Visual Studio for debugging. And the last 2% use something 
completely different.


I think Visual Studio is the professional standard for C/C++/C# 
on Windows (as in Windows is the main platform and not some bad 
port hacked on top of cygwin). Basically what Xcode is for Mac.

Re: D on quora ...

[Random D user via Digitalmars-d]

On Friday, 6 October 2017 at 18:09:58 UTC, Ali wrote:

On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote:
On Fri, Oct 06, 2017 at 05:14:51PM +, Rion via 
Digitalmars-d wrote:

https://www.quora.com/What-is-your-review-of-D-programming-language

It seems that D still has the GC being mentioned up to today.

Maybe its better to move the standard library slower to a non 
gc version in the future...


Why is GC a problem?


T


The reputation is D's GC is slow, and Manual Memory Management 
is fast


Actually, Manual Memory Management is slow and D's GC is slower.

But IMO that kind of means GC isn't that big of a problem in D. 
Because, if malloc/free is slow (free is often slower), you want 
to avoid them as much as possible. You do this by reusing your 
memory/buffers. Which means that even if they are GC allocated 
buffers, they aren't collected and you are not allocating new 
buffers (often) after initial allocs, so the GC doesn't even run.


There was a good talk in cppcon2016 that gives you an example 
what high perf AAA games do for memory allocation. The presenter 
explains how they reduced memory allocations from 300 000 to 3000 
(https://youtu.be/tD4xRNB0M_Q?t=1200).

Re: DWT is official ?

[User via Digitalmars-d-dwt]

On Wednesday, 12 July 2017 at 10:10:53 UTC, Flaze07 wrote:
hi...so is this group forum about the SWT D bindings ? (I am 
just surprised that it is...in the ecosystem if it is what I 
think it is)


No, D does not have a official gui lib. The dlang core community 
is still small and hardly funded, it's mostly still a 
design-by-volunteers language. Therefore it's impossible to 
maintain any significantly sized lib in phobos. Especially when 
majority of the D users are web based programmers and there is no 
common consensus about which gui lib to pick.


The main focus is to improve safety, before that out used to be 
parallelism and concurrency, even before that it used to be 
speed, ufcs, duck typing etc.


Point is that gui libs or any major libs will almost never be 
official, unless it's web related.


Also, nowadays it's fashionable to design-your-own-lang so every 
major company has their own language now, it seems less and less 
likely that D will be sponsored by any major company. Therefore 
although the language seems to be evolving fast, quality tools 
and libs are evolving excruciatingly slowly.

Re: Problem with integral promotions

[Random D user via Digitalmars-d]

On Saturday, 22 July 2017 at 10:44:04 UTC, Walter Bright wrote:
1. Fix it so it matches C, as has been generally promised. 
Fixing it will break existing code such as:


If D was my language I'd fix it, since it's a bug.

D's fluidity and effortlessness comes from a lot of small 
compounding convenience features.
The converse is true as well. A lot of small annoyances 
accumulate into frustration.

Re: proposed @noreturn attribute

[Random D user via Digitalmars-d]

On Saturday, 8 July 2017 at 12:18:38 UTC, Andrei Alexandrescu 
wrote:

On 7/8/17 7:07 AM, bachmeier wrote:

On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote:


Having an @noreturn attribute will take care of that:

   @noreturn void ThisFunctionExits();


Why should this be an attribute rather than a pragma?


So it's part of the summary of the function. -- Andrei


If it feels like a pragma, should be part of the function and 
reflectable, then how about:


void assertFalse(bool cond) @pragma(noreturn)

or

void assertFalse(bool cond) @pragma("noreturn")

The compiler could probably give an error if the "" (inside 
@pragma) wasn't a known string.
Also @pragma would be useful as standard way of saying "special 
compiler attribute". No need to consume global attribute 
namespace.


I'm expecting to see @myproject_safe and @myproject_noreturn type 
of attributes someday in some project :|

Re: What are your hopes for the future D GC

[Random D user via Digitalmars-d]

On Friday, 30 June 2017 at 06:14:41 UTC, Dmitry Olshansky wrote:

On 6/29/2017 10:19 PM, Random D user wrote:
2. Composable custom memory block GC. The ability to mallocate 
128MB
memory block and create a new GC instance to manage that 
block. It would
only need to scan that 128MB block and not worry about rest of 
memory
and resources (with complex destruction orders) in 16GB heap. 
This way
you probably could guarantee good collection times for some 
subsystems

in your program and use your favorite allocator for others.



Not sure what benefit this has compared to just limiting GC 
heap to 128Mb.




More flexibility, control and tools for doing mixed memory 
management.


I was thinking that you could have multiple of these (thread 
local or single threaded, edge cases/safety would be user 
responsibility).
Basically turning gc into similar custom allocator as "bump the 
pointer" allocators or object pools. This way few of these GCs 
could be used as poor man's incremental GC.


I think it could be useful for applications that have tight 
memory and timing budgets.
For example, in games, you typically have couple bigger 
subsytems. Some game architectures preallocate all the memory 
they need and distribute it to each subsystem using custom 
allocators.
Maybe some systems with lot of small allocations could use 
"memory block local GC" and be fast enough. For example, some 
sort of a scripting or debug console subsytem could be fine with 
32MB, but you wouldn't need care about releasing your temp 
objects. Small heap size would guarantee fast collections.
And for some sort of incremental emulation you could manually 
trigger the collections and cycle between different local GC per 
frame or timestep. Also if any of the would pause for too long, 
you could easily just see which one and fix it.

What are your hopes for the future D GC

[Random D user via Digitalmars-d]

I just got curious, after reading the GC analysis blog post. What 
kind of features people generally would want for the GC (in the 
distant murky future of 1999)?


Here's some of my nice to haves:

1. Thread local GCs. D is by default thread local, so it kind of 
would make sense and goodbye stop everything GC.


2. Composable custom memory block GC. The ability to mallocate 
128MB memory block and create a new GC instance to manage that 
block. It would only need to scan that 128MB block and not worry 
about rest of memory and resources (with complex destruction 
orders) in 16GB heap. This way you probably could guarantee good 
collection times for some subsystems in your program and use your 
favorite allocator for others.


3. Callbacks to GC operations. I have timeline profiler 
implemented for my project. It would be quite cool to have GC 
collection starts and stops record a timestamp for the timeline.
(Can this be done already? Hopefully without recompiling the GC. 
I tried to look but I couldn't find any hooks in the docs.)


4. Incremental GC with collection time limit. Is this even viable 
for D?

Re: Let's paint those bikesheds^Werror messages!

[Random D user via Digitalmars-d]

On Tuesday, 27 June 2017 at 18:42:45 UTC, Vladimir Panteleev 
wrote:

On Tuesday, 27 June 2017 at 18:41:00 UTC, Random D user wrote:
What ever you do, please don't use extreme high intensity 
colors like red(255,0,0), green (0,255,0) or blue (0,0,255).


That's up to the terminal (or your configuration of it). 
Without making many assumptions, console applications are 
limited to 16 symbolic colors, with their exact values 
depending on the OS/terminal/configuration.


Right. I should've known that.
I guess I don't really use cmd prompt or bash much these days.
I'm pretty much always on windows and using Visual Studio for D, 
C/C++ and others with custom color plugin for errors. And GUI 
everywhere :).

Re: What are the unused but useful feature you know in D?

[Random D user via Digitalmars-d]

On Monday, 26 June 2017 at 22:17:00 UTC, Moritz Maxeiner wrote:

On Monday, 26 June 2017 at 18:47:18 UTC, Random D user wrote:
Anyway, I think we could just have a compile time switch for 
defaults.


Imagine having n libraries with pairwise different required 
defaults used in your application. Say goodbye to combined 
compilation, hello n separate required compiler invocations.




Yeah, that's true. I didn't really think of full source 
compilation of libs in your project. I though .lib would've been 
compiled with some settings and you'd just link with that and 
work with its api.


Also in reality I wouldn't want to be able to cancel @nogc in a 
function, because then the attribute would just lose power and 
you couldn't trust it. I just used it as a simple example for the 
@ and @! syntax that I'd like to have in general. Which would 
allow a nice way of working with sections of code like this:

class
{
@nogc:or @!gc:
... some code ..
@gc:or @gc:
... more code ..
@nogc:or @!gc:
... even more code ..
}



Also I think @safe is a little bit broken (because of @trusted 
and even the very pros (d-devs) seem to get @trusted wrong on 
a regular basis (at least that's my perception)). Just bite 
the bullet and use Rust if you want to be actually safe.


Except Rust is in exactly the same boat as D, because the same 
issues that apply to `@trusted` apply to `unsafe`, as well.


Hmmm, I guess that's true. I don't really know a lot about Rust. 
Their safety story just sounds way more convincing and believable 
than D's. It would probably be the first language I'd look into 
if I was interested in low level safety critical code.

Re: Let's paint those bikesheds^Werror messages!

[Random D user via Digitalmars-d]

On Tuesday, 27 June 2017 at 14:32:28 UTC, Vladimir Panteleev 
wrote:
With 2.075's release near, now would be a good time to decide 
on a nice color palette that looks fine on most terminals. So, 
please vote:


What ever you do, please don't use extreme high intensity colors 
like red(255,0,0), green (0,255,0) or blue (0,0,255). They'll 
burn through your eyes and look bad on either white or black.
If you replace 0s with 32 and 255s with 192 you'll get colors 
that are more easy on the eyes and will work better on both black 
and white backgrounds.


Another strategy is to use HSV.
Set saturation and value something decent like 80 and 75.
Then loop through hue with 360 / num_colors step + good offset.
Now you should get enough colors that are as far from each other 
as they can be and give good contrast.
You can quickly preview this in some photo editor, or maybe even 
faster by writing some d code :)


I guess the next level would be actual color design instead of 
nerdy math.

Re: What are the unused but useful feature you know in D?

[Random D user via Digitalmars-d]

On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:

1) Add the opposite attributes: `impure`, `throws`, `@gc`, etc.
2) Add the module version thing that changes defaults on request
3) imagine more potential going forward


I dislike doubling the keywords by having a 'not' case for each.
I'd rather have a systematic way of adding/removing attributes 
and udas.


Something like:
@gc
@!gc  (previously @nogc, compiler could even rewrite @nogc into 
@!gc for transition)


---

Anyway, I think we could just have a compile time switch for 
defaults.
Since some projects want to have pure, @safe, immutable by 
default, but others want to have @system @nogc. And no one wants 
write attributes more than they have to.


For example, I kind of like the current defaults since I like 
flexibility/changeability/editability of code. Because that makes 
coding fun which in turn usually means better code, features and 
productivity. Strictness is just a kind of salt that can be 
sprinkled on code in few difficult or dangerous cases.


Also I think @safe is a little bit broken (because of @trusted 
and even the very pros (d-devs) seem to get @trusted wrong on a 
regular basis (at least that's my perception)). Just bite the 
bullet and use Rust if you want to be actually safe.


I'm not a huge fan of immutable/const system either as it's kind 
of difficult to use and low benefits. It often leads into 
backtracking and changing your code all over the place (small 
change becomes an avalanche), because you found out in the last 
leaf function of your subsystem, that your design can't actually 
be immutable (basically, you forgot or couldn't imagine that 
elusive corner case no. 99).
The good thing is that immutable/const is actually strict and 
checkable. No holes like in @safe.


So if this change would happen, I would probably start all of my 
d files with

impure:
@system:
(@nogc:) // depending on my needs, I actually haven't had big 
issues with the gc

(nothrow:)
...

Which reminds me that it would be nice to group attributes as 
well.

Something like this:
alias @apiStrict = @safe immutable pure

int foo() @apiStrict
{
  return 1;
}

Re: DMD now has colorized syntax highlighting in error messages

[Random D user via Digitalmars-d-announce]

On Sunday, 14 May 2017 at 14:07:20 UTC, Walter Bright wrote:

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

It turned out to be unexpectedly easy to implement.


Nice.

But color highlighting should always be configurable (otherwise 
it's half done), because there are a lot of people who like 
colors, but can't distinguish between certain color combinations, 
because of a color disability. Or they might have poor displays 
or viewing conditions etc.


I guess this should be simple to add, just output the colors into 
an .ini file and read them back if the file exists.

Re: DIP 1003 Formal Review

[Random D user via Digitalmars-d]

On Sunday, 14 May 2017 at 15:39:12 UTC, Walter Bright wrote:

On 5/12/2017 9:17 AM, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove 
body as a

Keyword", is now underway.


A combination of Options 1 and 2:

1. Introduce 'function' as an alternative to 'body'.


How about using some other keyword like, with, else, scope or do, 
for example.
Would they read better than 'function' (i.e. function with vs. 
function function vs. function body)? Let's experiment a bit.


int foo()
in
{
}
out
{
}
with
{
  bar();
}

-- or

int foo()
in
{
}
out
{
}
else  // I guess this could be too confusing with template 
constraint? See below.

{
  bar();
}

int foo(T)() if(cond)
in
{
}
out
{
}
else
{
}

-- or

int foo()
in
{
}
out
{
}
scope
{
  bar();
}

-- or

int foo()
in
{
}
out
{
}
do
{
  bar();
}

Re: Python : Pythonista / Ruby: Rubyist : / D : ?

[Random D user via Digitalmars-d]

On Friday, 21 April 2017 at 22:11:19 UTC, Namespace wrote:

nuDist - in D you can program as free as you want. ;)


void main()
body
{
  asm
  {
 naked;
  }
}

Re: I think is a bug?

[Random D user via Digitalmars-d-learn]

On Sunday, 12 March 2017 at 01:55:20 UTC, ketmar wrote:

Random D user wrote:


How come string* suddenly has a .length property?


due to automatic pointer dereferencing that `.` does. no, not a 
bug.


Ah... right. Silly me. Of course, since string is actually 
immutable(char)[].
That's bit of a nasty corner case where -> == . isn't that nice. 
Fortunately, it's rare.


Thanks.

This happened to me, when I was packing stuff into SoA layout and 
didn't want to duplicate the length in the struct (implicitly by 
using []). Of course, I forgot to update one place to use the 
shared length.

That is:

length
ptr
ptr
ptr

instead of

ptr
length
ptr
length
ptr
length

Perhaps I should do a SoA layout template that somehow disables 
.length on individual arrays.

I think is a bug?

[Random D user via Digitalmars-d-learn]

int*[] foo;
foo.length = 5;

import std.c.string;
int* baz = cast(string*)malloc(50);

import std.c.stdio;
printf("%d %d", foo.length, baz.length );

prints:
Error: no property 'length' for type 'int*'

BUT:

string*[] foo;
foo.length = 5;

import std.c.string;
string* baz = cast(string*)malloc(50);

import std.c.stdio;
printf("%d %d", foo.length, baz.length );

compiles and prints:
5 -842150451

How come string* suddenly has a .length property?
Anyway the result is garbage, so I think this must be a bug.

DMD32 D Compiler v2.073.2

Re: Independent Study at my university using D

[Random D user via Digitalmars-d-announce]

On Monday, 6 March 2017 at 02:25:41 UTC, Jeremy DeHaan wrote:
The precise GC is going to continue to hang until it can be 
tweaked to be as fast or faster than the conservative GC we 
have now.


In which cases?
Shouldn't this be pulled and put behind a switch? I thought D's 
GC was supposed to be pluggable.


This way people could actually try to use it easily and provide 
valuable real-world feedback and use cases. With some luck we 
could even get someone to contribute/improve the GC (at least for 
their use cases).


It doesn't have to be the default. It doesn't have to be perfect 
to be released as experimental.


I would probably try it if I could enable it with a simple 
compiler/application switch, but I'm not going to pull and build 
it from the source.


Sounds to me like current situation actively blocks people from 
contributing instead of encouraging them.

Why can't I init a new var from const var?

[Random D user via Digitalmars-d-learn]

I can init a variable from mutable source without defining any 
constructor or assignment operators, but not if the source is 
const. I would imagine the behavior to be the same with mutable 
and const source, since it's just reading the source and copying 
it.


Is there a reason for this? Or is this a bug?
I can workaround this by making copies or casting, that just 
creates ugly code everywhere.


Here's an example (with dmd 2.073):

struct Foo
{
this( Foo source )
{
buf = source.buf.dup;
}

this( const Foo source )
{
buf = source.buf.dup;
}

this( const ref Foo source )
{
buf = source.buf.dup;
}

void opAssign( Foo source )
{
buf = source.buf.dup;
}

void opAssign( const Foo source )
{
buf = source.buf.dup;
}

void opAssign( const ref Foo source )
{
buf = source.buf.dup;
}

char[] buf;
}

Foo fun(const ref Foo foo, Foo foo2)
{
Foo bar  = foo; // Error: cannot 
implicitly convert expression (foo) of type const(Foo) to Foo
Foo baz  = foo2;// Ok, No need for 
constructors or opAssign
Foo baz2 = cast(const Foo)foo2; // Error: cannot 
implicitly convert expression (Foo(null).this(foo2)) of type 
const(Foo) to Foo

Foo bar2;
bar2 = foo; // uses opAssing( const 
Foo ) / opAssign( const ref Foo )

Foo bar3;
bar3 = foo2;// uses opAssign( const 
Foo ) / opAssign( Foo )

Foo bar4;
bar4 = cast(const Foo)foo2; // uses opAssing( const 
Foo )


//Foo bar = Foo(foo); // This works provided there is 
non-const opAssign defined.

//Foo bar = cast(Foo)foo; // This seems to work as well
return bar;
}

Foo foo;
foo = fun(foo, foo);

Re: memcpy() comparison: C, Rust, and D

[Random D user via Digitalmars-d]

On Wednesday, 1 February 2017 at 23:49:29 UTC, H. S. Teoh wrote:
We would love to change the defaults, but unfortunately that 
boat has already sailed a long time ago.


What if d had a -safe-defaults switch? It should be ok, since 
safe is stricter than unsafe right?


This way old/existing code would compile fine by default, but if 
you want to use that code/lib with safe-defaults you either have 
to do trusted wrappers or modify it to be safe.


All new code with safe-defaults would compile fine in safe mode 
and unsafe mode.


To me it's similar approach to 'warnings-all' and 
'warnings-as-errors'.


---

I myself don't really care for @safe, it's complex and seems to 
have big practical hole with @trusted. Kind of like 'refs can't 
be null in c++' (as some people claim/argue) and then someone 
passes nullptr into function ref arg. Completely unreliable, even 
though refs  usually work ok 99% of the time (by conventions and 
effort).


I've already thrown const, immutable, inout mostly in to trash 
(string literals etc. are exception) after few tries. They make 
the code more complex and harder to modify especially when you 
have bigger system. Often you realize that your system/module 
isn't truly 100% const in the last insignificant leaf function, 
and that triggers large  cascading modifications and rewrites, 
just to get the code work. Also I can't really remember when I 
accidentally modified data that I shouldn't have (i.e. violate 
const protection). But I often modify correct data incorrectly. I 
believe most programmers first figure out what they need to do 
before doing it instead of just writing randomly into some 
array/pointer that looked handy :)


I prefer flexible (fun), fast and debuggable (debugger/printing 
friendly) code. It seems that neither @safe or const are part of 
it. (I'm not writing life and death safety critical code anyway).

Re: GtkD 3.5.0, GTK+ with D.

[dlang user via Digitalmars-d-announce]

On 01/07/2017 11:32 AM, Gerald wrote:

On Saturday, 7 January 2017 at 16:46:38 UTC, dlang user wrote:

When I compile the HelloWorld.d demo code on version 3.4.1 in debug
mode the resulting file size is 26.4MB, when I compile the same code
with 3.5.0 the file size is 70.7MB, that is quite a jump in size.  I
am using DMD V2.072.2 on 64bit Debian testing.


As you are probably aware, GtkD auto-generates code. Unfortunately,
adding the ability to remove event handlers generated an increase in the
size of code, instead of just tracking the delegate directly it now uses
a wrapper class to also track the connect flags and returned handlerId.
Right now a unique wrapper class is generated for each event handler
which I suspect is the primary culprit for the increase in size.

If this size increase is a major concern, one option might be for me to
try to use a generic wrapper class instead of a generating a unique one.
This would mean converting the generated code to cast the delegate
before using it.

I'll let Mike chime in with his thoughts first though before looking too
much into it.





No, the size increase isn't a concern for me at all. It was just an 
observation that I made using the new version, and I wasn't sure if it 
was expected or not.

Re: GtkD 3.5.0, GTK+ with D.

[dlang user via Digitalmars-d-announce]

On 01/06/2017 04:00 PM, Mike Wey wrote:

GtkD is a D binding and OO wrapper of Gtk+ and is released on the LGPL
license.

Close to the 3.4 release, but the new functionality to now also remove
registered signal handlers added by Gerald Nunn warrants a new release.
Signal handles can be removed with the
`gobject.Signals.Signals.handlerDisconnect` function.

```
gulong id = addOnDraw();

Signals.handlerDisconnect(this, id);
```

Users who previously removed there handlers from the internal array used
by GtkD will need to update there code to the new system.

Changelog: http://gtkd.org/changelog.html
Download: http://gtkd.org/Downloads/sources/GtkD-3.5.0.zip



When I compile the HelloWorld.d demo code on version 3.4.1 in debug mode 
the resulting file size is 26.4MB, when I compile the same code with 
3.5.0 the file size is 70.7MB, that is quite a jump in size.  I am using 
DMD V2.072.2 on 64bit Debian testing.

Re: Vision document for H1 2017

[Random D user via Digitalmars-d-announce]

On Wednesday, 4 January 2017 at 21:07:00 UTC, H. S. Teoh wrote:
On Wed, Jan 04, 2017 at 08:45:09PM +, Stefan Koch via 
Digitalmars-d-announce wrote: [...]
I claim dips on templates. (as in the colloquial english for 
asserting

rights/ownership )

[...]

FYI, it's spelt "dibs" (with a 'b'). ;-)


T


Actually, I think it's spelt "DIPs" (with capitalization) in 
dland ;)


-- Just a random thought

Re: fPIC Error

[dlang user via Digitalmars-d-learn]

On Thursday, 3 November 2016 at 06:11:48 UTC, rikki cattermole 
wrote:
Took me a while to replicate your build environment but it 
looks like a false alarm.


rikki@debian:/tmp/test$ dmd test.d
rikki@debian:/tmp/test$ file test
test: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
for GNU/Linux 2.6.32, 
BuildID[sha1]=0a6394b9ec9b82e07440ab62cd71932f0ab568d1, not 
stripped


rikki@debian:/tmp/test$ ./test
Edit source/app.d to start your project.

rikki@debian:/tmp/test$ cat /etc/dmd.conf
;
; dmd.conf file for dmd
;
; dmd will look for dmd.conf in the following sequence of 
directories:

;   - current working directory
;   - directory specified by the HOME environment variable
;   - directory dmd resides in
;   - /etc directory
;
; Names enclosed by %% are searched for in the existing 
environment and inserted

;
; The special name %@P% is replaced with the path to this file
;

[Environment32]
DFLAGS=-I/usr/include/dmd/phobos 
-I/usr/include/dmd/druntime/import -L-L/usr/lib/i386-linux-gnu 
-L--export-dynamic -fPIC -defaultlib=libphobos2.so


[Environment64]
DFLAGS=-I/usr/include/dmd/phobos 
-I/usr/include/dmd/druntime/import 
-L-L/usr/lib/x86_64-linux-gnu -L--export-dynamic -fPIC 
-defaultlib=libphobos2.so


Thanks for looking at it and confirming you are seeing the same 
thing.


I am no expert, but after some additional research I think I see 
what is going on.  From what I read the gcc -fPIC option creates 
a shared library, while gcc -fPIE option creates an executable.  
You can also create a dual purpose file that is a shared library 
and is also executable by creating a shared library if that file 
also contains a main function (that might be oversimplified a 
little bit).


Looking at the dmd documentation, it only has a -fPIC option, 
there is no -fPIE option, which has the following description:


generate Position Independent Code (which is used for building 
shared libraries).


So, if I am understanding everything correctly because dmd only 
has -fPIC, the only option is to create a dual purpose file that 
is both a shared library and executable.

fPIC Error

[Dlang User via Digitalmars-d-learn]

I am running Debian Testing and I think I have run into the 
recent fPIC issue.  This is the source code for the test project 
I am using:


import std.stdio;

void main()
{
writeln("Edit source/app.d to start your project.");
readln();
}


When I try to compile a project, I get the following errors 
(truncated for brevity):



/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libphobos2.a(thread_26c_155.o): relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC

/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
dmd failed with exit code 1.
Exit code 2
Build complete -- 1 error, 0 warnings

I followed the advice to add "-defaultlib=libphobos2.so -fPIC" to 
my dmd.conf file as a workaround.


This causes it to build without errors, but now the resulting 
executable is marked as a shared library:


Output of the file command:

fpictest: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 2.6.32, 
BuildID[sha1]=e83ac1d5dea9e78912a6175d3c1c54b50b4e29cd, not 
stripped


Is this a known issue with this workaround or is there some other 
setting that I need to change?

Nemiver Debugger

[dlang user via Digitalmars-d-debugger]

I am trying to use Nemiver (V0.9.6) on Debian Testing, but I can 
only get it to show the assembly, the source code isn't there.


I can get Nemiver to show the source code for a C++ hello world 
app, so it seems to working for C++.


I can also debug my D app and see the source code using either 
Monodevelop or GDB via the tui mode, so it seems like it is 
compiled with the debug information.


Searching through the forums, I see some posts where people are 
saying that that they are using it.


Does anyone have any suggestions?

Re: color lib

[Random D user via Digitalmars-d]

On Thursday, 6 October 2016 at 14:53:52 UTC, Manu wrote:
I've done another pass incorporating prior feedback, mostly 
focusing on documentation.


Just a quick minor comment on:
A8  RGB!("a",ubyte,false,0)  8 bit alpha-only color type.
-->
Reads like, "False what ???". Also "What is 0 ???".
-->
How about RGB!("a", ubyte, Linear.No, Colorspace.sRGB) or 
something like that,

since there's going to be a list of these in the docs.

What does colorspace 0 mean actually? (AdobeRGB??? i.e. first 
from colorspace enum according the docs).

Re: colour lib needs reviewers

[Random D user via Digitalmars-d]

On Tuesday, 13 September 2016 at 02:00:44 UTC, Manu wrote:
On 13 September 2016 at 07:00, Marco Leise via Digitalmars-d 
 wrote:

Am Tue, 13 Sep 2016 00:37:22 +1000
schrieb Manu via Digitalmars-d :
Alright, but hybrid gamma is really not something that can be 
googled. Or rather I end up at Toyota's Gamma Hybrid product 
page. :D


True. I'm not even sure what the technical term for this sort 
of gamma

function is... I just made that up! :/
As Walter and others have asked, I'll have to start adding 
links to
reference material I guess, although that still feels really 
weird to

me for some reason.


FWIW I stumbled into this while double-checking HDR standards for 
my previous post. (I'm not a HDR expert, only somewhat interested 
because it's the future of displays/graphics)


https://en.wikipedia.org/wiki/Hybrid_Log-Gamma

Re: colour lib needs reviewers

[Random D user via Digitalmars-d]

On Tuesday, 13 September 2016 at 01:05:56 UTC, Manu wrote:


Can you describe what  you  perceive to be hard?


Well, I just skimmed through the docs and I didn't look at the 
code, so that sense it was an "honest" view for phobos proposal. 
Also I was trying to convey that based on the docs it "looks 
hard", although I was suspecting that it isn't really.


So the list of things was a list of examples that I would've 
wanted to see in the docs. Maybe in an overview or "here's how 
you use it" page. I can read the details if I really need them, 
but I think it's important to have a cook book examples for quick 
start.


In general, I think basics should be dead simple (even over 
simplified for the very basic case), but the API and the docs 
should provide me layers of increasing detail and sophistication, 
which I can study if (or when) I really need control and care 
about the details.



Few basic things I'd be interested in (examples):
1. How to pack/unpack color into uint/rgba channels.


auto c  = RGBA8(r, g, b, a);
uint r = c.r.value; // 'r' is a 'NormalizedInt", so you need 
'.value'

to get the raw integer value
float g = cast(float)c.g; // cast to float knows about the 
normalized 0-1 range


Let's put these in the docs.




Also can I swizzle channels directly?


I could add something like:
  auto brg =  c.swizzle!"brg";


It's just a nicety. I guess I could just define exact color 
formats and convert (let the lib do the rest), or just unpack and 
repack.


Also the docs might want to mention which way is the 
preferred/designed way.


2. Can I just cast an array of bytes into a RGBA array and 
operate on that?


Yes. Of course, if the image library returned an array of 
colors, you wouldn't have an array of raw bytes in the first 
place.


Cool. I just wanted to make sure something like this possible.

Also should be in the docs as an example, so that people don't 
have to try this out themselves.

Or search through github for details.



3. How to scale color channels e.g. 5 bits to 8 bits and vice 
versa. How to convert color formats? Can I combine 
scale/conversion with single channel or channel swizzling?


alias CustomPackedColor = PackedRGB!("BGR_5_6_5", ubyte); // <- 
ordered bgr

CustomPackedColor[] image = loadPackedImage();

auto unpacked = cast(RGB8)image[0]; // unpack and swizzle

I'm not sure what you mean by "with single channel"?


For example if you first unpack RGBA_uint32 into R,G,B,A then you 
want to take G (or just swizzle color.g) and scale that to 5 bits 
or 16 bits for what ever use case you might have.


Looks to me like this can be handled with something like 
PackedRGB!("G_5") and then do color conversion into that.




4. Which way are RGBA format names defined ("byte array order" 
r is first byte or "uint order" r is in high bits)?


I describe formats in byte (bit) order. It's the only 
reasonable way

that works outside of a uint.


Agreed. This should be in the docs, so that it's clear to users. 
(especially, since RGBA is the common case and it does fit 
into uint)




I'm showing that parsing colors from string's follow the web
convention. I can't redefine how colours are expressed on the 
web for

decades.
I think you've just highlighted that I need to remove the '0x'
notation though, that is definitely misleading! Use '#', that 
should

be clear.


Right. I was interpreting 0x as c hex literal. You should 
document that it's following the web convention.


6. Perhaps you should define all the usual color formats, 
since everybody

and their cat has their own preference for rgba channel orders.
In my experience all these 4 variants for RGBA are pretty 
common:

RGBA
BGRA
ARGB
ABGR
and their X and 24bit variants.


I don't think they're common at all. Only 2 are common (one of 
which

is deprecated), the other 2 are very niche.


Deprecated by who? Shouldn't phobos grade lib include all 
reasonable platforms?


I agree that you probably don't see too much variation within 
windows APIs, images (BMP etc.) or with D3D GPU textures (they're 
compressed anyway and asset pipelines to do the conversions 
beforehand), but I was more of thinking image libraries and the 
numerous, sometimes old and quirky, image formats. Or perhaps 
someone wants to implement a software blitter for their favorite 
toy device/embedded project.


I was trying to balance a tasteful amount of instantiations. I 
don't

really want to provide an instantiation of every single realtime
format I've ever encountered out of the box.

Seems reasonable.




For 16 bits fairly common are:
RGB565 and RGBA5551, also sometimes you see one of RGBA 
permutations

(like RGBA8 above).


Nobody uses 16bit textures anymore. Compressed textures are 
both MUCH smaller, and generally higher quality.


Sure, agreed. These are not too useful as GPU textures these days 
(even on mobile), but if you do software 2d, load older image 
formats (image viewer etc.) or something even 

Re: colour lib needs reviewers

[Random D user via Digitalmars-d]

On Monday, 12 September 2016 at 04:14:27 UTC, Manu wrote:
I think I'm about as happy with my colour lib as I'm going to 
be. It really needs reviews.


- Manu


Hi. I'm just a random forum lurker, but here's my feedback.

It needs more docs/examples for the basic usage cases (i.e. how 
to skip docs and start working).


Now at first glance it looks like working with RGBA (most common 
case (with srgb)) is complicated and while reading the docs I 
kind of felt like I'd just write my own.


Few basic things I'd be interested in (examples):
1. How to pack/unpack color into uint/rgba channels. Also can I 
swizzle channels directly? How would I extract a single channel 
from color?
2. Can I just cast an array of bytes into a RGBA array and 
operate on that?
3. How to scale color channels e.g. 5 bits to 8 bits and vice 
versa. How to convert color formats? Can I combine 
scale/conversion with single channel or channel swizzling?
4. Which way are RGBA format names defined ("byte array order" r 
is first byte or "uint order" r is in high bits)?

5. Is it the same for packed rgba formats?
I'm not sure if packedrgb is a necessary distinction. Aren't they 
all kind of packed (small structs)? There's no guarantee that 1 
byte is not just a part of a bigger field.


Btw. Your RGBA8 example is a bit weird:
static assert(RGBA8("0x908000FF") == RGBA8(0x80,0x00,0xFF,0x90));
I'd assume RGBA8(r,g,b,a) would be either "uint order" r(0x90), 
g(0x80), b(0x00), a(0xFF) or "byte array order" (le) r(0xFF), 
g(0x00), b(0x80), a(0x90)


6. Perhaps you should define all the usual color formats, since 
everybody and their cat has their own preference for rgba channel 
orders.
In my experience all these 4 variants for RGBA are pretty 
common:

RGBA
BGRA
ARGB
ABGR
and their X and 24bit variants.

For 16 bits fairly common are:
RGB565 and RGBA5551, also sometimes you see one of RGBA 
permutations (like RGBA8 above).
Also L16 is pretty common for heightfields or other data 
images/textures.


I guess there are also planar formats, but I think those are more 
of a Image problem space.


Just as a completely random idea - How about aliases for HDR 
formats like HDR10 and Dolby Vision? Kind of looks like they're 
just combinations what you already have.

Re: How to detect/filter modules in __traits(allMembers)?

[Random D user via Digitalmars-d-learn]

On Saturday, 11 June 2016 at 20:30:47 UTC, Basile B. wrote:

On Saturday, 11 June 2016 at 19:45:56 UTC, Random D user wrote:

Any good ideas how to do that?

I couldn't figure it out in a short amount of time, but I 
expect that it's possible. I'm probably missing something 
obvious here. Probably because D's reflection/meta programming 
facilities are a bit all over the place (and unnecessarily 
convoluted IMO).
Also I'm not super familiar with every compile-time feature, 
which is why I want to learn and some meta functions/templates 
myself.


[...]


It will compile if you define the option informational warnings 
(-wi).


Yes, ignoring deprecations gets me forward (basically the same as 
dropping back to previous compiler version), but I'd rather 
figure out/know a proper solution.


I suppose I could wrap those structs (with UDA) into a another 
named struct or empty template to split them into a separate 
"namespace" from the import modules.
I guess that wouldn't be as bad since all the structs are similar 
which means their names are similar. So basically, NameType would 
become Type.Name. Hmm...


Anyway, that workaround seems a bit silly, so I'm hoping to find 
a proper, generic and robust solution without any gimmicks.

How to detect/filter modules in __traits(allMembers)?

[Random D user via Digitalmars-d-learn]

Any good ideas how to do that?

I couldn't figure it out in a short amount of time, but I expect 
that it's possible. I'm probably missing something obvious here. 
Probably because D's reflection/meta programming facilities are a 
bit all over the place (and unnecessarily convoluted IMO).
Also I'm not super familiar with every compile-time feature, 
which is why I want to learn and some meta functions/templates 
myself.


In my usecase I want to extract structs with UDAs from a module, 
which also imports bunch of stuff. Now __traits(allMembers) gives 
me the list of things (in strings) that the module contains. This 
includes module imports and when I do something like this (in 
pseudo D):


template
{
  foreach(name ; __traits(allMembers, MODULE) )
foreach(attr_name ; __traits(getAttributes, 
__traits(getMember, MODULE, name)))

  whatever logic...
}

I get "Deprecation: foo.bar is not visible from module baz" with 
2.071+ compiler (i.e. import symbol lookup rules changed) where 
foo.bar is an import in MODULE and baz is the module where the 
template for code above is located. And I'm calling the template 
from yet another module qux. This used to work with previous 
versions (modules were just skipped).
The trouble begins when an import module is passed to 
__traits(getMember). (however I can do __traits(hasMember) which 
is a bit weird, since I'd assume same visibility rules would 
apply).


Here's a pseudo example:

mymodule.d:
import foo.bar;
@uda
struct mystruct

baz.d
template get_uda_structs

qux.d
import mymodule.d
import baz.d
auto structs = get_uda_structs(mymodule, uda); // Won't compile: 
"Deprecation: foo.bar is not visible from module baz"

Re: [dlang.org] new forum design - preview

[Random D user via Digitalmars-d]

On Friday, 15 January 2016 at 05:56:37 UTC, Vladimir Panteleev 
wrote:

- A specific list of things that can be improved


I too like the current soft dark theme of the forum (and website).

Would it be possible to have optional dark theme in the forum 
settings?


I wish the main website would have a dark alternative too, 
because I might have language/phobos docs open all day on my 
second monitor.


The forum theme also has grey text on grey background (almost the 
same gray) in few places which makes it hard to read.


While neutral gray is fine as background for black text in a 
darker theme, I don't really like its usage as part of visual 
elements in the current light theme. IMO big neutral gray boxes 
make the site look really boring (like a rainy day). And even the 
red seems a bit like sun burnt and used.

Re: AA struct hashing bug?

[Random D user via Digitalmars-d-learn]

On Tuesday, 8 December 2015 at 11:04:49 UTC, Random D user wrote:

I need to look into this more.


Ok. This is minimal app that crashes for me. If someone could try 
this:


class App
{
this()
{
}

void crash( int val )
in
{
assert( val == 1 );
}
body
{
struct Foo
{
this( int k )
{
a = k;
}
int a;
}

Foo foo;
int[ Foo ] map;

map[ foo ] = 1;  // Crash! bug?
}
}

int main( char[][] args )
{
App a = new App;
a.crash( 1 );

return 0;
}

And the previous case for the crash looks like this:
asm:
_D6object14TypeInfo_Class7getHashMxFNbNexPvZm:
7ff6d9e4b500  push rbp
7ff6d9e4b501  mov rbp, rsp
7ff6d9e4b504  sub rsp, 0x30
7ff6d9e4b508  mov [rbp-0x8], rsi
7ff6d9e4b50c  mov rsi, [rdx]
7ff6d9e4b50f  test rsi, rsi
7ff6d9e4b512  jz 
_D6object14TypeInfo_Class7getHashMxFNbNexPvZm+0x20 
(0x7ff6d9e4b520)

7ff6d9e4b514  mov rcx, rsi
7ff6d9e4b517  mov rax, [rsi]
7ff6d9e4b51a  call qword near [rax+0x10] < 
crash here
7ff6d9e4b51e  jmp 
_D6object14TypeInfo_Class7getHashMxFNbNexPvZm+0x22 
(0x7ff6d9e4b522)

7ff6d9e4b520  xor eax, eax
7ff6d9e4b522  mov rsi, [rbp-0x8]
7ff6d9e4b526  lea rsp, [rbp]
7ff6d9e4b52a  pop rbp

stack:

_D6object14TypeInfo_Class7getHashMxFNbNexPvZm() + 0x1e bytesD
_D6object14TypeInfo_Const7getHashMxFNbNfxPvZm() + 0x13 bytesD
application.Application.startup.Foo.__xtoHash( 
application.Application.startup.Foo* p, ulong h ) + 0x55 bytes	D

_D6object15TypeInfo_Struct7getHashMxFNaNbNfxPvZm() + 0x22 bytes D
_aaGetY() + 0xa0 bytes  D
application.Application.startup() Line 159 + 0x26 bytes D

Re: AA struct hashing bug?

[Random D user via Digitalmars-d-learn]

On Tuesday, 8 December 2015 at 01:23:40 UTC, Ivan Kazmenko wrote:

On Monday, 7 December 2015 at 22:03:42 UTC, Alex Parrill wrote:

On Monday, 7 December 2015 at 18:48:18 UTC, Random D user
Tested the same code with -m32 and -m64 on Windows.  Works for 
me, too.


I tried this again. And it seems it might be my bug or that the 
runtime somehow corrupts it's state. Scary.


So I have an App class that gets created in main.
Basically
App = new App
App.start();

If I put that code as the first thing in the constructor 
everything works.
If I put that code as the first thing in the first method after 
constructor it crashes.

And that code is completely unrelated to everything else.
Without the code snippet the whole app works fine.
Also if I wrap the code in a local funtion or class, it works 
fine even in the first method.


I need to look into this more.

Re: How to make a transparent wrapper type?

[Random D user via Digitalmars-d-learn]

On Monday, 7 December 2015 at 20:03:07 UTC, Namespace wrote:

This seems to work:

struct RefVal(T) {
private T* ptr;

this(T* val) {
ptr = val;
}

ref auto opAssign(U)(auto ref U value) {
*ptr = value;

return *ptr;
}

auto get() inout {
return ptr;
}
}



Yes. It works for assignment as expected. Thanks. I don't know 
why I didn't try that. I mean I tried something like this:


struct RefVal(T)
{

}

Re: How to make a transparent wrapper type?

[Random D user via Digitalmars-d-learn]

On Tuesday, 8 December 2015 at 10:26:18 UTC, Random D user wrote:

On Monday, 7 December 2015 at 20:03:07 UTC, Namespace wrote:

This seems to work:

struct RefVal(T) {
private T* ptr;

this(T* val) {
ptr = val;
}

ref auto opAssign(U)(auto ref U value) {
*ptr = value;

return *ptr;
}

auto get() inout {
return ptr;
}
}



Yes. It works for assignment as expected. Thanks. I don't know 
why I didn't try that. I mean I tried something like this:


struct RefVal(T)
{

}


Whoops. For some reason lost focus to window while typing and 
accidentally sent the message.


Well. Anyway, I tried something similar using alias this and 
template functions, but obviously it didn't work.


Unfortunately. Your version doesn't work with methods. For 
example if Ref!T is Ref!Struct then ref.method() doesn't work. 
That's the reason for alias this.

But it's good enough with public ptr.

Maybe opDispatch could help here. I haven't really used it so far.

AA struct hashing bug?

[Random D user via Digitalmars-d-learn]

struct Foo
{
this( int k )
{
a = k;
}
int a;
}

Foo foo;
int[ Foo ] map;

map[ foo ] = 1;  // Crash! bug?

// This also crashes. I believe crash above makes a call like 
this (or similar) in the rt.

//auto h = typeid( foo ).getHash(  ); // Crash!

win64 & dmd 2.69.2

How to make a transparent wrapper type?

[Random D user via Digitalmars-d-learn]

I kind of miss reference values on stack, so I attempted to make 
one in a struct.
Pointers are pretty good (since d doesn't have ->), but it would 
be nice to avoid dereferencing them explicitly on assignment.


Since reference is a pointer that you can't change afterwards.
I tried something like this:

struct RefVal( T )
{
this( T* val )  {   ptr = val;  }

ref auto opAssign( T value ){   *ptr = value; return 
*ptr;  }
ref auto opAssign( ref T value ){   *ptr = value; return 
*ptr;  }


alias ptr this;
T* ptr;
}

This works for most basic cases but breaks in:

struct Foo
{
this( int k )
{
a = k;
}

void opAssign( int k )
{
a = k;
}

int a;
}

Foo foo = Foo(2);
Foo baz = Foo(3);
RefVal!Foo bar = RefVal!Foo(  );

bar = baz;

bar = 5; // Ooops! doesn't work

Is there a way to transparently pass everything to *RefVal.ptr?

Also is there a way to make "alias ptr this" to work with 
"private T*"?
Ideally I wouldn't want to give access to the ptr, but for now 
it's handy as a workaround.

Re: Three people out of four dislike SDL

[user via Digitalmars-d]

It all started here 

http://forum.dlang.org/post/evxhpxfkeorrrkhqz...@forum.dlang.org
:-)

... or one of the posts in that thread, I mean.

Re: Builtin array and AA efficiency questions

[Random D user via Digitalmars-d-learn]

Ah missed your post before replying to H.S. Teoh (I should 
refresh more often).

Thanks for reply.

On Thursday, 15 October 2015 at 19:50:27 UTC, Steven 
Schveighoffer wrote:


Without more context, I would say no. assumeSafeAppend is an 
assumption, and therefore unsafe. If you don't know what is 
passed in, you could potentially clobber data.


In addition, assumeSafeAppend is a non-inlineable, runtime 
function that can *potentially* be low-performing.


Yeah I know that I want to overwrite the data, but still that's 
probably a lot of calls to assumeSafeAppend. So I agree.


instance, you call it on a non-GC array, or one that is not 
marked for appending, you will most certainly need to take the 
GC lock and search through the heap for your block.




What does marked for appending mean. How does it happen or how is 
it marked?


The best place to call assumeSafeAppend is when you are sure 
the array has "shrunk" and you are about to append. If you have 
not shrunk the array, then the call is a waste, if you are not 
sure what the array contains, then you are potentially stomping 
on referenced data.


So assumeSafeAppend is only useful when I have array whose length 
is set to lower than it was originally and I want to grow it back 
(that is arr.length += 1 or arr ~= 1).




An array uses a block marked for appending, assumeSafeAppend 
simply sets how much data is assumed to be valid. Calling 
assumeSafeAppend on a block not marked for appending will do 
nothing except burn CPU cycles.


So yours is not an accurate description.


Related to my question above.
How do you get a block not marked for appending? a view slice?

Perhaps I should re-read the slice article. I believe it had 
something like capacity == 0 --> always allocates. Is it this?




A.3) If A.2 is true, are there any conditions that it reverts 
to

original behavior? (e.g. if I take a new slice of that array)


Any time data is appended, all references *besides* the one 
that was used to append now will reallocate on appending. Any 
time data is shrunk (i.e. arr = arr[0..$-1]), that reference 
now will reallocate on appending.




Thanks. IMO this is very concise description of allocation 
behavior.

I'll use this as a guide.

So when to call really sort of requires understanding what the 
runtime does. Note it is always safe to just never use 
assumeSafeAppend, it is an optimization. You can always append 
to anything (even non-GC array slices) and it will work 
properly.


Out of curiosity. How does this work? Does it always just 
reallocate with gc if it's allocated with something else?




This is an easy call then:

array.reserve(100); // reserve 100 elements for appending
array ~= data; // automatically manages array length for you, 
if length exceeds 100, just automatically reallocates more data.

array.length = 0; // clear all the data
array.assumeSafeAppend; // NOW is the best time to call, 
because you can't shrink it any more, and you know you will be 
appending again.
array ~= data; // no reallocation, unless previous max size was 
exceeded.




Thanks. This will probably cover 90% of cases.
Usually I just want to avoid throwing away memory that I already 
have.

Which is slow if it's all over your codebase.
Like re-reading or recomputing variables that you already have.
One doesn't hurt but a hundred does.

B.1) I have a temporary AA whose lifetime is limited to a 
known span
(might be a function or a loop with couple functions). Is 
there way to

tell the runtime to immeditially destroy and free the AA?


There isn't. This reminds me, I have a lingering PR to add 
aa.clear which destroys all the elements, but was waiting until 
object.clear had been removed for the right amount of time. 
Perhaps it's time to revive that.


Should array have clear() as well?
Basically wrap array.length = 0; array.assumeSafeAppend();
At least it would then be symmetric (and more intuitive) with 
built-in containers.




-Steve

Re: Builtin array and AA efficiency questions

[Random D user via Digitalmars-d-learn]

Thanks for thorough answer.

On Thursday, 15 October 2015 at 18:46:22 UTC, H. S. Teoh wrote:


It adjusts the size of the allocated block in the GC so that 
subsequent appends will not reallocate.




So how does capacity affect this? I mean what is exactly a GC 
block here.


Shrink to fit bit was confusing, but after thinking about this 
few mins I guess there's like at least three concepts:


slice  0 .. length
allocation 0 .. max used/init size (end of 'gc block', also 
shared between slices)
raw mem block  0 .. capacity (or whatever gc set aside (like 
pages))


slice is managed by slice instance (ptr, length pair)
allocation is managed by array runtime (max used by some array)
raw mem block is managed by gc (knows the actual mem block)

So if slice.length != allocation.length then slice is not an mem 
"owning" array (it's a reference).
And assumeSafeAppend sets allocation.length to slice.length i.e. 
shrinks to fit. (slice.length > allocation.length not possible, 
because allocation.length = max(slice.length), so it always just 
shrinks)
Now that slice is a mem "owning" array it owns length growing 
length happens without reallocation until it hits raw mem 
block.length (aka capacity).


So basically the largest slice owns the memory allocation and 
it's length.


This is my understanding now. Although, I'll probably forget all 
this in 5..4..3..2...


The thought that occurs to me is that you could still use the 
built-in arrays as a base for your Buffer type, but with 
various operators overridden so that it doesn't reallocate 
unnecessarily.


Right, so custom array/buffer type it is. Seems the simplest 
solution.
I already started implementing this. Reusable arrays are 
everywhere.


If you want to manually delete data, you probably want to 
implement your own AA based on malloc/free instead of the GC. 
The nature of GC doesn't lend it well to manual management.


I'll have to do this as well. Although, this one isn't that 
critical for me.


The only thing I can think of is to implement this manually, 
e.g., by wrapping your AA in a type that keeps a size_t 
"generation counter", where if any value in the AA is found to 
belong to a generation that's already past, it pretends that 
the value doesn't exist yet.  Something like this:


Right. Like a handle system or AA of ValueHandles in this case. 
But I'll probably just hack up some custom map and reuse it's 
mem. Although, I'm mostly doing this for perf (realloc) and not 
mem size, so it might be too much effort if D AA is highly 
optimized.

Builtin array and AA efficiency questions

[Random D user via Digitalmars-d-learn]

So I was doing some optimizations and I came up with couple basic 
questions...


A)
What does assumeSafeAppend actually do?
A.1) Should I call it always if before setting length if I want 
to have assumeSafeAppend semantics? (e.g. I don't know if it's 
called just before the function I'm in)
A.2) Or does it mark the array/slice itself as a "safe append" 
array? And I can call it once.
A.3) If A.2 is true, are there any conditions that it reverts to 
original behavior? (e.g. if I take a new slice of that array)


I read the array/slice article, but is seems that I still can't 
use them with confidece that it actually does what I want. I 
tried also look into lifetime.d, but there's so many potential 
entry/exit/branch paths that without case by case debugging (and 
no debug symbols for phobos.lib) it's bit too much.


What I'm trying to do is a reused buffer which only grows in 
capacity (and I want to overwrite all data). Preferably I'd 
manage the current active size of the buffer as array.length.


For a buffer typical pattern is:
array.length = 100
...
array.length = 0
...
some appends
...
array.length = 50
...
etc.

There's just so much magic going behind d arrays that it's a bit 
cumbersome to track manually what's actually happening. When it 
allocates and when it doesn't.
So, I already started doing my own Buffer type which gives me 
explicit control, but I wonder if there's a better way.


B.1) I have a temporary AA whose lifetime is limited to a known 
span (might be a function or a loop with couple functions). Is 
there way to tell the runtime to immeditially destroy and free 
the AA?


I'd like to assist the gc with manually destroying some AAs that 
I know I don't need anymore. I don't really want to get rid of 
gc, I just don't want to just batch it into some big batch of gc 
cycle work, since I know right then and there that I'm done with 
it.


For arrays you can do:
int[] arr;
arr.length = 100;
delete arr; // I assume this frees it

but for AAs:
int[string] aa;
delete aa; // gives compiler error  Error: cannot delete type 
int[string]


I could do aa.destroy(), but that just leaves it to gc according 
to docs.


Maybe I should start writing my own hashmap type as well?

B.2) Is there a simple way to reuse the memory/object of the AA?

I could just reuse a preallocated temp AA instead of 
alloc/freeing it.

Re: Tried release build got ICE, does anyone have a clue what might cause this?

[Random D user via Digitalmars-d-learn]

On Saturday, 19 September 2015 at 07:25:58 UTC, ponce wrote:
On Friday, 18 September 2015 at 22:54:43 UTC, Random D user 
wrote:
So I tried to build my project in release for the first time 
in a long while. It takes like 25x longer to compile and 
finally the compiler crashes. It seems to go away if I disable 
the optimizer.

I get:

tym = x1d
Internal error: backend\cgxmm.c 547

Does anyone have a clue what might trigger this?
I'm asking because my project has grown a bit and I don't 
really have any good way of isolating this.


I'm using dmd 2.068.1 and msvc x64 target.


As a backend ICE is is very important that you report this.

To workaround, try disabling inlining or -O selectively.


Thanks for the tips. I guess I should register an account (which 
I hate (already too many one off accounts)), since I already have 
like 3 bugs gathering dust in the corner.

Just hit another one (this time in debug):

Assertion failure: 'type->ty != Tstruct || ((TypeStruct 
*)type)->sym == this' on line 957 in file 'struct.c'


Ugh...
It really seems like D starts to break down once your code grows 
beyond toy program size. A bit frustrating...

Re: Tried release build got ICE, does anyone have a clue what might cause this?

[Random D user via Digitalmars-d-learn]

On Saturday, 19 September 2015 at 21:48:25 UTC, Random D user 
wrote:
Assertion failure: 'type->ty != Tstruct || ((TypeStruct 
*)type)->sym == this' on line 957 in file 'struct.c'


Ok managed to reduce this one to my own copy paste bug. This is 
invalid code, but compiler shouldn't crash...


I'm posting this here for reference (I will file a bug later):

class Gui
{
enum MouseButton { Left = 0, Right };

private:

struct ClickPair
{
MouseButton button = MouseButton.Left;
};

struct ClickPair  // Second struct ClickPair with the enum 
above --> Assertion failure: 'type->ty != Tstruct || 
((TypeStruct*)type)->sym == this' on line 957 in file 'struct.c'

{
MouseButton button = MouseButton.Left;
};
};

Tried release build got ICE, does anyone have a clue what might cause this?

[Random D user via Digitalmars-d-learn]

So I tried to build my project in release for the first time in a 
long while. It takes like 25x longer to compile and finally the 
compiler crashes. It seems to go away if I disable the optimizer.

I get:

tym = x1d
Internal error: backend\cgxmm.c 547

Does anyone have a clue what might trigger this?
I'm asking because my project has grown a bit and I don't really 
have any good way of isolating this.


I'm using dmd 2.068.1 and msvc x64 target.

Another, is it a bug?

[Random D user via Digitalmars-d-learn]

I'm trying to make a base class with get property and a sub class 
with corresponding set property. The value for the base class is 
set via constructor.
The intuitive way doesn't seem to work and workarounds are 
unnecessarily ugly (considering you'll sprinkle them all over the 
codebase).


class Father
{
int eat()
{
return 1;
}
}

class Daughter : Father
{

void eat( int apples ) {}

// int eat() { return super.eat(); }// Workaround A, 
works as expected
//override int eat( int apples ) {} // Workaround D, 
fails -> Error: function main.Daughter.eat does not override any 
function, did you mean to override 'main.Father.eat'?

}

Daughter d = new Daughter();

// BUG? I expected this to work. It seems that compiler doesn't 
even look into parent class to see if there's a matching function.
//int num = d.eat();// Error: function 
main.Daughter.eat (int apples) is not callable using argument 
types ()


int num2 = (cast(Father)d).eat();   // Workaround B, works as 
expected

int num3 = d.Father.eat();  // Workaround C, works as well

Re: Another, is it a bug?

[Random D user via Digitalmars-d-learn]

On Wednesday, 16 September 2015 at 03:17:05 UTC, Meta wrote:
Considering Father defines the function `int eat()` and 
Daughter defines the completely different function `int 
eat(int)`, it doesn't surprise me. You're not using virtual 
dispatch when you do `return super.eat` or `d.Father.eat()`, 
you're delegating the method call to the base class.


Yeah... I guess I was expecting it to overload across class 
boundaries. I mean there's already a member eat in base class and 
sub class can't override that since it's got different 
parameters, and it's a function (can't be variable), so the 
reasonable thing would be to overload it (which is why I tried 
override to see if it forces/hints overriding/overloading).
Instead it creates two ambiguous names of which only one has to 
be disambiguated to use which seems super error prone. IMO it 
should just be error/warning.


Given that, normally properties are just overloaded methods in D, 
it's pretty sad classes break this behavior/convention.

Re: Another, is it a bug?

[Random D user via Digitalmars-d-learn]

On Wednesday, 16 September 2015 at 03:54:34 UTC, Adam D. Ruppe 
wrote:

On Wednesday, 16 September 2015 at 03:48:59 UTC, Random D user
Given that, normally properties are just overloaded methods in 
D, it's pretty sad classes break this behavior/convention.


The D behavior for overloading is different in general:

http://dlang.org/hijack.html

It basically never overloads across scopes. You need to alias 
the name into the scope too explicitly


Thanks. That pretty much answers directly to all my questions. I 
tried to look for this info in class docs/reference, but couldn't 
find it (obviously). I never thought that this would be in 
"articles".

Re: I guess this is a bug?

[Random D user via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 18:28:02 UTC, Random D user 
wrote:

or is it some obscure feature conflict?

[...]


Oh... and I'm using win 64-bit and dmd 2.068.1, but this behavior 
was present earlier than that...

I guess this is a bug?

[Random D user via Digitalmars-d-learn]

or is it some obscure feature conflict?

struct Foo
{
this( float x_, float y_ )
{
// option A
//x = x_;
//y = y_;

// option B
v[0] = x_;
v[1] = y_;
}

union
{
struct
{
float x = 0;
float y = 0;
}
float[2] v;
}
}

struct Bar
{
Foo foo = Foo( 1, 2 );
}

Bar bar;
Bar baz = bar.init;

printf( "bar: %f, %f\n", bar.foo.x, bar.foo.y );
printf( "baz: %f, %f\n", baz.foo.x, baz.foo.y );
-
prints (with option B):
bar: 0.00, 0.00   // BUG??
baz: 1.00, 2.00

prints (with option A):
bar: 1.00, 2.00
baz: 1.00, 2.00
-
Luckily the option A works as I expected and is good enough for 
me...

Re: dmd codegen improvements

[Casual D user via Digitalmars-d]

On Friday, 28 August 2015 at 21:59:57 UTC, Walter Bright wrote:

On 8/28/2015 4:18 AM, Temtaime wrote:

Are you sure that ONE Walter can achieve what they done ?


People told me I couldn't write a C compiler, then told me I 
couldn't write a C++ compiler. I'm still the only person who 
has ever implemented a complete C++ compiler (C++98). Then they 
all (100%) laughed at me for starting D, saying nobody would 
ever use it.


My whole career is built on stepping over people who told me I 
couldn't do anything and wouldn't amount to anything.


LLVM is a fine compiler, but there's nothing magical about it.

Besides, we have a secret productivity enhancing weapon that 
LLVM doesn't have - D!


Now, if I can only tear myself away from the internet for a 
while...


The problem is that you're pretty much the face of D along with 
Andrei. Andrei announcing he was quitting Facebook to work on D 
fulltime was one of the most popular articles on Reddit's 
programming subreddit in the past month.



Someone picks up D, and realizes that out of the box it has a 
full stop the world 1960s-style garbage collector completely 
wrapped in a mutex, can't inline constructors/destructors, 
basically non-functioning RTTI, no safe way to manage resources, 
a type system with massive holes in it, type qualifiers being 
suggestions, the non-proprietary compilers that generate faster 
code lag a year+ behind. Even more than this, D has no real IDE 
integration like C++ or Java, and none is even being worked on as 
far as I'm aware. D is advertised as a system's language, but 
most of the built-in language features require the GC so you 
might as well just use C if you can't use the GC. There's other 
things I can't remember right now.


Then they come to the forums and see the head people of D working 
on ... DMD codegen improvements. That inspires a lot of 
confidence that these issues will get fixed beyond fixing them 
yourself - because that's what everyone adopting a new language 
wants to do.


Do you know what the most complaints about D in the reddit thread 
were? D's incredibly old garbage collector, a complete lack of a 
good IDE, and a lack of good manual memory management utilities.


I'm not blaming you, I'm just not sure if you're aware of what 
this looks like. If you intend for D to be a hobby project, then 
continue on.

Re: What have you done with UDAs?

[Random D-user via Digitalmars-d]

On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote:
I never seem to use them for anything, has anyone else done 
anything interesting with them?


What a cool thread.
This is very valuable info for new(ish) d users.

It's often the case for language features that they are just 
branded cool. But that's just a statement (and you go 'uhm, 
ok.'). What people usually need is some kind of proof or 
demonstration why they are useful and how to solve problems with 
them (which you can usually only get through experience).


Wouldn't it be great if there was a wiki page of cool d-features 
where each feature would have a list like this showcasing what 
people have done with it?


You could then just point people to this wiki page to get a 
practical view of why d is great.

Re: Breaking changes in Visual C++ 2015

[d user via Digitalmars-d]

On Wednesday, 6 May 2015 at 18:26:27 UTC, Brad Anderson wrote:

https://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.140).aspx

I'm sharing this specifically so we can have an unproductive 
flamewar about whether breaking changes in D are sometimes 
worth it or if they are holding D back from mass adoption :).


the truth is, one of the biggest things holding D back from mass 
adoption is the complete lack of tooling compared to  basically 
every other mainstream language.


Compare D to Go,
https://golang.org/cmd/go/

Go comes with a package manager, a linter, a static analysis 
tool, a formatter. Does D have these in some form? Sure. But you 
have to go hunting for them, and they're OK at best.


And really, the only thing to blame for this is dmd. Go provides 
a Go parser and tokenizer right in their standard library - just 
one of the benefits of their compiler being written in Go.


A lot of D's issues come back to: dmd is long in the tooth. 
Things D used to tout(faster compiler times) aren't really there 
anymore. My _desktop_ has a 8 core CPU - which dmd uses a whole 1 
of when compiling. Due to how modules are compiled, it's _slower_ 
to do separate object compilation like in C++, so it's impossible 
to even get a gain from parallel compilation.


Then you have LDC and GDC which generally lag behind dmd by a 
version or two(usually moreso for GDC,) fragmenting the libraries 
heavily because many new D versions fix tons of bugs. Due to 
dmd's license, it can't even be redistributed on Linux, BSD, etc. 
So now you have compilers for major Linux distros that are 
lagging versions behind. And really, the packages aren't well 
maintained anyways - LDC got blacklisted from Ubuntu for being 
unmaintained.


If there's anything to learn from Go's success, it's that you 
don't need a good language design to be successful. If you want D 
to be successful, submit some PRs to SDC. If you want D to stay 
unpopular, keep moving towards Haskell with braces.

Re: DMD compilation speed

[Random D-user via Digitalmars-d]

I've used D's GC with DDMD.  It works*, but you're trading 
better memory usage for worse allocation speed.  It's quite 
possible we could add a switch to ddmd to enable the GC.


As a random d-user (who cares about perf/speed and just happened 
to read this) a switch sounds VERY good to me. I don't want to 
pay the price of GC because of some low-end machines. Memory is 
really cheap these days and pretty much every machine is 64-bits 
(even phones are trasitioning fast to 64-bits).


Also, I wanted to add that freeing (at least to the OS (does this 
apply to GC?)) isn't exactly free either. Infact it can be more 
costly than mallocing.
Here's enlightening article: 
https://randomascii.wordpress.com/2014/12/10/hidden-costs-of-memory-allocation/

Re: Window creation, for phobos?

[user via Digitalmars-d]

I don't know, you sound like a perfectionist to me, like most of 
other community members. I can only give examples from my 
experience.


I am a controls engineer in my current day job, and I do SW 
coding in my free time (like couple of hours per week). In the 
past, I changed my D GUI libs from old-DWT -- DFL -- GTKD -- 
new DWT for obvious reasons. I cannot afford to keep doing that. 
Finally I gave up and picked python-TKinter and Java-swing. I 
know they will always work and they still keep working without 
any changes even after several update cycles.


My tools were such a hit that half the company (~ 0.5 * 2000 
people) is using them now, which is nice. Had I written them in 
D, that would have been a nice advertisement for D.


Note that I don't care that the GUI lib has to be awesome or 
perfect. It just have to work, even if it is ugly like tkinter.


I think I understand the reasons for this philosophy of lean, 
mean and efficient std libs, they will help D compete with other 
heavily financially backed languages, but I guess the same 
philosophy is also hurting people like me. Maybe in another 10 
years we will get a super efficient gui-lib in phobos, if at all, 
most likely we wont.


May be next time I will try to experiment once again with the 
gui-libs in dub.


- D user

Re: Window creation, for phobos?

[user via Digitalmars-d]

On Wednesday, 28 January 2015 at 12:02:25 UTC, Dicebot wrote:

GUI does not belong to Phobos.


That's the only reason I use Java instead of D. If GUI is not in 
phobos, it has no guaranteed support. Of course this is because I 
only create GUI desktop application.


Apparently this is only my issue, all others seems to be ok with 
no GUI in phobos.

Re: Dgui Will be continue?

[user via Digitalmars-d]

don't use crap - use

http://forum.dlang.org/thread/ovgoajvboltrtciqf...@forum.dlang.org

it is great. works for 64bit!!



On Wednesday, 17 December 2014 at 12:26:48 UTC, Gary Willoughby 
wrote:

On Wednesday, 17 December 2014 at 10:35:25 UTC, FrankLike wrote:

Dgui is very good,but what status is about now?


FrankLike please stop asking about DGui's status here, it's 
very annoying.


http://forum.dlang.org/thread/llevng$2pdm$1...@digitalmars.com?page=3#post-fizbqpdqhcpdrzftubsg:40forum.dlang.org
http://forum.dlang.org/thread/llevng$2pdm$1...@digitalmars.com?page=3#post-pterdvszyjumzkkdells:40forum.dlang.org
http://forum.dlang.org/thread/llevng$2pdm$1...@digitalmars.com?page=3#post-ijokafwolgjuriglosya:40forum.dlang.org
http://forum.dlang.org/thread/mhwrwanwhdzpkxllr...@forum.dlang.org?page=2#post-wnarnobzcmyqldzqfmqh:40forum.dlang.org

You can see for yourself the status *at any time* by visiting 
this URL: https://bitbucket.org/dgui/dgui/ There you can speak 
to the developer as much as you wish.

Re: What are the worst parts of D?

[user via Digitalmars-d]

On Wednesday, 24 September 2014 at 06:28:21 UTC, Manu via
Digitalmars-d wrote:

On 20 September 2014 22:39, Tofu Ninja via Digitalmars-d
digitalmars-d@puremagic.com wrote:
There was a recent video[1] by Jonathan Blow about what he 
would want in a
programming language designed specifically for game 
development. Go, Rust,
and D were mentioned and his reason for not wanting to use D 
is is that it
is too much like C++ although he does not really go into it 
much and it
was a very small part of the video it still brings up some 
questions.


What I am curious is what are the worst parts of D? What sort 
of things
would be done differently if we could start over or if we were 
designing a
D3? I am not asking to try and bash D but because it is 
helpful to know

what's bad as well as good.

I will start off...
GC by default is a big sore point that everyone brings up
is expressions are pretty wonky
Libraries could definitely be split up better

What do you think are the worst parts of D?

[1] https://www.youtube.com/watch?v=TH9VCN6UkyQ


Personally, after years of use, my focus on things that really 
annoy

me has shifted away from problems with the language, and firmly
towards basic practicality and productivity concerns.
I'm for addressing things that bother the hell out of me every 
single
day. I should by all reason be more productive in D, but after 
6 years
of experience, I find I definitely remain less productive, 
thanks

mostly to tooling and infrastructure.

1. Constant rejection of improvements because OMG breaking 
change!.
Meanwhile, D has been breaking my code on practically every 
release
for years. I don't get this, reject changes that are 
deliberately
breaking changes which would make significant improvements, but 
allow
breaking changes anyway because they are bug fixes? If the 
release
breaks code, then accept that fact and make some real proper 
breaking
changes that make D substantially better! It is my opinion that 
D
adopters don't adopt D because it's perfect just how it is and 
they
don't want it to improve with time, they adopt D *because they 
want it
to improve with time*! That implies an acceptance (even a 
welcoming)

of breaking changes.

2. Tooling is still insufficient. I use Visual Studio, and while
VisualD is good, it's not great. Like almost all tooling 
projects,
there is only one contributor, and I think this trend presents 
huge
friction to adoption. Tooling is always factored outside of the 
D
community and their perceived realm of responsibility. I'd like 
to see
tooling taken into the core community and issues/bugs treated 
just as

seriously as issues in the compiler/language itself.

3. Debugging is barely ever considered important. I'd love to 
see a
concerted focus on making the debug experience excellent. Iain 
had a
go at GDB, I understand there is great improvement there. 
Sadly, we
recently lost the developer of Mago (a Windows debugger). 
There's lots

of work we could do here, and I think it's of gigantic impact.

4. 'ref' drives me absolutely insane. It seems so trivial, but 
6 years
later, I still can't pass an rvalue-ref (been discussed 
endlessly),
create a ref local, and the separation from the type system 
makes it a
nightmare in generic code. This was a nuisance for me on day-1, 
and
has been grinding me down endlessly for years. It has now far 
eclipsed

my grudges with the GC/RC, or literally anything else about the
language on account of frequency of occurrence; almost daily.



i couldn't agree more. i would like to add, that coming from D1's
clean and nice syntax - D2 becomes a syntactic monster, that is
highly irritating and hard to get used to. its littered with @
like a scripting language. that really sucks!

Re: RFC: std.json sucessor

[Entusiastic user via Digitalmars-d]

I tried using -disable-linker-strip-dead, but it had no effect. 
From the error messages it seems the problem is compile-time and 
not link-time...




On Tuesday, 26 August 2014 at 07:01:09 UTC, Jacob Carlborg wrote:

On 25/08/14 21:49, simendsjo wrote:

So ldc can remove quite a substantial amount of code in some 
cases.


It's because the latest release of LDC has the --gc-sections 
falg enabled by default.

Re: RFC: std.json sucessor

[Entusiastic user via Digitalmars-d]

Hi!

Thanks for the effort you've put in this.

I am having problems with building with LDC 0.14.0. DMD 2.066.0
seems to work fine (all unit tests pass). Do you have any ideas
why?

I am using Ubuntu 3.10 (Linux 3.11.0-15-generic x86_64).

Master was at 6a9f8e62e456c3601fe8ff2e1fbb640f38793d08.
$ dub fetch std_data_json --version=~master
$ cd std_data_json-master/
$ dub test --compiler=ldc2

Generating test runner configuration '__test__library__' for
'library' (library).
Building std_data_json ~master configuration __test__library__,
build type unittest.
Running ldc2...
source/stdx/data/json/parser.d(77): Error: safe function
'stdx.data.json.parser.__unittestL68_22' cannot call system
function 'object.AssociativeArray!(string,
JSONValue).AssociativeArray.length'
source/stdx/data/json/parser.d(124): Error: safe function
'stdx.data.json.parser.__unittestL116_24' cannot call system
function 'object.AssociativeArray!(string,
JSONValue).AssociativeArray.length'
source/stdx/data/json/parser.d(341): Error: function
stdx.data.json.parser.JSONParserRange!(JSONLexerRange!string).JSONParserRange.opAssign
is not callable because it is annotated with @disable
source/stdx/data/json/parser.d(341): Error: safe function
'stdx.data.json.parser.__unittestL318_32' cannot call system
function
'stdx.data.json.parser.JSONParserRange!(JSONLexerRange!string).JSONParserRange.opAssign'
source/stdx/data/json/parser.d(633): Error: function
stdx.data.json.lexer.JSONToken.opAssign is not callable because
it is annotated with @disable
source/stdx/data/json/parser.d(633): Error:
'stdx.data.json.lexer.JSONToken.opAssign' is not nothrow
source/stdx/data/json/parser.d(630): Error: function
'stdx.data.json.parser.JSONParserNode.literal' is nothrow yet may
throw
FAIL
.dub/build/__test__library__-unittest-linux.posix-x86_64-ldc2-0F620B217010475A5A4E545A57CDD09A/
__test__library__ executable
Error executing command test: ldc2 failed with exit code 1.

Thanks

Re: RFC: std.json sucessor

[Entusiastic user via Digitalmars-d]

...
I am using Ubuntu 3.10 (Linux 3.11.0-15-generic x86_64).
...


I meant Ubuntu 13.10 :D

Re: D 2.066 is out. Enjoy!

[disapointed user via Digitalmars-d-announce]

thank you general for your selfish and user considered release.
the lieutenants probably feel kind of really taken care of - as 
well as D users.

how do you test and release at facebook.
i am a user that considers to leave after many years. i am 
starting to dislike the language, as it is getting blown up and 
the the syntax getting ever weirder, less mainstream and a 
support for windows that really sucks.


good luck in the future for all you guys



On Tuesday, 19 August 2014 at 22:27:28 UTC, Andrei Alexandrescu 
wrote:

On 8/19/14, 3:09 PM, Dicebot wrote:
On Tuesday, 19 August 2014 at 21:13:53 UTC, Andrei 
Alexandrescu wrote:
Walter, now that release is out can you please state your 
opinion about
https://github.com/D-Programming-Language/dmd/pull/3651 ? It 
is blocking

Phobos module split and decoupling.


LGTM. Any opposition to merging? -- Andrei


Walter seems to be the only one :)
http://forum.dlang.org/post/lt00a9$2uoe$1...@digitalmars.com


I think it would be great to motivate the change properly. -- 
Andrei

Re: D 2.066 is out. Enjoy!

[disapointed user via Digitalmars-d-announce]

too bad that i wasted my time for such a long time. i post a link 
to that thread with your answer to everywhere i can, so that 
others won't waste their time too.


anyway good luck in the future for you linux guys.



On Wednesday, 20 August 2014 at 09:37:24 UTC, ketmar via 
Digitalmars-d-announce wrote:

On Wed, 20 Aug 2014 09:15:53 +
disapointed user via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:


support for windows that really sucks.

that is 'cause windows really sucks.


good luck in the future for all you guys

you too.