Am 15.12.2012 03:56, schrieb Walter Bright:
On 12/14/2012 7:08 AM, Paulo Pinto wrote:
So the question is if toy university compilers have flow analysis why
not having
it in D?
The compiler does do full data flow analysis in the optimizer pass. But,
by then, it is intermediate code not D code.
On Saturday, 15 December 2012 at 06:37:51 UTC, Ali Çehreli wrote:
Works here as well.
My guess is that the encoding of the source code is not one of
the Unicode encodings, rather a "code table" encoding. If so,
please save the source code in a UTF encoding, e.g. UTF-8.
Ali
Yes, it was AN
12/14/2012 3:34 AM, deadalnix пишет:
On Thursday, 13 December 2012 at 20:48:30 UTC, deadalnix wrote:
On Thursday, 13 December 2012 at 20:04:50 UTC, Dmitry Olshansky wrote:
I think it's good.
But personally I'd expect:
* master to be what you define as dev, because e.g. GitHub puts
master as d
On 2012-12-14 19:27, Rob T wrote:
I wonder what can be done to allow a programmer to go fully manual,
while not loosing any of the nice features of D?
Someone has create a GC free version of druntime and Phobos.
Unfortunately I can't find the post in the newsgroup right now.
--
/Jacob Carlb
On Saturday, 15 December 2012 at 06:17:13 UTC, Walter Bright
wrote:
On 12/14/2012 6:26 PM, F i L wrote:
Sorry if I missed this, but with User Defined Attributes be
part of 2.61?
Yes.
Awesome! Can't wait :)
On 12/15/2012 03:50 AM, Dmitry Olshansky wrote:
I'd through in a spoiler (and featuring a later date):
http://www.nwcpp.org/old/Downloads/2008/memory-allocation.screen.pdf
Thanks for the slides. BTW is there any video of the presentation?
Interestingly, the slides mention the paper[1] in a few
On Saturday, 15 December 2012 at 11:35:18 UTC, Jacob Carlborg
wrote:
On 2012-12-14 19:27, Rob T wrote:
I wonder what can be done to allow a programmer to go fully
manual,
while not loosing any of the nice features of D?
Someone has create a GC free version of druntime and Phobos.
Unfortunat
On Saturday, 15 December 2012 at 10:29:55 UTC, Dmitry Olshansky
wrote:
12/14/2012 3:34 AM, deadalnix пишет:
On Thursday, 13 December 2012 at 20:48:30 UTC, deadalnix wrote:
On Thursday, 13 December 2012 at 20:04:50 UTC, Dmitry
Olshansky wrote:
I think it's good.
But personally I'd expect:
* m
On 2012-48-15 06:12, Jonathan M Davis wrote:
I don't see any reason not to support it. if you want coversion to only
go one
way, then alias a function which returns the value being aliased rather
than
aliasing a variable. If it doesn't support implicit conversions from
other
types, then it
I recently made some benchmarks with parallelism version of
Reduce using the example code, and I got this times with this
CPUs :
AMD FX(tm)-4100 Quad-Core Processor (Kubuntu 12.04 x64):
std.algorithm.reduce = 70294 ms
std.parallelism.reduce = 18354 ms -> SpeedUp = ~3.79
2x AMD Opteron(tm) Pr
On Friday, 14 December 2012 at 01:26:35 UTC, Walter Bright wrote:
On 12/13/2012 5:10 PM, H. S. Teoh wrote:
Remedy adopting D
Saying that would be premature and incorrect at the moment. We
still have to ensure that Remedy wins with D. This is an
ongoing thing.
Yes, but what H.S. Theoh wrote
On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
On 12/13/2012 4:17 PM, David Nadlinger wrote:
Like any major user of a language, they want confidence in our
full support of them. Asking them to use a patched or branch
version of the compiler does not inspire confidence.
Ma
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.
--
Russel.
=
Dr Russel Winder t:
On Saturday, 15 December 2012 at 16:55:39 UTC, Russel Winder
wrote:
Do people prefer to have all sources compiled in a
single compiler call
I prefer the single call.
On 12/15/12 11:55 AM, 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.
In phobos we use a single call for building the library. Then (at least
on Po
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.
Single compiler call is easier for small projects,
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 Haskell solutions are quite
un-idiomatic (you can see it also from th
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.
Oh and I should have asked: do you do things differently when
On Saturday, 15 December 2012 at 17:05:59 UTC, Peter Alexander
wrote:
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 followe
On Saturday, 15 December 2012 at 17:05:59 UTC, Peter Alexander
wrote:
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 followe
On Saturday, 15 December 2012 at 16:16:11 UTC, SomeDude wrote:
On Friday, 14 December 2012 at 01:26:35 UTC, Walter Bright
wrote:
On 12/13/2012 5:10 PM, H. S. Teoh wrote:
Remedy adopting D
Saying that would be premature and incorrect at the moment. We
still have to ensure that Remedy wins wit
On Sat, Dec 15, 2012 at 06:31:17PM +0100, RenatoUtsch wrote:
> On Saturday, 15 December 2012 at 17:05:59 UTC, Peter Alexander
> wrote:
> >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 com
On Saturday, 15 December 2012 at 17:27:38 UTC, Jakob Bornecrantz
wrote:
On Saturday, 15 December 2012 at 17:05:59 UTC, Peter Alexander
Single compiler call is easier for small projects, but I worry
about compile times for larger projects...
As evident by Phobos and my own project[1], for large
On Sat, Dec 15, 2012 at 06:35:33PM +0100, RenatoUtsch wrote:
> On Saturday, 15 December 2012 at 16:16:11 UTC, SomeDude wrote:
[...]
> >Yes, but what H.S. Theoh wrote about the desperate need of process
> >is still true and correct. Like many others here, I think it's the
> >biggest problem with D r
On Saturday, 15 December 2012 at 17:31:19 UTC, RenatoUtsch wrote:
On Saturday, 15 December 2012 at 17:05:59 UTC, Peter Alexander
wrote:
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 cal
On Saturday, 15 December 2012 at 18:00:58 UTC, H. S. Teoh wrote:
On Sat, Dec 15, 2012 at 06:31:17PM +0100, RenatoUtsch wrote:
On Saturday, 15 December 2012 at 17:05:59 UTC, Peter Alexander
wrote:
>On Saturday, 15 December 2012 at 16:55:39 UTC, Russel Winder
>wrote:
>>A quick straw poll. Do peop
With latest git dmd:
auto makeVoldemort(int x) {
struct Voldemort {
@property int value() { return x; }
}
return Voldemort();
}
void main() {
auto v = makeVoldemort();
wr
On Saturday, 15 December 2012 at 18:24:50 UTC, jerro wrote:
On Saturday, 15 December 2012 at 17:31:19 UTC, RenatoUtsch
wrote:
On Saturday, 15 December 2012 at 17:05:59 UTC, Peter Alexander
wrote:
On Saturday, 15 December 2012 at 16:55:39 UTC, Russel Winder
wrote:
A quick straw poll. Do people
On 15 December 2012 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.
>
> Thanks.
>
>
I do believe there are still some strange linker bugs
On Thu, 2012-12-13 at 14:49 -0800, H. S. Teoh wrote:
> Hi Russel,
>
> I've been using your BitBucket scons_d_tooling version of SCons for my D
> projects, and it's been great! However, I needed to make a static
> library today and I'm having some trouble with it. Here's a reduced
> testcase:
>
>
On Sat, Dec 15, 2012 at 07:30:52PM +0100, RenatoUtsch wrote:
> On Saturday, 15 December 2012 at 18:00:58 UTC, H. S. Teoh wrote:
[...]
> >So perhaps one possible middle ground would be to link packages
> >separately, but compile all the sources within a single package at
> >once. Presumably, if the
On Sat, Dec 15, 2012 at 06:42:27PM +, Iain Buclaw wrote:
> On 15 December 2012 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
On Saturday, 15 December 2012 at 18:38:29 UTC, H. S. Teoh wrote:
With latest git dmd:
auto makeVoldemort(int x) {
struct Voldemort {
@property int value() { return x; }
}
return Voldemort();
}
void ma
On Saturday, 15 December 2012 at 18:44:35 UTC, H. S. Teoh wrote:
On Sat, Dec 15, 2012 at 07:30:52PM +0100, RenatoUtsch wrote:
On Saturday, 15 December 2012 at 18:00:58 UTC, H. S. Teoh
wrote:
[...]
>So perhaps one possible middle ground would be to link
>packages
>separately, but compile all th
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 bugs should be
> fixed in the compiler, rather than force the user to compile one way or
> another.
Well obviou
On 12/15/2012 2:29 AM, Dmitry Olshansky wrote:
> I think one of major goals is to be able to continue ongoing development
> while at the _same time_ preparing a release.
> To me number one problem is condensed in the statement "we are going to
> release do not merge anything but regressions"
> t
On Saturday, 15 December 2012 at 19:03:49 UTC, Brad Roberts wrote:
This is a forcing function that's just required.
There is a focusing that needs to happen, but as you say, you
can't really dictate where someone puts their time (for open
source). So it is best to let the person who decided
On Sat, Dec 15, 2012 at 06:42:45PM +, Russel Winder wrote:
> On Thu, 2012-12-13 at 14:49 -0800, H. S. Teoh wrote:
> > Hi Russel,
> >
> > I've been using your BitBucket scons_d_tooling version of SCons for
> > my D projects, and it's been great! However, I needed to make a
> > static library to
On Saturday, December 15, 2012 19:50:34 Iain Buclaw wrote:
> On Saturday, 15 December 2012 at 18:38:29 UTC, H. S. Teoh wrote:
> > With latest git dmd:
> > auto makeVoldemort(int x) {
> >
> > struct Voldemort {
> >
> > @property int value() { ret
On Sat, Dec 15, 2012 at 11:31:22AM -0800, Jonathan M Davis wrote:
> On Saturday, December 15, 2012 19:50:34 Iain Buclaw wrote:
> > On Saturday, 15 December 2012 at 18:38:29 UTC, H. S. Teoh wrote:
> > > With latest git dmd:
> > > auto makeVoldemort(int x) {
> > >
> > > struct Voldemor
On 12/15/2012 8:55 AM, 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.
Both are needed, and are suitable for different purposes. It's like asking if
On Sat, Dec 15, 2012 at 11:45:10AM -0800, H. S. Teoh wrote:
[...]
> Found the reference in TDPL, §7.1.9 (p.263):
>
> Nested structs embed the magic "frame pointer" that allows them
> to access outer values such as a and b in the example above.
> [...] If you want to define a nest
On 15 December 2012 19:45, H. S. Teoh wrote:
> On Sat, Dec 15, 2012 at 11:31:22AM -0800, Jonathan M Davis wrote:
> > On Saturday, December 15, 2012 19:50:34 Iain Buclaw wrote:
> > > On Saturday, 15 December 2012 at 18:38:29 UTC, H. S. Teoh wrote:
> > > > With latest git dmd:
> > > > auto makeVo
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, whereas Walter's article promotes the use of
> such Voldemort types as a "happy discovery". :)
No, the real irony is that it's Andrei who
On 15 December 2012 19:58, Iain Buclaw wrote:
> On 15 December 2012 19:45, H. S. Teoh wrote:
>
>> On Sat, Dec 15, 2012 at 11:31:22AM -0800, Jonathan M Davis wrote:
>> > On Saturday, December 15, 2012 19:50:34 Iain Buclaw wrote:
>> > > On Saturday, 15 December 2012 at 18:38:29 UTC, H. S. Teoh wro
On Saturday, 15 December 2012 at 19:03:49 UTC, Brad Roberts wrote:
On 12/15/2012 2:29 AM, Dmitry Olshansky wrote:
I think one of major goals is to be able to continue ongoing
development while at the _same time_ preparing a release.
To me number one problem is condensed in the statement "we are
On Saturday, 15 December 2012 at 13:04:41 UTC, Mike Parker wrote:
On Saturday, 15 December 2012 at 11:35:18 UTC, Jacob Carlborg
wrote:
On 2012-12-14 19:27, Rob T wrote:
I wonder what can be done to allow a programmer to go fully
manual,
while not loosing any of the nice features of D?
Someo
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, whereas Walter's article promotes
> > the use of such Voldemort typ
On Saturday, 15 December 2012 at 20:32:42 UTC, Jesse Phillips
wrote:
On Saturday, 15 December 2012 at 10:29:55 UTC, Dmitry Olshansky
wrote:
Second point is about merging master into staging - why not
just rewrite it with master branch altogether after each
release?
master is the branch with cor
On 12.12.2012 02:42, David Nadlinger wrote:
On Tuesday, 11 December 2012 at 13:37:16 UTC, Iain Buclaw wrote:
I foresee that this release will be the biggest pain in the ass to
merge downstream into GDC. I wonder if David on LDC's side shares the
same concern...
I have been busy with getting LD
12/15/2012 11:03 PM, Brad Roberts пишет:
On 12/15/2012 2:29 AM, Dmitry Olshansky wrote:
I think one of major goals is to be able to continue ongoing development while
at the _same time_ preparing a release.
To me number one problem is condensed in the statement "we are going to release do
not
On Saturday, 15 December 2012 at 20:39:22 UTC, deadalnix wrote:
On Saturday, 15 December 2012 at 20:32:42 UTC, Jesse Phillips
wrote:
On Saturday, 15 December 2012 at 10:29:55 UTC, Dmitry
Olshansky wrote:
Second point is about merging master into staging - why not
just rewrite it with master bra
On Saturday, December 15, 2012 12:18:21 H. S. Teoh wrote:
> It seems that the only clean way to do this is to use a class instead of
> a struct, since the .init value will conveniently just be null, thereby
> sidestepping the problem.
That would incur unnecessary overhead and probably break all ki
On Saturday, 15 December 2012 at 21:10:19 UTC, Jonathan M Davis
wrote:
On Saturday, December 15, 2012 12:18:21 H. S. Teoh wrote:
It seems that the only clean way to do this is to use a class
instead of
a struct, since the .init value will conveniently just be
null, thereby
sidestepping the pro
On Sat, Dec 15, 2012 at 01:09:33PM -0800, Jonathan M Davis wrote:
> On Saturday, December 15, 2012 12:18:21 H. S. Teoh wrote:
> > It seems that the only clean way to do this is to use a class
> > instead of a struct, since the .init value will conveniently just be
> > null, thereby sidestepping the
On Saturday, December 15, 2012 13:44:13 H. S. Teoh wrote:
> But anyway, thinking a bit more about the .init problem, couldn't we
> just say that .init is not accessible outside the scope of the function
> that defines the type, and therefore you cannot declare a variable of
> that type (using typeo
On Saturday, 15 December 2012 at 17:02:08 UTC, Andrei
Alexandrescu wrote:
In phobos we use a single call for building the library. Then
(at least on Posix) we use multiple calls for running unittests.
This highlights the problem with giving a single answer to the
question: Building a large pro
On 12/15/2012 10:36 AM, H. S. Teoh wrote:
With latest git dmd:
auto makeVoldemort(int x) {
struct Voldemort {
@property int value() { return x; }
}
return Voldemort();
}
void main() {
On Saturday, 15 December 2012 at 19:03:49 UTC, Brad Roberts wrote:
On 12/15/2012 2:29 AM, Dmitry Olshansky wrote:
I think one of major goals is to be able to continue ongoing
development while at the _same time_ preparing a release.
To me number one problem is condensed in the statement "we are
Good finds.
The definition of a "nested struct" is not consistently or well
defined, so there's no wonder it's not working as anyone expects.
--rt
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 to get rid of the extra baggage use "static struct".
The r
On 12/15/2012 10:44 PM, H. S. Teoh wrote:
...
This way, the type still has an .init, except that it's only accessible
inside the function itself. Or are there unintended consequences here?
Lazy initialization of a member of such a type would require unsafe
language features and not work in CT
On 12/15/2012 9:31 AM, RenatoUtsch wrote:
Yes, I'm writing a build system for D (that will be pretty damn good, I think,
it has some interesting new concepts), and compiling each source separately to
an object, and then linking everything will allow easily to make the build
parallel, dividing the
On Saturday, 15 December 2012 at 20:39:22 UTC, 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 b
On Sunday, 16 December 2012 at 02:03:34 UTC, Jesse Phillips wrote:
On Saturday, 15 December 2012 at 20:39:22 UTC, 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 suitabl
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 bugs should be
> > fixed in the compiler, rather than
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.
On Thursday, 13 December 2012 at 07:18:16 UTC, foobar wrote:
Per my answer to Rob:
D2 *is* the major version.
releases should be minor versions and largely backwards
compatible - some evolution is allowed given some reasonable
restrictions like a proper migration path over several releases.
Cr
On Friday, 14 December 2012 at 19:24:39 UTC, Rob T wrote:
On Friday, 14 December 2012 at 18:46:52 UTC, Peter Alexander
wrote:
Allocating memory is simply slow. The same is true in C++
where you will see performance hits if you allocate memory too
often. The GC makes things worse, but if you rea
On Sunday, 16 December 2012 at 02:03:34 UTC, Jesse Phillips wrote:
On Saturday, 15 December 2012 at 20:39:22 UTC, 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 suitabl
On Sunday, 16 December 2012 at 03:59:33 UTC, Rob T wrote:
On Thursday, 13 December 2012 at 07:18:16 UTC, foobar wrote:
Per my answer to Rob:
D2 *is* the major version.
releases should be minor versions and largely backwards
compatible - some evolution is allowed given some reasonable
restrict
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 14 fields
per record.
With all dynamic memory allocation
72 matches
Mail list logo
