Re: lazy evaluation of logical operators in enum definition

[Shachar Shemesh via Digitalmars-d]

On 17/04/18 13:59, Simen Kjærås wrote:

There's a kinda neat (and kinda ugly) way to implement prop in one line:

     enum prop(T) = __traits(compiles, { static assert(T.member == 3); });

Now, that's not the same as short-circuiting, and only useful in some 
cases, but for those cases, it's useful.


Also, extremely dangerous.

Seriously, guys and gals. __traits(compiles) (and its uglier sibling, 
is(typeof())) should be used *extremely* sparingly.


The problem is that just about any use of __traits(compiles) I know of 
is seeking to weed out one particular reason for the compilation 
failure. There is a known bug in D, however, that the compiler 
consistently fails to read the programmer's mind. The compiler only 
knows that the code as provided does not compile, and that in that case 
you asked for something to happen.


The usual outcome is that 80-90% of the times your code does what you 
expect, but then something comes along that throws you off the beaten 
track. In those cases, instead of getting an error message, you get one 
of the sides of the "if", which results in random behavior by your code.


If you're lucky, you will get an error message much further down the 
compilation line, and then start having a fun day of trying to figure 
out what the !*#()%&!@#)!@( just happened. If you're less lucky, the 
code will actually compile.


My personal rule of thumb is this: If there is *any* way of achieving 
the result I want without __traits(compiles), do it that way.


Shachar

[Issue 18774] meta used in .di files causes link errors

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

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

--- Comment #8 from Jonathan M Davis  ---
Well, regardless of what's actually causing the problem, I completely agree
that it should be fixed. However, not being a compiler dev, I have no clue how
likely that is to be quick or easy.

--

[Issue 18774] meta used in .di files causes link errors

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

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

--- Comment #7 from Manu  ---
Orly? Doesn't happen for you? That's even worse.

Just the presence of the declaration shouldn't result in a link error.
You can declare all the undefined functions you like, you don't get link errors
unless there is a reference to them that the linker tries (and can't) resolve.
I don't understand what reference there could possibly be to Zip!().init, even
if it was generated and emit to the symbol table when it was instantiated by
CTFE.

Your hunch that it's emit into some sort of template-instantiation namespace
rather than into a module is probably on the money. It smells like the problem
could be tangled in that complexity... but at the end of the day, I just can't
imagine where the reference is that the linker could be upset about.

Anyway, this was discovered by a colleague at Blizzard who's exploring D. It
would certainly be reassuring if we could fix it promptly.

--

[Issue 18493] [betterC] Can't use aggregated type with postblit

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

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

Mike Franklin  changed:

   What|Removed |Added

   Keywords||pull
 CC||slavo5...@yahoo.com

--- Comment #4 from Mike Franklin  ---
A PR has been submitted to remove generation of the try-catch if the postblit
is `nothrow`:  https://github.com/dlang/dmd/pull/8184

I don't consider this a complete fix to this issue, but if it is accepted, it
will allow one to attribute their postblit with `nothrow` to avoid the error in
-betterC.

I'm pondering a more thorough solution for -betterC, and intend to tackle that
as another PR.

--

[Issue 18774] meta used in .di files causes link errors

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

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

--- Comment #6 from Jonathan M Davis  ---
(In reply to Manu from comment #5)
> I think you've missed my point, there is NO REFERENCE to Zip!().init in
> main.d, at least, there shouldn't be... so why the link error?
> Where is the reference coming from?

You imported test.di. test.di references Zip!().init, and it references it when
creating the function that you're calling from main.d. So, it's being used when
generating main.d even if main.d doesn't use it directly. I'd guess that the
problem relates to that. It's likely inserting the symbol when it imports
test.di. I don't see what else the problem could be. Also, remember that you're
actually generating template instantations with that code. It's not just
referencing existing code like it would with a normal function. Template
instantations don't live with the module that they come from in the same way
that other functions do, because they can't, since they're not compiled with
the module. I'd guess that that's part of the problem and that it results in
the template instantiations being inserted into the resultant binary.

Curiously, if I compile your example on FreeBSD (with clang as the C/C++
compiler, though I think that it's actually using GNU's linker), I only get an
undefined reference for `_D4test9test_funcFiiZv', so it appears that the
problem with Zip may be system-dependent. Maybe one linker ignores it because
it isn't used directly in main.d, and the other doesn't? I don't know.
Certainly, the fact that it appears to differ from system to system doesn't
give me a warm, fuzzy feeling.

--

Re: Delegates and classes for custom code.

[arturg via Digitalmars-d-learn]

On Wednesday, 18 April 2018 at 01:58:40 UTC, arturg wrote:


is it this what you want?

   class A
   {
   int a;
   void delegate() onDraw;

   this(void delegate() dg)
   {
   onDraw = dg;
   }

   void drawText(string s)
   {
   s.writeln;
   }
   }

   void main()
   {
A a;
a = new A((){ a.a = 5; a.drawText("test"); "drawing 
all".writeln; });

}

but if you do A a = new A((){ a.a = 5; ...});
the dg cant capture 'a' yet.
so maybe it would be better to just do:
A a = new A;
a.onDraw = (){ a.drawText("test"); "draw rest".writeln; };


ah i see bauss already wrote the same.

some other aproach could be:

class Base
{
final void draw()
{ drawSelf(); }

abstract void drawSelf();
}

class A : Base
{
override void drawSelf()
{ ... }
}

[Issue 18774] meta used in .di files causes link errors

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

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

--- Comment #5 from Manu  ---
> dmd -m64 main.d

Emits:

  main.obj : error LNK2019: unresolved external symbol _D4test9test_funcFiiZv
referenced in function _Dmain  (expected)
  main.obj : error LNK2001: unresolved external symbol
_D3std5range__T3ZipTAAyaTQfZQn6__initZ(WTF?)


I think you've missed my point, there is NO REFERENCE to Zip!().init in main.d,
at least, there shouldn't be... so why the link error?
Where is the reference coming from?

--

Re: Delegates and classes for custom code.

[arturg via Digitalmars-d-learn]

On Wednesday, 18 April 2018 at 01:12:33 UTC, Chris Katko wrote:

That was all pseudo-code typed by hand.

I got my code to work today. I don't know if it's the prettiest 
it can be, but it works:


// TESTING ACCESS TO the OWNING function
//---
class test_window
{
float x;
float y;

void draw_text(string text)
{
writeln(text);  
}

this( void function(test_window) onDraw  )
{   
this.onDraw = onDraw;
}

void run() //called every frame
{
onDraw(this);
}

void function (test_window) onDraw;
}


void test_dialog()
{
auto t = new test_window(function void(test_window ptr)
{
with(ptr)
{
draw_text( format("Hello, world. [x,y]=[%f,%f]", x, y));
}
});

t.run();
}





And a second attempt/version:





// TESTING ACCESS to anything
// --

struct data_to_access_t
{
int tacos;
}

struct data_to_access2_t
{
struct beans
{
int x;
};

beans b;
}

class abc(T)
{
int x;
void delegate(T) run_delegate;

T data;

this(T t, void delegate(T) d)
{
data = t;
run_delegate = d;
}

void execute()
{
run_delegate(data);
}
}

void test_dialog_anything()
{   
data_to_access_t  d;
data_to_access2_t d2;
d.tacos = 4;
d2.b.x  = 5;

	auto x = new abc!data_to_access_t ( d, (d) => writefln("test  
%d", d.tacos)  );
	auto y = new abc!data_to_access_t ( d, (d){writefln("test  
%d", d.tacos);}  );
	auto z = new abc!data_to_access2_t(d2, delegate void 
(d2){writefln("test2 %d", d2.b.x);}  );


x.execute();
y.execute();
z.execute();
}





My only questions are:

 -  is there any way to make it "smart" enough to take the type 
of the argument, instead of me manually giving it a type.


	auto x = new abc!data_to_access_t ( d, (d) => writefln("test  
%d", d.tacos)  );

becomes
auto x = new abc( d, (d) => writefln("test  %d", d.tacos)  );

 - Is there any way to eliminate the first d? Which is 
essentially a "this" pointer.


	auto x = new abc!data_to_access_t ( d, (d) => writefln("test  
%d", d.tacos)  );

becomes
	auto x = new abc!data_to_access_t ( (d) => writefln("test  
%d", d.tacos)  );


 - And preferably, if possible, both. But I'll take what I can 
get.


is it this what you want?

   class A
   {
   int a;
   void delegate() onDraw;

   this(void delegate() dg)
   {
   onDraw = dg;
   }

   void drawText(string s)
   {
   s.writeln;
   }
   }

   void main()
   {
A a;
a = new A((){ a.a = 5; a.drawText("test"); "drawing 
all".writeln; });

}

but if you do A a = new A((){ a.a = 5; ...});
the dg cant capture 'a' yet.
so maybe it would be better to just do:
A a = new A;
a.onDraw = (){ a.drawText("test"); "draw rest".writeln; };

Re: Delegates and classes for custom code.

[Chris Katko via Digitalmars-d-learn]

That was all pseudo-code typed by hand.

I got my code to work today. I don't know if it's the prettiest 
it can be, but it works:


// TESTING ACCESS TO the OWNING function
//---
class test_window
{
float x;
float y;

void draw_text(string text)
{
writeln(text);  
}

this( void function(test_window) onDraw  )
{   
this.onDraw = onDraw;
}

void run() //called every frame
{
onDraw(this);
}

void function (test_window) onDraw;
}


void test_dialog()
{
auto t = new test_window(function void(test_window ptr)
{
with(ptr)
{
draw_text( format("Hello, world. [x,y]=[%f,%f]", x, y));
}
});

t.run();
}





And a second attempt/version:





// TESTING ACCESS to anything
// --

struct data_to_access_t
{
int tacos;
}

struct data_to_access2_t
{
struct beans
{
int x;
};

beans b;
}

class abc(T)
{
int x;
void delegate(T) run_delegate;

T data;

this(T t, void delegate(T) d)
{
data = t;
run_delegate = d;
}

void execute()
{
run_delegate(data);
}
}

void test_dialog_anything()
{   
data_to_access_t  d;
data_to_access2_t d2;
d.tacos = 4;
d2.b.x  = 5;

	auto x = new abc!data_to_access_t ( d, (d) => writefln("test  
%d", d.tacos)  );
	auto y = new abc!data_to_access_t ( d, (d){writefln("test  %d", 
d.tacos);}  );
	auto z = new abc!data_to_access2_t(d2, delegate void 
(d2){writefln("test2 %d", d2.b.x);}  );


x.execute();
y.execute();
z.execute();
}





My only questions are:

 -  is there any way to make it "smart" enough to take the type 
of the argument, instead of me manually giving it a type.


	auto x = new abc!data_to_access_t ( d, (d) => writefln("test  
%d", d.tacos)  );

becomes
auto x = new abc( d, (d) => writefln("test  %d", d.tacos)  );

 - Is there any way to eliminate the first d? Which is 
essentially a "this" pointer.


	auto x = new abc!data_to_access_t ( d, (d) => writefln("test  
%d", d.tacos)  );

becomes
	auto x = new abc!data_to_access_t ( (d) => writefln("test  %d", 
d.tacos)  );


 - And preferably, if possible, both. But I'll take what I can 
get.

[Issue 18774] meta used in .di files causes link errors

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

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

Jonathan M Davis  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan M Davis  ---
If the .di file is being used, then the code that's importing it would expect
the symbol, but if the object file is then generated from the .d file, the
symbol isn't there, thus I would expect a linker error. AFAIK, the only way
around that would be if the compiler were smart enough to only use the symbol
for as long as necessary to do the CTFE call, because it's only used during
CTFE, and I don't think that it's that smart, much as I think that we can all
agree that we want it to be that smart.

I'd suggest that you provide the actual compilation commands that you're using
so that it's 100% clear how to reproduce what you're doing.

--

[Issue 18774] meta used in .di files causes link errors

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

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

--- Comment #3 from Manu  ---
Well in this case, the symbol is emit in a .di file, which means it's never
written to any object file; hence the unresolved external...

But that's actually kind-of irrelevant. The big question I have here is, where
is the link error coming from?! Why is there a reference in main.obj to
Zip!(...)'s init value? Where could that symbol reference possibly be coming
from? There's no runtime calls to zip().

I don't understand how the link error is even emerging, because there should be
nothing making such a reference.

--

[Issue 18774] meta used in .di files causes link errors

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

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

--- Comment #2 from hst...@quickfur.ath.cx ---
P.S. and the `if (__ctfe)` hack I use only saves on executable size, it doesn't
suppress the symbol itself from appearing in the object file, so it's probably
not good enough for your use case.

--

[Issue 18774] meta used in .di files causes link errors

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

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

--- Comment #1 from hst...@quickfur.ath.cx ---
AIUI, all template functions that are instantiated will end up in the object
file, even if they are only used during CTFE (i.e. the instantiation is
triggered by CTFE but not anywhere else).  This is a problem that's been
bothering me too, which has led me to insert `if (__ctfe)` blocks into my CTFE
functions.  But if you're using Phobos functions, then you're out of luck.

I agree that the compiler should have some way to track whether a particular
template function / instantiation / etc., is only referenced by CTFE code, so
that said functions are omitted from the object file when emitting code. 
Possibly something like a boolean flag in the template symbol to indicate
whether the symbol is referenced by runtime constructs.

I suspect, though, that this is far from trivial to implement, because code
that gets run by CTFE is essentially just one step away from being emitted as
object code, and for all intents and purposes is considered as "runtime" code
by many parts of the compiler.  So you get tricky things like whether a
function called by a CTFE function should be marked as CTFE-only or should be
included in the object file (since that function call would have been resolved
before the CTFE engine even sees it, so it would already have been considered
as "runtime", even if in actuality it will only ever be called from CTFE).

Still, it's a nice-to-have.

--

[Issue 18774] meta used in .di files causes link errors

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

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

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

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

Re: Feature to get or add value to an associative array.

[Giles Bathgate via Digitalmars-d]

On Tuesday, 17 April 2018 at 21:40:55 UTC, Giles Bathgate wrote:

Rust calls its version of this function `or_insert_with` (blegh)


Of course, a rustic API could be built atop this PR:

template entry(K, V)
{
static struct Entry
{
alias get this;
V[K] aa;
K key;
V get()
{
return aa[key];
}
V orInsert()
{
return aa.getOrAdd(key);
}
V orInsertWith(lazy V value = V.init)
{
return aa.getOrAdd(key, value);
}
}

Entry entry(ref V[K] aa, K key)
{
return Entry(aa,key);
}
}


void main()
{
class C{}
C[string] aa;
auto v1 = aa.entry("foo");
auto v2 = aa.entry("bar").orInsert();
auto v3 = aa.entry("baz").orInsertWith(new C);
}

But I think, this would be out of scope.

CTFE in .di files

[Manu via Digitalmars-d]

I've been having some problems like this:
https://issues.dlang.org/show_bug.cgi?id=18774

I have .di files with mixins that generate declarations using CTFE.
Trouble is, executing the CTFE seems to leave residual references to
symbols which result in unresolved link errors in the client of the
.di file.
This seems wrong to me. CTFE shouldn't leave residual dependencies on
runtime symbols... is this a well-known issue? Are there common
workarounds?

I'm surprised I haven't run into this before... I must have just
luckily managed to avoid the specific problem structure.

get literal symbol name without base class/struct as string

[Dr.No via Digitalmars-d-learn]

give structs like this:

struct A
{
int a = 10;
string s = "haha";
}

struct B
{
A aDetails;
}

I'd like to do this and store that symbol name as string (my goal 
is store the member name);


string memberName = magic(B.aDetails.s);
writeln(memberName); // otuput "aDetails.s"

how can I do that?

closet I got was:

template nameof(alias S) {
import std.array : split, join;
import std.traits;
pragma(msg, fullyQualifiedName!S);
pragma(msg, "stringof = " ~ S.stringof);
enum parts = fullyQualifiedName!S.split(".");
enum nameof = parts[1 .. $].join(".");
}


but neither fullyQualifiedName nor stringof give the symbol in 
the way I need.

Re: Feature to get or add value to an associative array.

[Giles Bathgate via Digitalmars-d]

On Tuesday, 17 April 2018 at 20:49:30 UTC, Steven Schveighoffer 
wrote:

Not as straightforward, but it can be done:

bool inserted = false;
auto p = aa.getOrAdd("key", {inserted = true; return new 
Person; });


Yes, I like that approach. I don't want to bloat the feature at 
this stage, although there is nothing stopping adding an overload 
later. I agree returning ref makes sense since we never return 
null. Consequently, I am leaning toward thinking it should be 
called getOrCreate now though.


Rust calls its version of this function `or_insert_with` (blegh)

https://doc.rust-lang.org/std/collections/hash_map/enum.Entry.html#method.or_insert_with

[Issue 18774] New: meta used in .di files causes link errors

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

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

  Issue ID: 18774
   Summary: meta used in .di files causes link errors
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

We produce a function prototype in a .di file using some meta

test.di
---
module test;

template Test()
{
import std.range, std.algorithm;
enum Test = "void test_func(" ~
  zip(["int","int"], ["a","b"])
.map!(tuple => tuple[0] ~ " " ~ tuple[1])
.reduce!((a, b) => a ~ ", " ~ b) ~
");";
}
mixin(Test!()); // <- Mixes in: void test_func(int a, int b);
---


main.d
--
import test;

int main()
{
test_func(1, 2);

return 0;
}
--


I expect compiling this example to result in a single link error to the
unresolved external test_func().
But we also see "error LNK2001: unresolved external symbol
_D3std5range__T3ZipTAAyaTQfZQn6__initZ"

Calling zip() at CTFE results in an additional unexpected link error.
Using a function in CTFE this way shouldn't affect the symbol table, or add any
additional link references.

--

Re: Feature to get or add value to an associative array.

[Steven Schveighoffer via Digitalmars-d]

On 4/17/18 12:18 PM, Nick Treleaven wrote:

On Sunday, 15 April 2018 at 22:52:47 UTC, Giles Bathgate wrote:
The function provides a means to get a value corresponding to the key, 
but if the value doesn't exist it will evaluate the lazy argument to 
create a new value, add this to the associative array and then return it.


auto p = lookup.getOrAdd("giles", new Person);


Thanks for making this pull, I've thought about solving this before. I 
think the function needs to provide a way to tell if the value was 
already present.


Not as straightforward, but it can be done:

bool inserted = false;
auto p = aa.getOrAdd("key", {inserted = true; return new Person; });

Note that most of the time, the only reason you need to know it's new is 
to initialize it. But the lazy parameter takes care of that for you.


I also think it's more ergonomic not to have to use a 
lazy argument, and probably more efficient, so I had in mind:


Value* slot(AA aa, K key, scope bool* inserted = null);


I like the name slot. I'm less enthused about the extra machinery needed 
for initializing the value.


Why do you think it's less efficient to use a lazy parameter?

This pattern needs a pointer to be returned, instead of using `ref`. 
Note that `` is valid in @safe code, but only with -dip1000. I 
called the function `slot` because it always returns the address of the 
slot which the value is stored in.

Returning ref makes more sense to me -- you are never going to return null.

-Steve

Re: (Unofficial) Discord Server!

[bachmeier via Digitalmars-d]

On Tuesday, 17 April 2018 at 06:43:16 UTC, JN wrote:

On Monday, 16 April 2018 at 22:24:18 UTC, Luke Wilson wrote:
Hi there! After having found nearly zero solutions for a D 
community on Discord, having one server be quite inefficient, 
I've made my own. https://discord.gg/crpA2Hn


I hope to bring the community closer by doing this.


I think most of the community is hanging out at the official D 
Irc channel. I prefer ergonomics of Discord/Slack/Gitter over 
IRC, although in the long run I guess IRC is good for the 
openness compared to proprietiary solution.


Gitter is open source:
https://gitlab.com/gitlab-org/gitter/webapp/

I set up Mattermost without any trouble, and if I can do it, it's 
not complicated:

https://docs.mattermost.com/guides/administrator.html

[Issue 18773] New: Constraints on buffer re-use for std.zlib should be documented.

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

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

  Issue ID: 18773
   Summary: Constraints on buffer re-use for std.zlib should be
documented.
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: briancsch...@gmail.com

The Compress and UnCompress classes have undocumented restrictions on when the
buffers passed to their `compress` and `uncompress` methods can be re-used.
This needs to be fixed so that people are not accidentally creating or reading
corrupted data.

--

Re: Feature to get or add value to an associative array.

[Giles Bathgate via Digitalmars-d]

On Tuesday, 17 April 2018 at 19:33:16 UTC, MrSmith wrote:
You may need to perform extra logic when value is inserted in 
the container and something else when value already existed.


Fair enough, I will consider adding this and some tests to the 
PR, a function overload seems like the way to go.

[Issue 18760] theAllocator should hold a reference to the allocator that it uses

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

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

--- Comment #1 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/4126f928270570c9149a6412acde16f16506fd39
Merge pull request #6449 from edi33416/fix_thread_alloc

Fix Issue 18760 - theAllocator dangling reference bug

--

[Issue 18760] theAllocator should hold a reference to the allocator that it uses

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

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

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

   What|Removed |Added

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

--

D's string mixins are like Tcl's uplevel

[Ali Çehreli via Digitalmars-d]

I came across this Tcl advocacy article on Reddit (the article is from 
2006):



https://www.reddit.com/r/programming/comments/8cw63d/tcl_the_misunderstood/

"Everything is a string" concept of Tcl reminded me of how D can 
generate code as string. So, Tcl's 'uplevel' is like string mixins. It's 
also similar to how body of 'static if' is inserted into this context.


Ali

Re: Feature to get or add value to an associative array.

[MrSmith via Digitalmars-d]

On Tuesday, 17 April 2018 at 17:27:02 UTC, Giles Bathgate wrote:
I like the name. I think your version is quite low level which 
ultimately provides more power at the expense of making the 
callee code less clean. I am not sure with D which of those two 
aspects is preferred. Perhaps both functions could be provided? 
What is the use case for knowing whether a value was inserted.


You may need to perform extra logic when value is inserted in the 
container and something else when value already existed.


I have a special version of function for that:
Value* getOrCreate(Key key, out bool wasCreated, Value 
default_value = Value.init)


here is an example of usage: 
https://github.com/MrSmith33/voxelman/blob/master/plugins/voxelman/entity/entityobservermanager.d#L33

[Issue 15574] wrong order of linker arguments

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

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

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

   What|Removed |Added

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

--

[Issue 15574] wrong order of linker arguments

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

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

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

https://github.com/dlang/dmd/commit/fbaeeaee1cac009d9f7157b7d63ea22dee1d3b0e
Fix issue 15574 - wrong order of link arguments

This essentially places *.a arguments before the -l and -L switches in
the linker command line.

This allows to link applications that link against a static archive *.a
that depends on -l lib switches.
Such dependency scheme is typical of the following situation:
  - have a D package that contains binding to a C library.
  - this D package is itself built as a static library (libdpackage.a).
  - the C library is built in the same build process as a static library
(pathtoClib/libclib.a)
  - dmd is invoked in the following way:

  $ dmd ... libdpackage.a -L-LpathtoClib -L-lclib

Currently dmd reorders arguments and places *.a after -l linker switches
which causes link errors if the -l points to a static library.

This is especially useful with Dub, which can be configured to probe for
the C library, and build it as a static lib if not found system-wide.
In both cases, the C library is provided with "libs" json entry.

So this is not about keeping relative order of linker arguments, it is
about providing an order of linker arguments that is more sound than
the current one.

https://github.com/dlang/dmd/commit/10c8fa536879536b4fa339d8325b7a3ab0990d51
add test for issue 15574

https://github.com/dlang/dmd/commit/6371942b1bf26dc6c65cc7e0668bc82e1974c18d
Merge pull request #8172 from rtbo/linker_arg_order

Fix issue 15574 - wrong order of link arguments
merged-on-behalf-of: Razvan Nitu 

--

Re: D IDE Coedit 3.6.7 - now with an integrated terminal emulator.

[ketmar via Digitalmars-d-announce]

Basile B. wrote:

I hadn't announced the 5 or 6 latest releases (3.6.x series) but this one 
comes with an integrated terminal emulator (linux only), a bit like Geany 
does, if you see what i mean.


See https://github.com/BBasile/Coedit/releases for changelog and download 
links.


yay!

D IDE Coedit 3.6.7 - now with an integrated terminal emulator.

[Basile B. via Digitalmars-d-announce]

I hadn't announced the 5 or 6 latest releases (3.6.x series) but 
this one comes with an integrated terminal emulator (linux only), 
a bit like Geany does, if you see what i mean.


See https://github.com/BBasile/Coedit/releases for changelog and 
download links.

Re: Issues with debugging GC-related crashes #2

[Matthias Klumpp via Digitalmars-d]

On Tuesday, 17 April 2018 at 08:23:07 UTC, Kagamin wrote:

Other stuff to try:
1. run application compiled on debian against ubuntu libs
2. can you mix dependencies from debian and ubuntu?


I haven't tried that yet (next on my todo list), if I do run the 
program compiled with address sanitizer on Debian, I do get 
errors like:

```
AddressSanitizer:DEADLYSIGNAL
=
==25964==ERROR: AddressSanitizer: SEGV on unknown address 
0x7fac8db3f800 (pc 0x7fac9c433430 bp 0x0008 sp 
0x7ffc92be3dd0 T0)

==25964==The signal is caused by a READ memory access.
#0 0x7fac9c43342f in 
_D2gc4impl12conservativeQw3Gcx4markMFNbNlPvQcZv 
(/usr/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.78+0xa142f)
#1 0x7fac9c433a2f in 
_D2gc4impl12conservativeQw3Gcx7markAllMFNbbZ14__foreachbody3MFNbKSQCm11gcinterface5RangeZi (/usr/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.78+0xa1a2f)
#2 0x7fac9c459ad4 in 
_D2rt4util9container5treap__T5TreapTS2gc11gcinterface5RangeZQBf13opApplyHelperFNbxPSQDeQDeQDcQCv__TQCsTQCpZQDa4NodeMDFNbKxSQDiQDiQCyZiZi (/usr/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.78+0xc7ad4)
#3 0x7fac9c459ac6 in 
_D2rt4util9container5treap__T5TreapTS2gc11gcinterface5RangeZQBf13opApplyHelperFNbxPSQDeQDeQDcQCv__TQCsTQCpZQDa4NodeMDFNbKxSQDiQDiQCyZiZi (/usr/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.78+0xc7ac6)
#4 0x7fac9c459ac6 in 
_D2rt4util9container5treap__T5TreapTS2gc11gcinterface5RangeZQBf13opApplyHelperFNbxPSQDeQDeQDcQCv__TQCsTQCpZQDa4NodeMDFNbKxSQDiQDiQCyZiZi (/usr/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.78+0xc7ac6)
#5 0x7fac9c459ac6 in 
_D2rt4util9container5treap__T5TreapTS2gc11gcinterface5RangeZQBf13opApplyHelperFNbxPSQDeQDeQDcQCv__TQCsTQCpZQDa4NodeMDFNbKxSQDiQDiQCyZiZi (/usr/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.78+0xc7ac6)
#6 0x7fac9c459a51 in 
_D2rt4util9container5treap__T5TreapTS2gc11gcinterface5RangeZQBf7opApplyMFNbMDFNbKQBtZiZi (/usr/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.78+0xc7a51)
#7 0x7fac9c430f26 in 
_D2gc4impl12conservativeQw3Gcx11fullcollectMFNbbZm 
(/usr/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.78+0x9ef26)
#8 0x7fac9c431226 in 
_D2gc4impl12conservativeQw14ConservativeGC__T9runLockedS_DQCeQCeQCcQCnQBs18fullCollectNoStackMFNbZ2goFNbPSQEaQEaQDyQEj3GcxZmTQvZQDfMFNbKQBgZm (/usr/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.78+0x9f226)
#9 0x7fac9c4355d0 in gc_term 
(/usr/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.78+0xa35d0)
#10 0x7fac9c443ab2 in rt_term 
(/usr/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.78+0xb1ab2)
#11 0x7fac9c443e65 in 
_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv 
(/usr/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.78+0xb1e65)
#12 0x7fac9c443d0b in _d_run_main 
(/usr/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.78+0xb1d0b)
#13 0x7fac9b9cfa86 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x21a86)
#14 0x55acd1dbe1d9 in _start 
(/home/matthias/Development/AppStream/generator/build/src/asgen/appstream-generator+0xba1d9)


AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV 
(/usr/lib/x86_64-linux-gnu/libdruntime-ldc-shared.so.78+0xa142f) 
in _D2gc4impl12conservativeQw3Gcx4markMFNbNlPvQcZv

==25964==ABORTING
```
So, I don't think this bug is actually limited to Ubuntu, it just 
shows up there more often for some reason.

Beta 2.080.0

[Martin Nowak via Digitalmars-d-announce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Glad to announce the first beta for the 2.080.0 release, ♥ to the 65
contributors for this release.

http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.080.0.html

As usual please report any bugs at https://issues.dlang.org

- 

Highlights:

https://dlang.org/changelog/2.080.0.html#fix5227
https://dlang.org/changelog/2.080.0.html#isReturnOnStack
https://dlang.org/changelog/2.080.0.html#objc_class_methods
https://dlang.org/changelog/2.080.0.html#std-typecons-nullable-apply

- -Martin

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlrWNI0ACgkQsnOBFhK7
GTmhoxAAtEX73TOcmKCV5ygM1HaeXPk0M6hhVOsRgQEhwopK/KFrcPme3KYeQ59j
2SICDIAnj662TRZkPRO4cwNOLHGGUwnTqUfu/TjEj90yqB1IU9/CV76J3CbgFF2A
xEPCVsZWBKH3FyJQIut4iKl9ep9aa9SLGd+Zm/cMEWmOsS2ZuE2dlJdGMjKxCGLu
5GeYAk5FBcAQyLmSnpGu3u4A8tIryy5YTCI+p8J5kuaqxhpNgR+HzYfWAwh1Vn4y
5RUKKfPQX9j86sbBXFNknKrPEKmwUwOz0XQPqDCgogj51U0CHoi2VL1b+M9WryUg
wsHmn71Al7ru+tR+yh38rKOl2RROtdRogAHIWGgAq2bWxDPCQvGaHJqTRuzIXIVn
5h0IVky0Z86Y2cG9DQT7tctYIEZralsUCvnSqQcvSIeAif+0ouAfmJ5D2p0pU5kf
DEcFpeS1C492X/OWa8qX+pgA/6LJg7PAOuDR2L2dJGpXZeucq+LWL1synFw1SZ/k
XwSlsOcyGaIupNksV8PZevFVg+ZAKYhYK9GzGncNcYAfwSR4umBWNnueI9jaLHAk
seylXnR7+H3SdAi+bYDPqjASvzTFThsE7wQTtdwe3ufQ1SzHv+sRDDT7ijybPGuN
vEjq6p1lxET7DDWzQ3GI6Uzlecq8ygBPY+pPkiWoF1mDlH5NDwc=
=rneL
-END PGP SIGNATURE-

[Issue 5227] X ^^ FP at compile-time

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

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

--- Comment #18 from Manu  ---
Yay! 8 years in the making. This must be a very fine brew! :P

--

Re: isInputRange is false for non-copyable types

[Dmitry Olshansky via Digitalmars-d]

On Tuesday, 17 April 2018 at 15:14:02 UTC, Steven Schveighoffer 
wrote:

On 4/15/18 6:14 AM, Dmitry Olshansky wrote:
On Sunday, 15 April 2018 at 06:39:43 UTC, Jonathan M Davis 
wrote:
On Sunday, April 15, 2018 07:26:54 Shachar Shemesh via 
Digitalmars-d wrote:

[...]


It's extremely common for range-based functions to copy 
front. Even foreach does it. e.g.


[...]



Arguably it should “move” them.

This would have worked if input ranges didn’t have to cache 
front to support multiple ‘front’ calls before popFront. Which 
is a painful misfeature really as all algorithms would 
optimize for touching front once anyway.


Ugh, then you get things like fungetc.



For many algorithms indeed you can’t stop w/o peeking ahead. It’s 
just that lookahead of 1 is hardcoded in the range definition b/c 
it’s enough for a lot of things.


But then once you are past lookahead of 1, it has to do .save + 
restore if overshot. ungetc of 2 if you’d like.


However, there are certainly cases where it's expensive to 
compute front, and therefore, requires a cache. A new primitive 
that accesses front and pops it at the same time would be 
useful. We can have selected algorithms that can deal with it 
use that primitive instead (and instrument foreach to do it).


Might be an option. But as long as you have front/popFront/empty 
as well, no concurrent stuff.


Potentially, we can create a wrapper for all input ranges such 
that they support it.


Input range should “produce” elements not keep cache of them, 
forward ranges may cache current item alright.


Well, sometimes you HAVE to cache it. For instance File.byLine


File caches, byLine actually does
“read up until EOL and give me slice of that”

I do not see where caching of char[] plays any significant role. 
Except that due to how ranges work it likely has to do the 
readline at _empty_ or on construction + popFront.


is clearly an input range, and not a forward range. But it MUST 
cache because it's i/o that has to be buffered to be looked at! 
No reason to force caching on the user at that point.

-Steve

Re: Feature to get or add value to an associative array.

[Giles Bathgate via Digitalmars-d]

On Tuesday, 17 April 2018 at 16:18:32 UTC, Nick Treleaven wrote:
I called the function `slot` because it always returns the 
address of the slot which the value is stored in.


I like the name. I think your version is quite low level which 
ultimately provides more power at the expense of making the 
callee code less clean. I am not sure with D which of those two 
aspects is preferred. Perhaps both functions could be provided? 
What is the use case for knowing whether a value was inserted.

[Issue 18772] [ICE] Internal error: dmd\backend\cgcod.c 607 no optimizations

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

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

ponce  changed:

   What|Removed |Added

Summary|[ICE] Internal error:   |[ICE] Internal error:
   |dmd\backend\cgcod.c 607 |dmd\backend\cgcod.c 607 no
   ||optimizations

--

[Issue 18772] [ICE] Internal error: dmd\backend\cgcod.c 607

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

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

--- Comment #1 from ponce  ---
Successfully reproduced using:

dmd_2.079.1 (latest)
dmd_2.074.1
dmd_2.070.0 (2 years ago)

--

Re: (Unofficial) Discord Server!

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 17 April 2018 at 06:43:16 UTC, JN wrote:
I prefer ergonomics of Discord/Slack/Gitter over IRC, although 
in the long run I guess IRC is good for the openness compared 
to proprietiary solution.


Have you tried Matrix / Riot?

https://riot.im/app/#/room/#freenode_#d:matrix.org

[Issue 18772] New: [ICE] Internal error: dmd\backend\cgcod.c 607

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

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

  Issue ID: 18772
   Summary: [ICE] Internal error: dmd\backend\cgcod.c 607
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: alil...@gmail.com

Please consider the following program:


 main.d --

float fun(cfloat z)
{
return z.re;
}

void main()
{
cfloat[1] A;
float[1] B;
int i = 0;
double C = fun(A[i] * B[i]);  
}



Build it with DMD D Compiler v2.079.0 in 64-bit


$ rdmd -m32 main.d

(Builds and run without problem)


$ rdmd -m64 main.d

Internal error: dmd\backend\cgcod.c 607

--

[Issue 12734] Template cannot deduce E[] from typeof(null)

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

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

ag0aep6g  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ag0ae...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #2 from ag0aep6g  ---
(In reply to Andrej Mitrovic from comment #0)
> -
> void take1(int[] buffer) { }
> void take2(E)(E[] buffer) { }
> 
> void main()
> {
> take1(null);  // ok
> take2(null);  // fail
> }
> -
> 
> I'm not sure what 'E' would be deduced to with a typeof(null) though. Maybe
> just a 'void'? Or a 'void*'? It's hard to tell, but the above forces us to
> create overloads for the sake of supporting null.

Works since 2.067.1, with E = void. Closing as worksforme.
https://run.dlang.io/is/QhvCjh

--

Re: Feature to get or add value to an associative array.

[Nick Treleaven via Digitalmars-d]

On Sunday, 15 April 2018 at 22:52:47 UTC, Giles Bathgate wrote:
The function provides a means to get a value corresponding to 
the key, but if the value doesn't exist it will evaluate the 
lazy argument to create a new value, add this to the 
associative array and then return it.


auto p = lookup.getOrAdd("giles", new Person);


Thanks for making this pull, I've thought about solving this 
before. I think the function needs to provide a way to tell if 
the value was already present. I also think it's more ergonomic 
not to have to use a lazy argument, and probably more efficient, 
so I had in mind:


Value* slot(AA aa, K key, scope bool* inserted = null);

bool inserted;
auto p = aa.slot("key", );
if (inserted) {
  ...
  *p = new Value(...);
}
// use *p

This pattern needs a pointer to be returned, instead of using 
`ref`. Note that `` is valid in @safe code, but only 
with -dip1000. I called the function `slot` because it always 
returns the address of the slot which the value is stored in.

[Issue 1807] ENHANCEMENT: Let IFTI "see through" templates to simple aliases

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

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

--- Comment #7 from ag0aep6g  ---
*** Issue 10884 has been marked as a duplicate of this issue. ***

--

[Issue 10884] Support for using alias expressions to shorten inferred function types

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

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

ag0aep6g  changed:

   What|Removed |Added

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

--- Comment #5 from ag0aep6g  ---


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

--

Re: isInputRange is false for non-copyable types

[H. S. Teoh via Digitalmars-d]

On Tue, Apr 17, 2018 at 11:14:02AM -0400, Steven Schveighoffer via 
Digitalmars-d wrote:
> On 4/15/18 6:14 AM, Dmitry Olshansky wrote:
[...]
> > Input range should “produce” elements not keep cache of them,
> > forward ranges may cache current item alright.
> 
> Well, sometimes you HAVE to cache it. For instance File.byLine is
> clearly an input range, and not a forward range. But it MUST cache
> because it's i/o that has to be buffered to be looked at! No reason to
> force caching on the user at that point.
[...]

In the past I've used range-like (i.e., iteration) APIs that do not
cache the current element. To be quite frank, they were a royal pain to
work with, because they force user code to be needlessly cluttered with
ad hoc caching schemes that pollute the code all over the place.
Instead of having the range handle the caching, all downstream code that
uses the range has to implement their own caching and/or otherwise
implement ugly ad hoc workarounds for the lack thereof.  Andrei got it
right when he designed the range API with a cached .front, and I would
be opposed to any range API design that involves a non-caching .front.

For generative ranges like std.range.generate, well, .generate exists
precisely for that reason: to be the single implementation of a caching
.front that wraps around a non-caching generating function, so that
range implementers don't have to write their own caching code, but only
need to care about writing the generating function and let .generate
handle the caching for them.  The downstream user also doesn't need to
worry about the odd semantics of a non-caching .front, but can use the
range API as usual.  Win-win.


T

-- 
Recently, our IT department hired a bug-fix engineer. He used to work for 
Volkswagen.

[Issue 10884] Support for using alias expressions to shorten inferred function types

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

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

ag0aep6g  changed:

   What|Removed |Added

 CC||atila.ne...@gmail.com

--- Comment #4 from ag0aep6g  ---
*** Issue 11452 has been marked as a duplicate of this issue. ***

--

[Issue 11452] IFTI failure for aliased static array parameter

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

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

ag0aep6g  changed:

   What|Removed |Added

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

--- Comment #3 from ag0aep6g  ---


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

--

[Issue 13090] Type inferring fails at function parameters with parameterized alias

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

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

ag0aep6g  changed:

   What|Removed |Added

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

--- Comment #2 from ag0aep6g  ---


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

--

[Issue 10884] Support for using alias expressions to shorten inferred function types

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

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

ag0aep6g  changed:

   What|Removed |Added

 CC||ncras...@gmail.com

--- Comment #3 from ag0aep6g  ---
*** Issue 13090 has been marked as a duplicate of this issue. ***

--

[Issue 10884] Support for using alias expressions to shorten inferred function types

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

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

ag0aep6g  changed:

   What|Removed |Added

 CC||sky.13th...@gmail.com

--- Comment #2 from ag0aep6g  ---
*** Issue 16486 has been marked as a duplicate of this issue. ***

--

[Issue 16486] Compiler see template alias like a separate type in template function definition

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

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

ag0aep6g  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from ag0aep6g  ---


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

--

[Issue 10884] Support for using alias expressions to shorten inferred function types

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

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

ag0aep6g  changed:

   What|Removed |Added

 CC||e...@weka.io

--- Comment #1 from ag0aep6g  ---
*** Issue 18769 has been marked as a duplicate of this issue. ***

--

[Issue 18769] Cannot infer template parameters for aliased types

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

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

ag0aep6g  changed:

   What|Removed |Added

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

--- Comment #1 from ag0aep6g  ---


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

--

[Issue 16465] Template alias does not get unwrapped in templated functions

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

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

ag0aep6g  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||ag0ae...@gmail.com
 Resolution|--- |INVALID

--- Comment #9 from ag0aep6g  ---
(In reply to Sky Thirteenth from comment #8)
> (In reply to b2.temp from comment #7)
> > (In reply to Sky Thirteenth from comment #6)
> > > (In reply to b2.temp from comment #5)
> > > > I confirm the misunderstanding. If you permit I would suggest you to 
> > > > close
> > > > this one but to open a new issue using your second example. The first 
> > > > one
> > > > really represented issue 6082. The second is perfectly clear.
[...]
> Here the new one https://issues.dlang.org/show_bug.cgi?id=16486

Since the issue has been moved, I'm closing this one as invalid.

--

Re: Feature to get or add value to an associative array.

[Giles Bathgate via Digitalmars-d]

On Tuesday, 17 April 2018 at 09:21:14 UTC, Giles Bathgate wrote:

The java name for such a function is `computeIfAbsent`


More names from other languages, this time python:

https://docs.python.org/3/library/stdtypes.html#dict.setdefault

It's horrid though, a method called `set` that returns a value? 
Maybe I am biased against anything pythonic ;)

Re: Small Buffer Optimization for string and friends

[Per Nordlöw via Digitalmars-d]

On Sunday, 8 April 2012 at 05:56:36 UTC, Andrei Alexandrescu 
wrote:
Walter and I discussed today about using the small string 
optimization in string and other arrays of immutable small 
objects.


I put together SSOString at

https://github.com/nordlow/phobos-next/blob/967eb1088fbfab8be5ccd811b66e7b5171b46acf/src/sso_string.d

that uses small-string-optimization on top of a normal D string 
(slice).


I'm satisfied with everything excepts that -dip1000 doesn't 
vorbids `f` from compiling.


I also don't understand why `x[0]` cannot be returned by ref in 
the function `g`.


Comments are welcome.

Contents of sso_string.d follows:

module sso_string;

/** Small-size-optimized string.
 *
 * Store on the stack if constructed with <= `smallCapacity` 
number of

 * characters, otherwise on the GC heap.
 */
struct SSOString
{
private alias E = immutable(char); // immutable element type
private alias ME = char;   // mutable element type

pure nothrow:

/** Construct from `elements`, with potential GC-allocation 
(iff

 * `elements.length > smallCapacity`).
 */
this()(scope ME[] elements) @trusted // template-lazy
{
if (elements.length <= smallCapacity)
{
small.data[0 .. elements.length] = elements;
small.length = 
cast(typeof(small.length))(2*elements.length);

}
else
{
large = elements.idup; // GC-allocate
raw.length *= 2;  // shift up
raw.length |= 1;  // tag as large
}
}

@nogc:

// TODO add @nogc overload to construct from mutable static 
array <= smallCapacity


/** Construct from `elements` without any kind of heap 
allocation.

 */
this()(immutable(E)[] elements) @trusted // template-lazy
{
if (elements.length <= smallCapacity)
{
small.data[0 .. elements.length] = elements;
small.length = 
cast(typeof(small.length))(2*elements.length);

}
else
{
large = elements;   // @nogc
raw.length *= 2;// shift up
raw.length |= 1;// tag as large
}
}

@property size_t length() const @trusted
{
if (isLarge)
{
return large.length/2; // skip first bit
}
else
{
return small.length/2; // skip fist bit
}
}

scope ref inout(E) opIndex(size_t index) inout return @trusted
{
return opSlice()[index]; // automatic range checking
}

scope inout(E)[] opSlice() inout return @trusted
{
if (isLarge)
{
union RawLarge
{
Raw raw;
Large large;
}
RawLarge copy = void;
copy.large = cast(Large)large;
copy.raw.length /= 2; // adjust length
return copy.large;
}
else
{
return small.data[0 .. small.length/2]; // scoped
}
}

private @property bool isLarge() const @trusted
{
return large.length & 1; // first bit discriminates small 
from large

}

private:
struct Raw  // same memory layout as `E[]`
{
size_t length;  // can be bit-fiddled without GC 
allocation

E* ptr;
}

alias Large = E[];

enum smallCapacity = Large.sizeof - Small.length.sizeof;
static assert(smallCapacity > 0, "No room for small elements 
for E being " ~ E.stringof);
version(LittleEndian) // see: 
http://forum.dlang.org/posting/zifyahfohbwavwkwbgmw

{
struct Small
{
ubyte length;
E[smallCapacity] data;
}
}
else
{
static assert(0, "BigEndian support and test");
}

union
{
Raw raw;
Large large;
Small small;
}
}

///
@safe pure nothrow @nogc unittest
{
import container_traits : mustAddGCRange;
alias S = SSOString;

static assert(S.sizeof == 2*size_t.sizeof); // two words
static assert(S.smallCapacity == 15);
static assert(mustAddGCRange!S); // `Large large.ptr` must be 
scanned


auto s0 = S.init;
assert(s0.length == 0);
assert(!s0.isLarge);
assert(s0[] == []);

const s7 = S("0123456");
static assert(is(typeof(s7[]) == string));
assert(!s7.isLarge);
assert(s7.length == 7);
assert(s7[] == "0123456");
// TODO assert(s7[0 .. 4] == "0123");

const s15 = S("012345678901234");
static assert(is(typeof(s15[]) == string));
assert(!s15.isLarge);
assert(s15.length == 15);
assert(s15[] == "012345678901234");

const s16 = S("0123456789abcdef");
static assert(is(typeof(s16[]) == string));
assert(s16.isLarge);
assert(s16.length == 16);
assert(s16[] == "0123456789abcdef");
assert(s16[0] == '0');
assert(s16[10] == 'a');
assert(s16[15] == 'f');

// TODO static assert(!__traits(compiles, { auto _ = 

Reddit Post: Overview of the Efficient Programming Languages (v.3)

[Nerve via Digitalmars-d]

Overview of the Efficient Programming Languages (v.3): C++, Rust, 
Swift, Scala, Dlang, Kotlin, Nim, Julia, Golang, Python.


http://reddit.com/r/programming/comments/8cw2xn/overview_of_the_efficient_programming_languages/

Re: isInputRange is false for non-copyable types

[Steven Schveighoffer via Digitalmars-d]

On 4/15/18 6:14 AM, Dmitry Olshansky wrote:

On Sunday, 15 April 2018 at 06:39:43 UTC, Jonathan M Davis wrote:
On Sunday, April 15, 2018 07:26:54 Shachar Shemesh via Digitalmars-d 
wrote:

[...]


It's extremely common for range-based functions to copy front. Even 
foreach does it. e.g.


[...]



Arguably it should “move” them.

This would have worked if input ranges didn’t have to cache front to 
support multiple ‘front’ calls before popFront. Which is a painful 
misfeature really as all algorithms would optimize for touching front 
once anyway.


Ugh, then you get things like fungetc.

However, there are certainly cases where it's expensive to compute 
front, and therefore, requires a cache. A new primitive that accesses 
front and pops it at the same time would be useful. We can have selected 
algorithms that can deal with it use that primitive instead (and 
instrument foreach to do it). Potentially, we can create a wrapper for 
all input ranges such that they support it.


Input range should “produce” elements not keep cache of them, forward 
ranges may cache current item alright.


Well, sometimes you HAVE to cache it. For instance File.byLine is 
clearly an input range, and not a forward range. But it MUST cache 
because it's i/o that has to be buffered to be looked at! No reason to 
force caching on the user at that point.


-Steve

Re: Ldc on Windows

[kinke via Digitalmars-d-learn]

On Tuesday, 17 April 2018 at 11:01:21 UTC, Nicholas Wilson wrote:
You should also be able to use -link-internally /LLMV's lld if 
you don't want to install MSVC


Nope, the MSVC libs are still required, and no, the ancient ones 
shipping with DMD can't be used.

Re: #dbugfix 18493

[Mike Franklin via Digitalmars-d]

On Tuesday, 17 April 2018 at 12:13:06 UTC, Mike Franklin wrote:

On Tuesday, 17 April 2018 at 05:33:53 UTC, Radu wrote:


This is very odd, as the following compiles:
---
struct S
{
this(this)
{
}

~this()
{
}
}

struct C
{
S s1;
}
---

If the scope failure would cause this then I assume it would 
not work at all in any case.


Yeah! I think that is also a bug.


Nope, that's not a bug.  The reason the try-catch is only 
generated with two or more fields is to ensure that if an 
exception is thrown while blitting `s2`, `s1`'s destructor will 
still be called.


I'm not sure what the proper fix is yet.  The compiler could 
require you to attribute `this(this)` with `nothrow` in order to 
promise the compiler that it won't throw.  Then the compiler 
would know that it wouldn't need to add the try-catch around the 
postblit because there's no way for it to throw.  That would also 
ensure consistent behavior when compiling the same code with or 
without -betterC.


However, since throwing is off-limits entirely for -betterC, it 
doesn't make much sense to generate try-catch statements, only to 
have the compiler emit an error about it.


Maybe I should implement both. I need to sleep on it.

Mike

Re: Feature to get or add value to an associative array.

[Steven Schveighoffer via Digitalmars-d]

On 4/15/18 6:52 PM, Giles Bathgate wrote:

I find this later code clunky and it requires two hashes/lookups. The 
proposed implementation adds support directly to rt/aaA.d to avoid this. 
I should also point out that the allocation of a new Person in the 
example is trivial, but it might often be the case that the person 
instance is created by fetching a record from a db, or an Image loaded 
from disk, or a movie downloaded from the internet.


I think this is a great addition. I've always disliked the double-lookup 
requirement for ensuring a key was initialized. I'll note that C++ gets 
around this by always initializing on any access.


The name "getOrAdd" is a bit mechanical sounding. The real reason you 
want this is to ensure that key's value is initialized. 
ensureInitialized is long. get is already taken (if get weren't already 
taken, I'd suggest that name). Others have suggested using flags, but 
I'll note to them, `Flag` and `Yes` are part of std.typecons, and not 
accessible here.


getWithDefault sounds reasonable but probably would be confusing with 
the current `get` overload. Maybe getInitialized? I don't know that 
either of these are giant leaps ahead of getOrAdd.


Another possibility is getPtr. get currently gets a value, or returns a 
default value if it doesn't exist. But getPtr would return a pointer to 
the value, ensuring it's initialized.


In any case, thumbs up to the concept, and I'm ambivalent on the name.

-Steve

Getting the overload set of a template

[Arafel via Digitalmars-d-learn]

Hi!

Is there any way to get the full set of templates that are "overloaded" 
(in my case, based on constraints)?


Basically, I'd like to make something like 
https://run.dlang.io/is/z2LeAj return both versions of the template (and 
then retrieve their UDAs)...


If it's not possible, I can still work around it, but I find it a bit 
frustrating that you can only access the first version of a template.


Thanks!

Arafel

Re: Ldc on Windows

[Nicholas Wilson via Digitalmars-d-learn]

On Tuesday, 17 April 2018 at 12:42:48 UTC, Dgame wrote:
On Tuesday, 17 April 2018 at 11:01:21 UTC, Nicholas Wilson 
wrote:

On Tuesday, 17 April 2018 at 10:17:56 UTC, Dgame wrote:
Ah, I found the msvcEnv.bat and I told me that I have to VSC 
installation. Solved!


You should also be able to use -link-internally /LLMV's lld if 
you don't want to install MSVC


What would be "/LLMV's lld" in this case?


Sorry that was meant to be -link-internally / LLMV's lld (i.e. 
not a command line option. I forgot windows uses / for that.


I mean lld-link.exe or link-lld.exe (can't remember which) that 
comes with the dmd  install (and I think ldc install? or maybe 
you just use -link-internally).

[Issue 18771] New: Identical overload sets in different modules have different identities

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

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

  Issue ID: 18771
   Summary: Identical overload sets in different modules have
different identities
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timon.g...@gmx.ch

DMD v2.079.0:

---
module a;
void foo(int){}
---

---
module b;
void foo(string){}
---

---
module c;
import a, b;
alias fooC=foo;
---

---
module d;
import a, b;
alias fooD=foo;
---

---
module e;
import c, d;
static assert(__traits(isSame, fooC, fooD)); // fail
---

The code should compile.

--

[Issue 18584] Undefined identifier when not specifying 'this'

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

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

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

   What|Removed |Added

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

--

[Issue 18584] Undefined identifier when not specifying 'this'

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

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

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

https://github.com/dlang/dmd/commit/814b822011002fe89434f195597ed6a20042ce88
Fix Issue 18584 - Undefined identifier when not specifying 'this'

https://github.com/dlang/dmd/commit/b4d5005db0fd3581789d8a0942583f7c13efbc82
Merge pull request #8159 from RazvanN7/Issue_18584

Fix Issue 18584 - Undefined identifier when not specifying 'this'
merged-on-behalf-of: Razvan Nitu 

--

Re: #dbugfix 18493

[Radu via Digitalmars-d]

On Tuesday, 17 April 2018 at 12:13:06 UTC, Mike Franklin wrote:

On Tuesday, 17 April 2018 at 05:33:53 UTC, Radu wrote:


This is very odd, as the following compiles:
---
struct S
{
this(this)
{
}

~this()
{
}
}

struct C
{
S s1;
}
---

If the scope failure would cause this then I assume it would 
not work at all in any case.


Yeah! I think that is also a bug.  So (at least right now in my 
investigation) I think we first need to fix it so that it emits 
the error even with a single statement, and then fix it so it 
no longer generates the `scope(failure)` in -betterC.


Mike


Making it work without `scope(failure)` in -betterC mode should 
be the goal of the fix, as the simple case (just one member) 
doesn't generate any `scope(failure)`, at least the AST ouput 
(https://run.dlang.io/is/l5CicG) doesn't contain it.


Thanks for looking into it!

[Issue 18770] Ternary operator returns incorrect value when compiling with -O option

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

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

nebukur...@gmail.com changed:

   What|Removed |Added

   Severity|enhancement |normal

--

Re: Assoc. Array and struct with immutable member

[Dgame via Digitalmars-d-learn]

On Tuesday, 17 April 2018 at 11:38:17 UTC, Jonathan M Davis wrote:
On Sunday, April 15, 2018 17:59:01 Dgame via 
Digitalmars-d-learn wrote:
How am I supposed to insert a struct with immutable members 
into an assoc. array?


Reduced example:

struct A {
 immutable string name;
}

A[string] as;
as["a"] = A("a"); // Does not work



I would point out that in general, having const or immutable 
fields in a struct is a terrible idea. It causes all kinds of 
problems because stuff like assignment doesn't work. If you 
want the field to be read-only, you'll have far fewer problems 
if you simply use a function to access it instead of making the 
member public. e.g.


struct A
{
public:

@property string name() { return _name; }

private:

string _name;
}

The problem you're having here is just one example of the list 
of things that don't work if you have a struct with immutable 
members. It looks like the AA probably is doing something like 
initializing the entry with A.init and then assigning it the 
new value, and that's not going to work if the struct has 
immutable members - which is exactly what the error message 
says.


- Jonathan M Davis


That's how I solved it. But it is troublesome and annoying 
because it increases the amount of manually work I have to do.

Re: Ldc on Windows

[Dgame via Digitalmars-d-learn]

On Tuesday, 17 April 2018 at 11:01:21 UTC, Nicholas Wilson wrote:

On Tuesday, 17 April 2018 at 10:17:56 UTC, Dgame wrote:
Ah, I found the msvcEnv.bat and I told me that I have to VSC 
installation. Solved!


You should also be able to use -link-internally /LLMV's lld if 
you don't want to install MSVC


What would be "/LLMV's lld" in this case?

[Issue 18770] New: Ternary operator returns incorrect value when compiling with -O option

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

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

  Issue ID: 18770
   Summary: Ternary operator returns incorrect value when
compiling with -O option
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: nebukur...@gmail.com

Code:

import std.stdio;

void main() {
foreach (i; 0..2) {
long x = (i % 2 == 0) ? 1 : -1;
x.writeln;
}
}

-
Output (with -O option):
1
4294967295
-
Output (without -O option):
1
-1
-

It seems that -1 is implicitly converted to uint.
As far as I tried, this behavior does not occur when...

# type is int
  int x = (i % 2 == 0) ? 1 : -1 

# negative value is on the left
  long x = (i % 2 == 0) ? -2 : -1  

# condition can be evaluated at compile time(?)
  long x = false ? 1 : -1

All of the above correctly returns negative value with -O option.

--

Re: #dbugfix 18493

[Mike Franklin via Digitalmars-d]

On Tuesday, 17 April 2018 at 05:33:53 UTC, Radu wrote:


This is very odd, as the following compiles:
---
struct S
{
this(this)
{
}

~this()
{
}
}

struct C
{
S s1;
}
---

If the scope failure would cause this then I assume it would 
not work at all in any case.


Yeah! I think that is also a bug.  So (at least right now in my 
investigation) I think we first need to fix it so that it emits 
the error even with a single statement, and then fix it so it no 
longer generates the `scope(failure)` in -betterC.


Mike

Re: Assoc. Array and struct with immutable member

[Alex via Digitalmars-d-learn]

On Tuesday, 17 April 2018 at 11:07:55 UTC, bauss wrote:


Even though it works in static this, then it still looks like a 
bug if you ask me, because the associative array itself isn't 
immutable.


Yeah... I'm not sure, if this behavior is wanted, too...

If you argue, that an absent field in in AA is not created, then 
it is a bug.
But if you argue that after creation of the AA everything is 
created, then adding another field is equal to modifying this 
very field, and that would be correctly forbidden.


So... no clue where a hint in the docu is hidden.

Re: Assoc. Array and struct with immutable member

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, April 15, 2018 17:59:01 Dgame via Digitalmars-d-learn wrote:
> How am I supposed to insert a struct with immutable members into
> an assoc. array?
>
> Reduced example:
> 
> struct A {
>  immutable string name;
> }
>
> A[string] as;
> as["a"] = A("a"); // Does not work
> 

I would point out that in general, having const or immutable fields in a
struct is a terrible idea. It causes all kinds of problems because stuff
like assignment doesn't work. If you want the field to be read-only, you'll
have far fewer problems if you simply use a function to access it instead of
making the member public. e.g.

struct A
{
public:

@property string name() { return _name; }

private:

string _name;
}

The problem you're having here is just one example of the list of things
that don't work if you have a struct with immutable members. It looks like
the AA probably is doing something like initializing the entry with A.init
and then assigning it the new value, and that's not going to work if the
struct has immutable members - which is exactly what the error message says.

- Jonathan M Davis

[Issue 7443] Better diagnostic on wrongly written static constructor

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

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

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

https://github.com/dlang/dmd/commit/4a023ae3f23480110ab5ac3e0a4915e1b0ad4b6d
Fix Issue 7443 - Better diagnostic on wrongly written static constructor

https://github.com/dlang/dmd/commit/af1d5bd9e10938c605938e2424de78dc941a24b3
Merge pull request #8164 from RazvanN7/Issue_7443

Fix Issue 7443 - Better diagnostic on wrongly written static constructor
merged-on-behalf-of: Razvan Nitu 

--

[Issue 7443] Better diagnostic on wrongly written static constructor

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

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

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

   What|Removed |Added

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

--

Re: Delegates and classes for custom code.

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

On Tuesday, 17 April 2018 at 03:55:55 UTC, Chris Katko wrote:

What I want:

class viewport_t
  {
  int x,y,w,h;
  }

class dialog_t
  {
  int x,y;

  this( int x, int y, delegate void (viewport_t) on_draw )
{
this.x = x;
this.y = y;
this.execute = execute;
}

  void draw_text(string text)
{
}

  delegate void (viewport_t) on_draw;
  }

void function()
  {
  viewport_t v;
  dialog_t (15, 15,
delegate void (viewport_t)
  {
  draw_text("hello world"); //calls dialog_t function
  }
)
  }

Is this possible? Pass to a class, the code to run. But the 
code has to somehow know about the class methods.


I don't think you can pass "dialog_t.this" as it's being 
constructed!


Depending on exactly what you want to do, this may be impossible, 
or bauss' code might fit the bill, or you could use anonymous 
classes:



class viewport_t
{
int x,y,w,h;
}

class dialog_t
{
int x,y;

this( int x, int y)
{
this.x = x;
this.y = y;
}

void draw_text(string text)
{
}

abstract void on_draw(viewport_t);
}

void fn()
{
viewport_t v;
auto d = new class dialog_t {
this() { super(15,15); }
override void on_draw(viewport_t) {
draw_text("hello world");
}
};
}

--
  Simen

Re: Assoc. Array and struct with immutable member

[bauss via Digitalmars-d-learn]

On Sunday, 15 April 2018 at 18:51:52 UTC, Alex wrote:

On Sunday, 15 April 2018 at 17:59:01 UTC, Dgame wrote:
How am I supposed to insert a struct with immutable members 
into an assoc. array?


Reduced example:

struct A {
immutable string name;
}

A[string] as;
as["a"] = A("a"); // Does not work



Via a static this() it would work. But I guess, this is not 
what you are looking for, is it?


´´´
static this()
{
as["a"] = A("a");
}

void main()
{   
assert(as["a"].name == "a");
}


struct A {
immutable string name;
}

A[string] as;
´´´


It also works, if you hide the AA in a class and all the 
insertions into the constructor.



´´´
/*
static this()
{
as["a"] = A("a");
}
*/
void main()
{   
auto c = new Container(A("a"));
assert(c.as["a"].name == "a");
}

struct A {
immutable string name;
}

class Container
{
A[string] as;
this(A a)
{
as[a.name] = a;
}
}
´´´


Even though it works in static this, then it still looks like a 
bug if you ask me, because the associative array itself isn't 
immutable.

Re: Ldc on Windows

[Nicholas Wilson via Digitalmars-d-learn]

On Tuesday, 17 April 2018 at 10:17:56 UTC, Dgame wrote:
Ah, I found the msvcEnv.bat and I told me that I have to VSC 
installation. Solved!


You should also be able to use -link-internally /LLMV's lld if 
you don't want to install MSVC

Re: lazy evaluation of logical operators in enum definition

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

On Monday, 16 April 2018 at 05:57:01 UTC, Shachar Shemesh wrote:

Consider the following program:

struct S1 {
enum member = 3;
}

struct S2 {
enum member = 2;
}

struct S3 {
}

enum prop(T) = __traits(hasMember, T, "member") && T.member==3;

pragma(msg, prop!S1);
pragma(msg, prop!S2);
pragma(msg, prop!S3);

When compiled, it produces:
true
false
test.d(12): Error: no property member for type S3
test.d(16): Error: template instance `test.prop!(S3)` error 
instantiating

test.d(16):while evaluating pragma(msg, prop!(S3))

If I change the definition of "prop" to:
template prop(T) {
static if( __traits(hasMember, T, "member") && T.member==3 )
enum prop = true;
else
enum prop = false;
}

then everything compiles as expected.

It seems that the && evaluation does not stop when the first 
false is found.


There's a kinda neat (and kinda ugly) way to implement prop in 
one line:


enum prop(T) = __traits(compiles, { static assert(T.member == 
3); });


Now, that's not the same as short-circuiting, and only useful in 
some cases, but for those cases, it's useful.


--
  Simen

Re: Delegates and classes for custom code.

[bauss via Digitalmars-d-learn]

On Tuesday, 17 April 2018 at 03:55:55 UTC, Chris Katko wrote:

What I want:

class viewport_t
  {
  int x,y,w,h;
  }

class dialog_t
  {
  int x,y;

  this( int x, int y, delegate void (viewport_t) on_draw )
{
this.x = x;
this.y = y;
this.execute = execute;
}

  void draw_text(string text)
{
}

  delegate void (viewport_t) on_draw;
  }

void function()
  {
  viewport_t v;
  dialog_t (15, 15,
delegate void (viewport_t)
  {
  draw_text("hello world"); //calls dialog_t function
  }
)
  }

Is this possible? Pass to a class, the code to run. But the 
code has to somehow know about the class methods.


I don't think you can pass "dialog_t.this" as it's being 
constructed!


First of all your code is not valid D code.

To construct a delegate you use the following syntax:

RETURN_TYPE delegate(PARAMS);

Ex. in your case:

void delegate(viewport_t);

Secondly, classes are reference types and thus you cannot 
construct just like:


viewport_t v;

It must be assigned using "new".

Ex.

auto v = new viewport_t;

The same goes for your dialog_t instance.

What you can do to avoid double allocation of dialog_t is to 
initially set it to void and thus you can point to the initial 
variable within your delegate that is constructed when dialog_t 
is actually constructed.


Ex.

dialog_t d = void;
d = new dialog_t (15, 15,
  delegate void (viewport_t)
  {
  d.draw_text("hello world"); //calls dialog_t 
function

  }
);

I could go into more details, but that would be completely 
unrelated to your issue at hand.

Re: Ldc on Windows

[Dgame via Digitalmars-d-learn]

On Tuesday, 17 April 2018 at 09:42:01 UTC, Dgame wrote:

I'm trying to use Ldc on Windows, but I get these linker errors:


OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Warning 9: Unknown Option : OUT
OPTLINK : Warning 9: Unknown Option : LIBPATH
OPTLINK : Warning 9: Unknown Option : D
OPTLINK : Warning 9: Unknown Option : LDC
OPTLINK : Warning 9: Unknown Option : ..
OPTLINK : Warning 9: Unknown Option : LIB
:REF.obj
 Error 2: File Not Found :REF.obj
Error: D:\D\dmd2\windows\bin\link.exe failed with status: 1


How can I solve this?


Ah, I found the msvcEnv.bat and I told me that I have to VSC 
installation. Solved!

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

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

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

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

   What|Removed |Added

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

--

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

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

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

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

https://github.com/dlang/dmd/commit/db1f8041670d592c3ad94111a3dc83ba12237932
Fix Issue 18746 - function returning empty struct isn't called if used in
equality expression

https://github.com/dlang/dmd/commit/ebd69c0b9ff4ae64d8e2a4aeef2939c973e6ad5b
Merge pull request #8153 from RazvanN7/Issue_18746

Fix Issue 18746 - function returning empty struct isn't called if used in
equality expression
merged-on-behalf-of: Razvan Nitu 

--

Ldc on Windows

[Dgame via Digitalmars-d-learn]

I'm trying to use Ldc on Windows, but I get these linker errors:


OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Warning 9: Unknown Option : OUT
OPTLINK : Warning 9: Unknown Option : LIBPATH
OPTLINK : Warning 9: Unknown Option : D
OPTLINK : Warning 9: Unknown Option : LDC
OPTLINK : Warning 9: Unknown Option : ..
OPTLINK : Warning 9: Unknown Option : LIB
:REF.obj
 Error 2: File Not Found :REF.obj
Error: D:\D\dmd2\windows\bin\link.exe failed with status: 1


How can I solve this?

Re: Is DWT usable?

[dangbinghoo via Digitalmars-d-dwt]

On Monday, 16 April 2018 at 18:50:38 UTC, Jacob Carlborg wrote:

On 2018-04-16 06:24, dangbinghoo wrote:


I have noticed DWT moved to as a dub package. And said it easy 
to startup.


So, I just cloned the DWT git repo. And did the same thing as 
README.


But I got the following :

```
dub --single main.d
Performing "debug" build using /usr/bin/dmd for x86_64.
dwt:base 1.0.1+swt-3.4.1.commit.2.gd729d7d: target for 
configuration "library" is up to date.
dwt 1.0.1+swt-3.4.1.commit.2.gd729d7d: target for 
configuration "linux-gtk" is up to date.

main ~master: building configuration "application"...
Linking...
To force a rebuild of up-to-date targets, run again with 
--force.

Running ./main
Program exited with code -11
```

the same result as I tried half year ago.


Which platform are you using?


both archlinux (updated) and deepin linux 15(same core as debain 
8).

Re: Feature to get or add value to an associative array.

[Giles Bathgate via Digitalmars-d]

On Tuesday, 17 April 2018 at 07:40:23 UTC, Giles Bathgate wrote:
My personal reason for not liking it is because the same name 
is used by Microsoft


The java name for such a function is `computeIfAbsent`

https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#computeIfAbsent-K-java.util.function.Function-

[Issue 18769] New: Cannot infer template parameters for aliased types

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

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

  Issue ID: 18769
   Summary: Cannot infer template parameters for aliased types
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: major
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@weka.io

Example code:

  struct S(A) {}
  alias T(A) = S!A;

  // OK:
  void withS(A)(S!A x) {}
  withS(S!int());

  // "foo cannot deduce function from argument types":
  void withT(A)(T!A x) {}
  withT(S!int());

Aliases in parameter types should be expanded (symbolically) before inferring.

--

[Issue 5227] X ^^ FP at compile-time

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

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

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

   What|Removed |Added

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

--

[Issue 5227] X ^^ FP at compile-time

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

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

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

https://github.com/dlang/dmd/commit/6767a32f6988c6794815405e01f07250177d6098
fix Issue 5227 - X ^^ FP at compile-time

https://github.com/dlang/dmd/commit/a4fbc9829da9e4b3e6d73859a42dc6e624e9b790
Merge pull request #8071 from WalterBright/fix5227

fix Issue 5227 - X ^^ FP at compile-time
merged-on-behalf-of: Walter Bright 

--

Re: Issues with debugging GC-related crashes #2

[Kagamin via Digitalmars-d]

Other stuff to try:
1. run application compiled on debian against ubuntu libs
2. can you mix dependencies from debian and ubuntu?

Re: Issues with debugging GC-related crashes #2

[Kagamin via Digitalmars-d]

On Monday, 16 April 2018 at 16:36:48 UTC, Matthias Klumpp wrote:
The code uses std.typecons.scoped occasionally, does no GC 
allocations in destructors and does nothing to mess with the GC 
in general.


What do you use destructors for?

Re: Feature to get or add value to an associative array.

[Giles Bathgate via Digitalmars-d]

On Tuesday, 17 April 2018 at 00:04:32 UTC, Cym13 wrote:
"in" returns a pointer to the object, there'es not double 
lookup necessary:


// if we don't know .get(key, default) exists
auto ptr   = key in aa;
auto value = ptr ? *ptr : default;


This doesn't work. `in` returns null when the key doesn't exist. 
So you are de-referencing null: 
https://github.com/dlang/druntime/blob/master/src/rt/aaA.d#L417


is a new flag/method really that necessary? In my experience if 
you have trouble naming it you haven't found its true purpose 
yet.


My personal reason for not liking it is because the same name is 
used by Microsoft: 
https://msdn.microsoft.com/en-us/library/ee378676(v=vs.110).aspx


I think I have clearly explained its purpose.

[Issue 18649] curl on Ubuntu 18.04 depends on libcurl4, .deb installer depends on libcurl3

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

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

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

https://github.com/dlang/installer/commit/4790451e11f3891cf74efa54b9e1b2e29fd4eaa9
fix Issue 18649 - curl on Ubuntu 18.04 depends on libcurl4, ...

... .deb installer depends on libcurl3

- depend on libcurl4 | libcurl3 alternative
- degrading libcurl from dependency to recommends would be welcome,
  but does not work because recommendations are not installed for raw
  .deb packages (--fix-broken only installs dependencies).
  `dpkg -i dmd_2.079.1-0_amd64.deb && apt-get --fix-broken install`
- also add suggested libcurl-dev alternative

https://github.com/dlang/installer/commit/8233177ccc37c4ca5e6a8cfdc39b0a06ece5b2d7
Merge pull request #318 from MartinNowak/test_pkg_install

fix Issue 18649 - curl on Ubuntu 18.04 depends on libcurl4, ...

--

[Issue 18649] curl on Ubuntu 18.04 depends on libcurl4, .deb installer depends on libcurl3

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

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

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

   What|Removed |Added

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

--

Re: Building is slow!

[Daniel Kozak via Digitalmars-d]

Try disable your antivirus

On Mon, Apr 16, 2018 at 10:27 PM, Ivan Trombley via Digitalmars-d <
digitalmars-d@puremagic.com> 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?
>
>

Re: (Unofficial) Discord Server!

[bauss via Digitalmars-d]

On Tuesday, 17 April 2018 at 02:36:20 UTC, Wild wrote:

On Monday, 16 April 2018 at 22:24:18 UTC, Luke Wilson wrote:
Hi there! After having found nearly zero solutions for a D 
community on Discord, having one server be quite inefficient, 
I've made my own. https://discord.gg/crpA2Hn


I hope to bring the community closer by doing this.


I guess I should link my discord. The dlang-community discord 
move there as my discord
was bigger and it was mostly already all about D. 
https://discord.gg/bMZk9Q4


This is were, for example WebFreak is (developer of code-d).


Indeed, I was about to mention your discord server.

[Issue 18767] __xtoHash memberwise hashing shouldn't just sum the member hashes

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

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

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

https://github.com/dlang/dmd/commit/2f13c2d416490fdb5e62c0d296e42b76c5c02388
Fix Issue 18767 - __xtoHash memberwise hashing shouldn't just sum the member
hashes

https://github.com/dlang/dmd/commit/f4c0c6579b8bca9af003f7221c9a99f241b7fea8
Merge pull request #8175 from n8sh/issue-18767-xtoHash

Fix Issue 18767 - __xtoHash memberwise hashing shouldn't just sum the member
hashes
merged-on-behalf-of: Walter Bright 

--

[Issue 18767] __xtoHash memberwise hashing shouldn't just sum the member hashes

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

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

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

   What|Removed |Added

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

--

Re: lazy evaluation of logical operators in enum definition

[Jacob Carlborg via Digitalmars-d]

On Monday, 16 April 2018 at 05:57:01 UTC, Shachar Shemesh wrote:

Consider the following program:

struct S1 {
enum member = 3;
}

struct S2 {
enum member = 2;
}

struct S3 {
}

enum prop(T) = __traits(hasMember, T, "member") && T.member==3;

pragma(msg, prop!S1);
pragma(msg, prop!S2);
pragma(msg, prop!S3);

When compiled, it produces:
true
false
test.d(12): Error: no property member for type S3
test.d(16): Error: template instance `test.prop!(S3)` error 
instantiating

test.d(16):while evaluating pragma(msg, prop!(S3))

If I change the definition of "prop" to:
template prop(T) {
static if( __traits(hasMember, T, "member") && T.member==3 )
enum prop = true;
else
enum prop = false;
}

then everything compiles as expected.

It seems that the && evaluation does not stop when the first 
false is found.


I think the issue is better illustrated with a function:

bool prop(T)()
{
if (__traits(hasMember, T, "member"))
{
if (T.member == 3)
return true;
}

return false;
}

In this function there's no way to tell if the function is going 
to be executed at compile time or at runtime. Therefore the 
semantics of the whole function need to be valid. Replacing the 
`if` with a `static if` would solve the problem, as you 
mentioned. This works because the semantic analysis of `static 
if` and CTFE evaluation of a function occurs at different phases 
in the compiler. This post explains this better and in more 
detail [1]. The issue is that the compiler will do the semantic 
analysis of `T.member` before it has run CTFE or constant folding 
on the expression.


Although, one could argue that in your case it's clear that the 
expression only will be evaluated at compile time, but that's not 
how the compiler works currently.


[1] 
https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time


--
/Jacob Carlborg