Re: How to make a logger (possible bug)

On Tuesday, 17 May 2016 at 18:59:31 UTC, Rishub Nagpal wrote: https://dlang.org/phobos/std_experimental_logger_filelogger.html import std.experimental.logger; void main() { auto l1 = new FileLogger("logFile", "loggerName"); } throws an error: Error: none of the overloads of '__ctor'

How to make a logger (possible bug)

https://dlang.org/phobos/std_experimental_logger_filelogger.html import std.experimental.logger; void main() { auto l1 = new FileLogger("logFile", "loggerName"); } throws an error: Error: none of the overloads of '__ctor' are callable using argument types (string, string), candidates

Re: imports && -run [Bug?]

On Friday, 13 May 2016 at 06:33:40 UTC, Jacob Carlborg wrote: Even better is to use "rdmd" which will automatically track and compile dependencies. but i should warn about annoing bug with local import http://forum.dlang.org/post/mailman.1984.1373610213.13711.digitalmar...@puremagic

Re: imports && -run [Bug?]

On 2016-05-13 08:27, Andrew Edwards wrote: I fail to see why the compiler would be less capable at this task than rdmd. Since it is already build to accept multiple input files and knows more about what's going on during compilation than rdmd will ever know, in does not make sense that it

Re: imports && -run [Bug?]

On 2016-05-13 08:10, tsbockman wrote: According to the DMD compiler manual, the -run switch only accepts a single source file: -run srcfile args... After the first source file, any further arguments passed to DMD will be interpreted as arguments to be passed to the program being run. To

Re: imports && -run [Bug?]

On 5/13/16 3:10 PM, tsbockman wrote: On Friday, 13 May 2016 at 01:16:36 UTC, Andrew Edwards wrote: command: dmd -run mod inc output: Undefined symbols for architecture x86_64: "_D3inc5printFZv", referenced from: __Dmain in mod.o ld: symbol(s) not found for architecture x86_64 clang:

Re: imports && -run [Bug?]

On Friday, 13 May 2016 at 01:16:36 UTC, Andrew Edwards wrote: command: dmd -run mod inc output: Undefined symbols for architecture x86_64: "_D3inc5printFZv", referenced from: __Dmain in mod.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit

imports && -run [Bug?]

module mod; // import inc; [1] // import inc: p=print; [1] // static import inc; [1] void main() { // import inc: print; // [2] print(); // static import inc; // [3] // inc.print(); } -- module inc; /*public*/ void print() // [4] { import

Re: Is this template constraint a bug?

Yes, it's a bug. Please file an issue. Meanwhile try this workaround: class A(T) { static assert(is(T : A!T), "..."); } Bug report filed, and thanks for the workaround. -Eric

Re: Is this template constraint a bug?

On Thursday, 12 May 2016 at 15:33:24 UTC, Eric wrote: is(T : A!T) tells if T can automatically be converted to A!T. The last line below is doing just that, yet the template constraint does not work. class A(T) if (is(T : A!T)) { } Yes, it's a bug. Please file an issue. Meanwhile try

Is this template constraint a bug?

is(T : A!T) tells if T can automatically be converted to A!T. The last line below is doing just that, yet the template constraint does not work. class A(T) if (is(T : A!T)) { } // if (is(T : A!T)) gives this error: // Error: template instance x.A!(B) does not match //template

Is it bug compiler?

Windows 7 32bit --- import std.stdio; import std.conv; class CFormaMain { ~this() { char[] zz = [ 'A', 'B', 'C' ]; writeln(to!string(zz)); } } int main(string[] args) { CFormaMain formaMain; formaMain = new

Re: Is it bug compiler?

On 5/12/16 9:20 AM, MGW wrote: Windows 7 32bit --- import std.stdio; import std.conv; class CFormaMain { ~this() { char[] zz = [ 'A', 'B', 'C' ]; This allocates. Allocations are not allowed in GC collection cycle. -Steve

Re: Is it bug compiler?

On Thursday, 12 May 2016 at 13:20:35 UTC, MGW wrote: Windows 7 32bit --- import std.stdio; import std.conv; class CFormaMain { ~this() { char[] zz = [ 'A', 'B', 'C' ]; writeln(to!string(zz)); } } int main(string[] args) {

Re: Is this a bug?

On Saturday, April 16, 2016 00:28:46 ag0aep6g via Digitalmars-d-learn wrote: > On 15.04.2016 20:55, Eric wrote: > > 13 class C : const (I!(J)) > > I think this const is ignored by the compiler. It's definitely ignored, and I'd argue that it's a bug in the compiler that it'

Re: Is this a bug?

On 15.04.2016 20:55, Eric wrote: 13 class C : const (I!(J)) I think this const is ignored by the compiler. 15F!(J) m; A little tip: You can omit the parentheses of template instantiations when the argument is a single identifier. That is, `F!(J)` can be written as `F!J`.

Re: Is this a bug?

On Friday, 15 April 2016 at 18:28:58 UTC, Eric wrote: line 6 can be fixed like this: "const I!(J) i = a;" Now if I can just figure out how to fix line 15... This works: 1 alias J = const C; 2 3 void main(string[] args) 4 { 5 J a = new C(); 6 const (I!(J)) i = a; 7 } 8

Re: Is this a bug?

On Friday, 15 April 2016 at 18:22:02 UTC, Eric wrote: On Friday, 15 April 2016 at 17:43:59 UTC, ag0aep6g wrote: On 15.04.2016 19:13, Eric wrote: 1 alias J = const C; 2 3 void main(string[] args) 4 { 5 J a = new C(); 6 I!(J) i = a; 7 } 8 9 interface I(V) { }

Re: Is this a bug?

On Friday, 15 April 2016 at 17:43:59 UTC, ag0aep6g wrote: On 15.04.2016 19:13, Eric wrote: 1 alias J = const C; 2 3 void main(string[] args) 4 { 5 J a = new C(); 6 I!(J) i = a; 7 } 8 9 interface I(V) { } 10 11 class F(V) if (is(V : I!(V))) { } 12 13

Re: Is this a bug?

On 15.04.2016 19:13, Eric wrote: 1 alias J = const C; 2 3 void main(string[] args) 4 { 5 J a = new C(); 6 I!(J) i = a; 7 } 8 9 interface I(V) { } 10 11 class F(V) if (is(V : I!(V))) { } 12 13 class C : I!(J) 14 { 15 F!(J) m; 16 } The above

Is this a bug?

1 alias J = const C; 2 3 void main(string[] args) 4 { 5 J a = new C(); 6 I!(J) i = a; 7 } 8 9 interface I(V) { } 10 11 class F(V) if (is(V : I!(V))) { } 12 13 class C : I!(J) 14 { 15 F!(J) m; 16 } The above code gives the following compile error: Error:

Re: Possible bug in RVO?

s like a bug. Just to make it more visible: auto clobber(ref Set x, ref Set o) { writefln("entered clobber- x.aa: %s", x.aa); Set ret; writefln("did not touch x.aa - x.aa: %s", x.aa); ret.aa = x.aa; return ret; } x.aa changes during the second call: ent

Re: Possible bug in RVO?

rn ret; } No idea myself but that's where it seems to go wrong. Looks like a bug. Just to make it more visible: auto clobber(ref Set x, ref Set o) { writefln("entered clobber- x.aa: %s", x.aa); Set ret; writefln("did not touch x.aa - x.aa: %s", x.aa); ret

Re: Possible bug in RVO?

On Monday, 4 April 2016 at 03:55:26 UTC, Yuxuan Shui wrote: On Monday, 4 April 2016 at 03:28:01 UTC, Yuxuan Shui wrote: auto clobber(ref Set x, ref Set o) { Set ret; ret.aa = x.aa; assert(x.aa.length > 0); // <-- boom return ret; } No idea myself but that's

Re: Possible bug in RVO?

On Monday, 4 April 2016 at 03:28:01 UTC, Yuxuan Shui wrote: I have encountered a weird bug. I defined a Set class, which has a opBinary!"-". And somehow this: auto tmp = set_a-set_b; produces different results as this: set_a = set_a-set_b; the latter will produce an empty set

Re: Possible bug in RVO?

On Monday, 4 April 2016 at 03:55:26 UTC, Yuxuan Shui wrote: On Monday, 4 April 2016 at 03:28:01 UTC, Yuxuan Shui wrote: I have encountered a weird bug. I defined a Set class, which has a opBinary!"-". And somehow this: auto tmp = set_a-set_b; produces different results as th

Re: Possible bug in RVO?

On Monday, 4 April 2016 at 03:28:01 UTC, Yuxuan Shui wrote: I have encountered a weird bug. I defined a Set class, which has a opBinary!"-". And somehow this: auto tmp = set_a-set_b; produces different results as this: set_a = set_a-set_b; the latter will produce an empty set

Possible bug in RVO?

I have encountered a weird bug. I defined a Set class, which has a opBinary!"-". And somehow this: auto tmp = set_a-set_b; produces different results as this: set_a = set_a-set_b; the latter will produce an empty set. I tried to reduce the source code to get a test case. But thi

Re: Initializing global delegate variable - bug or on purpose?

On Friday, 25 March 2016 at 23:40:37 UTC, data pulverizer wrote: On Friday, 25 March 2016 at 20:54:28 UTC, Atila Neves wrote: int delegate(int) dg = (i) => i * 2; Error: non-constant nested delegate literal expression __lambda3 int delegate(int) dg; static this() { dg = i => i * 2; //

Re: Initializing global delegate variable - bug or on purpose?

On Friday, 25 March 2016 at 20:54:28 UTC, Atila Neves wrote: int delegate(int) dg = (i) => i * 2; Error: non-constant nested delegate literal expression __lambda3 int delegate(int) dg; static this() { dg = i => i * 2; // ok } Am I doing anything wrong? Atila Hmm, looks like your

Initializing global delegate variable - bug or on purpose?

int delegate(int) dg = (i) => i * 2; Error: non-constant nested delegate literal expression __lambda3 int delegate(int) dg; static this() { dg = i => i * 2; // ok } Am I doing anything wrong? Atila

Re: Variant.type bug ?

On Wednesday, 23 March 2016 at 19:18:50 UTC, Chris Wright wrote: Consider the `coerce` method: http://dpldocs.info/experimental-docs/std.variant.VariantN.coerce.html Example: import std.variant; class A {} class B : A {} void main() { A b = new B; auto bb = Variant(b).coerce!B;

Re: Variant.type bug ?

Consider the `coerce` method: http://dpldocs.info/experimental-docs/std.variant.VariantN.coerce.html Example: import std.variant; class A {} class B : A {} void main() { A b = new B; auto bb = Variant(b).coerce!B; assert (bb !is null); }

Re: Variant.type bug ?

On Wednesday, 23 March 2016 at 12:52:24 UTC, Adam D. Ruppe wrote: On Wednesday, 23 March 2016 at 08:01:36 UTC, Voitech wrote: Hi Variant stores variant.type as not the "highest" in hierarchy. Yeah, it stores the static type. You can use it to get that then do a normal dynamic cast to test

Re: Variant.type bug ?

On Wednesday, 23 March 2016 at 08:01:36 UTC, Voitech wrote: Hi Variant stores variant.type as not the "highest" in hierarchy. Yeah, it stores the static type. You can use it to get that then do a normal dynamic cast to test for a more derived type.

Variant.type bug ?

Hi Variant stores variant.type as not the "highest" in hierarchy. Like this A a= new A; A b = new B; //B:A Variant bVar=Variant(b); bVar.type will be typeid(A) not typeid(B). Is this intentional ? If so is there a way to get "concrete" type of "b" variable like when passing to template

Re: Needed return type in static method? bug or feature?

On Tuesday, March 08, 2016 14:56:06 Antonio Corbi via Digitalmars-d-learn wrote: > On Tuesday, 8 March 2016 at 14:13:17 UTC, Adam D. Ruppe wrote: > > On Tuesday, 8 March 2016 at 13:40:06 UTC, Antonio Corbi wrote: > >> Is it a feature or a bug? > > > > It is allo

Re: Needed return type in static method? bug or feature?

On Tuesday, 8 March 2016 at 14:13:17 UTC, Adam D. Ruppe wrote: On Tuesday, 8 March 2016 at 13:40:06 UTC, Antonio Corbi wrote: Is it a feature or a bug? It is allowed because the "auto" keyword doesn't actually required for auto functions (or variables), what you need i

Re: Needed return type in static method? bug or feature?

On Tuesday, 8 March 2016 at 13:40:06 UTC, Antonio Corbi wrote: Is it a feature or a bug? It is allowed because the "auto" keyword doesn't actually required for auto functions (or variables), what you need is any one of the storage classes. Those include static, auto, const, immut

Needed return type in static method? bug or feature?

turn 1; } static sbar () { return "hi!"; } static ibar () { return 0; } } void main () { auto b = new B; writeln (B.sbar); writeln (B.ibar); } -8>< Is it a feature or a bug? I've seen it being used in https://github.com/geck

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 09:05:58 UTC, Ola Fosheim Grøstad wrote: IMO one shouldn't be able to take the reference of a tuple, to ensure that it can be kept in registers. No need to restrict the language here, there's nothing stopping a decent compiler from storing tuples (actually

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 08:35:21 UTC, tsbockman wrote: When faced with a judgment call like this, we really ought to err on the side of maintaining backwards compatibility - especially since this does not preclude adding a separate by-value version of `Tuple.slice`, as well. It was

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 06:22:55 UTC, Marco Leise wrote: As mentioned I never used the feature myself and wont vote for one or the other. Three people with no source code to exemplify current use of .slice! is indeed not much to base decisions on... The mere fact that all I had to do

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 13:43:16 UTC, Marc Schütz wrote: So what? Using that argument, you could just as well forbid taking the address of any variable. What's so special about tuples, in contrast to structs and arrays? Some key common qualities for a tuple: 1. They are primarily used

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 10:54:42 UTC, Marc Schütz wrote: No need to restrict the language here, there's nothing stopping a decent compiler from storing tuples (actually _anything_) in registers, in some cases even if references are taken. I'm pretty sure LLVM can handle this. If you

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 11:38:14 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 9 February 2016 at 10:54:42 UTC, Marc Schütz wrote: No need to restrict the language here, there's nothing stopping a decent compiler from storing tuples (actually _anything_) in registers, in some cases even

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 14:28:35 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 9 February 2016 at 13:43:16 UTC, Marc Schütz wrote: So what? Using that argument, you could just as well forbid taking the address of any variable. What's so special about tuples, in contrast to structs and

Re: Is this a bug in std.typecons.Tuple.slice?

On Tuesday, 9 February 2016 at 09:05:58 UTC, Ola Fosheim Grøstad wrote: I suggest lobbying for proper builtin tuple support. Built-in tuple support would be great (although to my mind, mostly because the current syntax is clunky). But that is a long-term goal, and `Tuple.slice` is corrupting

Re: Is this a bug in std.typecons.Tuple.slice?

On Wednesday, 10 February 2016 at 00:24:56 UTC, tsbockman wrote: [...] `Tuple.slice` is corrupting data *right now*. Some sort of short-term fix should be merged in the next release of D. +1

Re: Bug or intended?

On Saturday, 6 February 2016 at 14:15:04 UTC, rsw0x wrote: I was playing around with alias templates and came across this, I reduced it to: --- struct A(alias C c){ auto foo(){ return c.i; } } struct B{ C c; A!c a; } struct C{ int i; } --- It gives me a "need 'this' for 'i'

Re: Is this a bug in std.typecons.Tuple.slice?

't be > > emphasized enough. > > Although I wish more than 3 people had voted in my poll, two of > them did claim to need the `ref`-ness of `Tuple.slice`, so I > don't think we can just ditch it. (I did not vote.) > > If you guys want to add a return-by-value version, it shou

Re: Is this a bug in std.typecons.Tuple.slice?

the `ref`-ness of `Tuple.slice`, so I don't think we can just ditch it. (I did not vote.) If you guys want to add a return-by-value version, it should be treated as an enhancement, not a bug fix in my opinion.

Re: Bug or intended?

The specification doesn't list (non-static) members a valid template alias parameters: http://dlang.org/spec/template.html#TemplateAliasParameter

Re: Is this a bug in std.typecons.Tuple.slice?

Am Sat, 06 Feb 2016 11:02:37 + schrieb tsbockman : > On Saturday, 6 February 2016 at 08:47:01 UTC, Saurabh Das wrote: > > I think we should add a static assert to slice to ensure that > > the current implementation is not used in a case where the > > alignment

Re: Is this a bug in std.typecons.Tuple.slice?

On Sunday, 7 February 2016 at 02:51:49 UTC, tsbockman wrote: We should start a new thread in "General" to ask whether people care about the `ref`-ness of `Tuple` slices is really the deciding factor. I made a poll: http://forum.dlang.org/post/inswmiscuqirkhfql...@forum.dlang.org

Re: Is this a bug in std.typecons.Tuple.slice?

On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote: I understand that. We just have a different perspective on the problem. Your priorities: - don't break what's not broken - .slice! lends on opSlice and should return by ref My priorities: - type of .slice! should be as if

Re: Is this a bug in std.typecons.Tuple.slice?

On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote: Why do I insist on the return type? Because surprisingly simple code breaks if it doesn't match. Not everything can be covered by runtime conversions in D. It still took me a while to come up with something obvious:

Re: Is this a bug in std.typecons.Tuple.slice?

On Sunday, 7 February 2016 at 02:51:49 UTC, tsbockman wrote: On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote: I understand that. We just have a different perspective on the problem. Your priorities: - don't break what's not broken - .slice! lends on opSlice and should return by

Re: Is this a bug in std.typecons.Tuple.slice?

Am Sat, 06 Feb 2016 07:57:08 + schrieb tsbockman : > On Saturday, 6 February 2016 at 06:34:05 UTC, Marco Leise wrote: > > I don't want to sound dismissive, but when that thought came > > to my mind I considered it unacceptable that the type of > > Tuple!(int, bool,

Re: Is this a bug in std.typecons.Tuple.slice?

On Saturday, 6 February 2016 at 06:34:05 UTC, Marco Leise wrote: [...] I should also point out that, since there is no way to actually find out whether anyone is using the `ref`-ness of the return type in the wild, the approach that you and Saurabh Das are taking really ought to include

Re: Bug or intended?

I'd say support for this scenario is not implemented yet.

Re: Is this a bug in std.typecons.Tuple.slice?

On Saturday, 6 February 2016 at 06:34:05 UTC, Marco Leise wrote: I don't want to sound dismissive, but when that thought came to my mind I considered it unacceptable that the type of Tuple!(int, bool, string).slice(1, 3) would be something different than Tuple!(bool, string). In your case

Bug or intended?

I was playing around with alias templates and came across this, I reduced it to: --- struct A(alias C c){ auto foo(){ return c.i; } } struct B{ C c; A!c a; } struct C{ int i; } --- It gives me a "need 'this' for 'i' of type 'int'" error.

Re: Is this a bug in std.typecons.Tuple.slice?

On Saturday, 6 February 2016 at 08:47:01 UTC, Saurabh Das wrote: I think we should add a static assert to slice to ensure that the current implementation is not used in a case where the alignment doesn't match. This is better than failing without any warning. If we pursue the deprecation

Re: Is this a bug in std.typecons.Tuple.slice?

On Saturday, 6 February 2016 at 08:01:20 UTC, tsbockman wrote: On Saturday, 6 February 2016 at 06:34:05 UTC, Marco Leise wrote: [...] I should also point out that, since there is no way to actually find out whether anyone is using the `ref`-ness of the return type in the wild, the approach

Re: Is this a bug in std.typecons.Tuple.slice?

ting > > cast which doesn't work in general. This will change the > > semantics. Now the caller of 'slice' will deal with a whole new > > copy of everything in the returned slice instead of a narrower > > view into the original data. But that's a needed change to fix >

Re: Is this a bug in std.typecons.Tuple.slice?

hich doesn't work in general. This will change the semantics. Now the caller of 'slice' will deal with a whole new copy of everything in the returned slice instead of a narrower view into the original data. But that's a needed change to fix the bug. > > 2. Adding 'const' to the function signature

Re: Is this a bug in std.typecons.Tuple.slice?

opy of everything in the returned slice instead of a narrower view into the original data. But that's a needed change to fix the bug. Actually, it's not: https://github.com/D-Programming-Language/phobos/pull/3973 All that is required is to include a little padding at the beginning of the sl

Re: Is this a bug in std.typecons.Tuple.slice?

On Friday, 5 February 2016 at 19:16:11 UTC, Marco Leise wrote: Am Fri, 05 Feb 2016 05:31:15 + schrieb Saurabh Das : [...] That is enlightening. I have updated the PR at https://github.com/D-Programming-Language/phobos/pull/3975 to incorporate these changes.

Is this a bug in std.typecons.Tuple.slice?

dylib 0x7fff8a1345c8 start + 0 14 ??? 0x 0x0 + 0 Why does 'u1' behave differently? I'm thinking it's a bug, but I haven't worked much with tuples, so maybe I'm missing something? Thanks, Saurabh

Re: Is this a bug in std.typecons.Tuple.slice?

On Thursday, 4 February 2016 at 17:52:16 UTC, Marco Leise wrote: https://issues.dlang.org/show_bug.cgi?id=15645 Thank you. I understood why this is happening from your explanation in the bug report.

Re: Is this a bug in std.typecons.Tuple.slice?

On Thursday, 4 February 2016 at 12:28:39 UTC, Saurabh Das wrote: This code: [...] Update: Simplified, this also doesn't work: void main() { import std.typecons; auto tp = tuple(10, false, "hello"); auto u0 = tp.slice!(0, tp.length); auto u1 = tp.slice!(1, tp.length); auto

Re: Is this a bug in std.typecons.Tuple.slice?

On Thursday, 4 February 2016 at 17:52:16 UTC, Marco Leise wrote: https://issues.dlang.org/show_bug.cgi?id=15645 Is this a possible fixed implementation? : @property Tuple!(sliceSpecs!(from, to)) slice(size_t from, size_t to)() @trusted const if (from <= to && to <=

Re: Is this a bug in std.typecons.Tuple.slice?

On Friday, 5 February 2016 at 05:18:01 UTC, Saurabh Das wrote: [...] Apologies for spamming. This is an improved implementation: @property Tuple!(sliceSpecs!(from, to)) slice(size_t from, size_t to)() @safe const if (from <= to && to <= Types.length) {

Re: Is this a bug in std.typecons.Tuple.slice?

On Friday, 5 February 2016 at 05:18:01 UTC, Saurabh Das wrote: [...] PS: Additionally, '@trusted' can now be substituted with '@safe'.

Re: Is this a bug in std.typecons.Tuple.slice?

https://issues.dlang.org/show_bug.cgi?id=15645

Re: Is this a bug in std.typecons.Tuple.slice?

atic assert(is(typeof(u1) == Tuple!(bool, string))); > static assert(is(typeof(u2) == Tuple!(string))); > > assert(u2[0] == "hello"); > assert(u0[2] == "hello"); > assert(u1[1] == "hello");// This fails > } > > rdmd er

Can't add ubytes together to make a ubyte... bug or feature?

implicitly convert expression (cast(int)a + cast(int)b) of type int to ubyte On principal I'm not casting to fix this. I don't care if my computer needs to do math on a 4 byte basis, I'm not writing assembly. I'm really hoping this is a bug because trying to use any type other than ints is going

Re: Can't add ubytes together to make a ubyte... bug or feature?

a + b; can't works because b could be 255 and 255 + 1 does not fit to ubyte > On principal I'm not casting to fix this. I don't care if my  > computer needs to do math on a 4 byte basis, I'm not writing  > assembly. I'm really hoping this is a bug because trying to use  > any type ot

Re: Can't add ubytes together to make a ubyte... bug or feature?

On Tue, 19 Jan 2016 23:32:57 +0100, Daniel Kozak wrote: > Soviet Friend píše v Út 19. 01. 2016 v 22:12 +: >> I just attempted to add one ubyte to another and store the result in a >> ubyte but apparently ubytes get converted to ints when being added... >> and converting what becomes an int

Re: Can't add ubytes together to make a ubyte... bug or feature?

On 01/19/2016 02:12 PM, Soviet Friend wrote: > ubytes get converted to ints when being added... It's a common feature involving all integral type in languages like C, C++, and D: https://dlang.org/spec/type.html#integer-promotions > On the topic of complaining about casting... array

Re: Can't add ubytes together to make a ubyte... bug or feature?

On Tuesday, 19 January 2016 at 22:12:06 UTC, Soviet Friend wrote: I don't care if my computer needs to do math on a 4 byte basis, I'm not writing assembly. x86 actually doesn't need to do math that way, if you were writing assembly, it would just work. This is just an annoying rule brought

Re: Is this rdmd bug or my fault ?

Can anybody explain: Is dependencies file produced from command: dmd -deps=moduleA.deps moduleA.d must contains mention of moduleC? Is dependencies file produced reccursively? Thanks.

Re: Regression vs Bug

V Thu, 14 Jan 2016 17:32:47 + NX via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> napsáno: > Please explain. Regression: something works before does not work anymore Bug: something does not work as expected (regression is one type of bug)

Regression vs Bug

Please explain.

Re: Bug in csv or byLine ?

On Sunday, 10 January 2016 at 19:50:15 UTC, Tobi G. wrote: On Sunday, 10 January 2016 at 19:07:52 UTC, Jesse Phillips wrote: On Sunday, 10 January 2016 at 18:09:23 UTC, Tobi G. wrote: The bug has been fixed... Do you have a link for the fix? Is there a BugZilla entry? Yes sure.. https

Re: Bug in csv or byLine ?

/include/dlang/dmd/std/csv.d(1246): Row 3's length 1 does not match previous length of 2. I still do not understand half of the syntax(still learning) but my guess is that it is a bug in the csv reader: In https://github.com/D-Programming-Language/phobos/blob/67c95e6de21d5d627e3c57128b4d6e332c82f785

Re: Bug in csv or byLine ?

The bug has been fixed...

Re: Bug in csv or byLine ?

On Sunday, 10 January 2016 at 09:41:16 UTC, Keywan Ghadami wrote: On Friday, 8 January 2016 at 13:53:06 UTC, Guillaume Chatelet wrote: I still do not understand half of the syntax(still learning) but my guess is that it is a bug in the csv reader: In https://github.com/D-Programming-Language

Re: Bug in csv or byLine ?

On Sunday, 10 January 2016 at 18:09:23 UTC, Tobi G. wrote: The bug has been fixed... Do you have a link for the fix? Is there a BugZilla entry?

Re: Bug in csv or byLine ?

On Sunday, 10 January 2016 at 19:07:52 UTC, Jesse Phillips wrote: On Sunday, 10 January 2016 at 18:09:23 UTC, Tobi G. wrote: The bug has been fixed... Do you have a link for the fix? Is there a BugZilla entry? Yes sure.. https://issues.dlang.org/show_bug.cgi?id=15545 and the fix at github

Re: Is this rdmd bug or my fault ?

On Friday, 8 January 2016 at 22:36:49 UTC, Tobi G. wrote: On Saturday, 9 January 2016 at 01:43:57 UTC, Ivan Kazmenko wrote: I get also a compilation error (with rdmd and -g). Thanks Tobi and Ivan. https://issues.dlang.org/show_bug.cgi?id=15533

Re: Is this rdmd bug or my fault ?

On Friday, 8 January 2016 at 15:45:52 UTC, zabruk70 wrote: Should i create bugreport, or this is my mistake? Same here: rdmd moduleA.d works. rdmd -g moduleA.d produces a linker error. What's more: rdmd -m64 -g moduleA.d fails, and rdmd -m64 moduleA.d also fails. I have dmd 2.069.2 here.

Re: Is this rdmd bug or my fault ?

On Friday, 8 January 2016 at 15:45:52 UTC, zabruk70 wrote: Should i create bugreport, or this is my mistake? I get also a compilation error (with rdmd and -g). Fortunately building manually with dmd works. So there has to be a bug in rdmd.. togrue

Bug in csv or byLine ?

$ cat debug.csv timestamp,curr_property 2015-12-01 06:07:55,7035 $ cat process.d import std.stdio; import std.csv; import std.algorithm; import std.file; void main(string[] args) { version (Fail) { File(args[1],

Re: Bug in csv or byLine ?

On Friday, 8 January 2016 at 09:59:26 UTC, Guillaume Chatelet wrote: Any idea ? No, sorry. Under Windows DMD v2.069.2 it works perfectly in both cases. Which compiler do you use? You could run DMD with the -g option. This will print often more useful output, if it fails. togrue

Re: Bug in csv or byLine ?

On Friday, 8 January 2016 at 13:22:40 UTC, Tobi G. wrote: On Friday, 8 January 2016 at 12:13:59 UTC, Guillaume Chatelet wrote: On Friday, 8 January 2016 at 12:07:05 UTC, Tobi G. wrote: No, sorry. Under Windows DMD v2.069.2 it works perfectly in both cases. Which compiler do you use? -

Re: Bug in csv or byLine ?

On Friday, 8 January 2016 at 12:07:05 UTC, Tobi G. wrote: No, sorry. Under Windows DMD v2.069.2 it works perfectly in both cases. Which compiler do you use? - DMD64 D Compiler v2.069.2 on Linux. - LDC 0.16.1 (DMD v2.067.1, LLVM 3.7.0) So if it works on windows I guess it's a problem with

Re: Bug in csv or byLine ?

On Friday, 8 January 2016 at 12:13:59 UTC, Guillaume Chatelet wrote: On Friday, 8 January 2016 at 12:07:05 UTC, Tobi G. wrote: No, sorry. Under Windows DMD v2.069.2 it works perfectly in both cases. Which compiler do you use? - DMD64 D Compiler v2.069.2 on Linux. - LDC 0.16.1 (DMD v2.067.1,

Is this rdmd bug or my fault ?

OS: Windows 7 (32 bit) dmd: 2.069.2 and 2.070.0-b1 Then i used "-g" switch with RDMD, then i have OPTLINK error. Reduced code, 3 modules, 2 of them in subdir: moduleA.d test\moduleB.d test\moduleC.d / module moduleA; public void funcA () { import test.moduleB: funcB; return; }

<    4   5   6   7   8   9   10   11   12   13   >