Re: Why does nobody seem to think that `null` is a serious problem in D?
On Monday, 19 November 2018 at 21:57:11 UTC, Neia Neutuladh wrote: Programmers coming from nearly any language other than C++ would find it expected and intuitive that declaring a class instance variable leaves it null. What do you think about making the syntax slightly more explicit and warn or possibly error out if you don't do it that way? Either SomeClass c = null; or SomeClass c = new SomeClass(); and nothing else. The compiler *could* give you a warning that you're using an uninitialized variable in a way that will lead to a segfault, but that sort of flow analysis gets hard fast. Nulls/Nones are always a big gap in a language's type system. A common alternative is to have some Option/Maybe type like Rust or Haskell or D's Variant. How about making that required to plug the null gap? If you wanted the default constructor to be called implicitly, Yeah, maybe this bit of C++ syntax isn't the best idea. What about other alternatives?
Re: Why does nobody seem to think that `null` is a serious problem in D?
On Monday, 19 November 2018 at 21:52:47 UTC, Steven Schveighoffer wrote: A null pointer dereference is an immediate error, and it's also a safe error. It does not cause corruption, and it is free (the MMU is doing it for you). Is this always true for all arches that D can compile to? I remember back in the DOS days with no memory protection you really could read OS data around the beginning. Consistent segfaults are generally easy to figure out. I think I would still prefer a stack trace like other kinds of D errors. Is this too difficult?
Why does nobody seem to think that `null` is a serious problem in D?
When I was first playing with D, I managed to create a segfault by doing `SomeClass c;` and then trying do something with the object I thought I had default-created, by analogy with C++ syntax. Seasoned D programmers will recognise that I did nothing of the sort and instead created c is null and my program ended up dereferencing a null pointer. I'm not the only one who has done this. I can't find it right now, but I've seen at least one person open a bug report because they misunderstood this as a bug in dmd. I have been told a couple of times that this isn't something that needs to be patched in the language, but I don't understand. It seems like a very easy way to generate a segfault (and not a NullPointerException or whatever). What's the reasoning for allowing this?
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Tuesday, 10 July 2018 at 20:28:00 UTC, Seb wrote: Maybe looking at the recent DMD Backend to D conversion PRs (https://github.com/dlang/dmd/pulls?utf8=%E2%9C%93=is%3Apr+label%3A%22D+Conversion%22+) helps? Here -betterC is used. Octave is so far from -betterC, though. It's very C++-heavy, with C++11 features being used since the last couple of years. It's an old codebase that started circa 1992. Just getting it into -betterC territory seems like a very daunting task.
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Wednesday, 20 June 2018 at 19:57:55 UTC, jmh530 wrote: I'm not sure adding D to the GNU Octave code base is necessarily the biggest value add... I'm daydreaming of being able to rewrite all of Octave in D. I just was trying to think of where to start.
Is it feasible to slowly rewrite a C++ codebase in D?
I'm specifically thinking of the GNU Octave codebase: http://hg.savannah.gnu.org/hgweb/octave/file/@ It's a fairly old and complicated C++ codebase. I would like to see if I could slowly introduce some D in it, anywhere. Now, as I understand it, I would need to begin with making `main` a D function, because D needs to initialise the runtime. Is this correct? Another possibility might be in dlopen'able functions. Currently Octave uses so-called oct functions, which are nothing more than C++ object code that is dynamically loaded by the interpreter at runtime. They are compiled to the Octave C++ API, but we also have a Matlab-compatible C API that perhaps could be more amenable for D-ification. What are your ideas?
Re: Proposal for a standard Decimal type in alpha
On Wednesday, 14 March 2018 at 14:57:12 UTC, rumbu wrote: For 20 decimal digits, you can use decimal128 (having a 34 decimal digits precision) and set the context precision to 20. http://rumbu13.github.io/decimal/doc/decimal.html#.DecimalControl.precision I would also sometimes like around 1000 decimal digits. It's fun to compute digits of pi, especially today (or zeta(3) or whatever). Can yours do that?
Re: Proposal for a standard Decimal type in alpha
On Wednesday, 14 March 2018 at 14:29:48 UTC, Seb wrote: https://forum.dlang.org/thread/mutegviphsjwqzqfo...@forum.dlang.org?page=1 While certainly impressive and feature-complete, rumbu's isn't a bigdecimal library. I need arbitrary precision (in this case, exactly 20 decimal digits), not only IEEE 754 decimals. Jack, I think that's what you're doing instead?
Re: Proposal for a standard Decimal type in alpha
On Friday, 12 January 2018 at 15:44:01 UTC, Jack Stouffer wrote: 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. I was daydreaming today about using D to replace a certain Python computation module at work, but to do this, we really require a bigfloat/bigdecimal type. I think I might want to help completing this work, either your's or rumbu's. What's the code to look at? I found yours, but I couldn't find rumbu's.
Re: Advent of D
On Wednesday, 7 March 2018 at 21:35:06 UTC, Russel Winder wrote: On Tue, 2018-03-06 at 18:09 +, Jordi Gutiérrez Hermoso via Digitalmars-d wrote: I wrote a blog post about working on Advent of Code in D. You can read it here: http://jordi.inversethought.com/blog/advent-of-d/ Another blog post deserving of formal publication in an ACCU journal. Hm, I quickly looked at what that is. Some sort of informal journal? You think if I adapted the blog post for a print publication, they would take it?
Re: Advent of D
On Wednesday, 7 March 2018 at 14:50:34 UTC, Mike Parker wrote: On Wednesday, 7 March 2018 at 14:43:24 UTC, Jordi Gutiérrez Hermoso wrote: I only see it here: https://www.reddit.com/r/d_language/comments/82i0s4/advent_of_d/ There don't seem to be duplicate reposts to other subreddits. Where are you seeing it? Sorry, should have pasted the link: https://www.reddit.com/r/programming/comments/82j5m0/advent_of_d_a_good_overview_of_d_programming/ Ah, I see. Pity. Maybe it'll get rediscovered in a few months and people will post it again.
Re: Advent of D
On Wednesday, 7 March 2018 at 14:02:19 UTC, Mike Parker wrote: On Wednesday, 7 March 2018 at 01:07:54 UTC, Mike Parker wrote: On Tuesday, 6 March 2018 at 21:09:06 UTC, Jordi Gutiérrez Hermoso wrote: Posting to Reddit is easier, but I don't have a recognisable account on Reddit to post it from. I'll post it. There are good times and bad times to post on /r/programming in terms of getting attention. A good time would be in about ~12 hours or so. Ah, well. Someone had already submitted it. And completely missed the window :-( Oh? I only see it here: https://www.reddit.com/r/d_language/comments/82i0s4/advent_of_d/ There don't seem to be duplicate reposts to other subreddits. Where are you seeing it?
Re: Advent of D
On Tuesday, 6 March 2018 at 20:37:34 UTC, Steven Schveighoffer wrote: On 3/6/18 1:09 PM, Jordi Gutiérrez Hermoso wrote: I wrote a blog post about working on Advent of Code in D. You can read it here: http://jordi.inversethought.com/blog/advent-of-d/ I'm enjoying this. One thing jumped out at me: static does not mean execute at compile time (exactly), it really means allocate this data in thread-local storage. Thanks for the explanation. I forgot about using enum instead. I think I've only briefly encountered it before. I'm aware of the global storage of static in this context. I like that it's the same keyword for static foreach; that's kind of what I was thinking when I wrote that just adding a static can result in compile-time execution. BTW, that tour page needs updating, it has a few errors in it. You mean the Dlang tour? I've been meaning for a while to be able to generate a url to its Gems section but I've never managed to untangle its Vibe.d structure enough to do so.
Re: Advent of D
On Tuesday, 6 March 2018 at 21:03:47 UTC, JN wrote: On Tuesday, 6 March 2018 at 18:09:21 UTC, Jordi Gutiérrez Hermoso wrote: I wrote a blog post about working on Advent of Code in D. You can read it here: http://jordi.inversethought.com/blog/advent-of-d/ on Day 8, I think the original "verbose" code is better in the end. Mixin at least for me makes it a bit less clear on what exactly is going on. On the other hand the latter version is probably easier to maintain and more copy-paste-error-proof. Yeah, it's mostly the C that I wanted to get rid of. I do wish the static foreach had worked, though! It's odd that you can't have compile-time associative arrays.
Re: Advent of D
On Tuesday, 6 March 2018 at 20:09:58 UTC, Joakim wrote: Nice write-up, worth sharing on reddit/HN. Thanks. I tried posting it to HN, but it didn't pick up. If several of you try posting it too, it might pick up. Posting to Reddit is easier, but I don't have a recognisable account on Reddit to post it from. I did post it to Lobsters, though: https://lobste.rs/s/b4qki7/advent_d
Advent of D
I wrote a blog post about working on Advent of Code in D. You can read it here: http://jordi.inversethought.com/blog/advent-of-d/
Re: What's the proper way to use std.getopt?
On Tuesday, 12 December 2017 at 20:57:28 UTC, Jon Degenhardt wrote: On Monday, 11 December 2017 at 20:58:25 UTC, Jordi Gutiérrez Hermoso wrote: What's the proper style, then? Can someone show me a good example of how to use getopt and the docstring it automatically generates? [snip] See: https://github.com/eBay/tsv-utils-dlang/blob/master/tsv-sample/src/tsv-sample.d Oh, thanks! This is more or less what I wanted. I suppose showing all of the docstring when the arguments are bad is possibly stupid and I shouldn't be doing that to begin with. I'll adopt this style to only show which argument was bad.
Re: What's the proper way to use std.getopt?
On Monday, 11 December 2017 at 21:24:41 UTC, Mike Wey wrote:
try
{
auto helpInformation = getopt(
args,
"input|i", "The input", ,
"output|o", "The output",
);
if (helpInformation.helpWanted)
{
defaultGetoptPrinter("Description", helpInformation.options);
exit(0);
}
}
catch (GetOptException e)
{
writeln(e.msg);
exit(1);
}
But I would like to show the help docstring when processing the
exception. It's pretty standard behaviour. If you give a program
bad arguments, it just spits out a docstring of all options and
what each does. Can this be achieved?
Re: Why is there no std.stream anymore?
On Monday, 11 December 2017 at 21:21:51 UTC, Steven Schveighoffer wrote: Use the undead repository: Wow, really? Is the removal of stream from D some kind of error that hasn't been corrected yet?
What's the proper way to use std.getopt?
I don't quite understand what to do if getopt throws. I would
have hoped for something like
int arg1;
string arg2;
auto parser = getopt("opt1", "docstring 1", , "opt2",
"docstring 2", );
try {
auto opts = parser.parse(args)
}
except(BadArguments) {
parser.showHelpString();
}
but instead, the docstring from getopt is only generated if all
arguments are valid, i.e. when it's the least needed because the
user already knew what to input.
What's the proper style, then? Can someone show me a good example
of how to use getopt and the docstring it automatically generates?
Why is there no std.stream anymore?
I'd like to read from a file, one byte at a time, without loading
the whole file in memory.
I was hoping I could do something like
auto f = File("somefile");
foreach(c; f.byChar) {
process(c);
}
but there appears to be no such way to do it anymore. Instead,
the stdlib seems to provide several functions to do chunked reads
from the file where I have to manually manage the buffer. I see
that D1 had a stream, but it's no longer here and I understand
ranges are supposed to be used instead.
What's the explanation here? Why is there no more stream and what
am I supposed to use instead? Do I really need to be manually
managing the read buffer myself?
