Re: Jonathan Blow's presentation
On Tuesday, 9 May 2017 at 06:10:39 UTC, Patrick Schluter wrote: equipment. So they made a very good setup. What they discovered is that mp3 with 160 kbit/s CBR was already undistinguishable from CD for 99% of people for almost all kind of music. It isn't all that hard to distinguish if you know what to listen for. I hear a big difference in music I have mixed down/mastered on a good headset.
Re: Fantastic exchange from DConf
On Mon, May 08, 2017 at 06:33:08PM +, Jerry via Digitalmars-d wrote:
> Anything that goes on the internet already has memory safety.
Is that a subtle joke, or are you being serious?
A LOT of code out in the internet, both in infrastructure and as
applications, run C code. And if you know the typical level of quality
of a large C project written by 50-100 (or more) employees who have a
rather high turnover, you should be peeing your pants right now. A
frightening amount of C code both in infrastructure (by that I mean
stuff like routers, switches, firewalls, core services like DNS, etc.)
and in applications (application-level services like webservers, file
servers, database servers, etc.) are literally riddled with buffer
overflows, null pointer dereference bugs, off-by-1 string manipulations,
and other such savorable things.
Recently I've had the dubious privilege of being part of a department
wide push on the part of my employer to audit our codebases (mostly C,
with a smattering of C++ and other code, all dealing with various levels
of network services and running on hardware expected to be "enterprise"
quality and "secure") and fix security problems and other such bugs,
with the help of some static analysis tools. I have to say that even
given my general skepticism about the quality of so-called "enterprise"
code, I was rather shaken not only to find lots of confirmation of my
gut feeling that there are major issues in our codebase, but even more
by just HOW MANY of them there are.
An unsettlingly large percentage of bugs / problematic code is in the
realm of not handling null pointers correctly. The simplest is checking
for null correctly at the beginning of the function, but then proceeding
to dereference the possibly-null pointer with wild abandon thereafter.
This may seem like not such a big problem, until you realize that all it
takes is for *one* of these literally *hundreds* of instances of wrong
code to get exposed to a public interface, and you have a DDOS attack
waiting for you in your glorious future.
Another unsettlingly common problem is the off-by-1 error in string
handling. Actually, the most unsettling thing in this area is the
pervasiveness of strcpy() and strcat() -- even after decades of
experience that these functions are inherently unsafe and should be
avoided if at all possible. Yet they still appear with persistent
frequency, introducing hidden vulnerabilities that people overlook
because, oh well, we trust the guy who wrote it 'cos he's an expert C
coder, so he must have already made sure it's actually OK.
Unfortunately, upon closer inspection, there are actual bugs in a large
percentage of such code. Next to this is strncpy(), the touted "safe"
variant of strcpy / strcat, except that people keep writing this:
strncpy(buf, src, sizeof(buf));
Quick, without looking: what's wrong with the above line of code?
Not so obvious, huh? The problem is that strncpy is, in spite of being
the "safe" version of strcpy, badly designed. It does not guarantee
buf is null-terminated if src was too long to fit in buf! Next thing
you know -- why, hello, unterminated string used to inject shellcode
into your "secure" webserver!
The "obvious" fix, of course, is to leave 1 byte for the \0 terminator:
strncpy(buf, src, sizeof(buf)-1);
Except that this is *still* wrong, because strncpy doesn't write a '\0'
to the end. You have to manually put one there:
strncpy(buf, src, sizeof(buf)-1);
buf[sizeof(buf)-1] = '\0';
The second line there has a -1 that lazy/careless C coders often forget,
so you end up *introducing* a buffer overrun in the name of fixing
another.
This single problem area (improper use of strncpy) accounts for a larger
chunk of code I've audited than I dare to admit -- all just timebombs
waiting for somebody to write an exploit for.
Then there's the annoyingly common matter of checking for return codes.
Walter has said this before, and he's spot on: 90% of C code out there
ignore error codes where they shouldn't, so as soon as a
normally-working syscall fails for whatever reason, the code cascades
down a chain of unexpected control flow changes and ends in catastrophe.
Or rather, in silent corruption of internal data because any signs that
something has gone wrong was conveniently ignored by the caller, of
course. And even when you *do* meticulously check for every single darn
error code evah, it's so ridiculously easy to make a blunder:
int my_func(mytype_t *input, outbuf_t *output_buf,
char *buffer, int size)
{
/* Typical lazy way of null-checking (that will blow up
* later) */
myhandle_t *h = input ? input->handle : 0;
writer_t *w = output_buf ? output_buf->writer : 0;
char *block = (char *)malloc(size);
FILE *fp;
int i;
if (!buffer)
return -1; /
Re: Static foreach pull request
On 09/05/2017 7:10 AM, Jack Stouffer wrote: 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. http://forum.dlang.org/thread/oenjmm$lds$1...@digitalmars.com
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: Jonathan Blow's presentation
On Tuesday, 9 May 2017 at 02:13:19 UTC, Nick Sabalausky (Abscissa) wrote: On 05/08/2017 03:28 PM, Jack Stouffer wrote: Uncompressed? Seriously? I assume that really means FLAC or something rather than truly uncompressed, but even still...sounds more like a bullet-list pandering^H^H^H^H^H^H^H^H^Hselling point to the same suckers^H^H^H^H^H^H^H"classy folk" who buy Monster-brand cables for digital signals than a legit quality enhancement. Take a top-of-the-line audio system, set down a room full of audiophiles, and compare lossless vs 320kbps Vorbis...in a true double-blind, no WAY they'd be able to consistently spot the difference even if they try. Let alone while being detracted by all the fun of causing mass mayhem and carnage. Unless maybe you just happen to stumble upon some kind of audio savant. Don't need to go that high. c't did a double blind study some years ago with the help of her sister magazine for audio equipment. So they made a very good setup. What they discovered is that mp3 with 160 kbit/s CBR was already undistinguishable from CD for 99% of people for almost all kind of music. mp3 is much better than its reputation, due to really bad encoders at the beginning (Xing was awful and was the widest used at the beginning, Fraunhofer was excellent but not free, lame took years before it was any good) people thought that the crap they heard was inherent to the mp3 format but very often it was bad grabbing, over eager lo-pass filtering and crappy psycho-acoustic models (Xing). So you make a good point that uncompressed audio for a game is completely nuts.
Re: What are we going to do about mobile?
On Thursday, 6 April 2017 at 05:24:07 UTC, Joakim wrote: That means this tidal wave of mobile swamping PCs is only going to get worse: https://twitter.com/lukew/status/842397687420923904 D is currently built and optimized for that dying PC platform. There are only two devs working on mobile, Dan and me, I don't think anybody on the core team has even tried our work. "dying". Just cause there aren't a lot of new devices being sold doesn't mean it is dying. There's the used market to consider, and PCs have a long lifespan. I have a 7 year old desktop that still runs perfectly fine and does all the tasks and computing I need to be done. I'll probably be using it for another few years, maybe when zen+ comes out or there's actually a reason to buy a new computer. Even then I won't be buying a prebuilt, not sure if those sales figures includes sales of PC parts. Even though new PC sales are declining, GPU sales are seeing a major increase in sales.
DConf 2017 Hackathon report
Please list what we've achieved during the hackathon, including what is started but is likely to be finished in the coming days or months. For me: - Finished updating "Programming in D" to 2.074.0 (the HTML is now up to date but I could not get to the still manual work of preparing the ebooks) - Contributed to the logo and branding discussions - Opened two bugs - Ate German cookies :) Ali
Re: Static foreach pull request
On 09.05.2017 05:06, Timon Gehr wrote: ... Some examples: https://github.com/tgehr/dmd/blob/71ab1280c88f9f0922fabf89ab3e7e1164b70e8b/src/test_staticforeach.d Better link: https://github.com/tgehr/dmd/blob/static-foreach/src/test_staticforeach.d
Re: Fantastic exchange from DConf
On 05/08/2017 08:42 PM, John Carter wrote: On Monday, 8 May 2017 at 20:55:02 UTC, John Carter wrote: C/C++ has been granted an extension of life by the likes of valgrind and purify and *-sanitizer. Google makes my point for me https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html That reminds me, I've been thinking for awhile: We need a dead-simple D/dub-ified tool to fuzz-test our D projects. Even if it's just a trivial wrapper and DUB package for an existing fuzz tester (heck, probably that's the right way to go anyway) we really should make fuzz testing just as common & easy a thing for D projects as doc-generation and unittests.
Re: Fantastic exchange from DConf
On 05/08/2017 04:55 PM, John Carter wrote: On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote: Walter: I believe memory safety will kill C. C/C++ has been granted an extension of life by the likes of valgrind and purify and *-sanitizer. I think you will find everything that really matters and is internet facing has been run up under a tool like that. Like Cloudflare and OpenSSL?
Static foreach pull request
Code: https://github.com/dlang/dmd/pull/6760 Some examples: https://github.com/tgehr/dmd/blob/71ab1280c88f9f0922fabf89ab3e7e1164b70e8b/src/test_staticforeach.d This is a complete proof-of-concept implementation of "static foreach". The semantics of the construct are given by merging the ones of static if and runtime foreach. This allows declarations to be generated using an imperative loop. If you are interested in static foreach making it into the language, please play with the implementation and tell me how to break it. It would also be nice to get some code reviews (the implementation is the result of two days of exhausting trial-and-error figuring out how the DMD frontend works).
Re: Jonathan Blow's presentation
On 05/08/2017 09:21 AM, Rel wrote: What do you guys think of the points explained here: https://www.youtube.com/watch?v=gWv_vUgbmug Watched the first 15-20 min of it. Definitely want to watch the rest. Buu.so far it's a good example of the *one* little thing that kinda bugs me about Johnathan Blow: I keep hearing him say the same things I've been saying for years, but because he wrote Braid, he can sometimes get people to actually listen instead of blindly dismissing everything. :/ (Granted that's not a fault of Blow's. But it still bugs me!) 1) The compile times seems very fast in comparison with other modern programming languages, I'm wondering how he managed to do it? By being a game (and engine) developer and knowing the basics of writing efficient code, unlike the majority of the software industry. (Seriously, if other circles of dev would pull their * out of their * long enough recognize all of what game programming obviously involves (ex: It's more than the glorified calculators that the upptity banking software is, and don't get me started on "enterprise" in general), then they could finally start learning how to write grown-up code and software today wouldn't suck so f** badly.) Also, not using header files. 2) Compile-time execution is not limited, the build system is interestingly enough built into the language. Nemerle had that years ago (although I'm guessing/hoping that unlike Nemerle, Blow's implementation probably doesn't require manually compiling to a DLL before being able to use given code at compile-time). My inclination is that it's the right approach, and is one thing that makes D look clunky and awkward by comparison. I never bought D's argument that compiling source shouldn't be allowed to do arbitrary code execution or I/O because, come on, "build scripts" and "build systems". That "no arbitrary code execution" ship sailed ages ago: Who in hell compiles software from source without using the provided buildscript or buildsystem configuration (all of which, by necessity, allow arbitrary code execution and IO)? Nobody who isn't searcing for their own little corner of hell, that's who. The *one* thing that does give me a little pause though is the possibility that order of compilation could change the results of generated code. I think it'll be interesting to see how that plays out in practice. "Don't do that" sounds nice, but the question remains: "Is it something that will happen without the author knowing he's doing it? If so, will it be a problem?"
Re: Jonathan Blow's presentation
On 05/08/2017 09:57 PM, Meta wrote: Ok, fair point. Let's look at Final Fantasy XIII (linear, non-open world console RPG released in 2009 on X360 and PS3, recently ported to PC) and The Witcher 3 (huge open world PC RPG released in 2015). FFXIII's size on disk is 60(!) GB, while The Witcher 3 is 40 GB. This isn't true all the time, but a lot of console games ported to PC take a surprisingly large amount of space. It's like they just unpacked the disk image, did an x86 build, then uploaded the whole thing to Steam with uncompressed assets and called it good enough. I don't know anything about Witcher, but FF13 *does* have a fair amount of pre-rendered video, FWIW. And maybe Witcher uses better compression than FF13? Also, just a side nitpik, but open-world vs non-open-world alone shouldn't have any impact on data size - the real factors in a game world's data size are overall size and detail of the game world. Whether it's open world is just a matter of how all the data in the game world is laid out, not how much data there is.
Re: Jonathan Blow's presentation
On 05/08/2017 03:28 PM, Jack Stouffer wrote: 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. Yea. The crazy thing is though, the huge sizes don't even buy as much as the numbers suggest. Major case of diminishing returns: Look at PS3 vs PS4 GTA5: Something like 25GB on PS3 and double that on PS4, and yea you *can* tell a difference, but its *very* slight, and usually you have to really look for it. (And then there's other games like Cod Ghosts and Destiny, where I honestly couldn't tell any difference whatsoever between the systems no matter how closely I looked, aside from a few extra particles in the particle systems...although I can't say what the size difference is on those games, maybe they just used the same assets for both systems on those games.) > uncompressed audio. Uncompressed? Seriously? I assume that really means FLAC or something rather than truly uncompressed, but even still...sounds more like a bullet-list pandering^H^H^H^H^H^H^H^H^Hselling point to the same suckers^H^H^H^H^H^H^H"classy folk" who buy Monster-brand cables for digital signals than a legit quality enhancement. Take a top-of-the-line audio system, set down a room full of audiophiles, and compare lossless vs 320kbps Vorbis...in a true double-blind, no WAY they'd be able to consistently spot the difference even if they try. Let alone while being detracted by all the fun of causing mass mayhem and carnage. Unless maybe you just happen to stumble upon some kind of audio savant.
D to C# conversion of GPS Data
Does anyone know how to convert this D code to C# ?
string[] parse_gps_data(string data, SysTime start_time, SysTime
end_time) {
// Validate input
string[] gps;
if (!data.length) {
error("Empty GPS file");
return gps;
}
auto start_timestamp = start_time.toUnixTime();
auto end_timestamp = end_time.toUnixTime();
// Parse every line
foreach (line; splitLines(data)) {
// Detect type of line
auto match = matchFirst(line, GPS_LINE);
if (!match) {
// Unknown format
error("Unknown GPS line: " ~ line);
continue;
}
// Parse time
auto record_time = SysTime.fromISOExtString(match[1].replace("
", "T"));
auto record_timestamp = record_time.toUnixTime();
if (record_timestamp < start_timestamp || record_timestamp >
end_timestamp) {
// Skip invalid time interval
error(format(
"Invalid GPS interval: %d > %d || %d < %d\nLine:
%s",
record_timestamp, start_timestamp, record_timestamp,
end_timestamp,
line
));
continue;
}
// Parse coordinates
float longitude;
float latitude;
if (to!char(match[2]) == 'N') {
latitude = to!float(match[3]);
if (to!char(match[4]) == 'W') {
longitude = to!float(match[5]) * -1;
}
else {
longitude = to!float(match[5]);
}
}
else if (to!char(match[2]) == 'W') {
longitude = to!float(match[3]) * -1;
latitude = to!float(match[5]);
}
else if (to!char(match[2]) == 'E') {
longitude = to!float(match[3]);
latitude = to!float(match[5]);
}
// Prepare gps timestamp
auto record_interval = (record_time -
start_time).split!("hours", "minutes", "seconds")();
gps ~= format(
"('%02d:%02d:%02d', '(%f, %f)'::point)::time_point",
record_interval.hours, record_interval.minutes,
record_interval.seconds,
longitude, latitude
);
}
return gps;
}
I would appreciate if anyone who has both D and C# experience.
So far I have this :
///
///
///
///
///
///
public string[] ParseGPSData (string deviceData, DateTime
startTime, DateTime endTime)
{
string[] gps = null;
if (deviceData == string.Empty)
return gps;
var startTimeStamp = startTime.ToUniversalTime ();
var endTimeStamp = endTime.ToUniversalTime ();
foreach (var line in Regex.Split(deviceData, "\r\n
|\r |\n"))
{
var match = _rx.Match(line);
if (!match.Success)
continue;
var recordTime = match.Groups[1].Value.Replace ('
', 'T');
}
return gps;
}
}
The constructor for GPS class has this defined :
public class GPSEngine
{
private Regex _rx;
///
///
///
public GPSEngine ()
{
_rx = new Regex
(@"^(\d{4}-\d{2}-\d{2}\s+\d{2}:\d{2}:\d{2})\s+(N|W|E)(\d+\.\d+)\s+(N|W|E)(\d+\.\d+)",
RegexOptions.Compiled | RegexOptions.IgnoreCase);
}
Re: Jonathan Blow's presentation
On Monday, 8 May 2017 at 19:28:51 UTC, Jack Stouffer wrote: 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. Ok, fair point. Let's look at Final Fantasy XIII (linear, non-open world console RPG released in 2009 on X360 and PS3, recently ported to PC) and The Witcher 3 (huge open world PC RPG released in 2015). FFXIII's size on disk is 60(!) GB, while The Witcher 3 is 40 GB. This isn't true all the time, but a lot of console games ported to PC take a surprisingly large amount of space. It's like they just unpacked the disk image, did an x86 build, then uploaded the whole thing to Steam with uncompressed assets and called it good enough.
Re: Fantastic exchange from DConf
On Monday, 8 May 2017 at 20:55:02 UTC, John Carter wrote: On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote: Walter: I believe memory safety will kill C. C/C++ has been granted an extension of life by the likes of valgrind and purify and *-sanitizer. Google makes my point for me https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html Index out of bounds exceptions are great... but the elements of Walter's talk where bugs are banished at compile time are more compelling. Now if we can get to the point where there is no undefined behaviour in any safe code... that would be a major step forward.
Re: What are we going to do about mobile?
On 5/8/17 9:26 PM, Bienlein wrote: Let's not forget Kotlin and Swift, things we'd really be competing against - that is the other NEW stuff. Kotlin/Native is now in the making and there is already a preview: https://blog.jetbrains.com/kotlin/2017/04/kotlinnative-tech-preview-kotlin-without-a-vm/ All in all Kotlin is a decent language, also since JetBrains has Russian roots I kind of sympathize its development :) --- Dmitry Olshansky
Re: DLang quarterly EU?
On Monday, 8 May 2017 at 20:45:57 UTC, Johan Engelen wrote: Can we get a cool acronym / name for this thing? Helps when talking with people about it. ;-) DBeers? That's a diamond name ;-)
Re: DLang quarterly EU?
On Monday, 8 May 2017 at 21:02:22 UTC, Moritz Maxeiner wrote: On Monday, 8 May 2017 at 20:45:57 UTC, Johan Engelen wrote: Can we get a cool acronym / name for this thing? Helps when talking with people about it. ;-) Deuconf? how about we get it first to work for everybody. win-deu-conf
Re: DLang quarterly EU?
On Monday, 8 May 2017 at 20:45:57 UTC, Johan Engelen wrote: Can we get a cool acronym / name for this thing? Helps when talking with people about it. ;-) Deuconf?
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. Bait [1]? The things that need it aren't written in C Except - of course - for virtually all of our entire digital infrastructure. there's a lot of programs out there that just don't require it. Just not anything that may run on a system connected to the internet. [1] https://nvd.nist.gov/vuln/search/results?adv_search=false&form_type=basic&results_type=overview&search_type=all&query=remote+buffer+overflow
Re: Fantastic exchange from DConf
On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote: Walter: I believe memory safety will kill C. C/C++ has been granted an extension of life by the likes of valgrind and purify and *-sanitizer. I think you will find everything that really matters and is internet facing has been run up under a tool like that. They are truly wonderfully power tools... with the limitation that they are run time. ie. If you don't run that line of code... they won't tell you if you have it wrong. Index out of bounds exceptions are great... but the elements of Walter's talk we bugs are banished at compile time are more compelling. Now if we can get to the point where there is no undefined behaviour in any safe code... that would be a major step forward. Languages like Ruby are memory safe... but they are written in C and hence have a very long catalog of bugs found and fixed in the interpretor and supporting libraries. D has the interesting promise of being memory safe and the compiler and libraries being written in D.
Re: DLang quarterly EU?
On Saturday, 6 May 2017 at 23:53:45 UTC, Ethan Watson wrote: Rather than a city meet up monthly, what about a continental meet up quarterly? Can we get a cool acronym / name for this thing? Helps when talking with people about it. ;-) cheers, Johan
Re: Jonathan Blow's presentation
On Monday, 8 May 2017 at 19:11:03 UTC, Ethan Watson wrote: unless you want to try making a 45 gigabyte executable for current Playstation/Xbox games Just yesterday I was listening to my son cursing his Xbox as it downloaded 72 GB before he could play his game...
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 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
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.
Re: What are we going to do about mobile?
Let's not forget Kotlin and Swift, things we'd really be competing against - that is the other NEW stuff. Kotlin/Native is now in the making and there is already a preview: https://blog.jetbrains.com/kotlin/2017/04/kotlinnative-tech-preview-kotlin-without-a-vm/
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Friday, 21 April 2017 at 17:20:14 UTC, Vasudev Ram wrote: Hi list, I hope the question is self-evident from the message subject. If not, it means: what are D developers generally called (to indicate that they develop in D)? The question occurred to me somehow while browsing some D posts on the forums just now. DLanger? DLangist? D'er? Doer? :) I tend to favor DLanger, FWIW. Interested to know, just for fun ... Here is one for the fun : Dentists 😂
Re: Jonathan Blow's presentation
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.
Re: Jonathan Blow's presentation
On Monday, 8 May 2017 at 16:10:51 UTC, Rel wrote: I don't know if I ever will need it in my code. For the game development use case it may be useful, for example to package all of the game assets at compile time. It's only useful for very select cases when hardcoded assets are required. You know, unless you want to try making a 45 gigabyte executable for current Playstation/Xbox games. A talk I watched the other year made the point that as far as textures go in video games, literally all but 10 you'll ever use are read only so stop trying to program that exception as if it's a normal thing. Hardcoding a select few assets is also a case of a vast-minority exception. There's ways to do it on each platform, and it's not really worth thinking about too much until those rare times you need one. Embedding inside the executable is also already a thing you can do in D with the import keyword.
Thoughts on some code breakage with 2.074
Recently the EMSI data department upgraded the compiler we use to build our data processing code to 2.074. This caused several of the thousands of processes to die with signal 8 (floating point exceptions). This was caused by the fix to issue 17243. This is a good thing. We need more breaking changes like this. Now that the floating point exceptions are properly enabled we were able to track down some issues that were being silently ignored.
Re: Fantastic exchange from DConf
Anything that goes on the internet already has memory safety. The things that need it aren't written in C, there's a lot of programs out there that just don't require it. C won't be killed, there's too much already written in it. Sure there might be nothing new getting written in it but there will still be tons of software that needs to be maintained even if nothing new is being written in it. D also won't be that far behind it if that's truly the reason C gets 'killed'. Anyways can't watch the discussion as it's private.
Re: Jonathan Blow's presentation
On Monday, 8 May 2017 at 14:47:36 UTC, Ethan Watson wrote: I can answer #1, I know a few things there but that's more something he should talk about as I don't know how public he's made that knowledge. Well, I know that DMD in particular made a trade off not to collect garbage during the compilation to improve the speed, so it is really interesting to look at their compiler sources to find out what they did to make it compile so quickly. On Monday, 8 May 2017 at 14:47:36 UTC, Ethan Watson wrote: I also put forward to him a case with regards to compile time execution and code generation. Say you've got a global variable that you write to, and reading from that changes the kind of code you will generate. Thus, your outputted code can be entirely different according to whenever the compiler decides to schedule that function for execution and compilation. His response was, "Just don't do that." That's essentially the philosophical difference there. Jonathan wants a language with no restrictions, and leave it up to the programmer to solve problems like the above themselves. Whether you agree with that or not, well, that's an entirely different matter. At very least it is interesting to have this feature, I don't know if I ever will need it in my code. For the game development use case it may be useful, for example to package all of the game assets at compile time. I've seen similar thing being very popular in different Haxe-based game frameworks, though Haxe seems to be a bit more restrictive in this regard.
Re: Jonathan Blow's presentation
On Monday, 8 May 2017 at 13:21:07 UTC, Rel wrote: What do you guys think of the points explained here: https://www.youtube.com/watch?v=gWv_vUgbmug Seems like the language shares a lot of features with D programming language. However there are several features that caught my interest: 1) The compile times seems very fast in comparison with other modern programming languages, I'm wondering how he managed to do it? 2) Compile-time execution is not limited, the build system is interestingly enough built into the language. I was at that talk, and spoke to him quite a bit there. He also attended my talk. And yes, there is quite a bit of overlap in terms of features. He's well in to design by introspection, for example. I can answer #1, I know a few things there but that's more something he should talk about as I don't know how public he's made that knowledge. I also put forward to him a case with regards to compile time execution and code generation. Say you've got a global variable that you write to, and reading from that changes the kind of code you will generate. Thus, your outputted code can be entirely different according to whenever the compiler decides to schedule that function for execution and compilation. His response was, "Just don't do that." That's essentially the philosophical difference there. Jonathan wants a language with no restrictions, and leave it up to the programmer to solve problems like the above themselves. Whether you agree with that or not, well, that's an entirely different matter.
Re: reasoning of evaluating code after return in current block (static if return)
On Sunday, 7 May 2017 at 23:41:00 UTC, bastien penavayre wrote: On Sunday, 7 May 2017 at 23:20:26 UTC, Adam D. Ruppe wrote: [...] I just realized that I accidentally posted this while editing. I agree with you on that this is barely different from just adding "else". [...] compile your code with the -vcg-ast switch and look at the .cg output.
Jonathan Blow's presentation
What do you guys think of the points explained here: https://www.youtube.com/watch?v=gWv_vUgbmug Seems like the language shares a lot of features with D programming language. However there are several features that caught my interest: 1) The compile times seems very fast in comparison with other modern programming languages, I'm wondering how he managed to do it? 2) Compile-time execution is not limited, the build system is interestingly enough built into the language.
Re: DIP 1004 Preliminary Review Round 1
On Monday, 1 May 2017 at 14:55:28 UTC, Mike Parker wrote: DIP 1004 is titled "Inherited Constructors. Mike, given the general feedback I've received here, I think the next best take of action is to split the implicit inheritance proposal into a separate, smaller DIP, and update DIP 1004 with a second draft. Thoughts?
