On 7/4/2018 10:22 AM, H. S. Teoh wrote:
Actually, what will make dmd produce better code IMO is: (1) a more
aggressive metric for the inliner (currently it gives up too easily, at
the slightest increase in code complexity), and (2) implement loop
unrolling.
It's already doing some loop unrollin
On 7/3/2018 4:03 PM, H. S. Teoh wrote:
Hopefully this eventually translates to actual improvements to the
optimizer?
That's the plan. D code is a lot more malleable than C++.
On 06/27/2018 12:00 PM, Mario Silva wrote:
Hello,
Our code base has been growing steadily and it's currently at a point
where my 16GB machine just freezes when we're compiling our code. This
happens because DMD just consumes all my memory for a while.
Also, it's taking a long time to compile
On 2018-07-02 04:15, Seb wrote:
Shared libraries are working fine on Linux and OSX.
For macOS LDC is required.
--
/Jacob Carlborg
On 2018-06-27 18:00, Mario Silva wrote:
Hello,
Our code base has been growing steadily and it's currently at a point
where my 16GB machine just freezes when we're compiling our code. This
happens because DMD just consumes all my memory for a while.
Also, it's taking a long time to compile it
On 05/07/2018 5:22 AM, H. S. Teoh wrote:
If we can nail down these two things, I think dmd's codegen quality
should improve significantly.
Not disagreeing with your assessment. But that is a lot of work, so why
not try out a 'free' experiment as an addition? Just for interests sake.
On Thu, Jul 05, 2018 at 04:55:09AM +1200, rikki cattermole via Digitalmars-d
wrote:
> On 05/07/2018 4:06 AM, jmh530 wrote:
> > On Tuesday, 3 July 2018 at 23:05:00 UTC, rikki cattermole wrote:
> > >
> > > On that note, I have a little experiment that I'd like to see
> > > done. How would the code
On 05/07/2018 4:06 AM, jmh530 wrote:
On Tuesday, 3 July 2018 at 23:05:00 UTC, rikki cattermole wrote:
On that note, I have a little experiment that I'd like to see done.
How would the codegen change, if you were to triple the time the
optimizer had to run?
Would it make any difference to com
On Tuesday, 3 July 2018 at 23:05:00 UTC, rikki cattermole wrote:
On that note, I have a little experiment that I'd like to see
done.
How would the codegen change, if you were to triple the time
the optimizer had to run?
Would it make any difference to compile DMD with LDC?
On Wednesday, July 04, 2018 11:50:07 Steven Schveighoffer via Digitalmars-d
wrote:
> The obvious pros to ditching package.d and using a directory and module
> with the same name are: 1. no ambiguity in the filesystem (assuming you
> don't have weird package/file schemes) and 2. It's more understan
On 7/4/18 11:29 AM, Jonathan M Davis wrote:
On Wednesday, July 04, 2018 11:13:07 Steven Schveighoffer via Digitalmars-d
wrote:
I think if we went the different route we would have to provide a
mechanism to declare inside the module "this is a package". Maybe
"package module"?
I would point out
On Wednesday, July 04, 2018 11:13:07 Steven Schveighoffer via Digitalmars-d
wrote:
> I think if we went the different route we would have to provide a
> mechanism to declare inside the module "this is a package". Maybe
> "package module"?
I would point out that the pretty much the only reason tha
On 7/4/18 11:06 AM, aliak wrote:
On Wednesday, 4 July 2018 at 14:54:41 UTC, Steven Schveighoffer wrote:
On 7/1/18 7:36 AM, Yuxuan Shui wrote:
In Rust, they have something call mod.rs, which is very similar to
package.d. When you use a module 'foo' in Rust, it can either be
'foo.rs' or 'foo/mod
On 7/4/18 10:59 AM, Adam D. Ruppe wrote:
On Wednesday, 4 July 2018 at 14:54:41 UTC, Steven Schveighoffer wrote:
How would this affect the package attribute?
Nothing should change, since packages are determined from the D module
declaration, not the filename or directory layout.
This is even
On Wednesday, 4 July 2018 at 14:54:41 UTC, Steven Schveighoffer
wrote:
On 7/1/18 7:36 AM, Yuxuan Shui wrote:
In Rust, they have something call mod.rs, which is very
similar to package.d. When you use a module 'foo' in Rust, it
can either be 'foo.rs' or 'foo/mod.rs'. If 'foo' has
sub-modules, i
On Wednesday, 4 July 2018 at 14:54:41 UTC, Steven Schveighoffer
wrote:
How would this affect the package attribute?
Nothing should change, since packages are determined from the D
module declaration, not the filename or directory layout.
This is even true with package.d itself, but it is a w
On 7/1/18 7:36 AM, Yuxuan Shui wrote:
In Rust, they have something call mod.rs, which is very similar to
package.d. When you use a module 'foo' in Rust, it can either be
'foo.rs' or 'foo/mod.rs'. If 'foo' has sub-modules, it has to be
'foo/mod.rs'.
Now in the Rust 2018 edition, they are getti
On 24.06.2018 13:27, Basile B. wrote:
FYI this works fine, as expected it's just some small parser changes.
I didn't touch to for and foreach for now. I think that SwitchStatement
is a candidate too.
https://github.com/BBasile/dmd/commit/5455a65c8fdee5a6d198782d1f168906b59e6d3d
if (a+b)*c =
On Wednesday, 4 July 2018 at 10:47:12 UTC, Jonathan M Davis wrote:
At this point, to operate on anything that's shared, either
means using atomics or protecting the data with a mutex (be
that with a synchronized block / function or a mutex object)
and temporarily casting away shared while opera
On Wednesday, July 04, 2018 09:25:27 Boris-Barboris via Digitalmars-d wrote:
> Given the pain of shared usage with std and pretty much every
> library in existence, I cowboyed the server without this
> qualifier. One of the mechanisms required atomic class reference
> compare-and-set, and the class
Given the pain of shared usage with std and pretty much every
library in existence, I cowboyed the server without this
qualifier. One of the mechanisms required atomic class reference
compare-and-set, and the class reference is not shared, because
it would otherwise require, like, 30 or 40 cast
On Sunday, 1 July 2018 at 11:36:51 UTC, Yuxuan Shui wrote:
In Rust, they have something call mod.rs, which is very similar
to package.d. When you use a module 'foo' in Rust, it can
either be 'foo.rs' or 'foo/mod.rs'. If 'foo' has sub-modules,
it has to be 'foo/mod.rs'.
Now in the Rust 2018 ed
On Monday, 2 July 2018 at 20:28:06 UTC, Seb wrote:
On Sunday, 1 July 2018 at 12:02:03 UTC, Nick Treleaven wrote:
On Sunday, 24 June 2018 at 23:40:56 UTC, Timoses wrote:
The others may be rewritten to not have a leading "!" as
well, e.g.
if (!(t1.ty == Tarray && t2.ty == Tarray &&
needsDirect
On Saturday, 23 June 2018 at 04:45:07 UTC, user1234 wrote:
There is this case that requires parens:
if a && b c;
Is there a missing && or not ? It seems obvious for a human but
compiler parsers are "apparatchiks", i.e rules are rules. That
being said this would work by allowing parens for
24 matches
Mail list logo
