Re: Printing shortest decimal form of floating point number with Mir
On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote: On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote: On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote: It was a mockery executed by Atila Read the all comments and didnt saw any mockery Yes, it wasn't explicit. He didn't write bad words, he did a bad decision. Bad for D. Big difference between bad decision and mockery. It's very possible he was wrong, but I don't think he wasn't taking it seriously.
Re: MIR vs. Numpy
On Wednesday, 18 November 2020 at 13:01:42 UTC, Bastiaan Veelo wrote: On Wednesday, 18 November 2020 at 10:05:06 UTC, Tobias Schmidt wrote: Dear all, to compare MIR and Numpy in the HPC context, we implemented a multigrid solver in Python using Numpy and in D using Mir and perforemd some benchmarks with them. You can find our code and results here: https://github.com/typohnebild/numpy-vs-mir Nice numbers. I’m not a Python guy but I was under the impression that Numpy actually is written in C, so that when you benchmark Numpy you’re mostly benchmarking C, not Python. Therefore I had expected the Numpy performance to be much closer to D’s. An important factor I think, which I’m not sure you have discussed (didn’t look too closely), is the compiler backend that was used to compile D and Numpy. Then again, as a user one is mostly interested in the out-of-the-box performance, which this seems to be a good measure of. — Bastiaan. A lot of numpy is in C, C++, fortran, asm etc But when you chain a bunch of things together, you are going via python. The language boundary (and python being slow) means that internal iteration in native code is a requirement for performance, which leads to eager allocation for composability via python, which then hurts performance. Numpy makes a very good effort, but is always constrained by this. Clever schemes with laziness where operations in python are actually just composing operations for execution later/on-demand can work as an alternative, but a) that's hard and b) even if you can completely avoid calling back in to python during iteration you would still need JIT to really unlock the performance. Julia fixes this by having all/most in one language which is JIT'd D can do the same with templates AOT, like C++/Eigen does but more flexible and less terrifying code. That's (one part of) what mir provides.
Re: Printing shortest decimal form of floating point number with Mir
On Monday, 4 January 2021 at 09:21:02 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 4 January 2021 at 09:18:50 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 4 January 2021 at 05:55:37 UTC, Ola Fosheim Grostad
wrote:
On Monday, 4 January 2021 at 04:37:22 UTC, 9il wrote:
I suppose the answer would be that D doesn't pretend to
support all C++ template features and the bug is not a bug
because we live with this somehow for years.
But it is a bug even if there was no C++... An alias should
work by simple substitution, if it does not, then it is no
alias...
Here is an even simpler example that does not work:
struct Foo(T){}
void foo(T)(T!int x) {}
alias FooInt = Foo!int;
void main() {
foo(FooInt());
}
Oh, now wait, it does:
struct Foo(T){}
void foo(alias T)(T!int x) {}
alias FooInt = Foo!int;
void main() {
foo(FooInt());
}
My mistake.
What's the simplest example that doesn't work and is that simple
example just indirection through an alias or is it actually
indirection through a template that *when instantiated* turns out
to be just an alias?
I have a suspicion that what you're asking for here is the
type-inference to have x-ray vision in to uninstantiated
templates that works for a few simple cases. Am I wrong?
To be clear, a really useful special case can be really useful
and worthwhile, but I'm not convinced this is the principled
"type system bug" you are saying it is.
Re: Printing shortest decimal form of floating point number with Mir
On Monday, 4 January 2021 at 13:47:17 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 4 January 2021 at 12:35:12 UTC, John Colvin wrote:
What's the simplest example that doesn't work and is that
simple example just indirection through an alias or is it
actually indirection through a template that *when
instantiated* turns out to be just an alias?
Indirection through a parametric alias. This is the simplest I
have come up with so far:
struct Foo(T) {}
alias Bar(T) = Foo!T;
void f(T)(Bar!T x) {}
void main() {
f(Bar!int());
}
I created a thread for it:
https://forum.dlang.org/post/nxrfrizqdmhzhivxp...@forum.dlang.org
I have a suspicion that what you're asking for here is the
type-inference to have x-ray vision in to uninstantiated
templates that works for a few simple cases. Am I wrong?
No, just substitute: "Bar!int" with "Foo!int".
To be clear, a really useful special case can be really useful
and worthwhile, but I'm not convinced this is the principled
"type system bug" you are saying it is.
Why are you not convinced?
An alias is a short hand. If it is possible to discriminate by
the alias and the actual object then that it a semantic problem.
I have a longer reply I'm trying to write, but just to make sure
I'm on the right track:
template Foo(T) {
alias Foo = T;
}
template Q(A : Foo!T, T) {
pragma(msg, A.stringof, " ", T.stringof);
}
alias X = Q!(Foo!int);
in your opinion, this should compile and msg `int int`, yes?
I'm trying to make a really concise example without using IFTI.
Re: Printing shortest decimal form of floating point number with Mir
On Monday, 4 January 2021 at 17:22:55 UTC, John Colvin wrote:
On Monday, 4 January 2021 at 13:47:17 UTC, Ola Fosheim Grøstad
wrote:
[...]
I have a longer reply I'm trying to write, but just to make
sure I'm on the right track:
template Foo(T) {
alias Foo = T;
}
template Q(A : Foo!T, T) {
pragma(msg, A.stringof, " ", T.stringof);
}
alias X = Q!(Foo!int);
in your opinion, this should compile and msg `int int`, yes?
I'm trying to make a really concise example without using IFTI.
and presumably the same for
alias X = Q!(int);
yes?
Re: Symmetry looking for D programmers in Singapore/Hong Kong/Australia/New Zealand
On Wednesday, 16 June 2021 at 17:13:35 UTC, russhy wrote: For what kind of project? need more info It might help to look at https://jobs.symmetryinvestments.dev/ and https://github.com/symmetryinvestments/
Re: From the D Blog -- Interfacing D with C: Strings Part One
On Monday, 24 May 2021 at 16:16:53 UTC, Steven Schveighoffer
wrote:
On 5/24/21 10:02 AM, Mike Parker wrote:
The latest post in the D and C series dives into the weeds of
D and C strings: how they're implemented, when you need to
NUL-terminate your D strings and when you don't, and how the
storage of literals in memory allows you to avoid NUL
termination in one case you might not have considered and
another case that you shouldn't rely on but can in practice
with the current compilers.
There are at least two more posts worth of information to go
into on this topic, but everything in this post is enough to
cover many use cases of D to C string interop.
The blog:
https://dlang.org/blog/2021/05/24/interfacing-d-with-c-strings-part-one/
Reddit:
https://www.reddit.com/r/programming/comments/njyf76/interfacing_d_with_c_strings_part_one/
Nice article!
Note that there is a huge pitfall awaiting you if you use
`toStringz`: garbage collection. You may want to amend the
article to identify this pitfall.
And I'm not talking about requiring `@nogc`, I'm talking about
the GC collecting the data while C is still using it.
In your example:
```d
puts(s1.toStringz());
```
This leaves a GC-collectible allocation in C land. For `puts`,
it's fine, as the data is not used past the call, but in
something else that might keep it somewhere not accessible to
the GC, you'll want to assign that to a variable that lasts as
long as the resource is used.
-Steve
It’s worse than that, no? If the only reference to GC data isn’t
on the stack of a tracked thread, in GC allocated memory or in a
tracked root then it can be freed. Even in D:
void foo(int* a) {
int** b = cast(int**) malloc((int*).sizeof);
*b = a;
a = null;
GC.collect();
**b = 4; // whoops!!
}
foo(new int);
Right? Obviously that collection could be from calling another
function (e.g. a callback from C to D code) or from another
thread. Or am I missing something?
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/ Good talk. Many very clever people would achieve more if they tried to understand why a v. experienced developer would care to spend so much time talking about what might appear to be such basic points. The key challenge: If this stuff was so obvious & everyone did it or it didn't matter so much that they didn't, why would Walter care about it so much?
Re: Beerconf October 2022
On Sunday, 30 October 2022 at 01:50:33 UTC, Steven Schveighoffer wrote: On 10/29/22 2:00 PM, FeepingCreature wrote: On Saturday, 29 October 2022 at 10:14:31 UTC, rikki cattermole wrote: And now for some good news! Its almost Halloween, so grab your candy and any spooky brews you may have, and join us for a ghostly chat! https://meet.jit.si/Dlang2022OctoberBeerConf I wish you'd announce the time a bit in advance. :) I don't want to announce a time, because I don't know what time it can be started. I'm in the US, so I'm usually asleep when it's started. But I do try to announce 2 weeks before and then 2 days before. -Steve Quiet here, I’m around for a couple of hours, come say hi!
Re: text based file formats
On Tuesday, 20 December 2022 at 00:40:07 UTC, H. S. Teoh wrote: On Mon, Dec 19, 2022 at 04:16:57PM -0800, Walter Bright via Digitalmars-d-announce wrote: On 12/19/2022 4:35 AM, Adam D Ruppe wrote: > On Monday, 19 December 2022 at 09:55:47 UTC, Walter Bright > wrote: > > Curious why CSV isn't in the list. > > Maybe std.csv is already good enough? LOL, learn something every day! I've even written my own, but it isn't very good. There's also my little experimental csv parser that was designed to be as fast as possible: https://github.com/quickfur/fastcsv However it can only handle input that fits in memory (using std.mmfile is one possible workaround), has a static limit on field sizes, and does not do validation. T We use this at work with some light tweaks, it’s done a lot work
Re: text based file formats
On Wednesday, 21 December 2022 at 04:19:46 UTC, 9il wrote: On Tuesday, 20 December 2022 at 19:46:36 UTC, John Colvin wrote: On Tuesday, 20 December 2022 at 00:40:07 UTC, H. S. Teoh wrote: [...] We use this at work with some light tweaks, it’s done a lot work It has already been replaced with [mir.csv](https://github.com/libmir/mir-ion/blob/master/source/mir/csv.d). Mir is faster, SIMD accelerated, and supports numbers and timestamp recognition. Hah, so it has! Well anyway, it did do a lot of hard work for us for a long time, so thanks :)
