On Sunday, 27 July 2014 at 20:50:14 UTC, francesco cattoglio
wrote:
Yep, I have to agree.
Or well, probably it's good enough for Walter, but I would be
utterly unable to debug even 50 lines of code with that :-P
It should be usable, if you convert your debug information to PDB
format using cv
On 3.8.2014 21:47, David Bregman wrote:
> Walter has proposed a change to D's assert function as follows [1]:
> "The compiler can make use of assert expressions to improve
> optimization, even in -release mode."
Couldn't this new assert behaviour be introduced as a new optimization
switch ? Say -O
Windows console is broken, I recommend using API functions
(WriteConsole) instead.
Dne 25. 1. 2015 v 19:23 Daniel Kozak napsal(a):
> je tady nekdo z ceska? Vlastnim domenu dlang.cz a mam v planu tam rozchodit
Zdar, to by bylo zasluzne.
--
mk
---
Tato zpráva byla zkontrolována na viry programem Avast Antivirus.
http://www.avast.com
What I really want is a switch "stable", which contains all
safety relevant features like Contracts/Asserts and so on. But
Just compile _without_ -release -debug -g -unittest options.
On Wednesday, 4 June 2014 at 13:48:04 UTC, Andre wrote:
I currently wonder what is included by adding no switch to DMD?
default (no switch) = asserts, contracts, boundscheck=all
-debug = include code marked with debug keyword
-unittest = include unittests
-g = include debug info
-release = do
Plaese no.
What is essential, is to keep fixing bugs _after_ the release,
i.e. do point releases. It's shame we don't have one for 2.065
already. Part of the problem is tracking which bugs are actually
affecting a release branch. Another is a need to backport later
discovered bugs.
IMHO all regressions af
On Tuesday, 15 July 2014 at 08:01:40 UTC, Meta wrote:
I'll give you a hint: the bug causes flattenedType!R to always
returned uint.
What is unexpected about that ?
The reason for getting rid of it is because it's borderline
useless. It causes more accidental bugs than it enables
deliberate uses.
I find the comma op useful somemtimes. This example shows
absolutely nothing of comma wrongdoing. If anything, there could
be a warning for passing signed value
Example?
For loop with multiple variables and various one liners of
questionable utility aside:
import std.stdio;
bool funk()
{
static int count;
return ++count > 1 ? true : false;
}
void main()
{
bool flag = false;
if (flag && funk)
writeln("a");
else if (flag
On Tuesday, 15 July 2014 at 18:50:08 UTC, John Colvin wrote:
and not just because I don't like the comma. I'd say it's
generally bad practice to hide that write to `flag` inside the
You are right for the 'final' code, but the point of my example
is, that I can move the flag to another if and d
If I understand it correctly, Walter is against adding trusted
blocks (trusted {...}) into @safe functions. But what about
having safe blocks in @trusted functions ?
int somefunc() @trusted
{
int a = systemfunc();
int b;
@safe {
b = safefunc(); // calling systemfunc() not allowe
On Wednesday, 25 March 2015 at 12:01:15 UTC, wobbles wrote:
The "DOES POORLY AT..." column is good reading here for how D
could improve ( though some of the comments are stupid. D has
an annoying syntax!?)
doeas poorly at annoying syntax => not annoying syntax
It seems like every DMD release makes compilation slower. This
time I see 10.8s vs 7.8s on my little project. I know this is
generally least of concern, and D1's lighting-fast times are long
gone, but since Walter often claims D's superior compilation
speeds, maybe some profiling is in order ?
Here is one example:
Orange d5b2e0127c67f50bd885ee43a7dd61dd418b1661
https://github.com/jacob-carlborg/orange.git
make
2.065.0
real0m9.028s
user0m7.972s
sys 0m0.940s
2.066.1
real0m10.796s
user0m9.629s
sys 0m1.056s
2.067.0
real0m13.543s
user0m12.097s
sys 0m1.
On Wednesday, 1 April 2015 at 02:29:05 UTC, Martin Nowak wrote:
The lookup order for the config file should be changed to the
following.
- next to dmd binary (highest precedence so that I can have
multiple
installations)
- per-user conf folder (HOME) (to override the system-wide
config)
- syst
On Friday, 10 April 2015 at 22:55:19 UTC, Martin Nowak wrote:
A small reminder, as the next point release isn't that far
away, we're
now using stable branches to incorporate important bug fixes.
Stable is broken on autotester.
void main(string[] args)
{
int a = 1;
int b = to!int(args[1]);
uint c = 2;
switch (a)
{
case b: break; // OK
case c: break; // Error: variable c cannot be read at
compile time
default: break;
}
}
Switch spec says:
The case expressions must all e
https://github.com/D-Programming-Language/dmd/pull/2887
Ugh...
at the VERY LEAST, the error message should be fixed, as "can't
be read at compile time" is clearly not the issue.
Looks like this issue surfaces periodically. Somehow I've missed
it so far.
Anyway, either the spec is wrong or t
I can't seem to build phobos master on linux, unless I revert
pull #3014 unittests
DMD v2.067-devel-b9dee9e DEBUG
std/math.d(2702): Error: number '0x1p-1024' is not representable
std/math.d(2705): Error: number '0x1p-1024' is not representable
std/math.d(2708): Error: number '0x1p-1024' is not r
You list "DMD v2.067-devel-b9dee9e DEBUG." Does that mean that
you're not using the latest dmd? Make sure that you're using
I've tried making a fresh clone of dmd, druntime, phobos on a
different computer, compiling:
make -f posix.mak MODEL=32
Still the same error. I've no problem compiling
You might need to put DMD=path/to/dmd in front of make and give
it the path to the dmd from master so that it uses that rather
than the one installed on your system.
It picks up dmd from ../dmd/src by default, making it explicit
makes no difference. I've tried 2.067.1 binary too.
I think I read something (bugzilla issue, source comment, ...)
that hinted at libc having to do with it, but I can't find it
now. But CentOS 6's libc is indeed behind that of my usual
Ubuntu 14.10 (2.12 vs 2.19).
Yeah, upgrading Debian from wheezy to jessie solved the issue.
DMD, Phobos and Druntime open regressions over time:
http://bid.iline.cz/~mk/tmp/regs.png
Used to be stable, but seems to be getting worse since 2016.
IMHO all what is needed is to update the download page with some
description of deferences between the compilers, like:
dmd
- reference compiler, Digital Mars backend
- best for latest dlang features, fast compile times
gdc
- GNU gcc backend based compiler
- best for portability and com
How do I run DMD tests on Windows ? I'm not able to, even with gmake.
Also, is it possible to compile DMD with MSVC ?
And third question, what are the minimal (by size, not by version)
VS/VC/SDK requirements to compile Phobos with -m64 and -m32mscoff ?
Currently I have installed MS Visual C++ bu
Dne 20. 2. 2016 v 13:40 kinke napsal(a):
> You may want to have a look at
> http://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC#Running_the_dmd-testsuite_tests
> for some tools prerequisites.
I have gnu make, but it doesn't work:
D:\prac4\dmd\test>make -f Makefile
Creating output
Dne 21. 2. 2016 v 15:56 Nick Sabalausky napsal(a):
> On 02/19/2016 07:25 PM, Martin Krejcirik wrote:
> Unless things have changed since I last looked, DMD's Windows makefiles
> are written for Digital Mars Make, not gmake. The gmake makefiles are
Unfortunately, there is just one Makefile in the te
Dne 21. 2. 2016 v 15:56 Nick Sabalausky napsal(a):
> I don't know whether MSVC works, but the traditional way to compile the
> C++ parts on Windows is using the Digital Mars C++ compiler, DMC. So
> even if MSVC doesn't work, DMC definitely should.
To by more precise:
I need a receipe, how to comp
Dne 21. 2. 2016 v 17:56 kinke napsal(a):
> Anyway, the latest linking errors are due to some heavy changes in
> Microsoft's C runtime with VS 2015. Phobos v2.068 doesn't support it
> yet, so you may want to try the latest version instead.
Thanks, you are right, 2.070 works. No other changes needed
On Sunday, 3 April 2016 at 21:55:39 UTC, ag0aep6g wrote:
Does this make sense to anyone?
Using UTF8 console via C api is broken in many ways on Windows.
The problem is in C library. The only sensible way is to use
Windows API. Related issues:
https://issues.dlang.org/show_bug.cgi?id=1448
ht
And convert to non-unicode codepage (OEMCP) ...
Dne 4. 4. 2016 v 0:11 ag0aep6g napsal(a):
On 04.04.2016 00:07, Martin Krejcirik wrote:
I'm under the impression that ReadFile is a Windows API function. Is
that not so? If it isn't, what is the corresponding Windows API function?
Sorry, I missed that in your post. Anyway, after years of trying,
Dne 4. 4. 2016 v 0:52 ag0aep6g napsal(a):
reading UTF-8 is broken in Windows and there's no workaround, then issue
15845 can't be fixed, and we should stop telling people to use `chcp
65001` (and don't forget to change the font).
I think ReadConsole and WriteConsole API functions work with code
Dne 4. 4. 2016 v 2:03 Adam D. Ruppe napsal(a):
ReadConsoleW works fine though in all my attempts, we should prolly just
change the library to use it.
Probably not, it dont't work with pipes. Oh well ...
--
mk
Dne 4. 4. 2016 v 2:22 Adam D. Ruppe napsal(a):
On Monday, 4 April 2016 at 00:08:54 UTC, Martin Krejcirik wrote:
Probably not, it dont't work with pipes. Oh well ...
It is easy to detect that though and branch accordingly.
I think it not woth it. If Phobos just converted automatically from
c
I'd prefer just adding a warning where appropriate.
On Tuesday, 31 May 2016 at 18:13:05 UTC, Bruno Medeiros wrote:
performance on Windows has become horrible. Takes over 3
seconds on my machine just to display the version.
Doesn't happen to me. I doubt the problem is in dmd itself. Maybe
deep path search, antivirus, or something like that ?
On Tuesday, 11 October 2016 at 18:13:53 UTC, Andrei Alexandrescu
wrote:
http://indianautosblog.com/2016/10/most-powerful-suzuki-swift-produces-350-hp-25
-- Andrei
There is no Kenji Hara in the team, so I would say no :)
Then maybe this isn't photoshopped:
https://twitter.com/stamcd/status/742563964656062464
Why would be ? It's a screenshot from Forza Motorsport game.
For example, https://issues.dlang.org/show_bug.cgi?id=1448
should be addressable. Either we should provide a translation
function for outputting things and recommend it, or document
that codepages that D runs on Windows etc - there's got to be a
What is IMHO needed to fix this bug, is to add t
I'm not sure we should be documenting bugs in C standard
library implementation internals.
Users just don't expect broken console output. There should be a
note in writeln docs.
Digital Mars C++ bug reports can be filed here:
http://bugzilla.digitalmars.com/issues/
It's awfully slow.
44 matches
Mail list logo
