[Issue 16652] New: returned rvalue gets destroyed before expressions ends

[via Digitalmars-d-bugs]

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

  Issue ID: 16652
   Summary: returned rvalue gets destroyed before expressions ends
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
import std.stdio;

struct Vector
{
ubyte[] opSlice()
{
writeln("opslice");
return buf[];
}

~this()
{
writeln("dtor");
}

ubyte[4] buf;
}

void bar(ubyte[])
{
writeln("bar");
}

void main()
{
bar(Vector()[]);
}
CODE
dmd -inline -run bug
---
opslice
dtor <- !!! destroyed
bar <- stale reference
---

The order of evaluation changes when -inline is passed to the compiler. With
that the destructor runs before the function call finishes, thus possibly
passing a stale reference.

Also see https://github.com/rejectedsoftware/vibe.d/pull/1578 and
https://github.com/etcimon/botan/issues/23.

--

Re: Minimizing "reserved" words

[ketmar via Digitalmars-d]

On Monday, 31 October 2016 at 20:45:56 UTC, Jacob Carlborg wrote:
In the latest release of DMD (2.072.0) TypeInfo.init has been 
deprecate in favor of TypeInfo.initializer. That would not have 
been needed if .init wasn't a built-in property but instead a 
compiler recognized function.


at least for ".init" i can't see any reason for not replacing it 
with ".default". we can deprecate ".init", yet allow both for 
some time, and ".default" is just as logical as ".init", but it 
is using already reserved word. it is completely unambiguous, and 
easy to detect in highlighting engine by checking if we have dot 
before it.


at least this is way more logical than using `enum a = 42;` to 
declare a single constant instead of enumeration. ;-)

Re: CTFE and minimizing the GC

[ketmar via Digitalmars-d]

On Monday, 31 October 2016 at 20:23:13 UTC, Jacob Carlborg wrote:

Using StackFront at CTFE will give you the following error:

region.d(323,20): Error: null - null cannot be interpreted at 
compile time: cannot subtract pointers to two different memory 
blocks


i don't remember what specs says about this situation, tbh, but 
this is UB in C, for example. it doesn't matter that any sane 
person is ignoring it and assuming that subtracting from a 
pointer that points one cell after the region is valid, it is 
still technically unsafe operation (and possible UB).


this can be solved in two ways:

1. introducing a hack in CTFE engine, so it will explicitly allow 
using such "end-start" pointer math if result is still in the 
region at which "start" points (i'd prefer this solution)


2. fix allocators, so instead of having "_end" points past the 
allocated block, it will point right at the last cell, and do 
"+1" in each calculation (highly error-prone, as almost nobody is 
using end pointers in this way, so there will be forgotten 
increments).


allocators will break later, of course, but at least this issue 
should be fixed in CTFE engine, i think.

Re: Minimizing "reserved" words

[Karabuta via Digitalmars-d]

On Monday, 31 October 2016 at 20:45:56 UTC, Jacob Carlborg wrote:
The "reserved" words I'm referring to are not necessarily 
keywords in the language but otherwise words that should be 
avoided, especially for defining methods in aggregates. I'm 
mostly thinking of built-in properties like .init, .classinfo, 
.sizeof, .outer and so on.


All of the above can be used as variable names. Some of the 
above names can be used as methods in aggregates but some 
cannot. Of the above names only "sizeof" cannot be used as a 
method name.


classinfo, sizeof... do not match the D coding convention (which 
is necessary to write D code that don't conflict with built-in 
keywords) when used. camelCase is recommended.

Re: general questions about static this() at module level

[WhatMeWorry via Digitalmars-d-learn]

On Monday, 31 October 2016 at 18:46:31 UTC, Jonathan M Davis 
wrote:
though there's no reason to ever use a static constructor 
(shared or otherwise) when you can directly initialize the 
variable. It's really meant for more complicated initialization 
that can't be done directly.


Also, I would point out that in general, you'll be better off 
if you avoid static constructors and destructors. They can be 
extremely useful, but if multiple modules use them, and one 
imports the other (even indirectly), and the runtime thinks 
that that dependency is circular, then it'll throw an Error 
when you start your program (this comes from the fact that the 
runtime has to determine the order to run the static 
constructors so that everything is initialized before it's 
used, but it's not very smart about it, since it bases what it 
does solely on the presense of static constructors in a module 
and not what they actually do).


Thanks! This is probably why I was not able to find a good code 
example in github. Not that I tried very hard when search 
returned over 10K occurrences of "static this". Seems this kind 
of higher level reasoning is missing from the books and 
documentation that I've read. Hope this kind of knowledge gets 
recorded somewhere.

Re: strange -fPIC compilation error

[Charles Hixson via Digitalmars-d-learn]

On 10/31/2016 12:31 PM, Daniel Kozak via Digitalmars-d-learn wrote:

Dne 31.10.2016 v 20:20 Charles Hixson via Digitalmars-d-learn napsal(a):


...

but
dmd -defaultlib=libphobos2.so -fPIC test.d
works.  It shouldn't be required (as in the default /etc/dmd.conf 
should handle it correctly, but I can deal with it now.


It should work, it is possible that you have some another dmd.conf 
somewhere?



I did have a couple lying around, but they worked fine in the past, and 
renaming them didn't fix, or even just change, anything.  I've still got 
some others on my backup partition, but I can't imagine that they would 
be in use.


One of them was there because I had a few macros that were specified in 
an external ddoc file that was used by one project, e.g.

Re: SoundTab Theremin software synthesizer

[Karabuta via Digitalmars-d-announce]

On Friday, 28 October 2016 at 08:28:41 UTC, Vadim Lopatin wrote:

Hello,

I've open sourced my project SoundTab: 
https://github.com/buggins/soundtab/




For better experience, use Wacom digitizer with pressure 
detection.




These are are the kind of stuff needed to build enterprise level 
softwares for real-world use case. I really love to see more 
similar hardware interface libraries like reading from scanners, 
sensors, printing, PDF generators for printing, WebRTC, 
peer-to-peer, etc. and more IoT stuff/packages in dub registry.



I think we have a QRCode library in dub so the more the better - 
D becomes more competitive for both hobbyists, independent and 
enterprise developers.

Re: Classes and templates

[John Colvin via Digitalmars-d]

On Monday, 31 October 2016 at 19:24:46 UTC, Hefferman wrote:

Hello,

I've been trying to implement a class for sorting which accepts 
arrays which "different" data types. Hard to describe, here's 
my example (filename sorting.d):


[...]


Glad to see you're getting helpful responses here, but just an 
FYI: https://forum.dlang.org/group/learn would be a more 
appropriate forum for questions like this.

Re: newbie problem with nothrow

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, October 31, 2016 22:20:59 Kapps via Digitalmars-d-learn wrote:
> Assuming you're sure it'll never throw. To enforce this, use try
> { } catch { throw new Error("blah"); }. You can still throw
> errors, just not exceptions (as errors are not meant to be
> caught).

I always use assert(0). e.g.

try
return format("%s", 42);
catch(Exception)
assert(0, "format threw when it shouldn't be possible.");

- Jonathan M Davis

Re: Minimizing "reserved" words

[Jonathan M Davis via Digitalmars-d]

On Monday, October 31, 2016 22:22:00 Jacob Carlborg via Digitalmars-d wrote:
> On 2016-10-31 21:53, Steven Schveighoffer wrote:
> > The plan is to deprecate .init as an overridable method or field, and
> > then remove support (i.e. .init ALWAYS refers to the compile-generated
> > init instance). First step is for Phobos/druntime to eradicate all uses
> > of it.
>
> I suspected this was the plan. My post was about that there are other
> built-in properties that have the same problem. Also that the solution,
> to not make them overridable, might not be the best solution. The
> current implementation (built-in properties) don't add much advantage
> but has the disadvantage of taking up an additional word as reserved.

IMHO, it's just plain error-prone to allow for any of the built-in
properties to be overridden, and it should be disallowed in all cases. We
need to be able to rely on stuff like .init of .sizeof being the built-in
property, or you're just going to get bugs - especially in generic code.

I see no problem with being able to declare a variable with any of those
names, and it's probably okay for them to be used as the names of free
functions (and if you tried to use UFCS with them, they'd even be acting the
way that UFCS normally acts in the cases where there's a conflict). It's
just that they shouldn't be allowed to be declared as members of a type,
because they're already there with the built-in properties. Honestly, it
seems like a pretty serious bug to me that it's ever been possible to
declare any of them as members.

- Jonathan M Davis

Re: newbie problem with nothrow

[Kapps via Digitalmars-d-learn]

On Monday, 31 October 2016 at 17:04:28 UTC, Temtaime wrote:

On Monday, 31 October 2016 at 16:55:51 UTC, WhatMeWorry wrote:


Is there a way to turn off nothrow or work around it? Because 
to me it looks like nothrow prevents me from doing anything 
useful.


extern(C) void onKeyEvent(GLFWwindow* window, int key, int 
scancode, int action, int modifier) nothrow

{
if(queue.roomInQueue())
{
auto event = new Event;
event.type = EventType.keyboard;
event.keyboard.key = cast(Key) key;

// etc.
}

Error: function 'event_handler.CircularQueue.roomInQueue' is 
not nothrow
Error: function 'event_handler.onKeyEvent' is nothrow yet may 
throw



The compiler wouldn't let me just remove "nothrow" from the 
function. I tried a kludge where I had this function just pass 
all its parameters to another throwable function, but this 
caused errors as well.


So I'm stuck.  Anyone know how to proceed.
Thanks.


Wrap a body of the function to try {} catch {} and it'll work.


Assuming you're sure it'll never throw. To enforce this, use try 
{ } catch { throw new Error("blah"); }. You can still throw 
errors, just not exceptions (as errors are not meant to be 
caught).

Re: Can someone please explain why the following assertion fails?

[Ali Çehreli via Digitalmars-d-learn]

On 10/31/2016 12:08 PM, Gary Willoughby wrote:

Can someone please explain why the following assertion fails?

import std.stdio;
import std.conv;

void main(string[] args)
{
auto x = 1;

assert(hashOf(x.to!(string)) == hashOf(x.to!(string)));
}

Thanks.


I think you need TypeInfo.getHash.

  https://dlang.org/phobos/object.html#.TypeInfo.getHash

import std.conv;

auto myHashOf(T)(auto ref T value) {
return typeid(T).getHash();
}

void main() {
auto x = 1;
auto s = "1";
assert(myHashOf(x.to!string) == myHashOf(x.to!string));
assert(myHashOf(s) == myHashOf(s));
assert(myHashOf(s) == myHashOf(x.to!string));
}

Ali

Re: Minimizing "reserved" words

[Jacob Carlborg via Digitalmars-d]

On 2016-10-31 21:53, Steven Schveighoffer wrote:


The plan is to deprecate .init as an overridable method or field, and
then remove support (i.e. .init ALWAYS refers to the compile-generated
init instance). First step is for Phobos/druntime to eradicate all uses
of it.


I suspected this was the plan. My post was about that there are other 
built-in properties that have the same problem. Also that the solution, 
to not make them overridable, might not be the best solution. The 
current implementation (built-in properties) don't add much advantage 
but has the disadvantage of taking up an additional word as reserved.


--
/Jacob Carlborg

Re: Release D 2.072.0

[ag0aep6g via Digitalmars-d-announce]

On 10/31/2016 09:35 PM, Martin Nowak wrote:

There weren't any open regressions left in Bugzilla blocking this
release,


What makes a regression blocking? There are three open regressions in 2.072:

https://issues.dlang.org/show_bug.cgi?id=16013
https://issues.dlang.org/show_bug.cgi?id=16273
https://issues.dlang.org/show_bug.cgi?id=16574

Re: Minimizing "reserved" words

[Steven Schveighoffer via Digitalmars-d]

On 10/31/16 4:45 PM, Jacob Carlborg wrote:


In the latest release of DMD (2.072.0) TypeInfo.init has been deprecate
in favor of TypeInfo.initializer. That would not have been needed if
..init wasn't a built-in property but instead a compiler recognized
function.

Thoughts? Too late to change, to much could would break?



The plan is to deprecate .init as an overridable method or field, and 
then remove support (i.e. .init ALWAYS refers to the compile-generated 
init instance). First step is for Phobos/druntime to eradicate all uses 
of it.


-Steve

Re: CTFE Status

[Steven Schveighoffer via Digitalmars-d]

On 10/31/16 9:29 AM, 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.

I will start with giving an overview of what works and what does not work.


Awesome work, I can't wait for efficient streamlined CTFE.

Note to those not aware, Stefan is working on replacing the CTFE engine 
in D with a bytecode generated one. So although he mentions things that 
"don't work", he's talking about them in the context of the new CTFE 
engine. Many of these things already work in current CTFE implementation.


-Steve

Minimizing "reserved" words

[Jacob Carlborg via Digitalmars-d]

The "reserved" words I'm referring to are not necessarily keywords in 
the language but otherwise words that should be avoided, especially for 
defining methods in aggregates. I'm mostly thinking of built-in 
properties like .init, .classinfo, .sizeof, .outer and so on.


All of the above can be used as variable names. Some of the above names 
can be used as methods in aggregates but some cannot. Of the above names 
only "sizeof" cannot be used as a method name.


Would it be better to try to minimize these special words and instead 
use either compiler recognized functions/templates or something like 
__traits? If they were compiler recognized functions, defined somewhere 
in druntime, the normal language lookup rules could be used to 
disambiguate the compiler recognized functions from user defined 
functions. Or if a __trait is used, that would have it's own namespace 
and not cause any conflicts.


In the latest release of DMD (2.072.0) TypeInfo.init has been deprecate 
in favor of TypeInfo.initializer. That would not have been needed if 
.init wasn't a built-in property but instead a compiler recognized function.


Thoughts? Too late to change, to much could would break?

--
/Jacob Carlborg

Re: Classes and templates

[Kapps via Digitalmars-d]

On Monday, 31 October 2016 at 20:25:18 UTC, Hefferman wrote:

for (uint k = 1; k < n; k++) {
if (a[k-1] > a[k]) {
T tmp = a[k];
a[k] = a[k+1];
a[k+1] = tmp;
sorted = false;
}
}
n--;
} while (!sorted);
}
}
[/code]

It gives a Range Violation upon executing, but I guess it's 
part of the algorithm


The value of n is array length, so k reaches (n - 1), therefore 
k+1 gives you n which is out of bounds.

Re: Release D 2.072.0

[Martin Nowak via Digitalmars-d-announce]

On 10/31/2016 08:45 AM, Sönke Ludwig wrote:
> BTW, I was really surprised that there was not at least one release
> candidate. There is a forward reference regression that happened after
> the last beta and affects vibe.d. I'll see if I can find a workaround.

There weren't any open regressions left in Bugzilla blocking this
release, and I did take care of that forward reference bug (Issue 16607).
I did not want to delay the release any further. We can always follow up
with point releases if more fixes come in.
I hope https://ci.dawg.eu/ helps to avoid accumulating so many issues in
the first place.

-Martin

[Issue 16583] Static module ctor semantic proposition

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||c...@dawg.eu
 Resolution|--- |WONTFIX

--- Comment #1 from Martin Nowak  ---
That's doesn't make sense b/c using Type could depend on the sth. being
initialized first.
What we could try is to teach the compiler to recognize a few more standalone
constructors (that simply initialize plain data fields).

--

Re: Release D 2.072.0

[Martin Nowak via Digitalmars-d-announce]

On 10/31/2016 08:24 AM, Sönke Ludwig wrote:
> Hm, looks like DUB 1.1.0 was tagged on master instead of stable, which
> means that some fixes are missing and some changes haven't gone through
> a testing phase. Can we still fix this for this release?

Shoot, sorry for that. We still need to integrate dub into
http://wiki.dlang.org/DMD_Release_Building.

Release vibe.d 0.7.30

[Sönke Ludwig via Digitalmars-d-announce]

Main changes over 0.7.29:

  - Compiles on the latest DMD version (2.068.x-2.072.0)
  - Added a new authorization framework for the web/REST interface
generators
  - Extended the serialization framework with more hooks and traits,
enabling the use of custom UDAs - vibe-sdlang [1] is an SDLang
serialization module that became possible this way
  - opDispatch has been removed from Bson/Json
  - Optional support for using diet-ng [2] has been added and is
enabled by default for new projects - for existing projects, add
diet-ng as a dependency or add it to dub.selections.json
  - The HTTP client can now be used on Unix socket destinations
  - Added table support for the Markdown compiler

All changes:
https://vibed.org/blog/posts/vibe-release-0.7.30

DUB package:
https://code.dlang.org/packages/vibe-d/0.7.30

[1]: https://code.dlang.org/packages/vibe-sdlang
[2]: https://code.dlang.org/packages/diet-ng

Re: CTFE and minimizing the GC

[Stefan Koch via Digitalmars-d]

On Monday, 31 October 2016 at 20:23:13 UTC, Jacob Carlborg wrote:
One of the big features of D and a feature that is show cased 
is CTFE. The regex module and the PEG parser generator are 
projects that are often mentioned when talking about what CTFE 
can do.


One of the, or _the_, major goal now for D is to reduce the 
dependency on the GC in the standard library.


These two features/goals don't mix very well together. For 
CTFE, basically the only way to allocate memory is using the GC 
or stack allocated memory.


One way to minimize the dependency on the GC is to use 
allocators, i.e. std.experimental.allocator. It's 
understandable that an allocator that uses malloc/free under 
the hood doesn't work at CTFE. But there's both a GC allocator 
and a stack allocator, which in theory sounds like they could 
work. One could imagine a function taking an allocator as a 
policy, using a custom well optimized allocator that will be 
used at runtime. But when the function is used at CTFE, pass in 
the GC allocator instead. Unfortunately neither the GC 
allocator nor the stack allocator work at CTFE.


Using StackFront at CTFE will give you the following error:

region.d(323,20): Error: null - null cannot be interpreted at 
compile time: cannot subtract pointers to two different memory 
blocks


Trying to use GCAllocator at CTFE will give you:

Error: static variable instance cannot be read at compile time

Or trying to create your own instance to bypass the above error:

memory.d(368,25): Error: gc_malloc cannot be interpreted at 
compile time, because it has no available source code


Is this something that the D core team is aware of and is 
planning to address?


Is it possible to have an allocator fulfilling the allocator 
interface at the same time works at CTFE?


For quick fix std.allocator has to be fitted with a if(__ctfe) to 
detect usage at CTFE and use CTFEable allocation instead.

Re: Got a post for the D Blog?

[Jacob Carlborg via Digitalmars-d-announce]

On 2016-10-31 04:51, Mike Parker wrote:

So far, getting content for the blog has, with a few exceptions, been a
process of sending out emails prompted by activity on my radar. This is
no problem when it comes to project highlights or other fairly broad
topics, but it's highly inefficient for ginning up technical posts on
the implementation of specific algorithms, or optimization details, or
how a D feature prevented a nuclear meltdown.


Would it be interesting to have a blog post about implement support for 
Objective-C in D? That would be very technical and quite low level.


--
/Jacob Carlborg

Re: Classes and templates

[Hefferman via Digitalmars-d]

On Monday, 31 October 2016 at 20:20:09 UTC, Meta wrote:

[...]

You can't use an un-instantiated template as a type anyway, 
unlike Java. There the above is illegal because of `BubbleSort 
b = ...`. The symbol BubbleSort by itself is not a type; you 
have to instantiate it with template arguments to create a 
type. So you *could* do it like this:


BubbleSort!(typeof(arr)) b = new BubbleSort!(typeof(arr));

But that's too verbose. There's need need to repeat ourselves. 
You can instead use `auto` and omit the type of `b`, which will 
be inferred from the right hand side:


auto b = new BubbleSort!(typeof(arr));


Thanks! This compiled just fine...

[code]
import std.random;
import std.stdio;

void main()
{
immutable uint N = 10_000;

double[] arr = new double[](N);
for (uint k = 0; k < N; k++) arr[k] = uniform(0, N);

auto b = new BubbleSort!(typeof(arr));
b.Sort(arr);
}

public class BubbleSort(T)
{
private T[] a;
private uint n;

public void Sort(T)(T[] a) {
n = a.length;
bubblesort();
}

private void bubblesort() {
bool sorted;

do {
sorted = true;
for (uint k = 1; k < n; k++) {
if (a[k-1] > a[k]) {
T tmp = a[k];
a[k] = a[k+1];
a[k+1] = tmp;
sorted = false;
}
}
n--;
} while (!sorted);
}
}
[/code]

It gives a Range Violation upon executing, but I guess it's part 
of the algorithm

CTFE and minimizing the GC

[Jacob Carlborg via Digitalmars-d]

One of the big features of D and a feature that is show cased is CTFE. 
The regex module and the PEG parser generator are projects that are 
often mentioned when talking about what CTFE can do.


One of the, or _the_, major goal now for D is to reduce the dependency 
on the GC in the standard library.


These two features/goals don't mix very well together. For CTFE, 
basically the only way to allocate memory is using the GC or stack 
allocated memory.


One way to minimize the dependency on the GC is to use allocators, i.e. 
std.experimental.allocator. It's understandable that an allocator that 
uses malloc/free under the hood doesn't work at CTFE. But there's both a 
GC allocator and a stack allocator, which in theory sounds like they 
could work. One could imagine a function taking an allocator as a 
policy, using a custom well optimized allocator that will be used at 
runtime. But when the function is used at CTFE, pass in the GC allocator 
instead. Unfortunately neither the GC allocator nor the stack allocator 
work at CTFE.


Using StackFront at CTFE will give you the following error:

region.d(323,20): Error: null - null cannot be interpreted at compile 
time: cannot subtract pointers to two different memory blocks


Trying to use GCAllocator at CTFE will give you:

Error: static variable instance cannot be read at compile time

Or trying to create your own instance to bypass the above error:

memory.d(368,25): Error: gc_malloc cannot be interpreted at compile 
time, because it has no available source code


Is this something that the D core team is aware of and is planning to 
address?


Is it possible to have an allocator fulfilling the allocator interface 
at the same time works at CTFE?


--
/Jacob Carlborg

Re: Classes and templates

[Meta via Digitalmars-d]

On Monday, 31 October 2016 at 20:06:22 UTC, Hefferman wrote:

On Monday, 31 October 2016 at 19:43:57 UTC, Adam D. Ruppe wrote:

On Monday, 31 October 2016 at 19:24:46 UTC, Hefferman wrote:

Give a template type when crating it

new BubbleSort!(string)

for example


Is it possible to create this using "typeof"?
E. g. "BubbleSort b = new BubbleSort!(typeof(arr));"
Compilation fails with that line


You can't use an un-instantiated template as a type anyway, 
unlike Java. There the above is illegal because of `BubbleSort b 
= ...`. The symbol BubbleSort by itself is not a type; you have 
to instantiate it with template arguments to create a type. So 
you *could* do it like this:


BubbleSort!(typeof(arr)) b = new BubbleSort!(typeof(arr));

But that's too verbose. There's need need to repeat ourselves. 
You can instead use `auto` and omit the type of `b`, which will 
be inferred from the right hand side:


auto b = new BubbleSort!(typeof(arr));

Re: [Slides] Generic Low Level Programming with D - The Better C for your Business

[Nick B via Digitalmars-d-announce]

On Monday, 31 October 2016 at 19:59:59 UTC, cym13 wrote:
On Friday, 28 October 2016 at 06:46:27 UTC, Ilya Yaroshenko 
wrote:

https://docs.google.com/presentation/d/1w1cQ8vDluglRIt8Qdnm-sY7kqxoKZxbPEWW6tR3lPpo/edit?usp=sharing


Do you think you could maybe find the time to do a quick blog 
post to illustrate the slides? To be honnest the slides without 
the presentation aren't that clear or useful but I'd like to 
hear what you have to say.


Agreed. Some more context would help.

Re: Classes and templates

[Hefferman via Digitalmars-d]

On Monday, 31 October 2016 at 19:43:57 UTC, Adam D. Ruppe wrote:

On Monday, 31 October 2016 at 19:24:46 UTC, Hefferman wrote:

Give a template type when crating it

new BubbleSort!(string)

for example


Is it possible to create this using "typeof"?
E. g. "BubbleSort b = new BubbleSort!(typeof(arr));"
Compilation fails with that line

[Issue 12655] foldRange

[via Digitalmars-d-bugs]

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

--- Comment #6 from John Hall  ---
This can probably be closed now that D 2.072.0 adds cumulativeFold.

--

Re: [Slides] Generic Low Level Programming with D - The Better C for your Business

[cym13 via Digitalmars-d-announce]

On Friday, 28 October 2016 at 06:46:27 UTC, Ilya Yaroshenko wrote:

https://docs.google.com/presentation/d/1w1cQ8vDluglRIt8Qdnm-sY7kqxoKZxbPEWW6tR3lPpo/edit?usp=sharing


Do you think you could maybe find the time to do a quick blog 
post to illustrate the slides? To be honnest the slides without 
the presentation aren't that clear or useful but I'd like to hear 
what you have to say.

Re: Can someone please explain why the following assertion fails?

[Gary Willoughby via Digitalmars-d-learn]

On Monday, 31 October 2016 at 19:24:13 UTC, Ali Çehreli wrote:

On 10/31/2016 12:08 PM, Gary Willoughby wrote:

[...]


Because it considers the .ptr property of arrays as well:


https://github.com/dlang/druntime/blob/master/src/core/internal/hash.d#L61

[...]


Ah right.

Is there an alternative built-in, generic, nogc hash function 
that would return the same values for Strings?

Re: Classes and templates

[Adam D. Ruppe via Digitalmars-d]

On Monday, 31 October 2016 at 19:24:46 UTC, Hefferman wrote:
Whenever I try to compile this, it throws an error "class 
sorting.BubbleSort(T) is used as a type". How do I get a 
workaround?


Give a template type when crating it

new BubbleSort!(string)

for example

Re: strange -fPIC compilation error

[Daniel Kozak via Digitalmars-d-learn]

Dne 31.10.2016 v 20:20 Charles Hixson via Digitalmars-d-learn napsal(a):


...

but
dmd -defaultlib=libphobos2.so -fPIC test.d
works.  It shouldn't be required (as in the default /etc/dmd.conf 
should handle it correctly, but I can deal with it now.


It should work, it is possible that you have some another dmd.conf 
somewhere?

Classes and templates

[Hefferman via Digitalmars-d]

Hello,

I've been trying to implement a class for sorting which accepts 
arrays which "different" data types. Hard to describe, here's my 
example (filename sorting.d):


[code]
import std.random;

void main()
{
immutable uint N = 10_000;

double[] arr = new double[](N);
for (uint k = 0; k < N; k++) arr[k] = uniform(0, N);

BubbleSort b = new BubbleSort();
b.Sort(arr);
}

public class BubbleSort(T)
{
private T[] a;
private uint n;

public void Sort(T)(T[] a) {
this.a = a;
n = a.length;
bubblesort();
}

private void bubblesort() {
bool sorted;

do {
sorted = true;
for (uint k = 0; k < n; k++) {
if (a[k] > a[k+1]) {
T tmp = a[k];
a[k] = a[k+1];
a[k+1] = tmp;
sorted = false;
}
}
n--;
} while (!sorted);
}
}
[/code]

Whenever I try to compile this, it throws an error "class 
sorting.BubbleSort(T) is used as a type". How do I get a 
workaround?

Re: Can someone please explain why the following assertion fails?

[Ali Çehreli via Digitalmars-d-learn]

On 10/31/2016 12:08 PM, Gary Willoughby wrote:

Can someone please explain why the following assertion fails?

import std.stdio;
import std.conv;

void main(string[] args)
{
auto x = 1;

assert(hashOf(x.to!(string)) == hashOf(x.to!(string)));
}

Thanks.


Because it considers the .ptr property of arrays as well:


https://github.com/dlang/druntime/blob/master/src/core/internal/hash.d#L61

//dynamic array hash
size_t hashOf(T)(auto ref T val, size_t seed = 0)
if (!is(T == enum) && !is(T : typeof(null)) && is(T S: S[]) && 
!__traits(isStaticArray, T)

&& !is(T == struct) && !is(T == class) && !is(T == union))
{
alias ElementType = typeof(val[0]);
static if (is(ElementType == interface) || is(ElementType == class) ||
   ((is(ElementType == struct) || is(ElementType == union))
   && is(typeof(val[0].toHash()) == size_t)))
//class or interface array or struct array with toHash(); CTFE 
depend on toHash() method

{
size_t hash = seed;
foreach (o; val)
{
hash = hashOf(o, hash);
}
return hash;
}
else static if (is(typeof(toUbyte(val)) == const(ubyte)[]))
//ubyteble array (arithmetic types and structs without toHash) CTFE 
ready for arithmetic types and structs without reference fields

{
auto bytes = toUbyte(val);
return bytesHash(bytes.ptr, bytes.length, seed);// <-- HERE
}
else //Other types. CTFE unsupported
{
assert(!__ctfe, "unable to compute hash of "~T.stringof);
return bytesHash(val.ptr, ElementType.sizeof*val.length, seed);
}
}

Ali

Re: strange -fPIC compilation error

[Charles Hixson via Digitalmars-d-learn]

On 10/31/2016 11:23 AM, Daniel Kozak via Digitalmars-d-learn wrote:

Dne 31.10.2016 v 18:06 Charles Hixson via Digitalmars-d-learn napsal(a):


On 10/31/2016 09:26 AM, Charles Hixson via Digitalmars-d-learn wrote:

On 10/30/2016 11:34 PM, Daniel Kozak via Digitalmars-d-learn wrote:
Dne 31.10.2016 v 02:30 Charles Hixson via Digitalmars-d-learn 
napsal(a):




Well, that certainly changed the error messages.  With
dmd -defaultlib=/usr/lib/x86_64-linux-gnu/libphobos2.so test.d
I get:
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1121): Error: 
found 'nothrow' when expecting '{'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1123): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1124): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1125): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1126): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1127): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1128): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1129): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1133): Error: 
asm statements must end in ';'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1136): Error: 
found 'private' instead of statement
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1146): Error: 
no identifier for declarator add
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1149): Error: 
no identifier for declarator usDone
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1149): Error: 
Declaration expected, not ':'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1157): Error: 
Declaration expected, not '('
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1159): Error: 
Declaration expected, not 'foreach'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1159): Error: 
Declaration expected, not '0'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1164): Error: 
no identifier for declarator __fhnd_info[fd]
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1164): Error: 
Declaration expected, not '='
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1165): Error: 
Declaration expected, not 'return'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1167): Error: 
unrecognized declaration
/usr/include/dmd/phobos/std/typecons.d(1124): Error: semicolon 
expected following function declaration


This seems to be problem with your installation, you probably have 
diferen version of dmd compiler and phobos library. So you should 
uninstall all your dmd packages and make sure there is no 
/usr/include/dmd left in your system. And instal dmd only from one 
source (d-apt idealy).


I've done that 2 or 3 times.  If that's the problem, then there are 
different versions stored in the repository.  Since I'm on debian 
testing I'd been assuming that there'd been some system change since 
I'd last used the compiler, and the debs weren't yet up to date. The 
only updates to my system prior to the compiler breaking HAD been 
via apt-get.  Since then I've used dpkg remove and install a couple 
of times to try other versions of dmd with no benefit.

Currently dmd-bin version 2.071.2-0
  libphobos2.071.2-0
  libphobos2.071.2-0
so they're LISTED as being the same version.  And dmd.conf was 
installed by the deb, and is (eliminating the comments):

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


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


But somewhere during the process (which included the nightly system 
update) the error messages changed, and now:

dmd test.d
yields:
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1121): Error: 
found 'nothrow' when expecting '{'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1123): Error: 
mismatched number of curly brackets

...
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1167): Error: 
unrecognized declaration
/usr/include/dmd/phobos/std/typecons.d(1124): Error: semicolon 
expected following function declaration
FWIW starting at 
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1121)::

asm nothrow @nogc
{
mov EDX, num;
lock;
inc _iSemLockCtrs[EDX * 2];
so nothrow isn't being seen as appropriate at the beginning of an asm 
block.  After that I think it gets confused as 1123 doesn't HAVE a 
brace (i.e. curly bracket) in it.



when you type dmd --version what it prints?


THAT WAS THE CLUE!
(that which follows is how I proceeded to the answer after that clue.)
 dmd -version
Error: unrecognized switch '-version'
and
dmd --version
Error: 

Re: Can someone please explain why the following assertion fails?

[Gary Willoughby via Digitalmars-d-learn]

On Monday, 31 October 2016 at 19:08:50 UTC, Gary Willoughby wrote:

Can someone please explain why the following assertion fails?

import std.stdio;
import std.conv;

void main(string[] args)
{
auto x = 1;

assert(hashOf(x.to!(string)) == hashOf(x.to!(string)));
}

Thanks.


DMD64 D Compiler v2.072.0
Copyright (c) 1999-2016 by Digital Mars written by Walter Bright

Ubuntu 16.04

Can someone please explain why the following assertion fails?

[Gary Willoughby via Digitalmars-d-learn]

Can someone please explain why the following assertion fails?

import std.stdio;
import std.conv;

void main(string[] args)
{
auto x = 1;

assert(hashOf(x.to!(string)) == hashOf(x.to!(string)));
}

Thanks.

Re: general questions about static this() at module level

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, October 31, 2016 16:02:13 WhatMeWorry via Digitalmars-d-learn 
wrote:
> On Monday, 31 October 2016 at 05:42:16 UTC, sarn wrote:
> > On Monday, 31 October 2016 at 04:35:35 UTC, WhatMeWorry wrote:
> >> [...]
> >
> > I've seen hacks to do the same thing in C++.  They're not
> > pretty, though.
> >
> >> [...]
> >
> > Class/struct static constructors are good for initialising
> > class/struct static data.  Module static constructors are good
> > for initialising module "static data" (i.e., globals).  They're
> > especially handy for initialising immutable global data (which
> > is the kind of global data D encourages).
> >
> > BTW, immutable data is shared between threads, so you should
> > use "shared static this" to initialise it.  Regular static
> > constructors are executed per thread.
>
> Thanks! If you don't mind a follow up question, is this:
>
> immutable uint maxSize = 128;
>
> identical to this:
>
> immutable uint maxSize;
>
> static this()
> {
>  maxSize = 128;
>
> }

As Ali points out, the first one is initialized at compile time and usable
at compile time, whereas the second is initialized at runtime and thus is
not usable at compile time.

It should be pointed out however, that it's an outstanding bug that
initializing an immutable variable with a non-shared static this is allowed.
As it stands, with the second example, maxSize would actually be initialized
once per thread, which is a problem, because immutable is implicitly shared.
It wouldn't really matter in this case, because it's a value type, and it's
always given the same value, but it's still not something that should be
allowed. Rather, it should be

shared static this()
{
maxSize = 128;
}

though there's no reason to ever use a static constructor (shared or
otherwise) when you can directly initialize the variable. It's really meant
for more complicated initialization that can't be done directly.

Also, I would point out that in general, you'll be better off if you avoid
static constructors and destructors. They can be extremely useful, but if
multiple modules use them, and one imports the other (even indirectly), and
the runtime thinks that that dependency is circular, then it'll throw an
Error when you start your program (this comes from the fact that the runtime
has to determine the order to run the static constructors so that everything
is initialized before it's used, but it's not very smart about it, since it
bases what it does solely on the presense of static constructors in a module
and not what they actually do). So, if you ever end up with any kind of
circular imports (even indirectly), you can run into problems. Because of
issues related to that, static constructors border on being banned in Phobos
(they're still used in rare cases, but they're avoided if they're not truly
needed, and we try not to need them).

So, while static constructors are a great feature, they can cause problems
if use them heavily.

As to your original question about other languages that have them, IIRC,
Java has static constructors (but I don't think that it has static
destructors), if Java has it, C# almost certainly does as well. C++ does not
though, which can be really annoying. It can be faked via RAII and static
variables, but in general, using static variables in C++ is pretty iffy,
because the order of intializaton is undefined (which shows that the
annoyances with druntime detecting circular imports with static constructors
and complaining about them are well worth the pain, though it would be nice
if druntime were able to be smarter about it). So, D's static constructors
and destructors are a huge improvement over what C++ has.

- Jonathan M Davis

Re: strange -fPIC compilation error

[Daniel Kozak via Digitalmars-d-learn]

Dne 31.10.2016 v 18:06 Charles Hixson via Digitalmars-d-learn napsal(a):


On 10/31/2016 09:26 AM, Charles Hixson via Digitalmars-d-learn wrote:

On 10/30/2016 11:34 PM, Daniel Kozak via Digitalmars-d-learn wrote:
Dne 31.10.2016 v 02:30 Charles Hixson via Digitalmars-d-learn 
napsal(a):




Well, that certainly changed the error messages.  With
dmd -defaultlib=/usr/lib/x86_64-linux-gnu/libphobos2.so test.d
I get:
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1121): Error: 
found 'nothrow' when expecting '{'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1123): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1124): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1125): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1126): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1127): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1128): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1129): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1133): Error: 
asm statements must end in ';'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1136): Error: 
found 'private' instead of statement
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1146): Error: no 
identifier for declarator add
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1149): Error: no 
identifier for declarator usDone
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1149): Error: 
Declaration expected, not ':'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1157): Error: 
Declaration expected, not '('
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1159): Error: 
Declaration expected, not 'foreach'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1159): Error: 
Declaration expected, not '0'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1164): Error: no 
identifier for declarator __fhnd_info[fd]
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1164): Error: 
Declaration expected, not '='
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1165): Error: 
Declaration expected, not 'return'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1167): Error: 
unrecognized declaration
/usr/include/dmd/phobos/std/typecons.d(1124): Error: semicolon 
expected following function declaration


This seems to be problem with your installation, you probably have 
diferen version of dmd compiler and phobos library. So you should 
uninstall all your dmd packages and make sure there is no 
/usr/include/dmd left in your system. And instal dmd only from one 
source (d-apt idealy).


I've done that 2 or 3 times.  If that's the problem, then there are 
different versions stored in the repository.  Since I'm on debian 
testing I'd been assuming that there'd been some system change since 
I'd last used the compiler, and the debs weren't yet up to date. The 
only updates to my system prior to the compiler breaking HAD been via 
apt-get.  Since then I've used dpkg remove and install a couple of 
times to try other versions of dmd with no benefit.

Currently dmd-bin version 2.071.2-0
  libphobos2.071.2-0
  libphobos2.071.2-0
so they're LISTED as being the same version.  And dmd.conf was 
installed by the deb, and is (eliminating the comments):

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


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


But somewhere during the process (which included the nightly system 
update) the error messages changed, and now:

dmd test.d
yields:
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1121): Error: 
found 'nothrow' when expecting '{'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1123): Error: 
mismatched number of curly brackets

...
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1167): Error: 
unrecognized declaration
/usr/include/dmd/phobos/std/typecons.d(1124): Error: semicolon 
expected following function declaration
FWIW starting at 
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1121)::

asm nothrow @nogc
{
mov EDX, num;
lock;
inc _iSemLockCtrs[EDX * 2];
so nothrow isn't being seen as appropriate at the beginning of an asm 
block.  After that I think it gets confused as 1123 doesn't HAVE a 
brace (i.e. curly bracket) in it.



when you type dmd --version what it prints?

Re: general questions about static this() at module level

[Ali Çehreli via Digitalmars-d-learn]

On 10/31/2016 09:02 AM, WhatMeWorry wrote:

> Thanks! If you don't mind a follow up question, is this:
>
> immutable uint maxSize = 128;
>
> identical to this:
>
> immutable uint maxSize;
>
> static this()
> {
> maxSize = 128;
>
> }

As usual, yes and no. :)

The former is initialized at compile-time, meaning that it's burned into 
the binary program to be placed on a page for such immutable values.


The latter is initialized at run-time, meaning that its location in 
memory will be filled with the run-time computed value of the expression.


As long as we treat immutable as immutable, from the point of view of 
the program the two behave the same. If we attempt to mutate immutable 
data, the outcome is undefined. The following program demonstrates that


1) The two kinds of immutables are placed in different places in memory 
('a' is nearby 'a0' but 'b' is elsewhere)


2) Although both 'a' and 'b' are mutated, the last assert fails 
presumably because the compiler happens to treat 'a' differently from 
'b' by using its compile-time value like an enum. In other words, 
although 'a' has a place in memory and we manage to change it,


assert(a == 43)

is compiled as

assert(42 == 43)

and fails. That's not the same with b. Again, none of this is defined 
anywhere in the language spec. If we mutate const or immutable data, the 
behavior is undefined.


import std.stdio;

immutable uint a0 = 10;
immutable uint a = 42;
immutable uint b;

static this() {
b = 42;
}

void info(T)(string tag, ref T t) {
writefln("%20s: %s %s @ %s", tag, T.stringof, t, );
}

void mutate(alias t)() {
info(t.stringof ~ " before", t);

import std.traits : Unqual;
auto p = cast(Unqual!(typeof(t))*)
*p = *p + 1;
info(t.stringof ~ " after ", t);
}

void main() {
info("a0 for reference", a0);
mutate!a;
mutate!b;

assert(b == 43);
assert(a == 43);  // <-- FAILS
}

May print

a0 for reference: immutable(uint) 10 @ 69D390
a before: immutable(uint) 42 @ 69D394
a after : immutable(uint) 43 @ 69D394
b before: immutable(uint) 42 @ 6A9F70
b after : immutable(uint) 43 @ 6A9F70
core.exception.AssertError@deneme.d(851): Assertion failure

Ali

Re: Release D 2.072.0

[Basile B. via Digitalmars-d-announce]

On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:

Glad to announce D 2.072.0.

http://dlang.org/download.html

This is the release ships with the latest version of dub 
(v1.1.0), comes

with lots of phobos additions and native TLS on OSX.
See the changelog for more details.

http://dlang.org/changelog/2.072.0.html

-Martin


Thanks,

About http://dlang.org/changelog/2.072.0.html#drt-oncycle
I'll maybe propose this: 
https://issues.dlang.org/show_bug.cgi?id=16583


The ability to solve conflicts with selective/global imports as a 
language spec.

Re: Newbie: can't manage some types...

[zabruk70 via Digitalmars-d-learn]

On Monday, 31 October 2016 at 16:06:48 UTC, Adam D. Ruppe wrote:


dmd yourfile.d winmm.lib



i personally like https://dlang.org/spec/pragma.html#lib

pragma(lib, "winmm.lib");

Re: strange -fPIC compilation error

[Charles Hixson via Digitalmars-d-learn]

On 10/31/2016 09:26 AM, Charles Hixson via Digitalmars-d-learn wrote:

On 10/30/2016 11:34 PM, Daniel Kozak via Digitalmars-d-learn wrote:

Dne 31.10.2016 v 02:30 Charles Hixson via Digitalmars-d-learn napsal(a):



Well, that certainly changed the error messages.  With
dmd -defaultlib=/usr/lib/x86_64-linux-gnu/libphobos2.so test.d
I get:
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1121): Error: 
found 'nothrow' when expecting '{'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1123): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1124): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1125): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1126): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1127): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1128): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1129): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1133): Error: asm 
statements must end in ';'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1136): Error: 
found 'private' instead of statement
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1146): Error: no 
identifier for declarator add
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1149): Error: no 
identifier for declarator usDone
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1149): Error: 
Declaration expected, not ':'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1157): Error: 
Declaration expected, not '('
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1159): Error: 
Declaration expected, not 'foreach'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1159): Error: 
Declaration expected, not '0'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1164): Error: no 
identifier for declarator __fhnd_info[fd]
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1164): Error: 
Declaration expected, not '='
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1165): Error: 
Declaration expected, not 'return'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1167): Error: 
unrecognized declaration
/usr/include/dmd/phobos/std/typecons.d(1124): Error: semicolon 
expected following function declaration


This seems to be problem with your installation, you probably have 
diferen version of dmd compiler and phobos library. So you should 
uninstall all your dmd packages and make sure there is no 
/usr/include/dmd left in your system. And instal dmd only from one 
source (d-apt idealy).


I've done that 2 or 3 times.  If that's the problem, then there are 
different versions stored in the repository.  Since I'm on debian 
testing I'd been assuming that there'd been some system change since 
I'd last used the compiler, and the debs weren't yet up to date. The 
only updates to my system prior to the compiler breaking HAD been via 
apt-get.  Since then I've used dpkg remove and install a couple of 
times to try other versions of dmd with no benefit.

Currently dmd-bin version 2.071.2-0
  libphobos2.071.2-0
  libphobos2.071.2-0
so they're LISTED as being the same version.  And dmd.conf was 
installed by the deb, and is (eliminating the comments):

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


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


But somewhere during the process (which included the nightly system 
update) the error messages changed, and now:

dmd test.d
yields:
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1121): Error: found 
'nothrow' when expecting '{'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1123): Error: 
mismatched number of curly brackets

...
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1167): Error: 
unrecognized declaration
/usr/include/dmd/phobos/std/typecons.d(1124): Error: semicolon 
expected following function declaration

FWIW starting at /usr/include/dmd/druntime/import/core/stdc/stdio.d(1121)::
asm nothrow @nogc
{
mov EDX, num;
lock;
inc _iSemLockCtrs[EDX * 2];
so nothrow isn't being seen as appropriate at the beginning of an asm 
block.  After that I think it gets confused as 1123 doesn't HAVE a brace 
(i.e. curly bracket) in it.

Re: newbie problem with nothrow

[Temtaime via Digitalmars-d-learn]

On Monday, 31 October 2016 at 16:55:51 UTC, WhatMeWorry wrote:


Is there a way to turn off nothrow or work around it? Because 
to me it looks like nothrow prevents me from doing anything 
useful.


extern(C) void onKeyEvent(GLFWwindow* window, int key, int 
scancode, int action, int modifier) nothrow

{
if(queue.roomInQueue())
{
auto event = new Event;
event.type = EventType.keyboard;
event.keyboard.key = cast(Key) key;

// etc.
}

Error: function 'event_handler.CircularQueue.roomInQueue' is 
not nothrow
Error: function 'event_handler.onKeyEvent' is nothrow yet may 
throw



The compiler wouldn't let me just remove "nothrow" from the 
function. I tried a kludge where I had this function just pass 
all its parameters to another throwable function, but this 
caused errors as well.


So I'm stuck.  Anyone know how to proceed.
Thanks.


Wrap a body of the function to try {} catch {} and it'll work.

newbie problem with nothrow

[WhatMeWorry via Digitalmars-d-learn]

Is there a way to turn off nothrow or work around it? Because to 
me it looks like nothrow prevents me from doing anything useful.


extern(C) void onKeyEvent(GLFWwindow* window, int key, int 
scancode, int action, int modifier) nothrow

{
if(queue.roomInQueue())
{
auto event = new Event;
event.type = EventType.keyboard;
event.keyboard.key = cast(Key) key;

// etc.
}

Error: function 'event_handler.CircularQueue.roomInQueue' is not 
nothrow
Error: function 'event_handler.onKeyEvent' is nothrow yet may 
throw



The compiler wouldn't let me just remove "nothrow" from the 
function. I tried a kludge where I had this function just pass 
all its parameters to another throwable function, but this caused 
errors as well.


So I'm stuck.  Anyone know how to proceed.
Thanks.

Re: Newbie: can't manage some types...

[Cleverson Casarin Uliana via Digitalmars-d-learn]

Thanks Adam for your kindness, it Works now.

Thanks Alfred for the hint on setting the console output to 65001,
will be useful as well.

Greetings
Cleverson

Re: Box2D Lite D Port (Yet Another)

[John Colvin via Digitalmars-d-announce]

On Monday, 31 October 2016 at 13:53:26 UTC, ketmar wrote:

On Monday, 31 October 2016 at 13:40:38 UTC, John Colvin wrote:
If you could put up with putting each file (or maybe group of 
files that might form one dub package) in to a separate 
folder, add a dub.sdl for each folder, put a single dub.sdl in 
the root folder with all the other folders listed in it as 
subPackages, then push the whole thing to bitbucket, register 
on code.dlang.org and you're done?


If you really don't like having all those folders you could 
easily create a script to move everything in to place. Could 
even be in a git hook!


that's not something i'd call "non-intrusive". ;-)


I'm not saying it's non-intrusive, I'm suggesting that there 
might be a way to get what we all want - the code easily 
accessible for dub users - that might not be *too* 
intrusive/disruptive for you to put up with. Some sort of 
compromise in lieu of the perfect solution.


If it's really just the bitbucket / github thing then I mean 
there's such a thing as pushing a principle below its point of 
zero-benefit, but that's your choice. Hopefully code.dlang.org 
support for other hosts will come soon.

Re: strange -fPIC compilation error

[Charles Hixson via Digitalmars-d-learn]

On 10/30/2016 11:34 PM, Daniel Kozak via Digitalmars-d-learn wrote:

Dne 31.10.2016 v 02:30 Charles Hixson via Digitalmars-d-learn napsal(a):



Well, that certainly changed the error messages.  With
dmd -defaultlib=/usr/lib/x86_64-linux-gnu/libphobos2.so test.d
I get:
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1121): Error: 
found 'nothrow' when expecting '{'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1123): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1124): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1125): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1126): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1127): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1128): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1129): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1133): Error: asm 
statements must end in ';'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1136): Error: 
found 'private' instead of statement
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1146): Error: no 
identifier for declarator add
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1149): Error: no 
identifier for declarator usDone
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1149): Error: 
Declaration expected, not ':'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1157): Error: 
Declaration expected, not '('
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1159): Error: 
Declaration expected, not 'foreach'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1159): Error: 
Declaration expected, not '0'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1164): Error: no 
identifier for declarator __fhnd_info[fd]
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1164): Error: 
Declaration expected, not '='
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1165): Error: 
Declaration expected, not 'return'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1167): Error: 
unrecognized declaration
/usr/include/dmd/phobos/std/typecons.d(1124): Error: semicolon 
expected following function declaration


This seems to be problem with your installation, you probably have 
diferen version of dmd compiler and phobos library. So you should 
uninstall all your dmd packages and make sure there is no 
/usr/include/dmd left in your system. And instal dmd only from one 
source (d-apt idealy).


I've done that 2 or 3 times.  If that's the problem, then there are 
different versions stored in the repository.  Since I'm on debian 
testing I'd been assuming that there'd been some system change since I'd 
last used the compiler, and the debs weren't yet up to date. The only 
updates to my system prior to the compiler breaking HAD been via 
apt-get.  Since then I've used dpkg remove and install a couple of times 
to try other versions of dmd with no benefit.

Currently dmd-bin version 2.071.2-0
  libphobos2.071.2-0
  libphobos2.071.2-0
so they're LISTED as being the same version.  And dmd.conf was installed 
by the deb, and is (eliminating the comments):

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


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


But somewhere during the process (which included the nightly system 
update) the error messages changed, and now:

dmd test.d
yields:
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1121): Error: found 
'nothrow' when expecting '{'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1123): Error: 
mismatched number of curly brackets

...
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1167): Error: 
unrecognized declaration
/usr/include/dmd/phobos/std/typecons.d(1124): Error: semicolon expected 
following function declaration

Re: Newbie: can't manage some types...

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

On Monday, 31 October 2016 at 14:02:01 UTC, Cleverson Casarin 
Uliana wrote:

 Error 42: Symbol Undefined _PlaySoundW@12



This is the most common linker error, it means you used a 
function without including the library.


PlaySound's docs

https://msdn.microsoft.com/en-us/library/windows/desktop/dd743680%28v=vs.85%29.aspx

at the bottom list some facts about it. One is "Library - 
winmm.lib"


When you use that function, gotta include the library file 
somehow. Easiest is to just list it on your compile command:


dmd yourfile.d winmm.lib

since winmm.lib is provided with the operating system, that 
should just work.

Re: general questions about static this() at module level

[WhatMeWorry via Digitalmars-d-learn]

On Monday, 31 October 2016 at 05:42:16 UTC, sarn wrote:

On Monday, 31 October 2016 at 04:35:35 UTC, WhatMeWorry wrote:

[...]


I've seen hacks to do the same thing in C++.  They're not 
pretty, though.



[...]


Class/struct static constructors are good for initialising 
class/struct static data.  Module static constructors are good 
for initialising module "static data" (i.e., globals).  They're 
especially handy for initialising immutable global data (which 
is the kind of global data D encourages).


BTW, immutable data is shared between threads, so you should 
use "shared static this" to initialise it.  Regular static 
constructors are executed per thread.


Thanks! If you don't mind a follow up question, is this:

immutable uint maxSize = 128;

identical to this:

immutable uint maxSize;

static this()
{
maxSize = 128;

}

Re: Newbie: can't manage some types...

[Alfred Newman via Digitalmars-d-learn]

On Monday, 31 October 2016 at 11:44:25 UTC, Cleverson Casarin 
Uliana wrote:
Hello all, I'm trying to do two tasks which involves some type 
conversion, and I'm having dificulties, probably because I 
haven't yet understood well how such types works.


First, I wanted to convert UTF-8 strings to ansi, so it displays
correctly at the Windows command prompt. One function to do 
that is

"toMBSz" from std.windows.charset, which is declared as follows:
const(char)* toMBSz(in char[] s, uint codePage = 0);

So, after some struggling, I managed to write the following 
code:


import std.stdio;
import std.windows.charset;
void main() {
string s = "Testando acentuação";
auto r = toMBSz (s, 1);
writeln (r[0..19]);
}

Although the above code works, I have an impression that it 
could be more elegant and concise, but don't know how to 
improve it...


I'd also like to play a sound file, so tried to use the 
function "PlaySound" from core.sys.windows.mmsystem, declared 
as follows: BOOL PlaySoundW(LPCWSTR, HMODULE, DWORD);


According to some error messages I receive, the first parameter 
is of
type const(char)*, which corresponds to the sound file name, 
but I
just can't figure out how to convert the string (or a char 
array) to
that type... Could you please give some snippet example? The 
closest I

have come, which doesn't compile at all, is as follows:
import core.sys.windows.mmsystem;

void main() {
char[] f = "C:/base/portavox/som/_fon102.wav".dup;
const(wchar)* arq = cast(const(wchar)*)
void* nulo;
uint SND_FILENAME;
PlaySound (arq, nulo, SND_FILENAME);
}

Thank you,
Cleverson


Cleverson,

About your question related to "Testando acentuação", and 
assuming you're using Windows, you can also do the following:


import std.stdio, std.string;

//A Windows function to set the code page of the console output
extern (Windows): private int SetConsoleOutputCP(uint codepage);

void main()
{
SetConsoleOutputCP(65001);
string s = "Testando acentuação";
writeln("Output: ", s.toUpper());
}

Cheers

Re: ACM paper: CPU is the new bottleneck

[Kagamin via Digitalmars-d-learn]

On the other hand if you do more IO, you can have higher CPU load 
due to compression and serialization.

Re: Newbie: can't manage some types...

[Cleverson Casarin Uliana via Digitalmars-d-learn]

Thank you very much, Adam, now I'm receiving another strange error. My
code is this:

import core.sys.windows.mmsystem;

void main() {
PlaySoundW("C:/base/portavox/som/_fon102.wav"w.ptr, null, SND_FILENAME);
}

When trying to compile, it returns:
OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
tocaSom.obj(tocaSom)
 Error 42: Symbol Undefined _PlaySoundW@12
--- errorlevel 1

I made some quick searches, but not sure whether there is some error
messages' index ?

Thanks for helping,
Cleverson

Re: Box2D Lite D Port (Yet Another)

[ketmar via Digitalmars-d-announce]

On Monday, 31 October 2016 at 13:40:38 UTC, John Colvin wrote:
If you could put up with putting each file (or maybe group of 
files that might form one dub package) in to a separate folder, 
add a dub.sdl for each folder, put a single dub.sdl in the root 
folder with all the other folders listed in it as subPackages, 
then push the whole thing to bitbucket, register on 
code.dlang.org and you're done?


If you really don't like having all those folders you could 
easily create a script to move everything in to place. Could 
even be in a git hook!


that's not something i'd call "non-intrusive". ;-)

Re: Box2D Lite D Port (Yet Another)

[rikki cattermole via Digitalmars-d-announce]

On 01/11/2016 2:40 AM, John Colvin wrote:

On Monday, 31 October 2016 at 09:56:09 UTC, ketmar wrote:

i investigated the possibility of having IV as collection of DUB
projects (again), and it is still too intrusive. alas. actually, i'd
like to feature IV as a set of libraries with dependencies on
code.dlang.org, so people can easily use 'em, but DUB isn't very
tolerant to things that aren't done in "DUB way". i am really saddened
by that, but i have no desire to work on DUB, neither to "dubify" my
workflow.


Are there any specific problems you came across?

If you could put up with putting each file (or maybe group of files that
might form one dub package) in to a separate folder, add a dub.sdl for
each folder, put a single dub.sdl in the root folder with all the other
folders listed in it as subPackages, then push the whole thing to
bitbucket, register on code.dlang.org and you're done?

If you really don't like having all those folders you could easily
create a script to move everything in to place. Could even be in a git
hook!


I've had a long chat with ketmar about getting it all dubified.
The biggest problem is not using GH or BB.

It was almost completed until having to change code.dlang.org to support 
his repo host, which was do-able but still more work then he or I was 
willing to put in.

Re: Box2D Lite D Port (Yet Another)

[John Colvin via Digitalmars-d-announce]

On Monday, 31 October 2016 at 09:56:09 UTC, ketmar wrote:
i investigated the possibility of having IV as collection of 
DUB projects (again), and it is still too intrusive. alas. 
actually, i'd like to feature IV as a set of libraries with 
dependencies on code.dlang.org, so people can easily use 'em, 
but DUB isn't very tolerant to things that aren't done in "DUB 
way". i am really saddened by that, but i have no desire to 
work on DUB, neither to "dubify" my workflow.


Are there any specific problems you came across?

If you could put up with putting each file (or maybe group of 
files that might form one dub package) in to a separate folder, 
add a dub.sdl for each folder, put a single dub.sdl in the root 
folder with all the other folders listed in it as subPackages, 
then push the whole thing to bitbucket, register on 
code.dlang.org and you're done?


If you really don't like having all those folders you could 
easily create a script to move everything in to place. Could even 
be in a git hook!

Re: CTFE Status

[Dicebot via Digitalmars-d]

Thank you and keep doing awesome stuff ;)



signature.asc
Description: OpenPGP digital signature

CTFE Status

[Stefan Koch via Digitalmars-d]

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


I will start with giving an overview of what works and what does 
not work.


Currently the only basic type you can do arithmetic on is int.
Altough you can compare longs since a few days.

These are the constructs that will work.

- foreach on static arrays strings and range-foreach  (those 
kinds (0 .. 64)).

- switches (even deeply nested ones)
- for and while loops
- ternary expressions (? :)
- if and else statements (as long as you don't use && and || )
- lables and gotos
- arithmetic expressions as well as post and pre increment and 
decrement


Constructs that will not work (but are actively worked on)

- assignment to static array cells
- long ulong arithmetic.
- function calls
- dynamic arrays and slices
- pointers
- structs
- && and ||
- sliceing

Constructs that will not work and are futher down the list.

- classes
- closures
- boundschecks
- asserts

Please note that there will probably be bugs all over the place.
So even the working features might not be working completely.

Re: Newbie: can't manage some types...

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

On Monday, 31 October 2016 at 11:44:25 UTC, Cleverson Casarin 
Uliana wrote:
Although the above code works, I have an impression that it 
could be more elegant and concise, but don't know how to 
improve it...


That's OK except for the last line... the length isn't 
necessarily correct so your slice can be wrong.


I'd just use printf or some other function that handles the 
zero-terminated char* instead of slicing it.



char[] f = "C:/base/portavox/som/_fon102.wav".dup;
const(wchar)* arq = cast(const(wchar)*)
void* nulo;
uint SND_FILENAME;
PlaySound (arq, nulo, SND_FILENAME);



Oh, that can be much, much, much simpler. Try

PlaySoundW("c:/file.wav"w.ptr, null, SND_FILENAME);


So a few notes:

* SND_FILENAME is a constant defined in the header. You shouldn't 
define it yourself, it isn't meant to be a variable.


* The PlaySoundW function takes a wstring, which you can get in D 
by sticking the `w` at the end of the literal. So `"foo"` is a 
normal string, but `"foo"w` is a wstring. (The difference is 
normal is utf-8, wstring is utf-16, which Windows uses 
internally.)


* It furthermore takes a pointer, but you want a pointer to data. 
A D string or array has a pointer internally you can fetch via 
the `.ptr` property. Windows expects this string to be 
zero-terminated... which D string literals are, but other D 
strings may not be. There's a function in `std.utf` that 
guarantees it:


http://dpldocs.info/experimental-docs/std.utf.toUTF16z.html

const(wchar)* safe_to_pass_to_windows = toUTF16z("your string");

[Issue 16533] Cannot compile two file with same name

[via Digitalmars-d-bugs]

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

Nicholas Wilson  changed:

   What|Removed |Added

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

--- Comment #2 from Nicholas Wilson  ---
This was fixed by
https://github.com/ldc-developers/ldc/commit/eb85bc2f75706ea1ae54f5dc1a0345cc41f2f55c

--

Re: general questions about static this() at module level

[ggdc via Digitalmars-d-learn]

On Monday, 31 October 2016 at 04:35:35 UTC, WhatMeWorry wrote:

I am fascinated with D's module static this.

I have shamelessly stolen Ali's code directly from his book.

module cat;

static this() {
// ... the initial operations of the module ...
}
static ~this() {
// ... the final operations of the module ...
}


First, are there any other languages that has this feature?  
The few I know, certainly don't.




Object Pascal has them:


unit foo; // like a D module.

interface

// declarations...,
// like the content of a C/C++ *.h/*.hpp

implementation

// implementation like the content of a C/C++ *.c/*.cpp

initialization
// statements...
// like in a D static this(){}

finalization
// statements...
// like in a D static ~this(){}
end.


Actually without them a lot of stuffs wouldn't work properly.
They are more used than their D equivalent, particularly to
register classes for the object streaming system but not only.

Newbie: can't manage some types...

[Cleverson Casarin Uliana via Digitalmars-d-learn]

Hello all, I'm trying to do two tasks which involves some type
conversion, and I'm having dificulties, probably because I haven't yet
understood well how such types works.

First, I wanted to convert UTF-8 strings to ansi, so it displays
correctly at the Windows command prompt. One function to do that is
"toMBSz" from std.windows.charset, which is declared as follows:
const(char)* toMBSz(in char[] s, uint codePage = 0);

So, after some struggling, I managed to write the following code:

import std.stdio;
import std.windows.charset;
void main() {
string s = "Testando acentuação";
auto r = toMBSz (s, 1);
writeln (r[0..19]);
}

Although the above code works, I have an impression that it could be
more elegant and concise, but don't know how to improve it...

I'd also like to play a sound file, so tried to use the function
"PlaySound" from core.sys.windows.mmsystem, declared as follows:
BOOL PlaySoundW(LPCWSTR, HMODULE, DWORD);

According to some error messages I receive, the first parameter is of
type const(char)*, which corresponds to the sound file name, but I
just can't figure out how to convert the string (or a char array) to
that type... Could you please give some snippet example? The closest I
have come, which doesn't compile at all, is as follows:
import core.sys.windows.mmsystem;

void main() {
char[] f = "C:/base/portavox/som/_fon102.wav".dup;
const(wchar)* arq = cast(const(wchar)*)
void* nulo;
uint SND_FILENAME;
PlaySound (arq, nulo, SND_FILENAME);
}

Thank you,
Cleverson

Re: Release D 2.072.0

[John Colvin via Digitalmars-d-announce]

On Monday, 31 October 2016 at 07:24:23 UTC, Sönke Ludwig wrote:

Am 31.10.2016 um 02:27 schrieb Martin Nowak:

Glad to announce D 2.072.0.

http://dlang.org/download.html

This is the release ships with the latest version of dub 
(v1.1.0), comes

with lots of phobos additions and native TLS on OSX.
See the changelog for more details.

http://dlang.org/changelog/2.072.0.html

-Martin



Hm, looks like DUB 1.1.0 was tagged on master instead of 
stable, which means that some fixes are missing and some 
changes haven't gone through a testing phase. Can we still fix 
this for this release?


Martin, have you considered posting each release* here on the 
newsgroup 24 hours before the actual release, marked "pre-release 
sanity check" so mistakes like this are more likely to be caught?


* and I mean the actual bit-for-bit identical release packages 
here; this is test-firing the actual rocket that's going to space.

Re: Box2D Lite D Port (Yet Another)

[Martin Drašar via Digitalmars-d-announce]

Dne 31.10.2016 v 10:56 ketmar via Digitalmars-d-announce napsal(a):
>> I am asking, because it seems to contain some nice things (like a sat
>> solver port) that may help others and could benefit from being more
>> accessible than only with a programmer's spelunker gear. And I am
>> saying this with full knowledge of your passionate hate for github and
>> to some extent for dub.
> i investigated the possibility of having IV as collection of DUB
> projects (again), and it is still too intrusive. alas. actually, i'd
> like to feature IV as a set of libraries with dependencies on
> code.dlang.org, so people can easily use 'em, but DUB isn't very
> tolerant to things that aren't done in "DUB way". i am really saddened
> by that, but i have no desire to work on DUB, neither to "dubify" my
> workflow.

Got it.

> i'm trying to help those who wants to use my code, tho. ;-) i'm usually
> available on IRC.

Ok, that is also a good option :-) I will ping you if I find myself
needing an assistance.

Thanks.

Re: Got a post for the D Blog?

[Guillaume Piolat via Digitalmars-d-announce]

On Monday, 31 October 2016 at 03:51:16 UTC, Mike Parker wrote:


If you, or someone you know, have done something interesting 
with an algorithm or optimization in D, or have used a D idiom 
to do things in a way that pleasantly surprised you, please let 
me know. If I think it's something we can work with, I'll help 
you in putting together a guest post, or something like I do 
with the project highlights (where I build a post around 
whatever info you give me).




No fantastic story-telling there, but feel free to pick any 
content from https://p0nce.github.io/d-idioms/

Re: Box2D Lite D Port (Yet Another)

[ketmar via Digitalmars-d-announce]

On Monday, 31 October 2016 at 09:22:22 UTC, Martin Drašar wrote:
Neat! Not that I need a physics engine right now, but it is 
always good to have implementation of some structures at hand.

thank you.

Anyway, tht Invisible Vector project of yours, is it a 
collection of useful stuff like Adam's arsd, or is some 
standalone project?
it is like Adam's arsd: a collection of random things. basically, 
when i need something for one of my projects, i'm going to 
steal/implement it "in-place" (i.e. in project source tree), and 
later i may see that implementation as a good thing to share 
between other projects. at this stage i'm doing some more work on 
it, and then moving it in IV. and even if it won't be shared 
between projects, i sometimes moving it to IV just to have it 
everything in one place. ;-)


I am asking, because it seems to contain some nice things (like 
a sat solver port) that may help others and could benefit from 
being more accessible than only with a programmer's spelunker 
gear. And I am saying this with full knowledge of your 
passionate hate for github and to some extent for dub.
i investigated the possibility of having IV as collection of DUB 
projects (again), and it is still too intrusive. alas. actually, 
i'd like to feature IV as a set of libraries with dependencies on 
code.dlang.org, so people can easily use 'em, but DUB isn't very 
tolerant to things that aren't done in "DUB way". i am really 
saddened by that, but i have no desire to work on DUB, neither to 
"dubify" my workflow.


i'm trying to help those who wants to use my code, tho. ;-) i'm 
usually available on IRC.



p.s. to keep it all somewhat on-topic: if someone wants to add 
more joint types, it is possible to take 'em from Chipmunk code, 
almost unmodified. Chipmunk is using basically the same 
integration scheme (preStep/applyImpulse), so you'd have to do 
some simple renamings (cpFloat -> VFloat, etc.), and replace 
Chipmunk's vector math with iv.vmath. i deliberately avoied doing 
that to keep the code small (and to not spoil the fun of turning 
something simple to something more powerful ;-).

Re: Linus' idea of "good taste" code

[Dicebot via Digitalmars-d]

On 10/30/2016 06:35 PM, Laeeth Isharc wrote:
> But what I meant was LLVM will have a wasm backend.

Yes, but it is developed so slowly and conservatively, that coming up
with own proof-of-concept backend may be a chance to win early interest.
They may speed up greatly though when WebAssembly design gets closer to
MVP stage, but I am checking that regularly.

> So on basis of my
> limited understanding,  it would be some work to make LDC produce wasm
> code,  and then runtime and phobos would need work.

Most likely you would need a quite different runtime as most system/libc
level stuff will not be available in browser sandbox but the very same
browser APIs will need to be exposed instead. Most likely whatever
emscripten does for C should be fairly adaptable even outside of LLVM stack.

But right now it is mostly irrelevant because runtime requirements have
not been defined in WebAssembly at all, only low level byte code stuff.
It is all in very early stages really.



signature.asc
Description: OpenPGP digital signature

Re: Linus' idea of "good taste" code

[Dicebot via Digitalmars-d]

On 10/30/2016 07:53 AM, Walter Bright wrote:
> On 10/29/2016 10:30 PM, Dicebot wrote:
>> At the same time intended wasm spec
>> (https://github.com/WebAssembly/design) is
>> much more simple than machine code for something like x86_64. If
>> Walter gets
>> interested, that may be a feasible path :)
> 
> I looked at it for 5 minutes :-) and it looks like typical intermediate
> code that a compiler might generate. It wouldn't be hard to translate
> the intermediate code generated for the dmd back end to wasm. What I
> didn't see was any mention symbolic debug information, linking, or how
> to connect to system services like mutexes, I/O, etc. Time risks would
> also be wasm is an incomplete, moving target.

Well, "risk" and "opportunity" are pretty much synonymous in such
context :) Whoever comes first with easy to use toolchain for new
platform gets all the hype - it pretty much boils down to making
decision if one believes new platform is likely to succeed.

For now I am just keeping my track on relevant information to see where
does it all go.

> Looks like a fun project, but I don't see how I could split off time to
> work on it.

No argument here, it would be premature to pay much attention to it
anyway. I will probably remind you of this topic some time next year
with more information available so that more weighted judgment can be made.



signature.asc
Description: OpenPGP digital signature

Re: Battle-plan for CTFE

[Dicebot via Digitalmars-d-announce]

On 10/30/2016 11:19 PM, Stefan Koch wrote:
> Oh shoot!
> I did not enable the new call system :(
> This computed by the old interpreter.
> 
> The new engine fails :(

Stefan, would you mind creating a dedicated topic in main D newsgroup to
report your development progress? Bumping the thread in announce NG like
that is rather distracting, we should aim for posting only most
important/relevant info there.



signature.asc
Description: OpenPGP digital signature

Re: Release D 2.072.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 31.10.2016 um 08:24 schrieb Sönke Ludwig:

Am 31.10.2016 um 02:27 schrieb Martin Nowak:

Glad to announce D 2.072.0.

http://dlang.org/download.html

This is the release ships with the latest version of dub (v1.1.0), comes
with lots of phobos additions and native TLS on OSX.
See the changelog for more details.

http://dlang.org/changelog/2.072.0.html

-Martin



Hm, looks like DUB 1.1.0 was tagged on master instead of stable, which
means that some fixes are missing and some changes haven't gone through
a testing phase. Can we still fix this for this release?


BTW, I was really surprised that there was not at least one release 
candidate. There is a forward reference regression that happened after 
the last beta and affects vibe.d. I'll see if I can find a workaround.

Re: Release D 2.072.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 31.10.2016 um 08:24 schrieb Sönke Ludwig:

Am 31.10.2016 um 02:27 schrieb Martin Nowak:

Glad to announce D 2.072.0.

http://dlang.org/download.html

This is the release ships with the latest version of dub (v1.1.0), comes
with lots of phobos additions and native TLS on OSX.
See the changelog for more details.

http://dlang.org/changelog/2.072.0.html

-Martin



Hm, looks like DUB 1.1.0 was tagged on master instead of stable, which
means that some fixes are missing and some changes haven't gone through
a testing phase. Can we still fix this for this release?


2a90bd1c0d18d5a706723757cf01aeffc179ee1f is the right commit hash.

Re: Release D 2.072.0

[Ali Çehreli via Digitalmars-d-announce]

On 10/30/2016 06:27 PM, Martin Nowak wrote:

Glad to announce D 2.072.0.

http://dlang.org/download.html

This is the release ships with the latest version of dub (v1.1.0), comes
with lots of phobos additions and native TLS on OSX.
See the changelog for more details.

http://dlang.org/changelog/2.072.0.html

-Martin



Thanks!

Is the only valid remaining use for the comma operator the 'for' loop 
iteration?


for ( ; ; ++i, ++j) {
// ...
}

Are there other uses?

Ali

Re: Neural Networks / ML Libraries for D

[Relja Ljubobratovic via Digitalmars-d-learn]

On Tuesday, 25 October 2016 at 11:17:29 UTC, Saurabh Das wrote:

Hello,

Are there any good ML libraries for D? In particular, looking 
for a neural network library currently. Any leads would be 
appreciated.


Thanks,
Saurabh


There is also Henry Gouk's dnnet library[1]. I'm not sure how far 
is it in development, since there's no dub project registered at 
code.dlang.org, but you could give it a spin. AFAIK it relies 
another package of his, dopt[2][3], which depends on CUDA (cuBLAS 
and cuDNN).



[1] https://github.com/henrygouk/dnnet
[2] https://github.com/henrygouk/dopt
[3] http://code.dlang.org/packages/dopt

Re: Release D 2.072.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 31.10.2016 um 02:27 schrieb Martin Nowak:

Glad to announce D 2.072.0.

http://dlang.org/download.html

This is the release ships with the latest version of dub (v1.1.0), comes
with lots of phobos additions and native TLS on OSX.
See the changelog for more details.

http://dlang.org/changelog/2.072.0.html

-Martin



Hm, looks like DUB 1.1.0 was tagged on master instead of stable, which 
means that some fixes are missing and some changes haven't gone through 
a testing phase. Can we still fix this for this release?

Re: Neural Networks / ML Libraries for D

[Relja Ljubobratovic via Digitalmars-d-learn]

On Wednesday, 26 October 2016 at 12:13:16 UTC, Ilya Yaroshenko 
wrote:

https://github.com/ljubobratovicrelja/mir.experimental.model.rbf


Now moved to https://github.com/libmir/mir-neural

Re: strange -fPIC compilation error

[Sebastien Alaiwan via Digitalmars-d-learn]

Hello,
From GCC 6.2, -fpie is becoming the default setting at compile 
and at link time.
As dmd uses GCC to link, now the code needs to be compiled with a 
special option.
Which means you need, at the moment, to add the following options 
to your dmd.conf:

 -defaultlib=libphobos2.so -fPIC
(the change from GCC is related to security and address space 
randomization).

Re: Got a post for the D Blog?

[Ali Çehreli via Digitalmars-d-announce]

On 10/30/2016 08:51 PM, Mike Parker wrote:
> So far, getting content for the blog has, with a few exceptions, been a
> process of sending out emails prompted by activity on my radar.

Thank you and please continue doing that. I would have never thought of 
contributing to the blog if you hadn't contacted me with an idea.d


I have an article request for anyone who is considering writing 
something, which was prompted by a recent thread[1]. There are many 
functions in Phobos that can be used for searching and parsing: The ones 
in std.algorighm like find, findSplit, splitter, etc.; a few in 
std.range like some members of SortedRange; some in std.array like 
split; some in std.string like indexOf; and of course std.regex; and more...


It's likely that some of those are redundant or less efficient compared 
to others. There must be some simple guidelines to prefer one over the 
others. I would enjoy reading such an article. :)


Ali

[1] http://forum.dlang.org/thread/iygdxteveaykhiauo...@forum.dlang.org

JavaScript ( QScript Qt-5 ) in GUI framework QtE5

[MGW via Digitalmars-d-announce]

Support of JavaScript which is a part of Qt-5 is added to QtE5. 
The possibility of a call from the JS functions and methods 
written to D is provided. There is an opportunity to save JS 
status in case of execution of a series of scripts and from D to 
read values of any variables in JS.


screenshot:
https://pp.vk.me/c637429/v637429885/16b14/mSDeRXCZcdI.jpg

github
https://github.com/MGWL/QtE5

Re: strange -fPIC compilation error

[Daniel Kozak via Digitalmars-d-learn]

Dne 31.10.2016 v 02:30 Charles Hixson via Digitalmars-d-learn napsal(a):



Well, that certainly changed the error messages.  With
dmd -defaultlib=/usr/lib/x86_64-linux-gnu/libphobos2.so test.d
I get:
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1121): Error: found 
'nothrow' when expecting '{'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1123): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1124): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1125): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1126): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1127): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1128): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1129): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1133): Error: asm 
statements must end in ';'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1136): Error: found 
'private' instead of statement
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1146): Error: no 
identifier for declarator add
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1149): Error: no 
identifier for declarator usDone
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1149): Error: 
Declaration expected, not ':'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1157): Error: 
Declaration expected, not '('
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1159): Error: 
Declaration expected, not 'foreach'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1159): Error: 
Declaration expected, not '0'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1164): Error: no 
identifier for declarator __fhnd_info[fd]
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1164): Error: 
Declaration expected, not '='
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1165): Error: 
Declaration expected, not 'return'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1167): Error: 
unrecognized declaration
/usr/include/dmd/phobos/std/typecons.d(1124): Error: semicolon 
expected following function declaration


This seems to be problem with your installation, you probably have 
diferen version of dmd compiler and phobos library. So you should 
uninstall all your dmd packages and make sure there is no 
/usr/include/dmd left in your system. And instal dmd only from one 
source (d-apt idealy).

Re: Dlang 2016 roadmap is over? Look rust roadmap.

[Brian via Digitalmars-d]

On Monday, 31 October 2016 at 03:34:47 UTC, Brian wrote:


dlang:
http://wiki.dlang.org/Vision/2016H1

rust:
https://github.com/aturon/rfcs/blob/roadmap-2017/text/-roadmap-2017.md


Or this:
http://wiki.dlang.org/Vision/2016H2