On 14/02/2011 12:37, Jacob Carlborg wrote:
On 2011-02-13 16:07, Gary Whatmore wrote:
Paulo Pinto Wrote:
"Nick Sabalausky" wrote in message
news:ij7v76$1q4t$1...@digitalmars.com...
... (cutted) ...
That's not the compiler, that's the linker. I don't know what linker
DMD
uses on OSX, but on Wi
On 13/02/2011 23:28, retard wrote:
Sun, 13 Feb 2011 15:06:46 -0800, Brad Roberts wrote:
On 2/13/2011 3:01 PM, Walter Bright wrote:
Michel Fortin wrote:
But note I was replying to your reply to Denis who asked specifically
for demangled names for missing symbols. This by itself would be a
usef
nedbrek wrote:
Hope that helps,
Thanks, this is great info!
"distcc" wrote in message news:ijp9ji$1hvd$1...@digitalmars.com...
> nedbrek Wrote:
>> "Walter Bright" wrote in message
>> news:ijnt3o$22dm$1...@digitalmars.com...
>>> nedbrek wrote:
Also, "macro op fusion" allows you can get a branch along with the last
instruction in decode, potentia
nedbrek Wrote:
> Hello,
>
> "Walter Bright" wrote in message
> news:ijnt3o$22dm$1...@digitalmars.com...
> > nedbrek wrote:
> >> Reordering happens in the scheduler. A simple model is "Fetch",
> >> "Schedule", "Retire". Fetch and retire are done in program order. For
> >> code that is hittin
Hello,
"Walter Bright" wrote in message
news:ijnt3o$22dm$1...@digitalmars.com...
> nedbrek wrote:
>> Reordering happens in the scheduler. A simple model is "Fetch",
>> "Schedule", "Retire". Fetch and retire are done in program order. For
>> code that is hitting well in the cache, the biggest
nedbrek wrote:
Reordering happens in the scheduler. A simple model is "Fetch", "Schedule",
"Retire". Fetch and retire are done in program order. For code that is
hitting well in the cache, the biggest bottleneck is that "4" decoder (the
complex instruction decoder). Reducing the number of co
Hello all,
"Walter Bright" wrote in message
news:ijeih9$2aso$2...@digitalmars.com...
> Don wrote:
>> That would really be fun.
>> BTW, the current Intel processors are basically the same as Pentium Pro,
>> with a few improvements. The strange thing is, because of all of the
>> reordering that
Don wrote:
Walter Bright wrote:
Don wrote:
In hand-coded asm, instruction scheduling still gives more than half
of the same benefit that it used to do. But, it's become ten times
more difficult. You have to use Agner Fog's manuals, not Intel/AMD.
For example:
(1) a common bottleneck on all I
retard wrote:
> Mon, 14 Feb 2011 20:10:47 +0100, Lutger Blijdestijn wrote:
>
>> retard wrote:
>>
>>> Mon, 14 Feb 2011 04:44:43 +0200, so wrote:
>>>
> Unfortunately DMC is always out of the question because the
> performance is 10-20 (years) behind competition, fast compilation
> won
bearophile wrote:
Walter:
Huh, I simply could never find a document about how to use those which gave me any
comfortable sense that the author knew what he was talking about.<
http://www.agner.org/optimize/
--
Don:
A problem with that, is that the prefetching instructions
Walter Bright wrote:
Don wrote:
In hand-coded asm, instruction scheduling still gives more than half
of the same benefit that it used to do. But, it's become ten times
more difficult. You have to use Agner Fog's manuals, not Intel/AMD.
For example:
(1) a common bottleneck on all Intel process
Walter:
>Huh, I simply could never find a document about how to use those which gave me
>any comfortable sense that the author knew what he was talking about.<
http://www.agner.org/optimize/
--
Don:
>A problem with that, is that the prefetching instructions are vendor-specific
On 02/15/2011 03:47 AM, bearophile wrote:
Don:
But still, cache effects are more important than instruction scheduling
in 99% of cases.
I agree.
CPUs have prefetching instructions, but D doesn't expose them as intrinsics. A
bit more higher level visibility for those instructions may be posit
On Mon, 14 Feb 2011 15:03:01 -0500, Steven Schveighoffer wrote:
> I think linker errors in general are one of those things that few people
> understand, and most cope with just pattern recognition "Oh, I see
> _deh_start, probably forgot main()" with no regards to logic. :)
Please get out of my
bearophile wrote:
I agree. CPUs have prefetching instructions, but D doesn't expose them as
intrinsics. A bit more higher level visibility for those instructions may be
positive today.
Huh, I simply could never find a document about how to use those which gave me
any comfortable sense that the
Don wrote:
In hand-coded asm, instruction scheduling still gives more than half of
the same benefit that it used to do. But, it's become ten times more
difficult. You have to use Agner Fog's manuals, not Intel/AMD.
For example:
(1) a common bottleneck on all Intel processors, is that you can o
bearophile wrote:
Don:
But still, cache effects are more important than instruction scheduling
in 99% of cases.
I agree.
CPUs have prefetching instructions, but D doesn't expose them as intrinsics. A
bit more higher level visibility for those instructions may be positive today.
A problem w
> Mon, 14 Feb 2011 13:00:00 -0800, Walter Bright wrote:
>
>
> How about [2]:
>
> "LTO is quite promising. Actually it is in line or even better with
> improvement got from other compilers (pathscale is the most convenient
> compiler to check lto separately: lto gave there upto 5% improvement
Don:
> But still, cache effects are more important than instruction scheduling
> in 99% of cases.
I agree.
CPUs have prefetching instructions, but D doesn't expose them as intrinsics. A
bit more higher level visibility for those instructions may be positive today.
Being D a system language, an
Walter Bright wrote:
retard wrote:
> There are no arch specific optimizations for PIII, Pentium 4, Pentium D,
Core, Core 2, Core i7, Core i7 2600K, and similar kinds of products from
AMD.
The optimal instruction sequences varied dramatically on those earlier
processors, but not so much at all
On 2/14/11 3:22 PM, retard wrote:
Your obsession with fast compile times is incomprehensible. It doesn't
have any relevance in the projects I'm talking about. On multicore 'make -
jN', distcc& low cost clusters, and incremental compilation already
mitigate most of the issues. LLVM is also suppo
retard wrote:
Mon, 14 Feb 2011 13:00:00 -0800, Walter Bright wrote:
In particular, instruction scheduling no longer seems to matter, except
for the Intel Atom, which benefits very much from Pentium style
instruction scheduling. Ironically, dmc++ is the only available current
compiler which supp
Mon, 14 Feb 2011 13:00:00 -0800, Walter Bright wrote:
> In particular, instruction scheduling no longer seems to matter, except
> for the Intel Atom, which benefits very much from Pentium style
> instruction scheduling. Ironically, dmc++ is the only available current
> compiler which supports that
Nick Sabalausky wrote:
If it isn't already, maybe all this should be mentioned on the D site.
Maybe you're right.
On 2011-02-14 21:43, Nick Sabalausky wrote:
"Jacob Carlborg" wrote in message
news:ijbtpv$61a$1...@digitalmars.com...
On 2011-02-13 23:38, spir wrote:
On 02/13/2011 10:35 PM, Nick Sabalausky wrote:
"spir" wrote in message
news:mailman.1602.1297626622.4748.digitalmar...@puremagic.com...
Als
"Walter Bright" wrote in message
news:ijc4fk$iv3$1...@digitalmars.com...
>
> I hear stuff about how dmc should catch up with LLVM and do modern things
> like data flow analysis, yet dmc has done data flow analysis since 1985. I
> also hear that dmc should do named return value optimization, not
retard wrote:
> There are no arch specific optimizations for PIII, Pentium 4, Pentium D,
Core, Core 2, Core i7, Core i7 2600K, and similar kinds of products from
AMD.
The optimal instruction sequences varied dramatically on those earlier
processors, but not so much at all on the later ones. Read
retard wrote:
Your obsession with fast compile times is incomprehensible.
Yet people complain about excessive compile times with C++ all the time, such as
overnight builds. Quite a few dmc++ customers stick with it because of compile
times.
It doesn't have any relevance in the projects I'
"Jacob Carlborg" wrote in message
news:ijbtpv$61a$1...@digitalmars.com...
> On 2011-02-13 23:38, spir wrote:
>> On 02/13/2011 10:35 PM, Nick Sabalausky wrote:
>>> "spir" wrote in message
>>> news:mailman.1602.1297626622.4748.digitalmar...@puremagic.com...
Also, I really miss a D for D l
Jacob Carlborg wrote:
Done: http://d.puremagic.com/issues/show_bug.cgi?id=5577
Thank you.
Mon, 14 Feb 2011 11:38:50 -0800, Walter Bright wrote:
> Lutger Blijdestijn wrote:
>> retard wrote:
>>
>>> Mon, 14 Feb 2011 04:44:43 +0200, so wrote:
>>>
> Unfortunately DMC is always out of the question because the
> performance is 10-20 (years) behind competition, fast compilation
>
Mon, 14 Feb 2011 20:10:47 +0100, Lutger Blijdestijn wrote:
> retard wrote:
>
>> Mon, 14 Feb 2011 04:44:43 +0200, so wrote:
>>
Unfortunately DMC is always out of the question because the
performance is 10-20 (years) behind competition, fast compilation
won't help it.
>>>
>>> Can y
On Mon, 14 Feb 2011 14:24:05 -0500, Andrej Mitrovic
wrote:
I think this void main() issue is blown out of proportion. They'll see
the error message once, and they won't know what it means. Ok.
But the second time, they'll know. No start address == no main. Maybe
the linker should just add an
retard wrote:
Mon, 14 Feb 2011 10:01:53 -0800, Walter Bright wrote:
retard wrote:
Mon, 14 Feb 2011 04:44:43 +0200, so wrote:
Unfortunately DMC is always out of the question because the
performance is 10-20 (years) behind competition, fast compilation
won't help it.
Can you please give a few
On 2011-02-14 19:07, Walter Bright wrote:
Jacob Carlborg wrote:
I agree with you here except for the last sentence. Please stop saying
it's ok just because it's ok in C/C++.
I bring that up because the thread started with the implication that D
was worse than C/C++ in this regard.
Fair enoug
On 2011-02-14 18:55, Walter Bright wrote:
Jacob Carlborg wrote:
On 2011-02-13 18:36, Andrej Mitrovic wrote:
Could you elaborate on that? Aren't .di files supposed to be
auto-generated by the compiler, and not hand-written?
Yes, but they don't always work.
Where they don't work, please file
Lutger Blijdestijn wrote:
retard wrote:
Mon, 14 Feb 2011 04:44:43 +0200, so wrote:
Unfortunately DMC is always out of the question because the performance
is 10-20 (years) behind competition, fast compilation won't help it.
Can you please give a few links on this?
What kind of proof you nee
Mon, 14 Feb 2011 10:01:53 -0800, Walter Bright wrote:
> retard wrote:
>> Mon, 14 Feb 2011 04:44:43 +0200, so wrote:
>>
Unfortunately DMC is always out of the question because the
performance is 10-20 (years) behind competition, fast compilation
won't help it.
>>> Can you please giv
I think this void main() issue is blown out of proportion. They'll see
the error message once, and they won't know what it means. Ok.
But the second time, they'll know. No start address == no main. Maybe
the linker should just add another line saying that you might be
missing main, and that's it.
retard wrote:
> Mon, 14 Feb 2011 04:44:43 +0200, so wrote:
>
>>> Unfortunately DMC is always out of the question because the performance
>>> is 10-20 (years) behind competition, fast compilation won't help it.
>>
>> Can you please give a few links on this?
>
> What kind of proof you need then?
On 02/14/2011 06:54 PM, Steven Schveighoffer wrote:
On Sun, 13 Feb 2011 14:12:02 -0500, Walter Bright
wrote:
Vladimir Panteleev wrote:
On Sun, 13 Feb 2011 20:26:50 +0200, Walter Bright
wrote:
golgeliyele wrote:
I don't think C++ and gcc set a good bar here.
Short of writing our own link
On 2011-02-14 00:01, Walter Bright wrote:
Michel Fortin wrote:
But note I was replying to your reply to Denis who asked specifically
for demangled names for missing symbols. This by itself would be a
useful improvement.
I agree with that, but there's a caveat. I did such a thing years ago
for
On 2011-02-14 00:28, retard wrote:
Sun, 13 Feb 2011 15:06:46 -0800, Brad Roberts wrote:
On 2/13/2011 3:01 PM, Walter Bright wrote:
Michel Fortin wrote:
But note I was replying to your reply to Denis who asked specifically
for demangled names for missing symbols. This by itself would be a
usef
On 2011-02-13 23:38, spir wrote:
On 02/13/2011 10:35 PM, Nick Sabalausky wrote:
"spir" wrote in message
news:mailman.1602.1297626622.4748.digitalmar...@puremagic.com...
Also, I really miss a D for D lexical- syntactic- semantic- analyser
that
would produce D data structures. This would open th
On Mon, 14 Feb 2011 13:24:26 -0500, Walter Bright
wrote:
Steven Schveighoffer wrote:
On Sun, 13 Feb 2011 14:12:02 -0500, Walter Bright
wrote:
Vladimir Panteleev wrote:
On Sun, 13 Feb 2011 20:26:50 +0200, Walter Bright
wrote:
golgeliyele wrote:
I don't think C++ and gcc set a good
On 2011-02-13 20:49, Lutger Blijdestijn wrote:
gölgeliyele wrote:
...
I think what we need here is numbers from a project that everyone has
access to. What is the largest D project right now? Can we get numbers on
that? How much time does it take to compile that project after a change
(assuming
Steven Schveighoffer wrote:
On Sun, 13 Feb 2011 14:12:02 -0500, Walter Bright
wrote:
Vladimir Panteleev wrote:
On Sun, 13 Feb 2011 20:26:50 +0200, Walter Bright
wrote:
golgeliyele wrote:
I don't think C++ and gcc set a good bar here.
Short of writing our own linker, we're a bit stuck
Jacob Carlborg wrote:
I agree with you here except for the last sentence. Please stop saying
it's ok just because it's ok in C/C++.
I bring that up because the thread started with the implication that D was worse
than C/C++ in this regard.
Andrej Mitrovic wrote:
I've no idea. But Optlink actually has a switch you can use to disable
outputting corrupt executables. I've no idea what the use case for
this is.
It's from the olden days where you could use optlink to create all sorts of
specialized binary files, such as ones you'll be
retard wrote:
Mon, 14 Feb 2011 04:44:43 +0200, so wrote:
Unfortunately DMC is always out of the question because the performance
is 10-20 (years) behind competition, fast compilation won't help it.
Can you please give a few links on this?
What kind of proof you need then? Just take some exis
Lutger Blijdestijn wrote:
Let me take the opportunity to say I care about an unrelated usability
feature: the spelling suggestion. However small it's pretty nice so thanks
for doing that.
I like that one too, I liked it so much I wired it into dmc++ as well!
Jacob Carlborg wrote:
On 2011-02-13 18:36, Andrej Mitrovic wrote:
Could you elaborate on that? Aren't .di files supposed to be
auto-generated by the compiler, and not hand-written?
Yes, but they don't always work.
Where they don't work, please file bug reports to bugzilla.
On Sun, 13 Feb 2011 14:12:02 -0500, Walter Bright
wrote:
Vladimir Panteleev wrote:
On Sun, 13 Feb 2011 20:26:50 +0200, Walter Bright
wrote:
golgeliyele wrote:
I don't think C++ and gcc set a good bar here.
Short of writing our own linker, we're a bit stuck with what ld does.
That's
On 2011-02-13 20:12, Walter Bright wrote:
Vladimir Panteleev wrote:
On Sun, 13 Feb 2011 20:26:50 +0200, Walter Bright
wrote:
golgeliyele wrote:
I don't think C++ and gcc set a good bar here.
Short of writing our own linker, we're a bit stuck with what ld does.
That's not true. The compil
On 2011-02-13 19:42, Vladimir Panteleev wrote:
On Sun, 13 Feb 2011 20:26:50 +0200, Walter Bright
wrote:
golgeliyele wrote:
I don't think C++ and gcc set a good bar here.
Short of writing our own linker, we're a bit stuck with what ld does.
That's not true. The compiler has knowledge of wh
On 2/14/11, Don wrote:
>
> Why is that a "warning"?
> Why on earth does it create a corrupt exe file, instead of reporting an
> error???
>
I've no idea. But Optlink actually has a switch you can use to disable
outputting corrupt executables. I've no idea what the use case for
this is.
Mon, 14 Feb 2011 04:44:43 +0200, so wrote:
>> Unfortunately DMC is always out of the question because the performance
>> is 10-20 (years) behind competition, fast compilation won't help it.
>
> Can you please give a few links on this?
What kind of proof you need then? Just take some existing pie
Andrej Mitrovic wrote:
Don't forget DLLs.
But why not just change the linker error message from:
OPTLINK : Warning 134: No Start Address
to:
OPTLINK : Warning 134: No Start Address
"Are you missing a main() function?"
Why is that a "warning"?
Why on earth does it create a corrupt exe file, in
Don't forget DLLs.
But why not just change the linker error message from:
OPTLINK : Warning 134: No Start Address
to:
OPTLINK : Warning 134: No Start Address
"Are you missing a main() function?"
On Sun, 13 Feb 2011 21:12:02 +0200, Walter Bright
wrote:
Vladimir Panteleev wrote:
On Sun, 13 Feb 2011 20:26:50 +0200, Walter Bright
wrote:
golgeliyele wrote:
I don't think C++ and gcc set a good bar here.
Short of writing our own linker, we're a bit stuck with what ld does.
That's
Walter Bright wrote:
> Michel Fortin wrote:
>> But note I was replying to your reply to Denis who asked specifically
>> for demangled names for missing symbols. This by itself would be a
>> useful improvement.
>
> I agree with that, but there's a caveat. I did such a thing years ago for
> C++ and
On 2011-02-13 18:36, Andrej Mitrovic wrote:
On 2/13/11, Alan Smithee wrote:
You can do the same in D using .di files.
Except no one really does that because such an approach is insanely
error prone. E.g. with classes, you need to copy entire definitions.
Change any ordering, forget a field, c
On 2011-02-13 18:19, golgeliyele wrote:
p.s.: Does anyone know what the best way to use this newsgroup is? Is there a
better web interface? If not, is there a free
newsgroup (on a Mac) reader that is easy to use?
I'm using Thunderbird.
--
/Jacob Carlborg
On 2011-02-13 13:24, Nick Sabalausky wrote:
"Peter Alexander" wrote in message
news:ij8a8p$2gqv$1...@digitalmars.com...
On 13/02/11 10:10 AM, Peter Alexander wrote:
On 13/02/11 6:52 AM, Nick Sabalausky wrote:
D compiles a few orders of magnitude faster than C++ does. Better
handling
of increm
On 2011-02-13 16:07, Gary Whatmore wrote:
Paulo Pinto Wrote:
"Nick Sabalausky" wrote in message
news:ij7v76$1q4t$1...@digitalmars.com...
... (cutted) ...
That's not the compiler, that's the linker. I don't know what linker DMD
uses on OSX, but on Windows it uses OPTLINK which is written in
h
On 02/14/2011 02:29 AM, Denis Koroskin wrote:
On Mon, 14 Feb 2011 02:01:53 +0300, Walter Bright
wrote:
Michel Fortin wrote:
But note I was replying to your reply to Denis who asked specifically for
demangled names for missing symbols. This by itself would be a useful
improvement.
I agree wi
golgeliyele wrote:
I am relatively new to D. As a long time C++ coder, I love D. Recently, I have
started doing some coding with D. One of the things that
bothered me was the 'perceived' quality of the tooling. There are some
relatively minor things that make the tooling look bad.
The error
On Sun, 13 Feb 2011 19:47:30 +0200, Alan Smithee wrote:
Gary Whatmore Wrote (fixed that for you):
Let's try to act reasonable here. Walter fanboyism is already
getting old and sadly favored by our famous NG trolls, that is
pretty much everyone here. I wouldn't be shocked to hear this Gary
What
Sorry this was a completely unintentional error --- I meant to say "in case
anyone
doubts Gary's post". Blame the lateness of the night and/or my annoyingly lossy
wireless keyboard.
Kevin
> our famous Reddit trolls, that is retard = uriel = eternium = lurker
In case anyone doubts gay's guess... for those who don't follow entertainment
trivia, Alan Smithee is a pseudonym used by directors disowning a film (google
it). So anyone using this name is actually effectively *claiming* to
On 2/13/11 2:05 PM, Walter Bright wrote:
golgeliyele wrote:
2. dmd compiler's command line options:
This is mostly an esthetic issue. However, it is like the entrance to
your house. People who are not sure about entering in
care about what it looks like from the outside. If Walter is willing,
Unfortunately DMC is always out of the
question because the performance is 10-20 behind competition, fast
compilation won't help it.
Can you please give a few links on this?
Denis Koroskin wrote:
On Mon, 14 Feb 2011 02:01:53 +0300, Walter Bright
wrote:
Michel Fortin wrote:
But note I was replying to your reply to Denis who asked specifically
for demangled names for missing symbols. This by itself would be a
useful improvement.
I agree with that, but there's a
On Mon, 14 Feb 2011 02:01:53 +0300, Walter Bright
wrote:
Michel Fortin wrote:
But note I was replying to your reply to Denis who asked specifically
for demangled names for missing symbols. This by itself would be a
useful improvement.
I agree with that, but there's a caveat. I did such
Sun, 13 Feb 2011 15:06:46 -0800, Brad Roberts wrote:
> On 2/13/2011 3:01 PM, Walter Bright wrote:
>> Michel Fortin wrote:
>>> But note I was replying to your reply to Denis who asked specifically
>>> for demangled names for missing symbols. This by itself would be a
>>> useful improvement.
>>
>>
On 2/13/2011 3:01 PM, Walter Bright wrote:
> Michel Fortin wrote:
>> But note I was replying to your reply to Denis who asked specifically for
>> demangled names for missing symbols. This by
>> itself would be a useful improvement.
>
> I agree with that, but there's a caveat. I did such a thing y
Michel Fortin wrote:
But note I was replying to your reply to Denis who asked specifically
for demangled names for missing symbols. This by itself would be a
useful improvement.
I agree with that, but there's a caveat. I did such a thing years ago for C++
and Optlink. Nobody cared, including
On 2011-02-13 16:37:19 -0500, Walter Bright said:
Michel Fortin wrote:
Parsing error messages is a problem indeed. But demangling symbol names
is easy.
Demangling doesn't get us where golgeliyele wants to go.
Correct.
But note I was replying to your reply to Denis who asked specifically
On Sun, Feb 13, 2011 at 4:35 PM, Alan Smithee wrote:
> Nick Sabalausky Wrote:
>
>> "Perhaps"? Well, is it or isn't it? Are we supposed to just assume
> that lack of use means it's actually broken and not just unpopular?
>
> Assume it's broken or demonstrate large projects written in D to
> show th
Agreed. These things might make D appear like less of a joke, thus
attracting more hapless users to their subsequent dismay.
On 02/13/2011 10:35 PM, Nick Sabalausky wrote:
"spir" wrote in message
news:mailman.1602.1297626622.4748.digitalmar...@puremagic.com...
Also, I really miss a D for D lexical- syntactic- semantic- analyser that
would produce D data structures. This would open the door hoards of
projects, includ
Nick Sabalausky Wrote:
> "Perhaps"? Well, is it or isn't it? Are we supposed to just assume
that lack of use means it's actually broken and not just unpopular?
Assume it's broken or demonstrate large projects written in D to
show that it CAN be unpopular because something else makes up for
it.
>
Michel Fortin wrote:
Parsing error messages is a problem indeed. But demangling symbol names
is easy.
Demangling doesn't get us where golgeliyele wants to go.
"spir" wrote in message
news:mailman.1602.1297626622.4748.digitalmar...@puremagic.com...
>
> Also, I really miss a D for D lexical- syntactic- semantic- analyser that
> would produce D data structures. This would open the door hoards of
> projects, including tool chain elements, meta-studies on
"Alan Smithee" wrote in message
news:ij967s$12rb$1...@digitalmars.com...
> Andrej Mitrovic Wrote:
>
>> Could you elaborate on that? Aren't .di files supposed to be auto-
> generated by the compiler, and not hand-written?
>
> Yea, aren't they? How come no one uses that feature? Perhaps it's
> intr
Hi,
this is what I miss in D and Go.
Most developers that only used C and C++ aren't aware how easy it is to
compile applications in more
modern languages.
It is funny that both D and Go advertise their compilation speed, when I was
used to fast compilation since
the MS-DOS days with Turbo Pas
Hi,
now I am conviced. Thanks for the explanation.
--
Paulo
"Walter Bright" wrote in message
news:ij99gb$18fm$1...@digitalmars.com...
> Paulo Pinto wrote:
>> Why C and not directly D?
>>
>> It is really bad adversting for D to know that when its creator came
>> around to rewrite the linker, W
On 02/13/2011 08:30 PM, Walter Bright wrote:
1. people just check out when they see pages and pages of wacky switches. Has
anyone ever actually read all of man gcc?
+ 12_000 /lines/ in my version
Denis
--
_
vita es estrany
spir.wikidot.com
On 2011-02-13 14:38:20 -0500, Walter Bright said:
Denis Koroskin wrote:
It's not impossible, but is a tremendous amount of work in order to
improve one error message, and one error message that generations of C
and C++ programmers are comfortable dealing with.
What's wrong with parsing low-
On 02/13/2011 07:53 PM, Walter Bright wrote:
Paulo Pinto wrote:
Why C and not directly D?
It is really bad adversting for D to know that when its creator came around
to rewrite the linker, Walter decided to use C instead of D.
That's a very good question.
The answer is in the technical detai
On 02/13/2011 04:07 PM, Gary Whatmore wrote:
his might sound like blasphemy, but I believe the skills and knowledge for
developing large scale applications in language XYZ cannot be extrapolated from
small code snippets or from experience with projects in other languages. You
just need to eat
gölgeliyele wrote:
...
>
> I think what we need here is numbers from a project that everyone has
> access to. What is the largest D project right now? Can we get numbers on
> that? How much time does it take to compile that project after a change
> (assuming we are feeding all .d files at once)?
Denis Koroskin wrote:
It's not impossible, but is a tremendous amount of work in order to
improve one error message, and one error message that generations of C
and C++ programmers are comfortable dealing with.
What's wrong with parsing low-level linker error messages and output
them in human
On Sun, 13 Feb 2011 22:12:02 +0300, Walter Bright
wrote:
Vladimir Panteleev wrote:
On Sun, 13 Feb 2011 20:26:50 +0200, Walter Bright
wrote:
golgeliyele wrote:
I don't think C++ and gcc set a good bar here.
Short of writing our own linker, we're a bit stuck with what ld does.
That's
bearophile wrote:
Walter:
With D, the D compiler will create ModuleInfo and TypeInfo objects, which
more or less rely on some sort of D runtime existing.
In LDC there are no_typeinfo (and in maybe no_moduleinfo) pragmas to disable
the generation of those for specific types/modules:
http://ww
gölgeliyele wrote:
Walter Bright wrote:
golgeliyele wrote:
1. Difficult to understand linker errors due to missing main():
...
The problem is the main() can come from a library, or some other .obj file
handed to the compiler that the compiler doesn't look inside. It's a very
flexible way t
Walter:
> With D, the D compiler will create ModuleInfo and TypeInfo objects,
> which more or less rely on some sort of D runtime existing.
In LDC there are no_typeinfo (and in maybe no_moduleinfo) pragmas to disable
the generation of those for specific types/modules:
http://www.dsource.org/proj
Daniel Gibson wrote:
> Am 13.02.2011 20:01, schrieb gölgeliyele:
>> I don't think
>> supporting multiple compilation models is a good thing.
>>
>
> I think incremental compilation is a very useful feature for large projects so
> it should be available.
> Also the possibility to link in .o fi
On 02/13/2011 01:59 PM, bearophile wrote:
Walter:
In C++, you get essentially the same thing from g++:
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crt1.o: In function
`_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
Lot of people come here be
1 - 100 of 148 matches
Mail list logo
