Re: Problem with BP's

[Rainer Schuetze via Digitalmars-d-debugger]

On 20.08.2017 20:26, Johnson Jones wrote:

On Friday, 18 August 2017 at 06:43:37 UTC, Rainer Schuetze wrote:



On 18.08.2017 00:41, Johnson Jones wrote:

I was doing something strange ;/

I had code like

mixin(import("Myfile.d"));
CallSomeFunctionInMyFile();

And no BP's could be hit in side the function call. D would say that 
there was an error in the symbols for the project.




debugging mixins is not really supported by the compiler. It generates 
source filenames that don't exist.


Yes, but in this case, it does exist! Which is why I'm saying it might 
be a useful feature!


mixin(import(filename))

is essentially a direct insertion of filename in to the D source.

Even though it internally goes through the mixin analysis of the code, 
it passes right through.


So, If VisualD knew that, it could just link up filename in to the 
source and allow debugging of it.


If dmd outputted all string mixins to files, then the same logic would 
apply.


e.g.,

it would rewrite

mixin("Hello World");

to

mixin(import(temp342.d));

and temp342.d would contain "Hello World".

Or it could just create a special module for it then import that 
directly like below, which would probably allow it to nearly work with 
Visual D. Visual D would just then have to know what is going on so it 
could dive in to the "sub-file".



What I'm getting at is that it seems like very little work would have to 
be done to get string mixins to be debuggable... instead of trying to 
write some specialized mixin debugger. Dmd and Visual D already do all 
the heavy lifting, they just need to communicate with each other enough 
to make it happen.




There have been a couple of implementations of this, e.g. 
https://github.com/dlang/dmd/pull/426 and the patch in 
https://issues.dlang.org/show_bug.cgi?id=5051, but didn't get merged.

Re: dmd download record

[Joakim via Digitalmars-d]

On Monday, 21 August 2017 at 04:39:11 UTC, TooHuman wrote:

On Friday, 18 August 2017 at 12:59:07 UTC, Joakim wrote:
Downloads from dlang.org, which doesn't include outside distro 
packages like Arch or FreeBSD, have now jumped an order of 
magnitude over the last five years:


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

Congrats to all those who kept their head down grinding away 
on code, including the enlightening technical debates in this 
forum, as opposed to all the armchair strategists opining 
"What D really needs is..." but not submitting any pull 
requests (I partake in such strategizing too, but I have also 
contributed PRs to further the mobile effort, for example).


Ldc has seen similar gains, look at the increased downloads 
over the last two years:


http://www.somsubhra.com/github-release-stats/?username=ldc-developers=ldc

Here's to the next order of magnitude jump!


Would I be right in guessing that the huge spike earlier in the 
month/July was Netflix's announcement of using D for their NN 
library? If so this is a big indication of how important even 
the smallest amount of publicity can be.


No, the spike took off in June/July, but Netflix didn't announce 
till the beginning of August.  If anything, that library 
announcement coincided with the current dip back down, now that 
the chart was just updated.


I'm guessing people were just trying D out during their summer 
break, maybe driven by all the posts on the D blog that have 
gotten some attention.

Re: dmd download record

[TooHuman via Digitalmars-d]

On Friday, 18 August 2017 at 12:59:07 UTC, Joakim wrote:
Downloads from dlang.org, which doesn't include outside distro 
packages like Arch or FreeBSD, have now jumped an order of 
magnitude over the last five years:


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

Congrats to all those who kept their head down grinding away on 
code, including the enlightening technical debates in this 
forum, as opposed to all the armchair strategists opining "What 
D really needs is..." but not submitting any pull requests (I 
partake in such strategizing too, but I have also contributed 
PRs to further the mobile effort, for example).


Ldc has seen similar gains, look at the increased downloads 
over the last two years:


http://www.somsubhra.com/github-release-stats/?username=ldc-developers=ldc

Here's to the next order of magnitude jump!


Would I be right in guessing that the huge spike earlier in the 
month/July was Netflix's announcement of using D for their NN 
library? If so this is a big indication of how important even the 
smallest amount of publicity can be.

function cannot access frame

[Johnson Jones via Digitalmars-d-learn]

cannot access frame of function

I declared a helper function outside a lambda that is passed to C.

The semantics are the same inside of the function as they are 
outside as far as code goes.


How can I declare a function that essentially works inside the 
lambda also without having to do any real rewriting?


e.g., if I could use a define

#define foo(a,b) a + b


would work great, that is all I really need, templates have the 
same issue as functions though.


To make it work I used a mixin template, but that seems a bit 
obtuse ;/


e.g.,

template put()
{
int foo(a,b) { return a + b; }
}

mixin put;


then I mixin it inside the lambda also. That way I have both 
contexts covered, not bad but...

Re: cv2pdb: cannot add symbols to module, probably msobj140.dll missing

[Johnson via Digitalmars-d-debugger]

On Monday, 21 August 2017 at 03:18:38 UTC, Johnson wrote:
All of a sudden I'm getting this error. All I did was comment 
out a huge block of code so I could check something. The code 
compiles but the pdb conversion gives me that error ;/


Uncommenting out the code allows it to work again. I can't see 
why the code I'm commenting out would give that error ;/


Deleting the code also produces the same result.

It seems to be in use with GTK and event handlers. The handlers 
are completely isolated yet are somehow causing the problem.


You won't believe this, I'm sure, but

//Dialog.addOnDestroy((Widget w) {  });

causes the error! Must be some serious bug! Uncommenting allows 
the code to build fine.


I tried restarting visual D with no luck ;/


This just started happening too and a few hours ago I upgraded 
VS, so maybe the msobj140.dll changed and broke cv2pdb?  I copied 
it to the cv2pdb dir so it should have no trouble finding it. 
I've also cleaned the dir. It seems it's doing it on about 
everything I change. Going to reboot to see if that helps.

cv2pdb: cannot add symbols to module, probably msobj140.dll missing

[Johnson via Digitalmars-d-debugger]

All of a sudden I'm getting this error. All I did was comment out 
a huge block of code so I could check something. The code 
compiles but the pdb conversion gives me that error ;/


Uncommenting out the code allows it to work again. I can't see 
why the code I'm commenting out would give that error ;/


Deleting the code also produces the same result.

It seems to be in use with GTK and event handlers. The handlers 
are completely isolated yet are somehow causing the problem.


You won't believe this, I'm sure, but

//Dialog.addOnDestroy((Widget w) {  });

causes the error! Must be some serious bug! Uncommenting allows 
the code to build fine.


I tried restarting visual D with no luck ;/

Re: DerelictGL3 reload crashes in 32 builds

[Mike Parker via Digitalmars-d-learn]

On Sunday, 20 August 2017 at 19:29:55 UTC, Igor wrote:
In 64 bit builds it works with both LDC and DMD but in 32 bit 
LDC version crashes and DMD release version crashes. Using LDC 
debug build I managed to find that it crashes after executing 
ret instruction from bindGLFunc in glloader. If someone wants 
to try it you can do it with this project: 
https://github.com/igor84/dngin. I was testing this from Visual 
Studio but dub 32 bit LDC build also crashed.


Am I doing something wrong or is this some known DerelictGL3 or 
compiler issue?


This is a known issue [1] that I'm currently trying to resolve. I 
hadn't yet tested it using free functions (the bug report uses 
context types), so this new information helps.


[1] https://github.com/DerelictOrg/DerelictGL3/issues/56

Re: std.range.put vs R.put: Best practices?

[Mike Parker via Digitalmars-d-learn]

On Sunday, 20 August 2017 at 18:08:27 UTC, Jon Degenhardt wrote:
Documentation for std.range.put 
(https://dlang.org/phobos/std_range_primitives.html#.put) has 
the intriguing line:


put should not be used "UFCS-style", e.g. r.put(e). Doing this 
may call R.put directly, by-passing any transformation feature 
provided by Range.put. put(r, e) is prefered.


This raises the question of whether std.range.put is always 
preferred over calling an output range's 'put' method, or if 
there are times when calling an output range's 'put' method 
directly is preferred. Also, it seems an easy oversight to 
unintentionally call the wrong one.


Does anyone have recommendations or best practice suggestions 
for which form to use and when?


--Jon


It's recommended to always use the utility function in std.range 
unless you are working with an output range that has a well known 
put implementation. The issue is that put can be implemented to 
take any number or type of arguments, but as long as it has an 
implementation with one parameter of the range's element type, 
then the utility function will do the right thing internally 
whether you pass multiple elements, a single element, an array... 
It's particularly useful in generic code where most ranges are 
used. But again, if you are working with a specific range type 
then you can do as you like. Also, when the output range is a 
dynamic array, UFCS with the utility function is fine.


As for mitigating the risk of calling the wrong one, when you do 
so you'll either get a compile-time error because of a parameter 
mismatch or it will do the right thing. If there's another likely 
outcome, I'm unaware of it.

Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?

[crimaniak via Digitalmars-d-learn]

On Monday, 21 August 2017 at 02:17:57 UTC, crimaniak wrote:
...

shared A a;

...
 Sorry, accidental delete, read this as shared A a = new 
shared(A);

Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?

[crimaniak via Digitalmars-d-learn]

On Monday, 14 August 2017 at 03:59:48 UTC, Jonathan M Davis wrote:

And no, this isn't ideal, but the only semi-decent solution 
that's been proposed that safely casts away shared for you is 
synchronized classes, which Andrei describes in TDPL but have 
never been implemented.
 After reading this I did some experiment to understand the 
situation better. I make a simple class and unittest:


// dmd sync1.d -unittest -main

unittest
{
import std.stdio;

synchronized
class A
{
private int a;

void inc()
{
++a;
}

int get(){ return a;}
}

shared A a;

for(int i=0; i<100; ++i)
a.inc();

writeln(a.get); 

}

Oops! Deprecation: read-modify-write operations are not allowed 
for shared variables. Use core.atomic.atomicOp!"+="(this.a, 1) 
instead.


Why use atomic operations if the class already synchronized? 
Well..


...
   import core.atomic: atomicOp;
...
	// ++a; // Deprecation: read-modify-write operations are not 
allowed for shared variables. Use 
core.atomic.atomicOp!"+="(this.a, 1) instead.

atomicOp!"+="(this.a, 1);
...

ok, works. But it works by the way as if synchronized just makes 
all methods shared, but does not provide the object methods with 
a mutex lock, as Java does. Am I right here? And what preventing 
to implement it right, lack of manpower or some ideologic 
problems?

std.format expand "%s"

[jmh530 via Digitalmars-d-learn]

I'm playing around with std.format and I'm trying to figure out 
if there is any way to identify what "%s" should expand to.


So for instance:
int x = 1;
auto result = x.format!"%s";

I would know that result="1". I could run "1" through 
unformatValue and get back 1. I'm looking to see if there is a 
way to get back "%d": really a function would be like f(x, "%s") 
produces "%d".


Is there anything like that in std.format?

Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?

[crimaniak via Digitalmars-d-learn]

On Thursday, 17 August 2017 at 13:09:29 UTC, Kagamin wrote:

On Wednesday, 16 August 2017 at 23:15:10 UTC, crimaniak wrote:
I wonder if it possible and usable to make some template to 
support this pattern, where we give mutex(es), shared 
object(s) and delegate to operate with objects as non-shared.


https://dpaste.dzfl.pl/8b3b05c8ec0a like this? Not sure if it 
helps, don't forget that it's a casted shared object.
 Yes, something like this. In general, I thought about the 
possibility of using several shared objects in this block but 
then realized that everything can be reduced to the case of one 
object.

GtkD: New widget

[Johnson Jones via Digitalmars-d-learn]

Hey Mike, I bet you can answer this!

I'd like to extend a widget to add some functionality.

class MyBox : Box
{
protected GtkBox* gtkBox;

import std.typecons;
_gtk.Box Wrapped;
mixin Proxy!Wrapped;

public this(Box b)
{
this.gtkBox = b.getBoxStruct();
super(gtkBox, false);
}

}

Trying something like the above does extend the box, as far as 
allowing one to replace it, I think(using the code);


auto b = new MyBox(W1);
auto p = W1.getParent();
auto c = cast(Box)W4;
c.remove(W1);
c.add(b);

So, W4 is the main boxx, W1 is the box inside the main box I 
replaced with the new box b.


When running that code, nothing changes, which, assuming we are 
actually using the new box, then that is fine.


But I'm pretty sure that gtk never has a clue about `MyBox`? I 
say this because I'd like to simply modify the reported sizes of 
the box.


A gtkBox is not the same as a gtk.Box.

It seems like the best I can do is use a gtk.Container and 
inherit from that.



e.g.,

class FixableSizedBox : Container
{
protected GtkContainer* gtkContainer;

import std.typecons;
_gtk.Container Wrapped;
mixin Proxy!Wrapped;

public this(Container b)
{
this.gtkContainer = b.getContainerStruct();
super(gtkContainer, false);
}

}

But even the GtkD container doesn't seem to contain any code to 
deal with handling the sizes.



All I'm really looking to do is set the size of a container to 
whatever I want.

Re: @safe(bool)

[Danni Coy via Digitalmars-d]

> For instance, as it stands, it's relatively easy to figure out whether
> @safe
> has been explicitly applied. You can look on the function and look for
> @safe: or @safe {} which affects it. The same goes for other attributes.
> But
> as soon as you can do stuff like create new attributes that combine
> attributes, you lose that completely. Suddenly. you have to worry about
> whatever attributes someone came up on their own for their project which
> apply @safe or final or @nogc or whatever. You can no longer search or grep
> for an attribute like @safe to see whether it applies.
>
>
you can still search or grep but it's now a two step process. when you grep
the @safe attribute you will find the custom attribute declaration.
you then search for the custom declaration. You need to do the first step
exactly once for each codebase (unless you forget).

It's more diffucult but only a little bit.

Re: GtkD: Build script

[Johnson Jones via Digitalmars-d-learn]

On Sunday, 20 August 2017 at 20:13:17 UTC, Mike Wey wrote:

On 20-08-17 20:41, Johnson Jones wrote:

I guess I see why now you did what you did! ;)

.LIB pagesize exceeds 512

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

Wanna take bets on how many *years* this takes to get fixed?!?


That one happens when GtkD is build with debug symbols.

The main library is build by package because optlink or omf 
doesn't support more that 32767 symbols in one object file, and 
i hit that limit.


;/

After all, who will ever need more than 32767 symbols?

Is this a problem with the linker or the object format? Maybe 
both oplink and dmd could be upgraded to use an extended omf 
format that allows more symbols?

Re: Mixed up over mixins.

[Johnson Jones via Digitalmars-d-learn]

On Sunday, 20 August 2017 at 19:27:43 UTC, WhatMeWorry wrote:


It's stuff like this which makes me very frustrated. Or 
depressed because it demonstrates just how poor a programmer I 
am:



string printStatement(string message) {
return `writeln("` ~ message ~ `");`;
}

void main()
{
// Mixins are for mixing in generated code into the source 
code.

// The mixed in code may be generated as a template instance
// or a string.

mixin(printStatement("hello world"));
mixin(`writeln(` ~ `Hello`  ~ `);` );
mixin("writeln(`World`);");   
}

Compiling gives me the errors:

Error: undefined identifier Hello

To me, `writeln(` ~ `Hello`  ~ `);` is a valid D string? Okay, 
maybe a

string expression but a string nevertheless.

So, am I giving mixin more magical powers than it possesses?

Should we say that mixin needs to be given a "fully pre-formed 
D compilable" string?


Thanks. especially to let me vent.



It's not difficult, it's just new. It's not that you are a poor 
programmer, but you simply have not learned how to think about 
mixins correctly. Stop whining about it and focus that energy on 
working with them.


String mixins are very simple. It takes any string and inserts it 
as code in to the program directly as if you typed it by hand.


What makes them useful is that you can build strings a compile 
time and so essentially introduce compile time code generation.


e.g.,

L324: mixin("Hello World")

becomes

L324: Hello World

and so

mixin(N)

gets inserted as

N, as if you typed it in directly. (this is the important part. N 
isn't inserted but the contents of N as a string.


What this is good for, is say you want to generate code based off 
stuff at compile time, e.g., a configuration file. You can 
generate valid D code using strings that load the configuration 
file at compile time and do what you want with it.


e.g.,

enum config = import(myconfigfile);

config now contains, as a string, the contents of myconfigfile AT 
COMPILE TIME. Normally we think of config as being a run time 
variable, but it is simply a compile time variable(well, it can't 
vary, unfortunately, the compile time processing is not a fully 
integrated compile time compiler.


enum configCode = process(config);

let process be a function that takes config, extracts the data 
from it and bundles it all up in new D code.


mixin(configCode);

Now mixes in that code direct in to the source as if we typed it.

e.g.,

enum classes = import("classNames");
string code;
foreach(n; classes.split(","))
   code ~= "class "~n~";\n";
// at this point code should be something like "class X;\nclass 
Y;" etc, but it depends on the file.

mixin(code);

has the same effect if we typed

class X;
class Y;

But the difference is that we used a file to extract the class 
names and a string mixin that inserted the code. This way we 
don't have to manually change the class names in our D file, we 
just change the classNames file, which is probably autogenerated 
anyways.


String mixins come in very handy when you have D code that can be 
"generalized" (parameterized).


It's sort of the place holder concept: You have a D string like
"
if (alpha_1 > 0) { Alpha1(); }
if (alpha_2 > 0) { Alpha2();}
if (alpha_3 > 0) { Alpha3();}
if (alpha_4 > 0) { Alpha4();}
"
...

Obviously if you can simplify all that code it would be nice, 
well you can!


for(int i = 0; i < N; i++)
mixin("if (alpha_"~i~" > 0) { Alpha"~i~"();}");


this will mix N of those lines with the proper mapping. I only 
have to make one change rather than N.


You have to think of them as D code generators. Of course, you 
don't have to use them to generate code, but they are insert, 
foremost, in D code and will be interpreted by the D compiler.


mixin("string X = \"mixin string X = \""mixin string X = 
\"""mixin string X = .);


is the same as

string X = \"mixin string X = \""mixin string X = \"""mixin 
string X = .;


and, if we used enums(compile time object) instead of strings(run 
time object), we could do


mixin(X); and it would mix in the next layer, which would redfine 
X each time.


It's not difficult, just requires a different way to think about 
them, as does anything that is unfamiliar.

[Issue 17767] Dmd can't link recast.d, Gdc can't compile it and Ldc can perfectly compile it.

[via Digitalmars-d-bugs]

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

--- Comment #2 from ecstatic.coder  ---
Indeed...

I've downloaded the version on gdcproject.org, but same result... 

$ ./gdc --version

gdc (gdcproject.org 20161225-v2.068.2_gcc6) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ ./gdc -m64 recast.d

recast.d:1:0: internal compiler error: in get_symbol_decl, at d/d-decls.cc:136
 /*

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

And couldn't install gdc via your PPA, it says there is not support for
Xenial...

--

Re: Fix D's segfaults!

[user1234 via Digitalmars-d]

On Sunday, 20 August 2017 at 20:20:30 UTC, Jonathan M Davis wrote:
On Sunday, August 20, 2017 12:35:45 Ali Çehreli via 
Digitalmars-d wrote:

On 08/20/2017 12:14 PM, Johnson Jones wrote:
 >>> Dmd needs to be modified so that errors try to show from 
the source
 >>> code. This should be obvious the reasons, if it is not 
possible, make
 >>> it possible! There are no excuses why dmd should make me 
go on an

 >>> easter egg hunt when a seg fault occurs.

You can open an enhancement request at

   https://issues.dlang.org/enter_bug.cgi


[...]
But in spite of the lack of line numbers
[...]


The lack of line number is simply caused by phobos as a static 
library which is build without the -g switch. The only i see way 
to solve this is to


1/ ship dmd with an additional libphobos2-debug.{a|lib}
2/ change the compiler so that when the -g switch is passed, it 
links against the version that has the "-debug" suffix.


This or another trick that would have the same effect.

ATM we have to build the phobos-debug ourselves if we want to see 
the line nums.

Trial v0.3.1 is out

[Szabo Bogdan via Digitalmars-d-announce]

Hi,

I added some new improvements to `trial` 
http://trial.szabobogdan.com/ which is a hackable test runner for 
D.


This release contains:

- Support for `trial` configuration, that allows you to use 
custom dependencies for the test build

- Improved command line interface
- Spec test discovery
- Test Class test discovery with experimental support for data 
providers

- Configurable glyphs for all reporters
- HTML Code Coverage 
http://trial.szabobogdan.com/artifacts/coverage/html/index.html

- XUnit reporter
- Better fluent-asserts integration


Any feedback is appreciated.

Thanks,
Bogdan

Re: Fix D's segfaults!

[Jonathan M Davis via Digitalmars-d]

On Sunday, August 20, 2017 12:35:45 Ali Çehreli via Digitalmars-d wrote:
> On 08/20/2017 12:14 PM, Johnson Jones wrote:
>  >>> Dmd needs to be modified so that errors try to show from the source
>  >>> code. This should be obvious the reasons, if it is not possible, make
>  >>> it possible! There are no excuses why dmd should make me go on an
>  >>> easter egg hunt when a seg fault occurs.
>
> You can open an enhancement request at
>
>https://issues.dlang.org/enter_bug.cgi
>
> I don't know how well it works with D but what I used to do with C++ was
> to put a break point at Exception constructor, which would give me the
> useful stack to go back to my own code.

With the stacktrace, he should be able to know where in his code the problem
is right now. But he doesn't seem to have any debug information whatsoever,
so his stack trace is useless. If I run the program

module test;

import std.file;

void main()
{
rename("does_not_exist_1", "does_not_exist_2");
}

on my system (which is FreeBSD), I get

std.file.FileException@std/file.d(763): does_not_exist_2: No such file or 
directory

??:? @trusted bool std.file.cenforce!(bool).cenforce(bool, const(char)[], 
const(char)*, immutable(char)[], ulong) [0x476c26]
??:? @trusted void std.file.renameImpl(const(char)[], const(char)[], 
const(char)*, const(char)*) [0x4759e6]
??:? @safe void std.file.rename!(immutable(char)[], immutable(char)
[]).rename(immutable(char)[], immutable(char)[]) [0x470304]
??:? _Dmain [0x470202]

which is much better but still not where it should be. The line numbers are
missing, and for some reason, the module name isn't on _Dmain. However, if I
do

module test;

import std.file;

void main()
{
foo();
}

void foo()
{
rename("does_not_exist_1", "does_not_exist_2");
}

then I get

std.file.FileException@std/file.d(763): does_not_exist_2: No such file or 
directory

??:? @trusted bool std.file.cenforce!(bool).cenforce(bool, const(char)[], 
const(char)*, immutable(char)[], ulong) [0x476c66]
??:? @trusted void std.file.renameImpl(const(char)[], const(char)[], 
const(char)*, const(char)*) [0x475a26]
??:? @safe void std.file.rename!(immutable(char)[], immutable(char)
[]).rename(immutable(char)[], immutable(char)[]) [0x470344]
??:? void test.foo() [0x470242]
??:? _Dmain [0x47020c]

which _does_ have the module name on the function that main calls. So, the
lack of module name must be a quirk of _Dmain - probably tied to the fact
that there's only supposed to be one. But the line numbers are still
missing, which they really shouldn't be. I know that that's been a problem
in the past on *nix systems, but I'd thought that it had been fixed. So, I
don't know what the problem is. Regardless, I think that it should
definitely be considered a bug if the line numbers don't show up.

But in spite of the lack of line numbers, what I have here is way better
than what the OP sees. So, he's doing something differently, but I don't
know what. But based on what I'm seeing, it should be possible for the OP to
get a much better stack trace right now. It's just a question of figuring
out what he's doing differently that causes his stack traces to show up with
just addresses.

- Jonathan M Davis

Re: GtkD: Build script

[Mike Wey via Digitalmars-d-learn]

On 20-08-17 20:41, Johnson Jones wrote:

I guess I see why now you did what you did! ;)

.LIB pagesize exceeds 512

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

Wanna take bets on how many *years* this takes to get fixed?!?


That one happens when GtkD is build with debug symbols.

The main library is build by package because optlink or omf doesn't 
support more that 32767 symbols in one object file, and i hit that limit.


--
Mike Wey

Re: Mixed up over mixins.

[Ali Çehreli via Digitalmars-d-learn]

On 08/20/2017 12:27 PM, WhatMeWorry wrote:

> // Mixins are for mixing in generated code into the source code.
> // The mixed in code may be generated as a template instance
> // or a string.

Yes, it means that the string must be legal D code.

> mixin(`writeln(` ~ `Hello`  ~ `);` );

Yes, that's a D string but the string itself is not legal D code because 
it would be mixing in the following:


writeln(Hello);

The problem is, there is no Hello defined in the program.

You need to make sure that Hello is a string itself:

writeln("Hello");

So, you need to use the following mixin:

mixin(`writeln(` ~ `"Hello"`  ~ `);` );

Ali

[Issue 17767] Dmd can't link recast.d, Gdc can't compile it and Ldc can perfectly compile it.

[via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org

--- Comment #1 from Iain Buclaw  ---
(In reply to ecstatic.coder from comment #0)
> Created attachment 1655 [details]
> 
> $ gdc --version
> 
> gdc (Ubuntu 5.4.1-2ubuntu1~16.04) 5.4.1 20160904
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> $ gdc -m64 recast.d
> 
> recast.d:1:0: internal compiler error: in toSymbol, at d/d-decls.cc:75
>  /*
>  ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> 


That function doesn't exist anymore, or even that file.  Care to try a newer
version?

--

Re: Fix D's segfaults!

[Ali Çehreli via Digitalmars-d]

On 08/20/2017 12:14 PM, Johnson Jones wrote:

>>> Dmd needs to be modified so that errors try to show from the source
>>> code. This should be obvious the reasons, if it is not possible, make
>>> it possible! There are no excuses why dmd should make me go on an
>>> easter egg hunt when a seg fault occurs.

You can open an enhancement request at

  https://issues.dlang.org/enter_bug.cgi

I don't know how well it works with D but what I used to do with C++ was 
to put a break point at Exception constructor, which would give me the 
useful stack to go back to my own code.


Ali

Re: Fix D's segfaults!

[Bastiaan Veelo via Digitalmars-d]

On Sunday, 20 August 2017 at 19:14:10 UTC, Johnson Jones wrote:
Dne 20. 8. 2017 8:06 odpoledne napsal uživatel "Johnson Jones 
via Digitalmars-d" :


D has a major issue with segfaults! It always reports the 
fault in the lowest function that it occurs! This is 
completely useless!


std.file.FileException@std\file.d(755): Attempting to rename 
file X.lib to Y.lib: The system cannot find the file 
specified.


0x0041015E
0x00402C69
0x004025A3
0x00413ECF
0x00413E93
0x00413D94
0x0040DAD7
0x76D78744 in BaseThreadInitThunk
0x76FD582D in RtlGetAppContainerNamedObjectPath
0x76FD57FD in RtlGetAppContainerNamedObjectPath



[..]

This should be quite easy with a stacktrace, simply walk back 
until the location is in user code.


You are looking at the stack trace. The reason you don't see line 
numbers is probably that you did not compile with debugging 
information on?

Mixed up over mixins.

[WhatMeWorry via Digitalmars-d-learn]

It's stuff like this which makes me very frustrated. Or depressed 
because it demonstrates just how poor a programmer I am:



string printStatement(string message) {
return `writeln("` ~ message ~ `");`;
}

void main()
{
// Mixins are for mixing in generated code into the source 
code.

// The mixed in code may be generated as a template instance
// or a string.

mixin(printStatement("hello world"));
mixin(`writeln(` ~ `Hello`  ~ `);` );
mixin("writeln(`World`);");   
}

Compiling gives me the errors:

Error: undefined identifier Hello

To me, `writeln(` ~ `Hello`  ~ `);` is a valid D string? Okay, 
maybe a

string expression but a string nevertheless.

So, am I giving mixin more magical powers than it possesses?

Should we say that mixin needs to be given a "fully pre-formed D 
compilable" string?


Thanks. especially to let me vent.

DerelictGL3 reload crashes in 32 builds

[Igor via Digitalmars-d-learn]

In 64 bit builds it works with both LDC and DMD but in 32 bit LDC 
version crashes and DMD release version crashes. Using LDC debug 
build I managed to find that it crashes after executing ret 
instruction from bindGLFunc in glloader. If someone wants to try 
it you can do it with this project: 
https://github.com/igor84/dngin. I was testing this from Visual 
Studio but dub 32 bit LDC build also crashed.


Am I doing something wrong or is this some known DerelictGL3 or 
compiler issue?

Re: Fix D's segfaults!

[Johnson Jones via Digitalmars-d]

On Sunday, 20 August 2017 at 18:35:07 UTC, Daniel Kozak wrote:
This is not segfault.  This is an uncatched exception.  So it 
is your error. You does not do proper error handling. But still 
IIRC you should be able to see place where things go wrong


Dne 20. 8. 2017 8:06 odpoledne napsal uživatel "Johnson Jones 
via Digitalmars-d" :


D has a major issue with segfaults! It always reports the 
fault in the lowest function that it occurs! This is 
completely useless!


std.file.FileException@std\file.d(755): Attempting to rename 
file X.lib to Y.lib: The system cannot find the file specified.


0x0041015E
0x00402C69
0x004025A3
0x00413ECF
0x00413E93
0x00413D94
0x0040DAD7
0x76D78744 in BaseThreadInitThunk
0x76FD582D in RtlGetAppContainerNamedObjectPath
0x76FD57FD in RtlGetAppContainerNamedObjectPath

This tells me nothing about where the error occurred in *my* 
program!


Dmd needs to be modified so that errors try to show from the 
source code. This should be obvious the reasons, if it is not 
possible, make it possible! There are no excuses why dmd 
should make me go on an easter egg hunt when a seg fault 
occurs.


Um,

That was just an example, the same type of output occurs with 
segfaults or any error/crash that D outputs stuff trying to be 
"helpful".


Anyways, your missing the point. You expect me to write 
try/catches in every level of my program to create the 
granularity one needs to simply get the location the error 
occured in? Where is that exactly?


How hard is it for dmd to know if 
std.file.FileException@std\file.d occurs in the code I created or 
somewhere else? It should be able to say "Hey, that is part of a 
standard library or other non-user component, let me try to walk 
back a little and see if I can find a location in the user code 
that led to this problem".


This should be quite easy with a stacktrace, simply walk back 
until the location is in user code.


So, regardless of anything, D telling me stuff like "Hey, your 
error occurred in phobos" doesn't tell me shit except the error 
occurred in phobos. I'm still looking for easter eggs, and I 
don't like easter(which is why I don't capitalize it).

Re: GtkD: Build script

[Johnson Jones via Digitalmars-d-learn]

I guess I see why now you did what you did! ;)

.LIB pagesize exceeds 512

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

Wanna take bets on how many *years* this takes to get fixed?!?

Re: Debugging Visual D using Visual D

[Johnson Jones via Digitalmars-d-debugger]

I should state though, that I could be wrong(and haven't tested 
it out yet).  It's possible that some of the caching "features" 
screwed up what I think is going on. But the typical thing that 
got stuff to work was deleting the visual D entries in the 
registry(of course, it broke mago also). So, I'm not 100%. It may 
be no keys that are needed to be removed, just a few of them, or 
all of them.

Re: Fix D's segfaults!

[Daniel Kozak via Digitalmars-d]

This is not segfault.  This is an uncatched exception.  So it is your
error. You does not do proper error handling. But still IIRC you should be
able to see place where things go wrong

Dne 20. 8. 2017 8:06 odpoledne napsal uživatel "Johnson Jones via
Digitalmars-d" :

> D has a major issue with segfaults! It always reports the fault in the
> lowest function that it occurs! This is completely useless!
>
> std.file.FileException@std\file.d(755): Attempting to rename file X.lib
> to Y.lib: The system cannot find the file specified.
> 
> 0x0041015E
> 0x00402C69
> 0x004025A3
> 0x00413ECF
> 0x00413E93
> 0x00413D94
> 0x0040DAD7
> 0x76D78744 in BaseThreadInitThunk
> 0x76FD582D in RtlGetAppContainerNamedObjectPath
> 0x76FD57FD in RtlGetAppContainerNamedObjectPath
>
> This tells me nothing about where the error occurred in *my* program!
>
> Dmd needs to be modified so that errors try to show from the source code.
> This should be obvious the reasons, if it is not possible, make it
> possible! There are no excuses why dmd should make me go on an easter egg
> hunt when a seg fault occurs.
>
>

Re: Debugging Visual D using Visual D

[Johnson Jones via Digitalmars-d-debugger]

On Friday, 18 August 2017 at 06:37:44 UTC, Rainer Schuetze wrote:






Glad you figured it out. I had to enable Visual D in the 
extension manager when using the local pkgdef.


Visual D installs for all users, so I think just installing 
into the users AppData is not an option. VS 2017 doesn't seem 
to inspect the "All Users" folders.


The installer is not supposed to write to the system registry 
for VS2017 related components. I see some bad entries for mago 
and two entries for marshalling some data, though, but they 
don't seem to have an impact on extension detection (IIRC they 
are needed during build).


It writes a few clsID's I think. about 2 or 3, let me check...

Computer\HKEY_CLASSES_ROOT\TypeLib\{002a2de9-8bb6-484d-9903-7e4ad4084715}
C:\Program Files (x86)\VisualD\vdserver.tlb


Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{002A2DE9-8BB6-484D-980E-7E4AD4084715}
C:\Program Files (x86)\VisualD\visuald.dll


Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{002a2de9-8bb6-484d-aa05-7e4ad4084715}
C:\Program Files (x86)\VisualD\DParser\DParserCOMServer.exe

Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{97348AC0-2B6B-4B99-A245-4C7E2C09D403}
C:\Program Files (x86)\VisualD\Mago\MagoNatDE.dll

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\MagoDebugger

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VisualD


I also had to reinstall VisualD because for x64 the debugger 
would not run. That probably came from me deleting one of those 
directories(the ones referring to mago I guess).


So, I'm not sure if some of those keys are interfering with 
getting isolation between the VS versions or what, but it seems 
that Visual Studio load the registry version first before the 
extension package and also then caches it. This makes it 
impossible to actually use the isolated visual D even when 
everything is setup right as far as the pkgdef's.

GtkD: Build script

[Johnson Jones via Digitalmars-d-learn]

I've modified the build script:

changed 2 things: 1. Builds for all archs. 2. Replaced the 
specialized x86 build with the generic used for 64-bit. You were 
building for each individual directory for some reason, I guess 
for more granularity, but it produced a different result than the 
64 build because it left out the root gtk dir, when I put some 
package files in to help make it easier to deal with all the 
modules.


It might be better to put the libs in their own unique 
directories. I was just tired of having to build for each version 
so I simplified it. Probably could use some output mentioning 
what is going on, although it works well, so maybe not.


I assume for 2 you just did that for more control? The lib file 
was quite a bit larger(I think it went from 30 megs to 50 or 
something).



Maybe a script such as this could be added and called buildAll.

module Build;

import core.stdc.stdlib: exit;

import std.algorithm;
import std.array;
import std.file;
import std.getopt;
import std.path;
import std.process;
import std.stdio;
import std.string;

string dcflags;
string ldflags;


int main(string[] args)
{
version(Posix)
{
writeln("This build script is currently Windows only.");
return(1);
}

getopt(args, "dcflags", , "ldflags", );
args.popFront();

foreach ( arg; args )
{
		if ( !["gtkd", "gtkdgl", "sv", "gstreamer", "vte", "peas", 
"all"].canFind(arg) )

{
writefln("Unknown option: %s", arg);
return 1;
}
}

if ( args.length == 0 )
args = ["gtkd", "sv"];

if ( args.canFind("all") )
args = ["gtkd", "sv", "gstreamer", "peas"];

foreach ( arg; args )
{
switch ( arg )
{
case "gtkd":  
build("generated\\gtkd", "gtkd");
break;
case "gtkdgl":
build("generated\\gtkdgl", "gtkdgl");
break;
case "sv":
build("generated\\sourceview", "gtkdsv");
break;
case "gstreamer":
build("generated\\gstreamer", "gstreamerd");
break;
case "peas":
build("generated\\peas", "peasd");
break;
default:
assert(false);
break;
}
}

return(0);
}

void build(string dir, string lib)
{
import std.algorithm;
foreach(i; [0,1,2])
switch(i)
{
// 64bit
case 1: 
			std.file.write("build.rf", format("-m64 -c -lib %s %s 
-Igenerated/gtkd -of%sx64.lib %s ", dcflags, ldflags, lib, 
dFiles(dir)));

auto pid = spawnProcess(["dmd", "@build.rf"]);
if ( wait(pid) != 0 ) exit(1);
break;
default: goto case 0;
case 0:
			std.file.write("build.rf", format("-m32 -c -lib %s %s 
-Igenerated/gtkd -of%sx86.lib %s ", dcflags, ldflags, lib, 
dFiles(dir)));

auto pid = spawnProcess(["dmd", "@build.rf"]);
if ( wait(pid) != 0 ) exit(1);

break;  
case 2:
			std.file.write("build.rf", format("-m32mscoff -c -lib %s %s 
-Igenerated/gtkd -of%sx86coff.lib %s", dcflags, ldflags, lib, 
dFiles(dir)));

auto pid = spawnProcess(["dmd", "@build.rf"]);
if ( wait(pid) != 0 ) exit(1);  
break;
}

std.file.remove("build.rf");
}

string dFiles(string sourceDir)
{
string files;
auto entries = dirEntries(sourceDir, SpanMode.breadth);

foreach ( DirEntry entry; entries )
{
if ( entry.isDir == false && entry.name.extension == ".d" )
{
files ~= entry.name ~ " ";
}
}

return files;
}

std.range.put vs R.put: Best practices?

[Jon Degenhardt via Digitalmars-d-learn]

Documentation for std.range.put 
(https://dlang.org/phobos/std_range_primitives.html#.put) has the 
intriguing line:


put should not be used "UFCS-style", e.g. r.put(e). Doing this 
may call R.put directly, by-passing any transformation feature 
provided by Range.put. put(r, e) is prefered.


This raises the question of whether std.range.put is always 
preferred over calling an output range's 'put' method, or if 
there are times when calling an output range's 'put' method 
directly is preferred. Also, it seems an easy oversight to 
unintentionally call the wrong one.


Does anyone have recommendations or best practice suggestions for 
which form to use and when?


--Jon

[Issue 17769] New: dmd accepts conversion from shared(int)* to int* when value comes from method

[via Digitalmars-d-bugs]

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

  Issue ID: 17769
   Summary: dmd accepts conversion from shared(int)* to int* when
value comes from method
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: accepts-invalid
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com


struct S()
{
shared(int)* method() { return ptr; }
shared(int)* ptr;
}

void main()
{
S!() s;
int* foo = s.method(); /* accepted; should be rejected */
}


These variations are correctly rejected:


auto foo = s.method();
int* bar = foo; // rejected as expected
int* baz = s.ptr; // ditto


--

Fix D's segfaults!

[Johnson Jones via Digitalmars-d]

D has a major issue with segfaults! It always reports the fault 
in the lowest function that it occurs! This is completely useless!


std.file.FileException@std\file.d(755): Attempting to rename file 
X.lib to Y.lib: The system cannot find the file specified.


0x0041015E
0x00402C69
0x004025A3
0x00413ECF
0x00413E93
0x00413D94
0x0040DAD7
0x76D78744 in BaseThreadInitThunk
0x76FD582D in RtlGetAppContainerNamedObjectPath
0x76FD57FD in RtlGetAppContainerNamedObjectPath

This tells me nothing about where the error occurred in *my* 
program!


Dmd needs to be modified so that errors try to show from the 
source code. This should be obvious the reasons, if it is not 
possible, make it possible! There are no excuses why dmd should 
make me go on an easter egg hunt when a seg fault occurs.

Re: Estimating free system resource at runtime

[Anonymouse via Digitalmars-d-learn]

On Sunday, 20 August 2017 at 15:49:09 UTC, seany wrote:
However, i cant find anything on google to tell me how to 
estimate system resource using D. for C++ and windowes, i could 
find some API-s


Can e do this in D?


You can just use those C APIs. I believe the GC does, unless I'm 
reading it wrong.


https://github.com/dlang/druntime/blob/acd2c55095ec039be2a9c20a8891ee40e4a393c3/src/gc/os.d#L173-L175
https://github.com/dlang/druntime/blob/acd2c55095ec039be2a9c20a8891ee40e4a393c3/src/core/sys/windows/winbase.d#L1383-L1392

Re: @safe(bool)

[bitwise via Digitalmars-d]

On Sunday, 20 August 2017 at 01:33:00 UTC, Nicholas Wilson wrote:


 I'm not quite sure how this would lead to a loss of modularity?


Not sure if modularity is exactly the right word. The problem 
would be akin to extension methods in C#, or even a useful set of 
UFC's in D.


So, imagine you decide you need DateTime.LastWeek() or something 
similar. This turns out to be something you end up needing in 
most of your projects. So first of all, you're now required to 
start bringing this file into every project you work on. This is 
already annoying. Then, one day, you decide you also need 
DateTime.FortnightAgo(). So you add it to the file, except that 
all the other versions are now out of sync. You think, maybe I 
should have made a repository!? First of all, too late. Second, 
you now have to clone a repo into all your new projects instead 
of dragging and dropping a file, and update the repo every time 
you want to work on the project in case anything changed. At this 
point, any reasonable person would be frustratedbut 
wait...you also need some extensions for Math as well, which are 
not necessarily related to the extensions for DateTime. I suppose 
you could start throwing together your own small support library 
with all of these things in there... But wait...some of the 
extensions are platform specific *facepalm*. So eventually, you 
end up with a chart like this[1] describing which of these libs 
are in each of your projects.



The catch is, that a lot of the time, the things you make are 
these extensions for are so ubiquitous that they should probably 
just be included in the language, or standard library. An easy 
example is the million different variations of C++ "thread", 
"mutex" and "hashtable" that were built while the C++ community 
took a coffee break from 1998 to 2011 ;)


I think I've painted the picture sufficiently at this point.

[1] http://i.imgur.com/cQxxQJs.png

Aedi property reader, a library for reading configuration properties from multiple sources

[Alexandru Ermicioi via Digitalmars-d-announce]

Good day!

Announcing first release of aedi property reader.

Aedi property reader is a config reader, with ability to read 
from xml, json, environment, and command line.


It allows to define a set of default parameters, and extend or 
override them from environment, command line or any other 
configuration file.


Usecases:
- Just for simple config property reading.
- Organizing the config files into a hierarchical structure, with 
ability to override properties from environment or command line.

- Fallback to default config file.

The library can be used as standalone, or together with aedi 
framework.


code.dlang.org: 
http://code.dlang.org/packages/aedi-property-reader
Api documentation: 
https://aermicioi.github.io/aedi-property-reader/
Usage tutorial: 
https://github.com/aermicioi/aedi-property-reader/wiki


Aedi framework: https://github.com/aermicioi/aedi

Cheers!

[Issue 17768] Compile time reflection is missing for module/namespace(c++)/mixin names

[via Digitalmars-d-bugs]

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

Илья Ярошенко  changed:

   What|Removed |Added

   Keywords||C++

--

Estimating free system resource at runtime

[seany via Digitalmars-d-learn]

Hi

I have a system that has to deal with 30+GB files. They can't be 
loaded to the amount of memory I have.


So my idea was to create a way to estimate available system RAM, 
and read a chunk from file which is 1/10 of size of available 
RAM, and process it as far as i can. If the read chunk is too 
small to meaningfully process, then i wait until resources are 
free.  If i read a chunk with some trailing things at the end 
that cant be processed, then i trim it, and reset the seek 
position.


However, i cant find anything on google to tell me how to 
estimate system resource using D. for C++ and windowes, i could 
find some API-s


Can e do this in D?

[Issue 17768] New: Compile time reflection is missing for module/namespace(c++)/mixin names

[via Digitalmars-d-bugs]

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

  Issue ID: 17768
   Summary: Compile time reflection is missing for
module/namespace(c++)/mixin names
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com

Hi,

Could Dlang get something like that please:

__traits(isModule, M)   //for module M;
__traits(isMixinScope, S);  //for mixin Foo S;
__traits(isCppNamespace, N) //for extern(C++, N){}

For module I found ugly and probably not universal workaround:
enum isModule(alias M) = __traits(compiles, { mixin(`import ` ~
fullyQualifiedName!M ~ `;`); });

Current problem is that I need to distinguish С++ namespaces and D mixin
scopes.

(working on automated C++/Cython bindings generator).

Best regards,
Ilya

--

[Issue 17766] Wrong choice of generic mutable/const/immutable methods

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||ag0ae...@gmail.com

--

[Issue 17767] Dmd can't link recast.d, Gdc can't compile it and Ldc can perfectly compile it.

[via Digitalmars-d-bugs]

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

ecstatic.coder  changed:

   What|Removed |Added

Summary|Dmd and Gdc report an   |Dmd can't link recast.d,
   |internal error in the   |Gdc can't compile it and
   |compiler when compiling |Ldc can perfectly compile
   |recast.d, but Ldc can   |it.
   |perfectly compile it.   |

--

[Issue 17767] New: Dmd and Gdc report an internal error in the compiler when compiling recast.d, but Ldc can perfectly compile it.

[via Digitalmars-d-bugs]

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

  Issue ID: 17767
   Summary: Dmd and Gdc report an internal error in the compiler
when compiling recast.d, but Ldc can perfectly compile
it.
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ecstatic.co...@gmail.com

Created attachment 1655
  --> https://issues.dlang.org/attachment.cgi?id=1655=edit
standalone D file which crashes the Dmd and Gdc compilers

Dmd and Gdc report an internal error in the compiler when compiling recast.d,
but Ldc can perfectly compile it.

https://github.com/senselogic/RECAST/blob/master/recast.d

$ dmd --version

DMD64 D Compiler v2.075.1
Copyright (c) 1999-2017 by Digital Mars written by Walter Bright
eric@ENVY17 ~/data/WORK/PROJECT/TOOL/RECAST $ dmd -m64 recast.d
recast.o : Dans la fonction «
_D3std4conv17__T6toImplTAyaTsZ6toImplFNaNbNeskE3std5ascii10LetterCaseZAya » :
recast.d:(.text._D3std4conv17__T6toImplTAyaTsZ6toImplFNaNbNeskE3std5ascii10LetterCaseZAya[_D3std4conv17__T6toImplTAyaTsZ6toImplFNaNbNeskE3std5ascii10LetterCaseZAya]+0x5f)
: référence indéfinie vers «
_D3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6Result
»
recast.o : Dans la fonction «
_D3std5array96__T5arrayTS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZ5arrayFNaNbNfS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZAa
» :
recast.d:(.text._D3std5array96__T5arrayTS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZ5arrayFNaNbNfS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZAa[_D3std5array96__T5arrayTS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZ5arrayFNaNbNfS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZAa]+0xd)
: référence indéfinie vers «
_D3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6Result6lengthMFNaNbNdNiNfZm
»
recast.d:(.text._D3std5array96__T5arrayTS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZ5arrayFNaNbNfS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZAa[_D3std5array96__T5arrayTS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZ5arrayFNaNbNfS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZAa]+0x4f)
: référence indéfinie vers «
_D3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6Result5emptyMFNaNbNdNiNfZb
»
recast.d:(.text._D3std5array96__T5arrayTS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZ5arrayFNaNbNfS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZAa[_D3std5array96__T5arrayTS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZ5arrayFNaNbNfS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZAa]+0x5c)
: référence indéfinie vers «
_D3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6Result5frontMFNaNbNdNiNfZa
»
recast.d:(.text._D3std5array96__T5arrayTS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZ5arrayFNaNbNfS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZAa[_D3std5array96__T5arrayTS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZ5arrayFNaNbNfS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6ResultZAa]+0x9f)
: référence indéfinie vers «
_D3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6Result8popFrontMFNaNbNiNfZv
»
recast.o : Dans la fonction «
_D3std4conv17__T6toImplTAyaTiZ6toImplFNaNbNeikE3std5ascii10LetterCaseZAya » :
recast.d:(.text._D3std4conv17__T6toImplTAyaTiZ6toImplFNaNbNeikE3std5ascii10LetterCaseZAya[_D3std4conv17__T6toImplTAyaTiZ6toImplFNaNbNeikE3std5ascii10LetterCaseZAya]+0x5e)
: référence indéfinie vers «
_D3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TiZ7toCharsFNaNbNiNfiZ6Result
»
recast.o : Dans la fonction «
_D3std4conv17__T6toImplTAyaThZ6toImplFNaNbNehkE3std5ascii10LetterCaseZAya » :
recast.d:(.text._D3std4conv17__T6toImplTAyaThZ6toImplFNaNbNehkE3std5ascii10LetterCaseZAya[_D3std4conv17__T6toImplTAyaThZ6toImplFNaNbNehkE3std5ascii10LetterCaseZAya]+0x60)
: référence indéfinie vers «

Re: Using mixin templates for operator overloading.

[Balagopal Komarath via Digitalmars-d-learn]

On Sunday, 20 August 2017 at 12:46:59 UTC, Nicholas Wilson wrote:
Did you try changing the `: "+"` constraints to `if` 
constraints?


Yes. Yields the same result as this.

[Issue 17762] Cannot compile with clean DMD.

[via Digitalmars-d-bugs]

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

--- Comment #5 from Vincent  ---
(In reply to Rainer Schuetze from comment #4)
> BTW: I don't think there is an infected Visual D installer anywhere

It was long time ago, maybe 2-3 years. But it doesn't eliminate the fact of
infection. Anyway I don't see any reason to discuss viruses, while REAL REQUEST
was about COMPILATION. Rainer, sources are useless if they are not compillable.
If you have time/wish, please update "build from sources" page, so people can
follow instruction and build add-in w/o any stupid issues. Sources itself is
fine, we just need missed packages.

--

Re: Some news from Dplug

[Mike Parker via Digitalmars-d-announce]

On Sunday, 20 August 2017 at 12:55:00 UTC, Guillaume Piolat wrote:

On Saturday, 19 August 2017 at 07:20:06 UTC, Joakim wrote:


Thanks, I also liked his post about D, especially the title:

http://www.modernmetalproduction.com/d-elegant-language-civilized-age/

Mike, want to post the Dplug for Linux post to proggit/HN 
after the weekend?


I've put it in HN right now.
You'll find it in https://news.ycombinator.com/newest


I'll post it to reddit Monday.

Re: Some news from Dplug

[Guillaume Piolat via Digitalmars-d-announce]

On Saturday, 19 August 2017 at 07:20:06 UTC, Joakim wrote:


Thanks, I also liked his post about D, especially the title:

http://www.modernmetalproduction.com/d-elegant-language-civilized-age/

Mike, want to post the Dplug for Linux post to proggit/HN after 
the weekend?


I've put it in HN right now.
You'll find it in https://news.ycombinator.com/newest

Re: Using mixin templates for operator overloading.

[Nicholas Wilson via Digitalmars-d-learn]

On Saturday, 19 August 2017 at 10:16:18 UTC, Balagopal Komarath 
wrote:
Let us say I want to automatically define subtraction given 
that addition and negation are defined. I tried the following 
using mixin templates. If I simply mixin the template using 
"mixin sub;", then it gives the error


[...]


Did you try changing the `: "+"` constraints to `if` constraints?

Re: Using mixin templates for operator overloading.

[Balagopal Komarath via Digitalmars-d-learn]

On Saturday, 19 August 2017 at 10:16:18 UTC, Balagopal Komarath 
wrote:
Let us say I want to automatically define subtraction given 
that addition and negation are defined. I tried the following 
using mixin templates...


I assume there is no way to do this?

Re: dlang-requetst: openssl 1.1 compatible release

[ikod via Digitalmars-d-announce]

On Saturday, 5 August 2017 at 09:46:44 UTC, Jack Applegame wrote:

On Friday, 4 August 2017 at 18:28:23 UTC, ikod wrote:

On Friday, 4 August 2017 at 17:06:16 UTC, Jack Applegame wrote:
Does dlang-requests support binding interface for outgoing 
connection, like curl --interface option?


No, but this can be done. It would be nice if you post issue 
on github.



https://github.com/ikod/dlang-requests/issues/51


Hello,
Thanks for posting issue, 'bind' enabled for outgoing connections 
in v0.5.1 release

[Issue 17761] dmd 2.075.1 creates object files that can't be linked by ld.bfd

[via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

Re: Quora

[Rico Decho via Digitalmars-d]

Two more answers :

https://www.quora.com/How-do-I-get-started-with-programming-What-kind-of-laptop-do-I-need-What-is-the-best-programming-language-for-beginners
https://www.quora.com/Which-should-I-learn-as-my-first-programming-language-C-or-C++

Feel free to vote for my answers if you agree with my advices :)

Re: Quora

[Patrick Schluter via Digitalmars-d]

On Sunday, 20 August 2017 at 08:45:24 UTC, Rico Decho wrote:
So, editing and answering old questions is encouraged on 
stackoverflow and imho it is a good thing, nothing is more 
annoying than googling for a question and only finding answers 
in old mailing lists that apply only to a 
compiler/system/language from the '90s.


I absolutely agree.

We should not be shy to suggest D on old posts where it's 
missing despite it's nowadays a very good alternative to C, 
C++, Python, Ruby, etc.


And D is also a perfect language to teach programming, and that 
information is often missing when googling on the subject.


Indeed and Ali Çehreli's D book is really a nice tutorial even 
for people without format programming experience.




That also must be said on the forums, including on existing 
posts.

Re: Quora

[Rico Decho via Digitalmars-d]

So, editing and answering old questions is encouraged on 
stackoverflow and imho it is a good thing, nothing is more 
annoying than googling for a question and only finding answers 
in old mailing lists that apply only to a 
compiler/system/language from the '90s.


I absolutely agree.

We should not be shy to suggest D on old posts where it's missing 
despite it's nowadays a very good alternative to C, C++, Python, 
Ruby, etc.


And D is also a perfect language to teach programming, and that 
information is often missing when googling on the subject.


That also must be said on the forums, including on existing posts.

Re: Quora

[Patrick Schluter via Digitalmars-d]

On Sunday, 20 August 2017 at 02:44:13 UTC, Jonathan M Davis wrote:
On Saturday, August 19, 2017 15:17:52 Ecstatic Coder via 
Digitalmars-d wrote:

> Its called necro-posting.
> I'm surprised that post isn't read-only.

Call it like you want, but I ee people putting new 
answers/comments to years old posts all the times, as it's 
perfectly legitimate on many blogs and websites.


What was the best answer 10 years ago is often completely 
wrong nowadays.


Forbidding people to suggest what can easily solve the problem 
*right now* is what would be silly IMHO.


IIRC, there's even a badge for necro-posting. I don't think 
that I've ever done it though.


There are at least 2 different badges for old posting answers

Here my track record in C answers
https://stackoverflow.com/users/146377/patrick-schl%c3%bcter?tab=badges
I'm 12 times necromancer i.e. answered a question older than 60 
days with a score higher than 5 and am also an excavator which 
means that I edited a question or an answer in a post that was 
inactive for 6 months.
So, editing and answering old questions is encouraged on 
stackoverflow and imho it is a good thing, nothing is more 
annoying than googling for a question and only finding answers in 
old mailing lists that apply only to a compiler/system/language 
from the '90s.

Re: real simple delegate question.

[angel via Digitalmars-d-learn]

On Saturday, 19 August 2017 at 18:33:37 UTC, WhatMeWorry wrote:

On Friday, 18 August 2017 at 20:39:38 UTC, angel wrote:

On Friday, 18 August 2017 at 02:38:15 UTC, WhatMeForget wrote:

[...]


This actually appears correct ...
The 1-st example:
Each call to makeCalculator() increments a static (i.e. shared 
among all makeCalculator() instances) variable - context.

In addition, makeCalculator() generates a random variable.
Whereas the delegate merely captures these variables, and the 
displayed results reflect this.


The 2-nd example:
There is a single call to makeCalculator().
After this call, context == 1, randy == _apparently 2_.
Now the delegate, as has already been said, merely captures 
these values, so consecutive calls do not change the result.


Thanks. So,
auto calculator = makeCalculator();
is the actual call of the delegate? "Delegate is function 
pointer with context"

But what is
...calculator(0));

Or maybe another approach would be to ask, what type is the 
compiler replacing auto with.


No !
The actual call to the delegate is calculator(0).
But this delegate does not induce change on its context 
variables, so it is expectable that consecutive calls to 
calculator(0) produce the same results, isn't it ?
makeCalculator(), while not a delegate, also has a context 
variable - "static int context" - this is an "old-school" context 
variable implemented by the means of static variable.
Consecutive calls to makeCalculator() return delegates having 
different contexts, so each call to calculator(0) produces 
different results.