Re: How to make a Currency class from std.BigInt?
Thanks. Do I need to use rational fractions for the Currencies class?
Re: std.sevenzip - Do you need it?
On 2015-01-31 13:02, data man wrote: Thanks for the feedback! And DUB supports the compilation of external С-code? No, but you can execute shell commands before building the D code. There are four settings [1] that could be of interest: * preGenerateCommands * postGenerateCommands * preBuildCommands * postBuildCommands [1] http://code.dlang.org/package-format#build-settings -- /Jacob Carlborg
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 14:06:20 UTC, Piotrek wrote: and named Mars (Deimos is unfortunately already taken ). BTW, Mars is the name of the language, before people started calling it D (which stuck).
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 14:33:35 UTC, Vladimir Panteleev wrote: On Saturday, 31 January 2015 at 14:06:20 UTC, Piotrek wrote: and named Mars (Deimos is unfortunately already taken ). BTW, Mars is the name of the language, before people started calling it D (which stuck). I know that, but the naming is the least important aspect of the proposal. We can refarm the unused Mars name or choose another one, maybe Curiosity, or anything suitable ;) Piotrek
Re: How to make a Currency class from std.BigInt?
On Saturday, 31 January 2015 at 15:02:09 UTC, Colin wrote: Maybe you can articulate it in one post what this class is trying to achieve? Maybe this? https://github.com/andersonpd/decimal/blob/master/decimal/bigfloat.d The main thing is not to lose currency in calculations that use arithmetic.
[Issue 14089] New: [REG2.064] Assigning to AA has no value when overriding opAssign
https://issues.dlang.org/show_bug.cgi?id=14089
Issue ID: 14089
Summary: [REG2.064] Assigning to AA has no value when
overriding opAssign
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: sinkuup...@gmail.com
Introduced in: https://github.com/D-Programming-Language/dmd/pull/2539
void test()
{
Test[int] aa;
Test b = aa[1] = Test();
}
struct Test
{
Test opAssign(Test val) // ok if remove this
{
return this;
}
}
$ dmd test.d
test.d(4): Error: expression 1 in aa ? aa[1].opAssign(Test()) :
cast(void)(aa[1] = Test()) is void and has no value
--
Re: Labels in struct
On Saturday, 31 January 2015 at 16:04:36 UTC, tcak wrote:
I do not have a big example in the end to show, but is there
any way to put labels into struct definitions?
struct CommunicationMessage{
char[2] signature;
mainData:
int info1;
int info2;
extraData:
ushort checksum;
content:
}
Example I defined something like above. I am using it as a base
structure, and don't know how long the content of message will
be. But I know that it will be at the end. I could use that
content label to find out about end of struct. But
unfortunately, it doesn't seem like it is supported.
I could say void* endOfStruct = struct + sizeof(struct), but
then struct wouldn't be self explanatory with that content
label at the end.
... **without** that content label ...
Re: Arrays, garbage collection
On 1/31/15 1:10 AM, Martin Nowak wrote: Thanks for this code, it's a lot nicer and simpler than mine. -- Andrei So, pull request for std.array and reverting the dollar thingie? Problem solved? This looks like the way to go. I apologize to the community for the indecision shown. -- Andrei
Re: Labels in struct
You could use a UDA like that, though getting the offset will be
a bit tricky.
The idea is to use some uda type, even plain string is good
enough, then use the __traits to find the first appearance of
that UDA in the object and return that offset.
Keep in mind that the @uda: syntax applies it to ALL following
members, it isn't really a label, but if we only look at the
first time it shows up we can kinda pretend it is one.
Here's an example:
struct Foo {
int b;
@(label_one): // offset 4
int c;
int d;
@(label_two): // offset 12
int e;
}
// get the offset of the label on a type, see below for usage
size_t offsetOf(T, string label)() {
foreach(memberName; __traits(allMembers, T)) {
foreach(attribute; __traits(getAttributes, __traits(getMember,
T, memberName))) {
static if(is(typeof(attribute) == string) attribute ==
label)
return __traits(getMember, T,
memberName).offsetof;
}
}
assert(0, no such label);
}
void main() {
// gives what we expect
pragma(msg, offsetOf!(Foo, label_one));
pragma(msg, offsetOf!(Foo, label_two));
}
Re: Labels in struct
Oh this hack also won't work with a label at the very end. You could use sizeof for that though (however that would include padding bytes. Perhaps last member's offsetof plus last member's sizeof is a bit more accurate.)
[Issue 14041] Refused writeln of a fixed size array of chars
https://issues.dlang.org/show_bug.cgi?id=14041 sinkuup...@gmail.com changed: What|Removed |Added Keywords||pull CC||sinkuup...@gmail.com --- Comment #1 from sinkuup...@gmail.com --- https://github.com/D-Programming-Language/phobos/pull/2940 --
[Issue 14042] std.conv.to of a immutable char pointer
https://issues.dlang.org/show_bug.cgi?id=14042 sinkuup...@gmail.com changed: What|Removed |Added Keywords||pull CC||sinkuup...@gmail.com --- Comment #1 from sinkuup...@gmail.com --- https://github.com/D-Programming-Language/phobos/pull/2942 --
Mars Drafting Library - Official community driven library
Hi, The history of std.(experimental.)logger and the latest thread about gui functionality inclusion into Phobos made me think about how to solve the problem of adding new modules. I came up with the idea (maybe not new) to create a additional library(along druntime and Phobos) delivered with dmd package and named Mars (Deimos is unfortunately already taken ). The library itself would be driven by community (not individual library developer) in order to be... the standard. The process would be something similar to that other committees use (e.g http://www.iec.ch/standardsdev/how/processes/development/) where before the standard is approved it goes through a draft stage. Still a draft can be used to create a working product (e.g. some Wi-Fi solutions based on IEEE 802.11 drafts) Possible initial prerequisites: - User awareness about the usage consequences - Library placed at https://github.com/D-Programming-Language/ - Only well recognized community members have pull rights - design decision made on the best known sw engineering patterns used in D - New module should be functional with D/Phobos standards applied - API and implementation allowed to change any time in order to make a progress - no external dependencies beside OS services - draft as the root module name e.g. module draft.gui Advantages: - community driven process which ensures the lowest level of controversy - fast path for modules like GUI to be standardized Disadvantages: - additional effort for the sw release process Ready to be destroyed ;) Piotrek
Re: How to make a Currency class from std.BigInt?
The next version, which does not work: https://bpaste.net/show/b9c85de68d07
Re: How to make a Currency class from std.BigInt?
On 31.01.15 15:45, RuZzz wrote: Maybe I need good examples on C++, for this class, because a lot of examples on C++. Maybe this can help you: https://github.com/andersonpd/decimal
Re: Czech D community
Given the overwhelming number of responses you received, I would suggest to adhere to Kiith-Sa's suggestion of dropping the idea of a czech-only forum. I think that we are more likely to meet for a beer than to make such forum alive in near future. Martin smime.p7s Description: Elektronicky podpis S/MIME
[Issue 14037] Problem with BigInt and std.functional.memoize
https://issues.dlang.org/show_bug.cgi?id=14037 sinkuup...@gmail.com changed: What|Removed |Added CC||sinkuup...@gmail.com Hardware|x86 |All OS|Windows |All --- Comment #1 from sinkuup...@gmail.com --- Error on assigning to AA of BigInt seems a compiler problem: https://issues.dlang.org/show_bug.cgi?id=14089 However, memoize shouldn't assume that an overloaded opAssign returns the object. So I think your fix to memoize is necessary. --
Re: How to make a Currency class from std.BigInt?
I want to understand the correct architecture of the class.
Re: How to make a Currency class from std.BigInt?
On Saturday, 31 January 2015 at 13:45:22 UTC, RuZzz wrote: I want to understand the correct architecture of the class. Sorry, you still did not state your problem (or what you are trying to achieve) clearly. Writing down a clear problem description is likely to get you halfway to the solution.
Error when profiling
When trying to run my program with profiling enabled it dies before the first line of my main function runs. Everything works fine without profiling. I get the following stack trace: thread #1: tid = 0x38de4, 0x00010008d985 vision_entry`gc_malloc + 49, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x00010008d985 vision_entry`gc_malloc + 49 vision_entry`gc_malloc + 49: - 0x10008d985: movq (%rdi), %rbx 0x10008d988: callq *0x60(%rbx) 0x10008d98c: popq %rbx 0x10008d98d: movq %rbp, %rsp (lldb) thread backtrace * thread #1: tid = 0x38de4, 0x00010008d985 vision_entry`gc_malloc + 49, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x00010008d985 vision_entry`gc_malloc + 49 frame #1: 0x0001000908f5 vision_entry`_d_newclass + 117 frame #2: 0x0001000b4b28 vision_entry`D3std9exception7bailOutFNaNfAyamxAaZv + 40 frame #3: 0x0001000b4d06 vision_entry`D3std9exception14__T7enforceTbZ7enforceFNaNfbLAxaAyamZb + 94 frame #4: 0x0001000c4df6 vision_entry`D3std5stdio4File17LockingTextWriter6__ctorMFNcNeKS3std5stdio4FileZS3std5stdio4File17LockingTextWriter + 86 frame #5: 0x0001000c4f19 vision_entry`D3std5stdio4File17lockingTextWriterMFZS3std5stdio4File17LockingTextWriter + 41 frame #6: 0x00012c74 vision_entry`D3std5stdio4File15__T8writeflnTaZ8writeflnMFxAaZv + 124 at stdio.d:1238 frame #7: 0x00010c06 vision_entry`_Dmain + 86 at stdio.d:2727 frame #8: 0x00010009060c vision_entry`D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv + 40 frame #9: 0x000100090551 vision_entry`D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv + 45 frame #10: 0x0001000905b1 vision_entry`D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv + 45 frame #11: 0x000100090551 vision_entry`D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv + 45 frame #12: 0x0001000904cd vision_entry`_d_run_main + 433 frame #13: 0x00010d29 vision_entry`main + 65 frame #14: 0x7fff883a45c9 libdyld.dylib`start + 1 Does anyone have any ideas of what could have caused this?
[Issue 14042] std.conv.to of a immutable char pointer
https://issues.dlang.org/show_bug.cgi?id=14042 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/7cab71b22bd829db8712e9a4c4b9c7b62a51552a Fix Issue 14042 - std.conv.to of a immutable char pointer https://github.com/D-Programming-Language/phobos/commit/7b8c9b2e1a3dd44de769653b3f3b826b6e038181 Merge pull request #2942 from sinkuu/fix_14042 Fix Issue 14042 - std.conv.to of a immutable char pointer --
Re: something weird with strerror_r
On Thursday, 29 January 2015 at 15:25:09 UTC, Mike Parker wrote:
On 1/29/2015 11:40 PM, CodeSun wrote:
Recently, I found something really weird when I use strerror_t
function
which is declared inside std.c.string.
The code snippet is listed below:
import std.c.string;
import core.stdc.errno;
void main() {
import std.stdio;
char[128] buf;
strerror_r(errno, buf.ptr, buf.sizeof);
writeln(cast(string)buf);
}
The terminal should print Success with errno=0, but in this
example,
the result is
.
I test this snippet both on Archlinux and Ubuntu 14.04.1, and
the result
is same. If there is someone can help me?
I wanna know if it is my mistake or it is just a bug.
Thx!
The GNU version of strerror_r is documented as returning
a pointer to a string containing the error message. This may
be either a pointer to a string that the function stores in
buf, or a pointer to some (immutable) static string (in which
case buf is unused).
So I think what you may have been seeing in this case is that
it was returning a static string, your buffer remained empty
and the writeln was printing a bunch of 0xFFs. Probably this is
a better way to handle it:
void main()
{
import core.stdc.errno : errno;
import std.c.string : strerror_r;
// Static arrays are initialized to T.init. For
// char, T.init is 0xFF, *not* 0. The initializer
// here will fill the array with 0.
char[ 128 ] buf = 0;
auto cstr = strerror_r( errno, buf.ptr, buf.sizeof );
// Slice the C string with fromStringz. Unlike to!string,
this
// does not allocate or copy.
import std.string : fromStringz;
writeln( cstr.fromStringz() );
}
Yes, you are right, when I printed the cstr, I got the result I
wanted. In fact, I neglect the detail you attached here from the
manual.
Thx!
Re: How to make a Currency class from std.BigInt?
On 31.01.15 15:56, zeljkog wrote: On 31.01.15 15:45, RuZzz wrote: Maybe I need good examples on C++, for this class, because a lot of examples on C++. Maybe this can help you: https://github.com/andersonpd/decimal Also http://code.dlang.org/packages/eris
Labels in struct
I do not have a big example in the end to show, but is there any
way to put labels into struct definitions?
struct CommunicationMessage{
char[2] signature;
mainData:
int info1;
int info2;
extraData:
ushort checksum;
content:
}
Example I defined something like above. I am using it as a base
structure, and don't know how long the content of message will
be. But I know that it will be at the end. I could use that
content label to find out about end of struct. But
unfortunately, it doesn't seem like it is supported.
I could say void* endOfStruct = struct + sizeof(struct), but
then struct wouldn't be self explanatory with that content label
at the end.
[Issue 14042] std.conv.to of a immutable char pointer
https://issues.dlang.org/show_bug.cgi?id=14042 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: How to make a Currency class from std.BigInt?
Maybe I need good examples on C++, for this class, because a lot of examples on C++.
Re: How to make a Currency class from std.BigInt?
I am looking for not only free solutions.
Re: How to make a Currency class from std.BigInt?
On Saturday, 31 January 2015 at 14:26:45 UTC, RuZzz wrote: The next version, which does not work: https://bpaste.net/show/b9c85de68d07 I really dont understand what your trying to achieve here. Maybe you can articulate it in one post what this class is trying to achieve?
Harbored-mod (doc generator) 0.2: Cross-referencing, methods/fields no longer in separate files
Harbored-mod (https://github.com/kiith-sa/harbored-mod) is a documentation generator based on Brian Schott's Harbored that supports both DDoc and Markdown in documentation comments. -- Examples of generated docs -- * Public imports in a package.d: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity.html * Class with a template parameter, member functions and aliases: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/entitymanager/EntityManager.html * Simple DDoc See_Also: section: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/componenttypeinfo/ImmutableRawComponent.html * Note: DDoc section with some markdown: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/processtypeinfo.html#prioritizeProcessOverloads -- Release highlights -- * Automatic cross-referencing in code blocks and inline code * New (and now default) output format: aggregated HTML; generate documentation files only for aggregates (modules, structs, classes, etc.) and document non-aggregate members (functions, variables, etc.) in these files. The previous, DDox compatible format, where a separate file is generated for every symbol, is still supported through the `--format=html-simple` option. * Various style and usability improvements * Major refactoring * Many bugfixes Full changelog: https://github.com/kiith-sa/harbored-mod/releases/tag/v0.2.0
Re: DlangUI
On Wednesday, 28 January 2015 at 13:53:00 UTC, John Colvin wrote: On Wednesday, 28 January 2015 at 13:30:59 UTC, Vadim Lopatin wrote: On Wednesday, 28 January 2015 at 13:18:11 UTC, John Colvin wrote: On Wednesday, 28 January 2015 at 10:57:57 UTC, Vadim Lopatin wrote: On Wednesday, 28 January 2015 at 10:31:31 UTC, John Colvin wrote: $ ls -1 /Library/Fonts/ /System/Library/Fonts/ /Library/Fonts/: Al Nile.ttc ... Thank you! Submitted fix with some mac font paths hardcoded. v0.4.22 Could you please try it? BTW, could you try on mac https://github.com/buggins/dlangide.git as well? It's dlangui-based D language IDE I'm currently working on. tetris and helloworld now work. example1 fails to build: src/example1.d(69): Error: undefined identifier setTimer src/example1.d(75): Error: undefined identifier cancelTimer Checked on latest version from git - example1 works for me. Did you try to pull recent changes from git? All working for me now. A few points: As I mentioned about dlangide, the font scaling is nasty. The Window menu name overflows and is clipped. Are the draggable dividers in the Buttons tab supposed to be able to move? They don't seem to do anything. I've added Gamma setting for font rendering. Now text looks acceptable. In DlangIDE v0.1.4, I'm using FontManager.fontGamma = 0.8; FontManager.hintingMode = HintingMode.AutoHint; (as well, for Windows versions, USE_FREETYPE is set - but it falls back to win32 font rendering if no freetype.dll found) As for me, now font rendering look good with such settings. Latest features implemented: * Text cursor blinking * Update of actions state in UI (now working better for toolbars, has some bugs for menu items, will be fixed soon) Now DlangIDE allows to open DUB project, edit it, build and run, clean, rebuild, upgrade dependencies (using DUB). I hope it will become usable in a few weeks.
Re: Google Summer of Code - Again
On Saturday, 31 January 2015 at 08:57:15 UTC, Martin Nowak wrote: On Friday, 30 January 2015 at 14:11:27 UTC, CraigDillabaugh wrote: http://en.flossmanuals.net/GSoCMentoring/managing-the-mentors/ Sounds good, count me in. Thank you very much.
Re: Arrays, garbage collection
Thanks for this code, it's a lot nicer and simpler than mine. -- Andrei So, pull request for std.array and reverting the dollar thingie? Problem solved?
Re: Time for 2.067
Can we commit to having stuff done by Feb 15 for a release on Mar 1? -- Andrei Sounds good, work on regressions should start soon and we should no longer add features.
Re: Google Summer of Code - Again
On Friday, 30 January 2015 at 14:11:27 UTC, CraigDillabaugh wrote: http://en.flossmanuals.net/GSoCMentoring/managing-the-mentors/ Sounds good, count me in.
Re: Speeding up LDC with Make jobs
It seems completely unrelated to the -j flag, just related to per-file compilation. Look at the linker map file, maybe one build results in a better layout, though the effect should be marginal.
Re: Should we remove int[$] before 2.067?
On Saturday, 31 January 2015 at 07:00:05 UTC, eles wrote: Everytime I follow the process managemnt and decision in D, it looks to me like IndburIII-esque: What management? You mean the process that follow the structure: - analysis - prioritization - risk reduction - design - implementation - evaluation - analysis - prioritization - etc ? What I see is: - implementation - analysis - crisis - implementation - analysis - crisis I really support the syntax. Because makes one quirk less. Can you use it in function parameters? Will it be made superfluous if you have tuple literals? How is $ different from an inferred templated constant? Does it compete with more generic future concepts? No planning - chaos - high expenses.
Re: dlang.org redesign -- the state of documentation and learning resources [part 2]
On Friday, 23 January 2015 at 18:37:07 UTC, Martin Drašar wrote: Dne 23.1.2015 v 19:16 Andrei Alexandrescu via Digitalmars-d napsal(a): Both are nice: http://tour.golang.org/welcome/1 http://rustbyexample.com/ Or something along the lines of https://tryhaskell.org With possible integration with D REPL. That's actually where I want to go with D REPL. Even more interesting would be user editable tutorials. As usual lacking the time for this right now.
Re: Window creation, for phobos?
I don't know, you sound like a perfectionist to me, like most of other community members. I can only give examples from my experience. I am a controls engineer in my current day job, and I do SW coding in my free time (like couple of hours per week). In the past, I changed my D GUI libs from old-DWT -- DFL -- GTKD -- new DWT for obvious reasons. I cannot afford to keep doing that. Finally I gave up and picked python-TKinter and Java-swing. I know they will always work and they still keep working without any changes even after several update cycles. My tools were such a hit that half the company (~ 0.5 * 2000 people) is using them now, which is nice. Had I written them in D, that would have been a nice advertisement for D. Note that I don't care that the GUI lib has to be awesome or perfect. It just have to work, even if it is ugly like tkinter. I think I understand the reasons for this philosophy of lean, mean and efficient std libs, they will help D compete with other heavily financially backed languages, but I guess the same philosophy is also hurting people like me. Maybe in another 10 years we will get a super efficient gui-lib in phobos, if at all, most likely we wont. May be next time I will try to experiment once again with the gui-libs in dub. - D user
Re: Problem with coupling shared object symbol visibility with protection
Am 31.01.2015 um 06:11 schrieb Dicebot:
On Friday, 30 January 2015 at 19:10:06 UTC, Martin Nowak wrote:
It has a serious drawback of increasing attribute noise even more
though. First approach allows for more automatic inference.
But with D restrictions it seems the least bad option.
Well, export is going to remain transitive. So the first approach is
still going to work. The only difference is going to be that you can
force export private declarations. So for most modules it is hopefully
going to be enough to put export { } around the public part of the
module and force export some of the needed private declarations. For a
module without templates a single export { } should be enough.
[Issue 14090] New: [REG2.067a] Incorrect recursive alias declaration
https://issues.dlang.org/show_bug.cgi?id=14090
Issue ID: 14090
Summary: [REG2.067a] Incorrect recursive alias declaration
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: verylonglogin@gmail.com
This code used to compile:
---
import std.algorithm: min, max;
import std.range: StoppingPolicy;
import std.traits;
template Template(alias Pred, int argumentsCount, EnumType = void)
if(argumentsCount = -1)
{
static if(isSomeString!(typeof(Pred)))
{
template Template(Args...) if(argumentsCount == -1 || Args.length ==
argumentsCount)
{
static if(argumentsCount = 1 argumentsCount = 2)
{
static if(__traits(compiles, { enum e = Args[0]; }))
enum a = Args[0];
else static if(is(Args[0]))
alias T = Args[0];
else
alias A = Args[0];
static if(argumentsCount == 2)
{
static if(__traits(compiles, { enum e = Args[1]; }))
enum b = Args[1];
else static if(is(Args[1]))
alias U = Args[1];
else
alias B = Args[1];
}
}
static if(is(EnumType == void))
{
static if(__traits(compiles, { enum e = mixin(Pred); }))
enum Template = mixin(Pred);
else
mixin(`alias Template = `~Pred~`;`);
}
else
{
enum EnumType Template = mixin(Pred);
}
}
} else
alias Template = Pred;
}
alias UnaryTemplate(alias Pred, EnumType = void) = Template!(Pred, 1,
EnumType);
alias GenericTuple(Args...) = Args;
template PackedGenericTuple(Args...)
{
alias Tuple = Args;
static if(isTypeTuple!Args)
alias Types = Args;
else static if(isExpressionTuple!Args)
alias expressions = Args;
enum length = Tuple.length;
enum empty = !length;
}
template packedExpressionTuple(expr...) if(isExpressionTuple!expr)
{
alias packedExpressionTuple = PackedGenericTuple!expr;
}
template RoundRobinTuple(packedTuples...)
{
struct _Empty;
enum pred(alias A) = !is(A == _Empty);
alias ChainFunc(alias packedTuple) = packedTuple.Tuple;
alias RoundRobinTuple = MapTuple!(ChainFunc,
ZipTuple!(StoppingPolicy.longest, GenericTuple!_Empty, packedTuples));
}
template ZipTuple(StoppingPolicy stoppingPolicy : StoppingPolicy.longest, alias
empty, packedTuples...)
{
alias ZipTuple = ZipTupleImpl!(stoppingPolicy, PackedGenericTuple!empty,
packedTuples);
}
template ZipTuple(StoppingPolicy stoppingPolicy : StoppingPolicy.longest,
empty, packedTuples...)
{
alias ZipTuple = ZipTupleImpl!(stoppingPolicy, PackedGenericTuple!empty,
packedTuples);
}
template ZipTuple(StoppingPolicy stoppingPolicy, packedTuples...)
if(stoppingPolicy != StoppingPolicy.longest) // probably a compiler
@@@BUG@@@ workaround
{
alias ZipTuple = ZipTupleImpl!(stoppingPolicy, PackedGenericTuple!void,
packedTuples);
}
template ZipTuple(packedTuples...)
{
alias ZipTuple = ZipTuple!(StoppingPolicy.shortest, packedTuples);
}
private template ZipTupleImpl(StoppingPolicy stoppingPolicy, alias default_,
packedTuples...)
{
alias lengths = MapTuple!(`A.length`, packedTuples);
template Impl(size_t n, packedTuples...)
{
static if(n)
{
template tupleFrontOrDefault(alias packedTuple)
{
static if(!packedTuple.empty)
alias tupleFrontOrDefault = packedTuple.Tuple[0 .. 1];
else
alias tupleFrontOrDefault = default_.Tuple;
}
alias Impl =
GenericTuple!(PackedGenericTuple!(MapTuple!(tupleFrontOrDefault,
packedTuples)),
Impl!(n - 1, MapTuple!(`PackedGenericTuple!(A.Tuple[!A.empty ..
$])`, packedTuples)));
}
else
alias Impl = GenericTuple!();
}
static if(packedTuples.length == 1 || stoppingPolicy ==
StoppingPolicy.requireSameLength)
enum length = lengths[0];
else
enum length = GenericTuple!(min, max)
[stoppingPolicy == StoppingPolicy.longest](lengths);
alias ZipTupleImpl = Impl!(length, packedTuples);
}
template MapTuple(alias Func, A...)
{
alias FuncTemplate = UnaryTemplate!Func;
static if (A.length)
alias MapTuple = GenericTuple!(FuncTemplate!(A[0]),
MapTuple!(FuncTemplate, A[1 .. $]));
else
alias MapTuple = GenericTuple!();
}
void main()
{
alias roundRobin = RoundRobinTuple!(packedExpressionTuple!(1, 2, 3),
Re: Labels in struct
On 01/31/15 17:04, tcak via Digitalmars-d-learn wrote:
struct CommunicationMessage{
[...]
content:
}
Example I defined something like above. I am using it as a base structure,
and don't know how long the content of message will be. But I know that it
will be at the end. I could use that content label to find out about end of
struct. But unfortunately, it doesn't seem like it is supported.
I could say void* endOfStruct = struct + sizeof(struct), but then struct
wouldn't be self explanatory with that content label at the end.
The traditional way (ie C-like) would be
ubyte[0] content; // zero-sized; use casts etc to access data.
as the last member. D supports that too, and just like
many other D features it works for ~80% of cases. IOW
you should be able to get it to work, but you might run
into problems if you need to access/manipulate such types.
artur
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 18:11:48 UTC, Laeeth Isharc wrote: This has the advantage over existing situation where you have the official library where things need to go through exacting and time consuming process and then dub. Within dub every project is at the same level and it is not obvious which projects are the ones to use, and there is not necessarily coherence in the different ways things are done, and the only one motivated to work on supplementary features like documentation is the project author. So you have very useful, well written libraries that have no docs. What i hate about dub is that no every library is ready to use. Some require additional steps/resources in order to get them to work. Dub does not have any indication of that because the library authors dont usually include that information. What is good about this extra community driven standard library is that everything will be included in one place and will be at the ready when it is needed.
[Issue 14091] New: Migrate Digger to D-Programming-Language/tools
https://issues.dlang.org/show_bug.cgi?id=14091 Issue ID: 14091 Summary: Migrate Digger to D-Programming-Language/tools Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: tools Assignee: nob...@puremagic.com Reporter: and...@erdani.com See also discussion in https://github.com/D-Programming-Language/tools/pull/158 --
[Issue 14091] Migrate Digger to D-Programming-Language/tools
https://issues.dlang.org/show_bug.cgi?id=14091 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Assignee|nob...@puremagic.com|thecybersha...@gmail.com --
Re: Harbored-mod (doc generator) 0.2: Cross-referencing, methods/fields no longer in separate files
On Saturday, 31 January 2015 at 17:43:49 UTC, jklp wrote: On Saturday, 31 January 2015 at 15:31:37 UTC, Kiith-Sa wrote: Harbored-mod (https://github.com/kiith-sa/harbored-mod) is a documentation generator based on Brian Schott's Harbored that supports both DDoc and Markdown in documentation comments. -- Examples of generated docs -- * Public imports in a package.d: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity.html * Class with a template parameter, member functions and aliases: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/entitymanager/EntityManager.html * Simple DDoc See_Also: section: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/componenttypeinfo/ImmutableRawComponent.html * Note: DDoc section with some markdown: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/processtypeinfo.html#prioritizeProcessOverloads -- Release highlights -- * Automatic cross-referencing in code blocks and inline code * New (and now default) output format: aggregated HTML; generate documentation files only for aggregates (modules, structs, classes, etc.) and document non-aggregate members (functions, variables, etc.) in these files. The previous, DDox compatible format, where a separate file is generated for every symbol, is still supported through the `--format=html-simple` option. * Various style and usability improvements * Major refactoring * Many bugfixes Full changelog: https://github.com/kiith-sa/harbored-mod/releases/tag/v0.2.0 Hello i get an error while trying to compile it on Win32, with dmd 2066.1: Error 42: Symbol Undefined _D3std5array40__T5emptyTE14symboldatabase10SymbolTypeZ5emptyFNaNbNdNiNfxAE14symboldatabase10SymbolTypeZb demangled: pure nothrow @property @nogc @safe bool std.array.empty!(symboldatabase.SymbolType).empty(const(symboldatabase.SymbolType[])) the error only happend since commit 05ab80052d1b7d1dc3b1ff38c30addd9df7f3db4 otherwise thx for this nice software. Thanks for detecting the error/commit. Unfortunately I have no way to test on Win32 currently, and on Linux (32 or 64) I couldn't reproduce this (and AFAIK Mac build works as well), but based on the demangled name I tried to blindly fix a possible cause. That said, there is no obvious cause; I suspect this may be a Win32-specific linker error. Could you clone the current git master (https://github.com/kiith-sa/harbored-mod.git) and try if it works?
[Issue 13776] [REG2.067a] Incorrect recursive alias declaration error with `__traits(compiles, ...)`
https://issues.dlang.org/show_bug.cgi?id=13776 --- Comment #3 from Denis Shelomovskij verylonglogin@gmail.com --- (In reply to Kenji Hara from comment #2) (In reply to Kenji Hara from comment #1) https://github.com/D-Programming-Language/dmd/pull/4172 PR is merged and the issue is fixed. https://github.com/D-Programming-Language/dmd/commit/ 5ba2e4e4dc7de523352d0b61143d7c9bd2bd594a OK, but unstd.generictuple still doesn't compile. Opened Issue 14090. Sorry it's not that reduced. --
Re: Labels in struct
On 31.01.15 17:04, tcak wrote:
I do not have a big example in the end to show, but is there any way to
put labels into struct definitions?
struct CommunicationMessage{
char[2] signature;
mainData:
int info1;
int info2;
extraData:
ushort checksum;
content:
}
Members of type struct are actualy labels.
struct CommunicationMessage{
struct Md {
int info1;
int info2;
};
struct Ed {
ushort checksum;
}
struct Cnt {
}
char[2] signature;
Md mainData;
Ed extraData;
Cnt content;
}
Re: Mars Drafting Library - Official community driven library
This has the advantage over existing situation where you have the official library where things need to go through exacting and time consuming process and then dub. Within dub every project is at the same level and it is not obvious which projects are the ones to use, and there is not necessarily coherence in the different ways things are done, and the only one motivated to work on supplementary features like documentation is the project author. So you have very useful, well written libraries that have no docs.
Re: Harbored-mod (doc generator) 0.2: Cross-referencing, methods/fields no longer in separate files
On Saturday, 31 January 2015 at 15:31:37 UTC, Kiith-Sa wrote: Harbored-mod (https://github.com/kiith-sa/harbored-mod) is a documentation generator based on Brian Schott's Harbored that supports both DDoc and Markdown in documentation comments. -- Examples of generated docs -- * Public imports in a package.d: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity.html * Class with a template parameter, member functions and aliases: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/entitymanager/EntityManager.html * Simple DDoc See_Also: section: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/componenttypeinfo/ImmutableRawComponent.html * Note: DDoc section with some markdown: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/processtypeinfo.html#prioritizeProcessOverloads -- Release highlights -- * Automatic cross-referencing in code blocks and inline code * New (and now default) output format: aggregated HTML; generate documentation files only for aggregates (modules, structs, classes, etc.) and document non-aggregate members (functions, variables, etc.) in these files. The previous, DDox compatible format, where a separate file is generated for every symbol, is still supported through the `--format=html-simple` option. * Various style and usability improvements * Major refactoring * Many bugfixes Full changelog: https://github.com/kiith-sa/harbored-mod/releases/tag/v0.2.0 Hello i get an error while trying to compile it on Win32, with dmd 2066.1: Error 42: Symbol Undefined _D3std5array40__T5emptyTE14symboldatabase10SymbolTypeZ5emptyFNaNbNdNiNfxAE14symboldatabase10SymbolTypeZb demangled: pure nothrow @property @nogc @safe bool std.array.empty!(symboldatabase.SymbolType).empty(const(symboldatabase.SymbolType[])) the error only happend since commit 05ab80052d1b7d1dc3b1ff38c30addd9df7f3db4 otherwise thx for this nice software.
Re: DStep - Bindings Generator 0.0.1
On Friday, 30 January 2015 at 20:27:22 UTC, Jacob Carlborg wrote: On 2015-01-30 15:19, Chris wrote: I see what you mean, I'm tired of clever backronyms [1] too. However, DStep is not a product or a company like Apple but a tool with a very specific use. If I look for a tool, I prefer it to have what it does in the name, simply because it's easier to find it with a search engine. E.g. if there is a color picker plugin written in JavaScript, it makes sense that it has the words color and picker or something in the name (JSColorPicker) or so, because that's what you type into the search engine. If someone is wondering if there is an automatic converter form C.h to D, what will s/he type? Probably something like C to D conversion programming or convert C headers/files to D. It's not about aesthetics, it's about being practical. C2D or CtoD (as has been suggested) are the most practical names. C.hD would be a nice pun. I think that changing the name now is too late. At version 0.0.1? :)
[Issue 14041] Refused writeln of a fixed size array of chars
https://issues.dlang.org/show_bug.cgi?id=14041 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14041] Refused writeln of a fixed size array of chars
https://issues.dlang.org/show_bug.cgi?id=14041 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/6a3cd276b8a39d5cfc6fe7280accfe692c6d16f4 Fix issue 14041 - Refused writeln of a fixed size array of chars https://github.com/D-Programming-Language/phobos/commit/c3680e5bf8d701e4a0fca52f42106cf7113eedd7 Merge pull request #2940 from sinkuu/fix_14041 Fix issue 14041 - Refused writeln of a fixed size array of chars --
[Issue 14057] [REG2.066] opSlice not working correctly with AliasThis
https://issues.dlang.org/show_bug.cgi?id=14057 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/5e9006b90825453600b2080bca2ecd5f337deb14 Cleanup of #2724 Various semantic improvements Documentation improvements Disabled opSlice due to issue 14057 https://github.com/D-Programming-Language/phobos/commit/36cf60b4bf80ceca97ee13d4e16bdc499ccdd9c4 Re-enabled opSlice for std.exception.handle now that bug 14057 is fixed --
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 18:45:13 UTC, Israel wrote: On Saturday, 31 January 2015 at 18:11:48 UTC, Laeeth Isharc wrote: This has the advantage over existing situation where you have the official library where things need to go through exacting and time consuming process and then dub. Within dub every project is at the same level and it is not obvious which projects are the ones to use, and there is not necessarily coherence in the different ways things are done, and the only one motivated to work on supplementary features like documentation is the project author. So you have very useful, well written libraries that have no docs. What i hate about dub is that no every library is ready to use. Some require additional steps/resources in order to get them to work. Dub does not have any indication of that because the library authors dont usually include that information. What is good about this extra community driven standard library is that everything will be included in one place and will be at the ready when it is needed. Well, I certainly do appreciate that all these libraries exist and, as D matures, better documentation a and a general tidying up will surely be part of that process, as has already begun with phobos. There is something of a hacker disdain for docs - they are not fun to write (for most people), and one thinks that a few pointers should be enough for someone to figure it out. And that's true, for someone like the author of the code. But it is hard to imagine what it is like not to have the skillset and experience one has. And so it is a very different experience for the new user coming from python than what he experienced when he learnt python, even though if you have the basic ability D need not be intrinsically harder. The division of labour makes sense - the people who like and are good at writing docs are not necessarily those who like and are good at writing code. But its harder to recruit helpers for a personal project than a shared library.
dlang.org Getting Started page
I'm looking for feedback for: https://github.com/D-Programming-Language/dlang.org/pull/878 https://issues.dlang.org/show_bug.cgi?id=14088 Investigation shows that the D Wiki is the best landing place for newcomers, so they are directed there first. I think the current page leaves newcomers a little bit stranded.
Re: dlang.org Getting Started page
On Saturday, 31 January 2015 at 19:03:55 UTC, Zach the Mystic wrote: I'm looking for feedback for: https://github.com/D-Programming-Language/dlang.org/pull/878 https://issues.dlang.org/show_bug.cgi?id=14088 Investigation shows that the D Wiki is the best landing place for newcomers, so they are directed there first. I think the current page leaves newcomers a little bit stranded. Seems like a good idea to me. One thought, when I'm looking at a new language and I see a Getting Started, I would expect to see links for tutorials such as how to install and tutorials on writing Hello World... I would put those links first.
[Issue 14092] New: C++ mangling for struct nested inside same class as static function is broken when in namespace
https://issues.dlang.org/show_bug.cgi?id=14092
Issue ID: 14092
Summary: C++ mangling for struct nested inside same class as
static function is broken when in namespace
Product: D
Version: D2
Hardware: x86_64
OS: Mac OS X
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: coldencul...@gmail.com
On OSX (possibly other platforms, I haven't gotten to check), when a class in a
namespace has a static extern(C++) function takes a struct nested inside the
same class, the mangling for that struct ignores it's parent class, and just
uses the namespace qualifier.
Example:
C++:
---
namespace v8
{
class Isolate
{
public:
struct CreateParams { };
static Isolate* New(CreateParams params) { return 0; }
};
}
---
D:
---
extern(C++, v8)
{
class Isolate
{
struct CreateParams { }
static Isolate New(CreateParams params);
}
}
void main()
{
auto o1 = Isolate.New( Isolate.CreateParams() );
}
---
This results in the following error message:
---
Undefined symbols for architecture x86_64:
v8::Isolate::New(v8::CreateParams), referenced from:
__Dmain in run_test.o
ld: symbol(s) not found for architecture x86_64
---
It should be looking for v8::Isolate::New(v8::Isolate::CreateParams) instead.
--
[Issue 14092] C++ mangling for struct nested inside same class as static function is broken when in namespace
https://issues.dlang.org/show_bug.cgi?id=14092 Colden Cullen coldencul...@gmail.com changed: What|Removed |Added Keywords||C++ --
Re: dlang.org Getting Started page
On Saturday, 31 January 2015 at 19:35:45 UTC, Zach the Mystic wrote: On Saturday, 31 January 2015 at 19:22:06 UTC, Jonathan Marler wrote: Seems like a good idea to me. One thought, when I'm looking at a new language and I see a Getting Started, I would expect to see links for tutorials such as how to install and tutorials on writing Hello World... I would put those links first. In principle, I agree, but the front page of the Wiki has such links already, plus a whole lot more. It won't take the new user long to find what they're looking for there. I thought Getting Started was a good title, but maybe I should change it to Introduction. Introduction would conflict with: http://dlang.org/intro.html I think that's why I avoided it. If you've got something better, please suggest.
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 14:06:20 UTC, Piotrek wrote: Hi, The history of std.(experimental.)logger and the latest thread about gui functionality inclusion into Phobos made me think about how to solve the problem of adding new modules. I came up with the idea (maybe not new) to create a additional library(along druntime and Phobos) delivered with dmd package and named Mars (Deimos is unfortunately already taken ). The library itself would be driven by community (not individual library developer) in order to be... the standard. The process would be something similar to that other committees use (e.g http://www.iec.ch/standardsdev/how/processes/development/) where before the standard is approved it goes through a draft stage. Still a draft can be used to create a working product (e.g. some Wi-Fi solutions based on IEEE 802.11 drafts) Possible initial prerequisites: - User awareness about the usage consequences - Library placed at https://github.com/D-Programming-Language/ - Only well recognized community members have pull rights - design decision made on the best known sw engineering patterns used in D - New module should be functional with D/Phobos standards applied - API and implementation allowed to change any time in order to make a progress - no external dependencies beside OS services - draft as the root module name e.g. module draft.gui Advantages: - community driven process which ensures the lowest level of controversy - fast path for modules like GUI to be standardized Disadvantages: - additional effort for the sw release process Ready to be destroyed ;) Piotrek The most important thing about a standard library is decisiveness in the leadership about what *kinds* of things should be in it. When it's been made clear that a given task is worthy of inclusion in the standard library, there will be enough incentive for contributors to put in the time and effort required to meet its high standards. But there are so many tasks that aren't quite up to that bar, either because they serve too specific a niche, or because there are two or more good, but conflicting ways to implement solutions, and no good way to decide between them. For any such task that doesn't meet those high standards, the library's development is best left to the community. But there is a place for the official recognition of existing libraries which have reached a level of quality that can be safely recommended. This is what is currently missing. There needs to be a page for this. The existing Wiki page: http://wiki.dlang.org/Libraries_and_Frameworks ... suffers from exactly the same problem as code.dlang.org. It contains everything in existence. This is more of a second-party library system, for which idea I am indebted to this article: http://www.jfbillingsley.com/blog/?p=206 Suggestions for implementation?
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 19:03:55 UTC, Laeeth Isharc wrote: On Saturday, 31 January 2015 at 18:45:13 UTC, Israel wrote: the people who like and are good at writing docs are not necessarily those who like and are good at writing code. This is exactly how i feel.
Re: dlang.org Getting Started page
On Saturday, 31 January 2015 at 19:22:06 UTC, Jonathan Marler wrote: On Saturday, 31 January 2015 at 19:03:55 UTC, Zach the Mystic wrote: I'm looking for feedback for: https://github.com/D-Programming-Language/dlang.org/pull/878 https://issues.dlang.org/show_bug.cgi?id=14088 Investigation shows that the D Wiki is the best landing place for newcomers, so they are directed there first. I think the current page leaves newcomers a little bit stranded. Seems like a good idea to me. One thought, when I'm looking at a new language and I see a Getting Started, I would expect to see links for tutorials such as how to install and tutorials on writing Hello World... I would put those links first. In principle, I agree, but the front page of the Wiki has such links already, plus a whole lot more. It won't take the new user long to find what they're looking for there. I thought Getting Started was a good title, but maybe I should change it to Introduction.
Re: DStep - Bindings Generator 0.0.1
On 2015-01-31 19:38, Chris wrote: At version 0.0.1? :) At version 0.1.0: https://github.com/jacob-carlborg/dstep/releases/tag/v0.1.0 -- /Jacob Carlborg
Re: Using import in map
On Saturday, 31 January 2015 at 19:52:11 UTC, Jacob Carlborg wrote: Is this supposed to work: enum foo = [foo].map!((string e) = import(e)); When I compile the above code with 2.066.1 I get the following error: main.d(1): Error: variable e cannot be read at compile time main.d(1): Error: file name argument must be a string, not (__error) I think this is not supposed to work. try staticMap maybe ?
Using import in map
Is this supposed to work: enum foo = [foo].map!((string e) = import(e)); When I compile the above code with 2.066.1 I get the following error: main.d(1): Error: variable e cannot be read at compile time main.d(1): Error: file name argument must be a string, not (__error) -- /Jacob Carlborg
Re: Problem with coupling shared object symbol visibility with protection
Am 31.01.2015 um 13:07 schrieb Martin Nowak: That's probably how it should behave, though an attribute applying only to public members unless explicitly added is unprecedented. Still seems like the right choice here, but might require some additional compiler logic. Well you don't have to implement it that way with in the compiler. The only thing that matters is, that the users sees this transitive behavior of export. It is not neccessary that the attribute actually gets applied recursivly within the compiler implementation. Only the export behavior needs to be implemented recursivly and I already did a implementation for that. It currently works for the export protection level and would be trivial to adapt for a export attribute. It would also not require any additional logic for applying attributes recursivly under certain conditions. @Walter: Making export a attribute seems to be the preferred choice in this discussion. Additionaly this was the result of the last discussion around export, a year ago, although for different reasons. The last Discussion resulted in DIP 45 which also proposes making export an attribute. Before I start with the implementation, would you be ok with making export an attribute or would you veto it? Kind Regards Benjamin Thaut
[Issue 14093] New: __traits(compiles, cast(Object)(tuple)) is true even if it doesn't compile.
https://issues.dlang.org/show_bug.cgi?id=14093
Issue ID: 14093
Summary: __traits(compiles, cast(Object)(tuple)) is true even
if it doesn't compile.
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: kpierre+dl...@outlook.com
This code does not compile on most DMD compiler version on Linux:
import std.typecons;
void main()
{
Tuple!(int, x, int, y) point;
static if (__traits(compiles, {auto newPoint = cast(Object)(point);}))
{
{auto newPoint = cast(Object)(point);}
}
}
The compiles trait evaluates to true, even though it's impossible to cast a
tuple to object.
The code compiles if I run it in DPaste version DMD 2.x Git (cfb5842b49). It
doesn't work in 2.065.0 or commit 7c769ec517e8acc086d92c9dc0d6a680b83f69f0.
Since this bug seems to come and go there should probably be a unit test for
it.
--
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 14:06:20 UTC, Piotrek wrote: ... +1, basically boost for D. I heavily agree that the libraries should complement Phobos and never be orthogonal to phobos lest we have another tangos/phobos situation.
Re: How to make a Currency class from std.BigInt?
The next version https://bpaste.net/show/9468f24d9df0
Re: Mars Drafting Library - Official community driven library
On 1/31/2015 7:10 AM, Piotrek wrote: I know that, but the naming is the least important aspect of the proposal. I agree. Let's not have endless posts bikeshedding the name, no matter how tempting.
Re: Mars Drafting Library - Official community driven library
I like the idea of having an additional library that we would ship alongside Phobos with every release. There of course some obvious pros and cons for having 'Mars' (or whatever is called) as a DUB packages vs included in the standard library: Pros for being a DUB package: + faster release cycles (push a new version any time). + semantic versioning (instead of dmd 2.0xx). + can depend on other DUB packages (doesn't need to include everything it uses beside Phobos, ofc). + can have different configurations / build types, be split in DUB subpackages and all the other nice things that the DUB package format provides. + can include other binaries (eg. C libs). + etc... Cons: - Probably not so well tested, because it won't get as wildly used as Phobos. - Third-party with zero guarantees. (You have to trust the author(s) that it is not malicious or anything like that). - Not everybody is comfortable with having DUB as a dependency on their project. - Can be a bit of an inconvenience if you only want to write a small script. - DUB doesn't have first class support in the major IDEs, AFAIK (for people that prefer them over the terminal). Actually I thing it's extremely simple to use on the command-ling and I have no problem with Mono-D or dub generate visuald, but it's not like the NuGet support in VS for .NET projects (AFAIR you can now have language plugins/analyzers based on Roslyn (linting, DSLs, etc.) which are NuGet packages that you download from their gallery). - etc... Pros being included alongside Phobos: + Better testing because more people can/will use it + Potentially better code, because of code review during pull requests and generally high standards for new stuff (like with std.experimental.logger). + More stable, because people may care more for backwards comparability (though the points is that this will not be guaranteed). + People new to the language will feel more comfortable using 'standard' libraries. + etc... Cons: - Extremely slow release cycle. - Hard to get new stuff (controversial like GUI) in. - Not being able to have external dependencies than druntime and Phobos (like bindings for C libraries) - etc... With all that said I still think that it is a good idea to have another library shipping alongside Phobos with every DMD release (or GDC, LDC, etc.). I think a good compromise would be the following: 1. Include DUB with DMD. We don't need a stable DUB as a library API to just use it to get other packages. 2. Make 'Mars' a DUB package and use semantic versioning to tag new releases. 3. Move it to github.com/D-Programming-Language/. 4. Include last known 'well working' with every DMD release. (Of course other implementations are free to decide whether to include it). Or we can have some post-installation script which would call DUB. 5. Afterwards if a new version of 'Mars' is released users can just do a 'dub upgrade' to update the one that's already included, or wait for a new official release. I really do thing that this would be a step in the right direction. For example Microsoft has been been using their package manager NuGet as a .NET Framework release vehicle quite successfully for the last couple of years. Here[1] you can see that they are providing quite large and heavily used parts of .NET. Another good idea is to separate Phobos from DMD and also put it on DUB. As you can see[2] many of the integral parts of.NET are provided as packages and people have no problem using them as such (you can see by the large download numbers). [1]: http://blogs.msdn.com/b/dotnet/p/nugetpackages.aspx [2]: https://www.nuget.org/packages
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 14:06:20 UTC, Piotrek wrote: Hi, The history of std.(experimental.)logger and the latest thread about gui functionality inclusion into Phobos made me think about how to solve the problem of adding new modules. I came up with the idea (maybe not new) to create a additional library(along druntime and Phobos) delivered with dmd package and named Mars (Deimos is unfortunately already taken ). The library itself would be driven by community (not individual library developer) in order to be... the standard. The process would be something similar to that other committees use (e.g http://www.iec.ch/standardsdev/how/processes/development/) where before the standard is approved it goes through a draft stage. Still a draft can be used to create a working product (e.g. some Wi-Fi solutions based on IEEE 802.11 drafts) Possible initial prerequisites: - User awareness about the usage consequences - Library placed at https://github.com/D-Programming-Language/ - Only well recognized community members have pull rights - design decision made on the best known sw engineering patterns used in D - New module should be functional with D/Phobos standards applied - API and implementation allowed to change any time in order to make a progress - no external dependencies beside OS services - draft as the root module name e.g. module draft.gui Advantages: - community driven process which ensures the lowest level of controversy - fast path for modules like GUI to be standardized Disadvantages: - additional effort for the sw release process Ready to be destroyed ;) Piotrek I approve :) +1
Re: Using import in map
On 2015-01-31 20:54, Stefan Koch wrote: I think this is not supposed to work. try staticMap maybe ? Yes, staticMap worked, thanks. I filed a bug [1]. If I recall correctly, if the compiler outputs a message which includes __error it's a bug. [1] -- /Jacob Carlborg
[Issue 14094] New: Using string import in map results in error message with __error
https://issues.dlang.org/show_bug.cgi?id=14094 Issue ID: 14094 Summary: Using string import in map results in error message with __error Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: d...@me.com I'm not sure if this is supposed to compile but the following will result a compile error which includes __error in the error message: import std.algorithm; enum foo = [foo].map!((string e) = import(e)); The error message is: main.d(2): Error: variable e cannot be read at compile time main.d(2): Error: file name argument must be a string, not (__error) --
Re: dlang.org Getting Started page
On Saturday, 31 January 2015 at 19:35:45 UTC, Zach the Mystic wrote: On Saturday, 31 January 2015 at 19:22:06 UTC, Jonathan Marler wrote: On Saturday, 31 January 2015 at 19:03:55 UTC, Zach the Mystic wrote: I'm looking for feedback for: https://github.com/D-Programming-Language/dlang.org/pull/878 https://issues.dlang.org/show_bug.cgi?id=14088 Investigation shows that the D Wiki is the best landing place for newcomers, so they are directed there first. I think the current page leaves newcomers a little bit stranded. Seems like a good idea to me. One thought, when I'm looking at a new language and I see a Getting Started, I would expect to see links for tutorials such as how to install and tutorials on writing Hello World... I would put those links first. In principle, I agree, but the front page of the Wiki has such links already, plus a whole lot more. It won't take the new user long to find what they're looking for there. I thought Getting Started was a good title, but maybe I should change it to Introduction. Personally, when I get started with a new language the first things I want are: 1. Examples (Hello World, File IO, some examples that demonstrate what makes the language unique). 2. I want to see an introduction to the language, what makes the language unique, what are the goals of the language, things like that. 3. I want to see language references, where can I go to reference how to do something in the language. 4. I want to see build/install/small program tutorials. I think these 4 things should require 1 click to get to. The user should be able to click on one link (Getting Started) is a good name, and then be able to see direct links to all these topics. Redirecting to a wiki is not horrible but I think the optimal design is to have one landing page that a user can go back to in order to get started and find everything they need. In our case, I think links to the wiki and forums would be good as well, but the most important things should be obvious and easy to get to. Splitting these topics up among the wiki and the dlang website makes it harder to get around, not horrible, but not optimal.
Re: [website redesign] PR for the one with the big red menu bar
On Saturday, 31 January 2015 at 12:22:32 UTC, Brian Schott wrote: That's no moon. That's a space station. :)
[Issue 14093] __traits(compiles, cast(Object)(tuple)) is true even if it doesn't compile.
https://issues.dlang.org/show_bug.cgi?id=14093 Pierre krafft kpierre+dl...@outlook.com changed: What|Removed |Added CC||kpierre+dl...@outlook.com --
Re: foreach - premature optimization vs cultivating good habits
On Friday, 30 January 2015 at 14:41:11 UTC, Laeeth Isharc wrote: Thanks, Adam. That's what I had thought (your first paragraph), but something Ola on a different thread confused me and made me think I didn't understand it, and I wanted to pin it down. There is always significant optimization effects in long running loops: - SIMD - cache locality / prefetching For the former (SIMD) you need to make sure that good code is generated either by hand, by using vectorized libraries or by auto vectorization. For the latter (cache) you need to make sure that the prefetcher is able to predict or is being told to prefetch explicitly and also that the working set is small enough to stay at the faster cache levels. If you want good performance you cannot ignore any of these, and you have to design the data structures and algorithms for it. Prefetching has to happen maybe 100 instructions before the actual load from memory and AVX requires byte alignment and a layout that fits the algorithm. On next gen Xeon Skylake I think the alignment might go up to 64 byte and you have 512 bits wide registers (so you can do 8 64 bit floating point operations in parallel per core). The difference between issuing 1-4 ops and issuing 8-16 per time unit is noticable... An of course, the closer your code is to theoretical throughput in the CPU, the more critical it becomes to not wait for memory loads. This is also a moving target...
Re: Harbored-mod (doc generator) 0.2: Cross-referencing, methods/fields no longer in separate files
On Saturday, 31 January 2015 at 18:47:28 UTC, Kiith-Sa wrote: Could you clone the current git master (https://github.com/kiith-sa/harbored-mod.git) and try if it works? It's ok now, i confirm the fix.
[Issue 14096] ICE in toir.c: 187
https://issues.dlang.org/show_bug.cgi?id=14096 Vlad Levenfeld vlevenf...@gmail.com changed: What|Removed |Added CC||vlevenf...@gmail.com --
[Issue 14096] New: ICE in toir.c: 187
https://issues.dlang.org/show_bug.cgi?id=14096
Issue ID: 14096
Summary: ICE in toir.c: 187
Product: D
Version: D1 D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: vlevenf...@gmail.com
with dmd git head:
--M1.d---
struct Baz (alias f)
{
void g (){}
}
auto baz (alias f)(void[])
{
return Baz!f();
}
auto bar ()
{
return [].baz!(i = i);
}
--M2.d---
import M1;
import std.typecons;
auto x (alias s)()
{
typeof(s) p;
}
auto foo (T)(T t)
{x!t;}
void main ()
{
tuple(bar).foo;
}
-result---
Internal error: toir.c 187
--
[Issue 14097] New: root/async.c: free after use
https://issues.dlang.org/show_bug.cgi?id=14097 Issue ID: 14097 Summary: root/async.c: free after use Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: critical Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: ket...@ketmar.no-ip.org Created attachment 1473 -- https://issues.dlang.org/attachment.cgi?id=1473action=edit fix use after free in async.c async file reader (windows version at least) has a nasty bug: it uses `AsyncRead` structure after `free()`. this is what makes dmd.exe crash under my wine. i found that by inserting `printf`s everywhere. then i saw this: ..\dmd\src\dmd.exe -c -o- -Isrc -Iimport -Hfimport\core\sync\barrier.di src\core\sync\barrier.d AsyncRead::create: aw = 00242754; max=1 *** addFile(file = 00262510) filesdim = 0, filesmax = 1 addFile done: (f = 00242760; file = 00262510; result=0; event=003C) *** ::start aw-filesdim = 00242754 1 *** AsyncRead::read 000 i=0 (f=00242760; file = 00262510; event = 003C) *** aw-filesdim = 00242754 1 ++ aw-filesdim = 00242754 1 i=0 000: i=0; f=00242760; file=2499856; event=003C 001: i=0; f=00242760; file=2499856; event=003C AsyncRead::read 001 i=0 (f=00242760; file = 00262510; event = 003C; res=0) AsyncRead::read 002 i=0 (f=00242760; file = 00262510; event = 003C; res=0) AsyncRead::dispose; aw = 00242754 002: i=0; f=00242760; file=2499856; event=003C startthread done: aw-filesdim = 00242754 1 the line 002: i=0; f=00242760; file=2499856; event=003C is from `startthread`, it printed right after `SetEvent(f-event);` call. as you can see, `AsyncRead::dispose` was already called, yet `startthread` is still using `aw`. seems that this is highly depends on timing, 'cause SOMETIMES (very rarely) dmd works ok in my wine. but most of the time it crashes. yet it works fine on real windows. nevertheless, just commenting out `free(aw);` in `AsyncRead::dispose` fixes it all. as dmd.exe leaks memory as crazy anyway, there is no harm in leaking a little more, and it was the easiest fix. posix version of this seems to be protected from the bug, as posix `AsyncRead::dispose` correctly waits while all operations on all files are complete. more than that, posix `startthread` correctly caches `aw-filesdim`, so it will not use freed memory in loop condition check. so i attached a patch that waits for completion of all file operations before freeing `aw`. this seems to fix the issue, and this is what posix version do. --
Re: H1 2015 Priorities and Bare-Metal Programming
On 1/31/2015 9:21 PM, Mike wrote: Is D's core team genuinely interested in this domain? Yes. If you are genuinely interested, are you committed? And if so, what direction would you like to take? So far, my ideas have been very unpopular and I'm growing weary fighting the current. How can I contribute in a way that gets us both where we want to go? I don't recall what you've suggested in this vein that was very unpopular - can you please post an example?
[Issue 11488] FORTRAN FORI= Error
https://issues.dlang.org/show_bug.cgi?id=11488 --- Comment #2 from Manfred Nowak svv1...@hotmail.com --- (In reply to Stewart Gordon from comment #1) If chaining of -, --. + and ++ is used heavily, then disallowing to shoot oneself is okay. Hint: - -- -- -- - --- -- - -- - -- - --x is currently a legal expression and I doubt that one can _see_ in general the positions at which a significant space is wrongly placed or deleted. Disallowing chaining requires to use paired paranthesis in such cases, which doubles the number of wrongly placed characters needed to make an error slip through. BTW: allowing such chaining makes D similar to an esoteric language. If chaining of those operators will never be used heavily, then there is no ratio for allowing the chaining. --
windows wininet library
how can i use wininet.dll from D? i got bindings from https://github.com/ CS-svnmirror/dsource-bindings-win32.git, and then i tried to create wininet.lib with implib.exe from DMC package. no matter how i tried, the resulting wininet.lib seems to not work, as linker keep complaining about missing symbols like _InternetReadFile@16 and so on. i'm building for win32. ah, and yep, i compiled wininet.lib to lib dir, and added option to dmd.exe: -L+wininet.lib. i assume that i have to create corrent .def file to remap all the names, am i right? oh, delightful... signature.asc Description: PGP signature
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 18:45:13 UTC, Israel wrote: On Saturday, 31 January 2015 at 18:11:48 UTC, Laeeth Isharc wrote: This has the advantage over existing situation where you have the official library where things need to go through exacting and time consuming process and then dub. Within dub every project is at the same level and it is not obvious which projects are the ones to use, and there is not necessarily coherence in the different ways things are done, and the only one motivated to work on supplementary features like documentation is the project author. So you have very useful, well written libraries that have no docs. What i hate about dub is that no every library is ready to use. Some require additional steps/resources in order to get them to work. Dub does not have any indication of that because the library authors don't usually include that information. What is good about this extra community driven standard library is that everything will be included in one place and will be at the ready when it is needed. Thanks. I wanted to mention the DUB packages but the post would be too long. DUB can be seen as a repository of special purpose packages without the burden of standardization process and out of the box properties. In general, this proposal assumes DUB repository will serve the same role as it does now. Piotrek
Re: Arrays, garbage collection
On 1/31/2015 8:08 AM, Andrei Alexandrescu wrote: On 1/31/15 1:10 AM, Martin Nowak wrote: Thanks for this code, it's a lot nicer and simpler than mine. -- Andrei So, pull request for std.array and reverting the dollar thingie? Problem solved? This looks like the way to go. I apologize to the community for the indecision shown. -- Andrei I'm on board with this, too.
Re: Harbored-mod (doc generator) 0.2: Cross-referencing, methods/fields no longer in separate files
On 1/02/2015 4:31 a.m., Kiith-Sa wrote: Harbored-mod (https://github.com/kiith-sa/harbored-mod) is a documentation generator based on Brian Schott's Harbored that supports both DDoc and Markdown in documentation comments. -- Examples of generated docs -- * Public imports in a package.d: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity.html * Class with a template parameter, member functions and aliases: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/entitymanager/EntityManager.html * Simple DDoc See_Also: section: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/componenttypeinfo/ImmutableRawComponent.html * Note: DDoc section with some markdown: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/processtypeinfo.html#prioritizeProcessOverloads -- Release highlights -- * Automatic cross-referencing in code blocks and inline code * New (and now default) output format: aggregated HTML; generate documentation files only for aggregates (modules, structs, classes, etc.) and document non-aggregate members (functions, variables, etc.) in these files. The previous, DDox compatible format, where a separate file is generated for every symbol, is still supported through the `--format=html-simple` option. * Various style and usability improvements * Major refactoring * Many bugfixes Full changelog: https://github.com/kiith-sa/harbored-mod/releases/tag/v0.2.0 Atleast on chrome win7 the font is absolutely awful. Otherwise, I LOVE!
Re: Harbored-mod (doc generator) 0.2: Cross-referencing, methods/fields no longer in separate files
On 1/02/2015 1:02 p.m., Rikki Cattermole wrote: On 1/02/2015 4:31 a.m., Kiith-Sa wrote: Harbored-mod (https://github.com/kiith-sa/harbored-mod) is a documentation generator based on Brian Schott's Harbored that supports both DDoc and Markdown in documentation comments. -- Examples of generated docs -- * Public imports in a package.d: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity.html * Class with a template parameter, member functions and aliases: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/entitymanager/EntityManager.html * Simple DDoc See_Also: section: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/componenttypeinfo/ImmutableRawComponent.html * Note: DDoc section with some markdown: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/processtypeinfo.html#prioritizeProcessOverloads -- Release highlights -- * Automatic cross-referencing in code blocks and inline code * New (and now default) output format: aggregated HTML; generate documentation files only for aggregates (modules, structs, classes, etc.) and document non-aggregate members (functions, variables, etc.) in these files. The previous, DDox compatible format, where a separate file is generated for every symbol, is still supported through the `--format=html-simple` option. * Various style and usability improvements * Major refactoring * Many bugfixes Full changelog: https://github.com/kiith-sa/harbored-mod/releases/tag/v0.2.0 Atleast on chrome win7 the font is absolutely awful. Otherwise, I LOVE! Also any chance that it could output json to represent modules instead of html?
2015 H1 Vision
Hello, Walter and I have been mulling for a while on a vision for the first six months of 2015. http://wiki.dlang.org/Vision/2015H1 This is stuff we consider important for D going forward and plan to work actively on. We encourage the D community to focus contributions along the same lines. We intentionally kept the document short and high-level as opposed to discussing tactical details. Such discussions are encouraged in the appropriate forums. Thanks, Walter and Andrei
[Issue 14097] root/async.c: free after use
https://issues.dlang.org/show_bug.cgi?id=14097 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright bugzi...@digitalmars.com --- https://github.com/D-Programming-Language/dmd/pull/4363 --
[Issue 13969] [REG2.063] [ICE] (backend\cgcod.c 2309) with cycle(iota(a,b,s))
https://issues.dlang.org/show_bug.cgi?id=13969 --- Comment #5 from Walter Bright bugzi...@digitalmars.com --- https://github.com/D-Programming-Language/dmd/pull/4364 --
[Issue 13969] [REG2.063] [ICE] (backend\cgcod.c 2309) with cycle(iota(a,b,s))
https://issues.dlang.org/show_bug.cgi?id=13969 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Hardware|x86 |All OS|Windows |All --
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 20:34:32 UTC, Zach the Mystic wrote: The most important thing about a standard library is decisiveness in the leadership about what *kinds* of things should be in it. When it's been made clear that a given task is worthy of inclusion in the standard library, there will be enough incentive for contributors to put in the time and effort required to meet its high standards. The intention of creating draft modules would be the inclusion in Phobos. In simplistic way, the following stages of development will be applied: 1. Proposal (DIP, NG discussion, DUB package showcase, local meet-up events etc) 2. Draft module creation and development 3 Approval for Phobos merge, i.e. draft - std But there are so many tasks that aren't quite up to that bar, either because they serve too specific a niche, or because there are two or more good, but conflicting ways to implement solutions, and no good way to decide between them. For any such task that doesn't meet those high standards, the library's development is best left to the community. But there is a place for the official recognition of existing libraries which have reached a level of quality that can be safely recommended. This is what is currently missing. To be clear. I treat current DMD and Phobos library development as community driven as well. The reason, the title includes community driven is that modules can't be made by independent developer, i.e. without community approval. As an example DUB packages don't fulfill this requirement. This is more of a second-party library system, for which idea I am indebted to this article: http://www.jfbillingsley.com/blog/?p=206 Suggestions for implementation? I briefly read the article and some parts are similar. However the difference is that Curiosity/Mars would form some kind of trinity with Druntime and Phobos. See also my answer to weaselcat's post (http://forum.dlang.org/post/mtqjtavxzjucixuyc...@forum.dlang.org). Piotrek
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 20:44:38 UTC, weaselcat wrote: On Saturday, 31 January 2015 at 14:06:20 UTC, Piotrek wrote: ... +1, basically boost for D. I heavily agree that the libraries should complement Phobos and never be orthogonal to phobos lest we have another tangos/phobos situation. Several points from prerequisites was intensionally chosen to prevent Phobos/Tango fiasco. The general rule is that the draft module should be treated as a potential Phobos module. Piotrek
[Issue 14095] explicitly exclude symbol from resolution consideration
https://issues.dlang.org/show_bug.cgi?id=14095 Jonathan M Davis issues.dl...@jmdavisprog.com changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m --- Comment #1 from Jonathan M Davis issues.dl...@jmdavisprog.com --- I would point out that if the bug that's causing the problem is bug# 314, then I'm pretty sure that pragma(excludeSymbol, std.array.array) wouldn't work anyway, because it would be viewed as being a member of whatever module had the selective import rather than std.array. If something else is causing the problem, then maybe your suggestion would work. I don't know. Regardless, it would be easier to diagnose what's causing your problem if you provide a code sample which exhibited it. The fact that you're not seeing a symbol conflict definitely makes me wonder what's going on. Unless UFCS is involved, you'd normally end up with a symbol conflict, and UFCS favors member functions over free functions, so it's unlikely that that would cause a free function like std.array.array to be favored. It may be some bug in overload resolution. But if you provide code, then maybe we could actually figure out what you're running into - and it may or may not be a previously reported bug. In any case, as a workaround, IIRC, alias array = myarray.array; at the module level will fix the problem so that within the module, array refers to myarray.array. regardless of the imports. So, you should probably try that. Or you could just use static imports for everything, but that would be pretty annoying. Of course, an even easier alternative would simply be to rename your array function to something else, as annoying as that might be. --
Re: use after free crashbug in DMD (and fix)
On Sun, 01 Feb 2015 03:27:06 +, ketmar wrote: On Sun, 01 Feb 2015 03:09:15 +, ZombineDev wrote: I have made a pull request[1] with your fix, if you don't mind. thank you. ah, and that caching is needed. `free()` in `AsyncRead::dispose` *can* be executed before loop in `startthread` finishes, so `startthread` will try to dereference `aw-filesdim` and hit the same use after free bug. multithreaded code is a very fragile thing. ;-) signature.asc Description: PGP signature
Re: use after free crashbug in DMD (and fix)
On Sun, 01 Feb 2015 03:09:15 +, ZombineDev wrote: I have made a pull request[1] with your fix, if you don't mind. thank you. signature.asc Description: PGP signature
[Issue 13952] change in struct ctor lowering triggers codegen bug
https://issues.dlang.org/show_bug.cgi?id=13952 --- Comment #2 from Martin Nowak c...@dawg.eu --- (In reply to Walter Bright from comment #1) Please provide a reproducible example. I already spend almost a day on this and couldn't reduce it to less than compiling Higgs and running the tests. Will try again, but it's definitely cause by the mentioned commit. --
[Issue 14093] [REG2.065] __traits(compiles, cast(Object)(tuple)) is true even if it doesn't compile.
https://issues.dlang.org/show_bug.cgi?id=14093 sinkuup...@gmail.com changed: What|Removed |Added CC||sinkuup...@gmail.com Hardware|x86_64 |All Summary|__traits(compiles, |[REG2.065] |cast(Object)(tuple)) is |__traits(compiles, |true even if it doesn't |cast(Object)(tuple)) is |compile.|true even if it doesn't ||compile. OS|Linux |All --- Comment #1 from sinkuup...@gmail.com --- Introduced in https://github.com/D-Programming-Language/dmd/pull/3009 (In reply to Pierre krafft from comment #0) The code compiles if I run it in DPaste version DMD 2.x Git (cfb5842b49). commit cfb5842b49 seems to be DMD 2.063.x. --
