On Tuesday, 18 October 2022 at 05:48:27 UTC, Ali Çehreli wrote:
On 10/17/22 22:40, Joel wrote:
> I have two text fields. The one on the left has the whole
text, new
> stuff being added to the bottom. The one on the right has
text I've been
> wiping as I'm reading.
I think this can be modelled
On Tuesday, 18 October 2022 at 05:48:27 UTC, Ali Çehreli wrote:
On 10/17/22 22:40, Joel wrote:
> I have two text fields. The one on the left has the whole
text, new
> stuff being added to the bottom. The one on the right has
text I've been
> wiping as I'm reading.
I think this can be modelled
On Tuesday, 18 October 2022 at 11:56:30 UTC, Yura wrote:
```D
// Then for each Sphere, i.e. dot[i]
// I need to do some arithmetics with itself and other dots
// I have only parallelized the inner loop, i is fixed.
It's usually a much better idea to parallelize the outer loop.
Even OpenMP
On Tuesday, 18 October 2022 at 09:56:09 UTC, Siarhei Siamashka
wrote:
On Monday, 17 October 2022 at 20:05:24 UTC, mw wrote:
On Monday, 17 October 2022 at 19:54:12 UTC, Yura wrote:
it is possible to install the most recent ldc and gdc
compilers on Ubuntu 18.04?
Yes, I used LDC on the same
On 10/18/22 06:24, Guillaume Piolat wrote:
> To win something with OS threads, you must think of tasks that takes on
> the order of milliseconds rather than less than 0.1ms.
> Else you will just pay extra in synchronization costs.
In other words, the OP can adjust work unit size. It is on the
Dear All,
I am trying to make a simple code run in parallel. The parallel
version works, and gives the same number as serial albeit slower.
First, the parallel features I am using:
import core.thread: Thread;
import std.range;
import std.parallelism:parallel;
import std.parallelism:taskPool;
On Tuesday, 18 October 2022 at 11:56:30 UTC, Yura wrote:
What I am doing wrong?
The size of your task are way too small.
To win something with OS threads, you must think of tasks that
takes on the order of milliseconds rather than less than 0.1ms.
Else you will just pay extra in
On Monday, 17 October 2022 at 20:22:47 UTC, jmh530 wrote:
If you have a problem with support for mir, submit a bug
report. I don't think gdc is supported, but ldc should be.
GDC12 has finally upgraded its D language frontend version to
2.100 and I have successfully compiled a simple lubeck
On Monday, 17 October 2022 at 20:05:24 UTC, mw wrote:
On Monday, 17 October 2022 at 19:54:12 UTC, Yura wrote:
it is possible to install the most recent ldc and gdc
compilers on Ubuntu 18.04?
Yes, I used LDC on the same system.
What's the recommended way to have up to date D compilers in
Thank you, folks, for your hints and suggestions!
Indeed, I re-wrote the code and got it substantially faster and
well paralleled.
Insted of making inner loop parallel, I made parallel both of
them. For that I had to convert 2d index into 1d, and then back
to 2d. Essentially I had to
Well its not a type system issue.
Making u = n, that'll returns true.
So the problem almost certainly lies with IEEE-754.
They are horrible to compare (float/double).
Unfortunately you are stuck calling functions like isClose to compare.
On 10/18/22 12:26, Hipreme wrote:
> Is there any way to know which files produced this error or at least the
> symbol names that are clashing? I'm totally helpless about this error.
There is 'nm' on Posix systems that lists symbols in object files
(including libraries and programs).
Ali
Yes, did the same and it worked. The amazing thing is that the
system solver turned out to be natively parallel and runs
smoothly!
On Tuesday, 18 October 2022 at 15:22:02 UTC, mw wrote:
On Tuesday, 18 October 2022 at 09:56:09 UTC, Siarhei Siamashka
wrote:
On Monday, 17 October 2022 at
I am in the process of building a matrix class (uni project, with
my choice of programming language) and appear to have run into a
problem that I'm not too sure how to fix.
My class uses templates to define the shape of the matrix,
although I'm not sure if that matters. As part of my class, I
On Tuesday, 18 October 2022 at 18:59:37 UTC, rikki cattermole
wrote:
Well its not a type system issue.
Making u = n, that'll returns true.
So the problem almost certainly lies with IEEE-754.
They are horrible to compare (float/double).
Unfortunately you are stuck calling functions like
I get the warning `warning LNK4255: library contain multiple
objects of the same name; linking object as if no debug info`
when dealing a project with multiple static libraries.
Is there any way to know which files produced this error or at
least the symbol names that are clashing? I'm
On Tuesday, 18 October 2022 at 18:53:41 UTC, Matthew Rushworth
wrote:
The entirety of opEquals:
```
/// both matrices have to have an identical shape to compare
/// each element must be identical to match
bool opEquals(size_t X, size_t Y)(const Matrix!(X,Y) m1, const
Matrix!(X,Y) m2) {
for
On Wednesday, 19 October 2022 at 01:30:23 UTC, H. S. Teoh wrote:
On Wed, Oct 19, 2022 at 01:15:37AM +, Adam D Ruppe via
it only applies to types, not to functions.
Wat... so what's the use of it then? So it's not possible to
mark the return value of an int function @mustUse without
On Tuesday, 18 October 2022 at 19:38:39 UTC, Ali Çehreli wrote:
On 10/18/22 12:26, Hipreme wrote:
> Is there any way to know which files produced this error or
at least the
> symbol names that are clashing? I'm totally helpless about
this error.
There is 'nm' on Posix systems that lists
On 19/10/2022 2:30 PM, H. S. Teoh wrote:
On Wed, Oct 19, 2022 at 01:15:37AM +, Adam D Ruppe via Digitalmars-d-learn
wrote:
On Wednesday, 19 October 2022 at 00:57:31 UTC, H. S. Teoh wrote:
Has it really been implemented? I tested the latest git master, the
following code doesn't compile:
On Tuesday, 18 October 2022 at 20:02:02 UTC, ag0aep6g wrote:
On Tuesday, 18 October 2022 at 18:53:41 UTC, Matthew Rushworth
wrote:
The entirety of opEquals:
```
/// both matrices have to have an identical shape to compare
/// each element must be identical to match
bool opEquals(size_t X,
https://github.com/dlang/dmd/blob/master/druntime/src/core/attribute.d#L292
On Wednesday, 19 October 2022 at 00:57:31 UTC, H. S. Teoh wrote:
Has it really been implemented? I tested the latest git
master, the following code doesn't compile:
it only applies to types, not to functions.
On Wed, Oct 19, 2022 at 01:15:37AM +, Adam D Ruppe via Digitalmars-d-learn
wrote:
> On Wednesday, 19 October 2022 at 00:57:31 UTC, H. S. Teoh wrote:
> > Has it really been implemented? I tested the latest git master, the
> > following code doesn't compile:
>
> it only applies to types, not
On Sat, Oct 15, 2022 at 12:47:02AM +, Mike Parker via Digitalmars-d-learn
wrote:
> On Friday, 14 October 2022 at 22:17:52 UTC, H. S. Teoh wrote:
>
> > Given that this particular trap crops up regularly, perhaps some
> > sort of warning ought to be added. Once the @nodiscard DIP is
> >
On Wednesday, 19 October 2022 at 01:34:54 UTC, mw wrote:
Is there any (design) doc about this?
scroll up, click the link from this very thread.
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md#design-goals-and-possible-alternatives
On Wednesday, 19 October 2022 at 05:41:26 UTC, zjh wrote:
Why can't do it `in one step`?
Why always afraid to `add features`?
C++ is `so complicated` ,but that people are not afraid to
continue to `add features`.
There is also `class level private`. I saw someone start it by
himself, and he
On Wednesday, 19 October 2022 at 01:49:26 UTC, mw wrote:
On Wednesday, 19 October 2022 at 01:38:27 UTC, Adam D Ruppe
wrote:
On Wednesday, 19 October 2022 at 01:34:54 UTC, mw wrote:
Is there any (design) doc about this?
scroll up, click the link from this very thread.
On Wednesday, 19 October 2022 at 01:34:54 UTC, mw wrote:
On Wednesday, 19 October 2022 at 01:30:23 UTC, H. S. Teoh wrote:
On Wed, Oct 19, 2022 at 01:15:37AM +, Adam D Ruppe via
it only applies to types, not to functions.
Wat... so what's the use of it then? So it's not possible to
On Wednesday, 19 October 2022 at 01:38:27 UTC, Adam D Ruppe wrote:
On Wednesday, 19 October 2022 at 01:34:54 UTC, mw wrote:
Is there any (design) doc about this?
scroll up, click the link from this very thread.
On Wednesday, 19 October 2022 at 03:10:29 UTC, Mike Parker wrote:
It's right there in the summary of the Final Review of the DIP
that I linked above:
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md#final-review
I meant to say the summary of the formal assessment. One of
@mustuse as a function attribute was in the original version of
the DIP. It was vetoed by Walter. Thus, only the type attribute
remains in the accepted version.
Let's continue the discussion here:
https://forum.dlang.org/thread/nmornkxaxddfziqmq...@forum.dlang.org
in general, it's about:
On Wednesday, 19 October 2022 at 04:59:40 UTC, mw wrote:
...
Why can't do it `in one step`?
Why always afraid to `add features`?
C++ is `so complicated` ,but that people are not afraid to
continue to `add features`.
33 matches
Mail list logo
