Re: CTFE Status

On Monday, 5 December 2016 at 04:26:35 UTC, Stefan Koch wrote: I just improved the handling of void initializations. Now the code is less pessimistic and will allow them if they are assigned to before use. However using void variables at ctfe will not result in any performance wins. I found

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

Dne 5.12.2016 v 08:39 Stefan Koch via Digitalmars-d napsal(a): On Monday, 5 December 2016 at 07:25:20 UTC, Daniel Kozak wrote: Dne 5.12.2016 v 06:03 Stefan Koch via Digitalmars-d napsal(a): On Monday, 5 December 2016 at 04:59:01 UTC, ketmar wrote: On Monday, 5 December 2016 at 04:41:55

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

On Monday, 5 December 2016 at 07:25:20 UTC, Daniel Kozak wrote: Dne 5.12.2016 v 06:03 Stefan Koch via Digitalmars-d napsal(a): On Monday, 5 December 2016 at 04:59:01 UTC, ketmar wrote: On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote: Hi Guys, What is your opinion, should we

[Issue 16856] D does not work on FreeBSD current (what will eventually be 12) due to libunwind

https://issues.dlang.org/show_bug.cgi?id=16856 Jacob Carlborg changed: What|Removed |Added CC||d...@me.com --- Comment #3

Re: Building with dub fails on Ubuntu 16.10.

On Saturday, 3 December 2016 at 16:07:47 UTC, moe wrote: On Sunday, 11 September 2016 at 02:17:21 UTC, Vlasov Roman wrote: Hello, guys. I tried to build HelloWorld with dub, but i got strange linker error: [...] I just switched from Windows to linux (arch) and got the exact same problem.

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

Dne 5.12.2016 v 06:03 Stefan Koch via Digitalmars-d napsal(a): On Monday, 5 December 2016 at 04:59:01 UTC, ketmar wrote: On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote: Hi Guys, What is your opinion, should we warn if we unambiguously detect something that is clearly unwanted

Re: How to use library compiled with Microsoft Visual Studio 2015 in D?

On 2016-12-05 07:44, unDEFER wrote: Hello! I have compiled libdb (BerkeleyDB) with Microsoft Visual Studio 2015. 1) "Debug" mode. I have libdb53d.dll file. Do implib. The linker doesn't seen symbols from the library! Do "lib -l". In the list of symbols "db_create", linker searches "_db_create".

How to use library compiled with Microsoft Visual Studio 2015 in D?

Hello! I have compiled libdb (BerkeleyDB) with Microsoft Visual Studio 2015. 1) "Debug" mode. I have libdb53d.dll file. Do implib. The linker doesn't seen symbols from the library! Do "lib -l". In the list of symbols "db_create", linker searches "_db_create". Is it the problem? 2)

[Issue 16856] D does not work on FreeBSD current (what will eventually be 12) due to libunwind

https://issues.dlang.org/show_bug.cgi?id=16856 --- Comment #2 from Jonathan M Davis --- If I compile and run this program void main() { throw new Exception("blah"); } I get a bus error, and if I run it in gdb, I get this stacktrace: #0 0x000800cd91bf in

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

On Monday, 5 December 2016 at 04:59:01 UTC, ketmar wrote: On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote: Hi Guys, What is your opinion, should we warn if we unambiguously detect something that is clearly unwanted ? int fn(int y) { int x = void; ++x; return x+y; } This

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

On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote: Hi Guys, What is your opinion, should we warn if we unambiguously detect something that is clearly unwanted ? int fn(int y) { int x = void; ++x; return x+y; } This requires data-flow analysis (The same kind that tells you

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

On Monday, 5 December 2016 at 04:41:55 UTC, Stefan Koch wrote: And will slow down compilation a little if we enable such a warning. I have thought it over again. We can make it such that, hit will be unnoticeable if you never use = void.

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

Hi Guys, What is your opinion, should we warn if we unambiguously detect something that is clearly unwanted ? int fn(int y) { int x = void; ++x; return x+y; } This requires data-flow analysis (The same kind that tells you if you are skipping a statement) And will slow down compilation

Re: CTFE Status

I just improved the handling of void initializations. Now the code is less pessimistic and will allow them if they are assigned to before use. However using void variables at ctfe will not result in any performance wins.

[Issue 11367] Include paths on windows do not recursively expand env vars

https://issues.dlang.org/show_bug.cgi?id=11367 Martin Krejcirik changed: What|Removed |Added Status|NEW |RESOLVED

Re: CTFE Status

On Sunday, 4 December 2016 at 23:10:34 UTC, Stefan Koch wrote: Also the fix for infinite loops has apparently cost us a lot of performance. I am not sure where this loss is coming from. Maybe I am just reading my scales wrong ;) it seemed to have t odo with the hardware being particularly

Re: ThinLTO is there. I think that should settle the final/virtual debate

On Sunday, 4 December 2016 at 19:49:15 UTC, NVolcz wrote: My understanding was that the main argument for final by default was that it is easy to make the wrong decision for a method to be virtual and then going from virtual to final would break the compatibility. I have a lot of experience

Re: [OT] Feedback on Cooperative Threading Project

On Sunday, 4 December 2016 at 01:18:45 UTC, rikki cattermole wrote: On 04/12/2016 5:54 AM, Benjamin Ylvisaker wrote: I am a grad school acquaintance of Andrei's. I contacted him a little while ago asking for feedback on a project that I'm working on. He suggested I post it to the D list. So

[Issue 16856] D does not work on FreeBSD current (what will eventually be 12) due to libunwind

https://issues.dlang.org/show_bug.cgi?id=16856 Jonathan M Davis changed: What|Removed |Added Summary|D is borked on FreeBSD |D does not

Re: CTFE Status

I just had a hunch about the continue statement within for-loops being treated incorrectly. let's see where it leads. Also the fix for infinite loops has apparently cost us a lot of performance. I am not sure where this loss is coming from. Maybe I am just reading my scales wrong ;) While

Re: CTFE Status

On Sunday, 4 December 2016 at 00:23:32 UTC, Stefan Koch wrote: On Sunday, 4 December 2016 at 00:14:26 UTC, Stefan Koch wrote: On Saturday, 3 December 2016 at 23:30:58 UTC, Stefan Koch wrote: [...] I figured out part of the reason for this bug. baically it's like this. [...] beginBlock:

[Issue 16948] broken links in std.stdio due to inccorrect use of WEB macro

https://issues.dlang.org/show_bug.cgi?id=16948 ag0ae...@gmail.com changed: What|Removed |Added Assignee|nob...@puremagic.com|ag0ae...@gmail.com --

[Issue 16948] broken links in std.stdio due to inccorrect use of WEB macro

https://issues.dlang.org/show_bug.cgi?id=16948 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com

Re: @property get/set or public varaible?

On Sunday, December 04, 2016 15:30:22 vladdeSV via Digitalmars-d-learn wrote: > Hello! > > I have a question not directly related to D as it is with coding > standards. > > My issue at hand is if I have one variable for a class, which I > want to be directly accessible for anything else, should

[Issue 16794] .deb not working on Ubuntu 16.10 because of default PIE linking

https://issues.dlang.org/show_bug.cgi?id=16794 Martin Nowak changed: What|Removed |Added Summary|Official .deb packages must |.deb not working on Ubuntu

Re: ThinLTO is there. I think that should settle the final/virtual debate

On Sunday, December 04, 2016 19:49:15 NVolcz via Digitalmars-d wrote: > On Sunday, 4 December 2016 at 01:36:50 UTC, deadalnix wrote: > > First, presentation: > > https://www.youtube.com/watch?v=9OIEZAj243g > > > > Some of this is available in LLVM today, and everything > > presented here will be

Re: wrong isInputRange design

On Sunday, December 04, 2016 13:37:35 rumbu via Digitalmars-d wrote: > I think that the array range UFCSs must be moved out from the > std.range.primitives and let the library user to decide if there > is a need for range semantics applied to all arrays. That's not happening. In fact, pretty much

Impressed with Appender - Is there design/implementation description?

I've been using Appender quite a bit recently, typically when I need append-only arrays with variable and unknown final sizes. I had been prepared to write a custom data structure when I started using it with large amounts of data, but very nicely this has not surfaced as a need. Appender has

Re: ThinLTO is there. I think that should settle the final/virtual debate

On Sunday, 4 December 2016 at 01:36:50 UTC, deadalnix wrote: First, presentation: https://www.youtube.com/watch?v=9OIEZAj243g Some of this is available in LLVM today, and everything presented here will be in 4.0 . The long story short: ThinLTO can do most of what LTO does but with a price

Re: D with CygWin

DONE!!! === $ cat try.d import std.stdio; import std.string; import cygwin.std.file; import cygwin.loader; void main() { CygwinInit(); foreach (string name; dirEntries("/", SpanMode.shallow)) { writefln(name);

Re: @property get/set or public varaible?

On Sunday, 4 December 2016 at 15:30:22 UTC, vladdeSV wrote: Are there any other reasons to use get/setters? basically, no. as you can omit parentheses in D, converting to getter/setter later should be seamless. the only reason to have getter/setter in your case is a situation where you may

Re: @property get/set or public varaible?

On Sunday, 4 December 2016 at 15:30:22 UTC, vladdeSV wrote: Hello! I have a question not directly related to D as it is with coding standards. My issue at hand is if I have one variable for a class, which I want to be directly accessible for anything else, should it be 1. public, or 2.

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

https://issues.dlang.org/show_bug.cgi?id=16654 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

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

https://issues.dlang.org/show_bug.cgi?id=16654 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to stable at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/5c187e05ff87404ebf4884cfc548324c2c3ed0fc Revert object.hashOf changes from "use array

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

https://issues.dlang.org/show_bug.cgi?id=16764 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

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

https://issues.dlang.org/show_bug.cgi?id=16764 --- Comment #2 from github-bugzi...@puremagic.com --- Commit pushed to stable at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/5c187e05ff87404ebf4884cfc548324c2c3ed0fc Revert object.hashOf changes from "use array

Re: ThinLTO is there. I think that should settle the final/virtual debate

On Sun, 04 Dec 2016 10:36:30 +, angel wrote: > IMHO it was always obvious that the proper way is "devirtualization" > within compiler optimization process. Incremental compilation. You can't in general do this in the compiler. * I write a library that uses std.socket:InternetHost. * You

@property get/set or public varaible?

Hello! I have a question not directly related to D as it is with coding standards. My issue at hand is if I have one variable for a class, which I want to be directly accessible for anything else, should it be 1. public, or 2. private, with @property get/setters? From what I have been

Re: wrong isInputRange design

On Sunday, 4 December 2016 at 13:37:35 UTC, rumbu wrote: There is nowhere in the documentation where arrays are advertised as ranges by default. Huh. It really doesn't seem to say so in the prose. It's shown in the examples for isInputRange, though: static assert(

Re: D with CygWin

I have found. I have to use cygwin_dll_init == $ cat try.d import std.stdio; import std.string; import core.sys.windows.windows; extern(C) { alias int function(const (char)*, int, ...) open_t; alias void function() init_t; alias void

[Issue 16854] Inline assembler has VMOVLHPS and VMOVHLPS swapped

https://issues.dlang.org/show_bug.cgi?id=16854 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/95c9e17d9dfc28dc5a09b0d152882f196b1de537 fix Issue 16854 - Inline assembler has VMOVLHPS and VMOVHLPS

[Issue 16949] New: [Reg 2.073] confusing @safe error message for fields with unsafe destructors

https://issues.dlang.org/show_bug.cgi?id=16949 Issue ID: 16949 Summary: [Reg 2.073] confusing @safe error message for fields with unsafe destructors Product: D Version: D2 Hardware: All OS: All

[Issue 16948] https doesn't replace http on dlang.org/phobos

https://issues.dlang.org/show_bug.cgi?id=16948 LucienPe changed: What|Removed |Added Keywords||ddoc --

[Issue 16948] New: https doesn't replace http on dlang.org/phobos

https://issues.dlang.org/show_bug.cgi?id=16948 Issue ID: 16948 Summary: https doesn't replace http on dlang.org/phobos Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: minor

[Issue 16947] New: The digest function calls the put function incorrectly.

https://issues.dlang.org/show_bug.cgi?id=16947 Issue ID: 16947 Summary: The digest function calls the put function incorrectly. Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW

Re: wrong isInputRange design

On Sunday, 4 December 2016 at 11:50:08 UTC, Mike Parker wrote: On Sunday, 4 December 2016 at 11:18:56 UTC, rumbu wrote: Of course, the previous code will compile if we change the imports: import std.range.primitives: isInputRange, front, popFront, empty; But that just prove the bad

Re: How to get hash value of an object?

On Tuesday, 29 November 2016 at 00:05:31 UTC, Steven Schveighoffer wrote: hashOf is kind of this horrible hacky thing that nobody should be using. It literally takes whatever you pass it and hashes the local bytes. Ugg... Anything with pointers, classes or arrays will have huge problems

Re: Proper generic way to get the hash of something?

On Sunday, 4 December 2016 at 06:51:24 UTC, Tofu Ninja wrote: So what is the proper way to get the hash of something now? This question came up a few days ago: http://forum.dlang.org/post/o1igoc$21ma$1...@digitalmars.com

Re: wrong isInputRange design

On Sunday, 4 December 2016 at 11:18:56 UTC, rumbu wrote: Of course, the previous code will compile if we change the imports: import std.range.primitives: isInputRange, front, popFront, empty; But that just prove the bad design of isInputRange which cannot be used all alone without the

Re: wrong isInputRange design

On Sunday, 4 December 2016 at 05:31:59 UTC, lobo wrote: This works for me when specialising for input ranges, strings and arrays. auto f(T)(T val) if(isInputRange!T && !isSomeString!T && !isArray!T) {} auto f(T)(T val) if(isSomeString!T) {} auto f(T)(T val) if(isArray!T &&

Re: ThinLTO is there. I think that should settle the final/virtual debate

On Sunday, 4 December 2016 at 01:36:50 UTC, deadalnix wrote: First, presentation: https://www.youtube.com/watch?v=9OIEZAj243g Some of this is available in LLVM today, and everything presented here will be in 4.0 . The long story short: ThinLTO can do most of what LTO does but with a price

Re: ThinLTO is there. I think that should settle the final/virtual debate

On Sunday, 4 December 2016 at 01:36:50 UTC, deadalnix wrote: First, presentation: https://www.youtube.com/watch?v=9OIEZAj243g Some of this is available in LLVM today, and everything presented here will be in 4.0 . The long story short: ThinLTO can do most of what LTO does but with a price

Re: [Derelict-GL3] GLSL: Syntax error unexpected tokens following #version

On Sunday, 4 December 2016 at 08:32:23 UTC, Mike Parker wrote: On Sunday, 4 December 2016 at 08:30:40 UTC, Mike Parker wrote: your shader, print out the result of glGetString(GL_VERSION) to Alternatively, since you're using Derelict, you can check the return value of DerelictGL3.reload()

Re: [Derelict-GL3] GLSL: Syntax error unexpected tokens following #version

On Sunday, 4 December 2016 at 08:30:40 UTC, Mike Parker wrote: your shader, print out the result of glGetString(GL_VERSION) to Alternatively, since you're using Derelict, you can check the return value of DerelictGL3.reload() or, any time after calling it, DerelictGL3.loadedVersion.

Re: [Derelict-GL3] GLSL: Syntax error unexpected tokens following #version

On Sunday, 4 December 2016 at 06:41:07 UTC, Payotz wrote: So I've been trying to teach myself how to OpenGL, and there are errors whenever I try to compile my shaders. Errors are : http://i.imgur.com/5hRaQL8.png Why the screenshot? Simpler to respond to copy/pasted text. The second line is