Re: Disabling All Inlining in DMD Debug Builds

[Jack Stouffer via Digitalmars-d-learn]

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 get correct coverage inclusion of `foo()`. Is this still 
neeed?


This looks like a workable solution for now. Thanks

Disabling All Inlining in DMD Debug Builds

[Jack Stouffer via Digitalmars-d-learn]

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 a ~10x 
slowdown and become un-testable in many ways.


What sucks about this is that stepping through the code in a 
debugger is way worse because the the "step-over" operation no 
longer works properly. Maybe this is a bug in the PDB output, but 
trying to step over an inlined function call still takes you into 
the inlined function body as if it were a step-in.


So is there a way to tell DMD to ignore these pragmas in certain 
builds?

Re: Using getSymbolsByUDA in a static foreach loop

[Jack Stouffer via Digitalmars-d-learn]

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 __traits(getMember, Manager, memberName) to actually 
get the alias you can pass to getAttributes.


Thanks, that fixed it. Final working version for anyone who finds 
this thread:


```d
import std.traits;
import std.stdio;

enum Runnable;

struct SubSystem
{
void run()
{
writeln("SubSystem ran");
}
}

struct Manager
{
@Runnable SubSystem subsystem;

void run()
{
static foreach(memberName; __traits(allMembers, Manager))
{
static foreach (attribute; __traits(getAttributes, 
__traits(getMember, Manager, memberName)))

{
static if (is(attribute == Runnable))
{
__traits(getMember, Manager, 
memberName).run();

}
}
}
}
}


void main()
{
Manager m;
m.run();
}
```

Re: Using getSymbolsByUDA in a static foreach loop

[Jack Stouffer via Digitalmars-d-learn]

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 nothing:


```d
import std.traits;
import std.stdio;

enum Runnable;

struct SubSystem
{
void run()
{
writeln("SubSystem ran");
}
}

struct Manager
{
@Runnable SubSystem subsystem;

void run()
{
static foreach(member; __traits(allMembers, Manager))
{
static foreach (attribute; 
__traits(getAttributes, member))

{
static if (attribute == Runnable)
{
__traits(child, Manager, member).run();
}
}
}
}
}

void main()
{
Manager m;
m.run();
}
```

The `__traits(getAttributes, member)` call always returns an 
empty tuple. Calling `__traits(getAttributes, Manager.subsystem)` 
manually works as expected.

Re: Using getSymbolsByUDA in a static foreach loop

[Jack Stouffer via Digitalmars-d-learn]

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 `static foreach`, not 
the call to the `run` function. Which was odd to me because I 
thought it just returned a `AliasSeq`.


Here's a link to the erroring code with your traits change:

https://run.dlang.io/is/gO84ox

Using getSymbolsByUDA in a static foreach loop

[Jack Stouffer via Digitalmars-d-learn]

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 
documentation of getSymbolsByUDA is unhelpful, as there are no 
practical use-case examples.


Here's a very simplified version of my code

```d
import std.traits;

enum Runnable;

struct SubSystem
{
void run();
}

struct Manager
{
@Runnable SubSystem subsystem;

void run()
{
static foreach(system; getSymbolsByUDA!(Manager, 
Runnable))

{
system.run();
}
}
}

void main()
{
Manager m;
m.run();
}

```

Result:

```
onlineapp.d(16): Error: value of `this` is not known at compile 
time

```

This seems to me to be the logical way to write this code. What 
am I missing?

Re: Generating C Headers From D Code

[Jack Stouffer via Digitalmars-d-learn]

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 which 
do this?


I know the compiler has C++ header generation, and there's 
tons of tools which exist for importing C headers into D code. 
I'm not aware of anything which goes the other direction. 
Google wasn't much help either.


I also can't find anything... until someone else comes with a 
better answer, maybe you can do this:


Use the ```-H``` compiler flag to generate ```.di``` files.

Remove all the ```extern(C)``` decls in the .di files.

Rename the file extension from ```.di``` to ```.h```

Technically, it should work. Hopefully someone else knows 
better.


Well, that's disappointing. I suppose everyone just makes there 
main file a D file when converting C projects so they don't have 
this problem.


Eventually I'll have to write a script which takes .di files and 
generates .h files, but doing it manually will have to work for 
now.

Generating C Headers From D Code

[Jack Stouffer via Digitalmars-d-learn]

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 headers into D code. I'm not 
aware of anything which goes the other direction. Google wasn't 
much help either.

Re: Of possible interest: fast UTF8 validation

[Jack Stouffer via Digitalmars-d]

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 problem with any possible string 
format given that encoding translations and programmer error will 
always be prevalent.

Re: Of possible interest: fast UTF8 validation

[Jack Stouffer via Digitalmars-d]

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


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

It's too bad that nothing came of std.simd.

Re: Auto expiring cache library

[Jack Stouffer via Digitalmars-d-learn]

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 done?What library should I use?


Memcached

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

[Jack Stouffer via Digitalmars-d]

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 get a 
range from a String, you'd have to call toCodeUnits, 
toCodePoints, or toGraphemes, which would all be range returning 
member functions. That way, the user is in charge of the 
iteration every time, and there's no "magic" involved.


I might whip up a proof-of-concept of a String (without RC but 
with SSO) later when I have free time. It'd be useful in some of 
my projects.

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

[Jack Stouffer via Digitalmars-d]

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 
back as arrays of chars). But it MUST support slicing to pass 
muster in D.


A slice of a String could also return a String, and have some 
property raw or toArray to get the underlying slice.

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

[Jack Stouffer via Digitalmars-d]

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

[Jack Stouffer via Digitalmars-d]

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.


https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performance-improvements-in-net-core-2-1/


And we’re trying to move towards a string library type and away 
from raw slices :)

Re: The 10k Twitter Target

[Jack Stouffer via Digitalmars-d-announce]

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;`?

[Jack Stouffer via Digitalmars-d]

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 doing, it wouldn't exist, 
and no requirements have ever been place on opAssign for ranges 
(in fact, for better or worse, the range API doesn't actually 
require that opAssign even work for ranges, though it can 
certainly be argued that it should). Now, RefRange is weird 
enough overall that maybe it shouldn't exist, and it was trying 
to solve a problem that's not really solvable in the general 
case (basically it's trying to force a range-based function to 
mutate the original rather than to deal with a copy even though 
the function was written to copy) - especially once forward 
ranges get involved - but opAssign is doing exactly what it was 
intended to do, and if what it's doing wasn't considered valid 
at the time, RefRange wouldn't exist. Either way, there are 
times when I think that adding RefRange was a mistake precisely 
because it's such an oddball and because it's only ever really 
going to do what it was intended to do in some circumstances.


RefRange can be useful in certain situations. But, I don't see a 
pretty way out of this. Either


1. we break code by saying `RefRange` is doing something illegal
2. we break code by making `RefRange` always an input range
3. we change all range code which could use `opAssign` to use 
`move`, potentially breaking code which relies on opAssign being 
called, and imposing a large burden on the maintenance of 
existing code for a very small corner case. Just imagine how much 
code outside of Phobos also has this subtle bug.

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

[Jack Stouffer via Digitalmars-d]

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 assumptions that 
explode in your face when given a more unusual instance of a 
range. There used to be (and may still be) a lot of places that 
essentially assumes built-in array semantics, and that blew up 
in ugly ways when handed something else that's nevertheless 
still a valid range.)


It would be awesome to have these as range types in 
std.internal.test.dummyrange. Then they could be used in tests 
throughout Phobos.

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

[Jack Stouffer via Digitalmars-d]

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: Who's at fault? Where do I fix this? Do ranges 
have to support assignment as expected - even though std.range 
doesn't mention it? Or should range-handling code never do that 
- even though it comes naturally and is widespread currently?


Posting this from the PR.

This is a band-aid over the issue of what to do with funky 
operator overloads in ranges. In conjunction with this issue, you 
also have to assume that one could do stuff in the ctor that 
would mess up existing range code in Phobos. What really needs to 
happen is the range spec needs to be updated with a clear list of 
assumptions that Phobos makes in regards to these functions. I'm 
pretty sure that RefRange would have been designed differently if 
the designer realized the results of overloading opAssign like 
that.


In a perfect world, we'd have a pre-constructed test suite that 
people could plug their range (with some data in it) into, where 
all the tests make sure all Phobos assumptions hold true.


In my opinion, it would be best to update the range spec and go 
from there.

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

[Jack Stouffer via Digitalmars-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" 
in general.



Which attempts have been made already?


https://github.com/dlang/druntime/pull/1603

Re: PR duty

[Jack Stouffer via Digitalmars-d]

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 regularity, with more people 
popping up occasionally. I totally understand that people are 
busy, but it's near impossible to keep up with that many 
reviewers. The main reason the PR queue is so long for Phobos 
right now is we are way ahead of 2017 H2's pace with an average 
of 15 PRs merged per day vs 9.3, mainly due to the pace of people 
creating new PRs. We've been falling behind this past month with 
only 5 merged per day on average, while the number of new PRs 
didn't slow down, which allowed the open PRs to ballon to over 
120.


I think that more organization might help keep more reviewers 
involved.

Re: D compiles fast, right? Right??

[Jack Stouffer via Digitalmars-d]

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 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 general 
interest. Shall we start the auction?


Are you aware of this PR? 
https://github.com/dlang/dmd/pull/8124


This is but a layer of paint over the real problem.
Unneeded Dependencies. Programming should not be a game of 
jenga.

Piling things on top of other things rarely works out.


I encourage you to leave a review on the PR then with corrective 
measures.

Re: DIP in making: ProtoObject

[Jack Stouffer via Digitalmars-d]

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


For instance, if you want to print an Object to the terminal 
with some color, you can't use a chain of ranges like 
`yourObject.toString.colorizer`, you have to output to some 
intermediary buffer. Just by coincidence, yesterday I was once 
again wondering about this and I decided to prototype an 
input-range-based formatter.  By restricting the initial 
version to a compile-time format string it actually made it 
*very* easy to implement a MVP.


The counter to this is that output ranges are only for finalizing 
data that you want to buffered. In the example given, yourObject 
should instead have a range generating function which can be 
given to colorizer, which is then given to 
stdout.lockingTextWriter.

Re: D compiles fast, right? Right??

[Jack Stouffer via Digitalmars-d]

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 general interest. Shall 
we start the auction?


Are you aware of this PR? https://github.com/dlang/dmd/pull/8124

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

[Jack Stouffer via Digitalmars-d-announce]

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!


Wow, it's great news that the D Foundation can afford to do that 
;)

Re: About making Phobos @safe

[Jack Stouffer via Digitalmars-d]

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 call this function there 
are no parameter values which you could pass such that you 
could cause memory corruption. If you are concerned about 
heartbleed then you don't need to review @safe code, @trusted 
code should be reviewed so that @safe code can't cause issue 
with any of the valid parameters (the way it calls @system 
functions should be safe). And @system code should reviewed for 
heartbleed. If you use zlib and it has a heartbleed bug then it 
is your fault for not reviewing the @system code, not the fault 
of D marking its usage as @system.


We can't review the zlib code which is the thrust of the issue. 
It's entirely possible that a bug  in zlib could write past the 
bounds of an array. We could in theory verify zlib, but


1. It would require including the C code in the distribution that 
was reviewed rather than linking to the system version


2. The review process would have to be repeated every time we 
update to a new zlib release.


From a Phobos dev's perspective, zlib.compress2 is as much as a 
black box as malloc.


You mention mallac being ok to use with @trusted, but it has 
the same issue, if you didn't review the code behind your 
mallac call then it could introduce heartbleed, you don't know 
because you didn't review it.


Functions in the C standard library are a category difference 
because it's completely reasonable to assume that malloc isn't 
going to corrupt memory. The same assumption cannot be made with, 
to use the example again, libssl.

Re: About making Phobos @safe

[Jack Stouffer via Digitalmars-d]

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 already 
here, why not.


What are we going to do about C library calls in std.zlib and 
std.zip? I'm really uncomfortable about adding @trusted to the 
zlib calls, as it's different than calling C functions from the 
std library. There's no issue in reality with marking a 
malloc/free pair as trusted when it's verified to not escape. But 
there's really no garuntee about the safety of third party 
libraries. What if there's a Heartbleed level bug in zlib and we 
marked it as @trusted?


Should we just resign ourselves to the fact that some functions 
are going to be @system no matter what?

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

[Jack Stouffer via Digitalmars-d]

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 with DIP 1000 
as-is


Not as far as I can tell. Marking it as scope in the function 
body means it can't be returned, and marking the array in 
GetoptResult as scope results in a syntax error.


In this particular case, it may make more sense to just let 
getopt be @safe on its own and just let the caller mark all of 
the uses of & as @trusted.


This is thankfully the case currently.

If it's possible to mark GetoptResult with scope such that we 
can use scope without copying, then great, but if it's not, 
then I'm inclined to argue that we should just make sure that 
getopt itself is @safe and not worry about whether the caller 
is doing anything @system to call getopt or not.


Regardless, this does raise a potential issue with scope and 
user-defined return types, and we should explore how possible 
it is for DIP 1000 to solve that problem without forcing copies 
that wouldn't be necessary in @system code.


My cause for alarm with this limitation is this is one of the 
issues (taking address of locals safely) that DIP1000 was 
designed to solve. If, in practice, DIP1000 code can't be used 
for this case when the code become sufficiently complex, then we 
have a real problem on our hands.

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

[Jack Stouffer via Digitalmars-d]

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 some code 
has to be rewritten to accomodate ownership semantics is not a 
new one; one of the major complaints I've seen about Rust is 
that it requires you to adjust your coding style to satisfy the 
borrow checker.


The problem here is that it's impossible to apply this to the 
actual getopt code :/

Flaw in DIP1000? Returning a Result Struct in DIP1000

[Jack Stouffer via Digitalmars-d]

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 = Option(opts[0], opts[1]);
res.options ~= o;
return res;
}

void main() @safe
{
bool arg;
getopt("arg", "info", );
}
--

$ dmd -dip1000 -run main.d

--
main.d(16): Error: scope variable o assigned to non-scope res
main.d(23): Error: template instance `onlineapp.getopt!(string, 
string, bool*)` error instantiating

--

The only way I've found to make the code compile and retain the 
pre-dip1000 behavior is to change the Option construction to


--
auto o = Option(opts[0].idup, opts[1].idup);
--

How can we return non-scoped result variables constructed from 
scope variables without copies?

Re: Release D 2.079.0

[Jack Stouffer via Digitalmars-d-announce]

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" dlang package, and 
might even be included in the distribution (the latest version 
anyway), and docs included on the website. But if needed, you 
could have your dub package depend on a prior version.


The entire concept needs a reexamination IMO. I just checked the 
git history, and not one module has graduated from 
std.experimental to mainline Phobos since the idea's inception in 
2014. While it's possible that none of the modules are ready, 
logger has been there for four years now. I was against changing 
how experimental is handled in the past, but I recently have 
started to rethink how we promote modules.


Also, if you'll allow me to have crazy ideas for a moment, one 
wonders why we shouldn't just release Phobos itself through dub? 
Rust makes people use their build tool, why not us?

5000 Merged Phobos Pull Requests

[Jack Stouffer via Digitalmars-d]

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++?

[Jack Stouffer via Digitalmars-d]

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 improvement.


And we have been. I would rate our QA tooling to be 3x better now 
than when I started.



For some reason this ranks below colourful error-messages.


That's just something that Walter was able to bang out in an 
hour, should have been done years ago, and was excited about. 
There's tons of work being done on GH that's never talked about 
here in the forums.


Whatever spot D is in right now in comparison to other 
projects, good or bad, most certainly isn't because of a lack 
of marketing.


We clearly have a lot of work to do on messaging when many of the 
Quora answers are using eight year old information as 
condemnation.



People expect less friction today than they did 10 years ago.
To some extent Microsoft, Google, Jetbrains and others have 
handed out slick freebies and conditioned programmers to be 
more demanding.


True. D would be a in great place if everything worked out of the 
box if people wanted an IDE. But the post I was replying to first 
noted issues with the ecosystem six days ago, and has already 
rage quit over it.

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

[Jack Stouffer via Digitalmars-d]

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 easy to tell when criticism is made in good or bad 
faith, and at this point I'm going to reply to every rant in bad 
faith on here about how terrible D is with "Post issue numbers" 
and nothing else. If you have a legitimate problem, make an issue 
at issues.dlang.org

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

[Jack Stouffer via Digitalmars-d]

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 in this area. Never 
once have I seen someone argue that the existence of PyPy hurts 
Python or gogcc hurts Go.

Re: Proposed Phobos equivalent of wcswidth()

[Jack Stouffer via Digitalmars-d]

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 understand it is that std.uni is (supposed to be) for 
functions on individual unicode units (be they code units/points 
or graphemes) and std.utf is for functions which handle operating 
on unicode strings. Obviously there are exceptions. I think 
"they" put graphemeStride in std.uni because Grapheme was defined 
there and it seemed reasonable at the time. But, generally I 
think utf stuff should go into std.utf.

Re: Proposed Phobos equivalent of wcswidth()

[Jack Stouffer via Digitalmars-d]

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

[Jack Stouffer via Digitalmars-d-announce]

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

[Jack Stouffer via Digitalmars-d]

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 
release when it was is because the reddit post linked made it to 
the front page, which forced their hand.

Re: Proposal for a standard Decimal type in alpha

[Jack Stouffer via Digitalmars-d-announce]

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 again?


https://github.com/JackStouffer/stdxdecimal


Thanks! Will take a look sometime. Might throw in a PR or two 
if I can.



T


Well hold off on that for a day because I just realized I have to 
redesign the internals of the whole thing due to a bug I found.


Long story short, I'd been using a myriad of different types 
(depending on your chosen precision) to represent the coefficient 
in order to avoid the slowness of BigInt. But I realized due to a 
bug that this isn't really a workable solution.


I'm going to change the code to always use a BigInt, and just 
work on making BigInt faster where I can. This will make the 
Decimal code about half as complex thankfully.

Re: Proposal for a standard Decimal type in alpha

[Jack Stouffer via Digitalmars-d-announce]

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

[Jack Stouffer via Digitalmars-d-announce]

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 support to opBinary for mixing different precision levels 
on each side of the operation

Re: Some Observations on the D Development Process

[Jack Stouffer via Digitalmars-d]

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 also has at least 30 PRs which have had no action from the 
author in over a year. There's no reason these should be kept 
open; they just take up auto-tester resources and lower the 
signal to noise ratio.


If the author comes back later, they can always ask a maintainer 
to reopen.

Re: Release D 2.078.0

[Jack Stouffer via Digitalmars-d-announce]

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 actually accomplish in half a year. Instead, the 
document should give detailed milestones for two or three long 
term goals which the community should complete in the six months.


E.g.

@safety: we aim to enable large-scale uses of D with safety 
guarantees


and

Static introspection: We believe this is an important strategic 
advantage of D and we should continue to improve both compiler 
support and library support.


These are not actionable and can't be achieved in just six months 
of work. Instead, something like


To move toward a @safe Phobos, std.json, std.file, and 
std.stdio should all be 100% @safe by June.
Static introspection: we believe this is an important strategic 
advantage of D, so X, Y, and Z feature should be added by June


gives contributors goals they can start making PRs for.

Re: OT: Evidence of A Intel Virtual Memory Vulnerability

[Jack Stouffer via Digitalmars-d]

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 lots of syscalls will see around a 
30% slowdown or more, including compilation.


AMD is not effected.

Details and discussion:
Reddit: 
https://www.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/

HN: https://news.ycombinator.com/item?id=16046636


Attack details published by Google Project Zero with official 
names https://meltdownattack.com

OT: Evidence of A Intel Virtual Memory Vulnerability

[Jack Stouffer via Digitalmars-d]

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 compilation.


AMD is not effected.

Details and discussion:
Reddit: 
https://www.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/

HN: https://news.ycombinator.com/item?id=16046636

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

[Jack Stouffer via Digitalmars-d]

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 not able to execute,  
unless I throw a exception in Fiber.  I am look if there is 
some hack method to make the fiber Interrupted at any time with

 scope(exit) code executed.


You might want to repost this question to the Learn board, along 
with some example code of what you're trying to achieve.

Re: Beta 2.078.0

[Jack Stouffer via Digitalmars-d-announce]

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.

http://downloads.dlang.org/pre-releases/2.x/2.078.0/
https://github.com/dlang/dlang.org/commit/362da850fa65a20f0b68b76786bb6a57840b6c59


Martin, before you release 2.078, could you please comment on the 
problem of issuing a warning for issue 16997 
https://issues.dlang.org/show_bug.cgi?id=18148

Re: Proposal for a standard Decimal type in alpha

[Jack Stouffer via Digitalmars-d-announce]

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 template parameter currently controls how many 
significant digits your decimal can have and will eventually be 
able to control the min and max allowed exponents as well. By 
default, it's set at 9 digits, but you can have as many as 
int.max - 1 since it auto uses BigInt under the hood. Once your 
decimal has more than the allowed number of digits, it's rounded 
according to the Hook prescribed rounding method, which is half 
up by default.

Proposal for a standard Decimal type in alpha

[Jack Stouffer via Digitalmars-d-announce]

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 finished getting the type into an alpha version, and I 
wanted to solicit people's opinions on the API and if I'm heading 
in the right direction with this.


The dub page: https://code.dlang.org/packages/stdxdecimal

The docs: https://jackstouffer.github.io/stdxdecimal/

What you can do so far:

* Control behavior with a Hook type a-la 
std.experimental.checkedint

* Addition, subtraction, multiplication, division
* Construction from a strings and built-in number types

For the full list of planned features, see: 
https://github.com/JackStouffer/stdxdecimal


Please let me know what you think!

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

[Jack Stouffer via Digitalmars-d-learn]

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?

[Jack Stouffer via Digitalmars-d-learn]

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 sworn that mir was using InlineIR 
with it for multiplication. But InlineIR is the only way to get 
at it.


What operation do you need on it?


I'm looking to use it to store the coefficient in my precise 
decimal type when you need more than 9 significant digits.


I might just end up translating Boost's multiprecision lib to D 
if ucent is impossible.

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

[Jack Stouffer via Digitalmars-d-learn]

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

Re: Question on Dual-Licensing Some Code for Phobos

[Jack Stouffer via Digitalmars-d]

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 it in court" :)

Re: Question on Dual-Licensing Some Code for Phobos

[Jack Stouffer via Digitalmars-d]

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

[Jack Stouffer via Digitalmars-d]

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 have the original copyright notice, 
a copy of the PSFL, as a well as a summary of changes. This is 
simple enough to do, but the resulting code would be 
dual-licensed with the PSFL and the BSL 1.0 (dual-licensing being 
relatively common in other OSS projects).


My question is there any reason this could pose a problem? Could 
this interfere with something like distribution or company 
adoption?


Also note, one of the existing Phobos modules, std.net.isemail, 
is supposed to be dual-licensed because it's derived from an 
existing BSD work. But, it's missing the BSD license from the top 
(and is technically breaking the license because of that).

Re: Time to move logger from experimental to std ?

[Jack Stouffer via Digitalmars-d]

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 for logger - 
https://issues.dlang.org/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED=phobos=OP=OP=product=component=alias=short_desc=content=CP=CP=OR_id=218035=substring=substring=substring=substring=substring=matches_format=advanced_desc=logger_desc_type=allwordssubstr=logger=logger=logger=logger=logger=%22logger%22
- The history, mostly style things: 
https://github.com/dlang/phobos/commits/master/std/experimental/logger


In the past Andrei remarked that he didn't want to move it from 
stdx until RCStr was in Phobos. That was a couple of years ago, 
so his opinion might have change by seeing the slow progress on 
the DIP1000 front.

Re: First Impressions!

[Jack Stouffer via Digitalmars-d]

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 and tiresome to have 
to remember to decorate code with them. It seems like most of 
them should have been the defaults. I would have preferred if 
the compiler helped me and reminded me. I asked if there was a 
way to enforce them globally, which I guess there is, but I 
guess there's also not a way to turn some of them off 
afterwards. A bit unfortunate. But at least I can see some 
solutions to this.


Attributes were one of my biggest hurdles when working on my own 
projects. For example, it's a huge PITA when you have to add a 
debug writeln deep down in your call stack, and it ends up 
violating a bunch of function attributes further up. Thankfully, 
wrapping statements in debug {} allows you to ignore pure and 
@safe violations in that code if you compile with the flag -debug.


Also, you can apply attributes to your whole project by adding 
them to main


void main(string[] args) @safe {}

Although this isn't recommended, as almost no program can be 
completely safe. You can do it on a per-file basis by putting the 
attributes at the top like so


@safe:
pure:

Re: Website down: code.dlang.org

[Jack Stouffer via Digitalmars-d]

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

[Jack Stouffer via Digitalmars-d-announce]

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

[Jack Stouffer via Digitalmars-d]

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 for) or with a for loop.


It's an small increase in terseness for a decrease in readability 
and an increase in complexity.

Re: If Statement with Declaration

[Jack Stouffer via Digitalmars-d]

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

[Jack Stouffer via Digitalmars-d]

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 structs/classes can't call shared methods.

Unless you're saying that the above should work even though it 
currently doesn't. Even then, I don't know about that. If your 
type is complex enough to need a shared dtor then the dtor 
probably needs to do some locking or extra checks. You don't want 
to impose that cost on a struct instance which isn't shared.

Re: An Issue I Wish To Raise Awareness On

[Jack Stouffer via Digitalmars-d]

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 DMD nightly still errors:

https://run.dlang.io?compiler=dmd-nightly=struct%20A%0A%7B%0A%20%20%20%20this(string%20a)%20%7B%7D%0A%20%20%20%20this(string%20a)%20shared%20%7B%7D%0A%0A%20%20%20%20~this()%20%7B%7D%0A%20%20%20%20~this()%20shared%20%7B%7D%0A%0A%20%20%20%20this(this)%20%7B%7D%0A%20%20%20%20this(this)%20shared%20%7B%7D%0A%7D%0A%0Avoid%20main()%0A%7B%0A%20%20%20%20shared%20f%20%3D%20A(%22%22)%3B%0A%7D


(maybe we should remove the ban on URL shorteners for our own 
sites)

An Issue I Wish To Raise Awareness On

[Jack Stouffer via Digitalmars-d]

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 because stdin/out/err are all __gshared File, 
and are therefore unsafe. This makes for a really annoying 
situation where writeln("a") is @safe but stderr.writeln("a") 
isn't.


The obvious solution is to make stdin/out/err shared(File) and 
modify File to have shared overloads which either lock or use 
atomic ops safely. When I tried to write said functions, I ran 
into compilation issues that I couldn't diagnose until I ran 
across this thread by Atila [3]. The problem is, unlike a 
constructor, destructors and post-blits can't be overloaded with 
shared variants. Consider:


```
struct A
{
this(string a) {}
this(string a) shared {}

~this() {}
~this() shared {}

this(this) {}
this(this) shared {}
}

void main()
{
shared f = A("");
}
```

Error: destructor f152.A.~this conflicts with destructor 
f152.A.~this at /d422/f152.d(6)
Error: function f152.A.__postblit conflicts with function 
f152.A.__postblit at /d422/f152.d(9)


This is further compounded with this

```
struct A
{
~this() {}
}

void main()
{
auto a = A();
shared b = A();
}
```

Error: non-shared method f585.A.~this is not callable using a 
shared object


The only way to work around this is to create a new type that is 
defined as shared struct and copy over all of the code from the 
original type. This really hobbles shared in any real world 
context.


I ask that someone who knows the DMD code base could please take 
a look at this and see if this is something that can be fixed 
easily and without breakage.


[1] https://issues.dlang.org/show_bug.cgi?id=17658
[2] https://issues.dlang.org/show_bug.cgi?id=15768
[3] 
https://forum.dlang.org/post/sqazguejrcdtjimtj...@forum.dlang.org

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

[Jack Stouffer via Digitalmars-d]

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

[Jack Stouffer via Digitalmars-d]

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

[Jack Stouffer via Digitalmars-d]

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 for the D 
foundation, I don't know if that's the right avenue. It would 
certainly work, but Patreon is more built for people who release 
discrete pieces of content, not necessarily charities who have 
less concrete results.

Re: Output range primitives

[Jack Stouffer via Digitalmars-d]

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 know).

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

[Jack Stouffer via Digitalmars-d-announce]

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?

[Jack Stouffer via Digitalmars-d]

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

[Jack Stouffer via Digitalmars-d]

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 anything 
new of course). I don't have the data to back me up yet, but I 
am going to try to gather what I can and make a post about it 
sometime within the next month. Any ideas or insights are 
welcome.


1. https://github.com/dlang/phobos/pull/5515


This is particularly my fault. I haven't been reviewing PRs 
nearly as much as I was in the past.


I think the PR queue on Phobos has gotten out of control. Ideally 
we'd have around 50 or less PRs open.


I'm going to try to comment on/review at least one PR a day from 
here on out to slowly chip away at the queue.

Re: Go 1.9

[Jack Stouffer via Digitalmars-d]

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 commit to 
a large enough project to benefit enough from improved 
compilation speed.


I don't know where you're getting this idea that fast compile 
times only help for large projects.


I reap the benefits every time I use rdmd for my scripts. I reap 
the benefits every time the compilation is near instant when 
tweaking+debugging my libraries or when unit testing my projects.

Re: Go 1.9

[Jack Stouffer via Digitalmars-d]

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 problem.

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

[Jack Stouffer via Digitalmars-d-announce]

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 of two years sounds about right.


For Phobos, that _is_ the normal length of the deprecation 
cycle. For the language itself, I don't think that it's 
anywhere near as consistent, but I've gotten the impression 
that deprecations in the language usually stick around for 
quite awhile, but I haven't exactly tracked it closely, so I 
don't know.


- Jonathan M Davis


All of the recent Phobos deprecations have been a year. 18 months 
at most.

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

[Jack Stouffer via Digitalmars-d-announce]

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 
often. A period of two years sounds about right.

Re: Benchmark

[Jack Stouffer via Digitalmars-d]

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 reject out of hand any PR which reduces performance in order 
to "ratchet" performance over time.


I would also do this to a lesser degree to DMD as well.

Re: DCompute is now in the master branch of LDC

[Jack Stouffer via Digitalmars-d-announce]

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 happened to me when I saw the headline.

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

[Jack Stouffer via Digitalmars-d]

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

[Jack Stouffer via Digitalmars-d]

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 don't have ABI compatibility is the same reason 
neither Rust or Go does, it's a lot of work for a minority of 
users and it stops the language from progressing.


Maybe D will have it eventually due to pressure from large D 
using companies, but I highly doubt it.

Re: Faster Command Line Tools in D

[Jack Stouffer via Digitalmars-d-announce]

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 Python".


Wouldn't be the first time 
https://news.ycombinator.com/item?id=10828450

Re: DIP 1008 Preliminary Review Round 1

[Jack Stouffer via Digitalmars-d]

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);
}

//FIXME: delegate not @nogc
/*@nogc*/ override void toString(scope void delegate(in 
char[]) sink) const

{
foreach (a; sinkArgs)
sink(uniqueToString(a));
}
}

unittest
{
auto x = 7;
throw new MessageEx!(Exception, "x = ", x)(null);
}

The result of uniqueToString would free any memory allocated 
after the call to sink.


Heh, I actually ran into this problem earlier today and just saw 
this post https://issues.dlang.org/show_bug.cgi?id=17420


Weird coincidence.

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

[Jack Stouffer via Digitalmars-d]

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...

[Jack Stouffer via Digitalmars-d]

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, Ruby, etc.


Glad to see you're happy with the language.

Let's break down each of these suggestions.


  - std.database (connect/use MySQL/MongoDB/etc databases)


I while I don't agree that the connection facilities themselves 
should be included (shipping C libraries has been a huge pain), I 
agree that some form of either ORM or standardized format of DB 
API should be in Phobos. Like SQLAlchemy, let's leave the 
connection to other libraries.



  - std.ui (draw 2D user interfaces)
  - std.input (get mouse/touchscreen/etc events)


I would like to point out that users of the languages you 
mentioned almost never use the builtin versions of these types of 
libraries (and hasn't maintenance of Swing been a huge time 
burden on the Java devs, I remember reading this somewhere). 
Python users use either Qt or GTK, not Tk.


* a soft-realtime garbage collector (like in Nim), which can 
progressively recycle the memory of a thread without blocking 
the whole application.


This is possible, just needs a champion.


  - std.web (serve web data/files/pages)


There's a philosophical boundary here. There are many ways to 
make a web server, and there's no one right answer for every web 
problem. Standardizing one type of server seems improper.


Plus the below problem applies.


  - std.audio (load/play/process/record sounds/musics)
  - std.image (load/show/process/record images)
  - std.video (load/show/process/record videos)
  - std.graphic (draw 2D/3D graphics)
* a dedicated IDE, allowing to effortlessly 
open/compile/execute/debug a single ".d" file as well as an 
entire project.


The problem with all of these suggestions is that the maintenance 
burden is so enormous that it would take a medium sized team of 
paid professionals. Let's take std.graphic as an example. To give 
a sense of the scale of the job, getting a cross platform 
graphics API is a task so large that it takes some of the largest 
corporations in the world (MS, Apple, etc.) to come together to 
make it happen. It's not so much a code problem as it is an 
organization problem. The result is OpenGL, an API that no one 
likes very much and literally no one understands.


So we would have to support OpenGL, because this has to work on 
Linux and OpenBSD. Next, you probably want to support DX 11, 
because that's what pretty much 99% of video games use, so that's 
another monolithic API that you have to incorporate into your 
agnostic API. Now how about DX 12? Because it's supposedly way 
faster, and if you're going after game devs, they tend to worry 
about speed. How about Vulkan? How about OpenGL 3 as well as 4 
because Apple abjectly refuses to upgrade for no apparent reason. 
Speaking of Apple, how about Metal? Oh, and we want to support 
mobile so don't forget about OpenGL ES, plus all its different 
versions that have to be supported for different phone platforms.


I cannot stress enough how difficult a task a cross platform 3D 
graphics library is.


It's the same thing for audio and video too. Just look at all of 
the different encodings and features ffmpeg supports.


No, best to leave graphics/audio/video to C libraries that 
already exist. Even if it's painful, it's more painful to copy 
their work.



But with some efforts...


D is 100% community run and none of us get paid. Bringing 
something into Phobos doesn't mean that it gets more work (it can 
actually mean the opposite). It's gotten to the point where each 
module in Phobos ostensively has one or two owners who's 
responsible for its condition in order to spread the load.



For the web servers, vibe.d is already there.

For desktop applications, there is gtkd and dlangui.


In order to make the existing libraries standard would require

1. An API freeze. Not something that anyone in the community is 
willing to concede, not even Vibed.
2. Constant, time consuming review of every change, as is 
required by any standard library for QA. This is why ndslice is 
no longer in Phobos.
3. Tons of hours of work fixing the bugs that are present in the 
existing solutions before even considering merging them into 
Phobos.


I agree that at the moment, all these developments can be 
possible through several third-party libraries.


And that's the way it's going to have to stay TBH.

Re: DIP 1008 Preliminary Review Round 1

[Jack Stouffer via Digitalmars-d]

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

[Jack Stouffer via Digitalmars-d]

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 it 
does something else). So maybe different syntax can be used? 
How about "throw scope Exception"? ("scope" already does 
various things :)


This syntax was already proposed and mostly rejected by the 
community. See the original thread listed in the DIP.


But memory management is not only about allocations, it's also 
about deallocations! Manually deallocating stuff (like freeing 
exception objects) is error prone and bothersome.


That's why we have the GC.

Refcounted exceptions seems to me a pretty good solution (and I 
think the general plan for D is to use more reference counting? 
At least, that's my impression...)


That was my impression too. However Walter has made it clear that 
@safe ref-counting of classes is not planned as he doesn't think 
it's possible. I'm unclear on the details of that, so you'll have 
to ask him.

Re: DIP 1008 Preliminary Review Round 1

[Jack Stouffer via Digitalmars-d]

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 
Phobos. While the DIP is correct that in a lot of the absence of 
@nogc is due to exceptions, most notably the auto decoding 
functions in std.range, it not the only reason. There are many 
things in Phobos which stop @nogc, such as array literals, array 
appending, AAs, and delegates. While many functions can be made 
@nogc via this change, there will be many functions left in 
Phobos still allocating, and this is a major problem in my 
estimation. The reason I take this all or nothing view of the 
situation is that @nogc exists largely for a group of people who 
want to avoid the GC __completely__. If lack of any GC usage is 
actually a requirement for a project, having many very useful 
parts of Phobos off limits (a few that spring to mind are bigint, 
digest, and a lot of stdio) is still a problem when our 
competitors in this GC free arena are Rust and C++ which will 
both have a lot more functionality in this limited scope.


Secondly, I'm not a fan of special casing syntax, especially when 
I don't think the given benefits outweigh the above listed costs. 
Making operator new do something completely different in one 
specific context is a continuation of the trend in the recent 
past of making the language more and more complicated, which I 
find troubling as one of D's main selling points is it's 
practicality and its low learning curve.


And while I don't think the code breakage will be a huge problem, 
it still is something to consider when asking what are we getting 
for all of these costs.


Thirdly, I don't think the DIP asks the right question. The DIP 
asks


How can we make exceptions, and thereby many Phobos functions, 
@nogc?


IMO the right question to ask is a level of analysis above that. 
As already mentioned, there are many things which will still be 
allocated on the GC. We need to fix these as well if we want to 
market D as a GC optional language. Instead, we should be asking


How can allocations in Phobos and user code be transferred to 
an allocation strategy of the user's choosing/needs?


If the user values code simplicity and safety, then the GC is 
fine, and template functions which allocate can then be marked as 
@safe due to their use of GC. But if the user needs other speed 
or usage requirements, then the user needs to offer something 
else, and that will automatically be marked as @system. I think 
that integrating std.allocator across Phobos in a consistent 
manner will allow this, where functions can accept allocators, 
and their internal allocations can all be done on the given 
allocator. This would also allow exceptions and other objects can 
be manually freed after a function is called if needed, or just 
left to the GC to collect if the GC allocator was passed to the 
function.


In summary, I believe what Phobos needs is a wholistic approach 
to the problem of memory management, and not a bunch of small 
solutions over time. To be sure, this is a much harder task, but 
I think if it's done right, with D we can have the first language 
which has compete user control to those who need it while 
offering ease of use to everyone else.

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

[Jack Stouffer via Digitalmars-d]

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 shrinking views of data, 
onto containers of data which can grow or shrink. They seem 
antithetical to me.


The only reason foreach over a dynamic array doesn't consume the 
slice is because foreach uses index based iteration on static and 
dynamic arrays and not the std.range.primitives functions.


It's not evident to me that the non-consuming behavior makes 
sense to map onto something completely different like containers 
that won't even necessarily have index based access.


It seems odd to me that slices would be the design basis when 
slices


1. Are intentionally limited in scope design wise to be a 
shrinking view of data

2. Only make sense behavior wise for array containers
3. Their ability to grow is a GC oddity which may end up copying 
a whole lot of data depending on the origin of the slice


There is no way to reclaim the original container. If you 
create a container, you get a range positioned to "see" the 
entire container. Once you popFront from that range, you lose 
all access to the first element in the container, unless you 
have a separate copy of the range. This is not new and not 
different from:


auto r = new int[10];
r.popFront;

What happens here is an array of 10 elements gets created. But 
you don't get a type "array of 10 integers". You get "a slice 
of integers, incidentally initialized to refer to the entire 
array of 10 integers that was just created". Next, you decide 
you don't care about the first element in the array. Once you 
call r.popFront, access to that element is lost forever.


First off, how are you going to do something like a map over a 
immutable container then, as map uses the range primitives and 
not foreach? There's no reason in principal that that should 
cause an issue. But with that design popFront is mutating the 
underlying data, and therefore should not be allowed. But this 
works with the std.container design because popFront is mutating 
the range view which has no reason to be immutable.


Secondly, if I want to say, perform a map over the elements of a 
container for some output, and I want to do things with the 
elements later in the code, then I have to create a copy of the 
container and pass the original to map? If that's the case then 
why not just go with the std.container behavior of getting a 
range from a primitive if you end up having to create range 
copies? I mean it's fundamentally the same, but that way you 
don't have to worry about the copies changing the data of the 
container out from under you.


What happens to the copy of a container when the original 
modifies the underlying data? For example, what should this code 
print?


auto container = Array!int(MAllocator.instance);
container.put(iota(10));

auto container_copy = container;
container.popBackN(5);
container.insertBack(1);

container_copy.each!(a => write(a, ", "));

In my estimation, a properly designed containers library should 
print


0, 1, 2, 3, 4, 1, 5, 6, 7, 8, 9

But from what you're describing, that the containers act like 
slices, the code with print


0, 1, 2, 3, 4, 1, 6, 7, 8, 9

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

[Jack Stouffer via Digitalmars-d]

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 range of those elements to a function that caches the 
length somewhere because it's available (very common as ranges 
have never been expected to change before). What happens when 
you're iterating over the range and then another thread calls 
removeBack before the loop is completed? All sorts of functions 
in Phobos will blow up in interesting and different ways.


I think you'd have to make all ranges created from mutable 
containers input ranges with no extra primitives in order to 
avoid this problem.


Plus, you also have a problem with things like SList where 
removeFront can be called after a different thread creates a 
range. All of a sudden your range `front` is pointing to invalid 
data. So for that, you need to either


1. Make a thread safe way to invalidate all old ranges (possibly 
by marking them empty immediately)
2. Allow the program to blow-up and mark all remove functions as 
@system

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

[Jack Stouffer via Digitalmars-d]

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 fair bit of what is done 
with dynamic arrays are _not_ range-based functions (e.g. 
appending), making the whole situation that much more confusing 
when range-based functions and array-specific functions are 
mixed (which is definitely going to happen in stuff like string 
code).


Yes, adding in the free function versions of the range primitives 
in std.range, while convenient initially, seems to have had large 
negative effects down the line.

On "A New Collections Framework for the Standard Library"

[Jack Stouffer via Digitalmars-d]

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 container itself.


Is this accurate?

If so, then this is completely different than the currently 
accepted design of ranges and containers. Currently, a container 
allows the removal and insertion of elements, and to get a range 
of the elements you have to call a function or slice the 
container. This is how std.containers and Brain's EMSI container 
library. In this new library, what happens when I iterate the 
elements of one of these containers using foreach? Do the range 
primitives empty the container? How do I ask for a new, full 
range of my data in the collection to use in a range algorithm 
after I've already iterated over the elements?


As Andrei originally laid out in this talk introducing ranges 
[2], ranges only shrink and never grow. Put another way, Output 
Ranges and Input Ranges are two separate things. Andrei states 
durning that talk (at 1:20:20)


"Can ranges ever grow? ... No, never, because it would be 
fundamentally unsafe."


I'm not sure what Andrei meant by this, but he believes that 
growing ranges is also a bad idea.


[1] https://www.youtube.com/watch?v=k88QSIC-Na0
[2] 
https://archive.org/details/AndreiAlexandrescuKeynoteBoostcon2009

Re: Fantastic exchange from DConf

[Jack Stouffer via Digitalmars-d]

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 my reply.

I think Rust is a promising language but I don't know enough 
about it to comment. My impression about Rust is that:


a) Rust has a steep learning curve as a language.


So does C, if you're doing C "correctly".

b) If you want to do things that C allows you to do, then Rust 
is no more safer than C.


That's the entire bloody point isn't it? Maybe you shouldn't be 
doing a lot of the things that C allows you to do.

Re: Fantastic exchange from DConf

[Jack Stouffer via Digitalmars-d]

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 prevent the programmer from doing what needs to be 
done.


In reality this manifests as "Don't prevent the programmer from 
doing anything, especially if they're about to shoot themself".


See the code examples throughout this thread.


(c) Keep the language small and simple.
(d) Provide only one way to do an operation.


lol


(f) Make support for safety and security demonstrable.


LOL http://article.gmane.org/gmane.comp.compilers.llvm.devel/87749


My conclusion is that C, and derivatives like C++, is a very
dangerous language the write safety/correctness critical software
in, and my personal opinion is that it is almost impossible to 
write

*security* critical software in it.


(that's from the creator of clang btw)

But I don't see how languages like D or Rust can replace C for 
certain types of use cases.


Maybe you can argue for the use of C in embedded systems and in 
OS's, although I see no reason why Rust can't eventually overtake 
C there. However, much of the internet's security critical 
systems (openssl, openssh, DNS systems, router firmware) are in 
C, and if Google's Project Zero are any indication, they all have 
ticking time bombs in them.


As I stated earlier in the thread, at some point, some company is 
going to get sued for criminal negligence for shipping software 
with a buffer overflow bug that caused a security breach.


It almost happened with Toyota. The auto industry has a C coding 
convention for safety called MISRA C, and it was brought up in 
court as to why Toyota's acceleration problems were entirely 
their fault. You can bet this will be brought up again.

Re: Fantastic exchange from DConf

[Jack Stouffer via Digitalmars-d]

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 about 
2.5% of computers in existence.


Fun!

Re: Fantastic exchange from DConf

[Jack Stouffer via Digitalmars-d]

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 for not catching a buffer 
overflow (or other commonly known bug) which causes identity 
theft or loss of data?


Putting aside the moral questions, the people suing would have a 
good case, given the wide knowledge of these bugs and the 
availability of tools to catch/fix them. I think they could prove 
negligence/incompetence and win given the right circumstances.


Would be an interesting question to pose to any managers who 
don't want to spend time on security.

Re: Fantastic exchange from DConf

[Jack Stouffer via Digitalmars-d]

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 IO_ERROR;
}

strncpy(tmp, desc->data2, bufsz);
if (fwrite(tmp, strlen(tmp), 1, fp) != 1)
{
fclose(fp);
unlink("blah");
return IO_ERROR;
}


I think you cause a memory leak in these branches because you 
forget to free tmp before returning.


Side note: scope(exit) is one of the best inventions in PLs ever.

Re: Static foreach pull request

[Jack Stouffer via Digitalmars-d]

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

[Jack Stouffer via Digitalmars-d]

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

[Jack Stouffer via Digitalmars-d]

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 
https://forum.dlang.org/post/bomiwvlcdhxfegvxx...@forum.dlang.org


These things still happen all the time. Especially when companies 
realize that transitioning from a Python/Ruby backend to a C++ 
one can save tens of thousands in server costs.

Re: Jonathan Blow's presentation

[Jack Stouffer via Digitalmars-d]

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, for example, was 100GB, while Skyrim was 
around 8GB.


Skyrim was that size on release because the console version had 
to fit on a DVD for the xbox 360 version, plus they made almost 
no changes to the PC version of the game. GTA V however, was 
released several months after the console release and had larger 
textures and uncompressed audio.