On 10/29/2013 11:04 PM, Zeke wrote:
lowerBound and friends are related:
http://dlang.org/phobos/std_range.html#.lowerBound
Ali
Hello, I'm on day 2 of learning D. I've learned C, C++, Java,
Python, Ruby in University, but I wanted to broaden my palette by
picking up D.
This project is a basic implementation of Project Euler problem
10. I build an array of primes, and for each new test number I
check if the test is div
On Tuesday, 29 October 2013 at 11:46:53 UTC, Rene Zwanenburg
wrote:
On Monday, 28 October 2013 at 19:30:12 UTC, Maxim Fomin wrote:
Here is my attempt:
import std.stdio;
struct S
{
int i;
this(int i) { writefln("ctor, %X", i); this.i = i; }
this(this) { writefln("postblit, %X, %X", &th
Here's the code:
InputRange!Tree walk()
{
return inputRangeObject(chain(
[this],
children.map!(a=>a.walk())().joiner()));
}
Result:
---
[root, root.1, root.1.1, root.1.2, root.2, root.2.1, root.2.2]
---
It's a bit confusing to explain how I ca
On Wednesday, 30 October 2013 at 01:14:53 UTC, Daniel Davidson
wrote:
On Tuesday, 29 October 2013 at 18:02:46 UTC, Logesh Pillay
wrote:
On Sunday, 20 October 2013 at 16:08:50 UTC, bearophile wrote:
Logesh Pillay:
Thanks. Coming to D from python, I have to say D's tuples
look difficult. I'm
On Tuesday, 29 October 2013 at 19:40:40 UTC, Benjamin Thaut wrote:
So I found it. Its actually your fault.
IXAudio2Voice isn't a COM interface. That means it should _not_
inherit from IUnkown. But if it isn't a COM interface it can't
be a regular D interface either, because if it is a regular
On Wednesday, October 30, 2013 02:02:40 Peter Eisenhower wrote:
> I am confused as to why I cannot pass the return of the tag
> attribute directly into the parse int.
>
> // This works
> string s = xml.tag.attr["key"];
> int key = parse!int(s);
>
> // Compile error on these
> int key = parse!int(
On Tuesday, 29 October 2013 at 18:02:46 UTC, Logesh Pillay wrote:
On Sunday, 20 October 2013 at 16:08:50 UTC, bearophile wrote:
Logesh Pillay:
Thanks. Coming to D from python, I have to say D's tuples
look difficult. I'm going to see how far I can get with
structs writing my sudoku solver.
On Wednesday, 30 October 2013 at 01:02:45 UTC, Peter Eisenhower
wrote:
I am confused as to why I cannot pass the return of the tag
attribute directly into the parse int.
// This works
string s = xml.tag.attr["key"];
int key = parse!int(s);
// Compile error on these
int key = parse!int(xml.ta
I am confused as to why I cannot pass the return of the tag
attribute directly into the parse int.
// This works
string s = xml.tag.attr["key"];
int key = parse!int(s);
// Compile error on these
int key = parse!int(xml.tag.attr["key"]);
int key = parse!int(cast(string) cml.tag.attr["key"]);
Hi,
I'd like a version of std.range.chunk that does not require the
range to have the "length" property.
As an example, consider a file that you would like parse by lines
and always lump together four lines, i.e.
import std.stdio;
void main() {
auto range = File("test.txt", "r").byLine();
Maxim Fomin:
It works according to spec: "A named enum member can be
implicitly cast to its EnumBaseType, but EnumBaseType types
cannot be implicitly cast to an enum type. "
In this respect D enums behave like C enums.
In C conversion in both directions is allowed (C enums don't have
a Enu
Instead of the usual opApply approach, how would you implement an auto
return walker function *without* defining a special external struct
that holds all the logic? In other words, using existing Phobos
functionality only, composing functions like map and chain. Example
code which isn't correct:
-
On Tuesday, 29 October 2013 at 21:24:35 UTC, bearophile wrote:
Maxim Fomin:
Bools being integer types is reason of your problem with enums.
The reason of that problem of mine with enums is that they
convert implicitly to integers. And I still don't know the
original rationale of Walter of t
Maxim Fomin:
Bools being integer types is reason of your problem with enums.
The reason of that problem of mine with enums is that they
convert implicitly to integers. And I still don't know the
original rationale of Walter of this design mistake.
Bye,
bearophile
On Tuesday, 29 October 2013 at 19:40:40 UTC, Benjamin Thaut wrote:
So I found it. Its actually your fault.
IXAudio2Voice isn't a COM interface. That means it should _not_
inherit from IUnkown. But if it isn't a COM interface it can't
be a regular D interface either, because if it is a regular
Am 29.10.2013 21:26, schrieb Heinz:
On Tuesday, 29 October 2013 at 19:40:40 UTC, Benjamin Thaut wrote:
So I found it. Its actually your fault.
IXAudio2Voice isn't a COM interface. That means it should _not_
inherit from IUnkown. But if it isn't a COM interface it can't be a
regular D interface
So I found it. Its actually your fault.
IXAudio2Voice isn't a COM interface. That means it should _not_ inherit
from IUnkown. But if it isn't a COM interface it can't be a regular D
interface either, because if it is a regular D-Interface it will not
have a v-table layout that conforms with C+
On Tuesday, 29 October 2013 at 18:23:03 UTC, bearophile wrote:
Ali Çehreli:
>> enum Foo { A, B, C }
>> void main() {
>>bool[5] bools;
>>auto b = bools[2] != Foo.C;
>>bools[2] = Foo.A;
>> }
...
There was a long discussion about that. Walter was happy that
bool was a integer type. Ma
On 10/29/2013 11:11 AM, Maxim Fomin wrote:
> On Tuesday, 29 October 2013 at 17:57:01 UTC, Ali Çehreli wrote:
>> http://forum.dlang.org/post/l4osr0$2f3q$1...@digitalmars.com
> I did this in 2 January
> (http://forum.dlang.org/thread/lpljpfjxwobniglwn...@forum.dlang.org) and
> received exactly
Ali Çehreli:
>> enum Foo { A, B, C }
>> void main() {
>> bool[5] bools;
>> auto b = bools[2] != Foo.C;
>> bools[2] = Foo.A;
>> }
...
There was a long discussion about that. Walter was happy that
bool was a integer type. Many of us had objections:
My problem is mostly with enums. I
On Tuesday, 29 October 2013 at 17:40:23 UTC, Ali Çehreli wrote:
On 10/29/2013 09:15 AM, Maxim Fomin wrote:
> On Tuesday, 29 October 2013 at 12:43:17 UTC, bearophile wrote:
>> This code is accepted by the D compiler:
>>
>>
>> enum Foo { A, B, C }
>> void main() {
>> bool[5] bools;
>> auto
On Tuesday, 29 October 2013 at 17:57:01 UTC, Ali Çehreli wrote:
On 10/29/2013 08:47 AM, Maxim Fomin wrote:
On Monday, 28 October 2013 at 20:43:01 UTC, Ali Çehreli wrote:
What is the purpose of writeln in that delegate? Obviously,
to print
1. Yet it doesn't happen that way. Is this accepted to
On Sunday, 20 October 2013 at 16:08:50 UTC, bearophile wrote:
Logesh Pillay:
Thanks. Coming to D from python, I have to say D's tuples
look difficult. I'm going to see how far I can get with
structs writing my sudoku solver.
I think defining the full correct hashing protocol manually for
I have the exact same problem with XAudio2 in my own code. Code
compiles and run but doesn't output any sound. I tried your code
but it's the same as mine, runs but doesn't sound.
I'm using in my code the bindings from
http://www.dsource.org/projects/bindings/wiki/DirectX
Can't really understand
On 10/29/2013 08:47 AM, Maxim Fomin wrote:
On Monday, 28 October 2013 at 20:43:01 UTC, Ali Çehreli wrote:
What is the purpose of writeln in that delegate? Obviously, to print
1. Yet it doesn't happen that way. Is this accepted to be a bug?
Should the programmer 'new' the object instead?
Ali
On 10/29/2013 09:15 AM, Maxim Fomin wrote:
> On Tuesday, 29 October 2013 at 12:43:17 UTC, bearophile wrote:
>> This code is accepted by the D compiler:
>>
>>
>> enum Foo { A, B, C }
>> void main() {
>> bool[5] bools;
>> auto b = bools[2] != Foo.C;
>> bools[2] = Foo.A;
>> }
>>
>>
>> Wh
On Tuesday, 29 October 2013 at 12:43:17 UTC, bearophile wrote:
This code is accepted by the D compiler:
enum Foo { A, B, C }
void main() {
bool[5] bools;
auto b = bools[2] != Foo.C;
bools[2] = Foo.A;
}
Who is that likes such kind of code? What are the advantages of
accepting such
On Tuesday, 29 October 2013 at 12:03:09 UTC, Rene Zwanenburg
wrote:
On Monday, 28 October 2013 at 19:40:26 UTC, Maxim Fomin wrote:
The fact that structs are movable and there is too few struct
runtime reflection makes them noncollectable. However, you can
wrap struct inside class, in such case
On Tuesday, 29 October 2013 at 14:13:40 UTC, Benjamin Thaut wrote:
I also found that for all pp members which take pointers to COM
interfaces. For example the "CreateMasteringVoice"
"IXAudio2MasteringVoice** ppMasteringVoice" member. In D
interfaces are already reference types. So it should r
On Tuesday, 29 October 2013 at 11:46:53 UTC, Rene Zwanenburg
wrote:
That's pretty nasty :). But I suspect this is a bug and not by
design. __dtor and __traits are, IMHO, the proverbial escape
hatch D should provide, so I think that's OK. I take it that by
control flow trick you mean the try/c
On Monday, 28 October 2013 at 20:43:01 UTC, Ali Çehreli wrote:
What is the purpose of writeln in that delegate? Obviously, to
print 1. Yet it doesn't happen that way. Is this accepted to be
a bug? Should the programmer 'new' the object instead?
Ali
In my opinion it is a corner case, a cons
On Tuesday, 29 October 2013 at 14:13:40 UTC, Benjamin Thaut wrote:
As I'm not familiar with xaudio2 I will not be able to help you
unless you present a example which actually crashes. I don't
think this is a COM issue. Does a C++ program which does the
same work?
C++ example works fine(link
Am 29.10.2013 15:00, schrieb Benjamin Thaut:
Am 29.10.2013 14:45, schrieb evilrat:
On Tuesday, 29 October 2013 at 13:35:11 UTC, Benjamin Thaut wrote:
I already found the first problem with your library.
Your directx modules have module declarations in the form of:
module directx.xaudio2;
but
Am 29.10.2013 14:45, schrieb evilrat:
On Tuesday, 29 October 2013 at 13:35:11 UTC, Benjamin Thaut wrote:
I already found the first problem with your library.
Your directx modules have module declarations in the form of:
module directx.xaudio2;
but they are directly within the src directory.
Yo
On Tuesday, 29 October 2013 at 13:35:11 UTC, Benjamin Thaut wrote:
I already found the first problem with your library.
Your directx modules have module declarations in the form of:
module directx.xaudio2;
but they are directly within the src directory.
You should create a subfolder called "dir
I already found the first problem with your library.
Your directx modules have module declarations in the form of:
module directx.xaudio2;
but they are directly within the src directory.
You should create a subfolder called "directx" and place all your
modules in there so it is actually consist
This code is accepted by the D compiler:
enum Foo { A, B, C }
void main() {
bool[5] bools;
auto b = bools[2] != Foo.C;
bools[2] = Foo.A;
}
Who is that likes such kind of code? What are the advantages of
accepting such kind of code? I can see the disadvantages and
risks.
Bye,
be
On Tuesday, 29 October 2013 at 11:47:00 UTC, Benjamin Thaut wrote:
Am 29.10.2013 10:38, schrieb evilrat:
omg, almost a month passed and i even didn't notice it.
after some "research" i'm still don't know what the problem.
some COM
calls works, some fails(probably wrong method calls, and it
no
On Monday, 28 October 2013 at 19:40:26 UTC, Maxim Fomin wrote:
The fact that structs are movable and there is too few struct
runtime reflection makes them noncollectable. However, you can
wrap struct inside class, in such case struct dtor will be
called.
Yeah, if wrapping inside a class would
Am 29.10.2013 10:38, schrieb evilrat:
omg, almost a month passed and i even didn't notice it.
after some "research" i'm still don't know what the problem. some COM
calls works, some fails(probably wrong method calls, and it not crashes
just because same args). now i have half working d3d11 and n
On Monday, 28 October 2013 at 19:30:12 UTC, Maxim Fomin wrote:
Here is my attempt:
import std.stdio;
struct S
{
int i;
this(int i) { writefln("ctor, %X", i); this.i = i; }
this(this) { writefln("postblit, %X, %X", &this, i); }
~this() { writefln("dtor, %X, %X", &this, i); }
}
omg, almost a month passed and i even didn't notice it.
after some "research" i'm still don't know what the problem. some
COM calls works, some fails(probably wrong method calls, and it
not crashes just because same args). now i have half working
d3d11 and not working at all xaudio2.
due to
On Monday, 28 October 2013 at 18:34:51 UTC, Dicebot wrote:
Any difference in semantics between -profile and normal flow is
a
bug, so, yes, please report to bugzilla.
Done: http://d.puremagic.com/issues/show_bug.cgi?id=11375
44 matches
Mail list logo