On Monday, 16 November 2015 at 09:05:16 UTC, Marco Leise wrote:
Am Wed, 11 Nov 2015 14:23:15 +
schrieb Martin Nowak :
Think of that for a moment, no package manager allows you to
have cycles in your dependencies.
There are package managers that allow packages to mutually
depend on each ot
On Saturday, 14 November 2015 at 03:43:38 UTC, Walter Bright
wrote:
On 11/13/2015 9:23 AM, Johannes Pfau wrote:
Ellery filed a bug report and I've posted a reduced test case:
https://issues.dlang.org/show_bug.cgi?id=15324
Thank you!
https://issues.dlang.org/show_bug.cgi?id=15333
Also, than
On Wednesday, 11 November 2015 at 13:08:08 UTC, David Nadlinger
wrote:
...
Sorry I haven't read this whole thread so maybe this has been
mentioned before or not. I am not even sure if its really related
to this topic, but it seemed related to me so I figured I would
just post it here rather
Am Wed, 11 Nov 2015 14:23:15 +
schrieb Martin Nowak :
> Think of that for a moment, no package manager allows you to
> have cycles in your dependencies.
There are package managers that allow packages to mutually
depend on each other. Order is established by qualifying the
dependency similar t
On 11/13/2015 07:51 AM, Stefan wrote:
On Thursday, 12 November 2015 at 23:08:57 UTC, Jakob Ovrum wrote:
> [...dependency check...]
It can be implemented as an external tool with the -deps compiler switch.
there is depend [1].
It warns about cycles and unintended dependencies if you specif
On 11/13/2015 9:23 AM, Johannes Pfau wrote:
Ellery filed a bug report and I've posted a reduced test case:
https://issues.dlang.org/show_bug.cgi?id=15324
Thank you!
On 13/11/2015 8:26 PM, Robert burner Schadek wrote:
On Friday, 13 November 2015 at 02:50:07 UTC, Daniel Murphy wrote:
You also need to modify root/rmem.d to actually use the GC as the
allocator.
I should have known that it couldn't be that simple. Anyway, after doing
so. Building druntime and
Am Thu, 12 Nov 2015 15:15:24 -0800
schrieb Walter Bright :
> On 11/11/2015 5:47 AM, Johannes Pfau wrote:
> > Ellery Newcomer recently reported a template emission bug where
> > templates are emitted twice:
> > http://forum.dlang.org/thread/n1omke$1bh5$1...@digitalmars.com
>
> Please file bug re
On Wednesday, 11 November 2015 at 13:08:08 UTC, David Nadlinger
wrote:
Hi all,
Kenji and Walter have been working on improving the template
emission strategy during the last couple of releases, i.e.
whether a template instance is emitted to a given object file
or not. Nevertheless, I've been
On Wednesday, 11 November 2015 at 13:56:51 UTC, Martin Nowak
wrote:
On Wednesday, 11 November 2015 at 13:47:27 UTC, Johannes Pfau
wrote:
I think we should really fix these issues, working separate
compilation is very important.
No, it's not. Separate compilation is C++-ishly slow by design
(b
On Thursday, 12 November 2015 at 23:08:57 UTC, Jakob Ovrum wrote:
> [...dependency check...]
It can be implemented as an external tool with the -deps
compiler switch.
there is depend [1].
It warns about cycles and unintended dependencies if you specify
the target dependencies.
It helps us
On Friday, 13 November 2015 at 02:50:07 UTC, Daniel Murphy wrote:
You also need to modify root/rmem.d to actually use the GC as
the allocator.
I should have known that it couldn't be that simple. Anyway,
after doing so. Building druntime and phobos die with a segfault,
but all dmd tests pass,
I know what the problem is. Hence you need to import a in b and
b in a. There is not really anyway around this because this is
intrinsically how mixin works.
It could be all much easier if resolving aliases was controllable
in generic code, most importantly in regards of .stringof
On Friday, 13 November 2015 at 04:03:23 UTC, Walter Bright wrote:
On 11/12/2015 5:14 PM, deadalnix wrote:
module a;
struct S(E) {
import std.bitfield;
mixin(bitfield!(
bool, "flag", 1,
T, "myT", SizeOf!T,
uint, "", 32 - SizeOf!T - 1,
));
}
module b;
e
On 11/12/2015 5:14 PM, deadalnix wrote:
module a;
struct S(E) {
import std.bitfield;
mixin(bitfield!(
bool, "flag", 1,
T, "myT", SizeOf!T,
uint, "", 32 - SizeOf!T - 1,
));
}
module b;
enum MyEnum { Val1, Val2, Val3 }
import a;
alias UsefulStruct = S!M
On 12/11/2015 10:44 AM, Robert burner Schadek wrote:
I just run make -f posix.mak unittest -j10 on phobos after removing
GC.disable() from ddmd. It worked just fine. Everything build everything
passed the tests.
(the time program told 1:41.25 for nogc and 1:49.80 with gc. This is
with running a
On Friday, 13 November 2015 at 00:58:57 UTC, Walter Bright wrote:
On 11/12/2015 2:58 PM, deadalnix wrote:
You can have a template that
do mixin without creating loop because then you pass it down
identifiers that
won't resolve.
My brain seg faulted trying to parse that.
module a;
struct S
On 11/12/2015 2:58 PM, deadalnix wrote:
You can have a template that
do mixin without creating loop because then you pass it down identifiers that
won't resolve.
My brain seg faulted trying to parse that.
On 11/11/2015 5:47 AM, Johannes Pfau wrote:
Ellery Newcomer recently reported a template emission bug where
templates are emitted twice:
http://forum.dlang.org/thread/n1omke$1bh5$1...@digitalmars.com
Please file bug reports in bugzilla. Filing them in the n.g. means they will
most likely get o
On Thursday, 12 November 2015 at 22:50:08 UTC, Walter Bright
wrote:
I hadn't anticipated that code would inevitably be constructed
so that every module imports every other module.
One day, I was cleaning my house and found all kinds of the cat's
stuff under the couch. I wondered: why does the
On Thursday, 12 November 2015 at 22:50:08 UTC, Walter Bright
wrote:
On 11/11/2015 9:19 AM, David Nadlinger wrote:
Of course, many of the problems could have probably been
avoided if there was an
iron-clad rule that the module dependency graph must remain
acyclic from the
beginning of developmen
On Thursday, 12 November 2015 at 23:06:01 UTC, rsw0x wrote:
On Thursday, 12 November 2015 at 22:50:08 UTC, Walter Bright
wrote:
On 11/11/2015 9:19 AM, David Nadlinger wrote:
Of course, many of the problems could have probably been
avoided if there was an
iron-clad rule that the module dependenc
On Thursday, 12 November 2015 at 22:50:08 UTC, Walter Bright
wrote:
On 11/11/2015 9:19 AM, David Nadlinger wrote:
Of course, many of the problems could have probably been
avoided if there was an
iron-clad rule that the module dependency graph must remain
acyclic from the
beginning of developmen
On 11/11/2015 9:19 AM, David Nadlinger wrote:
Of course, many of the problems could have probably been avoided if there was an
iron-clad rule that the module dependency graph must remain acyclic from the
beginning of development (at least at the level of units of compilation).
In hindsight, I w
On 11/12/2015 5:38 AM, Andrei Alexandrescu wrote:
I notice you use a star - did you back off from the idea of defining C++'s
std::exception as an extern(C++) class (as opposed to an extern(C++) struct)? --
I just wanted to emphasize receiving it by reference rather than by value.
On Thursday, 12 November 2015 at 02:13:04 UTC, Martin Nowak wrote:
There shouldn't be anything quadratic left for template
instantiation in the frontend.
Maybe not for a single instantiation, but constructing the module
member list is overall still quadratic in the number of members
(which mi
On 11/12/2015 01:15 AM, Walter Bright wrote:
What D does need to do is support catching an std::exception*, or a
class derived from std::exception. I believe we are on solid ground in
not supporting any other C++ types being thrown.
Nor do I believe we need to catch C++ objects with catch(...).
On 11/11/2015 11:45 PM, Iain Buclaw via Digitalmars-d wrote:
> Nor do I believe we need to catch C++ objects with catch(...). Catching C++
objects will need an explicit catch(std.exception*).
>
Well, as demonstrated, that is the one thing that can be supported now for
free. Either by allowing
On 12 Nov 2015 7:15 am, "Walter Bright via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> On 11/11/2015 4:16 PM, Iain Buclaw via Digitalmars-d wrote:
>>
>> The main problem for seamless support is having some way to generate the
C++
>> typeinfo in D to allow work across boundaries.
>
>
>
On 12 Nov 2015 7:15 am, "Walter Bright via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> On 11/11/2015 4:16 PM, Iain Buclaw via Digitalmars-d wrote:
>>
>> The main problem for seamless support is having some way to generate the
C++
>> typeinfo in D to allow work across boundaries.
>
>
>
On 11/11/2015 4:45 PM, deadalnix wrote:
Ok I know Walter won't listen,
Does anyone else hear a buzzing sound? Or is my hearing aid on the fritz again?
On 11/11/2015 4:16 PM, Iain Buclaw via Digitalmars-d wrote:
The main problem for seamless support is having some way to generate the C++
typeinfo in D to allow work across boundaries.
I suspect that is unnecessary.
The whole point of D's C++ interface is to interface with C++ code. Defining C+
On Wednesday, 11 November 2015 at 17:19:31 UTC, David Nadlinger
wrote:
Of course, many of the problems could have probably been
avoided if there was an iron-clad rule that the module
dependency graph must remain acyclic from the beginning of
development (at least at the level of units of compil
On Wednesday, 11 November 2015 at 17:19:31 UTC, David Nadlinger
wrote:
Yes, there is a single cyclic inter-package dependency hidden
somewhere deep inside the dependency graph, but getting rid
of it after the fact would have either required re-structuring
large parts of a ˜10^5 LOC code base, or
On Wednesday, 11 November 2015 at 18:06:22 UTC, rsw0x wrote:
On Wednesday, 11 November 2015 at 13:56:51 UTC, Martin Nowak
wrote:
On Wednesday, 11 November 2015 at 13:47:27 UTC, Johannes Pfau
wrote:
I think we should really fix these issues, working separate
compilation is very important.
No,
On 11/11/2015 07:45 PM, deadalnix wrote:
This is definitively not impossible, but the cost benefit ratio is such
as I wouldn't prioritize this.
The way we see it is the benefit is all C++ interop. You can't really do
any meaningful interop whatsoever if you can't catch std::exception. --
Andr
On 11/11/2015 06:06 PM, Martin Nowak wrote:
On Wednesday, 11 November 2015 at 16:25:34 UTC, Andrei Alexandrescu wrote:
A redesign of template instantiation is necessary, and Walter needs to
be fully involved in it. However, please give it time.
I'd still opt to first refactor the existing code
On Wednesday, 11 November 2015 at 17:19:51 UTC, Iain Buclaw wrote:
Please no. I've done my fair share of investigating this in
libunwind, and it just isn't worth it.
Ok I know Walter won't listen, and I wouldn't be as radical as
Iain, but I concur. There are thing that can be done to improve
On 11 November 2015 at 19:02, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 11/11/2015 12:19 PM, Iain Buclaw via Digitalmars-d wrote:
>
>> On 11 November 2015 at 17:25, Andrei Alexandrescu via Digitalmars-d
>> mailto:digitalmars-d@puremagic.com>> wrote:
>>
>>
On Wednesday, 11 November 2015 at 23:44:04 UTC, Robert burner
Schadek wrote:
On Wednesday, 11 November 2015 at 13:47:27 UTC, Johannes Pfau
wrote:
A quick workaround could be enabling the GC for DDMD. IIRC I
read somewhere on github that the segfaulting code was
actually rewritten now and the GC
druntime also works with GC activated
On Wednesday, 11 November 2015 at 13:47:27 UTC, Johannes Pfau
wrote:
A quick workaround could be enabling the GC for DDMD. IIRC I
read somewhere on github that the segfaulting code was actually
rewritten now and the GC might just work.
I just run make -f posix.mak unittest -j10 on phobos after
On Wednesday, 11 November 2015 at 16:25:34 UTC, Andrei
Alexandrescu wrote:
A redesign of template instantiation is necessary, and Walter
needs to be fully involved in it. However, please give it time.
I'd still opt to first refactor the existing code into something
that's understandable before
On Wednesday, 11 November 2015 at 15:04:01 UTC, Andrei
Alexandrescu wrote:
Liran Zvibel […] mentioned the package-at-a-time solved
essentially all of their build problems.
They were stuck at 2.066 until very recently, though, because of
issues very similar to the one discussed here. Right now,
On Wednesday, 11 November 2015 at 18:02:01 UTC, Andrei
Alexandrescu wrote:
On 11/11/2015 12:13 PM, David Nadlinger wrote:
When was the last time you did "dmd -unittest -main $(find std
-name
'*.d')"? On current master, dmd takes just below 9 GiB to
complete the
build.
"Then don't do that". S
On Wednesday, 11 November 2015 at 13:56:51 UTC, Martin Nowak
wrote:
On Wednesday, 11 November 2015 at 13:47:27 UTC, Johannes Pfau
wrote:
I think we should really fix these issues, working separate
compilation is very important.
No, it's not. Separate compilation is C++-ishly slow by design
(b
On 11/11/2015 12:19 PM, Iain Buclaw via Digitalmars-d wrote:
On 11 November 2015 at 17:25, Andrei Alexandrescu via Digitalmars-d
mailto:digitalmars-d@puremagic.com>> wrote:
On 11/11/2015 08:08 AM, David Nadlinger wrote:
[snip]
Regarding the top-level issue. Walter and I agree it's a
On 11/11/2015 12:13 PM, David Nadlinger wrote:
On Wednesday, 11 November 2015 at 15:07:15 UTC, Andrei Alexandrescu wrote:
Phobos takes about 600MB max to build.
When was the last time you did "dmd -unittest -main $(find std -name
'*.d')"? On current master, dmd takes just below 9 GiB to comple
On Wednesday, 11 November 2015 at 17:19:51 UTC, Iain Buclaw wrote:
Please no. I've done my fair share of investigating this in
libunwind, and it just isn't worth it.
It isn't worth it, or you couldn't figure out how to? ;P
In other words, what I'm asking is: Yes, all the lifetime
management
On Wednesday, 11 November 2015 at 16:25:34 UTC, Andrei
Alexandrescu wrote:
Walter is currently working full time on catching C++
exceptions from D code […]
It would have sure been interesting to know about this, but I
couldn't find anything to that effect on the mailing lists or on
Trello – w
On Wednesday, 11 November 2015 at 15:04:01 UTC, Andrei
Alexandrescu wrote:
Yes, compiling package-at-a-time should be the mode endorsed by
the core community. Liran Zvibel and I discussed this privately
following his DConf 2015 talk, and I recall he mentioned the
package-at-a-time solved essent
On 11 November 2015 at 17:25, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 11/11/2015 08:08 AM, David Nadlinger wrote:
> [snip]
>
> Regarding the top-level issue. Walter and I agree it's an important
> problem, and also that plugging holes as they start leaking
On Wednesday, 11 November 2015 at 15:07:15 UTC, Andrei
Alexandrescu wrote:
Phobos takes about 600MB max to build.
When was the last time you did "dmd -unittest -main $(find std
-name '*.d')"? On current master, dmd takes just below 9 GiB to
complete the build.
Also, consider that many of th
On 11/11/2015 08:08 AM, David Nadlinger wrote:
[snip]
Regarding the top-level issue. Walter and I agree it's an important
problem, and also that plugging holes as they start leaking (which is
what we've been doing so far) is not going to work well in the long haul.
A redesign of template inst
Am 11.11.2015 um 15:15 schrieb Johannes Pfau:
I use docker hub to build docker images. One Dockerfile compiles one
small D tool which depends on vibe.d for JSON parsing. Without
separate compilation the build fails as docker hub kills the build
process, out of memory...
Sorry for OT: the lates
On Wednesday, 11 November 2015 at 13:56:51 UTC, Martin Nowak
wrote:
No, it's not. Separate compilation is C++-ishly slow by design
(b/c all dependencies get imported over and over again, just
like headers).
To a certain extent this is not true. As long as the amount
repeated work is not too b
On Wednesday, 11 November 2015 at 15:12:16 UTC, Adam D. Ruppe
wrote:
We, as a community, need to start believing people when they
say they are having troubles instead of blaming the customer
for doing it wrong.
+10_000
---
Paolo
On 11/11/15 10:12 AM, Adam D. Ruppe wrote:
We, as a community, need to start believing people when they say they
are having troubles instead of blaming the customer for doing it wrong.
Total agreement with that! -- Andrei
On Wednesday, 11 November 2015 at 14:31:54 UTC, Martin Nowak
wrote:
On Wednesday, 11 November 2015 at 14:15:54 UTC, Johannes Pfau
wrote:
Separate compilation works fine (and predictable) but is slow
(due to reparsing), you do need to link all objects from all
your sources though.
That's n
On Wednesday, 11 November 2015 at 15:04:01 UTC, Andrei
Alexandrescu wrote:
Yes, compiling package-at-a-time should be the mode endorsed by
the core community. Liran Zvibel and I discussed this privately
following his DConf 2015 talk, and I recall he mentioned the
package-at-a-time solved essent
On 11/11/15 9:15 AM, Johannes Pfau wrote:
Am Wed, 11 Nov 2015 13:56:50 +
schrieb Martin Nowak :
On Wednesday, 11 November 2015 at 13:47:27 UTC, Johannes Pfau
wrote:
I think we should really fix these issues, working separate
compilation is very important.
No, it's not. Separate compilati
On Wednesday, 11 November 2015 at 14:50:27 UTC, Johannes Pfau
wrote:
Anyway, I meant working _separate_ compilation is important,
incremental compilations is much less important for me. GDC
doesn't even support multiobj style compilation.
The particular issue I mentioned in the original post (
On Wednesday, 11 November 2015 at 14:31:54 UTC, Martin Nowak
wrote:
OK let's clarify the terminology first.
separate compilation: -c single_source.d
incremental compilation: -c source_a.d source_b.d (as well as
-c -ofsingle.o source_a.d source_b.d)
library compilation: -lib all_pkg_sources
Se
On 11/11/15 8:56 AM, Martin Nowak wrote:
On Wednesday, 11 November 2015 at 13:47:27 UTC, Johannes Pfau wrote:
I think we should really fix these issues, working separate
compilation is very important.
No, it's not. Separate compilation is C++-ishly slow by design (b/c all
dependencies get impo
On 11/11/15 9:14 AM, Daniel Kozak via Digitalmars-d wrote:
V Wed, 11 Nov 2015 13:56:50 +
Martin Nowak via Digitalmars-d napsáno:
On Wednesday, 11 November 2015 at 13:47:27 UTC, Johannes Pfau
wrote:
I think we should really fix these issues, working separate
compilation is very important.
Am Wed, 11 Nov 2015 14:31:53 +
schrieb Martin Nowak :
> On Wednesday, 11 November 2015 at 14:15:54 UTC, Johannes Pfau
> wrote:
> > And where do you draw the line? Do we expect ARM users to have
> > 4GB of RAM to compile phobos? Is 512MB enough? 64 MB? Even huge
> > C++ codebases such as GCC
On Wednesday, 11 November 2015 at 13:08:08 UTC, David Nadlinger
wrote:
Let's please make sure that we come out of this discussion with
some concrete actions to work on. Ideally you'd fill our backlog
with some stories, even if they are just research stories.
On Wednesday, 11 November 2015 at 14:26:28 UTC, Dicebot wrote:
I was referring to D packages, not dub packages.
Not much of a difference, compiling something separately that has
mutual dependencies is flawed but can be made working to some
extend.
On Wednesday, 11 November 2015 at 14:15:54 UTC, Johannes Pfau
wrote:
And where do you draw the line? Do we expect ARM users to have
4GB of RAM to compile phobos? Is 512MB enough? 64 MB? Even huge
C++ codebases such as GCC compile with 128MB memory.
OK let's clarify the terminology first.
sepa
On Wednesday, 11 November 2015 at 14:23:16 UTC, Martin Nowak
wrote:
On Wednesday, 11 November 2015 at 14:06:43 UTC, Dicebot wrote:
Note that many of template emission issues that affect "plain"
separate compilation are likely to affect package-based static
libraties as well, thus in context of
On Wednesday, 11 November 2015 at 14:06:43 UTC, Dicebot wrote:
Note that many of template emission issues that affect "plain"
separate compilation are likely to affect package-based static
libraties as well, thus in context of this thread distinction
is not very important.
Yes, you can get si
Am Wed, 11 Nov 2015 13:56:50 +
schrieb Martin Nowak :
> On Wednesday, 11 November 2015 at 13:47:27 UTC, Johannes Pfau
> wrote:
> > I think we should really fix these issues, working separate
> > compilation is very important.
>
> No, it's not. Separate compilation is C++-ishly slow by des
V Wed, 11 Nov 2015 13:56:50 +
Martin Nowak via Digitalmars-d napsáno:
> On Wednesday, 11 November 2015 at 13:47:27 UTC, Johannes Pfau
> wrote:
> > I think we should really fix these issues, working separate
> > compilation is very important.
>
> No, it's not. Separate compilation is C++-
On Wednesday, 11 November 2015 at 13:08:08 UTC, David Nadlinger
wrote:
We're well aware of the template problems and FWIW the most
important step is to simplify the current implementation (not the
rules).
http://forum.dlang.org/post/55f07e92.7040...@dawg.eu
Once that is done and we have a cle
On Wednesday, 11 November 2015 at 13:56:51 UTC, Martin Nowak
wrote:
On Wednesday, 11 November 2015 at 13:47:27 UTC, Johannes Pfau
wrote:
I think we should really fix these issues, working separate
compilation is very important.
No, it's not. Separate compilation is C++-ishly slow by design
(b
On Wednesday, 11 November 2015 at 13:47:27 UTC, Johannes Pfau
wrote:
I think we should really fix these issues, working separate
compilation is very important.
No, it's not. Separate compilation is C++-ishly slow by design
(b/c all dependencies get imported over and over again, just like
head
Am Wed, 11 Nov 2015 14:44:39 +0100
schrieb Johannes Pfau :
> Am Wed, 11 Nov 2015 13:08:06 +
> schrieb David Nadlinger :
>
> > Hi all,
> >
> > Kenji and Walter have been working on improving the template
> > emission strategy during the last couple of releases, i.e.
> > whether a template i
Am Wed, 11 Nov 2015 13:08:06 +
schrieb David Nadlinger :
> Hi all,
>
> Kenji and Walter have been working on improving the template
> emission strategy during the last couple of releases, i.e.
> whether a template instance is emitted to a given object file or
> not. Nevertheless, I've been
On Wednesday, 11 November 2015 at 13:08:08 UTC, David Nadlinger
wrote:
Hi all,
Nevertheless, I've been continually hearing complaints from
various people with large D code bases (our commercial users
and some of the more complex open source projects) that they
have problems compiling their co
Hi all,
Kenji and Walter have been working on improving the template
emission strategy during the last couple of releases, i.e.
whether a template instance is emitted to a given object file or
not. Nevertheless, I've been continually hearing complaints from
various people with large D code ba
80 matches
Mail list logo
