I took a random medium-sized xml :)
By the way for this test I downloaded it:
http://www.ollie10.it/file.axd?file=2010%2f4%
2fDatabase_Comuni_Italiani_2010.zip (folder /xml/Cities.xml)
Il giorno mer, 18/01/2012 alle 18.28 +0100, Martin Nowak ha scritto:
> > try this code using a long xml file (t
Am 18.01.2012, 16:35 Uhr, schrieb Jacob Carlborg :
How about DMD passing --export-dynamic to GCC if -shared is passed to
DMD?
--export-dynamic is required for the symbol names in exception back traces
and comes from dmd.conf. That said, you can remove it there and enable it
only for debug
On 1/18/2012 11:38 PM, Jacob Carlborg wrote:
On 2012-01-19 01:29, Walter Bright wrote:
On 1/18/2012 4:03 PM, Patrick Stewart wrote:
I am sorry to see many D community projects and libraries dead as they
are
targeted for D1 and not portable to D2, or just locked to specific
version of
D and not
On 15 January 2012 19:42, Kiith-Sa <4...@theanswer.com> wrote:
> I'm interested in game development using D, so I'll post my opinion.
>
> I think the discussions here show how particularly specialized people
> here are. I've seen some Manu's posts and it was clear that he is a person
> in gamedev
On 16 January 2012 02:23, Andrei Alexandrescu wrote:
> I do have ties with the gaming community; I taught a course at ENDI and I
> am well acquainted with a few game developers. Also, at conferences and
> events gaming programmers are represented. Finally, game developers who are
> reading TDPL a
Walter Bright Wrote:
> On 1/18/2012 4:03 PM, Patrick Stewart wrote:
> > I am sorry to see many D community projects and libraries dead as they are
> > targeted for D1 and not portable to D2, or just locked to specific version
> > of
> > D and not transferable to latest version due some bug.
>
>
On 1/19/2012 2:06 AM, Patrick Stewart wrote:
Long story short - I find new things added and premature optimizations The
worst enemy of language at the moment. They might look like selling point to
you, to me they look like distractions from fixing D's shaking legs and
solving some real problems u
Walter Bright Wrote:
> On 1/19/2012 2:06 AM, Patrick Stewart wrote:
> > Long story short - I find new things added and premature optimizations The
> > worst enemy of language at the moment. They might look like selling point to
> > you, to me they look like distractions from fixing D's shaking leg
I tried different versions of DMD 2.057:
- compiled from sources in the release zip (Gentoo ebuild)
- using the 32-bit binaries in the release zip
- compiling the latest 32-bit version of DMD from the repository
I tried different compiler flags or no flags at all, compiled similar code
in C++ to
P.S.: I could have realized it earlier: DMD uses the Windows PE BSS
section quite well! It is Linux where the .bss section is not used! I'll
file a bug report about this after lunch and look forward to smaller
executables under Linux any time soon :D
On 2012-01-19 11:11, Walter Bright wrote:
On 1/19/2012 2:06 AM, Patrick Stewart wrote:
Long story short - I find new things added and premature optimizations
The
worst enemy of language at the moment. They might look like selling
point to
you, to me they look like distractions from fixing D's sh
On 19/01/12 12:51 AM, Timon Gehr wrote:
On 01/19/2012 01:41 AM, Peter Alexander wrote:
On 18/01/12 12:52 AM, Timon Gehr wrote:
On 01/18/2012 01:40 AM, Jonathan M Davis wrote:
On Tuesday, January 17, 2012 19:31:25 bearophile wrote:
Nick Sabalausky:
Without properties, member function access *
On Wednesday, 18 January 2012 at 23:09:56 UTC, Timon Gehr wrote:
On 01/18/2012 10:12 PM, jdrewsen wrote:
On Wednesday, 18 January 2012 at 20:13:04 UTC, Timon Gehr
wrote:
On 01/18/2012 08:59 PM, jdrewsen wrote:
On Wednesday, 18 January 2012 at 19:43:52 UTC, Timon Gehr
wrote:
On 01/18/2012 08:3
On 1/17/12 8:29 PM, Andrei Alexandrescu wrote:
On 1/17/12 5:13 PM, Peter Alexander wrote:
On 17/01/12 10:11 PM, Jonathan M Davis wrote:
You would need to come up with some really solid arguments why it
should be
thrown out (and what we should do instead) and get both Walter and
Andrei (if
not t
On 1/19/12 3:25 AM, Manu wrote:
On 16 January 2012 02:23, Andrei Alexandrescu
mailto:seewebsiteforem...@erdani.org>>
wrote:
I do have ties with the gaming community; I taught a course at ENDI
and I am well acquainted with a few game developers. Also, at
conferences and events gaming
On 01/19/2012 03:47 PM, jdrewsen wrote:
On Wednesday, 18 January 2012 at 23:09:56 UTC, Timon Gehr wrote:
On 01/18/2012 10:12 PM, jdrewsen wrote:
On Wednesday, 18 January 2012 at 20:13:04 UTC, Timon Gehr wrote:
On 01/18/2012 08:59 PM, jdrewsen wrote:
On Wednesday, 18 January 2012 at 19:43:52 U
On Thursday, January 19, 2012 14:59:54 Jacob Carlborg wrote:
> On 2012-01-19 11:11, Walter Bright wrote:
> > On 1/19/2012 2:06 AM, Patrick Stewart wrote:
> >> Long story short - I find new things added and premature optimizations
> >> The
> >> worst enemy of language at the moment. They might look
> On 1/18/2012 2:15 PM, Adam Wilson wrote:
> > [...] There are 2719 open issues in the
> > bugtracker; that number alone will scare off many potential users.
Walter Bright Wrote:
> Take a look at the changelog. I just don't see how anyone could conclude that
> is
> not exactly what we are doin
On 17.01.2012 07:48, Andrei Alexandrescu wrote:
I hate I must ask this:
int[string] aa;
foreach (k; aa.byKey) { ... }
or
int[string] aa;
foreach (k; aa.byKey()) { ... }
For it to be a property, I think you should be able to simplify this
example:
---
auto k = aa.byKey;
writeln(k.front);
On 19.01.2012 18:19, torhu wrote:
On 17.01.2012 07:48, Andrei Alexandrescu wrote:
I hate I must ask this:
int[string] aa;
foreach (k; aa.byKey) { ... }
or
int[string] aa;
foreach (k; aa.byKey()) { ... }
For it to be a property, I think you should be able to simplify this
example:
--
I agree 100% with this, must say, beautifully written essay.
On 1/19/12 11:19 AM, torhu wrote:
On 17.01.2012 07:48, Andrei Alexandrescu wrote:
I hate I must ask this:
int[string] aa;
foreach (k; aa.byKey) { ... }
or
int[string] aa;
foreach (k; aa.byKey()) { ... }
For it to be a property, I think you should be able to simplify this
example:
---
auto
On 19.01.2012 18:21, torhu wrote:
On 19.01.2012 18:19, torhu wrote:
On 17.01.2012 07:48, Andrei Alexandrescu wrote:
I hate I must ask this:
int[string] aa;
foreach (k; aa.byKey) { ... }
or
int[string] aa;
foreach (k; aa.byKey()) { ... }
For it to be a property, I think you s
On 1/19/12 11:29 AM, torhu wrote:
The reason would be that if it looks like field access, it should behave
like that.
The difficulty is in knowing where to stop. The only things that behaves
exactly like a field access is a field access. This is a known issue in
C++, e.g. smart pointers "are
On 01/19/2012 03:47 PM, Peter Alexander wrote:
On 19/01/12 12:51 AM, Timon Gehr wrote:
On 01/19/2012 01:41 AM, Peter Alexander wrote:
On 18/01/12 12:52 AM, Timon Gehr wrote:
On 01/18/2012 01:40 AM, Jonathan M Davis wrote:
On Tuesday, January 17, 2012 19:31:25 bearophile wrote:
Nick Sabalausk
On 01/19/2012 06:13 PM, Heywood Floyd wrote:
However, I still subscribe to Adam's view that the D bug situation _is_ a
problem, even a scary one:
http://d.puremagic.com/issues/reports.cgi?product=D&datasets=NEW
More than one fourth of those are enhancement requests, therefore it is
somewhat
On Thu, 19 Jan 2012 12:19:09 -0500, torhu wrote:
On 17.01.2012 07:48, Andrei Alexandrescu wrote:
I hate I must ask this:
int[string] aa;
foreach (k; aa.byKey) { ... }
or
int[string] aa;
foreach (k; aa.byKey()) { ... }
For it to be a property, I think you should be able to simplify this
On Thursday, January 19, 2012 18:33:15 Timon Gehr wrote:
> Parens should be removed completely from lazy values. They don't add a
> lot while being inconsistent with how other STCs work.
Ignoring the fact that this will break code, I completely agree. However,
given the fact that it's going to br
On Thursday, January 19, 2012 11:33:24 Andrei Alexandrescu wrote:
> On 1/19/12 11:29 AM, torhu wrote:
> > The reason would be that if it looks like field access, it should behave
> > like that.
>
> The difficulty is in knowing where to stop. The only things that behaves
> exactly like a field acce
I've been wondering in the back of my mind for awhile now and it
really hasn't bothered me much but I figured I might as well get
it off my mind.
Why is there a need for a default "standard" library? I can
understand about some of the core stuff, but hell, even threads
can be handled via a 3r
Have you ever bought a remote and after unpacking it realized that
batteries were not included?
On 19.01.2012 19:17, Steven Schveighoffer wrote:
That's like saying this:
int[] arr;
int l = arr.length;
l++;
should be the same as this:
arr.length++;
because it's a property.
This is an orthogonal problem. byKey doesn't try to affect the original
AA, so the semantics should be the same
On 19-01-2012 19:52, Zachary Lund wrote:
I've been wondering in the back of my mind for awhile now and it really
hasn't bothered me much but I figured I might as well get it off my mind.
Why is there a need for a default "standard" library? I can understand
about some of the core stuff, but hell
The only thing actually required to build a D app is druntime, which contains
threading support (needed so the GC knows how to scan threads spawned by the
app), a GC, and compiler support code. When Phobos is built, druntime is
bundled into it, so only Phobos is actually linked.
Sent from my i
Am 19.01.2012, 19:02 Uhr, schrieb Timon Gehr :
On 01/19/2012 06:13 PM, Heywood Floyd wrote:
However, I still subscribe to Adam's view that the D bug situation _is_
a problem, even a scary one:
http://d.puremagic.com/issues/reports.cgi?product=D&datasets=NEW
More than one fourth of those ar
On 1/19/2012 1:25 AM, Manu wrote:
> You lead me to an interesting though though...
> I have been realizing one thing that is concerning me more and more though,
> and that is that for some reason, it always
> comes back to Walter. This seems absurd.
> Why should any feature be contingent on Walter
Hi,
Are we allowed to redistribute snn.lib? I'm a little confused, because
the Digital Mars license says that we cannot redistribute DM software,
yet we link statically to snn.lib in virtually all D programs, which get
redistributed.
--
- Alex
Am 19.01.2012, 19:19 Uhr, schrieb Jonathan M Davis :
On Thursday, January 19, 2012 11:33:24 Andrei Alexandrescu wrote:
On 1/19/12 11:29 AM, torhu wrote:
> The reason would be that if it looks like field access, it should
behave
> like that.
The difficulty is in knowing where to stop. The on
I'm unfamiliar with the reason for C++ having a standard library as well
(which I bring up when people bitch about poor design or something
similar which I usually get no viable or any answer at all). More of an
ignorant question probably but oh well...
:D
Do you know what a chaos there was
On 1/19/12 11:13 AM, Heywood Floyd wrote:
[snip]
Thanks for a very insightful post.
Andrei
On 1/19/12 1:30 PM, Brad Roberts wrote:
Another interesting tool is github's impact grph:
https://github.com/D-Programming-Language/dmd/graphs/impact
I was never able to interpret that saliently.
Andrei
Le 19/01/2012 11:11, Walter Bright a écrit :
On 1/19/2012 2:06 AM, Patrick Stewart wrote:
Long story short - I find new things added and premature optimizations
The
worst enemy of language at the moment. They might look like selling
point to
you, to me they look like distractions from fixing D's
On Thursday, 19 January 2012 at 17:00:59 UTC, Timon Gehr wrote:
On 01/19/2012 03:47 PM, jdrewsen wrote:
On Wednesday, 18 January 2012 at 23:09:56 UTC, Timon Gehr
wrote:
On 01/18/2012 10:12 PM, jdrewsen wrote:
On Wednesday, 18 January 2012 at 20:13:04 UTC, Timon Gehr
wrote:
On 01/18/2012 08:59
On 01/19/2012 09:33 PM, jdrewsen wrote:
On Thursday, 19 January 2012 at 17:00:59 UTC, Timon Gehr wrote:
On 01/19/2012 03:47 PM, jdrewsen wrote:
On Wednesday, 18 January 2012 at 23:09:56 UTC, Timon Gehr wrote:
On 01/18/2012 10:12 PM, jdrewsen wrote:
On Wednesday, 18 January 2012 at 20:13:04 UT
On 1/19/2012 12:27 PM, Andrei Alexandrescu wrote:
> On 1/19/12 1:30 PM, Brad Roberts wrote:
>> Another interesting tool is github's impact grph:
>>https://github.com/D-Programming-Language/dmd/graphs/impact
>
> I was never able to interpret that saliently.
>
> Andrei
>From below the graph:
B
Le 18/01/2012 21:41, Walter Bright a écrit :
On 1/18/2012 12:10 PM, deadalnix wrote:
Usually, a newcomer isn't even sure if the bug comes from his/her code
or from
the compiler. How can you expect them to fill a bug about the spec ???
That's what these forums are for - to ask.
Seriously, tha
On Thursday, January 19, 2012 20:56:39 Marco Leise wrote:
> I just came across some C++ code and came to the conclusion, that
> properties and indexed access should not modify the structure. In other
> words all my @property and opIndex will probably also by const. An
> exception to that being cach
Are you reading in my mind ?
Le 19/01/2012 18:13, Heywood Floyd a écrit :
On 1/18/2012 2:15 PM, Adam Wilson wrote:
[...] There are 2719 open issues in the
bugtracker; that number alone will scare off many potential users.
Walter Bright Wrote:
Take a look at the changelog. I just don't see
I want to applaud Sean Kelly and everyone who worked on std.concurrency
for a great API, and wish that I could easily write Cocoa applications
with it.
I'm writing a screen recording program in Objective-C, and to make sure
each frame has an equal length, I have two threads: one that takes the
Le 19/01/2012 19:52, Zachary Lund a écrit :
I've been wondering in the back of my mind for awhile now and it really
hasn't bothered me much but I figured I might as well get it off my mind.
Why is there a need for a default "standard" library? I can understand
about some of the core stuff, but h
Qt for example uses the pimpl idiom for achieving ABI compatibility between
releases. The problem is additional heap allocations, additional indirection
and you pay for it, whether needed or not. (For example even derived classes in
the same library pay for it.)
I wondered whether this would sti
On Thursday, 19 January 2012 at 19:06:41 UTC, Alex Rønne
Petersen wrote:
On 19-01-2012 19:52, Zachary Lund wrote:
I've been wondering in the back of my mind for awhile now and
it really
hasn't bothered me much but I figured I might as well get it
off my mind.
Why is there a need for a default
On Thursday, 19 January 2012 at 21:22:23 UTC, Zachary Lund wrote:
On Thursday, 19 January 2012 at 19:06:41 UTC, Alex Rønne
Petersen wrote:
On 19-01-2012 19:52, Zachary Lund wrote:
I've been wondering in the back of my mind for awhile now and
it really
hasn't bothered me much but I figured I mig
Third post a charm.
I'm not meaning to rant and my question for the most part has
already been answered (however much I disagree with it). I
probably won't provide much more input. Thanks for answering my
question.
On 19-01-2012 22:22, Zachary Lund wrote:
On Thursday, 19 January 2012 at 19:06:41 UTC, Alex Rønne Petersen wrote:
On 19-01-2012 19:52, Zachary Lund wrote:
I've been wondering in the back of my mind for awhile now and it really
hasn't bothered me much but I figured I might as well get it off my
On 19-01-2012 22:26, Zachary Lund wrote:
On Thursday, 19 January 2012 at 21:22:23 UTC, Zachary Lund wrote:
On Thursday, 19 January 2012 at 19:06:41 UTC, Alex Rønne Petersen wrote:
On 19-01-2012 19:52, Zachary Lund wrote:
I've been wondering in the back of my mind for awhile now and it really
h
On 1/19/2012 11:30 AM, Brad Roberts wrote:
Focusing on dmd for this email, phobos and druntime are essentially not
dependent on Walter in any way:
There is also a fair amount of low hanging fruit in bugzilla. For example, there
are patches that can be turned into pull requests, and some one l
On 1/19/2012 11:36 AM, Alex Rønne Petersen wrote:
Are we allowed to redistribute snn.lib? I'm a little confused, because the
Digital Mars license says that we cannot redistribute DM software, yet we link
statically to snn.lib in virtually all D programs, which get redistributed.
You can redist
On 19-01-2012 22:36, Walter Bright wrote:
On 1/19/2012 11:36 AM, Alex Rønne Petersen wrote:
Are we allowed to redistribute snn.lib? I'm a little confused, because
the
Digital Mars license says that we cannot redistribute DM software, yet
we link
statically to snn.lib in virtually all D programs,
What I want to know, is why "std.stdio" wasn't named "std.io"...
*sigh*.. my OCD is going to drive me crazy one day.
Walter has recently closed a bug report without fixing it and without an
answer, it's about contract based programming:
http://d.puremagic.com/issues/show_bug.cgi?id=5024
So I'm asking for more info here.
As reference I use this little program (I have improved it a bit compared to
the one insid
On 19-01-2012 23:13, F i L wrote:
What I want to know, is why "std.stdio" wasn't named "std.io"...
*sigh*.. my OCD is going to drive me crazy one day.
That *is* a valid concern IMHO.
--
- Alex
Thanks :-) If you have ideas on how it could be improved, please let me know.
On Jan 19, 2012, at 12:58 PM, Nathan M. Swan wrote:
> I want to applaud Sean Kelly and everyone who worked on std.concurrency for a
> great API, and wish that I could easily write Cocoa applications with it.
>
> I'm
On Thu, Jan 19, 2012 at 3:31 PM, Alex Rønne Petersen wrote:
> On 19-01-2012 23:13, F i L wrote:
>
>> What I want to know, is why "std.stdio" wasn't named "std.io"...
>> *sigh*.. my OCD is going to drive me crazy one day.
>>
>>
> That *is* a valid concern IMHO.
>
> --
> - Alex
>
I proposed Steve S
On Thu, 19 Jan 2012 14:06:00 -0500, torhu wrote:
On 19.01.2012 19:17, Steven Schveighoffer wrote:
That's like saying this:
int[] arr;
int l = arr.length;
l++;
should be the same as this:
arr.length++;
because it's a property.
This is an orthogonal problem. byKey doesn't try to affect t
On Thu, 19 Jan 2012 17:42:27 -0500, Brad Anderson wrote:
On Thu, Jan 19, 2012 at 3:31 PM, Alex Rønne Petersen
wrote:
On 19-01-2012 23:13, F i L wrote:
What I want to know, is why "std.stdio" wasn't named "std.io"...
*sigh*.. my OCD is going to drive me crazy one day.
That *is* a valid
On Fri, 20 Jan 2012 09:31:12 +1100, Alex Rønne Petersen
wrote:
On 19-01-2012 23:13, F i L wrote:
What I want to know, is why "std.stdio" wasn't named "std.io"...
*sigh*.. my OCD is going to drive me crazy one day.
That *is* a valid concern IMHO.
I thought that the name std.stdio reflect
It is in the works:
https://github.com/schveiguy/phobos/commit/9ee5034f446877b0e78fec608271084d289f6345
Ha! That's awesome. When do you think this update will take
effect?
Derek wrote:
I thought that the name std.stdio reflected that the module is
in the standard library (std.) and that the
On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
On Thu, 19 Jan 2012 14:06:00 -0500, torhu wrote:
If the type of byKeys is Range, I would expect to be able to treat it
like one. Not like one, then another, then another, then another... ad
infinitum.
I don't know what you mean. You can treat it
On Thursday, January 19, 2012 17:41:44 Andrei Alexandrescu wrote:
> On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
> > On Thu, 19 Jan 2012 14:06:00 -0500, torhu wrote:
> >> If the type of byKeys is Range, I would expect to be able to treat it
> >> like one. Not like one, then another, then anothe
On Thursday, January 19, 2012 22:33:30 Alex Rønne Petersen wrote:
> Regardless of your preferences, the majority of the D community likes to
> have a standard library, so there's no reason to just stop shipping it
> (even though I don't think that's what you're suggesting).
Most languages have fai
On Thursday, January 19, 2012 17:29:28 bearophile wrote:
> If I am mistaken please I'd like to know why the current design is better
> (or maybe why it's just equally good). Thank you :-)
Honestly, I don't think that the order is all that critical, since all of the
same assertions are run in eith
On 1/19/12 5:57 PM, Jonathan M Davis wrote:
On Thursday, January 19, 2012 17:41:44 Andrei Alexandrescu wrote:
On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
On Thu, 19 Jan 2012 14:06:00 -0500, torhu wrote:
If the type of byKeys is Range, I would expect to be able to treat it
like one. Not li
On Thursday, January 19, 2012 18:07:50 Andrei Alexandrescu wrote:
> Yah, but .length acts to a better extent like an lvalue.
True, but that's because it's both a getter and a setter. What's weirder IMHO
is properties which are just setters, but they do make sense once in a while.
- Jonathan M Da
On Fri, 20 Jan 2012 10:33:33 +1100, F i L wrote:
Derek wrote:
I thought that the name std.stdio reflected ...
Then why isn't "std.math" not "std.stdmath"?
Please don't misunderstand me. I wasn't defending the name, just stating
what I thought the rationale behind it was.
--
Derek Parn
Could we please have at least a warning if code isn't compatible with
64Bit?
It's really annoying to test out some code and having to fix a bunch of
stupid uint->size_t bugs just because the author is still on a 32 bit
machine.
Is that feasible?
On Thu, Jan 19, 2012 at 9:41 PM, Andrei Alexandrescu
wrote:
> On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
>>
>> On Thu, 19 Jan 2012 14:06:00 -0500, torhu wrote:
>>>
>>> If the type of byKeys is Range, I would expect to be able to treat it
>>> like one. Not like one, then another, then another
On Thursday, January 19, 2012 22:30:46 Jose Armando Garcia wrote:
> I think MSDN has some decent advice on when to use properties vs
> methods:
> http://msdn.microsoft.com/en-us/library/bzwdh01d(v=vs.71).aspx#cpconpropert
> yusageguidelinesanchor1
Those do seem like pretty good guidelines.
- Jona
Trass3r:
> Could we please have at least a warning if code isn't compatible with
> 64Bit?
> It's really annoying to test out some code and having to fix a bunch of
> stupid uint->size_t bugs just because the author is still on a 32 bit
> machine.
>
> Is that feasible?
Time ago I have sugge
On 20/01/12 12:25 AM, Trass3r wrote:
Could we please have at least a warning if code isn't compatible with
64Bit?
It's really annoying to test out some code and having to fix a bunch of
stupid uint->size_t bugs just because the author is still on a 32 bit
machine.
Is that feasible?
In general,
On Thu, 19 Jan 2012 18:33:33 -0500, F i L wrote:
It is in the works:
https://github.com/schveiguy/phobos/commit/9ee5034f446877b0e78fec608271084d289f6345
Ha! That's awesome. When do you think this update will take effect?
I first have to show it's a) better and b) a drop-in replacement :)
On Thu, 19 Jan 2012 18:41:44 -0500, Andrei Alexandrescu
wrote:
On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
On Thu, 19 Jan 2012 14:06:00 -0500, torhu wrote:
If the type of byKeys is Range, I would expect to be able to treat it
like one. Not like one, then another, then another, then ano
On 1/19/2012 4:08 PM, Jonathan M Davis wrote:
On Thursday, January 19, 2012 17:29:28 bearophile wrote:
If I am mistaken please I'd like to know why the current design is better
(or maybe why it's just equally good). Thank you :-)
Honestly, I don't think that the order is all that critical, sin
On 1/19/2012 1:37 PM, Alex Rønne Petersen wrote:
Fair enough. However, can I bring the thread on the dmd-internals list about
_tls_callbacks_a to your attention then? If I cannot redistribute an snn.lib
where this symbol is patched out, this needs fixing, badly.
You don't need to patch the libr
Walter:
> My reasoning is it (1) doesn't make any difference and (2) it's always been
> like
> that - and if it did make a difference, it would break 10 years of existing
> code.
In the second code example I've shown I receive an assert error in the wrong
place. If a method is buggy, and its
On 1/19/2012 5:40 PM, Walter Bright wrote:
On 1/19/2012 1:37 PM, Alex Rønne Petersen wrote:
Fair enough. However, can I bring the thread on the dmd-internals
list about
_tls_callbacks_a to your attention then? If I cannot redistribute an
snn.lib
where this symbol is patched out, this needs fix
On Thu, 19 Jan 2012 20:38:05 -0500, Walter Bright
wrote:
On 1/19/2012 4:08 PM, Jonathan M Davis wrote:
On Thursday, January 19, 2012 17:29:28 bearophile wrote:
If I am mistaken please I'd like to know why the current design is
better
(or maybe why it's just equally good). Thank you :-)
On 1/19/2012 6:37 PM, Steven Schveighoffer wrote:
I have to disagree on some level with (1). It might not make a difference in
determining there is a bug, but it makes a difference because failing in the
out-condition gives you more information, even if the invariant is broken. It
tells you which
On 1/19/2012 4:08 PM, Jonathan M Davis wrote:
On Thursday, January 19, 2012 17:29:28 bearophile wrote:
If I am mistaken please I'd like to know why the current design is better
(or maybe why it's just equally good). Thank you :-)
Honestly, I don't think that the order is all that critical, sin
On Thu, 19 Jan 2012 22:31:08 -0500, Walter Bright
wrote:
On 1/19/2012 6:37 PM, Steven Schveighoffer wrote:
I have to disagree on some level with (1). It might not make a
difference in
determining there is a bug, but it makes a difference because failing
in the
out-condition gives you more
On Thursday, January 19, 2012 23:19:02 Steven Schveighoffer wrote:
> Imagine you have 1000 lines of code that call 50 or so
> different methods on a class. Any one of those calls in any one of those
> methods could cause an invariant failure. But only one method call can
> cause a specific out co
On Thu, 19 Jan 2012 22:33:40 -0500, Davidson Corry
wrote:
On 1/19/2012 4:08 PM, Jonathan M Davis wrote:
On Thursday, January 19, 2012 17:29:28 bearophile wrote:
If I am mistaken please I'd like to know why the current design is
better
(or maybe why it's just equally good). Thank you :-)
On Thu, 19 Jan 2012 23:24:59 -0500, Jonathan M Davis
wrote:
On Thursday, January 19, 2012 23:19:02 Steven Schveighoffer wrote:
Imagine you have 1000 lines of code that call 50 or so
different methods on a class. Any one of those calls in any one of
those
methods could cause an invariant
On 1/19/2012 8:19 PM, Steven Schveighoffer wrote:
If they are related, yes it does give you more information. The out condition
might not check the class data directly, but the error which caused the
invariant to fail could have also caused the out-condition to fail. It's
inconsequential to the *
On Thursday, January 19, 2012 21:01:40 Walter Bright wrote:
> Invariants and conditions are allowed to be impure so they can do things
> like logging.
Yeah, but if they're modifying state, they're doing something which is
essentially invalid, so from the standpoint of breaking code, I don't think
On 1/19/2012 9:14 PM, Jonathan M Davis wrote:
Yeah, but if they're modifying state, they're doing something which is
essentially invalid,
Yup, so arguing for which order the state changes should come in is also
invalid.
so from the standpoint of breaking code, I don't think
that swapping the
On 1/19/2012 12:48 PM, Roberto Caravani wrote:
I think this would be a real neat and very important feature, when it comes
to shared libraries. Is there any plan to implement something like that in
the future? Do I miss something?
The pimpl pros and cons are the same for C++ and D.
On Thursday, January 19, 2012 21:31:14 Walter Bright wrote:
> I'm not going to swap them without a compelling demonstration of its
> advantages. Not breaking much code is not an argument for changing current
> behavior.
I'm not saying that it is. I'm just saying that breaking code should not be a
2012/1/20 bearophile :
> Walter has recently closed a bug report without fixing it and without an
> answer, it's about contract based programming:
> http://d.puremagic.com/issues/show_bug.cgi?id=5024
>
> So I'm asking for more info here.
>
> As reference I use this little program (I have improved
I was wondering... Github provides service hooks for integration
with Bugzilla. Based on the commit messages, my first guess would
be that it's not used. Using integration would lower the amount
effort needed to close and manage a bug on Bugzilla.
1 - 100 of 105 matches
Mail list logo
