Sergei Nosov:
T identity(T)(T e) { return e; }
struct S(alias Func)
{
void call()
{
import std.stdio;
writeln(Func("string").length);
}
}
static struct S1
{
alias S!(identity) A1;
//alias S!(x => x) A2;
alias S!(function string (string e) { return e; }) A3
On Thursday, 28 November 2013 at 08:23:22 UTC, bearophile wrote:
Global structs don't need the "static" attribute.
I've thought so, but added it just as a "I really mean, that I
don't need context".
This version of your code gives the output 6 6 on Windows 32
bit:
Do you have a 64-bit OS
Code:
import std.stdio;
import core.stdc.stdlib : calloc, free;
void main() {
readln(); /// ~ 1332 K
void* ptr = .calloc(100_000, int.sizeof);
readln(); /// ~ 1720 K
free(ptr);
ptr = null;
readln(); /// Still ~ 1720 K
}
If I compile t
Sergei Nosov:
Do you have a 64-bit OS at hand?
On 64 bit using dmd 2.064.2 it doesn't give the 6 6 output, so it
seems a 64 bit bug. This happens because the 64 bit version of
dmd is quite more new than the 32 bit version, so it has more
bugs.
Bye,
bearophile
On Thursday, 28 November 2013 at 09:48:47 UTC, bearophile wrote:
Sergei Nosov:
Do you have a 64-bit OS at hand?
On 64 bit using dmd 2.064.2 it doesn't give the 6 6 output, so
it seems a 64 bit bug. This happens because the 64 bit version
of dmd is quite more new than the 32 bit version, so
Namespace:
If I compile this code with dmd test.d and execute it, I see a
memory usage of ~ 1332K. If I press enter the programm allocate
100_000 int's and the memory usage increased to ~ 1720 K. If I
now press enter I assumed that the memory usage decreased to ~
1332 K again, but it is stil
I'd like to define an enum type with only a subset of the fields
of another enum.
enum Foo { A, B, C }
enum Bar : Foo { Foo.A, Foo.B }
void main() {
//Foo f = Bar.A; // Should be OK.
//Bar b = Foo.A; // Should be an error.
}
I receive the errors:
temp.d(2): Error: type only allowed if
On Thursday, 28 November 2013 at 10:23:39 UTC, Kenji Hara wrote:
It's a known front-end issue.
https://d.puremagic.com/issues/show_bug.cgi?id=11545
Kenji Hara
Great! Does this pull resolve both issues? (correct length and
x=>x syntax)
Does selective imports have an effect on the resulting
executable? For example if i included the following at the top of
my source to only include one function from a library:
import std.algorithm : reduce;
Would it have any impact on the resulting executable? i.e. only
include compiled code
On Wednesday, 27 November 2013 at 00:46:30 UTC, Ary Borenszweig
wrote:
On 11/26/13 7:00 PM, Namespace wrote:
On Tuesday, 26 November 2013 at 21:37:49 UTC, Jonas Drewsen
wrote:
Isn't it a bug that the assertion is triggered for this:
class Test3 {}
void main()
{
assert( (new Test3()) == (ne
On Thursday, 28 November 2013 at 12:31:11 UTC, Gary Willoughby
wrote:
Does selective imports have an effect on the resulting
executable?
No, I don't think so. The compiler still reads the module and the
linker still sees the whole object file to do its thing, it just
doesn't bring all the nam
On Thursday, 28 November 2013 at 12:31:11 UTC, Gary Willoughby
wrote:
Does selective imports have an effect on the resulting
executable? For example if i included the following at the top
of my source to only include one function from a library:
import std.algorithm : reduce;
Would it have an
On 2013-11-28 03:40:25 +, Kenji Hara said:
On Tuesday, 26 November 2013 at 23:31:16 UTC, bioinfornatics wrote:
Hi,
this time i have so many question about CT …
iws and ibuclaw help me for this.
I stuck currently about a cast at CT -> http://www.dpaste.dzfl.pl/1a28a22c
it seem this should
Hello all,
Some unittests I've been writing for Phobos involve using
assertThrown!AssertError to check that assert failures are indeed triggered
where they should be.
Surprise surprise, this fails on the release unittest build, because of course
the assertion statements are stripped out. I
I think using assert for unittests is a mistake if you ever going
to test release builds. `std.exception.enforce` or something
similar is a better match.
On 28/11/13 16:48, Dicebot wrote:
I think using assert for unittests is a mistake if you ever going to test
release builds. `std.exception.enforce` or something similar is a better match.
I'm testing an in-contract, as it happens.
The point is that code inside version(assert) should only be in
long x = 0x123456789;
writef("%0x",x);
prints 123456789
Seems like it has enough info to fill out to 16 hex digits...
On 28/11/13 16:58, Joseph Rushton Wakeling wrote:
But even with version(assert) conditionals in place, the assertThrown is still
called.
Come to that, even if I do:
version(release) {} else { assertThrown(...); }
then the assertThrown is _still_ called even in release mode.
On Thursday, 28 November 2013 at 16:01:06 UTC, Joseph Rushton
Wakeling wrote:
On 28/11/13 16:58, Joseph Rushton Wakeling wrote:
But even with version(assert) conditionals in place, the
assertThrown is still called.
Come to that, even if I do:
version(release) {} else { assertThrown(...);
On 28/11/13 17:04, Dicebot wrote:
Oh, oops, I thought your issue is exactly other way around, sorry. That looks
like an issue in assertThrown implementation. probably worth a bugzilla entry.
It's a bit mysterious. Consider this minimal example:
unittest
{
import std.exception,
assert(false) is special and never removed, don't use it for
testing assert code :
http://dlang.org/expression.html#AssertExpression
On 28/11/13 17:20, Dicebot wrote:
assert(false) is special and never removed, don't use it for testing assert code
: http://dlang.org/expression.html#AssertExpression
Seems to make no difference if I replace it with
int i = 1;
assertThrown!AssertError(assert(i == 3));
... and tweak th
I have quickly tested it and looks like asserts are not removed
from unittest blocks in release builds, only from normal code.
Which does not seem to be documented on dlang.org but was
probably introduced exactly to prevent existing tests from
breaking in release mode. I have just learned somet
P.S. version(assert) does not seem to be working at all
On 28/11/13 17:40, Dicebot wrote:
I have quickly tested it and looks like asserts are not removed from unittest
blocks in release builds, only from normal code. Which does not seem to be
documented on dlang.org but was probably introduced exactly to prevent existing
tests from breaking in release
On 28/11/13 17:40, Dicebot wrote:
I have quickly tested it and looks like asserts are not removed from unittest
blocks in release builds, only from normal code. Which does not seem to be
documented on dlang.org but was probably introduced exactly to prevent existing
tests from breaking in release
version(assert) is negated by -unittest at all actually:
import std.stdio;
void main()
{
version ( assert )
{
writeln("errr");
}
}
$ rdmd -release test.d
$ rdmd -release -unittest test.d
errr
That is so bad >_<
On 28/11/13 17:59, Dicebot wrote:
version(assert) is negated by -unittest at all actually:
import std.stdio;
void main()
{
version ( assert )
{
writeln("errr");
}
}
$ rdmd -release test.d
$ rdmd -release -unittest test.d
errr
That is so bad >_<
Aack!! :-\
And to
On Thursday, 28 November 2013 at 16:40:57 UTC, Dicebot wrote:
I have quickly tested it and looks like asserts are not removed
from unittest blocks in release builds, only from normal code.
Which does not seem to be documented on dlang.org but was
probably introduced exactly to prevent existing
I don't know what is the proper way to handle this but current
situation is clearly worth a bugzilla entry. It is just weird.
On Thursday, 28 November 2013 at 17:22:20 UTC, Dicebot wrote:
I don't know what is the proper way to handle this but current
situation is clearly worth a bugzilla entry. It is just weird.
Maybe this is intended behaviour to handle testing AssertErrors
in unit tests? How else could you test the
On 28/11/13 00:32, H. S. Teoh wrote:
Rotate the code by 90° to get real code!
If you fancy a preview, the aforementioned real imaginary code is here:
https://github.com/WebDrake/phobos/tree/imaginary
I reckon I'll land a pull request in a day or two but feedback always welcome
:-)
On Thursday, 28 November 2013 at 17:28:56 UTC, Gary Willoughby
wrote:
On Thursday, 28 November 2013 at 17:22:20 UTC, Dicebot wrote:
I don't know what is the proper way to handle this but current
situation is clearly worth a bugzilla entry. It is just weird.
Maybe this is intended behaviour to
On 28/11/13 19:01, Dicebot wrote:
On Thursday, 28 November 2013 at 17:28:56 UTC, Gary Willoughby wrote:
On Thursday, 28 November 2013 at 17:22:20 UTC, Dicebot wrote:
I don't know what is the proper way to handle this but current situation is
clearly worth a bugzilla entry. It is just weird.
M
On Thursday, 28 November 2013 at 18:26:15 UTC, Joseph Rushton
Wakeling wrote:
I think it may actually be a bug in whether -release implies
version(release).
Try out the attached code. (r)dmd -release release.d produces
an executable
that still reports that release mode is disabled.
There is
On Thursday, November 28, 2013 17:40:55 Dicebot wrote:
> I have quickly tested it and looks like asserts are not removed
> from unittest blocks in release builds, only from normal code.
> Which does not seem to be documented on dlang.org but was
> probably introduced exactly to prevent existing tes
On Thursday, November 28, 2013 19:53:48 Dicebot wrote:
> On Thursday, 28 November 2013 at 18:26:15 UTC, Joseph Rushton
>
> Wakeling wrote:
> > I think it may actually be a bug in whether -release implies
> > version(release).
> > Try out the attached code. (r)dmd -release release.d produces
> > a
On Thursday, 28 November 2013 at 19:01:40 UTC, Jonathan M Davis
wrote:
The closest you would get would be
version(assert) {}
else { /* release */ }
- Jonathan M Davis
Which does not work if you also have "-unittest" ;)
On Thursday, November 28, 2013 18:28:55 Gary Willoughby wrote:
> On Thursday, 28 November 2013 at 17:22:20 UTC, Dicebot wrote:
> > I don't know what is the proper way to handle this but current
> > situation is clearly worth a bugzilla entry. It is just weird.
>
> Maybe this is intended behaviour
On 28/11/13 20:08, Dicebot wrote:
Which does not work if you also have "-unittest" ;)
Plus, assert statements in the main body of code (not just the unittests) are
enabled with -release if -unittest is turned on, but in- and out-contracts are
still stripped. An oversight, perhaps?
I don't
On Thursday, November 28, 2013 20:08:34 Dicebot wrote:
> On Thursday, 28 November 2013 at 19:01:40 UTC, Jonathan M Davis
>
> wrote:
> > The closest you would get would be
> >
> > version(assert) {}
> > else { /* release */ }
> >
> > - Jonathan M Davis
>
> Which does not work if you also have "-
does such a thing exist? like html code beautifiers?
On 28/11/13 20:25, Joseph Rushton Wakeling wrote:
assert statements in the main body of code (not just the unittests) are
enabled with -release if -unittest is turned on, but in- and out-contracts are
still stripped.
After consideration, I think that this is the real issue here: it's not a
pro
On 2013-11-28 22:28:54 +, seany said:
does such a thing exist? like html code beautifiers?
Most IDE's support this. Try Xamarin Studio with MonoD.
http://mono-d.alexanderbothe.com
On Thursday, 28 November 2013 at 22:52:57 UTC, Shammah Chancellor
wrote:
On 2013-11-28 22:28:54 +, seany said:
does such a thing exist? like html code beautifiers?
Most IDE's support this. Try Xamarin Studio with MonoD.
http://mono-d.alexanderbothe.com
you can laways used the linux c
Hi guys I'm having some problems. Calculations are not working as
expected and I get segmentation fault. I used the 2.059 version
and it runs after compilation on compileonline.com
But I imagine is either a rookie mistake or a bug, what I'm
curious about is the foreach loop.
I'm wondering in
On Fri, Nov 29, 2013 at 12:36:18AM +0100, Binarydepth wrote:
> Hi guys I'm having some problems. Calculations are not working as
> expected and I get segmentation fault. I used the 2.059 version and
> it runs after compilation on compileonline.com
[...]
> foreach(t; 1..51)
> {
> temp=t;
>
I fixed a formatting problem on the code just now. And also a
note is that the numbers are supposed to display a number
depending on the initial value of the variable that the foreach
loop is increasing and the users age.
So if you were born in 1977 you input your birth year to the
program an
On Thursday, 28 November 2013 at 23:45:26 UTC, H. S. Teoh wrote:
On Fri, Nov 29, 2013 at 12:36:18AM +0100, Binarydepth wrote:
Hi guys I'm having some problems. Calculations are not working
as
expected and I get segmentation fault. I used the 2.059
version and
it runs after compilation on compi
H. S. Teoh:
Modifying the loop variable of a foreach is, in general, a
risky move.
Right. In my opinion D programmers should learn that this is the
preferred idiom of using foreach ranged loops:
foreach (immutable i; 0 .. n) {}
If a D programmers really needs to modify the index inside the
I recompile old project with dmd 2.064 and get the runtime error:
Fatal Error while loading '/usr/lib/x86_64-linux-gnu/libphobos2.so.0.64':
The module 'std.path' is already defined in
'bin64/workstation-x86-sdl_64'.
How can I avoid this `collision`?
51 matches
Mail list logo
