[Issue 14071] ICE: backend/gloop.c 862

[via Digitalmars-d-bugs]

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

--- Comment #2 from Martin Krejcirik  ---
ICE stopped after pull https://github.com/dlang/dmd/pull/5324 (DWARF EH), I'm
not sure if it was fixed since, or the original problem is still there.

--

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Friday, 9 December 2016 at 02:10:58 UTC, Andrei Alexandrescu 
wrote:

On 12/08/2016 04:24 PM, Stefan Koch wrote:

Results are obtained running the following code
uint MakeInitAndSumArray(uint length)
{
uint result;
uint[] arr;
arr.length = length;

while(length--)
{
arr[length] = length;
}
foreach(e;arr)
{
  result += e;
}

return result;
}

pragma(msg, MakeInitAndSumArray(ushort.max));
pragma(msg, MakeInitAndSumArray(ushort.max/2));
pragma(msg, MakeInitAndSumArray(ushort.max*2));


That's pretty awesome. The new CTFE engine release will soon 
rival Tesla Model 3 in terms of interest raised :o).


In addition to artificial corpora like the above, I suggest 
comparing against real-world code - starting with simpler 
things such as bitfields instantiations.



Andrei


That will not work currently.
Since function and methods calls are still "in the works".
They will require another restructuring as well.
Therefore artificial tests are the best I can do to gunge 
performance.

Re: template library like Jinja

[Brian via Digitalmars-d-learn]

On Wednesday, 21 November 2012 at 20:56:04 UTC, Masahiro Nakagawa 
wrote:
On Tuesday, 20 November 2012 at 11:38:46 UTC, Tobias Pankrath 
wrote:

Is there any template library like Jinja? (jinja.pocoo.org).

I'm pretty sure we can do even better by leveraging CTFE and a 
precompiler, but speed is no concern for me.


I'm not familiar with Jinja.
So I may not meet your expectation,
but I have the D version of Mustache template engine.

https://github.com/repeatedly/mustache4d
http://mustache.github.com/


Masahiro


jinja2 or twig better to use!

Re: CTFE Status

[Andrei Alexandrescu via Digitalmars-d]

On 12/08/2016 04:24 PM, Stefan Koch wrote:

Results are obtained running the following code
uint MakeInitAndSumArray(uint length)
{
uint result;
uint[] arr;
arr.length = length;

while(length--)
{
arr[length] = length;
}
foreach(e;arr)
{
  result += e;
}

return result;
}

pragma(msg, MakeInitAndSumArray(ushort.max));
pragma(msg, MakeInitAndSumArray(ushort.max/2));
pragma(msg, MakeInitAndSumArray(ushort.max*2));


That's pretty awesome. The new CTFE engine release will soon rival Tesla 
Model 3 in terms of interest raised :o).


In addition to artificial corpora like the above, I suggest comparing 
against real-world code - starting with simpler things such as bitfields 
instantiations.



Andrei

[Issue 16651] atomicOp!"-="(ulong, uint) = wrong result/codegen

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/druntime/commit/44f45280b7fe308731611801385f8c6226214682
fix issue 16651 - atomicOp!"-="(ulong, uint) = wrong result/codegen

https://github.com/dlang/druntime/commit/422c8f7b0f0e6598910737981074e0c45a4eb1b9
Merge pull request #1690 from aG0aep6G/16651

--

[Issue 16764] `hashOf` is misleading, error-prone, and useless

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/druntime/commit/5c187e05ff87404ebf4884cfc548324c2c3ed0fc
Revert object.hashOf changes from "use array interface to hashOf()"

--

[Issue 16654] hashOf returns different hashes for the same string value

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/druntime/commit/5c187e05ff87404ebf4884cfc548324c2c3ed0fc
Revert object.hashOf changes from "use array interface to hashOf()"

--

Re: @property

[ArturG via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 22:46:32 UTC, Jonathan M Davis 
wrote:
On Thursday, December 08, 2016 22:11:22 ArturG via 
Digitalmars-d-learn wrote:
On Thursday, 8 December 2016 at 16:54:57 UTC, Adam D. Ruppe 
wrote:

> On Thursday, 8 December 2016 at 16:53:13 UTC, Satoshi wrote:
>> is there any advantage of marking function as @property??
>
> Not really. I think it just changes the meaning of
> typeof(thatfunc) but otherwise it does nothing.
>
> However, if you use it in a base class, you must also use it 
> when overriding the function.


it does when you add it to for example a struct with alias 
opCall

this.
reported it as a bug
https://issues.dlang.org/show_bug.cgi?id=16951

but seems to be addressed by https://wiki.dlang.org/DIP23


...

- Jonathan M Davis


i actually didnt want to use @property at all, as i asumed that 
by using alias opCall this it would always call opCall not only 
sometimes.


the issue was about the commented line
// a; // Error: var has no effect in expression (a)

the rest can be solved by @property or a custom toString.

Re: Range of uncopyable elements

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, December 08, 2016 22:32:47 Jerry via Digitalmars-d-learn wrote:
> On Thursday, 8 December 2016 at 21:46:26 UTC, Jonathan M Davis
>
> wrote:
> > However, at least as of C++98, non-copyable elements in a
> > container were not allowed IIRC, so it would have been pretty
> > rare to have a C++ iterator that returned a non-copyable value
> > when you dereferenced it.
>
> Even if it was uncommon, i doubt anyone actually made a copy of
> the dereferenced iterator.

I've seen that in C++ code all the time, especially if you're dealing with
smart pointers, because otherwise you have to do stuff like (*iter)->foo()
instead of just var->foo().

> There were also no restrictions in place that every algorithm
> needed it to be copyable, only the ones that actually needed it.
> In the case of C++, dereferencing an iterator was basically free.
> As an iterator was essentially a pointer and there were no
> special iterators.

Except that C++ _does_ have special iterators. They're just not as common.

> As an example you can write the following in C++:
>
>  int  foo0() { return 10; }
>  int& foo1() { static int i; return i; }
>
>  const int& a = foo0(); // a copy is made on the stack, this
> ref points to it
>  const int& b = foo1(); // this ref points to the global
> variable in foo1()

> > Yes, not allowing copyable elements for ranges is a problem.
> > But allowing them would also be a big problem.
>
> Not if one of the biggest and most reoccurring complaints with D
> was fixed.

With the upcoming improvements to @safe and return ref, it _might_ happen
that there will be a way for a function to accept rvalues by ref. Andrei has
indicated that a really good proposal might be accepted. But that's a
separate issue from having ref on local variables, which is what would be
required for what you're suggesting, and both Walter and Andrei have been
adamant that that is not worth it - even without getting rvalue references
into the mix. I don't know that it would be impossible to convince them
otherwise, but I would be _very_ surprised if anyone managed to talk them
into it.

And for the most part, with ranges, this is pretty much a non-issue. It does
become an issue when you start worrying about ranges with a non-copyable
front, but this is literally only the second or third thread that I have
ever seen where anyone complained about it. Much as it is annoying when
someone runs int ito, it's not a big complaint that folks have. And given
how much of a pain it would be to deal with in general, I seriously question
that it's worth it - especially when simply using pointers fixes the
problem.

- Jonathan M Davis

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Thursday, 8 December 2016 at 19:49:47 UTC, Faux Amis wrote:

Any reason for the infinite depth update posting style?
I would have loved to see each update to be a child of the root 
post with its own discussions tree.
Currently, the posts are quite unreadable in tree view 
(thunderbird).



On 2016-10-31 14:29, Stefan Koch wrote:
Hi Guys, since I got a few complaints about giving minor 
status updates

in the announce group, I am opening this thread.


The reason it that I don't use the tree view.
I just answer to myself every time I have an update.
It looks fine on the web-frontend.

Re: @property

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, December 08, 2016 22:11:22 ArturG via Digitalmars-d-learn 
wrote:
> On Thursday, 8 December 2016 at 16:54:57 UTC, Adam D. Ruppe wrote:
> > On Thursday, 8 December 2016 at 16:53:13 UTC, Satoshi wrote:
> >> is there any advantage of marking function as @property??
> >
> > Not really. I think it just changes the meaning of
> > typeof(thatfunc) but otherwise it does nothing.
> >
> > However, if you use it in a base class, you must also use it
> > when overriding the function.
>
> it does when you add it to for example a struct with alias opCall
> this.
> reported it as a bug
> https://issues.dlang.org/show_bug.cgi?id=16951
>
> but seems to be addressed by https://wiki.dlang.org/DIP23

Except that it's not really a bug. It's a design flaw in the original
solution for properties which gave us optional parens. And since @property
has never really been implemented to properly _do_ much of anything, it
doesn't actually fix the problem. While it's a nice idea in concept,
@property was half-baked from the beginning, and it's never actually done
anything useful except act as documentation. So, as it stands, @property
doesn't matter for anything like this. It's just that we would need to
actually implement something with it to solve that particular problem (DIP23
being one proposal to do so). And as it stands, property functions for
callables simply don't work like a variable would, defeating the purpose of
making them properties.

It would be very nice if we got a DIP that was approved which solved this,
but @property is not a topic that much of anyone wants to discuss at this
point. There's never really been agreement on how properties should be
handled in D, and everyone is sick of discussing it. And we've lived with
this flaw with callables and properties for years now. So, I think that it
would be pretty hard to get a DIP past Walter and Andrei, much as we really
should clean this @property mess up.

- Jonathan M Davis

Re: Range of uncopyable elements

[Jerry via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 21:46:26 UTC, Jonathan M Davis 
wrote:

However, at least as of C++98, non-copyable elements in a
container were not allowed IIRC, so it would have been pretty
rare to have a C++ iterator that returned a non-copyable value
when you dereferenced it.


Even if it was uncommon, i doubt anyone actually made a copy of 
the dereferenced iterator.
There were also no restrictions in place that every algorithm 
needed it to be copyable, only the ones that actually needed it.

In the case of C++, dereferencing an iterator was basically free.
As an iterator was essentially a pointer and there were no 
special iterators.



Also, it pretty much _is_ assumed that

auto h = r.front;

is cheap, and there are plenty of cases where calling front
multiple times for the same range would incur additional
overhead, because front is calculated rather than simply
returning a value (e.g. this is what happens with map).
So, it could be a definite performance hit in general to start
insisting that r.front be called without the value being
assigned somewhere.


No one suggested calling front multiple times as a fix. Part of 
the problem with D is an old one and one that comes up often.
There are no rvalue references. This means it's a pain in the ass 
to write generic code. There's no easy way to write code that

will work for both references and values.

As an example you can write the following in C++:

int  foo0() { return 10; }
int& foo1() { static int i; return i; }

const int& a = foo0(); // a copy is made on the stack, this 
ref points to it
const int& b = foo1(); // this ref points to the global 
variable in foo1()


in D:

int foo0() { ... }
ref int foo1() { ... }

auto a = foo0();  // a copy is made
auto b = foo1();  // a copy is made
auto c = (); // need to write different code to get the 
result we want


void callback(ref int);

callback(a); // ok
callback(b); // ok
callback(c); // nope

The problem lies with D's inability to write generic code that 
works in boths instances. This means writing the same code twice

in some instances, or just not supporting one of the methods.



Yes, not allowing copyable elements for ranges is a problem.
But allowing them would also be a big problem.


Not if one of the biggest and most reoccurring complaints with D 
was fixed.



What we should ultimately do about it, I don't know, but I
think that it's pretty clear that the majority of code would be
better off if non-copyable elements for ranges were not
allowed. And it _is_ possible to work around the problem by
doing as H.S. Teoh suggested and using ranges of pointers.


I don't think so. There's a lot of functions that work with 
non-copyable
elements. Without modifying any code, the only blockage is caused 
by isInputRange.

Oh well, custom build of phobos it is.

Re: @property

[ArturG via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 16:54:57 UTC, Adam D. Ruppe wrote:

On Thursday, 8 December 2016 at 16:53:13 UTC, Satoshi wrote:

is there any advantage of marking function as @property??


Not really. I think it just changes the meaning of 
typeof(thatfunc) but otherwise it does nothing.


However, if you use it in a base class, you must also use it 
when overriding the function.


it does when you add it to for example a struct with alias opCall 
this.

reported it as a bug
https://issues.dlang.org/show_bug.cgi?id=16951

but seems to be addressed by https://wiki.dlang.org/DIP23

Re: @property

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, December 08, 2016 16:54:57 Adam D. Ruppe via Digitalmars-d-
learn wrote:
> On Thursday, 8 December 2016 at 16:53:13 UTC, Satoshi wrote:
> > is there any advantage of marking function as @property??
>
> Not really. I think it just changes the meaning of
> typeof(thatfunc) but otherwise it does nothing.
>
> However, if you use it in a base class, you must also use it when
> overriding the function.

Yeah, it's pretty common for folks to slap @property on functions to make it
clear that it's intended to be used as a property and thus is a getter or
setter. So, it serves a purpose from the standpoint of documentation. But at
this point, it doesn't make much differently on the technical level. The
differences with typeof and stuff like std.traits.FunctionAttributes are
what would be different. You can use the property syntax whether @property
was used or not.

The history of @property is a bit of a mess. It was an attempt to move away
from the ad-hoc situation with anything being treated as a property if it
had a signature that worked with one (e.g. something like writeln = 7; is
legal), but for various reasons, it never worked out, and we got a partial
transition with @property ultimately being mostly for documentation
purposes.

One place where this is truly a technical problem rather than a stylistic
one is property functions that return callables, since if you try and call
them with parens, you end up just calling the property function (whether
it's marked with @property or not), and you need a second set of parens to
actually call the callable, meaning that it doesn't actually work as a
property. So, @property _might_ be changed at some point in the future to
fix that problem, but given how long it's been the way that it is, there's a
good chance that we're just stuck with how it is, and it's going to do
pretty much nothing on a technical level except cause some corner case
weirdness with typeof and be detectable by introspection. It does serve as
documentation though, which I think is a lot of why many folks who know full
well what the whole situation with properties is continue to use it.

- Jonathan M Davis

Re: Range of uncopyable elements

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, December 08, 2016 20:21:41 Jerry via Digitalmars-d-learn wrote:
> Assuming that is wrong though, as you aren't copying an iterator
> or range you are copying the actual value. What you are confusing
> "auto h = r.front;" for is this: "auto rcopy = r;". The D code
> "auto h = r.front" is not a cheap operation and the equivalent in
> C++ is actually this: "auto h = *iterator;" and one should not
> assume it is cheap, cause it isn't. Anyways your comparison with
> C++ is off.

His comparison with C++ is off, because front isn't analogous to an
iterator. It's analagous to dereferencing an iterator. However, at least as
of C++98, non-copyable elements in a container were not allowed IIRC, so it
would have been pretty rare to have a C++ iterator that returned a
non-copyable value when you dereferenced it. Also, it pretty much _is_
assumed that

auto h = r.front;

is cheap, and there are plenty of cases where calling front multiple times
for the same range would incur additional overhead, because front is
calculated rather than simply returning a value (e.g. this is what happens
with map). So, it could be a definite performance hit in general to start
insisting that r.front be called without the value being assigned somewhere.
Part of the problem here is that in some cases, it's more efficient to call
front multiple times, whereas in others it's more efficient to call it once.
But since most ranges do not have their front or back return by ref (and
many cannot), it's going to be more efficient to call front only once for
most ranges.

Also, consider that the way that foreach works, it _has_ to be able to copy
front unless it's used with ref - and since most ranges do not have a front
that returns by ref, most ranges will not compile with a ref foreach
variable, and generic code would fall completly flat on its face if it tried
to use foreach with a range and made the foreach variable ref, whereas
that's exactly what would be required for a range of non-copyable elements.
Even if it were allowed, a range of non-copyable elements would not play
nicely with the same code that a normal range would work with, resulting in
a lot more conditional compilation from stuff like function overloading and
static ifs in order to make the code work for both. So, allowing ranges of
non-copyable types would tend to complicate code considerably - either that
or a lot of template constraints would just do something like
hasCopyableFront!R, making it so that ranges of non-copyable elements still
really didn't work.

Yes, not allowing copyable elements for ranges is a problem. But allowing
them would also be a big problem.

What we should ultimately do about it, I don't know, but I think that it's
pretty clear that the majority of code would be better off if non-copyable
elements for ranges were not allowed. And it _is_ possible to work around
the problem by doing as H.S. Teoh suggested and using ranges of pointers.

- Jonathan M Davis

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

I just wanted to post another performance comparision that does 
not test dmd's memory allocator more then anything else :)


[root@localhost dmd]# time src/dmd -c testSettingArrayLength.d  
-bc-ctfe

2147385345u
536821761u
4294639619u

real0m0.114s
user0m0.110s
sys 0m0.003s
[root@localhost dmd]# time src/dmd -c testSettingArrayLength.d
2147385345u
536821761u
4294639619u

real0m0.921s
user0m0.843s
sys 0m0.077s

Results are obtained running the following code
uint MakeInitAndSumArray(uint length)
{
uint result;
uint[] arr;
arr.length = length;

while(length--)
{
arr[length] = length;
}
foreach(e;arr)
{
  result += e;
}

return result;
}

pragma(msg, MakeInitAndSumArray(ushort.max));
pragma(msg, MakeInitAndSumArray(ushort.max/2));
pragma(msg, MakeInitAndSumArray(ushort.max*2));

[Issue 13429] icmp (and friends) should be @nogc

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/40787cee7f3ab4a3c747d47124e614d7b30cbbf1
Issue 13429: make sicmp and icmp @nogc nothrow

https://github.com/dlang/phobos/commit/5c770fba084a5e7addfaf65ab6deb36584ee2fd7
Merge pull request #4933 from sprinkle131313/master

Issue 13429: make sicmp and icmp @nogc nothrow.

--

Re: Tutorial: Form upload in vibe.d

[NVolcz via Digitalmars-d-announce]

On Tuesday, 6 December 2016 at 22:28:04 UTC, aberba wrote:

https://aberba.github.io/2016/form-upload-in-vibe-d/u


Love the article! Please keep writing tutorials like this :-D.

Feedback:
1.
The upload function is (kind of) vulnerable against path 
traversal:
  moveFile(file.tempPath, Path("./public/uploads") ~ 
file.filename);


If a file named "../SomeOtherFile.htm" is uploaded the server 
will hit this assert:

https://github.com/rejectedsoftware/vibe.d/blob/master/core/vibe/core/path.d#L426
Denail of Service attack!

When the application is compiled with the release flag the assert 
will be omitted and the path traversal will work.


2.
It would be more beginner friendly if you also described how to 
add the upload function to the router.


3.
Your github link on the left side is broken. Discovered this when 
I was looking for a zip with the finished code.

Re: Hosting vibe.d on OpenShift

[Tiberiu Gal via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 14:03:35 UTC, aberba wrote:
I would like to try vibe.d with mongoDB on OpenShit. I managed 
to do that on Heroku. Do I need a buildpack like vibe.d?


Any help will be really appreciated.


I've tried to create a vibe cartridge but cannot because of 
memory limitations.
The easiest way: You should build locally and deploy the 
executable

Re: Range of uncopyable elements

[Jerry via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 17:29:42 UTC, H. S. Teoh wrote:
The problem is that most range algorithms won't work if `auto h 
= r.front;` doesn't compile.  Random chunks of std.algorithm 
won't work for such a range.


One may argue, of course, that std.algorithm ought to be 
fixed... but the root of the problem really is a conceptual 
one. The definition of a range was made as an extension of a 
C++ iterator, which is basically a wrapped pointer. So `auto h 
= r.front;` is assumed to be a cheap copy of a *reference* to 
the underlying data, rather than copying the data itself. This 
is why most of std.algorithm is written the way it is, and why 
isInputRange is defined the way it is.  A range of non-copyable 
elements in this sense is a poor fit for the range concept; a 
better fit would be a range of references to an underlying 
container of non-copyable elements. Hence my suggestion of 
using pointers.


(In any case, conflating a range with a container is usually a 
red flag that there's a conceptual mismatch somewhere. 
Unfortunately built-in arrays aren't helping by hiding the fact 
that the container is actually GC-managed memory, which isn't 
directly visible to the user, thus perpetuating the 
misconception that range == container.)



T


Well it's exactly like that for C++ as well. std::copy(Iter, ...) 
won't compile if the values aren't copyable. There's no 
constraints in C++ either so you get some cryptic error message. 
The entire std library is like that.


Assuming that is wrong though, as you aren't copying an iterator 
or range you are copying the actual value. What you are confusing 
"auto h = r.front;" for is this: "auto rcopy = r;". The D code 
"auto h = r.front" is not a cheap operation and the equivalent in 
C++ is actually this: "auto h = *iterator;" and one should not 
assume it is cheap, cause it isn't. Anyways your comparison with 
C++ is off.

Re: How about a bounty for a new windows installer using inno setup ?

[Jesse Phillips via Digitalmars-d]

On Thursday, 8 December 2016 at 11:03:07 UTC, Thomas Mader wrote:
I think you might be right about using WiX. MSI seems to be 
build upon transactional installation.
Do you think it would be possible to use D instead of C++ to 
write custom code?


Short answer is yes, I've created such and actually inject my 
custom DLL for testing purposes.


MSI's are pretty awkward, no one knows how to create the MSI 
database instead there are 3 example databases provided which you 
can merge together if you desire that feature. From there the 
Database consists of tables which layout the installation 
sequence along with the installation sequence for the GUI. These 
sequences can call "Custom Actions" which are just table entries 
that point to a DLL (there is more to Custom Actions).


The signature looks something like below. I've got a little 
wrapper around the MSIHANDLE so as to add some safety and 
convenience.


   extern(Windows):
   export uint MyCustomActionName(const MsiLiveHandle hModule) {

I'm not too familiar with WIX and the exposure I've had is with 
older versions (3.x) which have had annoying and weird bugs. D 
certainly could be used to create the D MSI installer, but that 
is even lower level than WIX.

d***@*******

[85 Windsor via Digitalmars-d]

d***@***

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Thursday, 8 December 2016 at 19:13:23 UTC, Stefan Koch wrote:

I found the biggest performance bottleneck in newCTFE!

oldCtfe :
[root@localhost dmd]# time src/dmd -c ctfeTest.d testStringEq.d 
testStringLength.d testStruct.d testMultipleArrayLiterals.d


real0m0.026s
user0m0.020s
sys 0m0.003s


Before Fixing :
[root@localhost dmd]# time src/dmd -c ctfeTest.d testStringEq.d 
testStringLength.d testStruct.d testMultipleArrayLiterals.d 
-bc-ctfe


real0m0.025s
user0m0.020s
sys 0m0.003s

After Fixing

[root@localhost dmd]# time src/dmd -c ctfeTest.d testStringEq.d 
testStringLength.d testStruct.d testMultipleArrayLiterals.d  
-bc-ctfe


real0m0.019s
user0m0.017s
sys 0m0.000s


Please note that the ctfe interpretation, with newCTFE, inside 
the frontend takes 10% of the compilation time

Whereas with the old interpreter it takes 50%

Re: CTFE Status

[Faux Amis via Digitalmars-d]

Any reason for the infinite depth update posting style?
I would have loved to see each update to be a child of the root post 
with its own discussions tree.

Currently, the posts are quite unreadable in tree view (thunderbird).


On 2016-10-31 14:29, Stefan Koch wrote:

Hi Guys, since I got a few complaints about giving minor status updates
in the announce group, I am opening this thread.

Re: How about a bounty for a new windows installer using inno setup ?

[Jim Hewes via Digitalmars-d]

On 12/8/2016 3:03 AM, Thomas Mader wrote:


Do you think it would be possible to use D instead of C++ to write
custom code?


Custom code where? During the process of building the installation 
package or during installation itself. Anyway, in either case I don't 
see why not. You can insert a DLL into an MSI file. Then at some point 
during installation that you specify, the DLL will be extracted and an 
arbitrary function in it called. So any language that can generate a DLL 
will work there.

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

I found the biggest performance bottleneck in newCTFE!

oldCtfe :
[root@localhost dmd]# time src/dmd -c ctfeTest.d testStringEq.d 
testStringLength.d testStruct.d testMultipleArrayLiterals.d


real0m0.026s
user0m0.020s
sys 0m0.003s

[root@localhost dmd]# time src/dmd -c ctfeTest.d testStringEq.d 
testStringLength.d testStruct.d testMultipleArrayLiterals.d 
-bc-ctfe


real0m0.025s
user0m0.020s
sys 0m0.003s

After Fixing

[root@localhost dmd]# time src/dmd -c ctfeTest.d testStringEq.d 
testStringLength.d testStruct.d testMultipleArrayLiterals.d  
-bc-ctfe


real0m0.019s
user0m0.017s
sys 0m0.000s

Re: Templating Function Names

[Ali Çehreli via Digitalmars-d-learn]

On 12/08/2016 10:21 AM, Bryce Kellogg wrote:

> It should look like Foo always had a property named after their 
custom Component.


opDispatch?

  https://dlang.org/spec/operatoroverloading.html#dispatch

Ali

Templating Function Names

[Bryce Kellogg via Digitalmars-d-learn]

Say I've got a bunch of classes that inherit from a common 
interface (in this case Component) and a class Foo that can 
handle any subclass of Component. Like so:


interface Component { ... }
class A : Component { ... }
class B : Component { ... }
class C : Component { ... }

class Foo {
alias a = this.of!A;
alias b = this.of!B;
alias c = this.of!C;
void of(T : Component)(T t) { ... }
}

It's pretty trivial to access a specific component using regular 
templates:


f.of!A = new A();
f.of!B = new B();
f.of!C = new C();

And I can alias the instantiations of these templates as seen 
above for a cleaner interface:


f.a = new A();
f.b = new B();
f.c = new C();

However, suppose I have the following situation:

void main() {
Foo f = new Foo();
class D : Component { ... }

f.of!D = new D(); // works fine
f.d = new D();// fails to compile (for obvious reason)
}

Is there a way I can get a function of Foo named after D (like 
f.d() or f.D()) without knowing before hand every single subclass 
of Component and adding aliases manually?


For example, is there a way to template the name of the function 
or an alias like:


void T(T : Component)(T t) { ... }
or
alias T = this.of!T;

Both of these just gave me functions named T.

The important thing is that it's transparent to the person 
creating a new subclass of Component. It should look like Foo 
always had a property named after their custom Component.


Is this possible?

Thanks!
Bryce

[Issue 16699] [REG 2.070] stack corruption with scope(exit)

[via Digitalmars-d-bugs]

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

--- Comment #30 from Steven Schveighoffer  ---
(In reply to Ketmar Dark from comment #29)
> ok, i'm giving up. if inability to merge master is simply dismissed with
> "this is not a typical occurence" excuse, i have nothing else to say.

For instance: https://github.com/dlang/dmd/pull/5792

This is typical.

--

[Issue 16699] [REG 2.070] stack corruption with scope(exit)

[via Digitalmars-d-bugs]

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

--- Comment #29 from Ketmar Dark  ---
ok, i'm giving up. if inability to merge master is simply dismissed with "this
is not a typical occurence" excuse, i have nothing else to say.

--

Re: OT: Tiobe Index - December Headline: What is happening to good old language C?

[Anonymouse via Digitalmars-d]

On Thursday, 8 December 2016 at 13:19:31 UTC, Meta wrote:

On Thursday, 8 December 2016 at 08:46:07 UTC, Nordlöw wrote:

On Tuesday, 6 December 2016 at 07:40:44 UTC, Nick B wrote:

source: http://www.tiobe.com/tiobe-index/   (Dec 2016)


Glad to see D at 21. I believe this an improvement compared to 
previous year. Does anybody got any hard numbers for this?


Actually I think D has slipped. I believe it used to be at 18, 
but I can't remember when that was.


It's nice to see D in the ballpark of 1%+. That said, I also 
think the whole index should be taken with more than one grain of 
salt. Sources and metrics. Lies, damned lies and statistics.


As their disclaimer says, it's the languages most mentioned and 
with the most search hits that score the highest, not the most 
used. Maybe it was particularly high when dconf coverage 
circulated reddit and HN.

Re: Range of uncopyable elements

[H. S. Teoh via Digitalmars-d-learn]

On Thu, Dec 08, 2016 at 05:22:25PM +, Jerry via Digitalmars-d-learn wrote:
> On Thursday, 8 December 2016 at 16:48:07 UTC, H. S. Teoh wrote:
> > On Thu, Dec 08, 2016 at 04:35:02PM +, Jerry via Digitalmars-d-learn
> > wrote:
> > > The problem is with how isInputRange is defined, requires that
> > > front be copyable.
> > > 
> > > auto h = r.front; // can get the front of the range
> > > 
> > > https://github.com/dlang/phobos/blob/v2.072.1/std/range/primitives.d#L168
> > > 
> > > It doesn't take into consideration that front exists and that it's
> > > a reference to a struct that can't be copied. There was a
> > > discussion a while back to change it but it seems nothing came of
> > > it.
> > 
> > A possible workaround, which is somewhat ugly but should work, is to
> > have the range return pointers to the elements instead of the
> > elements themselves. For the most part, this should be mostly
> > transparent because the . operator automatically dereferences.
> > 
> > 
> > T
> 
> It's not something that you should have to workaround, isInputRange is not
> defined properly and should be fixed. You end up complicating your code for
> no reason other than isInputRange is poorly defined.

The problem is that most range algorithms won't work if `auto h =
r.front;` doesn't compile.  Random chunks of std.algorithm won't work
for such a range.

One may argue, of course, that std.algorithm ought to be fixed... but
the root of the problem really is a conceptual one. The definition of a
range was made as an extension of a C++ iterator, which is basically a
wrapped pointer. So `auto h = r.front;` is assumed to be a cheap copy of
a *reference* to the underlying data, rather than copying the data
itself. This is why most of std.algorithm is written the way it is, and
why isInputRange is defined the way it is.  A range of non-copyable
elements in this sense is a poor fit for the range concept; a better fit
would be a range of references to an underlying container of
non-copyable elements. Hence my suggestion of using pointers.

(In any case, conflating a range with a container is usually a red flag
that there's a conceptual mismatch somewhere. Unfortunately built-in
arrays aren't helping by hiding the fact that the container is actually
GC-managed memory, which isn't directly visible to the user, thus
perpetuating the misconception that range == container.)


T

-- 
What did the alien say to Schubert? "Take me to your lieder."

Re: Range of uncopyable elements

[Jerry via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 16:48:07 UTC, H. S. Teoh wrote:
On Thu, Dec 08, 2016 at 04:35:02PM +, Jerry via 
Digitalmars-d-learn wrote:
The problem is with how isInputRange is defined, requires that 
front be copyable.


auto h = r.front; // can get the front of the range

https://github.com/dlang/phobos/blob/v2.072.1/std/range/primitives.d#L168

It doesn't take into consideration that front exists and that 
it's a reference to a struct that can't be copied. There was a 
discussion a while back to change it but it seems nothing came 
of it.


A possible workaround, which is somewhat ugly but should work, 
is to have the range return pointers to the elements instead of 
the elements themselves. For the most part, this should be 
mostly transparent because the . operator automatically 
dereferences.



T


It's not something that you should have to workaround, 
isInputRange is not defined properly and should be fixed. You end 
up complicating your code for no reason other than isInputRange 
is poorly defined.

[Issue 16699] [REG 2.070] stack corruption with scope(exit)

[via Digitalmars-d-bugs]

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

--- Comment #28 from Steven Schveighoffer  ---
ketmar, since 11 days ago, merge from stable to master has been created.
However, there is some issue (which I admittedly have no understanding of), and
when that issue is resolved, this will be in master.

I still think the process as-is is what we should have. This is not a typical
occurrence, usually stable->master PRs are merged in a day.

--

[Issue 16699] [REG 2.070] stack corruption with scope(exit)

[via Digitalmars-d-bugs]

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

--- Comment #27 from Ketmar Dark  ---
oops. you provided PR that doesn't belong to this thread, and i didn't checked
it properly. still, my point stands. ;-)

--

[Issue 16699] [REG 2.070] stack corruption with scope(exit)

[via Digitalmars-d-bugs]

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

--- Comment #26 from Ketmar Dark  ---
and now we have this "fix" in *stable*! do you still think that "nothing should
be changed"? for me, this issue clearly indicates that something is *very*
broken in the current scheme.

--

Re: @property

[Adam D. Ruppe via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 16:53:13 UTC, Satoshi wrote:

is there any advantage of marking function as @property??


Not really. I think it just changes the meaning of 
typeof(thatfunc) but otherwise it does nothing.


However, if you use it in a base class, you must also use it when 
overriding the function.

Re: Range of uncopyable elements

[H. S. Teoh via Digitalmars-d-learn]

On Thu, Dec 08, 2016 at 04:35:02PM +, Jerry via Digitalmars-d-learn wrote:
> The problem is with how isInputRange is defined, requires that front
> be copyable.
> 
> auto h = r.front; // can get the front of the range
> 
> https://github.com/dlang/phobos/blob/v2.072.1/std/range/primitives.d#L168
> 
> It doesn't take into consideration that front exists and that it's a
> reference to a struct that can't be copied. There was a discussion a
> while back to change it but it seems nothing came of it.

A possible workaround, which is somewhat ugly but should work, is to
have the range return pointers to the elements instead of the elements
themselves. For the most part, this should be mostly transparent because
the . operator automatically dereferences.


T

-- 
Designer clothes: how to cover less by paying more.

@property

[Satoshi via Digitalmars-d-learn]

Hello,
is there any advantage of marking function as @property??


class Foo {
void objectValue(Object value) { }
Object objectValue() { }
}



auto foo = new Foo;

// This works fine without @property attribute
foo.objectValue = null;
auto bar = foo.objectValue;

[Issue 16699] [REG 2.070] stack corruption with scope(exit)

[via Digitalmars-d-bugs]

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

--- Comment #25 from Steven Schveighoffer  ---
Looks like there is a snag: https://github.com/dlang/dmd/pull/6287

--

Re: Range of uncopyable elements

[Jerry via Digitalmars-d-learn]

The problem is with how isInputRange is defined, requires that 
front be copyable.


auto h = r.front; // can get the front of the range

https://github.com/dlang/phobos/blob/v2.072.1/std/range/primitives.d#L168

It doesn't take into consideration that front exists and that 
it's a reference to a struct that can't be copied. There was a 
discussion a while back to change it but it seems nothing came of 
it.

Range of uncopyable elements

[RazvanN via Digitalmars-d-learn]

Hi,

I am trying to create a range with uncopyable elements. My 
thought process was the following:


1.I have created a struct :

struct S
{
int a;

@disable this(this);
}

2. I declared an array :

S[] arr = [S(1), S(2), S(3)];

expecting that arr will be a range like, for example, an int[].
I was surprised to see that isInputRange!arr is false.

So, is there any possibility to create a range with uncopyable 
elements?

[Issue 7115] sort function is broken with large arrays

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

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

--

[Issue 7996] Refuse std.math.isnan() on not floating point values?

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

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

--

Re: [OT] Interesting blog post on disadvantages of the pure functional paradigm

[Stefan Koch via Digitalmars-d]

On Thursday, 8 December 2016 at 13:40:21 UTC, Andrei Alexandrescu 
wrote:

http://flyingfrogblog.blogspot.com/2016/05/disadvantages-of-purely-functional.html
 -- Andrei


Great Find! Thanks for sharing it.

This article expresses in nice words what is wrong with 
mono-paradigm languages.

Performance always has to yield to the Paradigm.

Re: [Semi-OT] I don't want to leave this language!

[Ilya Yaroshenko via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 09:57:21 UTC, Guillaume Piolat 
wrote:
On Wednesday, 7 December 2016 at 12:12:56 UTC, Ilya Yaroshenko 
wrote:


R, Matlab, Python, Mathematica, Gauss, and Julia use C libs. 
--Ilya


As a C lib, you have the possibility of not initializing the 
runtime, which leaves usable a part of phobos+druntime and it's 
only a matter of avoiding TLS/globals and global ctor/dtor. No 
need to rewrite druntime this way.

https://www.auburnsounds.com/blog/2016-11-10_Running-D-without-its-runtime.html

-betterC is cleaner (link errors) but give more work.


Link requirement is problem too. A numeric library for the 
language list above will never be accepted if this library 
depends on huge non portable runtime like D has. --Ilya

Re: Should we warn if we detect null derefernces or void value uses ?

[Stefan Koch via Digitalmars-d]

On Thursday, 8 December 2016 at 08:52:45 UTC, qznc wrote:

On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote:
 This requires data-flow analysis (The same kind that tells 
you if you are skipping a statement)
And will slow down compilation a little if we enable such a 
warning.



I would rather see a separate tool for stuff like this. It can 
be much slower and do much more analysis.


Compare: clang-analyzer http://clang-analyzer.llvm.org/


Due to D's stronger focus on correctness,
something like the clang static analyzer has importance in D then 
it has in C++.


Also If we don't stick to unambiguous errors, there will be a LOT 
of false positives.

Re: [Semi-OT] I don't want to leave this language!

[Radu via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote:
what can be done, tho, is article (or series of articles) 
describing what exactly druntime is, how it is compared to libc 
and libc++, why it doesn't hurt at all, how to do "bare metal" 
with custom runtime, why GC is handy (and how to limit GC 
impact if that is necessary), and so on. that is something D 
Foundation should do, i believe.


give the man a cigar!

Re: [Semi-OT] I don't want to leave this language!

[Patric Dexheimer via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 12:10:55 UTC, Andrey wrote:

On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote:



what can be done, tho, is article (or series of articles) 
describing what exactly druntime is, how it is compared to 
libc and libc++, why it doesn't hurt at all, how to do "bare 
metal" with custom runtime, why GC is handy (and how to limit 
GC impact if that is necessary), and so on. that is something 
D Foundation should do, i believe.


+1


+1

Re: drepl fails because of missing lib linenoise

[Seb via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 13:03:10 UTC, Edwin van Leeuwen 
wrote:

On Thursday, 8 December 2016 at 12:31:01 UTC, Nordlöw wrote:

drepl fails to build as

https://github.com/drepl/drepl/issues/58

Any ideas why?


Looks like you don't have liblinenoise installed.


... and for the record I just recompiled it with the lastest, 
greatest DMD and it still worked :)


Btw if you also feel that DUB should have a smoother integration 
with C code ->


https://github.com/dlang/dub/issues/852

Some basic notes on how to install on linux/macosx can be found 
here:

https://github.com/BlackEdder/todod#linenoise



For ArchLinux there's also a convenient packages: 
https://aur.archlinux.org/packages/linenoise

Hosting vibe.d on OpenShift

[aberba via Digitalmars-d-learn]

I would like to try vibe.d with mongoDB on OpenShit. I managed to 
do that on Heroku. Do I need a buildpack like vibe.d?


Any help will be really appreciated.

[Issue 16959] New: bringToFront fails on char arrays

[via Digitalmars-d-bugs]

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

  Issue ID: 16959
   Summary: bringToFront fails on char arrays
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ola...@gmail.com

The following code, which is the first example in the docs for
std.algorithm.mutation.bringToFront, but using a char array instead of an int
array:

-- bringToFront.d --
import std.algorithm : bringToFront;

void main(string[] args)
{
  auto arr = ['4', '5', '6', '7', '1', '2', '3'];
  auto p = bringToFront(arr[0 .. 4], arr[4 .. $]);
  assert(p == arr.length - 4);
  assert(arr == ['1', '2', '3', '4', '5', '6', '7']);
}
-- end of file --

fails on compilation with this:

..\src\phobos\std\algorithm\mutation.d(2553): Error: front(r1) is not an lvalue
..\src\phobos\std\algorithm\mutation.d(2554): Error: front(r2) is not an lvalue
..\src\phobos\std\algorithm\mutation.d(134): Error: template instance
std.algorithm.mutation.swapFront!(char[], char[]) error instantiating
bringToFront.d(10):instantiated from here: bringToFront!(char[],
char[])
..\src\phobos\std\algorithm\mutation.d(2553): Error: function
std.range.Take!(char[]).Take.front () is not callable using argument types
(dchar)
..\src\phobos\std\algorithm\mutation.d(2554): Error: front(r2) is not an lvalue
..\src\phobos\std\algorithm\mutation.d(134): Error: template instance
std.algorithm.mutation.swapFront!(Take!(char[]), char[]) error instantiating
..\src\phobos\std\algorithm\mutation.d(163):instantiated from here:
bringToFront!(Take!(char[]), char[])
bringToFront.d(10):instantiated from here: bringToFront!(char[],
char[])

Compiled with rdmd, using dmd v2.072.0

--

[OT] Interesting blog post on disadvantages of the pure functional paradigm

[Andrei Alexandrescu via Digitalmars-d]

http://flyingfrogblog.blogspot.com/2016/05/disadvantages-of-purely-functional.html 
-- Andrei

dconf.org: Merge conflict marker in the banner?

[Nicholas Wilson via Digitalmars-d]

lines 23-28 of index.html

<<< 08a5395ead0589eb18e62d3b420781bfa5b0f3e2
  alt="DConf 2017: May 46  Berlin" height="116" 
border="0" />

===


Fix year from 2016 to 2017

[Issue 16798] Extend -Ipath switch to -Imodule=path so path heirarchy doesn't have to match package heirarchy

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/1e77dfac5e4e8564fa8eef4f3184f41b0cd31768
fix Issue 16798 - Extend -Ipath switch to -Imodule=path so path heirarchy
doesn't have to match package heirarchy

https://github.com/dlang/dmd/commit/72b20335f9dd47fc88d6a6c92ef312f0b5f81392
Merge pull request #6286 from WalterBright/fix16798

fix Issue 16798 - add -mv=path.module=filespec switch so path hiera…

--

[Issue 16798] Extend -Ipath switch to -Imodule=path so path heirarchy doesn't have to match package heirarchy

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: OT: Tiobe Index - December Headline: What is happening to good old language C?

[Meta via Digitalmars-d]

On Thursday, 8 December 2016 at 08:46:07 UTC, Nordlöw wrote:

On Tuesday, 6 December 2016 at 07:40:44 UTC, Nick B wrote:

source: http://www.tiobe.com/tiobe-index/   (Dec 2016)


Glad to see D at 21. I believe this an improvement compared to 
previous year. Does anybody got any hard numbers for this?


Actually I think D has slipped. I believe it used to be at 18, 
but I can't remember when that was.

Re: drepl fails because of missing lib linenoise

[Edwin van Leeuwen via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 12:31:01 UTC, Nordlöw wrote:

drepl fails to build as

https://github.com/drepl/drepl/issues/58

Any ideas why?


Looks like you don't have liblinenoise installed.

Some basic notes on how to install on linux/macosx can be found 
here:

https://github.com/BlackEdder/todod#linenoise

[Issue 16957] access function from inside template with same name

[via Digitalmars-d-bugs]

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

--- Comment #2 from John Colvin  ---
template a(alias b)
{
alias T = typeof(b);

auto a(T ret)
{
return ret;
}
}

auto a(T, size_t N)(T[N] a) {}  // breaks
// auto a(T)(T[] a) {} // OK

void main()
{
int x;
auto b = a!(x);
}

test.d(5): Error: undefined identifier 'T'
test.d(16): Error: cannot infer type from template instance a!(x)

--

drepl fails because of missing lib linenoise

[Nordlöw via Digitalmars-d-learn]

drepl fails to build as

https://github.com/drepl/drepl/issues/58

Any ideas why?

Re: [Semi-OT] I don't want to leave this language!

[Andrey via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote:



what can be done, tho, is article (or series of articles) 
describing what exactly druntime is, how it is compared to libc 
and libc++, why it doesn't hurt at all, how to do "bare metal" 
with custom runtime, why GC is handy (and how to limit GC 
impact if that is necessary), and so on. that is something D 
Foundation should do, i believe.


+1

Re: [Semi-OT] I don't want to leave this language!

[Chris via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote:

[...]

what can be done, tho, is article (or series of articles) 
describing what exactly druntime is, how it is compared to libc 
and libc++, why it doesn't hurt at all, how to do "bare metal" 
with custom runtime, why GC is handy (and how to limit GC 
impact if that is necessary), and so on. that is something D 
Foundation should do, i believe.


Amen. Features should never become a religion (else you'll get 
Java :).

Re: [Semi-OT] I don't want to leave this language!

[Guillaume Piolat via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 11:32:56 UTC, Paolo Invernizzi 
wrote:

On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote:

what can be done, tho, is article (or series of articles) 
describing what exactly druntime is, how it is compared to 
libc and libc++, why it doesn't hurt at all, how to do "bare 
metal" with custom runtime, why GC is handy (and how to limit 
GC impact if that is necessary), and so on. that is something 
D Foundation should do, i believe.


+1

/Paolo


+1

This is what technical domination is about :) not apologize for 
everything

Re: [Semi-OT] I don't want to leave this language!

[Paolo Invernizzi via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote:

what can be done, tho, is article (or series of articles) 
describing what exactly druntime is, how it is compared to libc 
and libc++, why it doesn't hurt at all, how to do "bare metal" 
with custom runtime, why GC is handy (and how to limit GC 
impact if that is necessary), and so on. that is something D 
Foundation should do, i believe.


+1

/Paolo

Re: [Semi-OT] I don't want to leave this language!

[ketmar via Digitalmars-d-learn]

On Thursday, 8 December 2016 at 10:49:40 UTC, Chris wrote:
The "hard way" (no runtime/Phobos/GC) should not be the default 
and I hope that nobody is seriously suggesting this. It should 
be available in case anyone needs it. I dare doubt, however, 
that C/C++ programmers will take to D like ducks take to water 
because of it.


especially considering that nobody in c++ land really talking 
about "we should drop c++ runtime". yes, in case somebody doesn't 
know, c++ also has runtime. and c too, by the way.


some people in c++ land avoiding using c++ features that require 
runtime (stl, rtti, etc.), but majority of programmers are ok 
with runtime. the very same is true for D. saying that "D will be 
more attractive to C++ programmers if we will remove runtime" 
is... i can't even find a word to describe it.


what can be done, tho, is article (or series of articles) 
describing what exactly druntime is, how it is compared to libc 
and libc++, why it doesn't hurt at all, how to do "bare metal" 
with custom runtime, why GC is handy (and how to limit GC impact 
if that is necessary), and so on. that is something D Foundation 
should do, i believe.

Re: How about a bounty for a new windows installer using inno setup ?

[Thomas Mader via Digitalmars-d]

On Wednesday, 7 December 2016 at 23:00:13 UTC, Jim Hewes wrote:

On 12/6/2016 10:31 PM, Thomas Mader wrote:


The update case could be better supported by Inno by default 
though I
don't know how to really do it transactionally/atomic. Once 
everything
is on the drive, how would you be able to switch from the old 
directory

to the new one with one atomic action under Windows?



I liked WiX because it was down to the metal and I don't think 
there's anything you can't do. With other tools (like 
InstallShield) I spent too much time trying to get the tool to 
do something I could have done really easy at the low level if 
I could've just gotten to it. But granted, for simpler install 
situations the scripting tools can work OK and have a smaller 
learning curve.


Jim


I think you might be right about using WiX. MSI seems to be build 
upon transactional installation.
Do you think it would be possible to use D instead of C++ to 
write custom code?

Re: OT: Tiobe Index - December Headline: What is happening to good old language C?

[Claude via Digitalmars-d]

It's strange to see "assembly language" as an entry, the target 
is not specified, so I suppose it includes them all, and is more 
a way of programming. It would be interesting to see which target 
(x86, ARM?) are the most used.

Re: [Semi-OT] I don't want to leave this language!

[Chris via Digitalmars-d-learn]

On Wednesday, 7 December 2016 at 16:43:54 UTC, bachmeier wrote:

On Wednesday, 7 December 2016 at 16:15:32 UTC, Chris wrote:
I don't understand this discussion at all. Why not have both? 
I don't need bare metal stuff at the moment but I might one 
day, and I perfectly understand that people may need it. At 
the same time, there are people who are happy with 
runtime/Phobos/GC. In my opinion it's not a question of 
"either or" but of "both and".


I can only speak for myself, but the concern is that we'll move 
in the direction of Rust, where you're supposed to read a 
dissertation on memory management before writing "Hello, 
World". The current state of affairs should be the default. 
Those with more advanced uses in mind should be able to do what 
they need, but it should be done without pushing away non-hard 
core developers.


The "hard way" (no runtime/Phobos/GC) should not be the default 
and I hope that nobody is seriously suggesting this. It should be 
available in case anyone needs it. I dare doubt, however, that 
C/C++ programmers will take to D like ducks take to water because 
of it. It's been said time and time again that D's mission is no 
longer to convert C/C++ programmers ("a better C++") but to 
provide a good tool for programming. I think D still suffers from 
the slogan that it's "a better C++". Bad marketing, because 
you'll always be compared to C++. Imagine you date a woman and 
tell her "I'm a better your ex-boyfriend/ex-husband".

[Issue 16951] trying to call opCall with alias opCall this, without parentesis fails to compile, when used as a single statement

[via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Hardware|x86_64  |All
 Resolution|--- |MOVED
 OS|Linux   |All

--- Comment #1 from anonymous4  ---
Addressed by https://wiki.dlang.org/DIP23

--

Re: [Semi-OT] I don't want to leave this language!

[Guillaume Piolat via Digitalmars-d-learn]

On Wednesday, 7 December 2016 at 12:12:56 UTC, Ilya Yaroshenko 
wrote:


R, Matlab, Python, Mathematica, Gauss, and Julia use C libs. 
--Ilya


As a C lib, you have the possibility of not initializing the 
runtime, which leaves usable a part of phobos+druntime and it's 
only a matter of avoiding TLS/globals and global ctor/dtor. No 
need to rewrite druntime this way.

https://www.auburnsounds.com/blog/2016-11-10_Running-D-without-its-runtime.html

-betterC is cleaner (link errors) but give more work.

Re: How about a bounty for a new windows installer using inno setup ?

[Thomas Mader via Digitalmars-d]

On Wednesday, 7 December 2016 at 23:00:13 UTC, Jim Hewes wrote:

On 12/6/2016 10:31 PM, Thomas Mader wrote:


The update case could be better supported by Inno by default 
though I
don't know how to really do it transactionally/atomic. Once 
everything
is on the drive, how would you be able to switch from the old 
directory

to the new one with one atomic action under Windows?



I'm not sure what you mean by switch the directory. If you mean 
that the update uses a different directory for the program than 
the original, then you can probably just use a "major" upgrade. 
Windows Installer has the idea of minor upgrade and major 
upgrade. (So, it's independent of whatever tools your using.) A 
minor upgrade just updates the files that have changed. A major 
upgrade essentially removes the original product totally and 
installs the new one. Some people even use a major upgrade for 
_every_ new version just to avoid problems that might occur 
with a minor upgrade.


The Update is triggered by the application itself. If the install 
fails or is Canceled in the middle the application can not start 
anymore and so the user needs to do something manually.
It would be possible to update everything into a new directory 
and after everything is done just exchange the stuff in the 
already installed directory with the new update directory.

But even this operation isn't atomic even though it's much better.
What might work is to make it work like the Nix package manager.
NixOS (Nix Package manager) provides atomic updates because the 
entire system environment is build by links. Replacing a version 
with another one is just a matter of changing the link to the 
proper directory.


So in Windows you could do it the same. Install versions in 
separate directories. The installation directory is linking to 
the appropriate version directory. On update just install to new 
version directory and after everything is done just update the 
installation directory link to the new update directory.
No matter what happens either the old or the new application 
version should be workable.

Re: Should we warn if we detect null derefernces or void value uses ?

[qznc via Digitalmars-d]

On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote:
 This requires data-flow analysis (The same kind that tells you 
if you are skipping a statement)
And will slow down compilation a little if we enable such a 
warning.



I would rather see a separate tool for stuff like this. It can be 
much slower and do much more analysis.


Compare: clang-analyzer http://clang-analyzer.llvm.org/

Re: OT: Tiobe Index - December Headline: What is happening to good old language C?

[Nordlöw via Digitalmars-d]

On Tuesday, 6 December 2016 at 07:40:44 UTC, Nick B wrote:

source: http://www.tiobe.com/tiobe-index/   (Dec 2016)


Glad to see D at 21. I believe this an improvement compared to 
previous year. Does anybody got any hard numbers for this?

Re: OT: Tiobe Index - December Headline: What is happening to good old language C?

[Nordlöw via Digitalmars-d]

On Wednesday, 7 December 2016 at 09:12:39 UTC, piotrklos wrote:

Smaller reason:
C is being replaced in some applications by Go, D and C++.


And most likely also Rust.

[Issue 16699] [REG 2.070] stack corruption with scope(exit)

[via Digitalmars-d-bugs]

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

--- Comment #24 from Ketmar Dark  ---
so, time is passing on. nothing was merged to master. versions diverges more
and more. definitely, the system works just fine. i can't see nothing that
should be changed in the way things works now.

--

Re: Tutorial: Form upload in vibe.d

[aberba via Digitalmars-d-announce]

On Thursday, 8 December 2016 at 00:44:19 UTC, Sönke Ludwig wrote:

Am 06.12.2016 um 23:28 schrieb aberba:

https://aberba.github.io/2016/form-upload-in-vibe-d/


Nice article, I'll add this to the tutorials section [1]. Two 
additional suggestions:


- It's probably a good idea to mention that 
HTTPServerSettings.maxRequestSize is 2 MiB by default and 
should be increased if larger files are expected


- The last snippet with "static this()" (using "shared static 
this" would be better to avoid issues in multi-threaded 
applications) doesn't contain the /upload route, but it's 
probably better to have it either there or later within the 
text, as it may not be obvious how to register that exactly


[1]: https://vibed.org/tutorials


Done! Thanks for the feedback.

[Issue 16705] [REG2.069] TaskPool.reduce fails to compile "cannot get frame pointer to D main"

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--

Re: Multiple producer - multiple consumer with std.concurrency?

[Christian Köstlin via Digitalmars-d-learn]

Hi Ali,

Thanks for the input, will read about this.
About the slowness. I think it also depends on the situation.
Sure, every message from all producers/consumers has to go through one
MessageBox, but, that is a small critical section, if the work for
producing and consuming takes long enough, the contention is not so
important (for small desktop sized problems). I would still be able to
stress all my cores :)

About a single dispatcher: Why not. But the dispatcher would have to
keep track (manually) of tasks to do and unoccupied workers. While this
is for sure possible, simply sharing the MessageBox would be a great
solutions I think. Looking into std.concurrency, it seems that it should
be possible to provide another spawn function, that takes an additional
MessageBox parameter that is then used for creating the Tid (given that
get and put on MessageBox are threadsafe).

What do you think?

Christian

On 08/12/2016 00:06, Ali Çehreli wrote:
> The simplest idea is to have a single dispatcher thread that distributes
> to consumers. However, both that and other shared mailbox designs are
> inherently slow due to contention on this single mailbox.
> 
> Sean Parent's "Better Code: Concurrency" presentation does talk about
> that topic and tells how "task stealing" is a solution.
> 
> There are other concurrency models out there like the Disruptor:
> 
>   https://lmax-exchange.github.io/disruptor/
> 
> It's a very interesting read but I don't know how it can be done with
> Phobos. It would be awesome if D had that solution.
> 
> Ali
>