cond and mutex are global variables,
and "Starting with dmd version 2.030, the default storage class
for statics and globals will be thread local storage (TLS)"
https://dlang.org/articles/migrate-to-shared.html
On Thursday, 11 September 2025 at 09:51:55 UTC, Mikhail wrote:
I don't understand what I should do? Define global variables as
shared?
Andrea Fontana reply more good than my.
But I hope you read article for new knowledges.
Anyway, IMHO, if you want use global variable from two ore more
thread
On Thursday, 11 September 2025 at 09:51:55 UTC, Mikhail wrote:
On Thursday, 11 September 2025 at 09:40:22 UTC, novicetoo wrote:
cond and mutex are global variables,
and "Starting with dmd version 2.030, the default storage
class for statics and globals will be thread local storage
(TLS)"
http
On Thursday, 11 September 2025 at 09:40:22 UTC, novicetoo wrote:
cond and mutex are global variables,
and "Starting with dmd version 2.030, the default storage class
for statics and globals will be thread local storage (TLS)"
https://dlang.org/articles/migrate-to-shared.html
I don't understan
On Thursday, 11 September 2025 at 09:29:29 UTC, Mikhail wrote:
I wrote simple example to learn how the work Conditions.
But program closed with signal, what's wrong?
import std.stdio;
import core.thread;
import core.sync.condition;
import core.sync.mutex;
Condition cond;
Mutex mutex;
void thr
On Wednesday, 19 February 2025 at 23:58:09 UTC, Salih Dincer
wrote:
On Friday, 31 January 2025 at 20:05:54 UTC, Jabari Zakiya wrote:
I'm converting Ruby code to D and am running into issues.
Would appreciate what needs to be done to get it to
compile/run correctly.
I removed 1 line in your co
On Friday, 31 January 2025 at 20:05:54 UTC, Jabari Zakiya wrote:
I'm converting Ruby code to D and am running into issues.
Would appreciate what needs to be done to get it to compile/run
correctly.
First of all, I see that you don't use reserve() at all in
arrays. Since I work on a mobile pla
On Wednesday, 19 February 2025 at 02:25:03 UTC, Salih Dincer
wrote:
have much time right now, I only saw 1 improvement. Below the
GCD filter will give the same list (lhr[]).
SDB@79
It is giving different result
On Tuesday, 18 February 2025 at 22:45:39 UTC, Jabari Zakiya wrote:
I'm bringing attention to this issue as it might improve D.
Known issue with upstream, try one of mine data structures
https://github.com/opendlang/d/blob/main/source/odc/datastructures.d
// convert lhr_mults vals > n/2 to their lhr complements
n-r,
// store them, those < n/2, in lhr_del; it now holds
non-pcp lhr vals
auto lhr_del = lhr_mults.map!((r_del) => r_del > ndiv2 ?
n - r_del : r_del).array;
lhr_del.sort!("a < b");
lhr = setDifference(lhr, l
On Wednesday, 5 February 2025 at 21:24:51 UTC, Jabari Zakiya
wrote:
On Tuesday, 4 February 2025 at 17:17:42 UTC, Jabari Zakiya
wrote:
On Monday, 3 February 2025 at 04:59:43 UTC, monkyyy wrote:
On Monday, 3 February 2025 at 04:15:09 UTC, Jabari Zakiya
wrote:
I translated this Ruby code:
FY
On Tuesday, 4 February 2025 at 17:17:42 UTC, Jabari Zakiya wrote:
On Monday, 3 February 2025 at 04:59:43 UTC, monkyyy wrote:
On Monday, 3 February 2025 at 04:15:09 UTC, Jabari Zakiya
wrote:
I translated this Ruby code:
FYI.
This code finds all the prime pairs that sum to n for all even
in
On Monday, 3 February 2025 at 04:59:43 UTC, monkyyy wrote:
On Monday, 3 February 2025 at 04:15:09 UTC, Jabari Zakiya wrote:
I translated this Ruby code:
FYI.
This code finds all the prime pairs that sum to n for all even
integers n > 2.
It (Ruby code) is included in a paper I just released
On Monday, 3 February 2025 at 04:15:09 UTC, Jabari Zakiya wrote:
I translated this Ruby code:
To this D code. It works, seems fast, can it be done shorter,
faster, more idiomatic?
translated code isnt going to be idiomatic ever; just state what
you want done
On Sunday, 2 February 2025 at 22:40:41 UTC, Jabari Zakiya wrote:
I am really impressed!
D is phenomenally memory efficient with this code.
I just ran the D code for some really large n values.
On my older Lenovo Legion 5, using Linux (June 2024) w/16GB
I was able to go up to n = 1,000,000, a
On Sunday, 2 February 2025 at 03:22:00 UTC, Jabari Zakiya wrote:
The D version is way slower, because of the array operations.
For an input of 100 (1M): D: 12+ secs; Crystal: 0.036 secs.
First of fall make sure you are using LDC or GDC compiler. Second
step is to add proper flags for optim
On Sunday, 2 February 2025 at 01:39:34 UTC, user1234 wrote:
On Sunday, 2 February 2025 at 01:12:59 UTC, user1234 wrote:
On Saturday, 1 February 2025 at 21:56:23 UTC, Jabari Zakiya
wrote:
On Saturday, 1 February 2025 at 00:21:22 UTC, user1234 wrote:
On Friday, 31 January 2025 at 20:05:54 UTC, Ja
On Sunday, 2 February 2025 at 01:12:59 UTC, user1234 wrote:
On Saturday, 1 February 2025 at 21:56:23 UTC, Jabari Zakiya
wrote:
On Saturday, 1 February 2025 at 00:21:22 UTC, user1234 wrote:
On Friday, 31 January 2025 at 20:05:54 UTC, Jabari Zakiya
wrote:
[...]
A first draft of the translation
On Saturday, 1 February 2025 at 21:56:23 UTC, Jabari Zakiya wrote:
On Saturday, 1 February 2025 at 00:21:22 UTC, user1234 wrote:
On Friday, 31 January 2025 at 20:05:54 UTC, Jabari Zakiya
wrote:
[...]
A first draft of the translation, not very idiomatic D code:
```d
module prime_pairs;
import
On Saturday, 1 February 2025 at 00:21:22 UTC, user1234 wrote:
On Friday, 31 January 2025 at 20:05:54 UTC, Jabari Zakiya wrote:
[...]
A first draft of the translation, not very idiomatic D code:
```d
module prime_pairs;
import std;
[...]
Thank you very much!
As you can see, D is not my pri
On Friday, 31 January 2025 at 20:05:54 UTC, Jabari Zakiya wrote:
I'm converting Ruby code to D and am running into issues.
Would appreciate what needs to be done to get it to compile/run
correctly.
Here's the Ruby code:
[...]
A first draft of the translation, not very idiomatic D code:
```
Dne so 20. 1. 2024 21:21 uživatel Renato via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> napsal:
> 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:
> >
>
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 difference, i
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 difference, i quickly looked up D
> > associative array implementation and t
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 a
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
necessary
On Saturday, 20 January 2024 at 01:27:50 UTC, H. S. Teoh wrote:
On Sat, Jan 20, 2024 at 01:35:44AM +0100, Daniel Kozak via
Digitalmars-d-learn wrote: [...]
> Try addressing the points I wrote above and see if it
makes a
> difference.
I have tried it (all of it) even before you wrote i
On Sat, Jan 20, 2024 at 01:35:44AM +0100, Daniel Kozak via Digitalmars-d-learn
wrote:
[...]
>> Try addressing the points I wrote above and see if it makes a
>> difference.
>
>I have tried it (all of it) even before you wrote it here, because
>I have completely the same ideas, but
On Fri, Jan 19, 2024 at 4:44 PM H. S. Teoh via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> Taking a look at this code:
> ...
> Try addressing the points I wrote above and see if it makes a
> difference.
>
>
I have tried it (all of it) even before you wrote it here, because
On Friday, 19 January 2024 at 17:18:36 UTC, evilrat wrote:
On Friday, 19 January 2024 at 16:55:25 UTC, ryuukk_ wrote:
You do hash map lookup for every character in D, it's slow,
whereas in Rust you do it via pattern matching, java does the
same, pattern matching
Yet another reason to advoc
On Friday, 19 January 2024 at 08:57:40 UTC, Renato wrote:
Do you know why the whole thread seems to have disappeared??
There's a lot of good stuff in the thread, it would be a huge
shame to lose all that!
I agree! Thanks for posting your benchmarks, I thought your whole
benching setup was pre
On Friday, 19 January 2024 at 16:55:25 UTC, ryuukk_ wrote:
You do hash map lookup for every character in D, it's slow,
whereas in Rust you do it via pattern matching, java does the
same, pattern matching
Yet another reason to advocate for pattern matching in D and
switch as expression
Th
On Friday, 19 January 2024 at 13:40:39 UTC, Renato wrote:
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 m
On Fri, Jan 19, 2024 at 01:40:39PM +, Renato via Digitalmars-d-learn wrote:
> On Friday, 19 January 2024 at 10:15:57 UTC, evilrat wrote:
[...]
> > Additionally if you comparing D by measuring DMD performance -
> > don't. It is valuable in developing for fast iterations, but it
> > lacks many m
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 Java
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 Java
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
./rust,24
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
> ./rust,24068096,592
> ./rust,24150016,1187
> ./rust,776601
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 funct
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 running
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 for ex
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
--
Why do conspiracy theories always come from the same people??
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
> for example, pasting lots of code in the forum makes it difficult to
On Wed, Jan 17, 2024 at 07:19:39AM +, Renato via Digitalmars-d-learn wrote:
> 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 f
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 onl
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 only works with ASCII encoding though.
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
[`benchmark.sh`](https://github.com/renatoathaydes/prech
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
[`benchmark.sh`](https://github.com/renatoathaydes/prechelt-phone-number-encoding/blob/master/benchmark.sh#L31):
```
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 >
phones
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 that
On Wednesday, 17 January 2024 at 07:06:25 UTC, Renato wrote:
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:
It's a GC allocations fest. Things like this make it slow:
```diff
{
-string digit = [digit
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 that Java generator for these numbers files is "broken",
the resul
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 manual
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
solution](https://github.com/renatoathaydes/prechelt-phone-number-encoding/blob/dlang-k
On Tue, Jan 16, 2024 at 10:15:04PM +, Siarhei Siamashka via
Digitalmars-d-learn wrote:
> On Tuesday, 16 January 2024 at 21:15:19 UTC, Renato wrote:
[...]
> > ... what I am really curious about is what the code I wrote is doing
> > wrong that causes it to run 4x slower than Rust despite doing "
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
solution](https://github.com/renatoathaydes/prechelt-phone-number-encoding/blob/dlang-key-hash-incremental/src/d/src/dencoder.d) time using the same algorithm
On Tue, Jan 16, 2024 at 09:15:19PM +, Renato via Digitalmars-d-learn wrote:
> 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 pro
On Tuesday, 16 January 2024 at 21:15:19 UTC, Renato wrote:
I can't explain why it's so incredibly fast, specially for the
`count` case. I tried using the same hashing function on my
solution, but that didn't really help me!
That's dynamic programming with memoization. Basically caching
the al
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 th
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.
[...]
Oops, forgot to actually paste the code. Here it is:
-
On Tue, Jan 16, 2024 at 06:54:56PM +, Renato via Digitalmars-d-learn wrote:
> On Tuesday, 16 January 2024 at 16:56:04 UTC, Siarhei Siamashka wrote:
[...]
> > You are not allowed to emit "1" as the first token in the output as
> > long as there are any dictionary word matches at that position. T
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 155
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 1556/0 does not have an
encoding, but isn't "1 Mai 0" a valid encoding ac
P.S. Compiling my program with `ldc -O2`, it runs so fast that I
couldn't measure any meaningful running time that's greater than startup
overhead. So I wrote a helper program to generate random phone numbers
up to 50 characters long, and found that it could encode 1 million phone
numbers in 2.2 s
On Tue, Jan 16, 2024 at 07:50:35AM -0800, H. S. Teoh via Digitalmars-d-learn
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 1556/0 does not have an encoding, but isn't
On Mon, Jan 15, 2024 at 08:10:55PM +, Renato via Digitalmars-d-learn wrote:
> 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
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
tha
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
that! But for now, my understanding is that the most promising
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 `Big
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 any
language in a few hours, but complex enough to exercise lots
On Saturday, 13 January 2024 at 23:20:32 UTC, Sergey wrote:
I would suggest to rewrite in the same way as Rust implemented.
Probably you would like to try:
[...]
I would strongly argue for profiling first instead of optimising
based on conjecture. If you profile you have solid evidence on
wha
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 `BigInt` was to blame
for the slowness (from what I could read f
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,
but
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,
but if you have the opportunity to run it on linux, have you
tried
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.
On Monday, 18 September 2023 at 02:49:37 UTC, vino wrote:
On Sunday, 17 September 2023 at 18:28:36 UTC, Joe wrote:
On Friday, 15 September 2023 at 16:55:34 UTC, Vino wrote:
[...]
[...]
char[] invalid = (cast(char*)malloc(char.sizeof *
len))[0..len];
This is not the way to go about it.
On Sunday, 17 September 2023 at 18:28:36 UTC, Joe wrote:
On Friday, 15 September 2023 at 16:55:34 UTC, Vino wrote:
[...]
[...]
char[] invalid = (cast(char*)malloc(char.sizeof * len))[0..len];
This is not the way to go about it. You are mixing "pointer
arrays" with "arrays".
[...]
Tha
On Friday, 15 September 2023 at 16:55:34 UTC, Vino wrote:
On Friday, 15 September 2023 at 15:27:00 UTC, Vino wrote:
On Friday, 15 September 2023 at 02:25:09 UTC, Joe wrote:
On Thursday, 14 September 2023 at 14:21:09 UTC, Vino wrote:
[...]
A pointer is a type that points to something. It's li
On Friday, 15 September 2023 at 15:27:00 UTC, Vino wrote:
On Friday, 15 September 2023 at 02:25:09 UTC, Joe wrote:
On Thursday, 14 September 2023 at 14:21:09 UTC, Vino wrote:
[...]
A pointer is a type that points to something. It's literally
that simple. Every piece of data and code exist so
On Friday, 15 September 2023 at 02:25:09 UTC, Joe wrote:
On Thursday, 14 September 2023 at 14:21:09 UTC, Vino wrote:
[...]
A pointer is a type that points to something. It's literally
that simple. Every piece of data and code exist somewhere in
memory. Every piece of memory has an address. T
On Thursday, 14 September 2023 at 14:21:09 UTC, Vino wrote:
Hi All,
Request your help to guide me in understanding about
pointers, the below code works,I have few question which i need
your help for better understanding.
Questions:1
```
char[] invalid = (cast(char*)malloc(char.sizeof *
l
On Thursday, 14 September 2023 at 17:23:53 UTC, Vino wrote:
On Thursday, 14 September 2023 at 15:33:45 UTC, Paul Backus
wrote:
On Thursday, 14 September 2023 at 14:21:09 UTC, Vino wrote:
Questions:1
```
char[] invalid = (cast(char*)malloc(char.sizeof *
length))[0..length];
```
The above state
On Thursday, 14 September 2023 at 15:33:45 UTC, Paul Backus wrote:
On Thursday, 14 September 2023 at 14:21:09 UTC, Vino wrote:
Questions:1
```
char[] invalid = (cast(char*)malloc(char.sizeof *
length))[0..length];
```
The above statement allocate memory for char type and the size
of the alloc
On Thursday, 14 September 2023 at 14:21:09 UTC, Vino wrote:
Questions:1
```
char[] invalid = (cast(char*)malloc(char.sizeof *
length))[0..length];
```
The above statement allocate memory for char type and the size
of the allocated memory is char.sizeof * length so what is the
use of this "[0.
On Wednesday, 12 April 2023 at 08:25:54 UTC, Richard (Rikki)
Andrew Cattermole wrote:
Your branches + tag is all messed up.
You have both ~master and ~main. ~main has dub.json (which is
required), but the tag is based upon ~master which has your
README.
Between the two branches everything is
Your branches + tag is all messed up.
You have both ~master and ~main. ~main has dub.json (which is required),
but the tag is based upon ~master which has your README.
Between the two branches everything is there, its just that it needs to
be all in one.
On Thursday, 9 March 2023 at 01:22:08 UTC, Steven Schveighoffer
wrote:
This is a known limitation -- dub builds the selections file
based on *all* configurations in the file. If you have
conflicting ones, it will not know what to pick.
However, if you manually construct the selections file,
On 3/8/23 7:52 PM, mw wrote:
Hi,
In my dub.json, I have:
```
"dependencies": {
"apache-thrift": "==0.16.0",
...
}
"subConfigurations": {
"apache-thrift": "use_openssl_1_1",
On Saturday, 22 October 2022 at 12:27:21 UTC, Hipreme wrote:
On Friday, 21 October 2022 at 18:10:39 UTC, ryuukk_ wrote:
I tried your project:
Linux x64
```
git clone https://github.com/MrcSnm/HipremeEngine.git
cd HipremeEngine
dub build (once to download dependencies if any)
time dub build -f
On Friday, 21 October 2022 at 18:10:39 UTC, ryuukk_ wrote:
I tried your project:
Linux x64
```
git clone https://github.com/MrcSnm/HipremeEngine.git
cd HipremeEngine
dub build (once to download dependencies if any)
time dub build -f
real0m4.604s
user0m3.686s
sys 0m0.900s
```
4.6
On Friday, 21 October 2022 at 16:32:17 UTC, Hipreme wrote:
Hey guys, I have been complaining a lot of time right now from
D compilation speed at least for my project.
I have:
- Underused CTFE
- Underused Templates
- Avoided importing standard libraries
- Created a multi module projects for bett
Make sure you have the latest version of DMD
Make sure your antivirus isn't blocking your files (scanning),
it's a common thing with Windows, whitelist dmd folder, your dev
folder and dub folder
I tried your project:
Linux x64
```
git clone https://github.com/MrcSnm/HipremeEngine.git
cd HipremeEngine
dub build (once to download dependencies if any)
time dub build -f
real0m4.604s
user0m3.686s
sys 0m0.900s
```
4.6 sec for a FULL rebuild doesn't seem that bad
and
```
real
On Fri, Oct 21, 2022 at 04:32:17PM +, Hipreme via Digitalmars-d-learn wrote:
> Hey guys, I have been complaining a lot of time right now from D
> compilation speed at least for my project.
>
> I have:
> - Underused CTFE
> - Underused Templates
> - Avoided importing standard libraries
> - Creat
On 13/05/2022 7:03 PM, MichaelBi wrote:
On Friday, 13 May 2022 at 06:43:30 UTC, rikki cattermole wrote:
On 13/05/2022 6:23 PM, MichaelBi wrote:
render!("index.dt", showData());
There ya go, template arguments are run at compile time.
Unh, then how to dynamically generate pages b
On Friday, 13 May 2022 at 06:43:30 UTC, rikki cattermole wrote:
On 13/05/2022 6:23 PM, MichaelBi wrote:
render!("index.dt", showData());
There ya go, template arguments are run at compile time.
Unh, then how to dynamically generate pages by using vibe.d
On 13/05/2022 6:23 PM, MichaelBi wrote:
render!("index.dt", showData());
There ya go, template arguments are run at compile time.
On Friday, 13 May 2022 at 06:12:01 UTC, rikki cattermole wrote:
Okay that is fine, now we need to see where showData is being
called.
thanks, here's the code:
import vibe.vibe;
import std.process;
import std.conv : to;
void main()
{
auto settings = new HTTPServerSettings;
se
Okay that is fine, now we need to see where showData is being called.
1 - 100 of 506 matches
Mail list logo
