Al 21/04/12 16:42, En/na Tyro[17] ha escrit:
> Actually, in that case it only happens when compiling to 64-bit.
>
> Note: comb1(BigInt(40), BigInt(20))/2; The the BigInt version is
> being divided by two (on MAC OS X) in order to yield the
> correct result.
>
You are right, sorry.
My test was d
On Thursday, 13 February 2014 at 16:37:20 UTC, Andre wrote:
Hi,
could you have a look whether this is a bug with tupleof?
In case you have a const string with a default value,
the attribute is not in the tupleof list.
struct A {
const string a = "abc";
string d;
}
Am 13.02.2014 17:42, schrieb Tobias Pankrath:
On Thursday, 13 February 2014 at 16:37:20 UTC, Andre wrote:
Hi,
could you have a look whether this is a bug with tupleof?
In case you have a const string with a default value,
the attribute is not in the tupleof list.
struct A {
const string a
Andre:
could you have a look whether this is a bug with tupleof?
In case you have a const string with a default value,
the attribute is not in the tupleof list.
struct A {
const string a = "abc";
string d;
}
void main(){
assert(A().tupleof.length == 2)
Am 13.02.2014 17:52, schrieb bearophile:
Andre:
could you have a look whether this is a bug with tupleof?
In case you have a const string with a default value,
the attribute is not in the tupleof list.
struct A {
const string a = "abc";
string d;
}
void main(){
On Thursday, 13 February 2014 at 16:52:58 UTC, bearophile wrote:
Andre:
could you have a look whether this is a bug with tupleof?
In case you have a const string with a default value,
the attribute is not in the tupleof list.
struct A {
const string a = "abc";
On Thursday, 13 February 2014 at 16:57:19 UTC, John Colvin wrote:
Don't you mean const/immutable fields with initialisers don't
become instance fields? Or is this actually as strange as it
sounds?
Yes, it is legacy behavior (== bug) that persisted since D1 days
and was addr
y behavior (== bug) that persisted since D1
days and was addressed only recently. Until this
deprecation/transition process will end this:
struct X
{
const string value = "literal";
}
is effectively same as this:
struct X
{
enum value = "literal";
}
To be anal, it's
Hi everyone,
I was trying to get my vector struct to use extensively
references for passing parameters and I found a subtle bug which
make me lose a few hour.
A sample code that shows the bug is here
http://pastebin.com/rvcNdjAE (fails with dmd 2.064 on linux)
I think that the code is wrong
On Saturday, 12 April 2014 at 19:34:11 UTC, Daniel K wrote:
This block of code fails the second assert, why?
Because DList is buggy. It should pass.
I have an open pull that fixes this, FYI.
On Sat, 26 Apr 2014 06:55:38 +
Domain via Digitalmars-d-learn
wrote:
> module test;
>
> public interface I
> {
> void foo();
> void foo(int);
> }
>
> public abstract class A : I
> {
> public void bar()
> {
> foo();
> }
>
> public void foo(int i)
>
On 4/26/14, Jonathan M Davis via Digitalmars-d-learn
wrote:
> No. That's expected.
I wonder whether a better diagnostic could help. But then again, maybe
the hiding would be intentional and the diagnostic would be
spurious/invalid. Not sure..
Hello,
I was playing around with indexOf when I noticed that the
parameter CaseSensitive seems to have a weird behavior.
Let's say the following code:
string str = "Les chemises sont sèches";
write(std.string.indexOf(str, "Les")); // Returns 0, as expected
write(std.string.indexOf(str, "les",
On Monday, 16 July 2012 at 17:02:52 UTC, Lemonfiend wrote:
[DMD32 D Compiler v2.059]
Hello,
I was rewriting some code so some large data array was a
separate data file, and got an abnormal program termination,
with the error:
C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(2704): Error:
On Monday, July 16, 2012 19:02:48 Lemonfiend wrote:
> According to the bugzilla referenced in the error this was fixed;
> perhaps not?
The commit date for the fix is after the release of 2.059, so presumably, it
works just fine with git master.
- Jonathan M Davis
On Monday, 16 July 2012 at 19:46:21 UTC, Jonathan M Davis wrote:
On Monday, July 16, 2012 19:02:48 Lemonfiend wrote:
According to the bugzilla referenced in the error this was
fixed;
perhaps not?
The commit date for the fix is after the release of 2.059, so
presumably, it
works just fine wi
On 07-Aug-12 16:06, Andrea Fontana wrote:
dmd 2.060 64bit ubuntu:
// Doesn't work:
auto r = ctRegex!(r"/api/places/(id|related|search|count)\.(json|xml)",
"g");
Could be. It is experimental and is known to have bugs.
What is the exact problem statement?
// Works:
auto r = regex(r"/api/place
import std.regex;
void main() {
auto r = ctRegex!(r"/a/b/(c|d|e|f)", "g");
}
This simple app fails at compile time.
Online compiler says:
/usr/local/include/dmd2/std/regex.d(1150): Error:
assert(this.ir[cast(ulong)orStart].code() == cast(IR)129u) failed
/usr/local/include/dmd2/std/regex.d(8
On 08-Aug-12 11:28, Andrea Fontana wrote:
import std.regex;
void main() {
auto r = ctRegex!(r"/a/b/(c|d|e|f)", "g");
}
This simple app fails at compile time.
( it's not that simple ;) )
But it's "been there, seen that". In short:
assert(this.ir[cast(ulong)orStart].code() == cast(IR)129
On Saturday, 29 September 2012 at 16:05:03 UTC, ixid wrote:
This behaviour seems inconsistent and unintuitive:
void main() {
int[3] a = [1,2,3];
a = [4, a[0], 6];
struct S {
int a, b, c;
}
S s = S(1,2,3);
s = S(4, s.a, 6);
the assignment expression can possibly lead to
this result. This seems to be a DMD bug.
On Saturday, 29 September 2012 at 18:16:24 UTC, Timon Gehr wrote:
This seems to be a DMD bug.
And a pretty serious looking one at that. That bug could make
nukes fly to wrong coordinates, and that just ruins everybody's
day.
ession.
But that mutation is happening to an object that is also being read
inside the same expression.
This is one of the definitions of undefined behavior, not a compiler bug.
>> Statement s = S(4, s.a, 6) writes to s object and simultaneously reads
>> it.
>> http://dlang.org/ex
".
>
> There is only one mutating sub-expression.
But that mutation is happening to an object that is also being read
inside the same expression.
This is one of the definitions of undefined behavior, not a compiler bug.
>> Statement s = S(4, s.a, 6) writes to s object an
MD 2.0.60. GDC does what I'd
>> >>> expect and gives both as 4,1,6.
>> >>
>> >> I think this is notorious "i = ++i + ++i".
>> >
>> > There is only one mutating sub-expression.
>>
>> But that mutation is happeni
e
>> >>> is true of the array assignment. Using DMD 2.0.60. GDC
does what I'd
>> >>> expect and gives both as 4,1,6.
>> >>
>> >> I think this is notorious "i = ++i + ++i".
>> >
>> > There is only one mutating sub-
gt; >>> expect and gives both as 4,1,6.
>> >> >>
>> >> >> I think this is notorious "i = ++i + ++i".
>> >> >
>> >> > There is only one mutating sub-expression.
>> >>
>> >> But that mu
, or the
second and the first. In any case it can store value only after
evaluations of both operands which means that value 4 cannot be
assigned to s.a when S(4, s.a, 6) is evaluated. Actually, it is a
bug.
I've filed the following bug: see Issue 8854
(http://d.puremagic.com/issues/show_bug.cgi?id=8854)
I'm curious as to what could cause such a bug, which disappears
when doing any of the following seemingly innocuous changes, such
as change a file name, change an import path, removing a
empty : 7FFFBD429B74
front : 7FFFBD429B74
popFront: 7FFFBD429B74
empty : 7FFFBD429B74
front : 7FFFBD429B74
popFront: 7FFFBD429B74
empty : 7FFFBD429B74
Ali
is normal or is a bug ?
nge :
>> > foreach( state, letter; fastq )
>> > and if fastq instance is called into this loop as done at
>> line 181 is
>> > not the same instance
>>
>> Correct.
> is normal or is a bug ?
It is not a bug. Here is a discussion on the topic:
http://forum
On Thursday, 31 January 2013 at 22:20:25 UTC, Ali Çehreli wrote:
This is not related to your actual problem but I have noticed
that you have side-effects in your FastqReader.front. I think
you will benefit from a design where front simply returns the
front element and all of the side-effects ar
On 01/31/2013 02:27 PM, bioinfornatics wrote:
> On Thursday, 31 January 2013 at 22:20:25 UTC, Ali Çehreli wrote:
>> This is not related to your actual problem but I have noticed that you
>> have side-effects in your FastqReader.front. I think you will benefit
>> from a design where front simply re
Apparently I didn't understand the code. :)
My comments should be generally correct: Calling front()
multiple times should return the same element and it should not
change the state of the range.
Ali
my code works like you said you ca
Apparently I didn't understand the code. :)
My comments should be generally correct: Calling front()
multiple times should return the same element and it should not
change the state of the range.
Ali
My code works like you said you can call front multiple time he
will return same thing.
My code works like you said you can call front multiple time he
will return same thing. I check in front the letter return to
set or not the state and the section number. this maye should
move to popFront.
To explain, i iterate over a fastq file with a memory mapped
file. Then i iterate letter by
On Friday, 1 February 2013 at 09:09:10 UTC, bioinfornatics wrote:
As i use a memory mapped file i won't copy my struct for able to
loop as i do not want map the file twice that is rather a big
problem for a big file this a perf issue. memory mapped file is
used to read fastly a file so is a nonse
On Friday, 1 February 2013 at 09:09:10 UTC, bioinfornatics wrote:
As i use a memory mapped file i won't copy my struct for able to
loop as i do not want map the file twice that is rather a big
problem for a big file this a perf issue. memory mapped file is
used to read fastly a file so is a nonse
> Hex digits are parsed there. So unles this is something special,
> this is a bug. Because for example what 'J' would mean in this
> context?
Looks like a bug. The last clause of the if-condition should check <=
'F', not <= 'Z'.
Please file a bug at http://d.puremagic.com/issues .
T
--
GEEK = Gatherer of Extremely Enlightening Knowledge
14-Feb-2013 22:24, Lubos Pintes пишет:
Hi,
I am reading std.regex. I found the following code on line 671:
else if('A' <= current && current <= 'Z')
val = val * 16 + current - 'A' + 10;
Hex digits are parsed there. So unles this
Yes, because dmd in some cases unexpectedly inserts temporaries.
http://d.puremagic.com/issues/show_bug.cgi?id=9334
http://d.puremagic.com/issues/show_bug.cgi?id=9335
phabricator looks pretty decent for code review, bug tracking etc. It was
created at facebook and is used by many other companies; it's actively
maintained and developed.
It could be a good replacement for bugzilla and other components.
assembly, and I (and maybe
he also) have no good debugger, I like to ask for help to find
and reduce the bug.
The regarding post with the example code is here:
http://dblog.aldacron.net/forum/index.php?topic=832.msg1011#msg1011
If you write the scope(exit) glPopAttrib(mask); without the scope
I saw this Tip of the Week a while ago
(http://arsdnet.net/this-week-in-d/2017-mar-12.html) and was kind
of perplexed at it. It seems like a crazy potential bug... How
exactly is the GC implemented that causes this problem to crop
up? Does the GC just blindly scan memory until it finds
I am using dirEntries to iterate over files to rename them.
I am renaming them in a loop(will change but added code for
testing).
In DMD the renaming works but in LDC the renaming fails. It fails
in a way that I can't quite tell and I cannot debug because
visual D is not working properly fo
The snippet below failed to compile (I think) in the latest DMD -
but I can't see the error message in the web-based editor at
dlang.org. It certainly failed to compile under GDC 5.2.0 when
tried out using d.godbolt.org. (Is there any chance of a later
GDC compiler there?)
Is it my bug,
Nothing new here but I almost fell prey to this bug today. Spot the bug:
import std.stdio;
import std.range;
int[3] bar() {
return [ 1, 2, 3 ];
}
auto foo() {
auto a = bar();
return zip(a[], a[]);
}
void main() {
writeln(foo());
}
In the real code, bar() was a call to
On Thursday, 5 October 2017 at 21:48:20 UTC, WhatMeWorry wrote:
With writing files, that's usually a permissions thing? But
all the other 8 packages build fine?
Note: I had a similar problem with derelict-assimp3 package, so
I went to an entirely different system and cloned my project.
But
On Friday, 6 October 2017 at 09:12:09 UTC, Mike Parker wrote:
On Thursday, 5 October 2017 at 21:48:20 UTC, WhatMeWorry wrote:
AppData/Roaming/dub/packages, create a new directory off C:
(say, C:\dub, manually fetch the packages you need into that
directory and use `dub add-local` on them (see
On Thursday, 5 October 2017 at 21:48:20 UTC, WhatMeWorry wrote:
I've got a github project and using DUB with DMD and I keep
running into this problem. I've tried deleting the entire
...\AppData\Roaming\dub\packages folder, but the
problem repeats the very next build attempt.
[...]
See my p
es the fix.
If it does, it will be the best timed bug fix ever :)
s issue. But
I'll hold off now and see if your change does the fix.
If it does, it will be the best timed bug fix ever :)
Turned out to be more fiddly than I hoped because of unicode.
Atila did the work, but it's awaiting a pre-review to be sure
it's okay before submitting.
Hi all,
Let's say we have this code:
struct B
{
int a;
this(int a) immutable
{
this.a = 7;
}
this(int a)
{
this.a = 10;
}
}
void main()
{
B a = immutable B(2);
writeln(a.a);
a.a = 4;
immutable B a2 = immutable B(3);
writeln(a2.a)
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 declara
On 08/30/2016 10:25 AM, WhatMeWorry wrote:
Error: module std.string import 'removeChars' not found, did you mean
template 'removechars(S)(S s, in S pattern) if (isSomeString!S)'?
Shouldn't it be removeChars? All the other library calls seem to be
camelCased. Should i not bother to open a change
Unexpected auto-concatenation of string elements:
string[] arr = ["a", "b" "c"];// ["a", "bc"], length==2
int[] arr2 = [[1], [2] [3]];// Error: array index 3 is out
of bounds [2][0 .. 1]
// Error: array index 3 is out
of bounds [0..1]
dmd 2.071.2-b2
sadly, gdc has way older frontend version than ldc (and dmd, of
course). gdc is like 2.067, and ldc/dmd is 2.072. that this was
fixed in later versions, but gdc is not updated yet.
On Thursday, 13 October 2016 at 20:18:31 UTC, ketmar wrote:
sadly, gdc has way older frontend version than ldc (and dmd, of
course). gdc is like 2.067, and ldc/dmd is 2.072. that this was
fixed in later versions, but gdc is not updated yet.
OK that's cool, I'll just avoid GDC for now. Is it ge
On Thursday, 13 October 2016 at 20:22:51 UTC, Peter Campbell
wrote:
OK that's cool, I'll just avoid GDC for now. Is it generally a
good approach to assume if something compiles in DMD then it's
correct and just hope that GDC/LDC pick up the latest version
at some point?
mostly yes. btw, ldc h
Is this a bug or a case of hijacking protection ?
struct S
{
void test(void*, size_t){}
}
void test(ref S,void[]){}
void main()
{
ubyte[] a;
(*new S).test(a);
}
showing
the bug?
https://github.com/CyberShadow/DustMite
On Sunday, 6 November 2016 at 01:11:34 UTC, Alex wrote:
dub dustmite ../dm2 --program-status=11
Try --program-status=139
(139 is 128 + 11)
On Saturday, 5 November 2016 at 22:38:31 UTC, cym13 wrote:
Could you use DustMite to generate a minimal code sample
showing the bug?
https://github.com/CyberShadow/DustMite
tried
dub dustmite ../dm
which reduced my code to an empty main... :)
and tried
dub dustmite ../dm2 --program
On Sunday, 6 November 2016 at 01:13:51 UTC, Vladimir Panteleev
wrote:
Try --program-status=139
(139 is 128 + 11)
tried
dub dustmite ../dm3 --program-status=139
which yields in
object.Exception@DustMite/dustmite.d(270): Initial test fails
(try using --no-redirect for details)
I'm not sure how to pass arbitrary dustmite arguments through dub
to dustmite. `dub dustmite -h' lists arguments.
When dustmite reduces your project to the empty project, maybe
try this from the dustmite website: "You can also surround code
that is not to be removed around the magic words
Dus
On Sunday, 6 November 2016 at 08:48:14 UTC, SimonN wrote:
I'm not sure how to pass arbitrary dustmite arguments through
dub to dustmite. `dub dustmite -h' lists arguments.
When dustmite reduces your project to the empty project, maybe
try this from the dustmite website: "You can also surround
ok... played with the code a little bit.
If I remove the @trusted attribute in line 657 inside atomic.d
everything works as expected...
Any ideas, why it is so?
On Sunday, 6 November 2016 at 15:13:56 UTC, Alex wrote:
ok... played with the code a little bit.
If I remove the @trusted attribute in line 657 inside atomic.d
everything works as expected...
Any ideas, why it is so?
By the way, replacement with @safe works too...
On 11/06/2016 05:00 PM, Alex wrote:
On Sunday, 6 November 2016 at 15:13:56 UTC, Alex wrote:
ok... played with the code a little bit.
If I remove the @trusted attribute in line 657 inside atomic.d
everything works as expected...
Any ideas, why it is so?
By the way, replacement with @safe works
On Sunday, 6 November 2016 at 16:07:54 UTC, ag0aep6g wrote:
On 11/06/2016 05:00 PM, Alex wrote:
On Sunday, 6 November 2016 at 15:13:56 UTC, Alex wrote:
ok... played with the code a little bit.
If I remove the @trusted attribute in line 657 inside atomic.d
everything works as expected...
Any id
On 11/07/2016 12:21 PM, Alex wrote:
On Sunday, 6 November 2016 at 16:07:54 UTC, ag0aep6g wrote:
[...]
Very weird. Would be great if you could provide a test case. Doesn't
need to be minimal.
I would if I would know how... :) the problem is, setting up the
debugger itself was not a simple task
Ok, ok. Here, I pasted the code, minimized as far as I could.
There are 434 lines of code, sorry.
http://pastebin.com/UcZUc79g
The main is empty. This is intended. I still have the
segmentation fault.
Maybe, I have another hint:
If I comment all the attributes in the
private HeadUnshared!(T)
On Monday, 7 November 2016 at 17:12:32 UTC, Alex wrote:
dmd -c -of./app.o -debug -g -gc -O -profile -w ./app.d -vcolumns
dmd -of./app ./app.o -g -gc
Knowing this, I tried to find the option which does the
difference. This was the profile option. So, if I omit it, the
segmentation fault is go
On Monday, 7 November 2016 at 16:55:29 UTC, Alex wrote:
Ok... Another point is, that I'm using dub and trying compiling
my app directly by dmd does not yield the error.
So, I have to attach the compiling commands, which I see, when
tried
dub build --force -v
dmd -c -of./app.o -debug -g -gc -O
On 11/07/2016 06:18 PM, Alex wrote:
On Monday, 7 November 2016 at 17:12:32 UTC, Alex wrote:
dmd -c -of./app.o -debug -g -gc -O -profile -w ./app.d -vcolumns
dmd -of./app ./app.o -g -gc
Knowing this, I tried to find the option which does the difference. This
was the profile option. So, if I om
On Monday, 7 November 2016 at 18:38:14 UTC, ag0aep6g wrote:
I've reduced it to this:
void main() {}
void f()
{
import core.atomic: atomicOp;
shared size_t workUnitIndex;
atomicOp!"+="(workUnitIndex, 1);
}
Which crashes when compiled with -profile. Looks like issue
14511 c
On 12/12/2016 12:15 AM, TheGag96 wrote:
I was porting my Evolutionary Computing homework written in Python over
to D, and I've come across this bug I cannot for the life of me figure out.
https://gitlab.com/TheGag96/evo-pacman/blob/master/source/pacman/tree.d#L139
Not public, please pas
On Sunday, 11 December 2016 at 11:17:50 UTC, rikki cattermole
wrote:
Not public, please pastebin.
https://github.com/TheGag96/evo-pacman/blob/master/source/pacman/tree.d#L135
I just put it on GitHub. No idea why the repo wasn't public even
after I set it to be public...
On 12/12/2016 12:43 AM, TheGag96 wrote:
On Sunday, 11 December 2016 at 11:17:50 UTC, rikki cattermole wrote:
Not public, please pastebin.
https://github.com/TheGag96/evo-pacman/blob/master/source/pacman/tree.d#L135
I just put it on GitHub. No idea why the repo wasn't public even after I
set
On 12/11/2016 12:43 PM, TheGag96 wrote:
On Sunday, 11 December 2016 at 11:17:50 UTC, rikki cattermole wrote:
Not public, please pastebin.
https://github.com/TheGag96/evo-pacman/blob/master/source/pacman/tree.d#L135
I just put it on GitHub. No idea why the repo wasn't public even after I
set
On Sunday, 11 December 2016 at 11:58:39 UTC, ag0aep6g wrote:
Try putting an `assert(childCrossPoint !is otherCrossPoint);`
before the assignment. If it fails, the variables refer to the
same node. That would explain how otherCrossPoint.left gets set.
Furthermore, I think he is calling breed
On Sunday, 11 December 2016 at 11:58:39 UTC, ag0aep6g wrote:
Try putting an `assert(childCrossPoint !is otherCrossPoint);`
before the assignment. If it fails, the variables refer to the
same node. That would explain how otherCrossPoint.left gets set.
Ahh... This led me to it. I was about to sa
I read docs and can't understand what's wrong. Or I am do not
understand it, or there is come mistake.
Let's look at function
https://dlang.org/phobos/std_stdio.html#.File.byLine
auto byLine(Terminator = char, Char = char)(KeepTerminator
keepTerminator = No.keepTerminator, Terminator termina
r(bool flag) {
return flag ? Bar() : Bar(Foo(10), false);
}
then output looks as expected:
10.this(int)
10.this(this)
10.~this()
10.~this()
I'm pretty sure this is a bug. And very bad bug. I spent several
hours looking for it.
What do you think?
Random D user wrote:
How come string* suddenly has a .length property?
due to automatic pointer dereferencing that `.` does. no, not a bug.
On Sunday, 12 March 2017 at 01:55:20 UTC, ketmar wrote:
Random D user wrote:
How come string* suddenly has a .length property?
due to automatic pointer dereferencing that `.` does. no, not a
bug.
Ah... right. Silly me. Of course, since string is actually
immutable(char)[].
That's b
1)
struct T{
void f1(){writeln("default f1");}
void f1(int x){writeln("overload f1");}
}
//main
T().f1();
T().f1(1);
//compiles and output as expected.
2)
mixin template add_function(){
void f1(){writeln("default f1");}
}
struct T{
mixin add_function;
void f1(int x){writeln
Hello all,
Here's an interesting little bug that arises when std.random.uniform is called
using dchar as the variable type:
//
import std.conv, std.random, std.stdio, std.string, std.typetuple;
void
[] buf() { return (_b.ptr)[0..size];}
}
I guess you are using different versions of the front-end.
Zero-length arrays was null before, and it's not null in V. 2.066.
So probably there is no bug, just a little design change for the
better.
Bye,
bearophile
;
char[0] _b;
@property char[] buf() { return (_b.ptr)[0..size];}
}
I guess you are using different versions of the front-end.
Zero-length arrays was null before, and it's not null in V.
2.066.
So probably there is no bug, just a little design chang
Hello,every one:
There is a unit test for a.d,it will be pass,do you think it's
right?
or it's my error?
/// the file name is a.d
class Math
{
/// add function
static int add(int x, int y) { return x + y; }
///
unittest
{
// assert(add(2, 2) == 5);
asse
On Fri, 05 Dec 2014 07:06:34 +
Andre via Digitalmars-d-learn wrote:
> Hi,
>
> following coding fails to compile with 2.066.0 and
> 2.067.0-b1.
>
>
> This is a bug, or?
> source\app.d(9): Error: mixin
> app.Data.insertReadMethods!("readTinyInt",
On Fri, 05 Dec 2014 07:06:34 +
Andre via Digitalmars-d-learn wrote:
> Hi,
>
> following coding fails to compile with 2.066.0 and
> 2.067.0-b1.
>
>
> This is a bug, or?
> source\app.d(9): Error: mixin
> app.Data.insertReadMethods!("readTinyInt",
e:
Hi,
following coding fails to compile with 2.066.0 and
2.067.0-b1.
This is a bug, or?
source\app.d(9): Error: mixin
app.Data.insertReadMethods!("readTinyInt", ubyte)
is not defined
template insertReadMethods(string MethodName, DataType)
{
enum insertReadMethods = &quo
On Fri, 05 Dec 2014 09:19:27 +
Andre via Digitalmars-d-learn wrote:
> I think I mimized the coding too much.
> What I actually want to achieve is to generate read methods
> in the structure for different data types (Ubyte, short, int):
>
> I thought the eponymous trick would insert the cont
thanks a lot. That makes sense.
Kind regards
André
On Friday, 5 December 2014 at 09:29:21 UTC, ketmar via
Digitalmars-d-learn wrote:
On Fri, 05 Dec 2014 09:19:27 +
Andre via Digitalmars-d-learn
wrote:
I think I mimized the coding too much.
What I actually want to achieve is to generat
On 26/12/2014 6:58 p.m., Jack wrote:
Complete error code here: http://codepad.org/KcW7jhXl
Apparently, there exists an incompatibility.
Take note, I just listed tkd as a dependency on my dub.json, and I
haven't really used the library as of the time of its building.
So, is this a bug?
used the library as of the time of its building.
So, is this a bug?
Short answer:
Don't build with ldc.
Long answer:
http://forum.dlang.org/post/m6m5tc$2c4d$1...@digitalmars.com
Grr grr grr.
Grr Grr indeed.
Now to figure out how to switch dub to dmd again.
Thanks
a dependency on my dub.json,
and I
haven't really used the library as of the time of its
building.
So, is this a bug?
Short answer:
Don't build with ldc.
Long answer:
http://forum.dlang.org/post/m6m5tc$2c4d$1...@digitalmars.com
Grr grr grr.
Grr Grr indeed.
Now to figure out how to
I don't know where to write about a bug on the website, so I
decided to write in this section.
This page is not displayed correctly:
http://dlang.org/phobos/std_format.html
901 - 1000 of 1955 matches
Mail list logo
