Re: Fix it for me!

On Tuesday, 31 January 2017 at 15:35:16 UTC, Adam D. Ruppe wrote: On Tuesday, 31 January 2017 at 14:56:32 UTC, cym13 wrote: That's not really the issue, the thing is this is not a forum, or not only. It's actually an interface to a mailing list and many people only use the mail so that

Re: Minimum PR size

On 2017-01-31 11:36, Jason Schroeder wrote: I am interested in contributing to D on GitHub, and was wondering if there is a minimum or preferabe minimum size of a pull request; e.g. I woukd like to work on increasing code coverage, and am wondering if a pull request with one additional line of

[Issue 17123] [REG 2.073] Issues with return @safe inference

https://issues.dlang.org/show_bug.cgi?id=17123 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/74f7a29935fe55a718a7bb92248e3c455bb4e105 fix Issue 17123 - [REG 2.073] Issues with return @safe

GC question

Hi all, I was looking at D as the next language to use in my hobby projects, but the "conservative GC" part in the language spec (http://dlang.org/spec/garbage.html) looks a bit concerning. I'm wondering what are the implications of the fact that current GC is a Boehm-style conservative GC

Re: memcpy() comparison: C, Rust, and D

Walter Bright wrote: > Rust says https://doc.rust-lang.org/1.14.0/libc/fn.memcpy.html: > > pub unsafe extern fn memcpy(dest: *mut c_void, > src: *const c_void, > n: size_t) > -> *mut

[Issue 17135] DMD hangs when compiling in release mode

https://issues.dlang.org/show_bug.cgi?id=17135 --- Comment #1 from Nick Sabalausky --- Forgot to include the relevent commit checkout: $ git clone https://github.com/Abscissa/SDLang-D.git sdlang $ cd sdlang $ git checkout 6b2097f6944 $ dub test --build=release --

LDC 1.1.0 released

Hi all, Version 1.1.0 of LDC, the LLVM-based D compiler, has finally been released: https://github.com/ldc-developers/ldc/releases/tag/v1.1.0 Please head over to the digitalmars.D.ldc forums for more details and discussions: http://forum.dlang.org/post/etynfqwjosdvuuukl...@forum.dlang.org

Re: struct: default construction or lazy initialization.

On Wednesday, 1 February 2017 at 00:43:39 UTC, bitwise wrote: Container!int c; // = Container!int() -> can't do this. Can you live with Container!int c = Container!int.create(); because D supports that and can force the issue with `@disable this();` which causes compilation to fail any

capture stdout or stderr

is it possible to intercept the STDOUT or STDERR and capture the output into a variable ? some pseudocode to explain what I mean string[] output_buffer; stdout.capture_to(output_buffer); writeln("test 1"); # not printed writeln("test 2"); # not printed stdout.release(output_buffer);

Re: struct: default construction or lazy initialization.

C#'s "Dispose" pattern comes to mind here. You don't leak memory, you just leak file handles and graphics resources instead when you forget to explicitly call Dispose().

Re: struct: default construction or lazy initialization.

On Tuesday, 31 January 2017 at 23:52:31 UTC, Ali Çehreli wrote: On 01/31/2017 03:15 PM, bitwise wrote: [...] Thanks for the response, but this doesn't really solve the problem. > If the object is defined at module scope as shared static > immutable It is indeed possible to initialize

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 23:42:43 UTC, Walter Bright wrote: On 1/31/2017 11:32 AM, Nordlöw wrote: On Tuesday, 31 January 2017 at 19:26:51 UTC, Walter Bright wrote: This "as if" thing enables the designer of a function API to set the desired relationships even if the implementation is

Re: struct: default construction or lazy initialization.

On 01/31/2017 03:15 PM, bitwise wrote: > If the object is defined at module scope as shared static immutable Yes, the situation is different from C++ but it's always possible to call a function (which constructor is one) to make the object. It is indeed possible to initialize immutable

Re: memcpy() comparison: C, Rust, and D

On 1/31/2017 11:32 AM, Nordlöw wrote: On Tuesday, 31 January 2017 at 19:26:51 UTC, Walter Bright wrote: This "as if" thing enables the designer of a function API to set the desired relationships even if the implementation is doing some deviated preversion with the data (i.e. a ref counted

Re: memcpy() comparison: C, Rust, and D

On 1/31/2017 12:00 PM, Mathias Lang wrote: *Can* make use of it... But won't. Any code calling memcpy has to be in a @trusted wrapper, in which `return scope` is not checked. So adding `return scope` annotations to non-safe D binding is just like adding documentation. Which is on par with what C

Re: memcpy() comparison: C, Rust, and D

On 1/31/2017 3:00 PM, Richard Delorme wrote: May we have an example of how the memory safety of arguments supplied to memcpy is checked in a way gcc cannot do? I was thinking of the return attribute, that prevents for example to return the address of a local variable through a call to memcpy:

struct: default construction or lazy initialization.

Unless I'm missing something, it seems that neither of these are actually possible. Consider an object which needs internal state to function. The obvious answer is to create it in the constructor: struct Foo(T) { T* payload; this() { payload =

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 19:20:40 UTC, Walter Bright wrote: On 1/31/2017 5:50 AM, Richard Delorme wrote: Well, I would not have taken memcpy as an example in favor of D. Good C compilers (like gcc) know what memcpy does and are able to optimize it according to its arguments. DMD may know

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 19:32:58 UTC, Nordlöw wrote: Why is this feature used? Optimizations? Safety? Just me being lazy. I'm gonna read up on https://wiki.dlang.org/DIP25

[Issue 17135] New: DMD hangs when compiling in release mode

https://issues.dlang.org/show_bug.cgi?id=17135 Issue ID: 17135 Summary: DMD hangs when compiling in release mode Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: critical

[Issue 17134] New: std.file.append documentation is incomplete

https://issues.dlang.org/show_bug.cgi?id=17134 Issue ID: 17134 Summary: std.file.append documentation is incomplete Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: trivial

[Issue 17133] New: Platform specific archives contain files from other platforms

https://issues.dlang.org/show_bug.cgi?id=17133 Issue ID: 17133 Summary: Platform specific archives contain files from other platforms Product: D Version: D2 Hardware: All OS: All Status: NEW

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright wrote: By this information being knowable from the declaration, the compiler knows it too and can make use of it. *Can* make use of it... But won't. Any code calling memcpy has to be in a @trusted wrapper, in which `return scope` is

Re: Associative array literal: length wrong when duplicate keys found

On Tuesday, 31 January 2017 at 17:20:00 UTC, John Colvin wrote: It's a bug, please report it. The initializer should be statically disallowed. Adding a .dup works around the problem. OK. Hmm, but the real use case was a bit more complicated, more like: - int n = 10; foreach (i; 0..n)

Re: vibe.d 0.8.0 and 0.7.31 beta releases

On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote: [1]: https://github.com/vibe-d/vibe-core Is vibe-core still in alpha stage? Github page says so.

Re: vibe.d 0.8.0 and 0.7.31 beta releases

On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote: The first release of the revamped core module [1] is nearing, and along with that, a compatible vibe.d release (0.8.0). The new core module is still opt-in in this release and can be activated using a `subConfiguration

Re: memcpy() comparison: C, Rust, and D

On 1/31/2017 2:44 AM, Nordlöw wrote: On Tuesday, 31 January 2017 at 10:20:59 UTC, Olivier FAURE wrote: I thought it meant "the parameter can be returned" not "the parameter *will* be returned". And what about multiple `return`-qualified function parameters? 'return' means treat the return

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 19:26:51 UTC, Walter Bright wrote: On 1/31/2017 2:44 AM, Nordlöw wrote: On Tuesday, 31 January 2017 at 10:20:59 UTC, Olivier FAURE wrote: I thought it meant "the parameter can be returned" not "the parameter *will* be returned". And what about multiple

Re: CTFE Status

On Tuesday, 31 January 2017 at 16:21:27 UTC, Stefan Koch wrote: newCTFE is now green on all platforms on travis as well. function pointer support are coming! with it most of std.algorithm will be supported. Cool!

Re: memcpy() comparison: C, Rust, and D

On 1/31/2017 5:50 AM, Richard Delorme wrote: Well, I would not have taken memcpy as an example in favor of D. Good C compilers (like gcc) know what memcpy does and are able to optimize it according to its arguments. DMD may know better about memcpy through its declaration but does not make any

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright wrote: 2. The return value is derived from s1. 4. Copies of s1 or s2 are not saved. Actually I didn't know either of those things from looking at the signature because DIP25 and DIP1000 have marketing problems, in that the only way

Re: Associative array literal: length wrong when duplicate keys found

On Tuesday, 31 January 2017 at 14:15:58 UTC, Ivan Kazmenko wrote: Hi. I wanted to check whether a few variables of the same type are all distinct, in a quick and dirty way. I tried to do it similar to Python's "len(set(value_list)) == len(value_list)" idiom by using an associative array

Re: vibe.d 0.8.0 and 0.7.31 beta releases

On Tuesday, 31 January 2017 at 13:27:31 UTC, Sönke Ludwig wrote: 0.7.31 will work with 2.069-2.073 and 0.8.0 will work with 2.070-2.073. This is especially interesting because GDC master is still on 2.069.x. Thanks!

Re: CTFE Status

newCTFE is now green on all platforms on travis as well. function pointer support are coming! with it most of std.algorithm will be supported.

[Issue 17130] [Reg 2.074] ambiguous implicit super call when inheriting core.sync.mutex.Mutex

https://issues.dlang.org/show_bug.cgi?id=17130 ZombineDev changed: What|Removed |Added CC|

Re: Fix it for me!

On Tuesday, 31 January 2017 at 14:56:32 UTC, cym13 wrote: That's not really the issue, the thing is this is not a forum, or not only. It's actually an interface to a mailing list and many people only use the mail so that provides only noise for Well, there's a few possibilities.. my

Re: Fix it for me!

On Tuesday, 31 January 2017 at 13:11:22 UTC, Profile Anaysis wrote: The web interface could use a little work! 1. Tabs - I know that tabs are designed to move to different elements but you can override the default behavior and make life quite a bit easier for most people(since most people

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 02:18:23 UTC, Mike wrote: On Tuesday, 31 January 2017 at 02:01:05 UTC, Walter Bright wrote: On 1/30/2017 5:53 PM, Mike wrote: One in particular prevents me from using D, period! - https://issues.dlang.org/show_bug.cgi?id=14758 The -betterC switch is the

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 11:32:01 UTC, John Colvin wrote: On Tuesday, 31 January 2017 at 10:17:09 UTC, Olivier FAURE wrote: On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright wrote: Point 3 is about `const`, which as far as I know is unaffected by application of @safe. Did you

Re: Fix it for me!

On Tuesday, 31 January 2017 at 13:11:22 UTC, Profile Anaysis wrote: The web interface could use a little work! 1. Tabs - I know that tabs are designed to move to different elements but you can override the default behavior and make life quite a bit easier for most people(since most people

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 10:00:03 UTC, Stefan Koch wrote: Because of the return attribute. return means I am passing this value through myself. Ahh, missed that. My mistake. Thanks, Walter!

Re: Partial arrays reclaimed?

On Friday, 27 January 2017 at 23:22:17 UTC, Nick Sabalausky wrote: Suppose an array is being used like a FIFO: --- T[] slice; // Add: slice ~= T(); // Remove: slice = slice[1..$]; --- Assuming of course there's no other references to the memory, as

Associative array literal: length wrong when duplicate keys found

Hi. I wanted to check whether a few variables of the same type are all distinct, in a quick and dirty way. I tried to do it similar to Python's "len(set(value_list)) == len(value_list)" idiom by using an associative array (AA). At this point, I found out that when initializing the AA with

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 13:50:33 UTC, Richard Delorme wrote: But, my main argument here, is that a good C compiler, is able to do a very good job at optimizing memcpy, so the extra information brought by the D language, is not so useful in practice. The point of Walter's argument was

Re: Yield from function?

On Monday, 30 January 2017 at 11:03:52 UTC, Profile Anaysis wrote: I need to yield from a complex recursive function too allow visualizing what it is doing. e.g., if it is a tree searching algorithm, I'd like to yield for each node so that the current state can be shown visually. I realize

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright wrote: Just from D's type signature, we can know a lot about memcpy(): 1. There are no side effects. 2. The return value is derived from s1. 3. Nothing s2 transitively points to is altered via s2. 4. Copies of s1 or s2 are not saved.

Re: vibe.d 0.8.0 and 0.7.31 beta releases

Am 31.01.2017 um 12:56 schrieb thedeemon: On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote: For anyone who does not depend on old D frontends, it is strongly recommended to switch to the 0.8.x branch What do you mean here by "old D frontends"? What are minimal dmd versions for

Fix it for me!

The web interface could use a little work! 1. Tabs - I know that tabs are designed to move to different elements but you can override the default behavior and make life quite a bit easier for most people(since most people have access to a mouse).

Re: D package for optimizing/compressing images

On Friday, 27 January 2017 at 11:03:15 UTC, aberba wrote: Are there any dub package for compressing images uploaded through web forms? Cropping/resizing may also come in handy. I want one for a vibe.d project. dlib-webp[1] is almost what I've been looking for. In fact, webp is a complete

Re: Yield from function?

On Tuesday, 31 January 2017 at 11:31:28 UTC, Ali Çehreli wrote: On 01/31/2017 03:00 AM, Profile Anaysis wrote: > [...] [...] > [...] return type. Options: [...] Thanks again!

Re: vibe.d 0.8.0 and 0.7.31 beta releases

On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote: For anyone who does not depend on old D frontends, it is strongly recommended to switch to the 0.8.x branch What do you mean here by "old D frontends"? What are minimal dmd versions for 0.7 and 0.8 branches?

Re: Syntax of isExpression

On Tuesday, 31 January 2017 at 11:40:06 UTC, Ali Çehreli wrote: On 01/31/2017 02:49 AM, Alex wrote: > auto r = E!(int, myType.a, true)(); > static if (is(T : TX!TL, alias TX, TL...)) > { > writeln(is(TL[0] == int)); > writeln(typeid(TL[1])); >

Re: Syntax of isExpression

On 01/31/2017 02:49 AM, Alex wrote: > auto r = E!(int, myType.a, true)(); > static if (is(T : TX!TL, alias TX, TL...)) > { > writeln(is(TL[0] == int)); > writeln(typeid(TL[1])); > writeln(typeid(TL[2])); > writeln(is(TL[2] == bool)); > } That's

Re: Snap packages for D compilers and core projects

On Tuesday, 31 January 2017 at 05:41:38 UTC, Joakim wrote: He can't read every forum thread, you should email him. That's what I did when I got his permission to put dmd in FreeBSD ports. Yes, I understand that, and I was going to do so anyway. But I was interested in any case in some more

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 10:17:09 UTC, Olivier FAURE wrote: On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright wrote: 3. Nothing s2 transitively points to is altered via s2. Wait, really? Does that mean that this code is implicitly illegal? import core.stdc.string; void

Re: Yield from function?

On 01/31/2017 03:00 AM, Profile Anaysis wrote: > Just curious, how can I use start() recursively? [...] > Seems I can't create start with a parameter and non-void return type. Options: - The class can maintain state - You can start the fiber with a delegate; int local; double state;

Re: CTFE Status

On Monday, 30 January 2017 at 15:15:55 UTC, Stefan Koch wrote: New bugs incoming: uint fn(uint a) { final switch(a) { case 1 : { while(a < 20) // bool whileCondition; //WhileBlockEvalCond : //whileCondition = (a < 20); {

Re: Minimum PR size

On Tuesday, 31 January 2017 at 10:42:41 UTC, rikki cattermole wrote: On 31/01/2017 11:36 PM, Jason Schroeder wrote: I am interested in contributing to D on GitHub, and was wondering if there is a minimum or preferabe minimum size of a pull request; e.g. I woukd like to work on increasing code

vibe.d 0.8.0 and 0.7.31 beta releases

The first release of the revamped core module [1] is nearing, and along with that, a compatible vibe.d release (0.8.0). The new core module is still opt-in in this release and can be activated using a `subConfiguration "vibe-d:core" "vibe-core"` directive in dub.sdl (`"subConfigurations":

Re: Yield from function?

On Tuesday, 31 January 2017 at 06:32:02 UTC, Ali Çehreli wrote: On 01/30/2017 08:12 PM, Profile Anaysis wrote: import std.stdio, std.concurrency, core.thread; class Search : Fiber { this() { super(); } int res = 0; void start() { Fiber.yield(); res = 1; } }

[Issue 16405] Trojan Win32/Ipac.B!cl detected on dmd-2.071.1.exe

https://issues.dlang.org/show_bug.cgi?id=16405 --- Comment #8 from anonymous4 --- About signing: http://robert.ocallahan.org/2017/01/disable-your-antivirus-software-except.html >Several times AV software blocked Firefox updates But firefox components are all signed.

Syntax of isExpression

Hey guys, could you help me understand the syntax of the isExpression? I have an example, leaned on documentation https://dlang.org/spec/expression.html#IsExpression case 7. // Code starts here // import std.stdio, std.typecons; alias Tup = Tuple!(int, string, bool); enum myType {a, b, c}

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 10:20:59 UTC, Olivier FAURE wrote: I thought it meant "the parameter can be returned" not "the parameter *will* be returned". And what about multiple `return`-qualified function parameters?

Re: Minimum PR size

On 31/01/2017 11:36 PM, Jason Schroeder wrote: I am interested in contributing to D on GitHub, and was wondering if there is a minimum or preferabe minimum size of a pull request; e.g. I woukd like to work on increasing code coverage, and am wondering if a pull request with one additional line

Re: Yield from function?

On Tuesday, 31 January 2017 at 06:32:02 UTC, Ali Çehreli wrote: On 01/30/2017 08:12 PM, Profile Anaysis wrote: [...] That's because the fiber is not in a callable state. (You can check with search.state.) Here is one where the fiber function lives (too) long: import std.stdio,

Minimum PR size

I am interested in contributing to D on GitHub, and was wondering if there is a minimum or preferabe minimum size of a pull request; e.g. I woukd like to work on increasing code coverage, and am wondering if a pull request with one additional line of code, e.g. one assert () in a unittest

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 10:00:03 UTC, Stefan Koch wrote: On Tuesday, 31 January 2017 at 09:31:23 UTC, Nordlöw wrote: How can we be sure that the return value points to the same content as `s1`? Because of the return attribute. return means I am passing this value through myself. I

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright wrote: 3. Nothing s2 transitively points to is altered via s2. Wait, really? Does that mean that this code is implicitly illegal? import core.stdc.string; void main() { int*[10] data1; int*[10] data2;

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 09:31:23 UTC, Nordlöw wrote: How can we be sure that the return value points to the same content as `s1`? Because of the return attribute. return means I am passing this value through myself.

[Derelict-Lua] FileSystem Trouble: Strange Behavior.

Hello! I have been trying to embed lua into my application, and I have strange behavior that I could not understand. I'm sure that this is not normal. First off, I have written a binding in order to interface my D code with Lua Code. ..:://\\::.. extern(C) nothrow int addSprite(lua_State

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 09:31:23 UTC, Nordlöw wrote: How can we be sure that the return value points to the same content as `s1`? If that is what you mean by "derived". Now that we allow allocation functions to be `pure` as in https://github.com/dlang/druntime/pull/1746

Re: memcpy() comparison: C, Rust, and D

On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright wrote: Rust: pub unsafe extern fn memcpy(dest: *mut c_void, src: *const c_void, n: size_t) -> *mut c_void D: pure void* memcpy(return void* s1,