On Monday, December 17, 2012 08:39:56 deadalnix wrote:
> On Monday, 17 December 2012 at 07:27:49 UTC, Jonathan M Davis
>
> wrote:
> > On Monday, December 17, 2012 08:24:27 deadalnix wrote:
> >> On Monday, 17 December 2012 at 00:57:30 UTC, Walter Bright
> >>
> >> wrote:
> >> > It doesn't hide the
On Monday, 17 December 2012 at 07:27:49 UTC, Jonathan M Davis
wrote:
On Monday, December 17, 2012 08:24:27 deadalnix wrote:
On Monday, 17 December 2012 at 00:57:30 UTC, Walter Bright
wrote:
> It doesn't hide the source in any effective way. There are
> enough Java byte code => source translator
On 2012-12-17 02:10, Jonathan M Davis wrote:
Given that .di don't work with inlining or CTFE, I'd consider them to be a
very poor solution. You're seriously impairing yourself if you use them. It's
pretty much BS that corporations insist on header files to hide implementation,
since it really do
On 2012-12-16 22:34, Walter Bright wrote:
No "seem" about it!
Ok, I see. I'm just taking some precautions since I don't know what
you're thinking.
--
/Jacob Carlborg
On Monday, December 17, 2012 08:24:27 deadalnix wrote:
> On Monday, 17 December 2012 at 00:57:30 UTC, Walter Bright wrote:
> > It doesn't hide the source in any effective way. There are
> > enough Java byte code => source translators around to prove
> > that. It only takes one such tool to exist (a
On Monday, 17 December 2012 at 00:57:30 UTC, Walter Bright wrote:
It doesn't hide the source in any effective way. There are
enough Java byte code => source translators around to prove
that. It only takes one such tool to exist (and it's especially
easy to create such a tool given D being open
On Sunday, December 16, 2012 22:58:26 Walter Bright wrote:
> On 12/16/2012 10:27 PM, Jonathan M Davis wrote:
> > If the entire .d file is there in binary form, then I don't see why it
> > wouldn't work. .di files fail because they strip out the implementation.
> > If a binary format were used,
>
>
On Monday, 17 December 2012 at 05:29:23 UTC, SomeDude wrote:
On Sunday, 16 December 2012 at 22:43:13 UTC, David Nadlinger
wrote:
On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
This sounds to me like a bad idea. And indeed, I haven't
heard of any other project doing this.
Having
On Sun, Dec 16, 2012 at 10:27:31PM -0800, Jonathan M Davis wrote:
> On Sunday, December 16, 2012 19:18:45 Walter Bright wrote:
[...]
> > Whether the file format is text or binary does not make any
> > fundamental difference.
>
> If the entire .d file is there in binary form, then I don't see why i
On 12/16/2012 10:27 PM, Jonathan M Davis wrote:
If the entire .d file is there in binary form, then I don't see why it wouldn't
work. .di files fail because they strip out the implementation. If a binary
format were used,
It's all about what is in the file, not whether it is text or binary.
t
On Sunday, December 16, 2012 19:18:45 Walter Bright wrote:
> On 12/16/2012 5:10 PM, Jonathan M Davis wrote:
> > On Sunday, December 16, 2012 16:57:31 Walter Bright wrote:
> >> I've done such (precompiled headers for C++), I've done .di files, and
> >> I've
> >> done Java bytecode. .di files are sup
On Sunday, 16 December 2012 at 22:43:13 UTC, David Nadlinger
wrote:
On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
This sounds to me like a bad idea. And indeed, I haven't heard
of any other project doing this.
Having release branches is a common practice for many open
source pr
On 2012-12-17 03:18:45 +, Walter Bright said:
Whether the file format is text or binary does not make any fundamental
difference.
I too expect the difference in performance to be negligible in binary
form if you maintain the same structure. But if you're translating it
to another format
On 12/15/2012 10:30 AM, RenatoUtsch wrote:
Well, the idea is good. Small projects usually don't have much packages,
so there will be just a few compiler calls. And compiling files
concurrently will only have a meaningful efect if the project is large,
and a large project will have a lot of packag
On 12/16/2012 5:10 PM, Jonathan M Davis wrote:
On Sunday, December 16, 2012 16:57:31 Walter Bright wrote:
I've done such (precompiled headers for C++), I've done .di files, and I've
done Java bytecode. .di files are superior in nearly every way.
Given that .di don't work with inlining or CTFE,
I have recently added a note about "init property is sometimes unsafe".
https://github.com/D-Programming-Language/d-programming-language.org/pull/201
To reduce the risk, I have proposed an enhancement for .init property usage.
http://d.puremagic.com/issues/show_bug.cgi?id=8752
Kenji Hara
2012
On 12/16/2012 3:24 PM, SomeDude wrote:
Proof is, it seems to me that you (Isaac Gouy) often come around here. We can
magically invoke you every time one talks about the shootout. Which is pretty
astonishing for a language you aren't interested in.
Not really. You can set Google to email you whe
On Sunday, December 16, 2012 16:57:31 Walter Bright wrote:
> I've done such (precompiled headers for C++), I've done .di files, and I've
> done Java bytecode. .di files are superior in nearly every way.
Given that .di don't work with inlining or CTFE, I'd consider them to be a
very poor solution.
On 12/16/2012 4:48 PM, H. S. Teoh wrote:
I've proposed this before: when compiling a library, the compiler should
process everything into an intermediate form (perhaps even the IR that's
used internally to integrate with the codegen), then save that as a sort
of partially-compiled object format.
On Sun, Dec 16, 2012 at 04:45:31PM +0100, jerro wrote:
> >if, say, GDC was granted to come back in the shootout. Given it's
> >now widely acknowledged (at least in the programming communities)
> >to be one of the most promising languages around...
>
> And especially if you also consider the fact t
On 12/17/2012 01:39 AM, deadalnix wrote:
On Monday, 17 December 2012 at 00:27:42 UTC, Timon Gehr wrote:
On 12/16/2012 11:52 PM, deadalnix wrote:
Following the thread on integer semantic, i wanted to know if some data
are available on the tradeoff we are doing. Let me first explain what
they are
On Sun, Dec 16, 2012 at 03:06:16PM -0800, Jonathan M Davis wrote:
> On Sunday, December 16, 2012 23:32:38 Andrej Mitrovic wrote:
> > On 12/16/12, Paulo Pinto wrote:
> > > If modules are used correctly, a .di should be created with the
> > > public interface and everything else is already in binary
On Monday, 17 December 2012 at 00:27:42 UTC, Timon Gehr wrote:
On 12/16/2012 11:52 PM, deadalnix wrote:
Following the thread on integer semantic, i wanted to know if
some data
are available on the tradeoff we are doing. Let me first
explain what
they are.
In D, integer are guaranteed to loop,
On Sun, Dec 16, 2012 at 11:43:12PM +0100, David Nadlinger wrote:
> On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
> >This sounds to me like a bad idea. And indeed, I haven't heard of
> >any other project doing this.
>
> Having release branches is a common practice for many open sourc
On 12/16/2012 11:52 PM, deadalnix wrote:
Following the thread on integer semantic, i wanted to know if some data
are available on the tradeoff we are doing. Let me first explain what
they are.
In D, integer are guaranteed to loop, ie uint.max + 1 == 0 . In C, the
compiler is allowed to consider
On 12/16/2012 4:04 PM, deadalnix wrote:
Assuming that other don't understand the issue is not going to help. The issue
is pretty clear and simple.
Why it happens in one circumstance and not another is not nearly so clear and
simple.
On Sunday, 16 December 2012 at 23:51:16 UTC, Walter Bright wrote:
On 12/16/2012 3:30 PM, deadalnix wrote:
On Sunday, 16 December 2012 at 21:34:53 UTC, Walter Bright
wrote:
I think it is a bad solution to the issue.
Is no solution better than a bad solution ?
Solutions based on not understan
On 12/16/2012 3:30 PM, deadalnix wrote:
On Sunday, 16 December 2012 at 21:34:53 UTC, Walter Bright wrote:
I think it is a bad solution to the issue.
Is no solution better than a bad solution ?
Solutions based on not understanding the issue rarely turn out well.
On Monday, December 17, 2012 00:30:34 deadalnix wrote:
> On Sunday, 16 December 2012 at 21:34:53 UTC, Walter Bright wrote:
> > On 12/16/2012 5:36 AM, Jacob Carlborg wrote:
> >> Walter doesn't seem to want to implement a flag that output
> >> the template
> >> instantiations to all object files.
> >
On Sunday, 16 December 2012 at 21:34:53 UTC, Walter Bright wrote:
On 12/16/2012 5:36 AM, Jacob Carlborg wrote:
Walter doesn't seem to want to implement a flag that output
the template
instantiations to all object files.
No "seem" about it!
I think it is a bad solution to the issue.
Is no s
On Sunday, 16 December 2012 at 19:59:31 UTC, Isaac Gouy wrote:
On Sunday, 16 December 2012 at 15:45:32 UTC, jerro wrote:
if, say, GDC was granted to come back in the shootout. Given
it's now widely acknowledged (at least in the programming
communities) to be one of the most promising languages
On Sunday, 16 December 2012 at 23:21:15 UTC, SomeDude wrote:
On Sunday, 16 December 2012 at 19:59:31 UTC, Isaac Gouy wrote:
On Sunday, 16 December 2012 at 15:45:32 UTC, jerro wrote:
if, say, GDC was granted to come back in the shootout. Given
it's now widely acknowledged (at least in the progra
On Saturday, 15 December 2012 at 16:55:39 UTC, Russel Winder
wrote:
A quick straw poll. Do people prefer to have all sources
compiled in a
single compiler call, or (more like C++) separate compilation
of each
object followed by a link call.
Thanks.
I currently use full compilation. I have n
On Sunday, December 16, 2012 11:23:57 Andrei Alexandrescu wrote:
> Right now we're using a tagging system for releases, implying releases
> are just snapshots of a continuum. But what we need is e.g. to be able
> to patch 2.065 to fix a bug for a client who can't upgrade right now.
> That means one
On Sunday, 16 December 2012 at 20:08:11 UTC, Jacob Carlborg wrote:
On 2012-12-16 20:04, Jesse Phillips wrote:
I see it unreasonable to maintain every release. If we need to
make a
special "maintenance" release then we directly handle the
issue being
requested instead of providing every fix ap
On Sunday, 16 December 2012 at 22:56:08 UTC, Tim Čas wrote:
FYI, in C, unsigned integers are guaranteed to be modulo 2^N
(it is not called "overflow" in such a case). In other words,
`UINT_MAX + 1U == 0`.
Only *signed* integers can overflow or underflow; I do not know
the D's semantics in thi
On 12/16/2012 2:13 PM, Simen Kjaeraas wrote:
What's a good solution to the issue, then? Leave it as is?
Figure out the cases where it happens and fix those cases.
On Sunday, December 16, 2012 23:32:38 Andrej Mitrovic wrote:
> On 12/16/12, Paulo Pinto wrote:
> > If modules are used correctly, a .di should be created with the public
> > interface and everything else is already in binary format, thus the
> > compiler is not really parsing everything all the ti
On Sunday, 16 December 2012 at 22:52:44 UTC, deadalnix wrote:
Following the thread on integer semantic, i wanted to know if
some data are available on the tradeoff we are doing. Let me
first explain what they are.
In D, integer are guaranteed to loop, ie uint.max + 1 == 0 . In
C, the compiler
Following the thread on integer semantic, i wanted to know if
some data are available on the tradeoff we are doing. Let me
first explain what they are.
In D, integer are guaranteed to loop, ie uint.max + 1 == 0 . In
C, the compiler is allowed to consider that operation do not
overflow, which
On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
This sounds to me like a bad idea. And indeed, I haven't heard
of any other project doing this.
Having release branches is a common practice for many open source
projects. For example, KDE creates a branch per minor release,
with pa
On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
On Sunday, 16 December 2012 at 15:05:58 UTC, Andrei
Alexandrescu wrote:
On 12/16/12 6:15 AM, Joseph Rushton Wakeling wrote:
On 12/15/2012 09:39 PM, deadalnix wrote:
Can we drop the LTS name ? It reminds me of ubuntu, and I
clearly ho
On 12/16/12, Paulo Pinto wrote:
> If modules are used correctly, a .di should be created with the public
> interface and everything else is already in binary format, thus the
> compiler is not really parsing everything all the time.
A lot of D code tends to be templated code, .di files don't help
On Sunday, 16 December 2012 at 15:05:58 UTC, Andrei Alexandrescu
wrote:
On 12/16/12 6:15 AM, Joseph Rushton Wakeling wrote:
On 12/15/2012 09:39 PM, deadalnix wrote:
Can we drop the LTS name ? It reminds me of ubuntu, and I
clearly hope
that
people promoting that idea don't plan to reproduce ub
On 12/16/2012 05:23 PM, Andrei Alexandrescu wrote:
Right now we're using a tagging system for releases, implying releases are just
snapshots of a continuum. But what we need is e.g. to be able to patch 2.065 to
fix a bug for a client who can't upgrade right now. That means one branch per
release.
On 2012-34-16 22:12, Walter Bright wrote:
On 12/16/2012 5:36 AM, Jacob Carlborg wrote:
Walter doesn't seem to want to implement a flag that output the template
instantiations to all object files.
No "seem" about it!
I think it is a bad solution to the issue.
What's a good solution to the
On Sunday, 16 December 2012 at 18:37:48 UTC, Andrei Alexandrescu
wrote:
This should be Walter's business and not part
of the "official" community process.
I think this is rather shortsighted. Corporate support by
Walter is only one possible scenario, but there are many others.
Indeed. To a
On Sunday, 16 December 2012 at 07:47:48 UTC, Rob T wrote:
On Sunday, 16 December 2012 at 05:37:57 UTC, SomeDude wrote:
Isn't the memory management completely negligible when
compared to the database access here ?
Here are the details ...
My test run selects and returns 206,085 records with
On 12/16/2012 5:36 AM, Jacob Carlborg wrote:
Walter doesn't seem to want to implement a flag that output the template
instantiations to all object files.
No "seem" about it!
I think it is a bad solution to the issue.
On Tuesday, 11 December 2012 at 12:53:38 UTC, monarch_dodra wrote:
integer operations are always promoted to at least int. That's
standard fare since C. I think it is a performance thing:
Unpack into ints, oeprate, repack into ints.
If memory serves me right, promotion to int is based more on
On Sunday, 16 December 2012 at 14:58:46 UTC, Andrei Alexandrescu
wrote:
[Request again] Would Andre like to make any comment,
especially on the
martin fowler article ? Others commenting here have said that
they
consider that the pattern has some value ?
What I think about a paper upon first s
On 2012-12-16 20:04, Jesse Phillips wrote:
I see it unreasonable to maintain every release. If we need to make a
special "maintenance" release then we directly handle the issue being
requested instead of providing every fix applicable.
We could say that we support X number of older releases.
On Sunday, 16 December 2012 at 13:05:50 UTC, SomeDude wrote:
-snip-
Was it something the compiler writers told you?
Probably bearophile meant that...
I can make my own guesses, but I wanted to know what bearophile
meant so I asked him ;-)
On Sunday, 16 December 2012 at 15:45:32 UTC, jerro wrote:
if, say, GDC was granted to come back in the shootout. Given
it's now widely acknowledged (at least in the programming
communities) to be one of the most promising languages
around...
And especially if you also consider the fact that t
On Sunday, 16 December 2012 at 16:23:57 UTC, Andrei Alexandrescu
wrote:
Right now we're using a tagging system for releases, implying
releases are just snapshots of a continuum. But what we need is
e.g. to be able to patch 2.065 to fix a bug for a client who
can't upgrade right now. That mean
On Sunday, 16 December 2012 at 07:35:27 UTC, deadalnix wrote:
I shouldn't be here explaining why this is wrong, you should be
here explaining me why it can be applied anyway.
We are developing a process, specifying what it will look like.
If I'm building an airplane and say I think it should
On Sunday, 16 December 2012 at 18:37:48 UTC, Andrei Alexandrescu
wrote:
The prevalent use of the feature would be that a bug in a
future release is back-patched onto an older release.
Andrei
The issue I see is we will have X releases. A bug is fixed, do we
now apply it to all X or only Y
On Sunday, 16 December 2012 at 11:43:20 UTC, John Colvin wrote:
Use the stopwatch class from std.datetime to get a proper idea
of where time is being spent. All this subtracting 2 secs
business stinks.
or just fire up a profiler.
I am using the stopwatch, but had not gotten around to wrappin
On 12/16/12 11:56 AM, foobar wrote:
I don't see why that is a requirement (having a branch per release).
We can still have a single stable branch with tags for releases and when
Walter needs to provide special customizations he can always just branch
off of the tagged release.
To the extent pos
Am 16.12.2012 16:50, schrieb H. S. Teoh:
On Sun, Dec 16, 2012 at 02:22:04PM +0100, Paulo Pinto wrote:
Am 16.12.2012 13:13, schrieb Blub:
On Sat, 2012-12-15 at 16:55 +, Russel Winder wrote:
A quick straw poll. Do people prefer to have all sources compiled
in a single compiler call, or (mor
On Sunday, 16 December 2012 at 15:05:58 UTC, Andrei Alexandrescu
wrote:
On 12/16/12 6:15 AM, Joseph Rushton Wakeling wrote:
On 12/15/2012 09:39 PM, deadalnix wrote:
Can we drop the LTS name ? It reminds me of ubuntu, and I
clearly hope
that
people promoting that idea don't plan to reproduce ub
On 12/16/12 10:15 AM, Joseph Rushton Wakeling wrote:
On 12/16/2012 04:05 PM, Andrei Alexandrescu wrote:
Just one tidbit of information: I talked to Walter and we want to
build into the
process the ability to modify any particular release. (One possibility
is to do
so as part of paid support for
On Sun, Dec 16, 2012 at 02:22:04PM +0100, Paulo Pinto wrote:
> Am 16.12.2012 13:13, schrieb Blub:
> >>On Sat, 2012-12-15 at 16:55 +, Russel Winder wrote:
> >>>A quick straw poll. Do people prefer to have all sources compiled
> >>>in a single compiler call, or (more like C++) separate compilati
if, say, GDC was granted to come back in the shootout. Given
it's now widely acknowledged (at least in the programming
communities) to be one of the most promising languages around...
And especially if you also consider the fact that there Clean and
ATS are in the shootout and I'm guessing tha
On Sun, Dec 16, 2012 at 10:05:58AM -0500, Andrei Alexandrescu wrote:
[...]
> Just one tidbit of information: I talked to Walter and we want to
> build into the process the ability to modify any particular release.
> (One possibility is to do so as part of paid support for large
> corporate users.)
On 2012-12-15 14:04, Mike Parker wrote:
http://3d.benjamin-thaut.de/?p=20
That's it, thanks.
--
/Jacob Carlborg
On 12/16/2012 04:05 PM, Andrei Alexandrescu wrote:
Just one tidbit of information: I talked to Walter and we want to build into the
process the ability to modify any particular release. (One possibility is to do
so as part of paid support for large corporate users.) That means there needs to
be o
On 12/16/12 6:15 AM, Joseph Rushton Wakeling wrote:
On 12/15/2012 09:39 PM, deadalnix wrote:
Can we drop the LTS name ? It reminds me of ubuntu, and I clearly hope
that
people promoting that idea don't plan to reproduce ubuntu's scheme :
- it is not suitable for a programming language (as stated
On 12/16/12 4:28 AM, Nick B wrote:
I'd consider http://martinfowler.com/articles/lmax.html to be quite
nice description as it helped me to decipher the most of details.
The paper itself lacks illustrative material, focuses too much on
overcoming Java limitations and generally too terse with impor
On Sunday, 16 December 2012 at 11:01:40 UTC, David Nadlinger
wrote:
Funny things also happen if you try to be clever by batching
modules needing recompilation together (when doing incremental
compilation):
http://d.puremagic.com/issues/show_bug.cgi?id=8769
Don't know if this is the same pr
Am 16.12.2012 13:13, schrieb Blub:
On Sat, 2012-12-15 at 16:55 +, Russel Winder wrote:
A quick straw poll. Do people prefer to have all sources compiled in a
single compiler call, or (more like C++) separate compilation of each
object followed by a link call.
Separate compilation imposes
On 12/16/2012 01:13 PM, Blub wrote:
On Sat, 2012-12-15 at 16:55 +, Russel Winder wrote:
A quick straw poll. Do people prefer to have all sources compiled in a
single compiler call, or (more like C++) separate compilation of each
object followed by a link call.
Separate compilation imposes
On Saturday, 15 December 2012 at 17:11:01 UTC, Isaac Gouy wrote:
On Tuesday, 11 December 2012 at 23:59:29 UTC, bearophile wrote:
-snip-
But as usual you have to take such comparisons cum grano
salis, because there are a lot more people working on the GHC
compiler and because the Shootout Hask
On Sat, 2012-12-15 at 16:55 +, Russel Winder wrote:
A quick straw poll. Do people prefer to have all sources
compiled in a
single compiler call, or (more like C++) separate compilation
of each object followed by a link call.
Separate compilation imposes continuous re-processing of files.
Am 16.12.2012 10:21, schrieb Walter Bright:
On 12/16/2012 12:57 AM, Iain Buclaw wrote:
It likely is in bugzilla, but with thousands of open tickets, things get
forgotten and suffer the same 'will never get fixed' rigmarole.
On the other hand, not putting it in bugzilla will *guarantee* it is
f
On Sunday, 16 December 2012 at 07:47:48 UTC, Rob T wrote:
On Sunday, 16 December 2012 at 05:37:57 UTC, SomeDude wrote:
Isn't the memory management completely negligible when
compared to the database access here ?
Here are the details ...
My test run selects and returns 206,085 records with
On 12/15/2012 09:39 PM, deadalnix wrote:
Can we drop the LTS name ? It reminds me of ubuntu, and I clearly hope that
people promoting that idea don't plan to reproduce ubuntu's scheme :
- it is not suitable for a programming language (as stated 3 time now, so just
read before why I won't repeat
On 12/16/2012 08:35 AM, deadalnix wrote:
On Sunday, 16 December 2012 at 02:03:34 UTC, Jesse Phillips wrote:
You don't need to repeat your self, you need to expand on your points. Joseph
has already requested that you give specifics of your objection, you have
explained why the situation is diffe
On Sunday, 16 December 2012 at 09:22:25 UTC, Iain Buclaw wrote:
Respective bugs, all been open for around 3 years.
http://d.puremagic.com/issues/show_bug.cgi?id=3745
http://d.puremagic.com/issues/show_bug.cgi?id=3770
Funny things also happen if you try to be clever by batching
modules needing
Am 15.12.2012 17:55, schrieb Russel Winder:
A quick straw poll. Do people prefer to have all sources compiled in a
single compiler call, or (more like C++) separate compilation of each
object followed by a link call.
Thanks.
I prefer to compile by package, like in any module supporting langu
On Sunday, 16 December 2012 at 08:52:24 UTC, deadalnix wrote:
So distro's versioning system is good for a programming
language because you use it successfully in your software which
isn't a programming language (and we also don't know according
to which goal it is successful) ?
Let's not ge
On Sunday, 16 December 2012 at 07:47:48 UTC, Rob T wrote:
On Sunday, 16 December 2012 at 05:37:57 UTC, SomeDude wrote:
Isn't the memory management completely negligible when
compared to the database access here ?
Here are the details ...
My test run selects and returns 206,085 records with
On Wednesday, 12 December 2012 at 08:09:40 UTC, Dmitry Olshansky
wrote:
12/12/2012 6:00 AM, Nick B пишет:
On Monday, 10 December 2012 at 23:04:56 UTC, Nick B wrote:
On Monday, 10 December 2012 at 20:08:32 UTC, Andrei
Alexandrescu wrote:
On 12/9/12 10:58 PM, Nick B wrote:
[about the Disruptor f
On 12/16/2012 12:57 AM, Iain Buclaw wrote:
It likely is in bugzilla, but with thousands of open tickets, things get
forgotten and suffer the same 'will never get fixed' rigmarole.
On the other hand, not putting it in bugzilla will *guarantee* it is forgotten
and never fixed.
And actually, se
On 16 December 2012 02:53, Iain Buclaw wrote:
> On 15 December 2012 18:52, Jonathan M Davis wrote:
>
>> On Saturday, December 15, 2012 10:44:56 H. S. Teoh wrote:
>> > Isn't that just some compiler bugs that sometimes cause certain symbols
>> > not to be instantiated in the object file? IMO, such
On Sunday, 16 December 2012 at 07:39:09 UTC, deadalnix wrote:
The compiler source code is probably what we have that look
like the most as a spec right now.
Unfortunately that is likely the case. I hope we can all agree
that the specification should be managed better, but it's a much
lesser p
On 16 December 2012 03:52, Walter Bright wrote:
> On 12/15/2012 6:53 PM, Iain Buclaw wrote:
>
>> Probably won't be easy (if bug still exists). To describe it (I'll try
>> to find
>> a working example later)
>>
>
> These things all belong in bugzilla. Otherwise, they will never get fixed.
>
>
It
On Sunday, 16 December 2012 at 08:30:04 UTC, Rob T wrote:
On Sunday, 16 December 2012 at 07:35:27 UTC, deadalnix wrote:
The only goal that is coming is trying to reach some level of
stability. Everything else is completely different.
There are still some clear similarities between what Deb
On Sunday, 16 December 2012 at 07:35:27 UTC, deadalnix wrote:
The only goal that is coming is trying to reach some level of
stability. Everything else is completely different.
There are still some clear similarities between what Debian is
doing and what I presume most people do in software
As an alternative possible solution,
The following allows efficient nested structs in classes:
http://dpaste.dzfl.pl/64025e0a
It is very similar to the idea of voldemort structs except that
instead of outer being a function it is a class.
Therefore, it makes sense that one could simply use f
On Sunday, 16 December 2012 at 01:04:44 UTC, Rob T wrote:
There's an interesting discussion going on that may be related
to this subject.
http://forum.dlang.org/thread/mailman.2705.1355596709.5162.digitalmar...@puremagic.com
Note the definition with the "hidden reference frame" baggage,
and t
Rob T:
I wonder why 2 seconds are used to disable and enable the GC?
If you want one more test, try to put a "exit(0);" at the end of
your program (The C exit is in core.stdc.stdlib).
Bye,
bearophile
On Saturday, 15 December 2012 at 20:20:10 UTC, H. S. Teoh wrote:
On Sat, Dec 15, 2012 at 12:02:16PM -0800, Jonathan M Davis
wrote:
On Saturday, December 15, 2012 11:45:10 H. S. Teoh wrote:
> Ironically enough, Andrei in the subsequent paragraph
> discourages
> the use of such nested structs, wh
93 matches
Mail list logo
