On Friday, 26 January 2024 at 11:38:39 UTC, Stephen Tashiro wrote:
On Thursday, 25 January 2024 at 20:36:49 UTC, Kagamin wrote:
On Thursday, 25 January 2024 at 20:11:05 UTC, Stephen Tashiro
wrote:
void main()
{
ulong [3][2] static_array = [ [0,1,2],[3,4,5] ];
On Monday, 22 January 2024 at 11:31:11 UTC, zjh wrote:
On Monday, 22 January 2024 at 08:54:54 UTC, zjh wrote:
```d
struct Person {
string name, email;
ulong age;
}
Person a{"n","email",33};
```
C++ can achieve ultimate `simplicity` without violating `DRY`,
And here, D violates the
On Wednesday, 24 January 2024 at 00:34:19 UTC, bachmeier wrote:
On Tuesday, 23 January 2024 at 21:40:46 UTC, Renato wrote:
While I can understand your frustration, it seems to me D is
not to blame in this instance because the code is quite
patently using unsafe constructs (D does not claim to
On Tuesday, 23 January 2024 at 23:40:55 UTC, Danilo wrote:
How did you make it correct?
Write 2 different versions for `signed` and `unsigned` types?
Or could you utilize `core.checkedint` somehow for checking
overflow?
```d
double value(T)(T index, double * x) {
bool overflow;
On Tuesday, 23 January 2024 at 21:18:53 UTC, bachmeier wrote:
There are two things things that cause the problem. One is the
use of a template and the other is passing an unsigned type.
The reason the first parameter uses a template is because there
are a lot of types I could send as the first
On Tuesday, 23 January 2024 at 19:32:31 UTC, Stephen Tashiro
wrote:
Thank you.
I don't really understand what the syntax
new Point[][](the_dimension,the_dimension);
denotes. Does it represent a function? To look up this topic,
what are the proper keywords?
By experimentation, I found
On Tuesday, 23 January 2024 at 17:54:25 UTC, bachmeier wrote:
On Tuesday, 23 January 2024 at 12:34:38 UTC, Nick Treleaven
wrote:
But I'm strongly in favour of catching any bugs at
compile-time (and have been since before I discovered D). I
just object to anyone trying to downgrade the
On Tuesday, 23 January 2024 at 18:15:29 UTC, Stephen Tashiro
wrote:
If the constructor of a class needs to create an array of
structs whose dimensions are inputs, what's the syntax for
doing this?
For a non-example, the following program errors in main()
because in t.array[][] "index [0] is
On Saturday, 20 January 2024 at 21:12:12 UTC, ryuukk_ wrote:
dub might not be passing this flag down to dependencies..
Try this env variable:
``LDFLAGS="$LDFLAGS -Wl,-ld_classic" dub build``
That didn't help.
If that doesn't work, try this one:
``MACOSX_DEPLOYMENT_TARGET=11 dub build``
On Friday, 22 December 2023 at 17:50:47 UTC, Johan wrote:
Some general advice:
1 - use `dub` from LDC's package (this may solve some arm64 vs
x86 issues when on Apple Silicon CPU)
2 - when you use a new or different compiler, you have to
rebuild _all_ packages. So clear your dub cache.
I
On Saturday, 20 January 2024 at 19:45:19 UTC, Daniel Kozak wrote:
On Sat, Jan 20, 2024 at 2:11 PM Renato via Digitalmars-d-learn
< digitalmars-d-learn@puremagic.com> wrote:
Wow, fantastic feedback from lots of people, thanks so much!
...
> evilrat:
> There is another important d
On Saturday, 20 January 2024 at 15:16:00 UTC, atzensepp wrote:
The section looks now simpler although I guess that there are
more appropriate mechanisms available (csvreader):
string [] orgids[string];
foreach (line; range)
{
if (!line.empty)
{
auto row
On Saturday, 20 January 2024 at 13:07:39 UTC, Renato wrote:
D overhead with the fastest compiler, LDC, compared with Rust:
```
1.0
1.707627119
1.919527897
1.954595186
1.351342502
1.556217748
```
Oh sorry, I only posted the rates for the Linux benchmark...
On Mac M1, for some reason, D was
Wow, fantastic feedback from lots of people, thanks so much!
I will try to answer all points raised in the several answers
I've got here since yesterday.
On Saturday, 20 January 2024 at 01:27:50 UTC, H. S. Teoh wrote:
I'm confused by the chained hashing of the digits. Why is that
On Friday, 19 January 2024 at 10:15:57 UTC, evilrat wrote:
On Friday, 19 January 2024 at 09:08:17 UTC, Renato wrote:
I forgot to mention: the Java version is using a Trie... and
it consistently beats the Rust numeric algorithm (which means
it's still faster than your D solution), but the
On Friday, 19 January 2024 at 10:15:57 UTC, evilrat wrote:
On Friday, 19 January 2024 at 09:08:17 UTC, Renato wrote:
I forgot to mention: the Java version is using a Trie... and
it consistently beats the Rust numeric algorithm (which means
it's still faster than your D solution), but the
On Friday, 19 January 2024 at 05:17:51 UTC, H. S. Teoh wrote:
On Thu, Jan 18, 2024 at 04:23:16PM +, Renato via
Digitalmars-d-learn wrote: [...]
Ok, last time I'm running this for someone else :D
```
Proc,Run,Memory(bytes),Time(ms)
===> ./rust
./rust,23920640,30
./rust,24018944,147
./r
On Thursday, 18 January 2024 at 04:31:52 UTC, zjh wrote:
On Thursday, 18 January 2024 at 04:24:18 UTC, zjh wrote:
```d
class V : ASTVisitor
{
Vector!string f=[];
alias visit = ASTVisitor.visit;
override void visit(const FunctionDeclaration decl)
{
writeln('
On Wednesday, 17 January 2024 at 16:54:00 UTC, H. S. Teoh wrote:
On Wed, Jan 17, 2024 at 07:57:02AM -0800, H. S. Teoh via
Digitalmars-d-learn wrote: [...]
I'll push the code to github.
[...]
Here:
https://github.com/quickfur/prechelt/blob/master/encode_phone.d
T
BTW here's you main
On Wednesday, 17 January 2024 at 16:54:00 UTC, H. S. Teoh wrote:
On Wed, Jan 17, 2024 at 07:57:02AM -0800, H. S. Teoh via
Digitalmars-d-learn wrote: [...]
I'll push the code to github.
[...]
Here:
https://github.com/quickfur/prechelt/blob/master/encode_phone.d
T
Ok, last time I'm
On Wednesday, 17 January 2024 at 16:30:08 UTC, H. S. Teoh wrote:
On Wed, Jan 17, 2024 at 07:19:39AM +, Renato via
Digitalmars-d-learn wrote: [...]
But pls run the benchmarks yourself as I am not going to keep
running it for you, and would be nice if you posted your
solution on a Gist
On Wednesday, 17 January 2024 at 13:38:10 UTC, Orfeo wrote:
On Tuesday, 16 January 2024 at 19:05:43 UTC, Jonathan M Davis
wrote:
When local imports were introduced, they were pushed as best
practice (in part, because Andrei is a big fan of them), and I
think that for the most part, they
On Wednesday, 17 January 2024 at 11:56:19 UTC, evilrat wrote:
On Wednesday, 17 January 2024 at 11:20:14 UTC, Renato wrote:
That means the input file is still not ASCII (or UTF-8) as it
should. Java is reading files with the ASCII encoding so it
should've worked fine.
It seems that it is
On Wednesday, 17 January 2024 at 10:50:26 UTC, evilrat wrote:
On Wednesday, 17 January 2024 at 10:43:22 UTC, Renato wrote:
On Wednesday, 17 January 2024 at 10:24:31 UTC, Renato wrote:
It's not Java writing the file, it's the bash script
On Wednesday, 17 January 2024 at 10:24:31 UTC, Renato wrote:
It's not Java writing the file, it's the bash script
[`benchmark.sh`](https://github.com/renatoathaydes/prechelt-phone-number-encoding/blob/master/benchmark.sh#L31):
```
java -cp "build/util" util.GeneratePhoneNumbers 1000 >
On Wednesday, 17 January 2024 at 09:15:02 UTC, evilrat wrote:
On Wednesday, 17 January 2024 at 07:11:02 UTC, Renato wrote:
If you want to check your performance, you know you can run
the `./benchmark.sh` yourself?
Out of curiosity I've tried to manually run this on Windows and
it seems
On Tuesday, 16 January 2024 at 22:13:55 UTC, H. S. Teoh wrote:
used for the recursive calls. Getting rid of the .format ought
to speed it up a bit. Will try that now...
That will make no difference for the `count` option which is
where your solution was very slow. To run the slow test
On Tuesday, 16 January 2024 at 22:15:04 UTC, Siarhei Siamashka
wrote:
On Tuesday, 16 January 2024 at 21:15:19 UTC, Renato wrote:
For the record (I already posted this on GitHub)... here's [my
current fastest
On Tuesday, 16 January 2024 at 20:34:48 UTC, H. S. Teoh wrote:
On Tue, Jan 16, 2024 at 12:28:49PM -0800, H. S. Teoh via
Digitalmars-d-learn wrote: [...]
Anyway, I've fixed the problem, now my program produces the
exact same output as Renato's repo. Code is posted below.
[...]
Great, I ran
On Tuesday, 16 January 2024 at 16:56:04 UTC, Siarhei Siamashka
wrote:
On Tuesday, 16 January 2024 at 15:50:35 UTC, H. S. Teoh wrote:
Unfortunately there seems to be some discrepancy between the
output I got and the prescribed output in your repository. For
example, in your output the number
On Monday, 15 January 2024 at 01:10:14 UTC, Sergey wrote:
On Sunday, 14 January 2024 at 17:11:27 UTC, Renato wrote:
If anyone can find any flaw in my methodology or optmise my
code so that it can still get a couple of times faster,
approaching Rust's performance, I would greatly appreciate
On Sunday, 14 January 2024 at 10:02:58 UTC, Jordan Wilson wrote:
On Saturday, 13 January 2024 at 11:03:42 UTC, Renato wrote:
I like to use a phone encoding problem to determine the
strenghtness and weaknesses of programming languages because
this problem is easy enough I can write solutions in
On Saturday, 13 January 2024 at 23:20:32 UTC, Sergey wrote:
On Saturday, 13 January 2024 at 19:35:57 UTC, Renato wrote:
On Saturday, 13 January 2024 at 17:00:58 UTC, Anonymouse wrote:
On Saturday, 13 January 2024 at 12:55:27 UTC, Renato wrote:
[...]
I will have to try it... I thought that
On Saturday, 13 January 2024 at 17:00:58 UTC, Anonymouse wrote:
On Saturday, 13 January 2024 at 12:55:27 UTC, Renato wrote:
[...]
Not a great profiling experience :). Anyone has a better
suggestion to "parse" the trace file?
As a drive-by suggestion and I hope it doesn't derail anything,
On Saturday, 13 January 2024 at 11:03:42 UTC, Renato wrote:
I tried to profile the D code but the profiler seems to be
broken on my OS (Mac):
I profiled it on Linux and stored [the trace.log
file](https://gist.github.com/renatoathaydes/fd8752ed81b0cf792ed7ef5aa3d68acd) on a public Gist.
I like to use a phone encoding problem to determine the
strenghtness and weaknesses of programming languages because this
problem is easy enough I can write solutions in any language in a
few hours, but complex enough to exercise lots of interesting
parts of the language.
You can check [my
On Monday, 8 January 2024 at 23:00:02 UTC, Dennis wrote:
On Monday, 8 January 2024 at 21:56:10 UTC, Renato wrote:
but I tried exactly that! Which gives a seg fault.
Looks like there's a bug with the -H switch:
https://issues.dlang.org/show_bug.cgi?id=24326
That's the bug that is affecting
On Monday, 8 January 2024 at 21:04:10 UTC, Dennis wrote:
On Monday, 8 January 2024 at 18:53:47 UTC, Renato wrote:
Perhaps using an intermediate C file to do this would work,
but I wanted to know if D can do it.
Yes, your best options are either:
- rename the .h to .c and edit it so the
On Monday, 8 January 2024 at 19:17:06 UTC, Lance Bachmeier wrote:
On Monday, 8 January 2024 at 18:53:47 UTC, Renato wrote:
Is it possible to use C header-only libs from D?
In C, I would need to do this:
```c
#define STB_DS_IMPLEMENTATION
#include "stb_ds.h"
```
The definition must be done in
Is it possible to use C header-only libs from D?
In C, I would need to do this:
```c
#define STB_DS_IMPLEMENTATION
#include "stb_ds.h"
```
The definition must be done in a single C file before including
the h file.
I tried this in D:
```d
enum STB_DS_IMPLEMENTATION = 1;
import stb_ds;
```
On Friday, 22 December 2023 at 17:45:27 UTC, Renato wrote:
I'm afraid I've lost interest to make it work at this point :(
Did you add "-L-ld_classic"?
That's the first thing I did... without that, LDC still
compiles , but logs a huge amount of things like this (it keeps
going for a few
On Saturday, 30 December 2023 at 19:27:08 UTC, Matheus Catarino
wrote:
Hi everyone.
Currently I'm working on D binding for sokol project (truly a
dual bindgen [sokol-tools, sokol-header]) which could be merged
into the upstream project.
Sorry if I sidetrack the discussion, but I was
On Wednesday, 27 December 2023 at 11:08:26 UTC, Thomas Teixeira
wrote:
Hi, you all !
I've wanted to look at D for the last two years, being a C
fanboy and not fond of C++.
It seemed like a good alternative between some delightful extra
new stuff and keeping C-like experience : performances
On Sunday, 24 December 2023 at 21:18:44 UTC, kdevel wrote:
On Sunday, 24 December 2023 at 20:00:15 UTC, Renato wrote:
I asked what could be causing an Exception in my code to
happen as that was quite unexpected.
I would have expected you asking questions like "Which program
might have
On Sunday, 24 December 2023 at 15:51:02 UTC, kdevel wrote:
On Sunday, 24 December 2023 at 14:19:18 UTC, Renato wrote:
I was trying to use a library (fswatch) for watching the file
system
Watching for what?
Your feedback is really abrasive. What a shame, first time I get
this kind of
I was trying to use a library (fswatch) for watching the file
system but I immediately ran into an error using it so I decided
to write my own.
Funny thing: I ran into the same error.
It seems that there's some problem with files with a name like
`#tests.txt#` (which emacs likes to create).
On Saturday, 23 December 2023 at 16:13:01 UTC, Renato wrote:
I am trying to use dependencies, so I need dub.
On emacs, the imports from dub libraries cannot be found, even
though dub can build it fine.
How can I get emacs/serve-d to "see" the libraries added by dub?
I found that dub has a
I am trying to use dependencies, so I need dub.
On emacs, the imports from dub libraries cannot be found, even
though dub can build it fine.
How can I get emacs/serve-d to "see" the libraries added by dub?
I found that dub has a command for letting the compiler know
about the load paths:
On Friday, 22 December 2023 at 17:50:47 UTC, Johan wrote:
Some general advice:
1 - use `dub` from LDC's package (this may solve some arm64 vs
x86 issues when on Apple Silicon CPU)
```
▶ which dub
/Users/renato/dlang/ldc-1.35.0/bin/dub
(ldc-1.35.0)
```
2 - when you use a new or different
On Friday, 22 December 2023 at 12:49:35 UTC, Guillaume Piolat
wrote:
On Thursday, 21 December 2023 at 23:25:55 UTC, Renato wrote:
ld: symbol(s) not found for architecture x86_64
Make sure you're using the "osx-universal" package in order to
have both arch.
On Friday, 22 December 2023 at 12:49:35 UTC, Guillaume Piolat
wrote:
On Thursday, 21 December 2023 at 23:25:55 UTC, Renato wrote:
ld: symbol(s) not found for architecture x86_64
Make sure you're using the "osx-universal" package in order to
have both arch.
On Thursday, 21 December 2023 at 19:29:31 UTC, Guillaume Piolat
wrote:
On Thursday, 21 December 2023 at 18:06:51 UTC, Renato wrote:
Unless silly is completely broken, it seems like this is a
linker issue again.
Hello, why not use ldc instead of dmd for macOS?
sudo ln -f -s
On Thursday, 21 December 2023 at 19:29:31 UTC, Guillaume Piolat
wrote:
On Thursday, 21 December 2023 at 18:06:51 UTC, Renato wrote:
Unless silly is completely broken, it seems like this is a
linker issue again.
Hello, why not use ldc instead of dmd for macOS?
sudo ln -f -s
On Sunday, 17 December 2023 at 12:08:40 UTC, Johan wrote:
On Wednesday, 13 December 2023 at 18:32:50 UTC, Renato wrote:
On Wednesday, 4 October 2023 at 11:01:08 UTC, Johan wrote:
On Tuesday, 3 October 2023 at 23:55:05 UTC, confuzzled wrote:
Any known workaround for this most recent issue on
On Wednesday, 20 December 2023 at 19:11:15 UTC, Richard (Rikki)
Andrew Cattermole wrote:
Yes that is to be expected.
It is not templated, and hasn't been compiled into your program.
How do I compile that into my program?
On Wednesday, 20 December 2023 at 18:46:41 UTC, Renato wrote:
```
dmd -L-ld_classic -unittest -checkaction=context -run main.d
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main executable
(maybe you meant:
On Wednesday, 20 December 2023 at 18:16:00 UTC, Renato wrote:
But with -betterC:
```
dmd -L-ld_classic -betterC -run dasc.d
Undefined symbols for architecture x86_64:
"__D3std6int1286Int1286__ctorMFNaNbNcNiNfllZSQBpQBoQBk",
referenced from:
_main in dasc.o
ld: symbol(s) not found for
I wanted to write a small program using betterC that needs to use
int128.
This simple program works without -betterC:
```d
module dasc;
import std.int128;
import core.stdc.stdio;
extern (C):
int main() {
auto n = Int128(128, 128);
printf("n=%lu%lu", n.data.hi, n.data.lo);
return 42;
}
On Thursday, 20 April 2023 at 19:54:11 UTC, Christian Köstlin
wrote:
I tried to reproduce my old eglot experiment, and for me
serve-d was not even compiling with the newest dmd. Which
versions are you using?
Kind regards,
Christian
I've just managed to make Emacs 29 work with serve-d using
On Thursday, 14 December 2023 at 13:12:06 UTC, Richard (Rikki)
Andrew Cattermole wrote:
On 15/12/2023 2:02 AM, Renato wrote:
How do you tell dub to "build and link in a single step"?
This should do it:
``--combined --build-mode=allAtOnce``
I run this:
```
dub build --combined
On Thursday, 14 December 2023 at 12:59:04 UTC, Hipreme wrote:
Yeah, D has a really bad experience in MacOS. If you want to
use it on mac, I suggest using LDC. And the package managers
doesn't do D justice. You want to get the zip and setup the
environment variables yourself, this is the
On Thursday, 14 December 2023 at 12:59:34 UTC, Richard (Rikki)
Andrew Cattermole wrote:
Welcome!
Regarding the problems with dub on OSX, that'll be due to
separate build + link steps.
It should work ok if you build and link in a single step with
the workaround applied.
DC is an
On Thursday, 14 December 2023 at 12:30:35 UTC, Renato wrote:
The other compilers were also easily installable on Kubuntu
using snap.
It seems that the Ubuntu "snap"s are not being updated for a few
years??
It seems some of my problems are related to the very old versions
I got with
Hi, I have been trying D for the last few days... I am only
writing because I really, really like the language! It's
absolutely stunning how the features it has are simple, well
designed and at the same time incredibly advanced! All with an
extremely fast compiler, which is almost
On Wednesday, 4 October 2023 at 11:01:08 UTC, Johan wrote:
On Tuesday, 3 October 2023 at 23:55:05 UTC, confuzzled wrote:
Any known workaround for this most recent issue on macOS
Sonoma? The file I'm compiling contains a blank main() without
any imports but this error shows up on everything
65 matches
Mail list logo
