Re: It makes me sick!

On Friday, 28 July 2017 at 01:10:03 UTC, Mike Parker wrote: On Friday, 28 July 2017 at 00:28:52 UTC, FoxyBrown wrote: You are not being very logical. The zip file as N files in it. No matter what those files are, it should be a closed system. That is, if I insert or add(not replace) M file

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Friday, 28 July 2017 at 01:50:24 UTC, Jonathan M Davis wrote: On Friday, July 28, 2017 01:13:10 Nicholas Wilson via Digitalmars-d wrote: IIRC the reason they lack a leading @ is purely historical and considered not good but not worth breaking code over. I believe this DIP presents an

Re: DDox and filters.

yup figured it out - module documentation needs to go *above* the module declaration or you get nothing. On Fri, Jul 28, 2017 at 11:53 AM, Soulsbane via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > On Thursday, 27 July 2017 at 03:01:50 UTC, Danni Coy wrote: > >> I am trying

Re: DDox and filters.

On Thursday, 27 July 2017 at 03:01:50 UTC, Danni Coy wrote: I am trying to build my projects documentation via the ddox system via dub. It seems that my modules are being documented and then filtered out. Ironically for a documentation system there isn't a lot of documentation. What is the

Re: using DCompute

On Friday, 28 July 2017 at 01:30:58 UTC, Nicholas Wilson wrote: Yes, although I'll have to add an attribute shim layer for the dcompute druntime symbols to be accessible for DMD. When you compile LDC will produce .ptx and .spv files in the object file directory which will be able to be used

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Friday, July 28, 2017 01:13:10 Nicholas Wilson via Digitalmars-d wrote: > IIRC the reason they lack a leading @ is purely historical and > considered not good but not worth breaking code over. I believe > this DIP presents an opportunity and reason to make that change. > Existing code will

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Friday, 28 July 2017 at 01:26:19 UTC, Mike wrote: On Friday, 28 July 2017 at 01:13:10 UTC, Nicholas Wilson wrote: Terminology: I was confused by the term "attribute group". Although the term is defined in the DIP, it implies a combination of attributes rather than a mutually exclusive

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Friday, 28 July 2017 at 01:26:19 UTC, Mike wrote: On Friday, 28 July 2017 at 01:13:10 UTC, Nicholas Wilson wrote: Terminology: I was confused by the term "attribute group". Although the term is defined in the DIP, it implies a combination of attributes rather than a mutually exclusive

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote: DIP 1012 is titled "Attributes". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md Like others in this thread have said, it needs more rationale. The rationale only mentions one actual problem: attributes can't be undone

Re: using DCompute

On Friday, 28 July 2017 at 00:39:43 UTC, James Dean wrote: On Friday, 28 July 2017 at 00:23:35 UTC, Nicholas Wilson wrote: On Thursday, 27 July 2017 at 21:33:29 UTC, James Dean wrote: I'm interested in trying it out, says it's just for ldc. Can we simply compile it using ldc then import it and

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Friday, 28 July 2017 at 01:13:10 UTC, Nicholas Wilson wrote: Terminology: I was confused by the term "attribute group". Although the term is defined in the DIP, it implies a combination of attributes rather than a mutually exclusive attribute category. Still having trouble understanding

[Issue 17661] New isInputRange rejects valid input range

https://issues.dlang.org/show_bug.cgi?id=17661 --- Comment #4 from Andrei Alexandrescu --- hsteoh, could you please submit those as a separate bug report for dmd and create a phobos PR using the simplest workaround you can find? That PR would close this bug, and the other bug

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Friday, 28 July 2017 at 00:32:33 UTC, Mike wrote: On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote: DIP 1012 is titled "Attributes". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md Terminology: I was confused by the term "attribute group". Although the term is

Re: Silent error when using hashmap

On Thursday, 27 July 2017 at 14:09:37 UTC, Mike Parker wrote: 1. You can't expect exceptions thrown in a callback called from C to be propagated through the C side back into the D side. That includes errors. It happens on some platforms, but not all. On Windows, it does not (at least, not with

Re: It makes me sick!

On Friday, 28 July 2017 at 00:28:52 UTC, FoxyBrown wrote: You are not being very logical. The zip file as N files in it. No matter what those files are, it should be a closed system. That is, if I insert or add(not replace) M file to the directory structure it should not break D, period!

Re: using DCompute

On Friday, 28 July 2017 at 00:23:35 UTC, Nicholas Wilson wrote: On Thursday, 27 July 2017 at 21:33:29 UTC, James Dean wrote: I'm interested in trying it out, says it's just for ldc. Can we simply compile it using ldc then import it and use dmd, ldc, or gdc afterwards? The ability to write

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote: DIP 1012 is titled "Attributes". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md Terminology: I was confused by the term "attribute group". Although the term is defined in the DIP, it implies a combination of attributes

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Friday, 28 July 2017 at 00:20:25 UTC, jmh530 wrote: On Thursday, 27 July 2017 at 23:27:53 UTC, Nicholas Wilson wrote: Might be useful to mention why not included. This DIP focuses on function (i.e. @-like attributes), the rest of those attributes are storage classes/visibility classes

Re: It makes me sick!

On Thursday, 27 July 2017 at 23:37:41 UTC, Jonathan M Davis wrote: On Thursday, July 27, 2017 11:55:21 Ali Çehreli via Digitalmars-d-learn wrote: On 07/27/2017 11:47 AM, Adam D. Ruppe wrote: > On Thursday, 27 July 2017 at 18:35:02 UTC, FoxyBrown wrote: >> But the issue was about missing

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Thursday, 27 July 2017 at 23:27:53 UTC, Nicholas Wilson wrote: Might be useful to mention why not included. This DIP focuses on function (i.e. @-like attributes), the rest of those attributes are storage classes/visibility classes or parametric in a way that doesn't fit with this DIP

Re: using DCompute

On Thursday, 27 July 2017 at 21:33:29 UTC, James Dean wrote: I'm interested in trying it out, says it's just for ldc. Can we simply compile it using ldc then import it and use dmd, ldc, or gdc afterwards? The ability to write kernels is limited to LDC, though there is no practical reason

Re: @safe and null dereferencing

On Thu, Jul 27, 2017 at 09:32:12PM +, Moritz Maxeiner via Digitalmars-d wrote: > On Thursday, 27 July 2017 at 20:48:51 UTC, H. S. Teoh wrote: [...] > > If someone malicious has root access to your server, you already > > have much bigger things to worry about than D services hanging. :-D > >

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Thursday, 27 July 2017 at 18:06:41 UTC, jmh530 wrote: I think those are only for overwriting @nogc module, but the DIP should be more clear on this matter. I would assume you can import core.attribute to simplify that. core.attribute will be implicitly imported. That is the FQN. As a

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Thursday, 27 July 2017 at 16:56:14 UTC, ketmar wrote: Mike Parker wrote: DIP 1012 is titled "Attributes". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Thursday, 27 July 2017 at 17:35:34 UTC, Adrian Matoga wrote: I don't want to see monsters like "@core.attribute.GarbageCollectedness.inferred" as part of any declaration, ever. I agree that the problem is valid, but I don't think adding the complexity and verboseness presented in the DIP

Re: @safe and null dereferencing

On Thursday, July 27, 2017 13:48:51 H. S. Teoh via Digitalmars-d wrote: > On Thu, Jul 27, 2017 at 07:50:52PM +, Moritz Maxeiner via Digitalmars- d wrote: > > On Thursday, 27 July 2017 at 18:46:16 UTC, Jonathan M Davis wrote: > [...] > > > > I see no problem whatsoever requiring that the

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Thursday, 27 July 2017 at 15:48:04 UTC, Olivier FAURE wrote: On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote: DIP 1012 is titled "Attributes". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md This DIP proposes a very complex change (treating attributes as Enums),

Re: It makes me sick!

On Thursday, July 27, 2017 11:55:21 Ali Çehreli via Digitalmars-d-learn wrote: > On 07/27/2017 11:47 AM, Adam D. Ruppe wrote: > > On Thursday, 27 July 2017 at 18:35:02 UTC, FoxyBrown wrote: > >> But the issue was about missing symbols, not anything "extra". If > >> datatime.d is there but nothing

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Thursday, 27 July 2017 at 15:40:01 UTC, jmh530 wrote: On Thursday, 27 July 2017 at 14:58:22 UTC, Atila Neves wrote: _Why_ it works like that I have no idea. I thought that the attributes were just using the same behavior as public/private/etc. Anyway, isn't that the same type of

Re: @safe and null dereferencing

Am Thu, 27 Jul 2017 17:59:41 + schrieb Adrian Matoga : > On Thursday, 27 July 2017 at 17:43:17 UTC, H. S. Teoh wrote: > > On Thu, Jul 27, 2017 at 05:33:22PM +, Adrian Matoga via > > Digitalmars-d wrote: [...] > >> Why can't we just make the compiler insert null

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Thursday, 27 July 2017 at 14:58:22 UTC, Atila Neves wrote: "at the top of a file means that one can never "undo" those attributes" That's not true for `@safe`. This is perfectly legal: @safe: void foo() { ... }// foo is @safe void bar() @system { } // bar is @system _Why_ it works

Re: Pass range to a function

On 07/27/2017 02:16 PM, Chris wrote: > What is the value of `???` in the following program: > void categorize(??? toks) { > foreach (t; toks) { > writeln(t); > } > } The easiest solution is to make it a template (R is a suitable template variable name for a range type): void

Re: @safe and null dereferencing

On Thursday, 27 July 2017 at 20:48:51 UTC, H. S. Teoh wrote: On Thu, Jul 27, 2017 at 07:50:52PM +, Moritz Maxeiner via Digitalmars-d wrote: On Thursday, 27 July 2017 at 18:46:16 UTC, Jonathan M Davis wrote: [...] > I see no problem whatsoever requiring that the platform > segfaults when

using DCompute

I'm interested in trying it out, says it's just for ldc. Can we simply compile it using ldc then import it and use dmd, ldc, or gdc afterwards? --- a SPIRV capable LLVM (available here to build ldc to to support SPIRV (required for OpenCL)). or LDC built with any LLVM 3.9.1 or greater that

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote: Destroy! Extend rationale: could be application to templates and using with CTFE. "inferred" is not consistent. As I understand inferred applies to templates only. And default value is so called inferred_or_system. So it is

Pass range to a function

I'm using regex `matchAll`, and mapping it to get a sequence of strings. I then want to pass that sequence to a function. What is the general "sequence of strings" type declaration I'd need to use? In C#, it'd be `IEnumerable`. I'd rather not do a to-array on the sequence, if possible. (e.g.

Re: @safe and null dereferencing

On Thu, Jul 27, 2017 at 07:50:52PM +, Moritz Maxeiner via Digitalmars-d wrote: > On Thursday, 27 July 2017 at 18:46:16 UTC, Jonathan M Davis wrote: [...] > > I see no problem whatsoever requiring that the platform segfaults > > when you dereference null. Anything even vaguely modern will do >

Re: all OS functions should be "nothrow @trusted @nogc"

On 07/25/2017 10:54 PM, Walter Bright wrote: On 7/25/2017 8:26 AM, Andrei Alexandrescu wrote: A suite of safe wrappers on OS primitives might be useful. The idea of fixing the operating system interface(s) has come up now and then. I've tried to discourage that on the following grounds: *

Re: @safe and null dereferencing

On Thursday, 27 July 2017 at 20:09:46 UTC, Steven Schveighoffer wrote: Well, let's not forget that the services should not be dereferencing null. It's still a bug in the code. Of course, but statistically speaking, all software is buggy so it's not an unreasonable assumption on the

Re: why no statements inside mixin teplates?

On Friday, 12 May 2017 at 00:20:13 UTC, سليمان السهمي (Soulaïman Sahmi) wrote: Is there a rational behind not allowing statements inside mixin templates? I know mixin does accept code containing statements, but using mixin is much uglier. so I was wondering. example use case:

Re: Problem with dtor behavior

On Thursday, 27 July 2017 at 19:19:27 UTC, SrMordred wrote: //D-CODE struct MyStruct{ int id; this(int id){ writeln("ctor"); } ~this(){ writeln("dtor"); } } MyStruct* obj; void push(T)(auto ref T value){ obj[0] = value; } void main() { obj =

Re: @safe and null dereferencing

On 7/27/17 3:50 PM, Moritz Maxeiner wrote: On Thursday, 27 July 2017 at 18:46:16 UTC, Jonathan M Davis wrote: On Thursday, July 27, 2017 11:03:02 Steven Schveighoffer via Digitalmars-d wrote: A possibility: "@safe D does not support platforms or processes where dereferencing a null pointer

Randomed/encoded code

I would like to encode code in such a way that each compilation produces "random" code as compared to what the previous compilation produced, but ultimately the same code is ran each time(same effect). Basically we can code a function that does a job X in many different ways. Each way looks

Re: @safe and null dereferencing

On Thursday, 27 July 2017 at 18:46:16 UTC, Jonathan M Davis wrote: On Thursday, July 27, 2017 11:03:02 Steven Schveighoffer via Digitalmars-d wrote: A possibility: "@safe D does not support platforms or processes where dereferencing a null pointer does not crash the program. In such

Re: It makes me sick!

On Thursday, 27 July 2017 at 03:34:19 UTC, FoxyBrown wrote: Knowing that every time I upgrade to the latest "official" D compiler I run in to trouble: I recompiled gtkD with the new compiler, same result. My code was working before the upgrade just fine and I did not change anything. I've

Re: @safe and null dereferencing

On Thursday, 27 July 2017 at 17:52:09 UTC, H. S. Teoh wrote: On Thu, Jul 27, 2017 at 11:03:02AM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...] However, there do exist places where dereferencing null may NOT cause a segmentation fault. For example, see this post by Moritz Maxeiner:

Re: It makes me sick!

On 07/27/2017 12:24 PM, Steven Schveighoffer wrote: On 7/27/17 3:00 PM, Ali Çehreli wrote: On 07/27/2017 11:54 AM, Jonathan M Davis via Digitalmars-d-learn wrote: > You ended up with two versions of std.datetime. One was the module, and the > other was the package. I don't know how many

Re: It makes me sick!

On 7/27/17 3:00 PM, Ali Çehreli wrote: On 07/27/2017 11:54 AM, Jonathan M Davis via Digitalmars-d-learn wrote: > You ended up with two versions of std.datetime. One was the module, and the > other was the package. I don't know how many people install from the zip file but I think the zip

Re: @safe and null dereferencing

On 7/27/17 2:46 PM, Jonathan M Davis via Digitalmars-d wrote: However, one issue that has been brought up from time to time and AFAIK has never really been addressed is that apparently if an object is large enough, when you access one of its members when the pointer is null, you won't get a

Problem with dtor behavior

//D-CODE struct MyStruct{ int id; this(int id){ writeln("ctor"); } ~this(){ writeln("dtor"); } } MyStruct* obj; void push(T)(auto ref T value){ obj[0] = value; } void main() { obj = cast(MyStruct*)malloc( MyStruct.sizeof ); push(MyStruct(1)); }

Re: It makes me sick!

On 7/27/17 2:54 PM, Jonathan M Davis via Digitalmars-d-learn wrote: You ended up with two versions of std.datetime. One was the module, and the other was the package. importing std.datetime could have imported either of them. dmd _should_ generate an error in that case, but I don't know if it

Re: It makes me sick!

On 07/27/2017 11:54 AM, Jonathan M Davis via Digitalmars-d-learn wrote: > You ended up with two versions of std.datetime. One was the module, and the > other was the package. I don't know how many people install from the zip file but I think the zip file should include a datetime.d file with

[Issue 17699] New: Importing a module that has both modulename.d and modulename/package.d should be an error

https://issues.dlang.org/show_bug.cgi?id=17699 Issue ID: 17699 Summary: Importing a module that has both modulename.d and modulename/package.d should be an error Product: D Version: D2 Hardware: All OS: All

Re: D easily overlooked?

On Wednesday, 26 July 2017 at 22:18:37 UTC, kinke wrote: My point was improving vs. complaining. Both take some analysis to figure out an issue, but then some people step up and try to help improving things and some just let out their frustration, wondering why noone has been working on that

Re: It makes me sick!

On 07/27/2017 11:47 AM, Adam D. Ruppe wrote: On Thursday, 27 July 2017 at 18:35:02 UTC, FoxyBrown wrote: But the issue was about missing symbols, not anything "extra". If datatime.d is there but nothing is using it, why should it matter? YOU were using it with an `import std.datetime;` line.

Re: It makes me sick!

On 7/27/17 2:35 PM, FoxyBrown wrote: On Thursday, 27 July 2017 at 18:14:52 UTC, Steven Schveighoffer wrote: On 7/27/17 1:58 PM, FoxyBrown wrote: On Thursday, 27 July 2017 at 12:23:52 UTC, Jonathan M Davis wrote: On Wednesday, July 26, 2017 22:29:00 Ali Çehreli via Digitalmars-d-learn wrote:

Re: It makes me sick!

On Thursday, July 27, 2017 18:35:02 FoxyBrown via Digitalmars-d-learn wrote: > On Thursday, 27 July 2017 at 18:14:52 UTC, Steven Schveighoffer > > wrote: > > On 7/27/17 1:58 PM, FoxyBrown wrote: > >> On Thursday, 27 July 2017 at 12:23:52 UTC, Jonathan M Davis > >> > >> wrote: > >>> On Wednesday,

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Thu, 27 Jul 2017 14:44:23 +, Mike Parker wrote: > DIP 1012 is titled "Attributes". > > https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md 1. I would like to see consistency; I'd rather see @nogc and @gc than @nogc and @core.attributes.[whatever].gc, so all these attributes

Re: It makes me sick!

On Thursday, 27 July 2017 at 18:47:57 UTC, Adam D. Ruppe wrote: YOU were using it with an `import std.datetime;` line Of course, it is also possible that import was through a dependency of something you used, possibly including the standard library.

Re: @safe and null dereferencing

On Thursday, July 27, 2017 11:03:02 Steven Schveighoffer via Digitalmars-d wrote: > A possibility: > > "@safe D does not support platforms or processes where dereferencing a > null pointer does not crash the program. In such situations, > dereferencing null is not defined, and @safe code will not

Re: It makes me sick!

On Thursday, 27 July 2017 at 18:14:52 UTC, Steven Schveighoffer wrote: On 7/27/17 1:58 PM, FoxyBrown wrote: On Thursday, 27 July 2017 at 12:23:52 UTC, Jonathan M Davis wrote: On Wednesday, July 26, 2017 22:29:00 Ali Çehreli via Digitalmars-d-learn wrote: On 07/26/2017 09:20 PM, FoxyBrown

Static initialization of pointers

The D language specification under "Global and static initializers" [1], says the following: The Initializer for a global or static variable must be evaluatable at compile time. Whether some pointers can be initialized with the addresses of other functions or data is implementation defined.

Re: It makes me sick!

On Thursday, July 27, 2017 14:14:52 Steven Schveighoffer via Digitalmars-d- learn wrote: > On 7/27/17 1:58 PM, FoxyBrown wrote: > > I do not use the installer, I use the zip file. I assumed that > > everything would be overwritten and any old stuff would simply go > > unused.. but it seems it

Re: @safe and null dereferencing

On 7/27/17 2:09 PM, Steven Schveighoffer wrote: there's nothing in the spec to require it. And it does seem apparent that we handle this situation. that we *should* handle this situation. -Steve

Re: @safe and null dereferencing

On 7/27/17 1:52 PM, H. S. Teoh via Digitalmars-d wrote: On Thu, Jul 27, 2017 at 11:03:02AM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...] However, there do exist places where dereferencing null may NOT cause a segmentation fault. For example, see this post by Moritz Maxeiner:

Re: It makes me sick!

On 7/27/17 1:58 PM, FoxyBrown wrote: On Thursday, 27 July 2017 at 12:23:52 UTC, Jonathan M Davis wrote: On Wednesday, July 26, 2017 22:29:00 Ali Çehreli via Digitalmars-d-learn wrote: On 07/26/2017 09:20 PM, FoxyBrown wrote: >> Somebody else had the same problem which they solved by removing

Re: @safe and null dereferencing

On 7/27/17 1:33 PM, Adrian Matoga wrote: Why can't we just make the compiler insert null checks in @safe code? We can afford bounds checking even in @system -O -release. C++ can afford null check upon executing an std::function. The pointer would most likely be in a register anyway, and the

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Thursday, 27 July 2017 at 17:35:34 UTC, Adrian Matoga wrote: I don't want to see monsters like "@core.attribute.GarbageCollectedness.inferred" as part of any declaration, ever. I agree that the problem is valid, but I don't think adding the complexity and verboseness presented in the DIP

Re: @safe and null dereferencing

On Thu, Jul 27, 2017 at 11:03:02AM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...] > However, there do exist places where dereferencing null may NOT cause > a segmentation fault. For example, see this post by Moritz Maxeiner: >

Re: @safe and null dereferencing

On Thursday, 27 July 2017 at 17:43:17 UTC, H. S. Teoh wrote: On Thu, Jul 27, 2017 at 05:33:22PM +, Adrian Matoga via Digitalmars-d wrote: [...] Why can't we just make the compiler insert null checks in @safe code? Because not inserting null checks is a sacred cow we inherited from the

Re: It makes me sick!

On Thursday, 27 July 2017 at 12:23:52 UTC, Jonathan M Davis wrote: On Wednesday, July 26, 2017 22:29:00 Ali Çehreli via Digitalmars-d-learn wrote: On 07/26/2017 09:20 PM, FoxyBrown wrote: >> Somebody else had the same problem which they solved by removing >> >> "entire dmd": >>

Re: @safe and null dereferencing

On Thu, Jul 27, 2017 at 05:33:22PM +, Adrian Matoga via Digitalmars-d wrote: [...] > Why can't we just make the compiler insert null checks in @safe code? Because not inserting null checks is a sacred cow we inherited from the C/C++ days of POOP (premature optimization oriented programming),

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote: DIP 1012 is titled "Attributes". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on August

Re: @safe and null dereferencing

On Thursday, 27 July 2017 at 15:03:02 UTC, Steven Schveighoffer wrote: Inside the thread for adding @safe/@trusted attributes to OS functions, it has come to light that @safe has conflicting rules. For the definition of safe, it says: "Safe functions are functions that are statically checked

[Issue 17697] Ddoc: get rid of `_` detection in URLs

https://issues.dlang.org/show_bug.cgi?id=17697 --- Comment #2 from Vladimir Panteleev --- (In reply to Adam D. Ruppe from comment #1) > The correct solution is to get rid of the utterly counterproductive > identifier highlighting entirely, then remove the

Re: DIP 1012--Attributes--Preliminary Review Round 1

Mike Parker wrote: DIP 1012 is titled "Attributes". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on August 10 (3:59 AM GMT August 11), or when I make

Re: Hacking the compiler: Get Scope after some line of function

On Thursday, 27 July 2017 at 11:59:51 UTC, unDEFER wrote: So how to get scope e.g. after line "B b;"? I have found. That in scopes was found symbols from declarations, you must iterate by declarations (DeclarationExp) and add symbols by sc.insert(decexp.declaration);

Re: Profiling after exit()

On Thursday, 27 July 2017 at 14:44:31 UTC, Temtaime wrote: Also there was an issue that profiling doesn't work with multi-threaded apps and leads to a crash. Don't know if it is fixed. Was fixed two years ago: http://forum.dlang.org/post/mia2kf$djb$1...@digitalmars.com

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote: DIP 1012 is titled "Attributes". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md This DIP proposes a very complex change (treating attributes as Enums), but doesn't really provide a rationale for these changes. The

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Thursday, 27 July 2017 at 14:58:22 UTC, Atila Neves wrote: _Why_ it works like that I have no idea. I thought that the attributes were just using the same behavior as public/private/etc. Anyway, isn't that the same type of behavior this DIP is suggesting? There is an @nogc module

Re: Profiling after exit()

On Thursday, 27 July 2017 at 14:52:18 UTC, Stefan Koch wrote: On Thursday, 27 July 2017 at 14:30:33 UTC, Eugene Wissner wrote: I have a multi-threaded application, whose threads normally run forever. But I need to profile this program, so I compile the code with -profile, send a SIGTERM and

Re: all OS functions should be "nothrow @trusted @nogc"

On Thursday, 27 July 2017 at 14:45:03 UTC, Steven Schveighoffer wrote: On 7/27/17 10:20 AM, Moritz Maxeiner wrote: On Thursday, 27 July 2017 at 13:56:00 UTC, Steven Schveighoffer wrote: I'm fine with saying libraries or platforms that do not segfault when accessing zero page are incompatible

@safe and null dereferencing

Inside the thread for adding @safe/@trusted attributes to OS functions, it has come to light that @safe has conflicting rules. For the definition of safe, it says: "Safe functions are functions that are statically checked to exhibit no possibility of undefined behavior." In the definition

Re: all OS functions should be "nothrow @trusted @nogc"

On Thursday, 27 July 2017 at 11:46:24 UTC, Steven Schveighoffer wrote: On 7/27/17 2:48 AM, Jacob Carlborg wrote: And then the compiler runs the "Dead Code Elimination" pass and we're left with: void contains_null_check(int* p) { *p = 4; } So the result is that it will segfault. I don't

Re: DIP 1012--Attributes--Preliminary Review Round 1

On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote: DIP 1012 is titled "Attributes". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on August

Re: Profiling after exit()

On Thursday, 27 July 2017 at 14:30:33 UTC, Eugene Wissner wrote: I have a multi-threaded application, whose threads normally run forever. But I need to profile this program, so I compile the code with -profile, send a SIGTERM and call exit(0) from my signal handler to exit the program. The

DIP 1012--Attributes--Preliminary Review Round 1 Begins

The first preliminary review round of DIP 1012, "Attributes", has begun. http://forum.dlang.org/thread/rqebssbxgrchphyur...@forum.dlang.org Two reminders: The first preliminary round for DIP 1011 ends in ~24 hours. http://forum.dlang.org/thread/topmfucguenqpucsb...@forum.dlang.org The

Re: all OS functions should be "nothrow @trusted @nogc"

On 7/27/17 10:20 AM, Moritz Maxeiner wrote: On Thursday, 27 July 2017 at 13:56:00 UTC, Steven Schveighoffer wrote: On 7/27/17 9:24 AM, Moritz Maxeiner wrote: On Wednesday, 26 July 2017 at 01:09:50 UTC, Steven Schveighoffer wrote: I think we can correctly assume no fclose implementations exist

DIP 1012--Attributes--Preliminary Review Round 1

DIP 1012 is titled "Attributes". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on August 10 (3:59 AM GMT August 11), or when I make a post declaring it

Re: Profiling after exit()

Also there was an issue that profiling doesn't work with multi-threaded apps and leads to a crash. Don't know if it is fixed.

Re: Profiling after exit()

Exit is not "normal exit" for D programs so, do not use it. Your threads should stop at some point to make able the app exit successfully. There's a "join" method. You can use it with your "done" variable.

Profiling after exit()

I have a multi-threaded application, whose threads normally run forever. But I need to profile this program, so I compile the code with -profile, send a SIGTERM and call exit(0) from my signal handler to exit the program. The problem is that I get the profiling information only from the main

[Issue 5176] Limit static object sizes

https://issues.dlang.org/show_bug.cgi?id=5176 Steven Schveighoffer changed: What|Removed |Added CC|

Re: all OS functions should be "nothrow @trusted @nogc"

On Thursday, 27 July 2017 at 13:56:00 UTC, Steven Schveighoffer wrote: On 7/27/17 9:24 AM, Moritz Maxeiner wrote: On Wednesday, 26 July 2017 at 01:09:50 UTC, Steven Schveighoffer wrote: I think we can correctly assume no fclose implementations exist that do anything but access data pointed at

[Issue 5176] Limit static object sizes

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

Re: Silent error when using hashmap

On Thursday, 27 July 2017 at 00:07:39 UTC, FatalCatharsis wrote: I figured this was the case. WM_NCCREATE is probably sent first and the lookup fails. I'm more concerned with why there was no exceptions/debug output of any kind. There are a few things going on with your code. I'll break it

Re: all OS functions should be "nothrow @trusted @nogc"

On Thursday, 27 July 2017 at 13:45:21 UTC, ag0aep6g wrote: On 07/27/2017 03:24 PM, Moritz Maxeiner wrote: --- null.d --- version (linux): import core.stdc.stdio : FILE; import core.sys.linux.sys.mman; extern (C) @safe int fgetc(FILE* stream); void mmapNull() { void* mmapNull =

Re: all OS functions should be "nothrow @trusted @nogc"

On 7/27/17 9:24 AM, Moritz Maxeiner wrote: On Wednesday, 26 July 2017 at 01:09:50 UTC, Steven Schveighoffer wrote: I think we can correctly assume no fclose implementations exist that do anything but access data pointed at by stream. Which means a segfault on every platform we support. On

Re: all OS functions should be "nothrow @trusted @nogc"

On 07/27/2017 03:24 PM, Moritz Maxeiner wrote: --- null.d --- version (linux): import core.stdc.stdio : FILE; import core.sys.linux.sys.mman; extern (C) @safe int fgetc(FILE* stream); void mmapNull() { void* mmapNull = mmap(null, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS

Re: Destructors vs. Finalizers

For cycle in RC you either do it like other RC system and break cycles manually, or create a parent owner to own every things pointing to each other and having cycles. On Thursday, 27 July 2017 at 11:43:37 UTC, Steven Schveighoffer wrote: This is an unworkable solution. Not at all

  1   2   >