On Thursday, 19 April 2012 at 06:56:21 UTC, Jonathan M Davis
wrote:
On Thursday, April 19, 2012 08:25:13 Namespace wrote:
Wow, many thanks for your trouble. Now it works as aspected.
I only need
T opCast(T)() const if(isImplicitlyConvertible!(typeof(this),
T))
{
return this;
}
to wor
On Thursday, April 19, 2012 09:01:15 Namespace wrote:
> Yeah, but
> const Vector2s vs_ = cast(Vector2s)(vf);
>
> don't work even with
I don't know why it isn't working for you. It's working for me. You can look
at the altered code here: http://codepad.org/C5Td5tVz
I had to comment out the lines
On 04/18/2012 08:45 PM, Brad Anderson wrote:
> On Thursday, 19 April 2012 at 03:37:00 UTC, bearophile wrote:
>> Brad Anderson:
>>> You can popFront() for as long as you want well passed the length.
>>> Obviously popping off the front of a zero length range isn't valid
>>> but I would have expected
Le 19/04/2012 05:36, bearophile a écrit :
> Brad Anderson:
>> You can popFront() for as long as you want well passed the length.
>> Obviously popping off the front of a zero length range isn't valid but
>> I would have expected a range violation to occur rather than it to
>> silently continuing the
Perhaps I'm just misunderstanding something about closures but
the following code seems to behave oddly:
import std.stdio, std.range, std.algorithm, std.string;
void main()
{
auto lst = ["a", "b"];
auto rng = range_gen(lst);
writeln(rng.take(5));
}
au
On Thursday, April 19, 2012 09:58:00 Somedude wrote:
> Le 19/04/2012 05:36, bearophile a écrit :
> > Brad Anderson:
> >> You can popFront() for as long as you want well passed the length.
> >> Obviously popping off the front of a zero length range isn't valid but
> >> I would have expected a range
Le 19/04/2012 10:07, Jonathan M Davis a écrit :
> Having an assertion may be desirable, but the bug is in the usage of iota,
> not
> iota itself. At best, the assertion would help indicate that the caller has a
> bug. It's exactly the same as doing something like
>
> for(size_t i = 3; cond; --i
Le 19/04/2012 05:04, "Michaël Larouche" " a
écrit :
>
> Reading the bug thread, I am wondering why my template worked in a
> struct but not inside a class.
>
> Anyway, I decided to move my mixin outside the struct/class and abuse
> UFCS instead. Now everything works like a charm :)
Cool. Glad it
And which version do you use? I use DMD 2.059 on Windows 7.
I get this compile error with your code
object.Error: Access Violation
41943C
4192C7
40F75B
40BE90
40BECA
40BAEB
4206E1
If i comment out this part
if (vs2 == vf) {
writeln("equal");
}
it works fine.
On Thursday, April 19, 2012 10:48:45 Namespace wrote:
> And which version do you use? I use DMD 2.059 on Windows 7.
>
> I get this compile error with your code
> object.Error: Access Violation
>
> 41943C
> 4192C7
> 40F75B
> 40BE90
> 40BECA
> 40BAEB
> 4206E1
>
> If i comment out t
On Thursday, April 19, 2012 10:14:39 Somedude wrote:
> Le 19/04/2012 10:07, Jonathan M Davis a écrit :
> > Having an assertion may be desirable, but the bug is in the usage of iota,
> > not iota itself. At best, the assertion would help indicate that the
> > caller has a bug. It's exactly the same
On Thursday, 19 April 2012 at 09:05:13 UTC, Jonathan M Davis
wrote:
On Thursday, April 19, 2012 10:48:45 Namespace wrote:
And which version do you use? I use DMD 2.059 on Windows 7.
I get this compile error with your code
object.Error: Access Violation
41943C
4192C7
40F75B
40BE
On Thursday, April 19, 2012 11:15:23 Namespace wrote:
> A specific Windows bug with opEquals and opCast?
Maybe. Certainly, it's working on my Linux box, so if you're compiling the
same code that I am, and you're using 2.059, it definitely sounds like it's a
Windows-specific bug.
> My Windows is
I will download dmd later again to check if i have an older
version or beta.
After download dmd again it get still the same compile error.
On Thursday, 19 April 2012 at 09:22:24 UTC, Jonathan M Davis
wrote:
On Thursday, April 19, 2012 11:15:23 Namespace wrote:
A specific Windows bug with opEquals and opCast?
Maybe. Certainly, it's working on my Linux box, so if you're
compiling the
same code that I am, and you're using 2.059, it
On Thursday, April 19, 2012 11:27:20 Namespace wrote:
> On Thursday, 19 April 2012 at 09:22:24 UTC, Jonathan M Davis
>
> wrote:
> > On Thursday, April 19, 2012 11:15:23 Namespace wrote:
> >> A specific Windows bug with opEquals and opCast?
> >
> > Maybe. Certainly, it's working on my Linux box, s
Le 19/04/2012 11:11, Jonathan M Davis a écrit :
> On Thursday, April 19, 2012 10:14:39 Somedude wrote:
>> Le 19/04/2012 10:07, Jonathan M Davis a écrit :
>>> Having an assertion may be desirable, but the bug is in the usage of iota,
>>> not iota itself. At best, the assertion would help indicate th
On Thu, 19 Apr 2012 04:07:00 -0400, Jonathan M Davis
wrote:
Having an assertion may be desirable, but the bug is in the usage of
iota, not
iota itself.
Yes, and iota should detect that bug with an assert. No case can really
be made that iota shouldn't be changed. Please file an enhanc
On Wed, 18 Apr 2012 17:07:07 -0400, Xan wrote:
Hi,
I want to know what is most interesting for me: delegates or functions.
I consulted sources but none say the practical consequences of such
election.
What can I do and what can't I do with functions and delegates?
Please, be didactics, I
A great thanks to you. But any of my tries to make
"const Vector2D vec = castFromObject(o);" possible i get an
error. Didn't i must only write "private static const(Vector2D)
castFromObject(Object o)" instead of "private static Vector2D
castFromObject(Object o)"?
On Thursday, 19 April 2012 at 11:38:39 UTC, Steven Schveighoffer
wrote:
On Thu, 19 Apr 2012 04:07:00 -0400, Jonathan M Davis
wrote:
Having an assertion may be desirable, but the bug is in the
usage of iota, not
iota itself.
Yes, and iota should detect that bug with an assert. No case
can
On Thursday, 19 April 2012 at 11:46:59 UTC, Steven Schveighoffer
wrote:
On Wed, 18 Apr 2012 17:07:07 -0400, Xan
wrote:
Hi,
I want to know what is most interesting for me: delegates or
functions. I consulted sources but none say the practical
consequences of such election.
What can I do a
The program:
import std.concurrency ;
import std.stdio ;
/*immutable*/ struct X { int i ; }
void printI ( ) {
receive (
( X x ) { writeln ( x.i ) ; }
) ;
}
int main ( immutabl
"Brad Anderson" , dans le message (digitalmars.D.learn:34902), a écrit :
> Perhaps I'm just misunderstanding something about closures but
> the following code seems to behave oddly:
>
> import std.stdio, std.range, std.algorithm, std.string;
>
> void main()
> {
> auto lst
I put this here because it's probably a flawed idea. A 'learn'
level suggestion.
At present function arguments that you want to default must go at
the end like so:
int fun(int a = 1, int b = 2, int c = 3)
{
return a + b + c;
}
fun(4); //Modifies a
where the default fields can only be fi
And while I think about it why not allow the following to make b
and c int rather than have to redeclare the type each time?
int fun(int a = 1, b = 2, c = 3)
{
return a + b + c;
}
I'm going through a number of bug reports, trying to reproduce the
problems and see what can be closed easily (i.e non reproduced, correct
behaviour, etc), and I just came accross
http://d.puremagic.com/issues/show_bug.cgi?id=7326 titled
"write interprets enum with byte backing type as a character"
On 4/19/12, Somedude wrote:
> Can anyone explain me if it is the correct behaviour, and if yes, why ?
It's fixed now and we can close this down. I think it was related to
formatting issues, that's all.
It seems that i can't cast if i want a const Vector2D, neither
with castFromtObject nor with opCast. If i do it i get a very
long list of compile errors. It's no problem because i can deal
without cast to const but it would be usefull if you can show me
how i can use both, const and normal cast
On Thu, Apr 19, 2012 at 7:25 AM, Christophe wrote:
> "Brad Anderson" , dans le message (digitalmars.D.learn:34902), a écrit :
> > Perhaps I'm just misunderstanding something about closures but
> > the following code seems to behave oddly:
> >
> > import std.stdio, std.range, std.algorithm, st
On 04/19/2012 03:27 PM, Russel Winder wrote:
The program:
import std.concurrency ;
import std.stdio ;
/*immutable*/ struct X { int i ; }
void printI ( ) {
receive (
( X x ) { writeln ( x.i ) ; }
) ;
On Thu, 19 Apr 2012 09:04:47 -0400, Xan wrote:
Thank you very much all of you for the information. Now I have an idea
of practical benefits and contra-benefits of these.
By the other hand, is there toFunction for passing delegate to function
(theorically it's possible, isn't?)
No. A del
On Wednesday, 18 April 2012 at 19:43:50 UTC, Paul D. Anderson
wrote:
SomeDude: Your outline and especially your emphasis on what a
rank beginner needs to know is very good.
Would you consider writing it up yourself? Not the whole thing,
maybe but the beginner info and the compiler/linker appen
I am having a problem with my Pull-Request, I don't know how I can do
that:
https://github.com/D-Programming-Language/phobos/pull/482#issuecomment-5070817
I hope you can give me a short intstruction what to do, thanks.
On Thursday, 19 April 2012 at 17:27:18 UTC, David wrote:
I am having a problem with my Pull-Request, I don't know how I
can do that:
https://github.com/D-Programming-Language/phobos/pull/482#issuecomment-5070817
I hope you can give me a short intstruction what to do, thanks.
Pull from upstrea
On 19.04.2012 21:27, David wrote:
I am having a problem with my Pull-Request, I don't know how I can do
that:
https://github.com/D-Programming-Language/phobos/pull/482#issuecomment-5070817
I hope you can give me a short intstruction what to do, thanks.
Should be as simple as:
git pull --rebas
Are there any info about them?
I tought that new std.process would replace the old one in
version 2.059, but it seems not...
On 04/19/2012 10:02 AM, SomeDude wrote:
> On Wednesday, 18 April 2012 at 19:43:50 UTC, Paul D. Anderson wrote:
>> SomeDude: Your outline and especially your emphasis on what a rank
>> beginner needs to know is very good.
>>
>> Would you consider writing it up yourself? Not the whole thing, maybe
>
Am 19.04.2012 20:00, schrieb Dmitry Olshansky:
On 19.04.2012 21:27, David wrote:
I am having a problem with my Pull-Request, I don't know how I can do
that:
https://github.com/D-Programming-Language/phobos/pull/482#issuecomment-5070817
I hope you can give me a short intstruction what to do, th
On Thu, 19 Apr 2012 14:17:04 -0400, Andrea Fontana
wrote:
Are there any info about them?
I tought that new std.process would replace the old one in version
2.059, but it seems not...
std.process is being worked on. I'm hoping 2.060
-Steve
On 2012-04-19 16:13, ixid wrote:
I put this here because it's probably a flawed idea. A 'learn' level
suggestion.
At present function arguments that you want to default must go at the
end like so:
int fun(int a = 1, int b = 2, int c = 3)
{
return a + b + c;
}
fun(4); //Modifies a
where the de
On 2012-04-19 20:34, Jacob Carlborg wrote:
On 2012-04-19 16:13, ixid wrote:
I put this here because it's probably a flawed idea. A 'learn' level
suggestion.
At present function arguments that you want to default must go at the
end like so:
int fun(int a = 1, int b = 2, int c = 3)
{
return a +
On Thu, Apr 19, 2012 at 08:17:04PM +0200, Andrea Fontana wrote:
> Are there any info about them?
>
> I tought that new std.process would replace the old one in version
> 2.059, but it seems not...
[...]
The new AA implementation is still in the works. The code is not
finished yet, and even after
Hi, I read http://dlang.org/operatoroverloading.html but in my
code it does not work. I tried to overload '*' binary operator in
my class Algorisme:
[...]
class Algorisme(U,V) {
string nom;
uint versio;
alias V function (U) Funcio;
Funcio funcio;
this(st
On Thursday, 19 April 2012 at 15:48:29 UTC, Namespace wrote:
It seems that i can't cast if i want a const Vector2D, neither
with castFromtObject nor with opCast. If i do it i get a very
long list of compile errors. It's no problem because i can deal
without cast to const but it would be usefull
On 19.04.2012 23:14, Xan wrote:
Hi, I read http://dlang.org/operatoroverloading.html but in my code it
does not work. I tried to overload '*' binary operator in my class
Algorisme:
[...]
class Algorisme(U,V) {
string nom;
uint versio;
alias V function (U) Funcio;
Funcio funcio;
this(string nom,
On Thursday, 19 April 2012 at 19:24:40 UTC, Dmitry Olshansky
wrote:
On 19.04.2012 23:14, Xan wrote:
Hi, I read http://dlang.org/operatoroverloading.html but in my
code it
does not work. I tried to overload '*' binary operator in my
class
Algorisme:
[...]
class Algorisme(U,V) {
string nom;
uin
On Thursday, April 19, 2012 21:14:43 Xan wrote:
> Hi, I read http://dlang.org/operatoroverloading.html but in my
> code it does not work. I tried to overload '*' binary operator in
> my class Algorisme:
>
> [...]
> class Algorisme(U,V) {
> string nom;
> uint versio;
> alias V function (U) Funcio;
On Wednesday, 18 April 2012 at 17:28:16 UTC, Jonathan M Davis
wrote:
Ideally, you'd also have a template constraint restricting the
cast to the
types that you want to be able to cast to, but since you're
dealing with a
templated type, that can be a bit tricky. One (somewhat ugly)
option would b
On Thursday, 19 April 2012 at 16:26:19 UTC, Timon Gehr wrote:
On 04/19/2012 03:27 PM, Russel Winder wrote:
The program:
import std.concurrency ;
import std.stdio ;
/*immutable*/ struct X { int i ; }
void printI ( ) {
receive (
( X x
On Thursday, 19 April 2012 at 18:34:41 UTC, Jacob Carlborg wrote:
Named arguments would probably be better for this.
fun(c = 5);
Maybe so, but `fun(c = 5);` is not an additive change, while the
OP's suggestion actually is.
T opCast(T : const(Vector2D!U), U)() const
{
return new T(x, y);
}
Awesome, now i only need this three and it works perfect.
typeof(this) opCast(T)() if
(isImplicitlyConvertible!(typeof(this), T)) {
writeln("implicit cast");
return this;
}
const(typeof(this)) opCast(T)()
On Thursday, April 19, 2012 23:06:58 Jakob Ovrum wrote:
> T opCast(T : const(Vector2D!U), U)() const
> {
> return new T(x, y);
> }
Cool. That's definitely better. I definitely need to improve my template-foo
with regards to :.
- Jonathan M Davis
On 04/19/2012 11:11 PM, Jakob Ovrum wrote:
Fixing std.concurrency entails fixing std.variant which entails fixing
std.typecons.Rebindable by moving its functionality into the language
where it belongs.
https://github.com/D-Programming-Language/dmd/pull/3
This one has been lurking around foreve
On Thursday, 19 April 2012 at 21:33:46 UTC, Timon Gehr wrote:
Unfortunately the patch is incomplete. (template parameter
matching is not implemented afaik and it does not work for
structs)
Ah, didn't know about the template blocker, but how should it
work for structs? Shouldn't the syntax onl
On 04/19/2012 11:55 PM, Jakob Ovrum wrote:
On Thursday, 19 April 2012 at 21:33:46 UTC, Timon Gehr wrote:
Unfortunately the patch is incomplete. (template parameter matching is
not implemented afaik and it does not work for structs)
Ah, didn't know about the template blocker, but how should it
In the same vein, I have getting nothing on the screen when there
should be rendered a red triangle. The vertex positions are those
used by McKeeson http://www.arcsynthesis.org/gltut/, being in ndc
fall within the frustum. The code for setting up vao and shaders
is:
module ShaderHub;
import
Can I remove this section from the D docs, in functions? :
"
Local Variables
It is an error to use a local variable without first assigning it a
value. The implementation may not always be able to detect these
cases. Other language compilers sometimes issue a warning for this,
but since it is alwa
On Friday, April 20, 2012 02:53:25 Andrej Mitrovic wrote:
> Can I remove this section from the D docs, in functions? :
>
> "
> Local Variables
> It is an error to use a local variable without first assigning it a
> value. The implementation may not always be able to detect these
> cases. Other lan
On Thursday, 19 April 2012 at 12:39:25 UTC, SomeDude wrote:
On Thursday, 19 April 2012 at 11:38:39 UTC, Steven
Schveighoffer wrote:
On Thu, 19 Apr 2012 04:07:00 -0400, Jonathan M Davis
wrote:
Having an assertion may be desirable, but the bug is in the
usage of iota, not
iota itself.
Yes,
On 03/04/12 02:24, Cristi Cobzarenco wrote:
Mixins templates would be the answer:
OK, I've had a go at writing up some mixin template-based policy code of my own.
However ... it winds up with compilation errors that I can't decipher:
mixin.d(55): Error: type MyStruct!(ulong,GenOne,WriteOne)
On 4/20/12, Joseph Rushton Wakeling wrote:
> void main()
> {
> auto oneOne = MyStruct!(size_t, GenOne, WriteOne);
> auto oneTwo = MyStruct!(double, GenOne, WriteTwo);
> auto threeOne = MyStruct!(double, GenThree, WriteOne);
> auto threeTwo = MyStruct!(long, GenThree, WriteT
On 20/04/12 04:41, Andrej Mitrovic wrote:
You're doing the equivalent of:
auto one = Foo;
but you need:
auto one = Foo();
Ah, clear. I'm an idiot -- I wrote my own constructor requiring a number as
input!
That said, I'm surprised that it accepts the () given that the constructor does
ask fo
On 4/20/12, Joseph Rushton Wakeling wrote:
> That said, I'm surprised that it accepts the () given that the constructor
> does
> ask for a number.
You can use:
@disable this();
But it doesn't work in all cases:
struct Foo
{
@disable this();
this(int i) { }
}
void main()
{
Foo foo;
64 matches
Mail list logo
