Ellery Newcomer wrote:
> So this behavior is new, but is it sensical?
It is a bug:
If a mixin has a MixinIdentifier, it can be used to disambiguate
[cited 11 Feb 2012 from
http://www.d-programming-language.org/template-mixin.html ]
Am 11.02.2012, 00:16 Uhr, schrieb Ellery Newcomer
:
On 02/10/2012 01:59 PM, Timon Gehr wrote:
I seem to have more RAM than you. The behavior is apparently caused by a
Phobos bug:
That is likely.
The code is a dustmite reduction, so I don't really care what the error
is, just that it sho
I've also injected some dll's and when I recompiled them they seemed to
crash the target program too.
this means that no C program will be able to load a dll written in D :s
the test I compiled was
import std.c.windows.windows;
import core.sys.windows.dll;
__gshared HINSTANCE g_hInst;
extern (Win
On 2012-02-11 05:41, Ellery Newcomer wrote:
dmd 2.057
Two mixin templates, each define toString, mix them in to your class and ..
Error: function test.X.T2!().toString multiple overrides of same function
So this behavior is new, but is it sensical?
Sample code:
mixin template T1(){
string t
Ellery Newcomer wrote:
> Can anyone confirm this behavior?
The behavior has nothing to do with fedora, because I can confirm it
for win32. It seems to be rooted in an infinite loop of memory
allocations.
Is this the first time of a report that an implementation attempt
stumbles into the holti
On 02/11/2012 08:48 AM, Jonathan M Davis wrote:
On Friday, February 10, 2012 22:41:20 Ellery Newcomer wrote:
dmd 2.057
Two mixin templates, each define toString, mix them in to your class and ..
Error: function test.X.T2!().toString multiple overrides of same function
So this behavior is new,
On 02/11/2012 02:29 PM, Manfred Nowak wrote:
Ellery Newcomer wrote:
Can anyone confirm this behavior?
The behavior has nothing to do with fedora, because I can confirm it
for win32. It seems to be rooted in an infinite loop of memory
allocations.
Is this the first time of a report that an im
On 02/11/2012 07:29 AM, Manfred Nowak wrote:
Is this the first time of a report that an implementation attempt
stumbles into the holting problem hidden in the evaluation of templates
during some compilation phase?
-manfred
Don't know, but this sort of thing has happened to me quite a bit over
Timon Gehr wrote:
> This would make it a Phobos bug.
Not necassarily. But it would be a Phobos bug if the allocation cycle
is completely located within Phobos and the possibilty of such a cycle
is not mentioned in the docs.
An analog argument holds for every templated "library", that uses
tem
On 02/10/2012 10:28 AM, Ali Çehreli wrote:
> Ubuntu 11.10 64-bit dmd.
>
> The following program gets stuck during the writeln() call.
>
> - The foo() call alone works fine.
>
> - The program works fine when there is no writeln() call nor foo() call.
> All elements get processed in that case and th
On 02/11/2012 05:19 PM, Manfred Nowak wrote:
Timon Gehr wrote:
This would make it a Phobos bug.
Not necassarily.
You didn't quote everything that is relevant:
Timon Gehr wrote:
Probably not, but the error message suggests the problem might be in
std.functional. This would make it a Phobos
I'm pretty sure this used to work:
import std.algorithm;
int[] ra;
copy(ra[5 .. 10], ra[4 .. 9]);
and would correctly shift the range [5 .. 10] down one
(unlike ra[4 .. 9] = ra[5 .. 10], which is prohibited by spec)
In dmd 2.057 of course it doesn't work; is this a bug or should I be
looking
On Saturday, February 11, 2012 12:09:32 Ellery Newcomer wrote:
> I'm pretty sure this used to work:
>
> import std.algorithm;
>
> int[] ra;
> copy(ra[5 .. 10], ra[4 .. 9]);
>
> and would correctly shift the range [5 .. 10] down one
> (unlike ra[4 .. 9] = ra[5 .. 10], which is prohibited by spec)
On Sat, Feb 11, 2012 at 10:30:43AM -0800, Jonathan M Davis wrote:
> On Saturday, February 11, 2012 12:09:32 Ellery Newcomer wrote:
> > I'm pretty sure this used to work:
> >
> > import std.algorithm;
> >
> > int[] ra;
> > copy(ra[5 .. 10], ra[4 .. 9]);
> >
> > and would correctly shift the range
On Saturday, February 11, 2012 10:51:36 H. S. Teoh wrote:
> This brings up an interesting point: what does the GC do if you have an
> array that's continually appended to, and also shrunk from the front?
> That is:
>
> ubyte[] buf;
> while ( ... ) {
> consumeData(buf[0]);
On Sat, Feb 11, 2012 at 11:02:43AM -0800, Jonathan M Davis wrote:
> On Saturday, February 11, 2012 10:51:36 H. S. Teoh wrote:
> > This brings up an interesting point: what does the GC do if you have an
> > array that's continually appended to, and also shrunk from the front?
> > That is:
> >
> >
http://d.puremagic.com/issues/show_bug.cgi?id=7484
On 02/11/2012 12:09 PM, Ellery Newcomer wrote:
I'm pretty sure this used to work:
import std.algorithm;
int[] ra;
copy(ra[5 .. 10], ra[4 .. 9]);
and would correctly shift the range [5 .. 10] down one
(unlike ra[4 .. 9] = ra[5 .. 10], which is
Timon Gehr wrote:
> The error message says
[...]
> recursive expansion
I did not read that in the posts and on dmd 2.057/win32 only an out of
memory was thrown.
> I'll attempt to analyse
Good luck.
-manfred
Hi all,
When aliases are used I expect to see it names on compile errors. But when
I use:
> struct __Bulk(T) {
> T[] chunks;
> }
> alias __Bulk!(byte) Bulk;
> alias __Bulk!Bulk MultiBulk;
The compilation error for:
> void question1() {
> Bulk("bad");
> }
is:
> bla.d(12): Error: ca
> On Sunday, February 12, 2012 01:52:16 Pedro Lacerda wrote:
> What are your opinions about these erros output?
aliases are always replaced with the original and you never see the aliased
name in the compiler output. It's only for the source. Now, that's not
entirely a good thing. I'd actually p
Jonathan M Davis:
> aliases are always replaced with the original and you never see the aliased
> name in the compiler output. It's only for the source. Now, that's not
> entirely a good thing. I'd actually prefer that the alias name were used if
> the variable in question was declared with the
On Saturday, February 11, 2012 23:59:39 bearophile wrote:
> Jonathan M Davis:
> > aliases are always replaced with the original and you never see the
> > aliased
> > name in the compiler output. It's only for the source. Now, that's not
> > entirely a good thing. I'd actually prefer that the alias
22 matches
Mail list logo
