date:20170822


https://news.ycombinator.com/item?id=15075242

[Issue 12496] __traits(parent, x) returns incorrect type

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

Mike  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=13372

--

[Issue 13372] traits parent does not work on eponymous templates

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

Mike  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=12496

--

[Issue 11259] traits(isSame) fails on the result of traits(parent) if parent is a package

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

Mike  changed:

   What|Removed |Added

 CC||slavo5...@yahoo.com

--- Comment #1 from Mike  ---
Potential Fix: https://github.com/dlang/dmd/pull/7095

--

Re: HTOD

2017-08-22 Thread Johannes Loher via Digitalmars-d-announce


On 8/22/2017 2:50 PM, Steven Schveighoffer wrote:

On 8/22/17 5:17 PM, Walter Bright wrote:

On 8/22/2017 11:23 AM, Steven Schveighoffer wrote:
I downloaded it. The exe is last modified April 28, 2010, corresponding with 
DMD version 2.044.


This can't possibly produce valid D headers for 2.075.1. I think it should be 
either updated or removed from the web site.


It doesn't correspond to the D version, it corresponds to the C compiler 
version, which is stable.


But it is generating D code, no?


Sure. And the C subset of D has been very stable, too.

dub zsh completion

I created a zsh completion script for dub. It is not perfect, but 
it does many things well already. You can find it here: 
https://github.com/ghost91-/dub-zsh-completion.


I have seen that bash and fish completion scripts are included in 
the dub github repo. If people are interested in this, I could 
create a pull request to also add the zsh completion script.


I hope this helps some people :)

Re: Type Inference in @safe unittests

2017-08-22 Thread Steven Schveighoffer via Digitalmars-d-learn


On 8/22/17 5:44 PM, jmh530 wrote:

On Tuesday, 22 August 2017 at 18:25:31 UTC, Steven Schveighoffer wrote:


@safe void main()
{
 struct Foo {
 int foo(int i, string s) @safe { return 0; }
 double foo2(string s) @safe { return 0; }
 }
 printMemberTypes!(Foo);
}


The surprising part to me is that non-@safe main doesn't infer 
anything. Is that true?




They aren't auto functions or templates, just normal member functions of 
a struct in main. I thought inferring function attributes was only for 
auto functions and templates. I never thought it would for member 
functions of structs in main. But yeah, I'm pretty those functions are 
@safe and not @safe @nogc nothrow pure.


Logically, any internal struct's code is available for examination 
wherever it could possibly be used. If it's returned, then the function 
return must be auto (and the function code available). If it's passed as 
a template parameter, it is available.


Inference could happen on any internal function anywhere, not just 
inside internal structs.


I'm not sure why the marking of the enclosing function should make a 
difference, either they all infer or they all don't infer. To me, this 
seems like a bug (the inconsistency).


-Steve

Re: HTOD

2017-08-22 Thread Steven Schveighoffer via Digitalmars-d


On 8/22/17 5:17 PM, Walter Bright wrote:

On 8/22/2017 11:23 AM, Steven Schveighoffer wrote:
I downloaded it. The exe is last modified April 28, 2010, 
corresponding with DMD version 2.044.


This can't possibly produce valid D headers for 2.075.1. I think it 
should be either updated or removed from the web site.


It doesn't correspond to the D version, it corresponds to the C compiler 
version, which is stable.


But it is generating D code, no?

-Steve

Re: Type Inference in @safe unittests

On Tuesday, 22 August 2017 at 18:25:31 UTC, Steven Schveighoffer 
wrote:


@safe void main()
{
 struct Foo {
 int foo(int i, string s) @safe { return 0; }
 double foo2(string s) @safe { return 0; }
 }
 printMemberTypes!(Foo);
}


The surprising part to me is that non-@safe main doesn't infer 
anything. Is that true?


-Steve


They aren't auto functions or templates, just normal member 
functions of a struct in main. I thought inferring function 
attributes was only for auto functions and templates. I never 
thought it would for member functions of structs in main. But 
yeah, I'm pretty those functions are @safe and not @safe @nogc 
nothrow pure.

[Issue 17771] foreach over const input range fails

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

Jonathan M Davis  changed:

   What|Removed |Added

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

--- Comment #12 from Jonathan M Davis  ---
For const to work with ranges, we'd really need some sort of tail-const slicing
mechanism similar to what happens with dynamic arrays and IFTI (though
presumably, it would require help from the programmer as opposed to being
automatic, since it really can't be done automatically with ranges like it can
be with arrays). But wthout some form of tail-const mechanism, it's a waste of
time to muck around with const and ranges. Best case, you make certain use
cases work while having a bunch that don't. At this point, it's far better to
just never use const with ranges. They're pretty much inherently incompatible
given the fact that iterating a range modifies it, and the only defined way to
copy a range is save. Technically, even using a range after passing it to a
function or using foreach on it is undefined behavior in generic code, since
the copy semantics differ wildly depending on how the range is defined. So,
trying to do anything with const automatically is a total minefield. My answer
to anyone trying to use const with ranges is to just give up now. They simply
don't work together, and trying to make them work together without language
additions related to tail-const is just going to cause you grief in the long
run.

--

Re: HTOD


On 8/22/2017 11:23 AM, Steven Schveighoffer wrote:
I downloaded it. The exe is last modified April 28, 2010, corresponding with DMD 
version 2.044.


This can't possibly produce valid D headers for 2.075.1. I think it should be 
either updated or removed from the web site.


It doesn't correspond to the D version, it corresponds to the C compiler 
version, which is stable.

[Issue 17732] SysTime.init.toString segfaults because timezone is null

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

Jonathan M Davis  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||issues.dl...@jmdavisprog.co
   ||m
 Resolution|--- |DUPLICATE

--- Comment #1 from Jonathan M Davis  ---


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

--

[Issue 12507] SysTime.init.toString should not segfault

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #9 from Jonathan M Davis  ---
*** Issue 17732 has been marked as a duplicate of this issue. ***

--

[Issue 17666] std.c.linux.socket has no replacement

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

--- Comment #5 from Jonathan M Davis  ---
druntime now has core.sys.freebsd.inet.in_, core.sys.linux.inet.in_, and 
core.sys.darwin.inet.in_ to conver all of the non-POSIX bindings from
netinet/in.h. So, I think that this problem is _mostly_ solved (though
unfortunately, it looks like it just missed making it into 2.076). I think that
some of what's in std.c.linux.socket is from some other header files though,
and some of that still needs to be added to druntime. IP_ADD_MEMBERSHIP is now
there though.

> Was it simply forgotten to be moved to druntime?
> Or what's the story behind std.c.{linux,osx}.socket?

I think that what happened is that since we don't put the OS bindings in Phobos
anymore, it was decided that they should be deprecated, and no effort was made
to verify whether everything that was defined there had actually been added to
druntime yet or not. And AFAIK, no bug reports were opened about the missing
symbols when someone did run into the problem, so the issue didn't get any
attention, and it all just went under the radar.

--

[Issue 17666] std.c.linux.socket has no replacement

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

Jonathan M Davis  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan M Davis  ---
(In reply to Sebastiaan Koppe from comment #3)
> (In reply to Sebastiaan Koppe from comment #2)
> > Just so that you know, I am working on a PR to add them to druntime.
> 
> I am a bit stuck on the issue.
> 
> In src/core/sys/posix/netinet/in_.d there are 2 general sections, one for
> ipv4 and one for ipv6. In each section constants are defined for
> CRuntime_Glibc, Darwin, FreeBSD, NetBSD, Solaris and linux (in that order).
> Except there is no linux version for ipv6.
> 
> Which makes me wonder how things for linux can actually compile, since basic
> things like in6_addr and sockaddr_in6 structures are not defined.
> 
> I suppose the CRuntime_Glibc branch is taken, but that would be invalid
> since the constants differ slightly with linux.

Well, AFAIK, basically every linux distro uses glibc, so CRuntime_Glibc is what
would be used. It's Android that wouldn't use it, and I believe that it uses
CRuntime_Bionic. The way that the IPv4 portion is a bit odd though, since it
doesn't include CRuntime_Bionic, so I guess that Android would use the linux
section in that case whereas any other linux would use CRuntime_Glibc. And in
the IPv6 section, it uses CRuntime_Bionic instead of linux. So, I suspect that
the fact that version(linux) is used in there at all is a bug, but I don't
know. Regardless, for any normal linux system, both the IPv4 and IPv6 stuff is
defined.

--

Re: @safe(bool)

2017-08-22 Thread Timon Gehr via Digitalmars-d


On 22.08.2017 21:46, 12345swordy wrote:

On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote:

On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote:
[...]
If you need an IDE to figure out what your code is doing, that's an 
epic fail IMHO. Walter has made similar statements on several occasions.


There was a time that people would write code with even modest 
performance requirements in assembler for fear of what the compiler 
would spit out, but that's in the past, as is the notion of trying to 
develop without an IDE.


You shouldn't rely on an IDE to compensate poor language design. That is 
coming from a guy who prefers IDE's.


I disagree with both the notion that this is poor language design and 
that an IDE is required to make sense out of code that uses the new feature.

Re: HTOD

2017-08-22 Thread Jacob Carlborg via Digitalmars-d


On 2017-08-22 19:47, 12345swordy wrote:


Use Clang frontend?


DStep [1] is doing that. It handles both GCC and Microsoft extensions.

[1] https://github.com/jacob-carlborg/dstep

--
/Jacob Carlborg

Re: @safe(bool)

2017-08-22 Thread 12345swordy via Digitalmars-d


On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote:
On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis 
wrote:

[...]
If you need an IDE to figure out what your code is doing, 
that's an epic fail IMHO. Walter has made similar statements 
on several occasions.


There was a time that people would write code with even modest 
performance requirements in assembler for fear of what the 
compiler would spit out, but that's in the past, as is the 
notion of trying to develop without an IDE.


You shouldn't rely on an IDE to compensate poor language design. 
That is coming from a guy who prefers IDE's.

[Issue 17771] foreach over const input range fails

2017-08-22 Thread Steven Schveighoffer via Digitalmars-d-learn

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #11 from ag0ae...@gmail.com ---
(In reply to Alex Goltman from comment #9)
> the error stating foreach doesn't work with a
> const actually made me question whether foreach over a range modifies the
> range I give it,

I don't really have a horse in this race, but if we consider a generic range,
then `foreach` does very much modify it. `foreach` doesn't call `save`, so
every `popFront` potentially modifies the original range.

It doesn't really matter that `foreach` copies the range, because copying is
not a range concept. If you have a generic range, and you run it through
`foreach`, you must be prepared to have an empty range afterwards.

--

Re: GStreamer issues.

2017-08-22 Thread Johnson via Digitalmars-d-learn

On Tuesday, 22 August 2017 at 15:15:41 UTC, Mike Wey wrote:

On 22-08-17 02:13, Johnson wrote:

I can't get the example to work(although slightly modified).

The installed version of GStreamer is 1.12.2
The file is: D:\temp\test.ogg
Loading
Setting to PLAYING.
Running.
XError: Could not demultiplex stream. dbug:
gstoggdemux.c(4418): gst_ogg_demux_find_chains ():
/GstPipeline:audio-player/GstOggDemux:ogg-parser:

can't get first chain

Actually I was getting a much worse error before ;/ I can't
remember it now.

The installed version of GStreamer is 1.12.2
The file is: D:\temp\test2.wav
Loading
Setting to PLAYING.
Running.
XError: Internal data stream error. dbug:
gstwavparse.c(2249): gst_wavparse_loop ():
/GstPipeline:audio-player/GstWavParse:wav-parser:

streaming stopped, reason not-linked (-1)

Basically all I did was change the sink:

sink = ElementFactory.make("autoaudiosink",
"auto-output");

So it I could get past the error about alsa. I think the last
name doesn't matter?

I downloaded the gstreamer binaries from their site, had some
issues with a few of the dll's complaining about gxx errors, I
removed them(h264, soundtouch, tag).

For the wav I changed
//parser = ElementFactory.make("oggdemux",
"ogg-parser");
//decoder = ElementFactory.make("vorbisdec",
"vorbis-decoder");
parser = ElementFactory.make("wavparse",
"wav-parser");
decoder = ElementFactory.make("audioconvert",
"wav-decoder");

which, is all i could find on line, I don't know if it's right
at all.

Ultimately I want to be able to read somewhat arbitrary audio
formats(most common at least), get the raw channel
data(samples for each channel), play/pause/stop with good
accuracy(no latency or low latency(<20ms), possibly do some
pitch shifting and basic mixing(EQ, limiting, panning, etc),
and eventually play some videos.

Is GstreamerD going to be useful for this or so I look in to
using ffmpeg directly and do some of the stuff(e.g., eq)
myself?

Thanks.

The Gstreamer demo should use an `playbin` instead of
explicitly setting the pipeline, Like this:
https://github.com/gtkd-developers/GtkD/blob/master/demos/gstreamer/helloworld/gstreamer_helloworld.d

This way gstreamer will detect the file type, i don't know if
it helps with the errors.

Thanks, that works!

Could you address some of my concerns:

1. I need to be able to get the raw data, is this easily possible
with gstreamer?

2. It's quite a big package 600mb+ total and about 150 for the
bin and 150 for the lib. Eventually I want to support android,
this seems quite excessive for it. I'm not familiar with
Gstreamer though and maybe most of that space is "junk". It seems
people use it already on android so I'm not too worried, I
imagine it can be customized?

3. Does Gstreamer/D provide any type of EQ, pitch shifting,
stretching, etc?

4. Do you have any idea why the original code would work? I ask
because maybe in the future I'll need to use it for other
purposes and don't wanna hit a brick wall.

Note that I'm completely new to gstreamer and only learned of it
through gtkD... so some of these might be basic questions. I'm
just trying to find something simple to use but is robust so I
don't waste time learning an api that isn't going to really do
what I need. I was plan on using portaudio and ffmpeg, but
ffmpegD doesn't really seem to work(old bindings I guess). I also
had trouble with portaudio not playing any sound, but haven't
spent much time with it to why.

Gstreamer, with your updated example, works though. Just not sure
how far of a leap I'll have to make to get it working the way I
need in my app.

Re: @safe(bool)

2017-08-22 Thread bitwise via Digitalmars-d

On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis 
wrote:

[...]
If you need an IDE to figure out what your code is doing, 
that's an epic fail IMHO. Walter has made similar statements on 
several occasions.


There was a time that people would write code with even modest 
performance requirements in assembler for fear of what the 
compiler would spit out, but that's in the past, as is the notion 
of trying to develop without an IDE.

Re: Community Rant

2017-08-22 Thread Sönke Ludwig via Digitalmars-d


Am 22.08.2017 um 17:14 schrieb Jonathan Shamir:
The DUB package repository is horrible! More often than not, the 
packages are so poorly written I end up just writing my own 
implementation. Adding the ability to "rate" packages would go a long 
way in improving the situation.


We are working on this point. There will be some form of popularity and 
quality measures, as well as top lists to discover notable projects.

Re: LDC, ARM: unnecessary default initialization

2017-08-22 Thread Johan Engelen via Digitalmars-d


On Tuesday, 22 August 2017 at 18:26:46 UTC, Johan Engelen wrote:


It was discussed briefly during my DConf 2016 talk


2017.

Re: LDC, ARM: unnecessary default initialization

2017-08-22 Thread Johan Engelen via Digitalmars-d


On Friday, 18 August 2017 at 12:09:04 UTC, kinke wrote:

On Friday, 18 August 2017 at 09:42:25 UTC, Jack Applegame wrote:
For some reason, the LDC default initializes the structure, 
even if initialization of all its members is specified as 
void. I believe that this is wrong.


Afaik, this has been brought up multiple times already and is 
so by design.


https://issues.dlang.org/show_bug.cgi?id=11331
https://issues.dlang.org/show_bug.cgi?id=11817
https://issues.dlang.org/show_bug.cgi?id=15951

It was discussed briefly during my DConf 2016 talk, and the 
status is that it is considered a performance bug. But it'll 
require spec changes / clarifications; Johannes listed a number 
already and maybe more it needed.


- Johan

Re: Type Inference in @safe unittests


On 8/22/17 2:19 PM, jmh530 wrote:

Yeah, this happens with @safe main also (below), but not for more 
regular local blocks. Anyway, I found it very confusing as that's not 
how I assumed @safe applied to unittests or main worked.


@safe void main()
{
 struct Foo {
 int foo(int i, string s) @safe { return 0; }
 double foo2(string s) @safe { return 0; }
 }
 printMemberTypes!(Foo);
}


The surprising part to me is that non-@safe main doesn't infer anything. 
Is that true?


-Steve

Re: HTOD

2017-08-22 Thread Steven Schveighoffer via Digitalmars-d


On 8/22/17 1:15 PM, Walter Bright wrote:

On 8/22/2017 8:14 AM, Jonathan Shamir wrote:

https://dlang.org/htod.html

I click download and get an exe!

And in the bugs section:
No linux version.

I'll start with the productive part. If anyone can point me out to the 
sources of htod I would love to compile for linux + osx. Any task 
seems more attractive to me than manually converting a 1000 line 
header to D.


You're right about htod, and it's on me. It's built out of the DMC++ 
front end. I haven't gotten around yet to releasing it as open source.


I downloaded it. The exe is last modified April 28, 2010, corresponding 
with DMD version 2.044.


This can't possibly produce valid D headers for 2.075.1. I think it 
should be either updated or removed from the web site.


-Steve

Re: Type Inference in @safe unittests

2017-08-22 Thread Steven Schveighoffer via Digitalmars-d-learn

On Tuesday, 22 August 2017 at 16:27:05 UTC, Jonathan M Davis 
wrote:


Well, templates aren't the only case where we have attribute 
inference anymore (e.g. auto return functions have it), and I'm 
pretty sure that there have been several requests for fixing 
issues regards to local declarations so that they have 
inference (in particular, I think that there have been 
complaints about marking a function as pure having issues with 
internal declarations then not being treated as pure even 
though they could be). And for better or worse, the trend has 
been towards adding inference in cases where it's guaranteed 
that the code will always be available and will be available to 
any code using that code - and in the case of a declaration 
inside of a function like that, it's guaranted that anything 
referencing it is going to have access to the code. So, it 
doesn't surprise me at all if attribute inference has been 
added to local declarations like this. If you want to guarantee 
that no inference is happening, then you'll probably have to 
declare it directly in the module where it can't be infered due 
to the fact that a .di file could redeclare it without any 
function bodies.


- Jonathan M Davis


Yeah, this happens with @safe main also (below), but not for more 
regular local blocks. Anyway, I found it very confusing as that's 
not how I assumed @safe applied to unittests or main worked.


@safe void main()
{
struct Foo {
int foo(int i, string s) @safe { return 0; }
double foo2(string s) @safe { return 0; }
}
printMemberTypes!(Foo);
}

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


On 8/22/17 12:15 PM, Kagamin wrote:
https://issues.dlang.org/show_bug.cgi?id=6585 is this fixed too? How 
various opIndex will behave now?


Seems to work. I closed as a duplicate.

-Steve

[Issue 14246] RAII - proper destruction of partially constructed objects/structs

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

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

https://github.com/dlang/dlang.org/commit/45ca5e35d3de824e104c3049083eb23fa03775c5
Remove wrong changelog entry

--

[Issue 13262] Cannot send certain shared data to another thread

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||c...@klickverbot.at

--- Comment #6 from Steven Schveighoffer  ---
*** Issue 6585 has been marked as a duplicate of this issue. ***

--

[Issue 6585] std.variant cannot handle shared arrays

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
 Resolution|--- |DUPLICATE

--- Comment #4 from Steven Schveighoffer  ---
Should be fixed by PR in 13262. Almost the exact code in the OP's comment is
now in a unit test:
https://github.com/dlang/phobos/blob/752fc0323a92d37056bb373cf8b91885a6406320/std/variant.d#L1390

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

--

Re: HTOD

2017-08-22 Thread Jonathan Shamir via Digitalmars-d


On Tuesday, 22 August 2017 at 17:15:27 UTC, Walter Bright wrote:

You're right about htod, and it's on me. It's built out of the 
DMC++ front end. I haven't gotten around yet to releasing it as 
open source.


We can discuss possible ways of implementing htod.

Instead, I'd rather discuss how we can make D more approachable 
and attractive to people thinking of picking up the language.


In that respect, as far as htod goes, I think it should be 
removed from the site (it could still be available online). D 
can't have an official command line utility that doesn't work.


Small steps.

[Issue 17604] Reject mutable fields initialized with reference types to data segment

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

--- Comment #4 from Steven Schveighoffer  ---
There's a certain extra weight attached to such a low bug number, especially
when it has so many duplicates.

--

[Issue 17771] foreach over const input range fails

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

--- Comment #10 from Steven Schveighoffer  ---
It's actually counter-intuitive for the D compiler to strip qualifiers
automatically, it almost never happens.

The only place I'm aware of is IFTI for arrays and pointers.

I feel like this is a case of being helpful, but will be confusing because it's
not consistent for all ranges. Experience shows that the benefit is not worth
the confusion.

But I am not the decider of such things, so I will leave it up to Walter/Andrei
to comment.

--

Re: HTOD

2017-08-22 Thread 12345swordy via Digitalmars-d


On Tuesday, 22 August 2017 at 17:15:27 UTC, Walter Bright wrote:

On 8/22/2017 8:14 AM, Jonathan Shamir wrote:

[...]


You're right about htod, and it's on me. It's built out of the 
DMC++ front end. I haven't gotten around yet to releasing it as 
open source.


[...]


Use Clang frontend?

[Issue 17604] Reject mutable fields initialized with reference types to data segment

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

--- Comment #3 from Vladimir Panteleev  ---
Thanks. Definitely not surprised this was filed before. I prefer the
description on this bug but I'm a little biased ;)

--

HTOD


On 8/22/2017 8:14 AM, Jonathan Shamir wrote:

https://dlang.org/htod.html

I click download and get an exe!

And in the bugs section:
No linux version.

I'll start with the productive part. If anyone can point me out to the sources 
of htod I would love to compile for linux + osx. Any task seems more attractive 
to me than manually converting a 1000 line header to D.


You're right about htod, and it's on me. It's built out of the DMC++ front end. 
I haven't gotten around yet to releasing it as open source.


The second problem is the DMC++ front end is tuned to deal with Windows compiler 
extensions, not Linux compiler extensions. So compiling it and running it on 
Linux will fail because every non-trivial C header file writer is unable to 
resist using every extension.


There's also the gcc problem with its reliance on many hundreds (!) of 
predefined macros that are turned on/off by various gcc compiler switches. It's 
a madhouse. And, of course, every gcc on every platform has a different set of 
these. The situation was so bad that when I developed Warp (a fast C 
preprocessor) I left the predefined list up to the user to load from a special file.


gcc on Ubuntu has 240 predefined macros when using the default switches. Who 
knows what the full list actually is.


gcc -dM -E - https://stackoverflow.com/questions/2224334/gcc-dump-preprocessor-defines

[Issue 17771] foreach over const input range fails

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

--- Comment #9 from Alex Goltman  ---
Asking the user to use a converter makes sense when the user understands
there's a reason to convert. 
Here it's counter-intuitive - the error stating foreach doesn't work with a
const actually made me question whether foreach over a range modifies the range
I give it, and I've somehow been unaware of this the whole time. 
The current state is more confusing IMHO.

--

Re: DerelictGL3 reload crashes in 32 builds

2017-08-22 Thread Igor via Digitalmars-d-learn


On Tuesday, 22 August 2017 at 12:03:18 UTC, Igor wrote:

On Monday, 21 August 2017 at 12:38:28 UTC, Mike Parker wrote:


Have you tried to compile outside of VisualD?


Hmmm... I though I tried running with just typing dub which 
should use m32 by default as far as I know and got the error. I 
will check one more time this evening. But LDC 32bit builds 
crash for sure. Note that I committed a version last night 
where I commented out the Derelict.reload call, so just make 
sure it is not commented before trying it out.


I must have remembered it wrong. I just tried it again and DMD 
32bit debug build works. It is DMD 32bit release build that is 
not working. When I run dub --build=release --force I get:

...
Error object.Error@(0): Access Violation

0x59BED731
0x5A6202C9 in wglGetProcAddress
0x004103B6
0x0040DC80
0x0040C691
Program exited with code 1

Re: Static inline field initialization

2017-08-22 Thread H. S. Teoh via Digitalmars-d

On Tue, Aug 22, 2017 at 04:28:43PM +, Moritz Maxeiner via Digitalmars-d 
wrote:
[...]
> I'd argue that - as new in this case doesn't allocate on the heap, but
> in the resulting application's appropriate segments) - it should work
> like this (from a language semantics standpoint):
> 
> ---
> 
> class Test
> {
> shared(ubyte)[] buf = new shared(ubyte)[1000]; // classic global
> storage, instances in all threads refer to the same static array
> }
> 
> class Test
> {
> ubyte[] buf = new ubyte[1000]; // thread local storage, instances in the
> same thread refer to the same static array
> }
> ---

Sounds like a good idea.  Please file this in bugzilla (if it isn't
already) so that it doesn't get lost in the ether.


T

-- 
Two wrongs don't make a right; but three rights do make a left...

[Issue 17773] this template parameter not working from derived class

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

Martin Nowak  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All
   Severity|enhancement |normal

--

[Issue 17773] New: this template parameter not working from derived class

2017-08-22 Thread Jonathan M Davis via Digitalmars-d-learn

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

  Issue ID: 17773
   Summary: this template parameter not working from derived class
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
class Base
{
this(size_t size)
{
}

size_t classSize(this This)()
{
pragma(msg, This);
return This.sizeof;
}
}

class Derived : Base
{
this()
{
super(classSize);
}

void foo()
{
classSize;
}
}

void test()
{
auto derived = new Derived;
auto size = derived.classSize;
}
CODE
dmd -c bug

bug.d(18): Error: constructor bug.Base.this (ulong size) is not callable using
argument types (void)
bug.d(23): Error: template classSize(this This)() has no type
Derived


Seems like template this parameters are not correctly resolved/inferred when
calling such methods from a derived instance.

--

Re: Static inline field initialization

2017-08-22 Thread Moritz Maxeiner via Digitalmars-d


On Tuesday, 22 August 2017 at 15:52:48 UTC, Kagamin wrote:
On Tuesday, 22 August 2017 at 14:53:21 UTC, Moritz Maxeiner 
wrote:
There is a bug [1] - as others have pointed out - that the 
static array isn't stored in TLS, but in global storage, 
however, but that doesn't apply in this single threaded case.


The initializer is copied from typeinfo, that can't refer to 
TLS data.


Which means it isn't easily fixable (or even feasible). I'd still 
consider it a loophole in the type system right now as it allows 
declaring global data mutably shared between threads without 
`shared` or `__gshared` (the latter of which couldn't be applied 
here, though).
I'd argue that - as new in this case doesn't allocate on the 
heap, but in the resulting application's appropriate segments) - 
it should work like this (from a language semantics standpoint):


---

class Test
{
shared(ubyte)[] buf = new shared(ubyte)[1000]; // classic 
global storage, instances in all threads refer to the same static 
array

}

class Test
{
ubyte[] buf = new ubyte[1000]; // thread local storage, 
instances in the same thread refer to the same static array

}
---

Re: Type Inference in @safe unittests

On Tuesday, August 22, 2017 16:11:11 jmh530 via Digitalmars-d-learn wrote:
> I'm not sure if this is a bug or not.
>
> I was playing around with printing out some member types with
> unittests and I was noticing some strange results when they were
> in @safe unittests rather than normal unittests. The first one
> prints out what I would expect, but the @safe unittest puts @safe
> @nogc nothrow and pure on them, as if it is re-writing the struct
> as a template (or maybe just the functions as templates, I don't
> know).
>
> private enum isPrivate(T, string member) = !__traits(compiles,
> __traits(getMember, T, member));
>
> void printMemberTypes(alias T)()
> {
>  foreach(memberName; __traits(allMembers, T))
>  {
>  static if(!isPrivate!(T, memberName)) {
>  writeln(typeid(typeof(__traits(getMember, T,
> memberName;
>  }
>  }
> }
>
> unittest
> {
>  struct Foo {
>  int foo(int i, string s) @safe { return 0; }
>  double foo2(string s) @safe { return 0; }
>  }
>
>  printMemberTypes!(Foo);
> }
>
> @safe unittest
> {
>  struct Foo {
>  int foo(int i, string s) @safe { return 0; }
>  double foo2(string s) @safe { return 0; }
>  }
>
>  printMemberTypes!(Foo);
> }

Well, templates aren't the only case where we have attribute inference
anymore (e.g. auto return functions have it), and I'm pretty sure that there
have been several requests for fixing issues regards to local declarations
so that they have inference (in particular, I think that there have been
complaints about marking a function as pure having issues with internal
declarations then not being treated as pure even though they could be). And
for better or worse, the trend has been towards adding inference in cases
where it's guaranteed that the code will always be available and will be
available to any code using that code - and in the case of a declaration
inside of a function like that, it's guaranted that anything referencing it
is going to have access to the code. So, it doesn't surprise me at all if
attribute inference has been added to local declarations like this. If you
want to guarantee that no inference is happening, then you'll probably have
to declare it directly in the module where it can't be infered due to the
fact that a .di file could redeclare it without any function bodies.

- Jonathan M Davis

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

2017-08-22 Thread Kagamin via Digitalmars-d-learn

https://issues.dlang.org/show_bug.cgi?id=6585 is this fixed too? 
How various opIndex will behave now?

[Issue 6585] std.variant cannot handle shared arrays

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

--- Comment #3 from anonymous4  ---
std.concurrency problem is fixed in issue 13262, though don't know if it
applies to all uses of variant.

--

Type Inference in @safe unittests


I'm not sure if this is a bug or not.

I was playing around with printing out some member types with 
unittests and I was noticing some strange results when they were 
in @safe unittests rather than normal unittests. The first one 
prints out what I would expect, but the @safe unittest puts @safe 
@nogc nothrow and pure on them, as if it is re-writing the struct 
as a template (or maybe just the functions as templates, I don't 
know).


private enum isPrivate(T, string member) = !__traits(compiles, 
__traits(getMember, T, member));


void printMemberTypes(alias T)()
{
foreach(memberName; __traits(allMembers, T))
{
static if(!isPrivate!(T, memberName)) {
writeln(typeid(typeof(__traits(getMember, T, 
memberName;

}
}
}

unittest
{
struct Foo {
int foo(int i, string s) @safe { return 0; }
double foo2(string s) @safe { return 0; }
}

printMemberTypes!(Foo);
}

@safe unittest
{
struct Foo {
int foo(int i, string s) @safe { return 0; }
double foo2(string s) @safe { return 0; }
}

printMemberTypes!(Foo);
}

[Issue 6585] std.variant cannot handle shared arrays

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

anonymous4  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=13262

--

[Issue 13262] Cannot send certain shared data to another thread

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

anonymous4  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=6585

--

[Issue 13262] Cannot send certain shared data to another thread

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

anonymous4  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Mac OS X|All

--

Re: Community Rant

2017-08-22 Thread Guillaume Piolat via Digitalmars-d


On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir wrote:
The DUB package repository is horrible! More often than not, 
the packages are so poorly written I end up just writing my own 
implementation. Adding the ability to "rate" packages would go 
a long way in improving the situation.

+1
There are lots of hidden gems in code.dlang.org and (maybe) some 
metrics to consider to measure relevance: frequency of 
tags/commits, number of contributors, Github stars or forks, 
number of dependent packages, download count per week...

Re: std.format expand "%s"

On Monday, 21 August 2017 at 15:39:04 UTC, Steven Schveighoffer 
wrote:


What I mean is that %s goes to %d for isIntegral!(typeof(x)), 
and %s goes to %g for isFloatingPoint!(typeof(x)), and stays as 
%s for everything else.


Given this, you could probably write the function you were 
looking for.


-Steve


I realized I was more interested in the length of the result than 
the type.

Re: Community Rant

2017-08-22 Thread Jonathan M Davis via Digitalmars-d

On Tuesday, August 22, 2017 15:14:33 Jonathan Shamir via Digitalmars-d 
wrote:
> https://dlang.org/htod.html
>
> I click download and get an exe!
>
> And in the bugs section:
> No linux version.
>
> I'll start with the productive part. If anyone can point me out
> to the sources of htod I would love to compile for linux + osx.
> Any task seems more attractive to me than manually converting a
> 1000 line header to D.

>From what I recall, it works pretty poorly anyway. As unpleasant as it may
seem, the only way that I'd really consider converting a C header file would
be by hand. If you want an automated solution though, dstep is probably the
better way to go.

http://code.dlang.org/packages/dstep

I'm not sure tha anyone has touched htod in years. dstep certainly will have
issues (as will any automated solution), but I believe that it's better
maintained and would expect it to do a better job.

> The DUB package repository is horrible! More often than not, the
> packages are so poorly written I end up just writing my own
> implementation.

Well, that depends entirely on the individual package maintainers. At least
there's actually a place to go find such projects now. It used to be that
there really wasn't a good place to go find any D libraries, and there
weren't very many around. So, while the situation may not be ideal and could
certainly use some improvement, it has improved considerably in recent
years.

> Adding the ability to "rate" packages would go a
> long way in improving the situation.

It's been brought up before, and I expect that it will happen at some point.
But it's the kind of thing that not many folks want to work on, so it's
likely to suffer. It's probably the sort of thing where it would make sense
for the dlang foundation to pay someone to do that now that they're able to
do that at least occassionally. Someone would probably still have to show
interest in doing the work though.

> I understand hacking the frontend is way more interesting to most
> of the community. But if we don't find the time to improve on our
> visibility and language maturity, D will never get the attention
> it deserves.

Honestly, I think that the library gets more attention than the compiler.
But in general, what gets done is what the person doing the work wants done
regardless of whether that's the best thing to be doing for the community as
a whole, and that's often how it goes with open source projects. Certainly,
if you're looking for large additions to the standard library, that requires
quite a big commitment in terms of time and effort to get it through the
Phobos review process, and it seems that most folks these days simply don't
want to do that. They'd rather just put their code up on code.dlang.org. A
lot of small stuff does get done to Phobos all the time though. And if you
compare what D's standard library has to what C++'s standard library has, D
really doesn't look that bad. It has a lot of stuff that C++ doesn't. But
there are some areas that C++ does better that we need to improve upon (e.g.
containers - though supposedly Andrei and/or is supervising one of his
students on them; they'd made some progress that they talked about at the
last dconf, but whatever they're up to hasn't matured enough to make it into
Phobos yet).

If you're looking to have the amount of stuff that a language like Java or
C# has in their standard libraries though, I think that you're forever going
to be disappointed. There simply isn't enough manpower for that to happen,
and it would likely require folks being paid fulltime to work on a lot of
it, and that certainly isn't happening. Almost all of what gets done for the
compiler and standard libraries is what folks are doing in their free time.

- Jonathan M Davis

[Issue 9183] Add a Nullable.get(x) overload

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

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

https://github.com/dlang/phobos/commit/1c071c2176b3ef4552f70e4fefc78f4ebe9d748c
Fix Issue 9183 - Add a Nullable.get(x) overload

https://github.com/dlang/phobos/commit/752fc0323a92d37056bb373cf8b91885a6406320
Merge pull request #5695 from RazvanN7/Issue_9183

Fix Issue 9183 - Add a Nullable.get(x) overload
merged-on-behalf-of: Jack Stouffer 

--

Re: Community Rant

2017-08-22 Thread Jonathan Shamir via Digitalmars-d


On Tuesday, 22 August 2017 at 15:48:17 UTC, Kagamin wrote:
Other possibilities can be dstep or cpp2d from visuald project. 
Though don't know if the latter can work on linux.


So I guess someone should pick one and put it on the site. And 
make sure the source code is available. Having a link to a broken 
unusable utility on the main language website looks bad, to say 
the least.

Re: Static inline field initialization

2017-08-22 Thread Kagamin via Digitalmars-d


On Tuesday, 22 August 2017 at 14:53:21 UTC, Moritz Maxeiner wrote:
There is a bug [1] - as others have pointed out - that the 
static array isn't stored in TLS, but in global storage, 
however, but that doesn't apply in this single threaded case.


The initializer is copied from typeinfo, that can't refer to TLS 
data.

Re: @safe(bool)

2017-08-22 Thread Jonathan M Davis via Digitalmars-d

On Tuesday, August 22, 2017 09:11:13 Steven Schveighoffer via Digitalmars-d 
wrote:
> On 8/21/17 9:20 PM, Jonathan M Davis via Digitalmars-d wrote:
> > Regardless, it means that I would need to run a tool to figure out which
> > attributes actually applied to a function rather than just reading it
> > like I could do now. And the fact that this is can be done with UDAs
> > right now is _not_ a plus. I can understand wanting to reduce the
> > number of attributes being manually applied to functions, but I think
> > that hiding them with aliases and/or combined attributes is a
> > maintenance nightmare and would argue that it's just plain bad
> > practice.
>
> Not for or against the DIP, but this is already the case, due to block
> attributes. I have to search around the file to find out whether pure:
> is at the top, etc. In fact, I've made recommendations many times on PRs
> to add an attribute to a function, to find out it's already handled at
> the top.
>
> I would think documentation generation should solve the issues.

Honestly, I tend to be against block attributes for this very reason, but at
least with block attributes, you can grep/search the file and find the
information. With this DIP, you potentially have to go looking in other
libraries to figure out which attributes actually apply, and you have to
track down every attribute on a function just to figure out whether a
built-in attribute applies to it. And I bet the documentation generation (at
least as it stands) would just put the custom attributes on there and not
translate them to their constituent attributes. But even if it put all of
the attributes on there individually, honestly, I think that it's a huge
negative if I have to run the documentation generation to figure out what
some code is doing. IMHO, I should be able to read the code and see what
it's doing without running extra tools or searching through several other
projects. Sometimes (particularly with more complicated code where you have
to understand other functionality to understand the stuff in front of you),
life doesn't work that way, but that should be the goal. And aliasing and
combining attributes goes completely against that goal. Stuff like block
attributes already harm it, but at least they're localized.

- Jonathan M Davis

Re: Community Rant

2017-08-22 Thread Kagamin via Digitalmars-d

Other possibilities can be dstep or cpp2d from visuald project. 
Though don't know if the latter can work on linux.

Re: Community Rant

2017-08-22 Thread Jonathan Shamir via Digitalmars-d


On Tuesday, 22 August 2017 at 15:24:54 UTC, ixid wrote:
On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir 
wrote:

various.


Out of interest did you pick up D before or after joining the 
start up? If before did you introduce D to them or were they 
already using it?


I work at weka.io. I learned D at weka, same as most of our 
workers (including the founders that looked for a powerful system 
programming language).

[Issue 17771] foreach over const input range fails

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

--- Comment #8 from Steven Schveighoffer  ---
(In reply to Alex Goltman from comment #7)
> Actually map does works on const NumRange, since it's declared as:
> 
> auto map(Range)(Range r) if (isInputRange!(Unqual!Range))

Yep, I didn't realize that, ironic that I picked map as the example :)

However, there are other functions that aren't checked this way, and most user
code isn't going to do this. It's the wrong way to approach this IMO.

> Why shouldn't foreach work as well? 

I'll leave the issue open, as there obviously are some in the core team who
find such subtleties worth considering, given the state of std.algorithm. I
still don't these kinds of tricks are worth the confusion they can cause,
especially when a suitable converter is easily had and used.

--

Re: Community Rant

2017-08-22 Thread ixid via Digitalmars-d


On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir wrote:

various.


Out of interest did you pick up D before or after joining the 
start up? If before did you introduce D to them or were they 
already using it?

Re: GStreamer issues.

2017-08-22 Thread Mike Wey via Digitalmars-d-learn


On 22-08-17 02:13, Johnson wrote:

I can't get the example to work(although slightly modified).

The installed version of GStreamer is 1.12.2
The file is: D:\temp\test.ogg
Loading
Setting to PLAYING.
Running.
XError: Could not demultiplex stream. dbug: gstoggdemux.c(4418): 
gst_ogg_demux_find_chains (): 
/GstPipeline:audio-player/GstOggDemux:ogg-parser:

can't get first chain

Actually I was getting a much worse error before ;/ I can't remember it 
now.



The installed version of GStreamer is 1.12.2
The file is: D:\temp\test2.wav
Loading
Setting to PLAYING.
Running.
XError: Internal data stream error. dbug: gstwavparse.c(2249): 
gst_wavparse_loop (): /GstPipeline:audio-player/GstWavParse:wav-parser:

streaming stopped, reason not-linked (-1)

Basically all I did was change the sink:

 sink = ElementFactory.make("autoaudiosink", "auto-output");

So it I could get past the error about alsa. I think the last name 
doesn't matter?


I downloaded the gstreamer binaries from their site, had some issues 
with a few of the dll's complaining about gxx errors, I removed 
them(h264, soundtouch, tag).



For the wav I changed
 //parser = ElementFactory.make("oggdemux", "ogg-parser");
 //decoder = ElementFactory.make("vorbisdec", "vorbis-decoder");
 parser = ElementFactory.make("wavparse", "wav-parser");
 decoder = ElementFactory.make("audioconvert", "wav-decoder");


which, is all i could find on line, I don't know if it's right at all.


Ultimately I want to be able to read somewhat arbitrary audio 
formats(most common at least), get the raw channel data(samples for each 
channel), play/pause/stop with good accuracy(no latency or low 
latency(<20ms), possibly do some pitch shifting and basic mixing(EQ, 
limiting, panning, etc), and eventually play some videos.


Is GstreamerD going to be useful for this or so I look in to using 
ffmpeg directly and do some of the stuff(e.g., eq) myself?


Thanks.


The Gstreamer demo should use an `playbin` instead of explicitly setting 
the pipeline, Like this: 
https://github.com/gtkd-developers/GtkD/blob/master/demos/gstreamer/helloworld/gstreamer_helloworld.d


This way gstreamer will detect the file type, i don't know if it helps 
with the errors.


--
Mike Wey

Community Rant

2017-08-22 Thread Jonathan Shamir via Digitalmars-d


https://dlang.org/htod.html

I click download and get an exe!

And in the bugs section:
No linux version.

I'll start with the productive part. If anyone can point me out 
to the sources of htod I would love to compile for linux + osx. 
Any task seems more attractive to me than manually converting a 
1000 line header to D.


I'm a D lover and advocate. I actually get a salary writing D 
code for a cutting-edge startup.


But lets be honest. If I was just interested to learn about this 
"modern system programming language" that is C++ done right, I 
would dismiss D very quickly. We need to get together as a 
community and rethink your priorities, because with problems like 
this we're making it very hard for newcomers to trust in this 
very poorly adapted language.


Programming tools used by day to day programmers should be a 
priority. Because everyone expects valgrind to work.


The standard library should be a priority. It's far from complete 
(hopefully my company will contribute in this respect in the near 
future).


The DUB package repository is horrible! More often than not, the 
packages are so poorly written I end up just writing my own 
implementation. Adding the ability to "rate" packages would go a 
long way in improving the situation.


I understand hacking the frontend is way more interesting to most 
of the community. But if we don't find the time to improve on our 
visibility and language maturity, D will never get the attention 
it deserves.


P.S. I don't know you guys (except Ali and Andrei which I had the 
honor to meet). I don't follow the forums. I'm sure you often 
speak about these topics here. So - if I offended anyone know 
it's not personal (I don't know who you are). I just want to 
share my impressions and experience as an actual day to day D 
user.

Hello World

2017-08-22 Thread Roffi Ulwn via Digitalmars-d


import std.stdio;

void main(char[][] args)
{
  writefln("Hello World");
}

Re: Static inline field initialization

2017-08-22 Thread Moritz Maxeiner via Digitalmars-d


On Tuesday, 22 August 2017 at 12:38:50 UTC, Jonas Mminnberg wrote:
On Tuesday, 22 August 2017 at 12:20:45 UTC, Moritz Maxeiner 
wrote:




I agree that it can be confusing if you try to read it with 
C++ semantics [1]; the solution, however, imho is not to 
change D semantics or throw warnings [2], but to refer to the 
D spec [3], which states that static initialization of class 
members is used instead of default initialization (before any 
constructors are run). To me that means a statically 
initialized class field shall have the same value in all class 
instances, i.e. it's not silent sharing, you explicitly 
requested the sharing. If that doesn't mean the same to 
others, the D spec wording should be updated to be clearer on 
the subject.
If you don't want instances to share a field value, instead of 
static initialization you can use constructor initialization 
[4]:



class Test
{
ubyte[] buf;
this()
{
buf = new ubyte[1000];
}
 }

void main()
{
auto a = new Test();
auto b = new Test();
assert(a.buf.ptr != b.buf.ptr);
}


I know that it is according to the standard but since D has 
gone out of it's way to make sure sharing doesn't occur 
otherwise, by defaulting to TLS storage etc,


While I can understand the sentiment, there is a difference 
between sharing data between threads and sharing data between 
class instances in the same thread, the latter of which is 
occurring here.
There is a bug with static field initializers (as others have 
pointed out), but it's about the fact that the array is stored in 
global storage and not in TLS and doesn't apply in the example 
above.



I feel this breaks the "no surprises" rule.
I took me a long time to find this out and when I mentioned it 
to other casual D programmers they also had no idea this was 
how it worked.


While I don't find how it works surprising personally (it's 
consistent with how static initialization works everywhere else 
in D) - in contrast to other subtleties in D - it might make be 
sensible to include this in the Dlang tour.

[Issue 17771] foreach over const input range fails

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

Alex Goltman  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #7 from Alex Goltman  ---
Actually map does works on const NumRange, since it's declared as:

auto map(Range)(Range r) if (isInputRange!(Unqual!Range))

Why shouldn't foreach work as well? 

It's not a critical bug, but fixing this would remove an annoyance which would
make D users much less frustrated. Please don't dismiss this before really
evaluating what would it take to fix it, because currently we don't see a
reason for this not to just work, as map does already.

--

Re: Static inline field initialization

2017-08-22 Thread Moritz Maxeiner via Digitalmars-d


On Tuesday, 22 August 2017 at 13:53:05 UTC, Daniel Kozak wrote:

s/buf/bug/

On Tue, Aug 22, 2017 at 3:52 PM, Daniel Kozak 
 wrote:


On Tue, Aug 22, 2017 at 2:20 PM, Moritz Maxeiner via 
Digitalmars-d < digitalmars-d@puremagic.com> wrote:


On Tuesday, 22 August 2017 at 11:50:50 UTC, Jonas Mminnberg 
wrote:



...



I agree that it can be confusing if you try to read it with 
C++ semantics [1]; the solution, however, imho is not to 
change D semantics or throw warnings [2], but to refer to the 
D spec [3], which states that static initialization of class 
members is used instead of default initialization (before any 
constructors are run). To me that means a statically 
initialized class field shall have the same value in all 
class instances, i.e. it's not silent sharing, you explicitly 
requested the sharing.




What? D spec does say nothing about sharing, its only speak 
about order, nothing else. So it is a buf from my POV.


It doesn't have to and it's not a bug (though considering the 
replies in this thread the wording should be changed to include 
that): D's builtin arrays consist of a pointer and a length; the 
example thus *explicitly* initializes both the pointer and the 
length to the same (static) value for all instances (as per 
spec), sharing them. There is a bug [1] - as others have pointed 
out - that the static array isn't stored in TLS, but in global 
storage, however, but that doesn't apply in this single threaded 
case.


[1] https://issues.dlang.org/show_bug.cgi?id=2947

[Issue 17718] [scope] function literal arguments can be escaped

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

--- Comment #2 from ZombineDev  ---
(Where line 9 is the `alias f = ...` same as in the original example.)

--

[Issue 17718] [scope] function literal arguments can be escaped

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

--- Comment #1 from ZombineDev  ---
If I change the structure to:

struct S
{
int p;
int* leak() return scope { return  }
}

I get:
scope_bug17718.d(9): Error: returning s.leak() escapes a reference to parameter
s, perhaps annotate with return

Where exactly is one supposed to add return?

--

Re: GtkD: New widget

2017-08-22 Thread Mike Wey via Digitalmars-d-learn


On 22-08-17 01:38, Johnson wrote:

On Monday, 21 August 2017 at 20:54:04 UTC, Mike Wey wrote:

On 21-08-17 03:45, Johnson Jones wrote:

[...]


If you want gtk to know about the functions you override you could use 
gtkd.Implement.ImplementCLass.


[...]


Thanks, I'll test it out when I get a chance. I was able to work around 
the issue for now but I imagine I'll need the ability to implement my 
own container in the future.


BTW, when I try to create a value I get an error about opCall

Value handleSize = new Value(0);

vs

Value handleSize = Value(0);

I'd rather not create a value on the heap when I only need it locally.

Could you add a way to create the value with the right type to Value?

Even static constructors would work(probably could templatize it).

Although, I'm not sure how much it matters since value itself seems to 
allocate on the heap ;/


 public this()
 {
 this(new GValue);
 }

But it might help reduce some memory waste.



`Value` is a class so you will need to use `new`.

--
Mike Wey

[Issue 17718] [scope] function literal arguments can be escaped

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

[Issue 17370] [scope] Escaping scope pointers possible via struct GC allocation

2017-08-22 Thread Sönke Ludwig via Digitalmars-d-announce

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--- Comment #1 from ZombineDev  ---
The issue is with only with the auto generated constructor. If you write one
yourself, you get:

void main () @safe
{
int* ptr = fwd();
assert(ptr !is null);
}

int* fwd () @safe
{
int i;
return new Struct().oops;
}

struct Struct
{
int* oops;
this(int* p) @safe { oops = p; }
}

scope_bug17370.d(10): Error: reference to local variable i assigned to
non-scope parameter p calling scope_bug17370.Struct.this

--

Third release candidate vibe.d 0.8.1-rc.3

The latest RC fixes a build issue with the OpenSSL 1.1.0 compatibility 
code and adds Meson build files.

[Issue 2947] Static initializer stored in mutable non-TLS global

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

anonymous4  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net

--- Comment #17 from anonymous4  ---
*** Issue 17604 has been marked as a duplicate of this issue. ***

--

[Issue 17604] Reject mutable fields initialized with reference types to data segment

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

anonymous4  changed:

   What|Removed |Added

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

--- Comment #2 from anonymous4  ---
Well, any type system violation is safety violation, so not sure about the
keyword.

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

--

[Issue 2947] Static initializer stored in mutable non-TLS global

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

anonymous4  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=15612
Summary|Array literal changeable if |Static initializer stored
   |part of class.  |in mutable non-TLS global

--- Comment #16 from anonymous4  ---
Class initializer from issue 11107:

class A{}
struct S
{
auto a = new A;
}

--

[Issue 15612] Break immutability with default initialisers

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

anonymous4  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=2947

--

Re: Static inline field initialization

2017-08-22 Thread Kagamin via Digitalmars-d


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

Re: Static inline field initialization

2017-08-22 Thread Daniel Kozak via Digitalmars-d

s/buf/bug/

On Tue, Aug 22, 2017 at 3:52 PM, Daniel Kozak  wrote:

> On Tue, Aug 22, 2017 at 2:20 PM, Moritz Maxeiner via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
>
>> On Tuesday, 22 August 2017 at 11:50:50 UTC, Jonas Mminnberg wrote:
>>
>>> ...
>>
>>
>> I agree that it can be confusing if you try to read it with C++ semantics
>> [1]; the solution, however, imho is not to change D semantics or throw
>> warnings [2], but to refer to the D spec [3], which states that static
>> initialization of class members is used instead of default initialization
>> (before any constructors are run). To me that means a statically
>> initialized class field shall have the same value in all class instances,
>> i.e. it's not silent sharing, you explicitly requested the sharing.
>>
>
> What? D spec does say nothing about sharing, its only speak about order,
> nothing else. So it is a buf from my POV.
>

Re: Static inline field initialization

2017-08-22 Thread Daniel Kozak via Digitalmars-d

On Tue, Aug 22, 2017 at 2:20 PM, Moritz Maxeiner via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On Tuesday, 22 August 2017 at 11:50:50 UTC, Jonas Mminnberg wrote:
>
>> ...
>
>
> I agree that it can be confusing if you try to read it with C++ semantics
> [1]; the solution, however, imho is not to change D semantics or throw
> warnings [2], but to refer to the D spec [3], which states that static
> initialization of class members is used instead of default initialization
> (before any constructors are run). To me that means a statically
> initialized class field shall have the same value in all class instances,
> i.e. it's not silent sharing, you explicitly requested the sharing.
>

What? D spec does say nothing about sharing, its only speak about order,
nothing else. So it is a buf from my POV.

[Issue 2947] Array literal changeable if part of class.

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

anonymous4  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=11107

--

[Issue 11107] variable initialized to mutable non-TLS global.

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

anonymous4  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=2947

--

[Issue 17604] Reject mutable fields initialized with reference types to data segment

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
Duplicate of 2947?

--

[Issue 2947] Array literal changeable if part of class.

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

anonymous4  changed:

   What|Removed |Added

   Keywords||accepts-invalid, spec
URL||https://dlang.org/spec/clas
   ||s.html#constructors
   Hardware|x86 |All
 OS|Linux   |All

--- Comment #15 from anonymous4  ---
Applicable to static variables too. Probably breaks @safety.

--

[Issue 17771] foreach over const input range fails

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

--- Comment #6 from Steven Schveighoffer  ---
(In reply to Eyal from comment #4)
> * Pointers are dereferenced in some contexts but not others
Not sure about this one. Perhaps an example can explain better?

> * Integers have valid init values, floats have invalid ones
And it is a cause of problems IMO, especially with generic code.

> * Arrays and slices have specific foreach behavior and not the input-range
> behavior
Again, causes lots of problems:
string s = "hello";
pragma(msg, typeof(s.front())); // immutable dchar
foreach(x; s)
   pragma(msg, typeof(x)); // immutable char

> * Tuples have special handling in the language
Since obsoleted with a better new feature (static foreach). Again, this is a
source of problems, and not meant as a model to follow.

--

[Issue 2947] Array literal changeable if part of class.

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

anonymous4  changed:

   What|Removed |Added

 CC||floating.po...@rambler.ru

--- Comment #14 from anonymous4  ---
*** Issue 13646 has been marked as a duplicate of this issue. ***

--

[Issue 13646] static darray & pointer initializers always allocated in shared(global) memory rather than in TLS

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

anonymous4  changed:

   What|Removed |Added

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

--- Comment #1 from anonymous4  ---


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

--

[Issue 17771] foreach over const input range fails