Re: Disabling All Inlining in DMD Debug Builds

On Tuesday, 25 October 2022 at 08:14:26 UTC, Per Nordlöw wrote: On Monday, 24 October 2022 at 20:43:45 UTC, ryuukk_ wrote: I wish we could do ``version(DebugFast | Release)`` Moreover, I've been using, for instance, ```d version(D_Coverage) {} else pragma(inline, true); void foo() {} ``` to

Disabling All Inlining in DMD Debug Builds

I use ``` pragma(inline, true) function definition ``` all over my code. And by default, DMD inlines these functions even in debug builds, which normally is great. I have a custom dynamic array container and if the indexing operator overload function wasn't inlined the debug build would have

Re: Using getSymbolsByUDA in a static foreach loop

On Thursday, 20 January 2022 at 01:14:51 UTC, Adam Ruppe wrote: On Thursday, 20 January 2022 at 00:55:33 UTC, Jack Stouffer wrote: static foreach(member; __traits(allMembers, Manager)) member here is a string, not the member. I prefer to call it memberName. Then you

Re: Using getSymbolsByUDA in a static foreach loop

On Wednesday, 19 January 2022 at 21:49:12 UTC, Adam D Ruppe wrote: I never use most of std.traits, they just complicate things. Bleh idk, I wouldn't bother with it and loop through the __traits instead. Unless I'm missing something obvious this has to be a DMD bug, because this prints

Re: Using getSymbolsByUDA in a static foreach loop

On Wednesday, 19 January 2022 at 20:53:29 UTC, Adam D Ruppe wrote: So you want to `__traits(child, system, this).run()` and it should work - the traits child will re-attach a this value. The error is actually coming from trying to use the result of getSymbolsByUDA in the right part of the

Using getSymbolsByUDA in a static foreach loop

I'm trying to use getSymbolsByUDA in order to loop over all of the members in a struct with a certain UDA, and then call a function on the member. The plan is to use this to avoid looping over an array of function pointers. However, the compiler is giving a strange error and the

Re: Generating C Headers From D Code

On Thursday, 5 August 2021 at 17:02:33 UTC, Tejas wrote: On Thursday, 5 August 2021 at 16:28:35 UTC, Jack Stouffer wrote: I need to generate plain C99 .h files from a D module's extern(C) declarations, so that I can link a DMD generated .o file with a C code base. Are there any automated tools

Generating C Headers From D Code

I need to generate plain C99 .h files from a D module's extern(C) declarations, so that I can link a DMD generated .o file with a C code base. Are there any automated tools which do this? I know the compiler has C++ header generation, and there's tons of tools which exist for importing C

Re: Of possible interest: fast UTF8 validation

On Wednesday, 16 May 2018 at 17:18:06 UTC, Joakim wrote: I think you know what I'm referring to, which is that UTF-8 is a badly designed format, not that input validation shouldn't be done. UTF-8 seems like the best option available given the problem space. Junk data is going to be a

Re: Of possible interest: fast UTF8 validation

On Wednesday, 16 May 2018 at 11:18:54 UTC, Andrei Alexandrescu wrote: https://www.reddit.com/r/programming/comments/8js69n/validating_utf8_strings_using_as_little_as_07/ D doesn't seem to have C definitions for the x86 SIMD intrinsics, which is a bummer

Re: Auto expiring cache library

On Friday, 27 April 2018 at 09:07:31 UTC, Pasqui23 wrote: I want a library that offers an in-memory data structure,such that I can write,for example: cache.insert(key,value,expiry) and I can retrieve the value with something like cache[key],unless it has passed expiry seconds. Can be

Re: OT - Replacing strings with slices in C# - high performance improvement

On Saturday, 21 April 2018 at 20:54:32 UTC, Steven Schveighoffer wrote: I'm all for a string type and auto-decoding, so we can get rid of auto-decoding for char arrays. I've floated the idea of having the String type not be a range in order to solve this problem once and for all. In order to

Re: OT - Replacing strings with slices in C# - high performance improvement

On Saturday, 21 April 2018 at 19:15:58 UTC, Steven Schveighoffer wrote: An RCString could have slicing just like C#. And it doesn't prevent "raw slicing" with char arrays. FWIW, I support having a string library type and have been advocating for it for years (I'd love to have my char arrays

Re: OT - Replacing strings with slices in C# - high performance improvement

On Saturday, 21 April 2018 at 16:08:13 UTC, Steven Schveighoffer wrote: Since when? -Steve Since Andrei came up with the RCStr concept. Even a non-RC String type would still solve our auto decoding problem while also allowing us to do SSO.

Re: OT - Replacing strings with slices in C# - high performance improvement

On Friday, 20 April 2018 at 16:33:44 UTC, rumbu wrote: .NET Core 2.1 was announced, with emphasis on using Span instead of classic String class all around the framework. For people not familiar with C#, Span is similar to a D array slice.

Re: The 10k Twitter Target

On Monday, 16 April 2018 at 08:39:05 UTC, Mike Parker wrote: If you have a Twitter handle, it would help us out to retweet anything interesting you see on @D_Programming. The link in the navbar should probably link to this twitter handle rather than the hash tag.

Re: Must ranges support `r1 = r2;`?

On Monday, 16 April 2018 at 16:22:04 UTC, Jonathan M Davis wrote: Well, the reality of the matter is that if RefRange's opAssign doesn't work the way that it works, then RefRange is broken and fails at its purpose (and this is the designer of it speaking). So, if RefRange couldn't do what it's

Re: Must ranges support `r1 = r2;`?

On Monday, 16 April 2018 at 16:15:30 UTC, H. S. Teoh wrote: I could come up with some pretty pathological range types for stress-testing, if you want. (These are actual range types I've used in my own code, I didn't set out to break Phobos, but it turned out that Phobos makes many unstated

Re: Must ranges support `r1 = r2;`?

On Saturday, 24 March 2018 at 21:44:35 UTC, ag0aep6g wrote: Long version: ("std.range and std.algorithm can't handle refRange"). Short version: With two `std.range.RefRange`s, `r1 = r2;` does not what other Phobos code expects. Question is:

Re: Migrating an existing more modern GC to D's gc.d

On Monday, 9 April 2018 at 18:27:26 UTC, Per Nordlöw wrote: How difficult would it be to migrate an existing modern GC-implementation into D's? Considering no one has done it, very. Which kinds of GC's would be of interest? There's been threads about this. I'd do a search for "precise GC"

Re: PR duty

On Wednesday, 4 April 2018 at 05:31:10 UTC, Andrei Alexandrescu wrote: ... We can certainly try it, I'd be interested to see it's impact. The biggest problem Phobos is facing at the moment is total number of reviewers. There have been, in the past few weeks, three people reviewing PRs with

Re: D compiles fast, right? Right??

On Wednesday, 4 April 2018 at 20:29:19 UTC, Stefan Koch wrote: On Wednesday, 4 April 2018 at 20:04:04 UTC, Jack Stouffer wrote: On Wednesday, 4 April 2018 at 01:08:48 UTC, Andrei Alexandrescu wrote: Exactly, which is why I'm insisting this - and not compiler benchmarking, let alone idle

Re: DIP in making: ProtoObject

On Wednesday, 4 April 2018 at 14:47:03 UTC, Luís Marques wrote: Regarding the output range replacing toString. That's an obvious improvement. Yet, before that is set in stone, give the following at least some thought. It's a bit late for that ;) https://github.com/dlang/phobos/pull/5991

Re: D compiles fast, right? Right??

On Wednesday, 4 April 2018 at 01:08:48 UTC, Andrei Alexandrescu wrote: Exactly, which is why I'm insisting this - and not compiler benchmarking, let alone idle chattaroo in the forums - is where we need to hit. What we have here, ladies and gentlemen, is a high-impact preapproved item of great

Re: DConf 2018 Hackathon -- now open to the public free of charge

On Tuesday, 27 March 2018 at 14:04:29 UTC, Mike Parker wrote: Yesterday, I made the announcement that the Hackathon would be open to anyone willing to pay $100 to get in. That idea has now been nixed. Instead, anyone can come in for the full day completely free. It's like a big Munich Meetup!

Re: About making Phobos @safe

On Friday, 23 March 2018 at 17:31:09 UTC, Jesse Phillips wrote: @safe/@trusted doesn't mean "calling this function will not result in heartbleed." If @safe doesn't protect against buffer overflows then chuck the whole thing out the window and start over. What you're getting is that when you

Re: About making Phobos @safe

On Thursday, 22 March 2018 at 19:14:06 UTC, Seb wrote: Making all high-level functions of Phobos @safe --- There's are still some functions in Phobos which could be @safe, but aren't. I was going to ask this in Slack but since this thread is

Re: Flaw in DIP1000? Returning a Result Struct in DIP1000

On Wednesday, 21 March 2018 at 18:50:59 UTC, Jonathan M Davis wrote: The struct being returned would need to be marked with scope (or its members marked with scope) such that the compiler treated the result as containing values from the function arguments. I don't know whether that's possible

Re: Flaw in DIP1000? Returning a Result Struct in DIP1000

On Wednesday, 21 March 2018 at 19:15:41 UTC, Meta wrote: But the compiler doesn't like that. However, I _did_ get it working by doing this: GetoptResult getopt(T...)(scope T opts) @safe { return GetoptResult([Option(opts[0], opts[1])]); } Which is not ideal, obviously, but the notion that

Flaw in DIP1000? Returning a Result Struct in DIP1000

Consider this example simplified from this PR https://github.com/dlang/phobos/pull/6281 -- struct GetoptResult { Option[] options; } struct Option { string optShort; string help; } GetoptResult getopt(T...)(scope T opts) @safe { GetoptResult res; auto o =

Re: Release D 2.079.0

On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote: That being said, I'm wondering if it wouldn't be better to have std.experimental be in its own repository. This allows selection of the dependency on std.experimental separate from phobos. It still would be an "official"

5000 Merged Phobos Pull Requests

Nine days ago, Phobos hit 5000 merged pull requests: https://github.com/dlang/phobos/pulls?page=201=is%3Apr+is%3Amerged+sort%3Amerged-desc=✓ Thats an average of 1.93 merged PRs per day (first PR merged on Jan 31, 2011). A huge thank you to everyone who made this happen.

Re: Quora: Why hasn't D started to replace C++?

On Wednesday, 31 January 2018 at 17:02:06 UTC, Ola Fosheim Grøstad wrote: Ok, and now you are entering a messy space, define "legitimate"? Actionable, clear, and made with the intent to better the language/ecosystem and not just to complain. Development processes need continuous

Re: Quora: Why hasn't D started to replace C++?

On Wednesday, 31 January 2018 at 10:55:56 UTC, Benny wrote: On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote: Let me say this again *uch* Never mind this rant. I am just fed up with the issues. I will not post anymore as its just a wast of time for everybody involved. It's quite

Re: Quora: Why hasn't D started to replace C++?

On Wednesday, 31 January 2018 at 07:56:37 UTC, Andrew Benton wrote: E.g. three compilers Every other compiled language (and a lot of scripting ones) uses the fact of multiple compilers for the language as a sign of adoption and ecosystem growth. I've only ever seen people complain about D

Re: Proposed Phobos equivalent of wcswidth()

On Monday, 15 January 2018 at 17:32:40 UTC, H. S. Teoh wrote: On Mon, Jan 15, 2018 at 02:14:56PM +, Simen Kjærås via Digitalmars-d wrote: On Monday, 15 January 2018 at 13:34:09 UTC, Jack Stouffer wrote: > std.utf.displayWidth +1 [...] Why std.utf rather than std.uni, though? The way I

Re: Proposed Phobos equivalent of wcswidth()

On Saturday, 13 January 2018 at 17:26:52 UTC, H. S. Teoh wrote: ... Thanks for taking the time to do this. And now the obligatory bikeshed: what should the Phobos equivalent of wcswidth be called? std.utf.displayWidth

Re: Proposal for a standard Decimal type in alpha

On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer wrote: ... While I believe my library has certain API advantages, I'm really not interested in duplicating a bunch of work when rumbu's version is pretty much complete, so I'm dropping this.

Re: OT: Evidence of A Intel Virtual Memory Vulnerability

On Thursday, 4 January 2018 at 02:06:04 UTC, Brad Roberts wrote: Calling it a vendor or architecture specific issue is a bit misleading, based on the reading I did today. In my defense, when I posted this all people had to go off of where the linux git patches. I assume the announcement was

Re: Proposal for a standard Decimal type in alpha

On Friday, 5 January 2018 at 15:44:57 UTC, H. S. Teoh wrote: On Fri, Jan 05, 2018 at 03:38:45PM +, Jack Stouffer via Digitalmars-d-announce wrote: On Friday, 5 January 2018 at 15:22:01 UTC, H. S. Teoh wrote: > Very nice to see this taking shape. What's the link to the > code

Re: Proposal for a standard Decimal type in alpha

On Friday, 5 January 2018 at 15:22:01 UTC, H. S. Teoh wrote: Very nice to see this taking shape. What's the link to the code again? https://github.com/JackStouffer/stdxdecimal

Re: Proposal for a standard Decimal type in alpha

On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer wrote: ... Updated version out: * Added unary +,-,++,-- * Added casting to bool and floating point types * Added static ctors for infinite and nan for floating point type compatibility * Added abs, isNaN, isInfinite * Added

Re: Some Observations on the D Development Process

On Thursday, 4 January 2018 at 10:34:05 UTC, Mike Franklin wrote: A few of us are working hard to revive old PRs and either see them across the finish line, or give them a quick path to closure. 2 months ago the DMD PR queue stood at about 190. Now it's hovering between 140 and 150. DMD

Re: Release D 2.078.0

On Thursday, 4 January 2018 at 15:53:33 UTC, Mike Parker wrote: On a related note, the vision document for 2018H1 has not yet been created. It's a WIP. If I may make a suggestion, please make the vision documents smaller and more focused. The goals laid out are typically far too broad to

Re: OT: Evidence of A Intel Virtual Memory Vulnerability

On Wednesday, 3 January 2018 at 15:51:35 UTC, Jack Stouffer wrote: The gist of the story is that an Intel vulnerability is requiring OS vendors to institute Page Table Isolation in their kernels. This fix has an _across the board_ 5-7% slowdown on Intel chips. Worse yet, programs which do

OT: Evidence of A Intel Virtual Memory Vulnerability

The gist of the story is that an Intel vulnerability is requiring OS vendors to institute Page Table Isolation in their kernels. This fix has an _across the board_ 5-7% slowdown on Intel chips. Worse yet, programs which do lots of syscalls will see around a 30% slowdown or more, including

Re: Is there a way to call scope guard without throw exception?

On Saturday, 30 December 2017 at 13:48:16 UTC, ChangLong wrote: I try to find a way to yield custom fiber without throw exception, is it possible ? I need make sure the scope guard is executed and the resource will auto release relay on scope(exit). After fiber yield, the spoke guard is

Re: Beta 2.078.0

On Saturday, 30 December 2017 at 14:34:13 UTC, Martin Nowak wrote: On Tuesday, 19 December 2017 at 22:51:59 UTC, Martin Nowak wrote: First beta for the 2.078.0 release. Release Candidate is tagged and uploaded, website will be updated soon.

Re: Proposal for a standard Decimal type in alpha

On Thursday, 21 December 2017 at 23:08:22 UTC, Andre Pany wrote: That are fantastic news. Thanks for working on this topic. Is it possible to define a decimal type with a defined scale and precision? From the examples and the documentation I am not sure whether it is possible. Yes, the Hook

Proposal for a standard Decimal type in alpha

A couple of months ago, Andrei noted that a donor asked for a precise decimal type for D specifically: https://forum.dlang.org/post/osnema$d5s$1...@digitalmars.com. I've also heard this asked for many times, so I decided to start work on a library for eventual proposal to Phobos. I just

Re: Is there anyway to access LLVM's 128 bit int type for C from LDC?

On Friday, 15 December 2017 at 02:08:12 UTC, Nicholas Wilson wrote: See also https://github.com/d-gamedev-team/gfm/tree/master/integers/gfm/integers Thanks

Re: Is there anyway to access LLVM's 128 bit int type for C from LDC?

On Thursday, 14 December 2017 at 23:33:34 UTC, Nicholas Wilson wrote: On Thursday, 14 December 2017 at 19:47:53 UTC, Jack Stouffer wrote: Clang has __int128. Is there anyway to use this with D with LDC? Not really as a plain type, although there is effort to get [u]cent working. I could have

Is there anyway to access LLVM's 128 bit int type for C from LDC?

Clang has __int128. Is there anyway to use this with D with LDC?

Re: Question on Dual-Licensing Some Code for Phobos

On Saturday, 2 December 2017 at 02:35:18 UTC, codephantom wrote: Just the fact that you've seen that source code, is enough to have already 'contaminated' you with that source code's licence, and, that could (potentially)constitute your work as being a derivative work. To that I say "prove

Re: Question on Dual-Licensing Some Code for Phobos

On Thursday, 30 November 2017 at 19:17:32 UTC, Jack Stouffer wrote: ... Ok, decided to try to make it from scratch based off just the spec in order to avoid any issues. You can follow my progress if you so desire here: https://github.com/JackStouffer/stdxdecimal

Question on Dual-Licensing Some Code for Phobos

I'm starting work on a proposal for stdx.decimal, and one of the clearest implementations to work off of is the Python implementation. This however, poses a problem because Python's source is under the PSFL, a BSD-like permissive license. Any derivative work, such as a D conversion, must

Re: Time to move logger from experimental to std ?

On Wednesday, 29 November 2017 at 14:32:54 UTC, Basile B. wrote: Hello, most of the changes made during the current year to the std.experimental.logger package are related to the cosmetic style. Isn't this a sign showing that the experimentation is achieved ? Facts: - There only 4 issues

Re: First Impressions!

On Tuesday, 28 November 2017 at 03:01:33 UTC, A Guy With an Opinion wrote: - Attributes. I had another post in the Learn forum about attributes which was unfortunate. At first I was excited because it seems like on the surface it would help me write better code, but it gets a little tedious

Re: Website down: code.dlang.org

On Monday, 27 November 2017 at 10:20:17 UTC, Chris wrote: There seems to be a problem with http://code.dlang.org/ at the moment (27.11.) Down again.

Re: static foreach is now in github master

On Tuesday, 18 July 2017 at 15:46:04 UTC, Seb wrote: https://is.gd/1TCQOh Hmmm, that code is printing 0 1 2 3 0 1 2 3 for me. Shouldn't it just be printing once?

Re: If Statement with Declaration

On Thursday, 20 July 2017 at 14:05:36 UTC, Iakh wrote: It is not about reduce number of lines. It is about binding related things in one statement. Even so, it's already been shown in this thread that the same effect can be achieved via a block statement (doing exactly what it was designed

Re: If Statement with Declaration

On Wednesday, 19 July 2017 at 13:30:56 UTC, sontung wrote: Thoughts on this sort of feature? To be frank, I don't think that helping the programmer reduce the line count in their program by one line is worth further complicating the language.

Re: An Issue I Wish To Raise Awareness On

On Wednesday, 19 July 2017 at 14:56:58 UTC, Dukc wrote: Shouldn't it be : struct A { ~this() shared {} } void main() { auto a = A(); shared b = A(); } ? Because handling theard-local data as shared is safe as far as I remember, but not the other way round. Non-shared

Re: An Issue I Wish To Raise Awareness On

On Monday, 17 July 2017 at 17:41:58 UTC, Atila Neves wrote: On Monday, 17 July 2017 at 14:26:19 UTC, Jack Stouffer wrote: TL;DR: Issue 17658 [1] makes using shared very annoying/practically impossible. [...] I fixed this already, should be in the next release. Atila Are you sure? Because

An Issue I Wish To Raise Awareness On

TL;DR: Issue 17658 [1] makes using shared very annoying/practically impossible. Over the weekend, I attempted to fix Issue 15768 [2], which is an underlying problem in the std.stdio.File struct that stops it from closing properly when shared across threads. This is a big problem for users

Re: DIP 1010--Static foreach--Formal Review

On Monday, 10 July 2017 at 08:53:42 UTC, Mike Parker wrote: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md Sorry for not getting in on the original review, but I've submitted a PR for the DIP in regards to formatting.

Re: proposed @noreturn attribute

On Saturday, 8 July 2017 at 11:07:32 UTC, bachmeier wrote: Why should this be an attribute rather than a pragma? I agree. There's no reason I can think of as to why the no-return should be part of the ABI.

Re: Experience with https://www.patreon.com

On Thursday, 6 July 2017 at 13:53:08 UTC, Andrei Alexandrescu wrote: Does anyone have experience with https://www.patreon.com either as a patron or creator? Thanks! -- Andrei It works well for supporting artists. I support many people with it. However, if you're thinking of an application

Re: Output range primitives

On Wednesday, 5 July 2017 at 21:28:31 UTC, Jonathan M Davis wrote: So, they definitely work, but they're a bit hampered in comparison to what they could or should be. Yes, and it will take someone writing a DIP for this to be fixed (not aiming this at you, just notifying people who don't

Re: docarchives.dlang.io - go back in time to previous released versions of dlang.org

On Tuesday, 4 July 2017 at 01:39:23 UTC, Seb wrote: ... Thanks for doing this. IMO there should be a link under the "switch to pre-release." link in the current docs. Maybe replace it with a dropdown to select the version from 2.066 to pre-release?

Re: Why do "const inout" and "const inout shared" exist?

On Sunday, 2 July 2017 at 18:49:29 UTC, Walter Bright wrote: Thank you. This explanation makes sense (given that applying const to immutable => immutable). Since seemly everyone is confused about it, this topic looks like a great subject for a blog post.

Re: Phobos PR in need of review/merge

On Tuesday, 27 June 2017 at 01:35:31 UTC, Meta wrote: On this topic, I feel like we've been falling behind lately in responding to PRs promptly, communicating with submitters on what changes (if any) are needed to get the PR into merge shape, and actually getting stuff merged (this isn't

Re: Go 1.9

On Sunday, 25 June 2017 at 17:21:06 UTC, Michael wrote: I think the problem with this is that compilation speed being the no. 1 selling point requires people to invest in large projects in order to reap the benefits. However, if you fail to draw them in to begin with, then they're not going to

Re: Go 1.9

On Monday, 19 June 2017 at 13:24:00 UTC, Russel Winder wrote: The former is not a problem for D, but the latter… Disagree. One of D's biggest competitive advantages is fast compilation of fast code. If other languages become as fast or faster than DMD in compilation speed then that's a big

Re: DIP 1003 (Remove body as a Keyword) Accepted!

On Saturday, 3 June 2017 at 06:09:21 UTC, Jonathan M Davis wrote: On Saturday, June 03, 2017 02:00:13 Jack Stouffer via Digitalmars-d-announce wrote: I recommend a longer deprecation cycle than usual for this, as this will break many legacy libraries that don't get maintained often. A period

Re: DIP 1003 (Remove body as a Keyword) Accepted!

On Friday, 2 June 2017 at 14:17:10 UTC, Mike Parker wrote: Congratulations, Jared! https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md Congratulations. I recommend a longer deprecation cycle than usual for this, as this will break many legacy libraries that don't get maintained

Re: Benchmark

On Thursday, 1 June 2017 at 21:08:43 UTC, Robert burner Schadek wrote: So my idea is to eventually get this library into phobos, write benchmarks for all functions in phobos, execute the benchmarks for every merge into master, use gnuplot to display the results on the dlang webpage And

Re: DCompute is now in the master branch of LDC

On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote: I fear the conversation will go like this, like it has for me: N: DCompute W: What's DCompute? N: Enables GPU programming with D W: Cool! instead of: N: D-GPU W: Cool! I can use D to program GPUs! This was literally what

Re: std.functional.memoize : thread local or __gshared memoization?

On Thursday, 25 May 2017 at 11:15:19 UTC, Stanislav Blinov wrote: Count me const scope. https://www.youtube.com/watch?v=YIp-0V6YKfQ

Re: Warning, ABI breakage from 2.074 to 2.075

On Thursday, 25 May 2017 at 15:02:00 UTC, Jason King wrote: That’s a fairly important requirement if it’s supposed to be a systems programming language, less so for application focused stuff. I would hope it’s at least an eventual goal even if it’s not quite the case today. The reason we

Re: Faster Command Line Tools in D

On Wednesday, 24 May 2017 at 21:46:10 UTC, cym13 wrote: I am disappointed because there are so many good things to say about this, so many good questions or remarks to make when not familiar with the language, and yet all we get is "Meh, this benchmark shows nothing of D's speed against

Re: DIP 1008 Preliminary Review Round 1

On Monday, 22 May 2017 at 12:00:30 UTC, Nick Treleaven wrote: //FIXME: uniqueToString should return @nogc UniquePtr!(const char[]) import std.conv; alias uniqueToString = to!(const char[]); class MessageEx(E, sinkArgs...) : E { this(A...)(A args) { super(args); }

Re: Ali's slides from his C++Now talk

On Wednesday, 24 May 2017 at 00:05:54 UTC, Ali Çehreli wrote: ... Any videos up?

Re: My two cents on what D needs to be more successful...

On Sunday, 21 May 2017 at 05:52:11 UTC, Ecstatic Coder wrote: Since a few months, I'm using D for all my command-line tools. For that use case, the language and its standard libraries are really perfect, making it the best scripting language I know, completely exploding JavaScript, Python,

Re: DIP 1008 Preliminary Review Round 1

On Saturday, 20 May 2017 at 13:06:01 UTC, Jonathan M Davis wrote: ... Let's take the CTFE discussion to a different thread

Re: DIP 1008 Preliminary Review Round 1

On Friday, 19 May 2017 at 19:46:07 UTC, nkm1 wrote: As someone who iis interested in @nogc (more precisely: in avoiding GC pauses), I like this proposal... But it looks like people are concerned about 'new' becoming contextual keyword (that in some contexts it allocates with GC and in others

Re: DIP 1008 Preliminary Review Round 1

On Friday, 19 May 2017 at 15:45:28 UTC, Mike Parker wrote: ... I have already made my objections known in the other threads, but I'll list them here for posterity. Firstly, and most importantly IMO, this does not solve the surface level problem, which is the lack of @nogc in much of

Re: On "A New Collections Framework for the Standard Library"

On Thursday, 18 May 2017 at 18:27:22 UTC, Andrei Alexandrescu wrote: Iterating over a container using e.g. foreach won't consume the container same as iterating over int[] won't consume the slice. I don't understand why you're mapping the behavior of ranges/slices, which theoretically are

Re: On "A New Collections Framework for the Standard Library"

On Thursday, 18 May 2017 at 15:18:00 UTC, Jack Stouffer wrote: ... Also, shared allocators raise another problem entirely. Let's say for the sake of clarity that these future containers will use a separate range type. Let's say you have a container with five elements, and then you give a

Re: On "A New Collections Framework for the Standard Library"

On Thursday, 18 May 2017 at 15:38:39 UTC, Jonathan M Davis wrote: That point concerned me as well. Dynamic arrays in D are very strange beasts indeed, and while it works for them to function as both ranges and (sort of) containers, it's also created a fair bit of confusion, and it really a

On "A New Collections Framework for the Standard Library"

I just got around to watching Eduard Staniloiu's talk at DConf [1] about the collections library he was working on. One thing seemed odd, in that Eduard seems to be saying that the container and the range over the container's elements are one in the same and the range primitives are on the

Re: Fantastic exchange from DConf

On Sunday, 14 May 2017 at 10:10:41 UTC, Dibyendu Majumdar wrote: In real terms though tools like ASAN and Valgrind if used from the start usually allow you to catch most of the issues. Most likely even better tools for C will come about in time. See Walter's comment earlier in this thread and

Re: Fantastic exchange from DConf

On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar wrote: (a) Trust the programmer. That's the first and most deadly mistake. Buffer overflows and null pointers alone have caused hundreds of millions of dollars of damages. I think we can say that this trust is misplaced. (b) Don't

Re: Fantastic exchange from DConf

On Tuesday, 9 May 2017 at 14:13:31 UTC, Walter Bright wrote: 2. it may not be available on your platform I just had to use valgrind for the first time in years at work (mostly Python code there) and I realized that there's no version that works on the latest OS X version. So valgrind runs on

Re: Fantastic exchange from DConf

On Thursday, 11 May 2017 at 09:39:57 UTC, Kagamin wrote: https://bugs.chromium.org/p/project-zero/issues/detail?id=1252=5 - a vulnerability in an application that doesn't go on the internet. This link got me thinking: When will we see the first class action lawsuit for criminal negligence

Re: Fantastic exchange from DConf

On Wednesday, 10 May 2017 at 00:30:42 UTC, H. S. Teoh wrote: strncpy(tmp, desc->data1, bufsz); if (fwrite(tmp, strlen(tmp), 1, fp) != 1) { fclose(fp); unlink("blah"); return

Re: Static foreach pull request

On Tuesday, 9 May 2017 at 03:06:37 UTC, Timon Gehr wrote: ... I'm going to save you some time and tell you that Andrei and Walter are going to require a DIP for this.

Re: Fantastic exchange from DConf

On Monday, 8 May 2017 at 19:37:05 UTC, Jack Stouffer wrote: ... Wrong link https://forum.dlang.org/post/novsplitocprdvpoo...@forum.dlang.org

Re: Fantastic exchange from DConf

On Monday, 8 May 2017 at 18:33:08 UTC, Jerry wrote: Anything that goes on the internet already has memory safety. BS, a damn buffer overflow bug caused cloudflare to spew its memory all over the internet just a couple of months ago. Discussed here

Re: Jonathan Blow's presentation

On Monday, 8 May 2017 at 19:14:16 UTC, Meta wrote: On Monday, 8 May 2017 at 19:11:03 UTC, Ethan Watson wrote: You know, unless you want to try making a 45 gigabyte executable for current Playstation/Xbox games. Is this why most console games that get ported to PC are massive? GTA V on PC,

  1   2   3   4   5   6   7   8   >