Re: Beta 2.108.0
On Saturday, 16 March 2024 at 09:26:20 UTC, Iain Buclaw wrote: The RC for 2.108 has been released, which includes the following changes from the initial beta: - Named Arguments is now implemented and documented as a new feature in this release. The beta supports the feature, but was left undocumented while some remaining issues were being fixed. - Hexstrings now implicitly convert to integer arrays. The beta had introduced support to allow casting to arrays only. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.108.0.html As usual please report any bugs at https://issues.dlang.org -Iain on behalf of the Dlang Core Team It's only getting a quick mention in the middle of the list of bug fixes, but "Bugzilla 24397: Support C preprocessor function-like macros" is a big deal for ImportC - that was the final piece needed to use ImportC with large C files without manual intervention. (At least that's the case for the code I'm working with.)
Re: Is D programming friendly for beginners?
On Tuesday, 12 March 2024 at 19:07:25 UTC, M.M. wrote: I was always wondering about this debate on a suitable "first" programming language in a CS curriculum. I largely observe one dividing point: to start with a strongly-typed language or not. (After that, it probably does not matter so much which language is chosen; alas, it should be available on Windows, Linux, and Mac OS). Do you observe similar sentiment in the discussions in the university settings? I'm not a CS person so I'll have to defer to others (their needs are very different). My grad students are doing more complicated programming for data analysis and simulation. I focus on recursion and using a functional programming approach, because that simplifies things so much for these types of problems. All I need is a language that supports that.
Re: Is D programming friendly for beginners?
On Tuesday, 12 March 2024 at 17:03:42 UTC, Mike Shah wrote: As a note, the 'which language is best for CS 1' debate has long been debated -- but at least in a school setting, I've found the quality/enthusiasm/encouragement of the teacher to be the most important aspect regardless of language choice. As someone that's been teaching beginners to program at a university for a long time (but not in a CS department) I've come to see the choice of language as largely unimportant. You have to decide what you want to teach them and then eliminate the languages that aren't suitable. D is one of many languages that would work with the right content. Other languages, like C++, add unnecessary overhead and thus should not be used. It's often said "X is a complicated language" but that's the wrong way to look at it. You're teaching a set of programming concepts, not a language. The question is how well a particular language works for learning those concepts.
Re: R and D interop with saucer
On Tuesday, 9 January 2024 at 19:56:38 UTC, data pulverizer wrote:
I'd encourage you to approach this however you like, but for the
sake of anyone else reading this, I want to correct a few points.
I'm guessing you haven't spent any time understanding embedrv2.
Regarding your `R.lib` file (embedrv2 and the previous
version), I thought it might have something to do with Weka,
the machine learning library - I got my wires crossed there.
Perhaps I was reading something to do with the ML library
before/while I was reading your repo. My point still stands
though. I've never worked anywhere that would allow a developer
to install unverified pre-compiled code from an online repo. It
would pose too much of a security issue.
That's not "unverified pre-compiled code". As I said, it's an
import library for Windows, from an attempt long ago to call R
from D on Windows. You don't call the .dll file directly on
Windows, you call the .lib file. It's the same thing you do with
OpenBLAS and many other popular libraries.
As I explained my approach is to mirror the 'design language'
of Rcpp/RInside/cpp11 libraries, because its a great approach,
I'm familiar with it, and so are many others. A user (including
myself) will be sensitive to on-boarding and usage friction, so
I my library will present a clear, familiar, and easy to use
interface.
I'm familiar with Rcpp/RInside/cpp11. If you go to the CRAN page
for RInside, you'll see I'm one of the authors. If you check out
Dirk's 2013 book, you'll see that one of the sections in it was
based on an example I gave him. I haven't done much with cpp11,
but that's because I was already using D before it existed.
embedrv2 does exactly the same thing. You write your D function
and metaprogramming is used to create a wrapper that you can call
from R without further modification.
I didn't know about your betterr R package. I think it is a
different approach from the one I would take. I think both Rcpp
and in particular cpp11 have very good design approaches and
continuous improvements to their design that gives me plenty to
think about. They are at the cutting edge and are pushing the
boundaries, and I think it would be cool to show that D can
play in the same space with ease, finesse, and style.
Since you've clearly never used it and don't know how it works,
why are you trashing it? I'll let anyone else judge how awkward,
complicated and lacking in style it is. Here's the example from
the landing page:
```
void main() {
// Initialization
startR();
// Generate 100 draws from a N(0.5, sd=0.1) distribution
Vector x = rnorm(100, 0.5, 0.1);
// Create a 3x2 matrix and fill the columns
auto m = Matrix(3,2);
Column(m,0) = [1.1, 2.2, 3.3];
Column(m,1) = [4.4, 5.5, 6.6];
// Calculate the inverse of the transpose
auto m2 = solve(t(m));
// Modify the second and third elements of the first column of m
m[1..$,0] = [7.7, 8.8];
// Choose x and y to minimize x^2 + y^2
// Use Nelder-Mead with initial guesses 3.5 and -5.5
auto nm = NelderMead();
OptimSolution sol = nm.solve([3.5, -5.5]);
// Clean up
closeR();
}
extern(C) {
double f(int n, double * par, void * ex) {
return par[0]*par[0] + par[1]*par[1];
}
}
```
That's ten lines of code to generate a vector of random numbers,
create and fill a matrix, take the inverse of the transpose of
the matrix, mutate the matrix, and solve a nonlinear optimization
problem.
I don't care that you're not using it. Have fun creating your own
project. That doesn't excuse writing falsehoods about the work
I've done.
Re: R and D interop with saucer
On Saturday, 30 December 2023 at 00:50:54 UTC, data pulverizer
wrote:
That's a great point. I really can't remember what stage I was
writing saucer when I became aware of EmbedR, but one thing I
didn't understand was why it had to have pre-compiled weka?
code within the package this is the `R.lib` file, which is a
nonstarter security-wise. I also felt that such a project
should have strong syntactic similarities with Rcpp to
facilitate adoption, that it should have a nicer easier
interface, that it would be a good learning experience for me,
and that I could (probably) do a decent job at it.
I have updated the package to include a reference to EmbedR
outlining these points. Interestingly enough, there is a Rust
package for R and D interop called embedr as well
(https://docs.rs/extendr-api/latest/extendr_api/).
Here is the updated version of embedr:
https://github.com/bachmeil/embedrv2
The old version you're referencing is from ages ago. I don't know
what you mean by Weka code. There was an old import library from
when I tried to get embedding of R inside D to work on Windows.
The updated library generates the R bindings for the user. There
might be something useful there, and the code isn't very long:
https://github.com/bachmeil/embedrv2/blob/main/inst/embedr/r.d#L1228 There's an extern_R attribute to specify which functions to export to R.
Here's an example from the readme:
```
@extern_R ar1irf(double alpha, double shock, int h) {
double[] result;
result ~= shock;
foreach(ii; 1..h) {
result ~= alpha * result.last;
}
return result;
}
mixin(exportRFunctions);
double last(double[] v) {
if (v.length > 0) {
return v[$-1];
} else {
return 0.0;
}
}
```
I honestly don't use D much as a replacement for Rcpp any longer.
I mostly work in the other direction these days:
https://bachmeil.github.io/betterr/ I've been adding Windows
support lately so I can share my code with others.
There are possibly things in there that are useful to you
(whether D calls R or R calls D is not relevant for working with
the API). For instance, if you want to pass a function to R
without creating a shared library (one example being an objective
function for optimization):
https://bachmeil.github.io/betterr/funcptr.html Another is using
a custom allocator to pass data to R even if it was allocated in
D:
https://github.com/bachmeil/betterr/blob/main/testing/testalloc.d
There are pieces of knowledge I gained by debugging segfaults,
like the fact that certain operations will change the pointer of
an array and that sort of thing.
Re: New DUB documentation
On Wednesday, 22 November 2023 at 21:35:34 UTC, WebFreak001 wrote: the revamped DUB documentation I started a while ago is now deployed on https://dub.pm Limiting my comments to the "Getting Started" page, since that's obviously where new programmers will go first. On the very first page, there are links to the DUB registry website and assorted man pages. You've just lost half the audience right there. The best possible outcome is that the user is confused but pushes on. It says "You can also skip ahead to First steps if you already have dub installed." How do they know if it's installed? The first page has to be crystal clear. It can't have distractions or require knowledge of the installation status of this thing called "DUB". The "First Steps" page is likely to be the last steps for many. It provides a CLI command and then shows a bunch of output from an interactive session with no explanation. That's followed by a brief discussion of directories and files. There's also mention of .gitignore, so I guess that means Git is required to use DUB. Then there's discussion of two formats, with no information on how to choose, or why it's important. That's followed by a presentation of configuration files with no explanation. I wish I could be positive, but this doesn't move the needle. The two key ingredients for a getting started guide are examples and explanations, and both are missing.
Re: From the D Blog: Crafting Self-Evident Code in D
On Monday, 2 October 2023 at 17:28:19 UTC, Mike Parker wrote:
It's been a long, long while since I published anything on the
blog. I do intend to get pick it up again down the road, but
Walter recently surprised me with plans of his own. He's taken
the topic of his DConf '23 talk and derived a blog post from it:
https://dlang.org/blog/2023/10/02/crafting-self-evident-code-with-d/
I guess he got impatient with the pace at which I'm getting the
talk videos uploaded :-)
And for anyone who'd like to engage in any Reddit discussion
that comes up:
https://www.reddit.com/r/programming/comments/16y2h36/crafting_selfevident_code_in_dlang/
I wonder if Walter has an opinion on this. In a .c file:
```
void *(STDVEC_DATAPTR)(SEXP x) {
if (ALTREP(x))
error("cannot get STDVEC_DATAPTR from ALTREP object");
if (! isVector(x) && TYPEOF(x) != WEAKREFSXP)
error("STDVEC_DATAPTR can only be applied to a vector, not a
'%s'",
type2char(TYPEOF(x)));
CHKZLN(x);
return STDVEC_DATAPTR(x);
}
```
`CHKZLN(x)` only does some checks. It doesn't have any side
effects. After scratching my head for a bit, I used grep to
locate this in a .h file:
```
#define STDVEC_DATAPTR(x) ((void *) (((SEXPREC_ALIGN *) (x)) + 1))
```
And of course, there were no comments to explain what is going
on. Very self-evident.
Re: From the D Blog: Crafting Self-Evident Code in D
On Wednesday, 4 October 2023 at 19:50:55 UTC, claptrap wrote: On Wednesday, 4 October 2023 at 12:50:16 UTC, bachmeier wrote: On Wednesday, 4 October 2023 at 07:26:25 UTC, claptrap wrote: I personally found this talk very disappointing. Walter is the head honcho and he's giving talks on coding guidelines? Its like visiting the F1 engineering workshop and getting a talk on health and safety. Tell us the engine, about what you're working on, some gnarly problem you've solved, or something cool. Walter's a contributor to this open source project like anyone else. He's going to give talks on whatever strikes his interest at the time. If he was a CEO with a 7-figure salary like Mitchell Baker, things would be different. Hes not like everyone else he's... "Walter bright creator of the D Programming Language" That means he's contributed a lot in the past, so he has more freedom, not less, in choosing what to talk about. Your post is an example of a contribution tax. Those that do the most work on a project are held to a higher standard than everyone else, and they are the ones most open to criticism, including public criticism. It's one reason productive contributors leave open source projects, and why many people turn down leadership positions.
Re: From the D Blog: Crafting Self-Evident Code in D
On Wednesday, 4 October 2023 at 07:26:25 UTC, claptrap wrote: I personally found this talk very disappointing. Walter is the head honcho and he's giving talks on coding guidelines? Its like visiting the F1 engineering workshop and getting a talk on health and safety. Tell us the engine, about what you're working on, some gnarly problem you've solved, or something cool. Walter's a contributor to this open source project like anyone else. He's going to give talks on whatever strikes his interest at the time. If he was a CEO with a 7-figure salary like Mitchell Baker, things would be different.
Re: From the D Blog: Crafting Self-Evident Code in D
On Tuesday, 3 October 2023 at 12:01:56 UTC, Martyn wrote: Agreed. Even though I do like UFCS, I find the above confusing to follow despite being more pleasing to the eye. I had to break it down and, as Matheus already pointed out, looked incorrect. I normally avoid writing code like a.b.c.d.e.f because it obscures the intermediate steps. I define variables that hold the results of one or a small number of steps so I can track what the code is doing.
Re: DasBetterR
On Tuesday, 1 August 2023 at 12:37:58 UTC, jmh530 wrote: You mention creating a better interface, but recall for rstan to work you need to put the data into an R list with names that match what is in your program (your stan program could be all kinds of complicated with all kinds of different naming conventions). For it to be seamless, you would need to be able to pass a named D tuple to R easily. rstanarm might be easier to create initially, but I don't use that much. That should easy using a list, [as demonstrated here](https://github.com/bachmeil/betterr/blob/main/testing/testlist.d). Anyway, it looks like you have done the hard work in terms of figuring out the code needed to pass a pointer to double[] from D to R. Is that something that you will incorporate into the broader project? I'm not sure. There are a couple of issues. First is that you have to allocate an extra 80 bits at the beginning of the array so R can use it, and that might be sufficiently inconvenient that nobody would want to use it. Second, it currently only works for vectors. I've checked the R source code and creating a new matrix or array always allocates a new vector for storage, then copies existing data into it. Data frames would be fine (they're lists holding vectors of the same length) but the matrix and array types are also important. That means I'd have to add my own matrix and array allocation functions that use custom allocators for this to be practical. Here's the function that allocates a matrix: https://github.com/wch/r-source/blob/713cbe56df52e75f7711e176749c1458e0b2bb05/src/main/array.c#L212 A matrix/array is just a wrapper around a vector plus metadata to interpret the elements. The full code that allocates the data in a matrix is `PROTECT(s = allocVector(mode, n));`. In principle, I can just change that to `PROTECT(s = allocVector3(mode, n, ));`. If it's that simple, then yes, I'll do more with this.
Re: DasBetterR
On Friday, 7 July 2023 at 21:54:12 UTC, jmh530 wrote: Cool. The main thing I want to try is rstan. They have an interface called cmdstan that you can call from the command line that would be possible to use with D. The problem is that you have to write the data to a CSV file and then read it. So it would be kind of slow and I never got around to playing around with it in D. With your tool as it is, I would just have to copy the data in memory, which I would expect not to be as bad of an overhead as IO (but again haven't gotten around to do anything with it). I just pushed an update with a minimal example of how to call RStan with the following workflow: - Allocate a double[] in D and fill it with data. - Use a custom allocator to pass a pointer to the double[] to R. - Call RStan functions using the data. - Pull the results into D. Note that: - This is the first I've used RStan. My previous (limited) usage of Stan was at the command line. In practice, you'd want to create a better interface, so that it feels like D rather than passing strings of code around. I'm not familiar enough with RStan to do that. - The custom allocator requires leaving 80 bits immediately preceding the data free for R to store its metadata related to the vector. There's no way around that as R would not know what to do without the metadata. https://github.com/bachmeil/betterr/blob/main/testing/teststan.d
Re: DasBetterR
On Friday, 30 June 2023 at 16:14:48 UTC, jmh530 wrote: On Thursday, 29 June 2023 at 23:51:44 UTC, bachmeier wrote: [snip] Glad you're continuing to do work on this front. There's a lot of great material explaining things, which is always good. It would be cool to have another version of the link below for using a mir Slice with R. https://bachmeil.github.io/betterr/setvar.html I was wrong. They added custom allocators a while back, but didn't tell anyone. Actually, what I said before is technically correct. The SEXP struct itself still has to be allocated by R and managed by the R garbage collector. It's just that you can use a custom allocator to send a pointer to the data you've allocated, and once R is done with the data, it'll call the function you've provide to free the memory before destroying the SEXP struct that wraps it. I uploaded [an example here](https://github.com/bachmeil/betterr/blob/main/testing/testalloc.d). It's still a bit hackish because you need to adjust the pointer for a header R inserts when it allocates arrays. Adjusting by 10*double.sizeof works in this example, but "my test didn't segfault" doesn't exactly inspire confidence. Once I am comfortable with this solution, I'll do a new release of betterr. This'll be kind of a big deal if it works. For instance, if you want to use a database interface and D doesn't have one, you can use R's interface to that database without having R manage your project's memory. You could use any of the available R interfaces (databases, machine learning libraries, Qt, etc.)
Re: DasBetterR
On Friday, 30 June 2023 at 16:14:48 UTC, jmh530 wrote: On Thursday, 29 June 2023 at 23:51:44 UTC, bachmeier wrote: [snip] Glad you're continuing to do work on this front. There's a lot of great material explaining things, which is always good. It would be cool to have another version of the link below for using a mir Slice with R. https://bachmeil.github.io/betterr/setvar.html I assume you mean that you've allocated memory on the D side, like this: ``` auto a = new double[24]; a[] = 1.6; Slice!(double*, 1) s = a.sliced(); ``` and you want to pass s to R for further analysis. Unfortunately, that will not work. R functions only work with memory R has allocated. It has a single struct type, so there's no way to pass s in this example to R. The best you can do right now is something like this: ``` auto a = Vector(24); Slice!(double*,1) s = a.ptr[0..24].sliced(); // Manipulate s // Send a as an argument to R functions ``` In other words, you let R allocate a, and then you work with the underlying data array as a slice. A way around this limitation would be to implement the same struct (SEXPREC) in D, while avoiding issues with R's garbage collector. That's a more involved problem than I've been willing to take on. If someone has the interest, the SEXPREC struct is defined here: https://github.com/wch/r-source/blob/060f8b64a3a8e489d8684c18b269eea63f182e73/src/include/Defn.h#L184 and the internals are documented here: https://cran.r-project.org/doc/manuals/r-release/R-ints.html#SEXPs As much fun as it is to figure these things out, I have never had sufficient time or motivation to do so.
DasBetterR
I've been using D and R together for a decade. I wrote [a blog post for the D Blog](https://dlang.org/blog/2020/01/27/d-for-data-science-calling-r-from-d/) on the eve of the pandemic. I released the [embedrv2 library](https://github.com/bachmeil/embedrv2) in late 2021. It's useful for writing D functions that are called from R, using D's metaprogramming to write the necessary bindings for you. My programs usually take the opposite approach, where D is the primary language, and I call into R to fill in missing functionality. I've accumulated a large collection of code snippets to enable all kinds of things. The problem is that they were scattered across many projects, there was no consistency across programs, documentation didn't exist, and they were more or less useless to anyone other than me. [This Github repo](https://github.com/bachmeil/betterr) includes D modules, tests demonstrating most of the functionality, documentation, and some posts about how I do specific things. I'm sharing publicly all the things I've been doing in case it has value to anyone else. Examples of functionality: - Creating, accessing, and mutating R data structures, including vector, matrix, data frame, list, array, and time series types. Reference counting handles memory management. - Basic statistical functionality like calculating the mean. Many of these functions use Mir for efficiency. - Linear algebra - Random number generation and sampling - Parallel random number generation - Numerical optimization: direct access to the C libraries used by R's optim function - Quadratic programming - Passing D functions to R without creating a shared library. For example, you can use a D function as the objective function you pass to constrOptim for constrained optimization problems. [Project website](https://bachmeil.github.io/betterr/) There's more detail on the website, but I used the name "Better R" because the entirety of R is available inside your D program and you can use D to improve on it as much as you'd like. Feel free to hate the name. I was originally going to include all of this as part of embedrv2, but realized there was almost no overlap between the two use cases. Moreover, it would be strange to call R from D and call D functions from R in the same program. It simplifies things to keep them in different projects. If you try it and have problems, you can [create a discussion](https://github.com/bachmeil/betterr/discussions). You can also post in this forum, but I won't guarantee I'll see it.
Re: D Language Foundation April 2023 Monthly Meeting Summary
On Monday, 15 May 2023 at 18:15:54 UTC, jmh530 wrote: On Monday, 15 May 2023 at 18:02:49 UTC, ryuukk_ wrote: [snip] It can be frustrating when you are are neck deep in some complicated problem to explain to people who haven't spent the same amount of time with it as you have. That poster turns conversation after conversation into the same toxic cesspool. If human interaction is that frustrating, they should refrain from posting.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Monday, 1 May 2023 at 00:34:03 UTC, ryuukk_ wrote: I don't think it's a misconception. It's more like a complete lack of clarity. the goal is not to use an anonymous enum, the goal is to leverage the robust type system to avoid repeting yourself, wich is bad ``` Value value; value.type = ValueType.STRING; ``` vs ``` Value value; value.type = .STRING; ``` This is another case of the "complete lack of clarity" I wrote about in my earlier comment. With an anonymous enum you could write ``` value.type = STRING; ``` Maybe you have something deeper in mind, but that example does not make a case for changing the language. Rather than shouting, you should put together a better example. I will let this conversation die. I don't think it's going to resolve anything (and I'm not the one that needs convincing anyway).
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 27 April 2023 at 06:10:57 UTC, Basile B. wrote:
It's a misconception of the problem that the DIP tried to
solve. What the DIP tried to solve is that the compiler should
know that you are using an enum member. Actually I even think
this should work without any special syntax, as a "last
resort", let's say. But as you've explained, through Mike's
report, this causes problems for D because the identifier
resolution is tied to a particular implementation, i.e your
fast symtabs.
I don't think it's a misconception. It's more like a complete
lack of clarity. What would be the point of complexifying the
language for the new programmer when you can just use an
anonymous enum? This program runs just fine:
```
import std.stdio;
enum {
A1,
B1,
C1,
D1
}
enum {
_A,
_B,
_C,
_D
}
void main() {
writeln(A1);
writeln(_A);
writeln(A1 == _A);
auto flag = _B;
switch(flag) {
case _A:
writeln("_A");
break;
case _B:
writeln("_B");
break;
case _C:
writeln("_C");
break;
case _D:
writeln("_D");
break;
default:
break;
}
}
```
What's the point in using a named enum if you want an anonymous
enum? The response when this question was asked was not "because
[something where it matters]". It was instead to ignore the
question, give an unrealistic example that was solved by the
response, and insert a bunch of unhelpful hostility.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 27 April 2023 at 06:10:57 UTC, Basile B. wrote:
On Thursday, 27 April 2023 at 00:16:10 UTC, Walter Bright wrote:
This also works:
alias F = MySuperLongNameFlag;
auto flag = F.A | F.B | F.C | F.D;
set_flags(F.A | F.B | F.C | F.D);
It's similar to setting a local variable to some complex
expression, just so you don't have to repeat that expression
multiple times.
It's a misconception of the problem that the DIP tried to
solve. What the DIP tried to solve is that the compiler should
know that you are using an enum member. Actually I even think
this should work without any special syntax, as a "last
resort", let's say. But as you've explained, through Mike's
report, this causes problems for D because the identifier
resolution is tied to a particular implementation, i.e your
fast symtabs.
I don't think it's a misconception. It's more like a complete
lack of clarity. What would be the point of complexifying the
language for the new programmer when you can just use an
anonymous enum? This program runs just fine:
```
import std.stdio;
enum {
A1,
B1,
C1,
D1
}
enum {
_A,
_B,
_C,
_D
}
void main() {
writeln(A1);
writeln(_A);
writeln(A1 == _A);
auto flag = _B;
switch(flag) {
case _A:
writeln("_A");
break;
case _B:
writeln("_B");
break;
case _C:
writeln("_C");
break;
case _D:
writeln("_D");
break;
default:
break;
}
}
```
What's the point in using a named enum if you want an anonymous
enum? The response when this question was asked was not "because
[something where it matters]". It was instead to ignore the
question, give an unrealistic example that was solved by the
response, and insert a bunch of unhelpful hostility.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 15:07:36 UTC, ryuukk_ wrote: Again, all of this was covered and argumented during the DIP discussion The goal is to improve the language, not find excuses or workarounds, don't defend obfuscation, move forward Your proposals were built on unrealistic examples and false dichotomies. If the only choice is 48-character informative names or two-character uninformative names, the problem is not the language.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 13:08:22 UTC, Jacob Shtokolov wrote: On Wednesday, 26 April 2023 at 12:50:32 UTC, bachmeier wrote: Many other solutions were provided as well, including but not limited to - Using shorter names - Using alias - Using an IDE with autocomplete - Using copy and paste While aliases and shorter names are always good options, autocomplete and copy/paste really aren't as the end user of the code is either yourself or another developer, so reading the mess produced with copy/paste makes life much more miserable :) Unless you're using incredibly long names (which is not a reason to change the language) I find the explicit approach to be more readable. If I have to parse the code and do inference, it's a lot more work, and in some cases, more error-prone. We've had proposals to drop the semicolon requirement. I would hate that. It's easier to read code when I don't have to figure out where the lines end. I wish the `with()` operator would also be an expression, so you could do something like: ```d auto f = with(Flags) A | B | C |D; ``` This would be great, but it goes against the spirit of this DIP, since you have to explicitly type out `with(Flags)`.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: I submitted DIP1044, "Enum Type Inference", to Walter and Atila on April 1. I received the final decision from them on April 18. They have decided not to accept this proposal. This was the right decision, but it would have been nice to include as one of the reasons that it would have made it harder for new users.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 11:52:31 UTC, Jacob Shtokolov
wrote:
On Tuesday, 25 April 2023 at 20:15:39 UTC, ryuukk_ wrote:
void set_connected()
{
network_connect_state = NetworkConnectState.CONNECTED
}
MySuperLongNameFlag flag = MySuperLongNameFlag.A |
MySuperLongNameFlag.B | MySuperLongNameFlag.C |
MySuperLongNameFlag.D;
set_flags(MySuperLongNameFlag.A | MySuperLongNameFlag.B |
MySuperLongNameFlag.C | MySuperLongNameFlag.D)
Okay, I understand this is sometimes really annoying, but in
this example, why can't you just:
Many other solutions were provided as well, including but not
limited to
- Using shorter names
- Using alias
- Using an IDE with autocomplete
- Using copy and paste
Re: D Language Foundation March 2023 Monthly Meeting Summary
On Tuesday, 11 April 2023 at 21:53:50 UTC, Mike Parker wrote: ImportC was slowly grinding along. His priority was getting all the standard header files to compile on all the platforms. A lot of the system `.h` files on the various platforms have made a feeble attempt to be usable by different compilers but fail miserably, and each one fails in its unique fashion. They'd be easy to fix if he could edit those files, but of course, he can't. Can't the changes to those files by stored in the compiler? Walter obviously can't change the raw header files, but he can make changes to the files before they're used by the compiler. If that's not possible, can't a modified set of header files be available for download, and if you want to use a system .h file, you have to use the modified version instead?
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 15:39:35 UTC, Dom Disc wrote: On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote: On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote: Razvan [submitted a PR deprecating `alias this` in classes](https://github.com/dlang/dmd/pull/14812) the next day. Amaury [initiated a forum discussion](https://forum.dlang.org/thread/roaaoujwgkzednetb...@forum.dlang.org) a few days later. Is there a replacement? Yes. And there always was: In classes this was only an additional way to do, what should better be done with inheritance. That is not my understanding from the linked thread. For instance, someone said it can be used as a substitute for multiple inheritance. It seems that anyone using it that way would be losing working code for no reason due to this deprecation.
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote: Razvan [submitted a PR deprecating `alias this` in classes](https://github.com/dlang/dmd/pull/14812) the next day. Amaury [initiated a forum discussion](https://forum.dlang.org/thread/roaaoujwgkzednetb...@forum.dlang.org) a few days later. Is there a replacement? If not, why is this even being discussed? I'm all for breaking changes if there's a benefit and an easy path to maintain the existing functionality. This fails on both counts. If you want to enforce that it's not used, add a flag, but don't take it away just for the sake of taking it away. Martin suggested a fourth option: phase out `-betterC` because it's a "pile of hacks". Dennis considered that but thought BetterC users would not be happy when it gets deprecated without a suitable replacement. If you don't like BetterC, don't use BetterC. It *already* requires a flag. More generally, deprecation decisions like this shouldn't be made by a small group of people that write a tiny percentage of the D code running in the real world. That same process gave us a safe by default proposal that would have made it impossible to interoperate with C code.
Re: WildCAD - a simple 2D drawing application
On Monday, 30 January 2023 at 20:51:59 UTC, Richard (Rikki) Andrew Cattermole wrote: It isn't. WebFreak has an on-going project to replace it. https://forum.dlang.org/post/ojoiwbcftqsxbsviv...@forum.dlang.org https://docs.webfreak.org/ That's quite an improvement. Perhaps it should be announced again, because I don't remember seeing the original post.
Re: WildCAD - a simple 2D drawing application
On Monday, 30 January 2023 at 04:40:48 UTC, Siarhei Siamashka wrote: On Monday, 30 January 2023 at 02:44:50 UTC, bachmeier wrote: if you put your code in directories that match the modules you want to import, there's no need for Dub and the corresponding poorly documented configuration. What is poorly documented? Can you suggest some documentation improvements? That ship has sailed. I've given up on Dub because those who promote it aren't interested in criticism. I'll just link to [this page](https://dub.pm/package-format-json) and if anyone thinks that's acceptable documentation for someone new to the language, there's no point having a conversation about it.
Re: WildCAD - a simple 2D drawing application
On Sunday, 29 January 2023 at 15:01:40 UTC, Adam D Ruppe wrote: dub fights D compilers. This is why it forces me to write 600 lines of ugly configuration file for something that just works in dmd. I don't want to get sucked into another discussion of the pros and cons of Dub, but yeah, if you put your code in directories that match the modules you want to import, there's no need for Dub and the corresponding poorly documented configuration.
Re: text based file formats
On Sunday, 18 December 2022 at 15:56:38 UTC, Robert Schadek wrote: I complaint before that D and phobos needs more stuff. But I can't do it all by myself, but I can ask for help. So here it goes https://github.com/burner/textbasedfileformats As on the tin, text based file formats is a library of SAX and DOM parsers for text based file formats. I would like to get the following file formats in. * json (JSON5) there is actually some code in there already * xml, there is some code already, the old std.experimental.xml code * yaml, maybe there is something in code.dlang.org to be reused * toml, maybe there is something in code.dlang.org to be reused * ini, can likely be parsed by the toml parser * sdl, I know I know, but D uses it. A natural complement to this would be the functionality in https://github.com/eBay/tsv-utils I've created versions of the filter and select functions that take a string as input and return a string or string[] as output. It's a performant way to query text files. Most important, all the hard work is already done.
Re: Walter's Edited DConf Talk Video -- Feedback Request
On Wednesday, 7 September 2022 at 12:42:35 UTC, Mike Parker wrote: If you haven't seen Walter's talk yet (or would like to watch it again), please give it a look and let me know if you uncover any major problems: https://youtu.be/iuP-AWUyjp8 Thanks! Looks like high quality work. I jumped over a few topics but I saw nothing that needs to change.
Re: GCC 12.2 Released (D v2.100.1)
On Friday, 19 August 2022 at 11:36:09 UTC, Iain Buclaw wrote: - Updated the D front-end from v2.100.0-rc1 to v2.100.1. GDC is now ahead of DMD?
Re: importC | Using D with Raylib directly | No bindings | [video]
On Monday, 8 August 2022 at 13:01:46 UTC, Petar Kirov [ZombineDev] wrote: I think this was recently documented here: https://dlang.org/spec/importc.html#preprocessor Give it a read, try it out and let us know how it works out! Happy to see that. I'll be giving it a test.
Re: Giving up
On Friday, 5 August 2022 at 18:29:46 UTC, mw wrote: On Friday, 5 August 2022 at 17:56:47 UTC, bachmeier wrote: Here's the code if anyone is relying on it: https://github.com/bachmeil/decimal/tree/main I really think DUB should save a copy of all the files of all the registered packages: https://code.dlang.org/packages/decimal to prevent such disaster in the future. @bachmeier, you want create a new DUB entry? I'm not familiar with that process. Anyone else that has the necessary knowledge should feel free to do so.
Re: Giving up
On Friday, 5 August 2022 at 17:46:59 UTC, bachmeier wrote: The D source files should be saved as part of the documentation. I checked and this is the case for the five modules. (Never used it, so no idea what to do with them, but they're there if someone else wants them.) Here's the code if anyone is relying on it: https://github.com/bachmeil/decimal/tree/main Same license as the original.
Re: Giving up
On Friday, 5 August 2022 at 16:51:44 UTC, Steven Schveighoffer wrote: On 8/5/22 12:48 PM, Rumbu wrote: On Friday, 5 August 2022 at 16:37:56 UTC, Steven Schveighoffer wrote: I don't think that code ever built. Possibly you didn't test it properly originally. But if you are done with it, I guess it doesn't matter. Thank you for this. Deleted since everything is fake there and never worked. I meant the intel.d file, not the whole thing! Hopefully you change your mind, as removing projects can affect anyone who is depending on it. At least let someone take it over! -Steve The D source files should be saved as part of the documentation. I checked and this is the case for the five modules. (Never used it, so no idea what to do with them, but they're there if someone else wants them.)
Re: Blog post on extending attribute inference to more functions
On Wednesday, 13 July 2022 at 20:59:00 UTC, Adam D Ruppe wrote: I very rarely announce them here since I don't want to spam too much. So while you might only hear from me here a couple times a year, I am probably actually writing something on the website once or twice a month. It would be nice if you'd spam our subreddit. There have been eight posts in the last month.
Re: D Community Conversations: Walter Bright on the Origins of D Part 1
On Monday, 11 July 2022 at 13:51:27 UTC, Salih Dincer wrote: On Sunday, 10 July 2022 at 18:26:13 UTC, bachmeier wrote: On Sunday, 10 July 2022 at 16:17:11 UTC, Mike Parker wrote: [...] This is really good. Have you considered uploading the audio to Spotify or somewhere as a podcast? No idea what that would involve, but for a lot of us there are more opportunities to listen to a podcast rather than watch a YT video. I mostly use this site: https://mp3y.download/en The intro music and the beginning of the video were great. SDB@79 I've used those tools before, but it's not the same as following a podcast on Podbean, and you're not going to get into anyone's search on the podcast services.
Re: D Community Conversations: Walter Bright on the Origins of D Part 1
On Monday, 11 July 2022 at 15:53:40 UTC, jmh530 wrote: Many podcasts edit for the uhs and ahhs. Nothing wrong with that. One reason is that the editing can be done automatically by services like Descript. I don't know if Mike does it manually.
Re: D Community Conversations: Walter Bright on the Origins of D Part 1
On Sunday, 10 July 2022 at 16:17:11 UTC, Mike Parker wrote: [...] This is really good. Have you considered uploading the audio to Spotify or somewhere as a podcast? No idea what that would involve, but for a lot of us there are more opportunities to listen to a podcast rather than watch a YT video.
Re: All Community Discord channels are now being bridged to Matrix
On Sunday, 16 January 2022 at 01:02:22 UTC, Ali Çehreli wrote: On 1/15/22 16:53, Paul Backus wrote: there is a Matrix client for emacs: I am not surprised at all. :) Matrix sounds very promising: https://matrix.org/ Ali Now all we need is a Matrix client written in D.
Re: Why I Like D
On Wednesday, 12 January 2022 at 16:52:02 UTC, Arjan wrote: I wonder if there is just so much fear of the GC vs people who actually tried to use the GC and it failed to suit their needs. I've never been afraid of the GC in my projects, and it hasn't hurt me at all. I think it stems from experience from long ago when JAVA was HOT and sold as the solution of all world problems, but failed to meet expectations and was dismissed because they found is was the GC what made it fail.. A lot of engineers just repeat the opinion of some guru they admire without fact checking. Although I've seen various serious performance issues with JAVA and python software, only once it was related to the GC.. I don't think they're necessarily wrong. If you don't want to deal with GC pauses, it may well be easier to use an approach that doesn't have them, in spite of what you have to give up. On the other hand, many of them have no idea what they're talking about. Like claims that a GC gets in your way if the language has one.
Re: D Language Foundation Monthly Meeting, December 2021
On Monday, 27 December 2021 at 06:40:30 UTC, Mike Parker wrote: This meeting was originally supposed to take place on the fourth Friday in November, but given that the day before that was Thanksgiving Day in America (and is so every November), we moved it to the first Friday in December. Then given that the fourth Friday in December this year was Christmas Eve, we agreed to just stick with the first Friday each month going forward. Most of us are busy with holiday stuff in late December anyway even when the fourth Friday isn't Christmas Eve. [...] Iain used this opportunity to bring attention to a header file he maintains to resolve some such issues. Walter suggested that this, or something like it, should be a part of the D compiler release. This prompted a discussion about how to do that and the pros and cons of dmd invoking the C preprocessor vs. incorporating Warp. Walter suggested it's just about time for dmd to start invoking the C preprocessor. This would be a big step forward. I've been testing various libraries with ImportC in an attempt to identify bugs, limitations, and workarounds. I've gotten a lot of mileage from Iain's file, in the sense that it was sufficient to get most of those files to compile. What it can't solve is duplicate function definitions across preprocessed files. That's where a compiler solution would be valuable. I assume their solution will address this.
Re: DConf Online 2021 Links
On Monday, 22 November 2021 at 03:14:34 UTC, forkit wrote: On Friday, 19 November 2021 at 10:10:11 UTC, Mike Parker wrote: See you there! Well, you won't see me there, as I'd have to get up too early in the morning. But have really enjoyed watching the broadcasts on youtube. btw. Andrei Alexandrescu... no show??... is he still part of the D Foundation or involved in D in any way, anymore? He is currently working on versioning Phobos. IMO that's the most important thing for D right now, so he's definitely still contributing. I'm sure he'd have presented something if he thought it was worth his time to do so. I'd rather he not get distracted and spend his time on versioning Phobos.
Re: On the Blog: DLang News for September/October 2021
On Monday, 1 November 2021 at 04:08:00 UTC, Mike Parker wrote: I think the YouTube channel is a better vector to spread the Good Word about D than the blog, and I really want to make more use of it. The blog is good for explaining technical material, and has a lot of value because of Google, but I agree YouTube is better for evangelizing. Time is always the downer, though. So I'll be begging for contributed content (like I used to beg for guest posts on the blog) after DConf Online. One suggestion I have is that the format of PLTalk by Jean Yang might be a good fit when you want to get others involved. If you're not familiar with it, she has a Zoom chat with someone, that person demos whatever they're talking about, and she asks clarifying questions. She records the talk and uploads it to YouTube. Here's an example that would work well for short demos of changes to the language/new libraries/whatever: https://www.youtube.com/watch?v=kylAbEPcadw=712s You might have other plans, but it's one way to reduce the cost for yourself and for others.
Re: On the Blog: DLang News for September/October 2021
On Sunday, 31 October 2021 at 19:26:24 UTC, Mike Parker wrote: On Friday, 29 October 2021 at 15:03:46 UTC, Mike Parker wrote: I'll be putting together a video version this weekend for the foundation's YouTube channel that I should be able to publish by Sunday. The video version is done and is available here: https://youtu.be/jX9grHMTGAU I really want this to be a regular thing every two months, for both a news blog post and video. My request from you: share, share, share! Good video. Makes the language feel exciting.
Re: D Language Foundation Monthly Meeting Summary
On Thursday, 3 June 2021 at 23:48:16 UTC, zjh wrote: D does not owns the advantages of GC , but all the disadvantages of GC .Why not discard it? This is not a realistic or helpful suggestion. You're proposing to get rid of current users of the language - many of whom like that there's a GC - in order to chase C++ programmers, who represent a small sliver of all programmers, who mostly wouldn't change languages anyway, and who would change to Rust if they were planning to change languages. Again, not a helpful suggestion.
Re: Our community seems to have grown, so many people are joining the Facebook group
On Monday, 28 December 2020 at 17:31:21 UTC, Murilo wrote: I'm very happy, at first the people here did not like my idea, they thought a Facebook group was unnecessary, but what is the biggest social media in the world? Facebook! So that's is the best way to communicate with the world and advertise Dlang. I'm happy to hear your group is growing. I do have to disagree with your last sentence. Any information you post on Facebook is posted into a black hole. It can be an effective way to make announcements if you have a really big group of followers (or friends or whatever they call them these days), but it's definitely not a good idea for information you want archived for the long run.
Re: New language based on D
On Thursday, 12 November 2020 at 15:28:44 UTC, Faux Amis wrote: Maybe these type of subset languages could be integrated in the D frontpage. I hope not. That would create lots of problems: - There are multiple versions of the language. - What happens when a version dies? What do you tell the developers (perhaps even businesses) that relied on a version they downloaded from the official homepage that now have a dead version? - What if a developer makes weird changes (like removing int, which would still be a subset) or goes Windows-only because of the burden maintaining for multiple OSes? Is that something that should be promoted on the official homepage? These are just the problems that immediately come to mind. I'm sure there are others. Open source is wonderful because it lets things like this happen. That doesn't mean we want to promote them on dlang.org.
Re: LDC 1.24.0-beta1
On Friday, 23 October 2020 at 20:21:39 UTC, aberba wrote: Beginners, if you want an LDC installer then "Go do it yourself". I wouldn't consider that a good message. Out of curiosity, what is the alternative message? Someone has to do it. This is a volunteer project, not a business, so there's not a manager that can put a couple guys on it.
Re: DConf Online 2020 Submission Deadline Extended
On Saturday, 5 September 2020 at 09:50:44 UTC, FeepingCreature wrote: On Saturday, 5 September 2020 at 04:01:43 UTC, Mike Parker wrote: On Monday, 31 August 2020 at 08:36:09 UTC, Mike Parker wrote: I've received exactly one submission for DConf Online. Two keynotes + one talk does not make a conference. So this is the last call. The deadline has been extended to Sunday, September 6 AOE. This makes or breaks the conference. If we don't have enough talks submitted, it ain't happening. I've gotten one more submission. We'll need more than that. Let's go, folks! hi okay, if I'm literally the only one that's kind of problematic, yeah. Let's see how it goes on Sunday. I'd guess that ... like, either ultimately a structured online conference just isn't something people are interested in or think is useful, or the effort of recording videos poses too much of a roadblock. You wouldn't think that flying to London would be more effort than making a video, but it wouldn't surprise me. Or right now maybe people are keeping their ideas for the next in-person DConf, so if Corona keeps up we'd see more talks next year. You know what, let's ask. Anyone here who considered submitting but didn't, would you share why not? I might have done so, but the pandemic has increased my workload so much that my major decisions now involve deciding which parts of my job I can't do. Adding something else to the todo list is a pre-pandemic concept. That said, I will be recording videos that involve the use of D, it's just that they'll be very specialized applications for my grad students rather than some of interest to a general audience.
Re: Symmetry Investments and the D Language Foundation are Hiring
On Sunday, 30 August 2020 at 14:13:36 UTC, Mike Parker wrote: Looking for a full-time or part-time gig? Not only is Symmetry Investments hiring D programmers, they are also generously funding two positions for ecosystem work under the D Language Foundation. And they've put up a bounty for a new DUB feature. Read all about it here: https://dlang.org/blog/2020/08/30/symmetry-investments-and-the-d-language-foundation-are-hiring/ Thanks to Symmetry and the Foundation for this. This is a big deal. I hope there will be announcements posted and promoted after the hires are made. From a marketing perspective, it is initiatives like this that give others the confidence to invest in the language.
Re: tsv-utils 2.0 release: Named field support
On Tuesday, 28 July 2020 at 00:16:05 UTC, Jon Degenhardt wrote: On Monday, 27 July 2020 at 14:32:27 UTC, aberba wrote: On Sunday, 26 July 2020 at 20:28:56 UTC, Jon Degenhardt wrote: I'm happy to announce a new major release of eBay's TSV Utilities. The 2.0 release supports named field selection in all of the tools, a significant usability enhancement. So I didn't checked it out until today and I'm really impressed about the documentation, presentation and just about everything. Thanks for the kind words, and for taking the time to check out the toolkit. Both are very much appreciated! Thanks for your work. I've recommended tsv-utils to some students for their data analysis. It's a nice substitute for a database depending on what you're doing. It really helps that you store can store your "database" in repo like any other text file. I'm going to be checking out the new version soon.
Re: Dlang: The Complete D programming Language Course
On Thursday, 23 July 2020 at 01:13:25 UTC, aberba wrote: Found this introductory course from Udemy on D Complete introduction to programming in D. Learn by doing assignments and projects. https://www.udemy.com/course/d-programming-language/ Not to rain on anyone's parade, but it's listed under C++, the title of the course says "Next C++", and the instructor does not claim expertise in the D language: https://subscription.packtpub.com/video/programming/9781789538007 https://www.linkedin.com/public-profile/in/nikoloz-sanakoevi?challengeId=AQH4LdTZ-N0KgXN8Q9mDXBLU_DgsLf6-gj9pQL1VAMQ_mcIuTIDOiF3ndVwQxwKdkmfxUk1pLff8RjW1NmDClFziAuowcA=0aa86833-e26a-2416-76ce-587eccdd834a
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 14:38:09 UTC, Timon Gehr wrote: On 22.05.20 15:58, bachmeier wrote: ... Honest question: What is the use case for an absolutely-positively-has-to-be-safe program that calls C code? Why would anyone ever do that? C is not and will never be a safe language. "Someone looked at that blob of horrendous C code and thinks it's safe" does not inspire confidence. Why not rewrite the code in D (or Rust or Haskell or whatever) if safety is that critical? Honesty is what's critical. The annotations should mean what they are advertised to mean and making those meanings as simple as possible makes them easier to explain. As things stand, @safe can mean that someone accidentally or historically did not annotate an extern(C) prototype and an unsafe API a few calls up was ultimately exposed with the @safe attribute because the compiler never complained. In my opinion, the only advantage of @safe is that the compiler has checked the code and determines that it only does things considered safe. I don't see that marking an extern(C) function @trusted buys you anything, at least not until you can provide a compiler guarantee for arbitrary C code.
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 14:13:20 UTC, Paul Backus wrote: On Friday, 22 May 2020 at 13:58:14 UTC, bachmeier wrote: On Friday, 22 May 2020 at 03:36:03 UTC, Paul Backus wrote: This is the nightmare scenario that people are worried about: safety violations being introduced *silently* into existing, correct D code. Honest question: What is the use case for an absolutely-positively-has-to-be-safe program that calls C code? Why would anyone ever do that? C is not and will never be a safe language. "Someone looked at that blob of horrendous C code and thinks it's safe" does not inspire confidence. Why not rewrite the code in D (or Rust or Haskell or whatever) if safety is that critical? The problem isn't that safety is critical, it's that the D compiler is lying to me about the safety of my code. If the compiler was honest and told me that my code was unsafe, I'd be able to make an informed decision to either (a) accept the lack of safety, or (b) do the additional work needed to make it safe. As-is, DIP 1028 takes that choice away from me, and I am forced to accept a lack of safety whether I want to or not. At that point, why not use C? If you're compiling a program that calls into C, you know that's what you're doing, so you know you've given up any guarantees of safety. Back in the early days of Rust, someone made a comment along the lines of Rust being a language to rewrite C code in, not to use to call C code. D has, to this point, been a language designed to interoperate easily with C code. I personally don't care about safety guarantees at all. It's not obvious to me that guaranteed safety at all costs is the way to go - especially considering the degree to which that breaks from current behavior.
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 13:57:27 UTC, Mike Parker wrote: On Friday, 22 May 2020 at 12:47:04 UTC, matheus wrote: As an end user, I'd like to know if this language will be guided by community or one person, because it seems the "democracy" is very shallow right now. And again why waste time with this process plus 2 rounds of discussion? I mean just do it and tell in this announcement section about the feature. The DIP review process is not intended for community approval or rejection of DIPs. It's not a democratic voting process. It's intended to elicit community feedback to enhance the DIP under review (the Feedback Threead) and to allow the airing of opinions (the Discussion Thread). All DIP authors have the freedom to incorporate suggestions into their DIP or not, and Walter and Atila make the decision to accept or reject. If you look at the history of Walter's DIPs, they *do* take the opinions into consideration even when he is the author. Several of his previous DIPs have been withdrawn or rejected. If a popular DIP is rejected, it means neither of them were convinced by opinion to accept it. And, as in the case for this DIP, if an unpopular DIP is accepted, it means they were not persuaded by the arguments against it. From my perspective, the process is working as intended, despite the comments to the contrary in this thread. You either convince a DIP author to modify his DIP, or you don't. You either persuade Walter and Atila to accept or reject it, or you don't. I think the source of the problem is that Walter's DIPs require the community to prove that Walter's proposal is so bad that he needs to reject it. Anyone else's proposal has to prove that it's worthy of being added to the language. There's a big perceived gap between those two. As I've said many times, it's odd for someone to judge his own DIPs, and as someone that is an academic administrator and runs a high-profile journal, I can say this type of practice is not the norm in those areas because it doesn't lead to good decisions.
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 03:36:03 UTC, Paul Backus wrote:
Someone has created bindings for a C library and published them
on
code.dlang.org. Because they were written prior to DIP 1028,
the author assumed
that @system was the default, and didn't bother to add explicit
annotations to
@system functions. Their code looks like this:
--- clibrary.d
void monkey_around(...); // assumed @system-by-default
---
Months or years later, I decide to write a D program that makes
use of these
bindings. By then, @safe-by-default has been fully implemented.
I add
`clibrary` as a dependency to my Dub project and write the
following code:
--- app.d
import clibrary;
void main() // @safe-by-default
{
/* ... code ... */
monkey_around(...);
/* ... more code ... */
}
---
My program compiles with no errors...and then corrupts memory
at run-time, even
though every line of code I've written is @safe. Oops.
This is the nightmare scenario that people are worried about:
safety violations
being introduced *silently* into existing, correct D code.
Honest question: What is the use case for an
absolutely-positively-has-to-be-safe program that calls C code?
Why would anyone ever do that? C is not and will never be a safe
language. "Someone looked at that blob of horrendous C code and
thinks it's safe" does not inspire confidence. Why not rewrite
the code in D (or Rust or Haskell or whatever) if safety is that
critical?
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 20:48:18 UTC, Walter Bright wrote: On 5/21/2020 10:03 AM, bachmeier wrote: Walter makes decisions based on his mood on a particular day That's uncalled for. Regional variation in English? Translation: You make your decisions based on how you feel about the situation at a point in time. "Mood" is used because there's some subjectivity and "gut feel" involved in the decision. It's not intended to be negative, it's simply a description of how any human makes any decision. That's why I said the same about how a committee would make decisions.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 17:49:27 UTC, Paul Backus wrote: On Thursday, 21 May 2020 at 17:03:49 UTC, bachmeier wrote: The problem as I see it is someone making a decision on his own DIP. That just doesn't make any sense to me, and I've stated that numerous times. Walter has a tendency to throw gas on the fire by ignoring much of the feedback and not spending time to understand the points others are making when he does respond. I really think you should have to convince *someone else* that your proposal is reasonable. In principle, at least, this is why we have two "language maintainers," Walter and Atila (previously, Walter and Andrei). There's a big difference between being part of a three-person committee discussing a proposal by Walter and working together with Walter to make a decision on his own proposal. It's certainly doesn't pass the smell test.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote: On Thursday, 21 May 2020 at 13:51:34 UTC, Mike Parker wrote: DIP 1028, "Make @safe the Default", has been accepted without comment. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1028.md "without comment" - even though there were a lot of unaddressed problems :/ Great! So what's the entire point of this process? To give people the illusion of progress and participation? Why we can't we have a technical board where the community can vote in experts and potentially companies could even buy a seat for $$$ which would mean a lot more for them than the current very vague sponsorship options. I'm aware that Walter doesn't like the idea of giving up ownership, but it makes all the other people question why they should still bother with this process and not simply fork and move to an open, transparent development... I honestly don't know if that would help. We'd be moving from a system where Walter makes decisions based on his mood on a particular day to one where others make decisions based on their moods on a particular day. The only thing worse than letting one person choose what to implement is having a group of people choose what to implement. Everyone has their own view of what is important. In my case, it's beginners and appealing to less technical users. Others view 20-year C++ programmers that specialize in performance optimizations as the only ones that matter. Needless to say, there's not a lot of overlap in the set of changes we think make sense. No matter who is making the decisions, the tradeoff between ease of use and technical awesomeness will continue to exist. The problem as I see it is someone making a decision on his own DIP. That just doesn't make any sense to me, and I've stated that numerous times. Walter has a tendency to throw gas on the fire by ignoring much of the feedback and not spending time to understand the points others are making when he does respond. I really think you should have to convince *someone else* that your proposal is reasonable.
Re: DConf 2020 Canceled
On Monday, 16 March 2020 at 13:59:44 UTC, SashaGreat wrote: On Monday, 16 March 2020 at 13:36:02 UTC, bachmeier wrote: On Monday, 16 March 2020 at 11:43:58 UTC, SashaGreat wrote: First I totally agree with Online Conference, but on the other hand I don't think this will fly in this community, because for what I see unfortunately Walter is trapped in the past and for him it's: in-person meeting or NOTHING. Walter's opinion is irrelevant to anything beyond his own participation. Anybody can organize an online conference without Walter. Of course, but I really think that if the heads of organization shown some appreciations and their incentives would help this idea to fly. "Have an online conference" isn't especially helpful. There haven't been any detailed proposals, and Walter hasn't said anything one way or the other about doing something online.
Re: DConf 2020 Canceled
On Monday, 16 March 2020 at 11:43:58 UTC, SashaGreat wrote: First I totally agree with Online Conference, but on the other hand I don't think this will fly in this community, because for what I see unfortunately Walter is trapped in the past and for him it's: in-person meeting or NOTHING. Walter's opinion is irrelevant to anything beyond his own participation. Anybody can organize an online conference without Walter. (Setting aside issues with your interpretation of what he wrote.)
Re: DConf 2020 Canceled
On Saturday, 7 March 2020 at 21:58:06 UTC, Adam D. Ruppe wrote: Let's do a little online thing instead! We could do a chat room, livestream, blog, you know stuff like that. I'd like to see this happen. Hopefully it would work out better than the recent Emacs conference. I tried to watch a few of the presentations, but it was mostly me sitting in front of my computer watching them work through technical issues.
Re: Blog post on calling C from Python via D
On Wednesday, 26 February 2020 at 14:51:06 UTC, Atila Neves wrote: On Wednesday, 19 February 2020 at 16:30:04 UTC, Atila Neves wrote: https://atilaoncode.blog/2020/02/19/want-to-call-c-from-python-use-d/ Discussion elsewhere: https://www.reddit.com/r/programming/comments/f6agvt/want_to_call_c_from_python_use_d/ https://news.ycombinator.com/item?id=22365166 A lot of the comments were about how stupid I was for not just using ctypes or cffi. I tried today and both of them are horrible. As I say in the blog post below, either they didn't read the article (people on the internet commenting on things they didn't even read? Shock! Horror!) or just aren't lazy enough. My followup: https://atilaoncode.blog/2020/02/26/seriously-just-use-d-to-call-c-from-python/ There needs to be a variant of "mansplaining" modified for Python users.
Re: DIP 1027---String Interpolation---Format Assessment
On Monday, 24 February 2020 at 08:43:57 UTC, Robert M. Münch wrote: I mean, people spend a lot of time thinking, making suggestions, etc. and the end result is: we now have nothing. Which, IMO is the worst result for all. We don't have nothing. There's an option value of not making a decision at this time. Once you decide to go forward with a string interpolation proposal, you're deciding not to go forward with any other similar proposal for many years, or even forever. This is IMO a minor feature (not a big deal if we don't have it). If you're going to do it, do it right. In some cases, there's really no way to know until you have a formal proposal and discuss the heck out of it whether it's worth going forward.
Re: The good old CGI
On Saturday, 15 February 2020 at 22:06:42 UTC, Tier wrote: P.S. I know you made an scgi client. Do you plan on making a fcgi one too? Check out Adam Ruppe's cgi.d: https://arsd-official.dpldocs.info/arsd.cgi.html
Re: FeedSpot Recognizes the GtkDcoding Blog
On Friday, 7 February 2020 at 15:05:13 UTC, Russel Winder wrote: True companies have convinced themselves that only licences that allow stealing of others' intellectual work are acceptable to business, but then that is the point, they can steal the intellectual work with impugnity. A rant of my own: The push against the GPL is mostly by those who want free software to mean "free labor". GPL software can be dual licensed. Companies can pay for an alternative licensing arrangement if it's that valuable to them. Instead they want "free" software that allows them to avoid payment while imposing restrictions on how others use the software.
Re: D For Data Science: Calling R from D
On Monday, 27 January 2020 at 14:20:20 UTC, Adam D. Ruppe wrote: On Monday, 27 January 2020 at 14:16:47 UTC, Mike Parker wrote: https://dlang.org/blog/2020/01/27/d-for-data-science-calling-r-from-d/ "D [...] interoperability with C (in many cases as simple as adding an #include directive to import a C header file), " like it is simple... but it isn't a #include directive unless you use third party things (that have their own issues). Minor thing but can be misleading to newcomers. Good catch. I intended to link to both dpp and dstep but I forgot to do it.
Re: D For Data Science: Calling R from D
On Monday, 27 January 2020 at 14:55:37 UTC, jmh530 wrote: On Monday, 27 January 2020 at 14:16:47 UTC, Mike Parker wrote: You've seen Lance Bachmeier posting in the forums under the bachmeier handle. He's put together a post for the D Blog showing how to integrate R into a D program. The Blog: https://dlang.org/blog/2020/01/27/d-for-data-science-calling-r-from-d/ Reddit: https://www.reddit.com/r/programming/comments/euobu1/d_for_data_science_calling_r_from_d/ It's also on Hacker News. If it isn't on the front page, just search for "D for Data Science". Please don't post a direct link if you find it on there, not until after it's been on there a few days. https://news.ycombinator.com/ Great piece. Glad to see it. One point that is confusing is below: "There are two ways to execute R code from a D program. evalR executes a string in R and prints the output to the screen, while evalRQ does the same thing but suppresses the output. evalRQ also accepts an array of strings that are executed sequentially." So evalR normally prints the output to the screen, but evalRQ does not unless you specify it with a print statement. However, in Example 4 later have an array of strings with a print statement at the end but it says that it won't print from it. So does Example 4 print or not? Maybe distinguish between suppress in D and print with R a little more clearly? In addition, the embedr documentation could probably be more clear on the difference between evalR and evalRQ using some of this text. Thanks for catching that. I must have messed that up during editing. This is incorrect: "evalR executes a string in R and prints the output to the screen". evalR executes a string in R and then returns the R output to D as an Robj struct. The comment on Example 4 is also wrong. I'll have to think about the best way to word things and ask Mike to make the change.
Re: My Android project nearing beta
On Wednesday, 1 January 2020 at 17:35:28 UTC, Adam D. Ruppe wrote: On Wednesday, 1 January 2020 at 17:12:01 UTC, bachmeier wrote: A question that comes to mind with respect to your JNI work: Is this specific to Android, or could we use it, for instance, as a way to call Java functions from R, where we use D as a bridge to simplify things? That should be possible. And the bindings generator and packing techniques should work on other things too. All I did here was run it on android.jar, but I see no reason why it wouldn't work on other jars too, perhaps with adjustments for like java.lang.X so it pulls them from another source if necessary. The jni thing is not specific to Android at all (which is also why I put it in my arsd repo instead of the d_android one). In fact, most my testing of it has been done outside android since it is so much more convenient. I have tested on 64 bit Windows and 64 bit Linux as well, it should work anywhere else D and the jvm both run. Excellent. I'll definitely be digging into this when I have time. R is very heavily used. Once users have D installed to facilitate calling into Java, there's no longer a good reason to not work with D itself.
Re: My Android project nearing beta
On Wednesday, 1 January 2020 at 16:48:40 UTC, Adam D. Ruppe wrote: Another big update here in my blog this week: http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_30.html A question that comes to mind with respect to your JNI work: Is this specific to Android, or could we use it, for instance, as a way to call Java functions from R, where we use D as a bridge to simplify things? If so, this could potentially lead to significant use of D, as there are a fair number of R packages that call into Java. It was a nightmare when I looked into it years ago. Making this even more appealing is GDC's inclusion in GCC.
Re: My Android project nearing beta
On Tuesday, 17 December 2019 at 20:47:24 UTC, Adam D. Ruppe wrote: On Tuesday, 17 December 2019 at 20:26:39 UTC, aberba wrote: This part is unclear to follow OK, I'll rewrite it with more examples later in the week. It is still a little bit of a pain to set up too so if I can fix that, the instructions will be simplified as well. Maybe Docker can help ease the burden for others to test it.
Re: My Android project nearing beta
On Tuesday, 17 December 2019 at 17:24:58 UTC, H. S. Teoh wrote: Especially check out arsd/jni.d, that can be used to almost-seamlessly interoperate D with Java. It's not 100% there yet, but it's pretty danged awesome. I've never imagined D/Java interop would be so nice to use! And this is thanks to D's awesome metaprogramming capabilities. Compile-time introspection + static foreach, pragma(mangle), and mixin templates = win. I had no idea that existed. That should really be promoted. There might be a lot of interest.
Re: code.dlang.org downtime
On Tuesday, 17 December 2019 at 00:55:35 UTC, Pham wrote: On Monday, 16 December 2019 at 22:43:58 UTC, bachmeier wrote: On Monday, 16 December 2019 at 20:21:16 UTC, Temtaime wrote: My ISP still serves old IP. Thanks for such a blackout. D is still not for production use, just a toy that may break accidentally by a will of its creators. I wish I could disagree, but from the view of large enterprise adoption, this is indeed a very bad situation. Interprise must always use local copy -> never blindly trust the internet for reliable! Oh, I don't doubt that. My point was that it makes the D language project look like a small-scale open source project relying on volunteers (in this case Sonke) being generous with time and resources. What manager is going to trust a project like that with a major project? It seems unlikely that this would not be considered a major issue.
Re: code.dlang.org downtime
On Monday, 16 December 2019 at 20:21:16 UTC, Temtaime wrote: My ISP still serves old IP. Thanks for such a blackout. D is still not for production use, just a toy that may break accidentally by a will of its creators. I wish I could disagree, but from the view of large enterprise adoption, this is indeed a very bad situation.
Re: Goings-on in DLand
On Tuesday, 10 December 2019 at 10:09:22 UTC, Mike Parker wrote: My latest post on the D Blog is an update on some current and upcoming events, a thank you note to all of our contributors, and a plea to help us fill our ongoing need for contributions. Thanks for the post. The language is making major steps forward. I was not aware that Weka had provided funding for so much work. Thanks to them for their contribution.
Re: dud: A dub replacement
On Monday, 18 November 2019 at 19:44:46 UTC, Russel Winder wrote: On Mon, 2019-11-18 at 15:35 +, Joseph Rushton Wakeling via Digitalmars-d- announce wrote: […] It is quite extraordinary how readily folks fall to arguing over what the config format should be, rather than what the app should actually be able to do. :-\ Perhaps because writing the configuration files is a critical part of the usability of the tool. IMO this is one of the most important parts of the first five minutes with the language. Someone has installed the compiler, and now they want to test it out. If they have a bad experience with Dub, they will not continue with the language. A package manager, including the choice of format, is something you have to get right. Rust understands this.
Re: When will you announce DConf 2020?
On Wednesday, 6 November 2019 at 21:30:36 UTC, Ali Çehreli wrote: On 11/06/2019 11:20 AM, bachmeier wrote: > While I encourage you to submit a talk, I encourage everyone to submit a proposal. > I'll point out that there were > only six regular talks per day this year, and a lot of those were core > contributors A major part of that outcome was the low number of total proposals. The core contributors and others kind of chipped in to save the day. We want tons of proposals. Ali Also, it's low cost to submit, so there's no reason not to do so. Even if it's turned down, you don't have much to lose. You'd obviously have more information about the proposals than I do, but there must not have been many given how few presentations came from outside the inner circle this year.
Re: When will you announce DConf 2020?
On Tuesday, 5 November 2019 at 03:04:30 UTC, Murilo wrote: On Sunday, 3 November 2019 at 19:49:48 UTC, Manu wrote: On Sun, Nov 3, 2019 at 8:20 AM Murilo via Digitalmars-d-announce wrote: If you have ideas for an interesting talk, submit a proposal, and perhaps you may have your costs covered? It's great to see people coming from such different parts of the world! Oh, so they cover the costs if I can give an interesting talk? I already had several ideas in mind to speak during DConf but I never imagined that could get my costs covered. While I encourage you to submit a talk, I'll point out that there were only six regular talks per day this year, and a lot of those were core contributors, Andrei's students, and prominent members of the community. So hope for the best but maybe don't be too disappointed if there's no room on the schedule.
Re: DLang Tour Now Supports Korean
On Friday, 1 November 2019 at 09:57:13 UTC, Mike Parker wrote: BOSKorea has a few Korean programmers who had never used D before joining the company. Now future hires can take the DLang Tour in Korean. Thanks to Mathias Lang for initiating the translation effort. https://tour.dlang.org/tour/en/welcome/languages This is great. At least one person is using it.
Re: Átila's Vision of D's Future
On Wednesday, 16 October 2019 at 09:46:49 UTC, aliak wrote: On Tuesday, 15 October 2019 at 20:33:32 UTC, Walter Bright wrote: On 10/15/2019 6:11 AM, Mike Parker wrote: Reddit: https://www.reddit.com/r/d_language/comments/di7gwl/%C3%A1tilas_vision_of_ds_future/ It's also on the front page of hacker news: https://news.ycombinator.com/news It's better to link straight to an item on hackernews as links on the front page disappear very fast. https://news.ycombinator.com/item?id=21257943 Cheers, - Ali You can do that once it's no longer on the front page, but if you do that while it's on the front page the post will be deleted.
Re: New Funding Initiatives from the D Language Foundation
On Friday, 4 October 2019 at 10:22:56 UTC, Mike Parker wrote: The latest post on the blog details some new funding initiatives from the D Language Foundation. This includes putting some of the HR Fund to use and seeding the first two of a set of forthcoming Bugzilla bounties. https://dlang.org/blog/2019/10/04/d-language-foundation-funding-new-platforms-new-bounties/ It's good to see D moving forward like this, and to see that there are some real dollar amounts to support these important projects. Things continue to get better week by week.
Re: commonmark-d: A fast CommonMark and Github Flavoured Markdown parser, translation of MD4C
On Monday, 30 September 2019 at 23:06:42 UTC, Guillaume Piolat wrote: Hello, commonmark-d is a D translation of MD4C, a fast SAX-like Markdown parser. MD4C achieves remarkable parsing speed through the lack of AST and careful memory usage. The route of translation was choosen because parsing Markdown is much more involved that first thought. The D translation largely preserve the speed benefits of M4DC. Usage: // Parse CommonMark, generate HTML import commonmarkd; string html = convertMarkdownToHTML(markdown); Key Performance Numbers: - commonmark-d compiles 3x faster than dmarkdown and 40x faster than hunt-markdown. - commonmark-d parses Markdown 2x faster than dmarkdown and 15x faster than hunt-markdown (see GitHub for benchmark details) I haven't measured memory usage of either compile time or run time, but I feel like it's also better. Available now on DUB: http://code.dlang.org/packages/commonmark-d GitHub page: https://github.com/p0nce/commonmark-d This is really nice. The examples show only conversion to html. Is there an easy way to get the intermediate output and convert to PDF through latex, to org-mode, etc., or to change the html conversion? One use case that is easy with Pandoc is to copy just the code from markdown into its own source file as a simple form of literate programming.
Re: Release D 2.088.0
On Tuesday, 3 September 2019 at 08:22:36 UTC, Manu wrote: I like to think std::string and std::vector are a pretty big deal too ;) And thanks to you and whoever else did the work!
Re: Release D 2.088.0
On Tuesday, 3 September 2019 at 08:22:36 UTC, Manu wrote: I like to think std::string and std::vector are a pretty big deal too ;) Those are a big deal. From a marketing perspective, those are gold IMO.
Re: Intellij: Support for TextMate Bundled
On Thursday, 25 July 2019 at 19:42:21 UTC, Andre Pany wrote: On Thursday, 25 July 2019 at 18:46:00 UTC, bachmeier wrote: On Thursday, 25 July 2019 at 16:20:15 UTC, Andre Pany wrote: [...] Curious if there are a lot of D programmers using IntelliJ. It's $500 just for the first year. The community edition is free to use even for commercial usage. Kind regards Andre I'll check it out. I must not have understood when I read people talking about paying for it.
Re: Intellij: Support for TextMate Bundled
On Thursday, 25 July 2019 at 16:20:15 UTC, Andre Pany wrote: Hi, Intellij added support for TextMate bundles. By adding the DLang TextMate Bundle[1] you get syntax highlighting. If you want also code completion, formatting and linting you can install the LSP plugin from marketplace and setup DLS [2]. In addition there is also the complete D support including debugging by installing the IntelliJ D plugin from marketplace. [1] https://github.com/textmate/d.tmbundle [2] https://github.com/d-language-server/dls Kind regards Andre Curious if there are a lot of D programmers using IntelliJ. It's $500 just for the first year.
Re: DConf 2019 Livestream
On Wednesday, 8 May 2019 at 08:00:15 UTC, Andrej Mitrovic wrote: On Wednesday, 8 May 2019 at 07:57:40 UTC, Mike Parker wrote: The venue uses WebEx for livestreaming. All the information is available in this PDF: https://drive.google.com/open?id=1yekllbfOmxHqJNuuWIVeP9vNeROmfp1I "When joining: Please connect using Internet Explorer, not Google Chrome or another web browser." You guys can't be serious, you're using WebEx? I could be wrong, but I think this also means we'd need to watch the videos on webex in the future, not just the livestream.
Re: DStep 1.0.0 on the Blog
On Monday, 22 April 2019 at 12:24:16 UTC, Mike Parker wrote: To coincide with the announcement of DStep 1.0.0, Jacob submitted a post to the D Blog that goes into detail on all the new stuff included in this release. The blog: https://dlang.org/blog/2019/04/22/dstep-1-0-0/ Reddit: https://www.reddit.com/r/programming/comments/bg1ezr/dstep_100_generate_d_bindings_from_c_and/ Nice post. I think "DStep" in the first sentence should be a link to the Github page. I didn't see any other links to it until the very bottom of the page.
Re: DIP 1018--The Copy Constructor--Formal Review
On Monday, 25 February 2019 at 19:24:55 UTC, Mike Parker wrote: From the process document: “the DIP Manager or the Language Maintainers may allow for exceptions which waive requirements or responsibilities at their discretion.” If you were to write a DIP for a feature they think important enough, it could be fast tracked, too. I hate to be so negative, but when I see D's corporate management structure, the lack of community contribution is obvious. It doesn't exactly motivate contributions. This is no way to run an open source project. I understand that it works well for Facebook because everyone on the team is paid six figures, and they can be replaced in two hours, but an open source project is not Facebook. I know the whole argument about why it is that way. That doesn't mean it's going to work.
Re: Top Five World’s Most Underrated Programming Languages
On Wednesday, 23 January 2019 at 18:42:06 UTC, bauss wrote: Go is garbage and it's only popular because Google is behind it. It has absolutely nothing to do with the language itself. I don't know if I'd agree that it's garbage - it has a lot of appeal to certain types of programmers, though not to me - but I do agree that it's popular (to whatever extent it is) because of Google. I remember when the language was first announced, there were a lot of people excited by the prospect that GOOGLE IS CREATING A LANGUAGE. IT HAS TO BE AWESOME. These were not people who tried the language and found it to be better than the alternatives. They were people who hadn't even seen it. That was back in the days when Microsoft was the devil and Google were the good guys. Of course, one could argue that it must have offered enough to keep some of them interested. They were able to get stuff done when they used it.
Re: Top Five World’s Most Underrated Programming Languages
On Wednesday, 23 January 2019 at 12:26:02 UTC, rikki cattermole
wrote:
Also as an FYI, Rust has had significant marketing effort put
into it. Consider its home page, it tells a story to get you
into developing code fast. D's doesn't. It is much better and I
think it might be time to have a complete rethink of D's
because the last redesign wasn't all that different to what it
was prior.
I've made this comparison many times before, but I'll do it
again...
Look at what Rust offers as documentation for Cargo:
https://doc.rust-lang.org/cargo/index.html
This is what you get with Dub:
https://dub.pm/getting_started
One is professional documentation, the other was something hacked
together by a sixth grader over the weekend. The Dub
documentation is good through the part demonstrating `dub init`,
then it falls apart. It talks about two configuration file
formats - not one, but two ("use whichever you prefer") and I
have no idea there is even a discussion of configuration file
formats at that point. Then there's a link to this word dump
https://dub.pm/package-format-json.html.
Noticeably absent: how I'm supposed to *use* Dub. Where do I put
my source files? How do I add dependencies? Have you ever heard
of an example?
Then a little below that is a link to this page:
https://dub.pm/publish.html. I wonder what that is for. Can't
make heads or tails out of that.
This is *introduction to the language*. If someone sees that and
doesn't run away, there's something wrong. I most definitely
would have gone with Rust if it had been usable when I started
using D. The Dub documentation makes it really hard to bring in
users - and makes Rust look like a sane language in comparison.
Re: The New Fundraising Campaign
On Saturday, 19 January 2019 at 16:15:21 UTC, H. S. Teoh wrote: I wonder if it's worth it to split the database into an active part (for recent threads) and an archive part (for older threads that are unlikely to change). Most of the lookups will be in the smaller active part, which hopefully will be more performant, and old posts will be migrated to the archive to maintain a maximum active size. Whatever the problem, it's reasonable to raise money to fix it. We shouldn't expect Vladimir to do all the work for something like this.
Re: The New Fundraising Campaign
On Saturday, 19 January 2019 at 08:17:30 UTC, Anonymouse wrote: On Saturday, 19 January 2019 at 06:43:34 UTC, H. S. Teoh wrote: This forum is very functional. I would participate less in a forum that requires loading up a browser to use. But then again, maybe people would be happier if I wasn't around to blab about vim and symmetry and why dub sux, so perhaps that might be for the better. :-P T For us on the browser pages don't always load, though. The norm is for pages to not load in the browser. I don't think it's necessary to elaborate on the impression this creates on potential users.
Re: The New Fundraising Campaign
On Friday, 4 January 2019 at 10:30:07 UTC, Martin Tschierschke wrote: Cool, what a wonderful start to the year 2019! A big thank you to all pushing the development of D with money and time! What next Mike? Hopefully a campaign to put together a working forum. Would you invest major resources in a language that doesn't even have a usable forum?
Re: My Meeting C++ Keynote video is now available
On Monday, 14 January 2019 at 03:58:37 UTC, Mike Franklin wrote: Because design by introspection allows us to "assemble programs atomically", perhaps high-level language features like classes and interfaces can become obsolete, and the language itself can be reduced simpler primitives that don't require the overhead of a runtime. Only a small sliver of programming involves anything where "overhead of a runtime" is an issue. I hope you intend this comment as pertaining to Better C usage.
Re: My Meeting C++ Keynote video is now available
On Monday, 14 January 2019 at 05:31:27 UTC, Paul Backus wrote: Scheme is probably the language that takes this idea of a minimal "core language" with powerful metaprogramming facilities the furthest, and the result is a fragmented ecosystem that makes writing portable, non-trivial programs close to impossible. (See "The Lisp Curse" [1].) Much as I hate to disagree with folks on the internet, this is an explanation in search of an example. Scheme was originally created as a toy language so Steele and Sussman could have an object oriented language with actors.[1] It later turned out to be a good language for SICP. Macros did not even appear in the Scheme standard until R4RS, and they were not part of the standard until R5RS in 1998, 23 years after initial work started on Scheme. That's not to say that individual implementations didn't have Common Lisp macros prior to R5RS, but the metaprogramming thing was more of a Common Lisp thing than a Scheme thing. To me, it's obvious why Scheme has never taken off. It wasn't created as a language for widespread commercial usage. That was the realm of Common Lisp, and to some extent Common Lisp succeeded. CL was not killed by excessive use of macros. I'll also note that R started as a dialect of Scheme, but it was designed for practical use from the start, and it has millions of users. D has little hope of ever achieving the popularity of R. You can do all kinds of metaprogramming with R. I got tired of R's lack of proper tail call support, so added a working implementation of Clojure's recur in a couple of hours. Extrapolating from Scheme to D is simply not the best use of one's time. [1] See page 33 of https://dreamsongs.com/Files/HOPL2-Uncut.pdf
Re: Blog post: What D got wrong
On Tuesday, 18 December 2018 at 12:20:48 UTC, Kagamin wrote: On Tuesday, 18 December 2018 at 10:19:14 UTC, Russel Winder wrote: Clojure is but you have to work hard for that, the initial language is effectively pure. https://ideone.com/y8KWja clearly it isn't, its site only claims that most code happens to be pure, but it looks like it's not checked in any way and not sure if purity can be even checked there. From the Clojure homepage: "Clojure is impure, yet stands behind the philosophy that programs that are more functional are more robust." The goal is to make it easy to program in a functional style, not to provide a pure functional programming language. It is like OCaml in that respect.
Re: Autowrap for .NET is Now Available
On Thursday, 13 December 2018 at 11:24:05 UTC, Adam Wilson wrote: I am pleased to announce that Autowrap has now gained the ability to generate .NET interfaces for D libraries! This means that if you have a D library that you would like to call from .NET you can now Autowrap it and use the library in .NET as if it were any other .NET assembly. I've never done much with .NET. Will this allow calling of D libraries from F#?
