Re: Improving assert-printing in DMD

[Per Nordlöw via Digitalmars-d]

On Thursday, 1 October 2015 at 19:04:51 UTC, Andrei Alexandrescu 
wrote:
* I don't think we need a new flag, just make the new behavior 
work.


So you mean that extra diagnostics should kick in when extra 
overloads are made visible via import of, for instance, 
`core.assert`?


* Should the lowering happen only on the function called if the 
assertion actually fails? Then no more need for laziness and 
other complications.


Could explain what you mean by *lowering*, please?

I'm currently unsure whether
in L lhs
or
lazy L lhs

should be used and whether or not we should use
version(assert)

See the added example at
http://wiki.dlang.org/DIP83


* Extend to other expressions (!=, ordering etc).


How should we categorize expressions? Like this
- Unary: assert(x UNOP y)
- Binary: assert(x BINOP y)
- Function Calls: assert(f(x,y))
- Other: assert(x)

Does it suffice to just mention these or should I be explicit 
exactly about which operators for each category that should be 
included?

Re: Go, D, and the GC

[Iain Buclaw via Digitalmars-d]

On 1 Oct 2015 11:35 am, "Tourist via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> Hi Guys,
>
> I know that Go invested many time and resources in an implementation of a
good GC. And they keep working on it, e.g.
https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md
>
> I also see that the implementation is licensed as BSD, as far as I see:
https://github.com/golang/go/blob/master/LICENSE
>
> Question: is it possible to make a D compiler/runtime that uses Go's GC?
Wouldn't it largely benefit D? I guess that I'm not the first one to think
about it. Thoughts?

Why do you think Go's GC might be better than D's?  Is it because we lack
the PR when changes/innovations are done to the GC in druntime?  Do you
*know* about anything new that has changed or improved in D's GC over the
last two years?

I'd be interested to hear about this.

Re: Is Anything Holding you back?

[crimaniak via Digitalmars-d]

Full-featured PDF library (with JBIG2 and Jpeg2000 support and so 
on...)

Re: Improving assert-printing in DMD

[Per Nordlöw via Digitalmars-d]

On Thursday, 1 October 2015 at 17:33:51 UTC, Jack Stouffer wrote:
Bikesheading: could you change "being" in "([1,2,3][2] being 3) 
!= ([1,2,4][2] being 4)" and the other examples to "is"?


Done.

Re: problem with exceptions

[steven kladitis via Digitalmars-d-learn]

On Friday, 2 October 2015 at 12:18:36 UTC, Dmitri wrote:
On Friday, 2 October 2015 at 11:44:21 UTC, steven kladitis 
wrote:

C:\d\examples>pb2
=>main's first line
  =>makeOmelet's first line
=>prepareAll's first line
  =>prepareEggs's first line
object.Exception@pb2.d(64): Cannot take -8 eggs from the fridge

0x00402252
0x0040512F
0x00405043
0x00403E48
0x7600338A in BaseThreadInitThunk
0x77A497F2 in RtlInitializeExceptionChain
0x77A497C5 in RtlInitializeExceptionChain


- I always see the info at the bottom. Is this normal. I 
was thinkig I should only the the exception message itself.

---  this is windows 7 32 bit.


that would the stack of the thread leading up to the exception. 
I think you get that if you dump the exception object itself 
(not just the message).


-- code is below
import std.stdio;
import std.string;

void indent(in int level)
{
foreach (i; 0 .. level * 2)
{
write(' ');
}
}
void entering(in char[] functionName, in int level)
{
indent(level);
writeln("=>", functionName, "'s first line");
}
void exiting(in char[] functionName, in int level)
{
indent(level);
writeln("<=", functionName, "'s last line");
}
void main()
{
entering("main", 0);
makeOmelet(-8);
eatOmelet();
exiting("main", 0);
}
void makeOmelet(int eggCount)
{
entering("makeOmelet", 1);
prepareAll(eggCount);
cookEggs();
cleanAll();
exiting("makeOmelet", 1);
}
void eatOmelet()
{
entering("eatOmelet", 1);
exiting("eatOmelet", 1);
}
void prepareAll(int eggCount)
{
entering("prepareAll", 2);
prepareEggs(eggCount);
prepareButter();
preparePan();
exiting("prepareAll", 2);
}
void cookEggs()
{
entering("cookEggs", 2);
exiting("cookEggs", 2);
}
void cleanAll()
{
entering("cleanAll", 2);
exiting("cleanAll", 2);
}
void prepareEggs(int count)
{
entering("prepareEggs", 3);
if (count < 1)
{
throw new Exception(
  format("Cannot take %s eggs from the fridge", 
count));

}
exiting("prepareEggs", 3);
}
void prepareButter()
{
entering("prepareButter", 3);
exiting("prepareButter", 3);
}
void preparePan()
{
entering("preparePan", 3);
exiting("preparePan", 3);
}

Re: Is Anything Holding you back?

[Jonathan M Davis via Digitalmars-d]

On Friday, 2 October 2015 at 13:24:10 UTC, Andrei Alexandrescu 
wrote:

On 10/02/2015 09:11 AM, Dmitry Olshansky wrote:

On 02-Oct-2015 05:25, Yaser wrote:
Are there any critical frameworks or libraries that are 
holding you back
in fully investing in D? Obviously I think D is an awesome 
language, but
some frameworks/libraries hold me back, wish I could do 
everything in D.


My personal favorite (8+ years old OMG):
https://issues.dlang.org/show_bug.cgi?id=1238

Makes me want to laugh every time we discuss "problems" of D. 
Bugs are

as usual at the top of problems in my book.


I agree it's a hole in the module system, but it's not quite 
something that prevents work from being done.


And couple more from the miserable line of basic encapsulation 
not working:


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


These seem in the same category. Not to say they aren't 
important.


Yeah. They do make it much easier to break other code when you 
make changes (including making changes in something like Phobos), 
but mostly, they don't prevent work getting done. They are pretty 
embarrassing though.


- Jonathan M Davis

Re: Compile failing with D 2.068.2 works with 2.068.1

[ponce via Digitalmars-d]

On Thursday, 1 October 2015 at 23:01:59 UTC, Zz wrote:


Can you post the code that causes the error?


I traced it to when JSONValue get is being used.

{
  import stdx.data.json;

  string str = `{"a": true, "b": "test"}`;
  auto v = parseJSONValue(str);

  // The following line causes the problem in 2.068.2
  auto obj = v.get!(JSONValue[string]);
}

Zz


Please enter a bugzilla issue, else it will be forgotten.

Re: Improving assert-printing in DMD

[Nordlöw via Digitalmars-d]

On Friday, 2 October 2015 at 14:08:06 UTC, Jacob Carlborg wrote:

On 2015-10-02 14:15, Per Nordlöw wrote:

So lowering is kind of like macro expansion for AST-nodes, 
then?


Is DMD clever enough to avoid trigger postblits for


The compiler just rewrites the AST.


So you mean that no postblits are called and we should go with 
Andreis first lowering proposal?

Re: std.data.json formal review

[Marco Leise via Digitalmars-d]

Am Tue, 28 Jul 2015 14:07:18 +
schrieb "Atila Neves" :

> Start of the two week process, folks.
> 
> Code: https://github.com/s-ludwig/std_data_json
> Docs: http://s-ludwig.github.io/std_data_json/
> 
> Atila

There is one thing I noticed today that I personally feel
strongly about: Serialized double values are not restored
accurately. That is, when I send a double value via JSON and
use enough digits to represent it accurately, it may not be
decoded to the same value. `std.json` does not have this
problem with the random values from [0..1) I tested with.
I also tried `LexOptions.useBigInt/.useLong` to no avail.

Looking at the unittests it seems the decision was deliberate,
as `approxEqual` is used in parsing tests. JSON specs don't
enforce any specific accuracy, but they say that you can
arrange for a lossless transmission of the widely supported
IEEE double values, by using up to 17 significant digits.

-- 
Marco

Re: Improving assert-printing in DMD

[Dicebot via Digitalmars-d]

On Friday, 2 October 2015 at 12:27:11 UTC, Per Nordlöw wrote:

What about the case

assert(f(expr))
assert(symbol)

Should `op` be empty in that casesor should we use yet another 
overload


onAssertFailed(e, __FILE__, ...)

for that case?


empty op for unary overload

[Issue 15060] Can't load a D shared library first, then load a C shared library

[via Digitalmars-d-bugs]

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

--- Comment #14 from bitwise  ---
(In reply to Jacob Carlborg from comment #13)
> (In reply to bitwise from comment #12)
> > (In reply to Jacob Carlborg from comment #10)
> > >> DMD already does what's necessary for ELF (Linux, FreeBSD). Just do the 
> > >> same
> > >> for Mach-O and OS X.
> > 
> > That's easier said than done ;)
> 
> :)
> 
> > This is why I was saying we should just add some(or one special one) pragmas
> > that will allow this to be done in the front end.
> 
> I don't think this can be completely done in the front end. The code (or
> that function) that should be run as a global ctor/dtor need to be placed in
> a special segment/section, if I recall correctly.

Right, which is why I am recommending the special pragmas(or pragma).

--

Re: Is Anything Holding you back?

[Dmitry Olshansky via Digitalmars-d]

On 02-Oct-2015 05:25, Yaser wrote:

Are there any critical frameworks or libraries that are holding you back
in fully investing in D? Obviously I think D is an awesome language, but
some frameworks/libraries hold me back, wish I could do everything in D.


My personal favorite (8+ years old OMG):
https://issues.dlang.org/show_bug.cgi?id=1238

Makes me want to laugh every time we discuss "problems" of D. Bugs are 
as usual at the top of problems in my book.


And couple more from the miserable line of basic encapsulation not working:

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

And there is even more to dig up.

--
Dmitry Olshansky

Re: problem with exceptions

[Dmitri via Digitalmars-d-learn]

On Friday, 2 October 2015 at 12:45:38 UTC, steven kladitis wrote:

On Friday, 2 October 2015 at 12:18:36 UTC, Dmitri wrote:
On Friday, 2 October 2015 at 11:44:21 UTC, steven kladitis 
wrote:

C:\d\examples>pb2
=>main's first line
  =>makeOmelet's first line
=>prepareAll's first line
  =>prepareEggs's first line
object.Exception@pb2.d(64): Cannot take -8 eggs from the 
fridge


0x00402252
0x0040512F
0x00405043
0x00403E48
0x7600338A in BaseThreadInitThunk
0x77A497F2 in RtlInitializeExceptionChain
0x77A497C5 in RtlInitializeExceptionChain


- I always see the info at the bottom. Is this normal. I 
was thinkig I should only the the exception message itself.

---  this is windows 7 32 bit.


that would the stack of the thread leading up to the 
exception. I think you get that if you dump the exception 
object itself (not just the message).


-- code is below
import std.stdio;
import std.string;

void indent(in int level)
{
foreach (i; 0 .. level * 2)
{
write(' ');
}
}
void entering(in char[] functionName, in int level)
{
indent(level);
writeln("=>", functionName, "'s first line");
}
void exiting(in char[] functionName, in int level)
{
indent(level);
writeln("<=", functionName, "'s last line");
}
void main()
{
entering("main", 0);
makeOmelet(-8);
eatOmelet();
exiting("main", 0);
}
void makeOmelet(int eggCount)
{
entering("makeOmelet", 1);
prepareAll(eggCount);
cookEggs();
cleanAll();
exiting("makeOmelet", 1);
}
void eatOmelet()
{
entering("eatOmelet", 1);
exiting("eatOmelet", 1);
}
void prepareAll(int eggCount)
{
entering("prepareAll", 2);
prepareEggs(eggCount);
prepareButter();
preparePan();
exiting("prepareAll", 2);
}
void cookEggs()
{
entering("cookEggs", 2);
exiting("cookEggs", 2);
}
void cleanAll()
{
entering("cleanAll", 2);
exiting("cleanAll", 2);
}
void prepareEggs(int count)
{
entering("prepareEggs", 3);
if (count < 1)
{
throw new Exception(
  format("Cannot take %s eggs from the fridge", 
count));

}
exiting("prepareEggs", 3);
}
void prepareButter()
{
entering("prepareButter", 3);
exiting("prepareButter", 3);
}
void preparePan()
{
entering("preparePan", 3);
exiting("preparePan", 3);
}


I guess it's normal:
void main()
{
throw new Exception("duh");
}

-->
object.Exception@/home/d955/f505.d(3): duh
 
./f505(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x1f) [0x41e467] ./f505(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x41e3c2] ./f505(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()+0x2b) [0x41e423] ./f505(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x41e3c2] ./f505(_d_run_main+0x1d2) [0x41e342] ./f505(main+0x12) [0x41d9ce] /usr/lib/libc.so.6(__libc_start_main+0xf5) [0x40967a15]



Looks like the runtime always dumps the uncaught exception that 
way. If you need it any other way, catch by Exception and print 
only the message.

Re: Improving assert-printing in DMD

[Andrei Alexandrescu via Digitalmars-d]

On 10/02/2015 08:15 AM, Per Nordlöw wrote:

On Friday, 2 October 2015 at 11:19:51 UTC, Andrei Alexandrescu wrote:

assert(e1 == e2)

could be lowered into:

{
  auto a = e1, b = e2;
  if (a == b) return;
  onAssertFailed!"=="(a, b, __FILE__, __LINE__, __FUNCTION__,
__MODULE__);
}()


So lowering is kind of like macro expansion for AST-nodes, then?


Not sure what you mean. The code up there will be replaced with the code 
down there :o).



Is DMD clever enough to avoid trigger postblits for


  auto a = e1, b = e2;
  if (a == b) return;


? Or is that part of the question whether this will work?


Ah, interesting. There is a means in the compiler to generate ref 
variables, which is not accessible for user code. But perhaps that's not 
necessary if we do the lowering as such:


(auto ref a, auto ref b) {
  if (a == b) return;
  onAssertFailed!"=="(a, b, __FILE__, __LINE__, __FUNCTION__, __MODULE__);
}(e1, e2)

So that evaluates the two expressions and avoids creating copies for 
lvalues.



I guess we only need on symbol name for `onAssertFailed` then instead of
`assertBinOp` and `assertUnOp`, right?


Probably a judgment call. I'd start with one and see what happens.


Andrei

Re: Improving assert-printing in DMD

[Atila Neves via Digitalmars-d]

On Thursday, 1 October 2015 at 17:19:39 UTC, Per Nordlöw wrote:
On Thursday, 1 October 2015 at 14:37:55 UTC, Andrei 
Alexandrescu wrote:
Whoever wants to work on better assert expression printing: 
make sure you specify which grammar constructs are supported, 
and how the parts involved are printed. Expressing semantics 
via lowering would be great. Write a DIP, discuss, implement. 
I'll have your six.



Andrei


A first version:

http://wiki.dlang.org/DIP83


I like the idea, I just have a practical question on 
std.experimental.testing: should it go ahead as-is? Should the 
custom assertions be removed and the rest kept? Should they go in 
as-is and then deleted when/if this DIP is implemented?


Atila

Re: Is Anything Holding you back?

[Chris via Digitalmars-d]

On Friday, 2 October 2015 at 03:34:18 UTC, Adam D. Ruppe wrote:

Moreover, and this is really important, D can already interact 
the majority of existing software out there.


This is a very important point that is often forgotten. What has 
been done in C is also available to D. To work with D you don't 
need to have everything written in D. If that was the case, no 
new language could ever be used, because it's impossible to catch 
up with the wealth of libraries that already exist in C/C++.


And through C you can communicate with other languages too, 
Python, Lua etc. Look at PyD and LuaD for example or the 
DerelictD stuff.


One caveat though: if your software is GUI-centered, research the 
possibilities in D. If you wanna go mobile (ARM), check carefully 
what can be done already and what can't.

Re: Interface file

[Atila Neves via Digitalmars-d]

On Thursday, 1 October 2015 at 17:12:02 UTC, Jeremy DeHaan wrote:
On Thursday, 1 October 2015 at 01:41:22 UTC, Jan Johansson 
wrote:

[...]


Having the declarations in both files is the point though.

If you notice, the only difference between my test.d and 
test.di files is that test.di is only the declarations. The 
speed increase for compiling happens because of this. You still 
need all declarations to be there when you build, or at least 
the ones you use.


You build the library with test.d and then build using test.di 
when you use the library. You never use both test.d and test.di 
together. Double check my build commands.


The linker will be the bottleneck anyway, I don't think .di files 
are worth it.


Atila

http://wiki.dlang.org/Building_DMD improvements

[Andrei Alexandrescu via Digitalmars-d]

The Wiki page http://wiki.dlang.org/Building_DMD could be easily 
reorganized to make better.


Currently it uses sections such as "Getting the sources", "Building the 
sources", etc. Within each seion there's a Posix section and a Windows 
section.


However, folks using e.g. Windows have no interest in Posix and 
shouldn't have to skip through portions of the document.


So the better organization would be to fork the page into two, and have 
http://wiki.dlang.org/Building_DMD link to them:


* Building on Windows
* Building on Posix

Could someone please look into this? I see the main author is BBaz, is 
(s)he active on this forum?



Thanks,

Andrei

Re: Improving assert-printing in DMD

[Timon Gehr via Digitalmars-d]

On 10/02/2015 02:47 AM, deadalnix wrote:

...
  - assert already have a fair amount of magic, notably assert(0) change
the way control flow works.


Yes, and it is not stellar design. Generally, if it is not possible to 
wrap a statement or expression in a function without changing its 
semantics, the language provides too much magic and insufficient 
abstraction capabilities. (Of course, in practice, there might be 
legitimate reasons to deviate from this principle, but less often than 
one might think.)



Having it as an expression is making
everything very convoluted for no reason.


What is the problem with assert expressions?

Re: Improving assert-printing in DMD

[Andrei Alexandrescu via Digitalmars-d]

On 10/02/2015 02:31 AM, Per Nordlöw wrote:

On Thursday, 1 October 2015 at 19:04:51 UTC, Andrei Alexandrescu wrote:

* I don't think we need a new flag, just make the new behavior work.


So you mean that extra diagnostics should kick in when extra overloads
are made visible via import of, for instance, `core.assert`?


* Should the lowering happen only on the function called if the
assertion actually fails? Then no more need for laziness and other
complications.


Could explain what you mean by *lowering*, please?


Rewrite proposed constructs into simpler constructs that already exist. 
That way we don't need to invent semantics, just "see lowering".



I'm currently unsure whether
 in L lhs
or
 lazy L lhs


That's why I think it's better to go with calling the function only 
after the assertion has failed. E.g.,


assert(e1 == e2)

could be lowered into:

{
  auto a = e1, b = e2;
  if (a == b) return;
  onAssertFailed!"=="(a, b, __FILE__, __LINE__, __FUNCTION__, __MODULE__);
}()

or something similar (I'm glossing over the details). Point is the 
expressions are only evaluated once and then passed into onAssertFailed.


There'd be a default definition of onAssertFailed in object.d.


should be used and whether or not we should use
 version(assert)


Yah, all expansions related to assert() are only in effect if assertions 
are used. Otherwise, assert disappears and that's not configurable.



See the added example at
http://wiki.dlang.org/DIP83


* Extend to other expressions (!=, ordering etc).


How should we categorize expressions? Like this
- Unary: assert(x UNOP y)
- Binary: assert(x BINOP y)
- Function Calls: assert(f(x,y))
- Other: assert(x)

Does it suffice to just mention these or should I be explicit exactly
about which operators for each category that should be included?


I think you should use the names of the grammatical constructs, e.g. 
http://dlang.org/expression.html#EqualExpression.



Andrei

std.experimental.allocator

[Andrei Alexandrescu via Digitalmars-d]

It's been bitrotting for a while, I've rebased and it has passed tests 
now. Who will do the honors?


https://github.com/D-Programming-Language/phobos/pull/3405

There are three pull requests open against my fork, I invite the authors 
to rebase them or retarget them against the phobos mainline after 3405 
is pulled.



Thanks,

Andrei

Continuous bootstrapping in dmd

[Andrei Alexandrescu via Digitalmars-d]

Currently, if AUTO_BOOTSTRAP=1 flag is passed to the make command for 
dmd, an existing dmd build is downloaded off of the Net into a temporary 
directory and used to bootstrap building the compiler.


This is great for machines that either don't have dmd or have an older 
version installed.


However, there's no easy way to _continue_ auto-bootstrapping, i.e. 
using the just-built dmd to build the "next" dmd. For that we need a few 
simple changes such as making temporary copies of dmd etc.


Is this a model that would be of interest to dmd contributors?


Andrei

Re: Walter and I talk about D in Romania

[Andrei Alexandrescu via Digitalmars-d-announce]

On 10/02/2015 08:03 AM, Dicebot wrote:

If only this was mentioned at least few weeks earlier I'd try to attend :(


My mistake, sorry. -- Andrei

Re: std.experimental.allocator

[Jonathan M Davis via Digitalmars-d]

On Friday, 2 October 2015 at 13:12:47 UTC, Andrei Alexandrescu 
wrote:
It's been bitrotting for a while, I've rebased and it has 
passed tests now. Who will do the honors?


Done.

- Jonathan M Davis

Re: Linker error with dmd

[John Colvin via Digitalmars-d-learn]

On Friday, 2 October 2015 at 09:43:54 UTC, Chris wrote:
Why do I get this error msg with dmd 2.067.1 and 2.068.0 in 
release mode:


$ dub --build=release

(.data._D65TypeInfo_xC3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ+0x10):
 undefined reference to 
`_D64TypeInfo_C3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ'
collect2: error: ld returned 1 exit status
--- errorlevel 1
dmd failed with exit code 1.

It works fine with the latest version of ldc2.


What is it that you are building?

Re: Is Anything Holding you back?

[Jack Stouffer via Digitalmars-d]

On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
Are there any critical frameworks or libraries that are holding 
you back in fully investing in D? Obviously I think D is an 
awesome language, but some frameworks/libraries hold me back, 
wish I could do everything in D.


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

This is honestly embarrassing for me when ever I mention D to 
someone.

[Issue 15060] Can't load a D shared library first, then load a C shared library

[via Digitalmars-d-bugs]

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

--- Comment #15 from bitwise  ---
(In reply to bitwise from comment #14)
> (In reply to Jacob Carlborg from comment #13)
> > [...]
>
> Right, which is why I am recommending the special pragmas(or pragma).

Basically, we need these:

pragma(attribute, weak)
pragma(visibility, hidden)
pragma(section, "__mod_init_func");
pragma(section, "__mod_term_func");

--

Re: Walter and I talk about D in Romania

[Dragos Carp via Digitalmars-d-announce]

On Friday, 2 October 2015 at 12:03:59 UTC, Dicebot wrote:
If only this was mentioned at least few weeks earlier I'd try 
to attend :(


Then don't miss this: http://codedive.pl/en/agenda/

Re: In the age of AliasSeq, how to refer to template tuple parameters?

[Mike Parker via Digitalmars-d]

On Friday, 2 October 2015 at 12:31:35 UTC, Mike Parker wrote:
On a whim, I went to [1], which I had previously referenced in 
the book, and found that all of the content that was previously 
there has been replaced by a couple of sentences pointing to 
std.typecons and to [2]. It also says we should no longer refer


[1] http://dlang.org/tuple.html
[2] http://dlang.org/ctarguments.html

Re: In the age of AliasSeq, how to refer to template tuple parameters?

[Mike Parker via Digitalmars-d]

On Thursday, 1 October 2015 at 08:20:52 UTC, Mike Parker wrote:

What's the official way to refer to T... now? In std.meta,


On a whim, I went to [1], which I had previously referenced in 
the book, and found that all of the content that was previously 
there has been replaced by a couple of sentences pointing to 
std.typecons and to [2]. It also says we should no longer refer 
tuple is now discouraged in reference to T The second link is 
all about Compile-Time Argument Lists, which is apparently the 
new name.


If that's the case, then the template docs need to be updated so 
that they no longer refer to "Template Tuple Parameters".

Re: Checking that a template parameter is an enum

[Per Nordlöw via Digitalmars-d-learn]

On Thursday, 1 October 2015 at 22:37:57 UTC, Ali Çehreli wrote:

template allSame(V...)
if (isExpressions!(V))
{
bool impl_(V...)() {
static if (V.length > 1) {
foreach (i, _; V[0 .. $ - 1]) {
if (V[i] != V[i + 1]) {
return false;
}
}

return true;

} else {
return true;
}
}

enum allSame = impl_!V();
}


Will proposed `static foreach` reduce number of instantiations 
here?

Re: In the age of AliasSeq, how to refer to template tuple parameters?

[Dmitry Olshansky via Digitalmars-d]

On 02-Oct-2015 15:32, Mike Parker wrote:

On Friday, 2 October 2015 at 12:31:35 UTC, Mike Parker wrote:

On a whim, I went to [1], which I had previously referenced in the
book, and found that all of the content that was previously there has
been replaced by a couple of sentences pointing to std.typecons and to
[2]. It also says we should no longer refer


[1] http://dlang.org/tuple.html
[2] http://dlang.org/ctarguments.html


Article used terminology that was then changed sadly nobody felt strong 
enough to rewrite the article to use AliasSeq (the e-hm actual new name).


--
Dmitry Olshansky

Re: In the age of AliasSeq, how to refer to template tuple parameters?

[Mike Parker via Digitalmars-d]

On Friday, 2 October 2015 at 12:40:02 UTC, Dmitry Olshansky wrote:

On 02-Oct-2015 15:32, Mike Parker wrote:

On Friday, 2 October 2015 at 12:31:35 UTC, Mike Parker wrote:
On a whim, I went to [1], which I had previously referenced 
in the
book, and found that all of the content that was previously 
there has
been replaced by a couple of sentences pointing to 
std.typecons and to

[2]. It also says we should no longer refer


[1] http://dlang.org/tuple.html
[2] http://dlang.org/ctarguments.html


Article used terminology that was then changed sadly nobody 
felt strong enough to rewrite the article to use AliasSeq (the 
e-hm actual new name).


I see. Well, it does mention AliasSeq. While that may work for 
the std.meta template, I just don't see how that's even a 
remotely useful name for T...


It really was much easier to explain the tuple mess before these 
changes were made.

Re: In the age of AliasSeq, how to refer to template tuple parameters?

[Dicebot via Digitalmars-d]

On Friday, 2 October 2015 at 12:31:35 UTC, Mike Parker wrote:
The second link is all about Compile-Time Argument Lists, which 
is apparently the new name.


Heh, I have written that second article for initial `std.meta` PR 
(one that used name `MetaList` and got reverted eventually). 
Looks like it was still merged with some modification for 
`AliasSeq` but uses my old terminology in some places. I'd warn 
against taking it as very official source :)

Re: Improving assert-printing in DMD

[Andrei Alexandrescu via Digitalmars-d]

On 10/02/2015 08:31 AM, Dicebot wrote:

On Friday, 2 October 2015 at 12:27:11 UTC, Per Nordlöw wrote:

What about the case

assert(f(expr))
assert(symbol)

Should `op` be empty in that casesor should we use yet another overload

onAssertFailed(e, __FILE__, ...)

for that case?


empty op for unary overload


Even better. -- Andrei

Re: Is Anything Holding you back?

[Andrei Alexandrescu via Digitalmars-d]

On 10/02/2015 09:11 AM, Dmitry Olshansky wrote:

On 02-Oct-2015 05:25, Yaser wrote:

Are there any critical frameworks or libraries that are holding you back
in fully investing in D? Obviously I think D is an awesome language, but
some frameworks/libraries hold me back, wish I could do everything in D.


My personal favorite (8+ years old OMG):
https://issues.dlang.org/show_bug.cgi?id=1238

Makes me want to laugh every time we discuss "problems" of D. Bugs are
as usual at the top of problems in my book.


I agree it's a hole in the module system, but it's not quite something 
that prevents work from being done.



And couple more from the miserable line of basic encapsulation not working:

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


These seem in the same category. Not to say they aren't important.


Andrei

Re: Is Anything Holding you back?

[Andrei Alexandrescu via Digitalmars-d]

On 10/02/2015 08:54 AM, Jack Stouffer wrote:

On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:

Are there any critical frameworks or libraries that are holding you
back in fully investing in D? Obviously I think D is an awesome
language, but some frameworks/libraries hold me back, wish I could do
everything in D.


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


Do we have an attack on this problem? -- Andrei

Re: Improving assert-printing in DMD

[Andrei Alexandrescu via Digitalmars-d]

On 10/02/2015 08:27 AM, Per Nordlöw wrote:

On Friday, 2 October 2015 at 12:15:13 UTC, Per Nordlöw wrote:

I guess we only need on symbol name for `onAssertFailed` then instead
of `assertBinOp` and `assertUnOp`, right?


And two overloads

Binary case:

 onAssertFailed(string op)(e1, e2, __FILE__, ...)

Unary case:

 onAssertFailed(string op)(e, __FILE__, ...)

I presume?


Sounds good.


Because number of arguments to each overload will be fixed, right?

What about the case

assert(f(expr))
assert(symbol)

Should `op` be empty in that casesor should we use yet another overload

 onAssertFailed(e, __FILE__, ...)

for that case?


I'd say lower the same as (e !is 0) for numerics and (e !is null) for 
the others.



Andrei

Re: Walter and I talk about D in Romania

[Andrei Alexandrescu via Digitalmars-d-announce]

On 10/02/2015 08:01 AM, Per Nordlöw wrote:

On Friday, 2 October 2015 at 11:25:44 UTC, Andrei Alexandrescu wrote:

Walter and I will travel to Brasov, Romania to hold an evening-long
event on the D language. There's been strong interest in the event
with over 300 registrants so far.


Great!

Will there be video recordings?


I don't think so. -- Andrei

[Issue 15136] If we want toStringz to be fully correct, it needs to stop checking for '\0'

[via Digitalmars-d-bugs]

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

Andrej Mitrovic  changed:

   What|Removed |Added

 CC||andrej.mitrov...@gmail.com

--- Comment #1 from Andrej Mitrovic  ---
+1. If we really need to avoid memory allocations let's just add an overload or
something like assumeZeroTerminated or something..

--

Re: problem with exceptions

[Mike Parker via Digitalmars-d-learn]

On Friday, 2 October 2015 at 11:44:21 UTC, steven kladitis wrote:

C:\d\examples>pb2
=>main's first line
  =>makeOmelet's first line
=>prepareAll's first line
  =>prepareEggs's first line
object.Exception@pb2.d(64): Cannot take -8 eggs from the fridge

0x00402252
0x0040512F
0x00405043
0x00403E48
0x7600338A in BaseThreadInitThunk
0x77A497F2 in RtlInitializeExceptionChain
0x77A497C5 in RtlInitializeExceptionChain


- I always see the info at the bottom. Is this normal. I 
was thinkig I should only the the exception message itself.

---  this is windows 7 32 bit.


The info at the bottom is the backtrace. Compiling with -g should 
make it readable (with function names and such).

```
void bar(int i) {
if(i > 10)
throw new Exception("i is too large!!");
}

void main() {
bar(12);
}
```

dmd -g foo

object.Exception@foo.d(14): i is too large!!

0x00402055 in void foo.bar(int) at 
C:\LearningD\Chapter05\foo.d(15)

0x00402065 in _Dmain at C:\LearningD\Chapter05\foo.d(19)
0x00402916 in 
D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv
0x004028EB in void rt.dmain2._d_run_main(int, char**, extern (C) 
int function(char[][])*).runAll()

0x004027FF in _d_run_main
0x004024F4 in main
0x00419F51 in mainCRTStartup
0x75803744 in BaseThreadInitThunk
0x770EA064 in RtlSetCurrentTransaction
0x770EA02F in RtlSetCurrentTransaction

Re: Improving assert-printing in DMD

[Jacob Carlborg via Digitalmars-d]

On 2015-10-02 14:15, Per Nordlöw wrote:


So lowering is kind of like macro expansion for AST-nodes, then?

Is DMD clever enough to avoid trigger postblits for


The compiler just rewrites the AST.

--
/Jacob Carlborg

Re: Is Anything Holding you back?

[Sönke Ludwig via Digitalmars-d]

Am 02.10.2015 um 10:15 schrieb Kagamin:

On Friday, 2 October 2015 at 08:03:03 UTC, Dmitry Olshansky wrote:

On 02-Oct-2015 10:49, Kagamin wrote:

On Friday, 2 October 2015 at 05:15:26 UTC, luminousone wrote:

vibe.d compatible sqlite, postgresql, and oracle sql drivers.


An ODBC driver would be fine too, anything that can connect to a
database.


http://dlang.org/phobos/etc_c_odbc_sql.html


http://wiki.dlang.org/Libraries_and_Frameworks#Databases


http://code.dlang.org/?sort=name=library.database

Re: Checking that a template parameter is an enum

[John Colvin via Digitalmars-d-learn]

On Friday, 2 October 2015 at 08:13:00 UTC, John Colvin wrote:

On Thursday, 1 October 2015 at 22:26:39 UTC, Nordlöw wrote:

On Thursday, 1 October 2015 at 02:06:48 UTC, Fusxfaranto wrote:

[...]


Thanks!

BTW: Is there some way to turn the recursive definition of 
`allSame`


template allSame(V...)
if (isExpressions!(V))
{
static if (V.length <= 1)
enum allSame = true;
else
enum allSame = V[0] == V[1] && allSame!(V[1..$]);
}

into an iterative definition?


Why? To avoid slowing down compilation with all those template 
instantiations?


How about a O(log2(N)) depth recursive version, something like 
this:


template allSame(V ...)
if (isExpressions!V)
{
static if (V.length <= 1)
enum allSame = true;
else static if(V.length & 1)
enum allSame = V[$-1] == V[0]
&& V[0 .. $/2] == V[$/2 .. $-1]
&& allSame!(V[0 .. $/2]);
else
enum allSame = V[0..$/2] == V[$/2 .. $]
&& allSame!(V[0 .. $/2]);
}


Although you should consider that isExpressions is instantiating 
V.length templates anyway (it uses a binary split to avoid 
excessive template recursion depth, but it ends up checking them 
all one-per-template in the end anyway.

Re: Improving assert-printing in DMD

[Jonathan M Davis via Digitalmars-d]

On Friday, 2 October 2015 at 09:32:23 UTC, Atila Neves wrote:

On Thursday, 1 October 2015 at 17:19:39 UTC, Per Nordlöw wrote:
On Thursday, 1 October 2015 at 14:37:55 UTC, Andrei 
Alexandrescu wrote:
Whoever wants to work on better assert expression printing: 
make sure you specify which grammar constructs are supported, 
and how the parts involved are printed. Expressing semantics 
via lowering would be great. Write a DIP, discuss, implement. 
I'll have your six.



Andrei


A first version:

http://wiki.dlang.org/DIP83


I like the idea, I just have a practical question on 
std.experimental.testing: should it go ahead as-is? Should the 
custom assertions be removed and the rest kept? Should they go 
in as-is and then deleted when/if this DIP is implemented?


If we're going to be improving the built-in assertions, then I 
don't think that it makes sense to add custom assertions to 
Phobos, and I definitely don't like the idea of adding them with 
the idea that we'll just be deprecating them later. If it turns 
out that that isn't going work (Walter rejected it the last time 
it was done, but maybe that will go differently this time - 
particularly since Andrei is very much in favor of it), then we 
can add the custom assertions later.


Personally, I think that the parts of this module which really 
matter are the unittest names (though I still wish that we'd just 
put that in the language itself - particularly since each 
unittest block already has a corresponding function that's named 
after where it is and it really shouldn't be a big deal to just 
allow the user to provide a name to use instead) and the parts 
about parallelizing unittest blocks. Even if we don't end up with 
improvements to the built-in assertions, the custom assertions 
are just gravy that makes it so that you're less like to have to 
go change your unit tests to print more info when they fail. So, 
I don't think that it's a big deal if they get delayed while we 
wait and see if we can get the built-in assertions improved, and 
if the built-in assertions do get improved, then we'll never need 
the custom ones anyway.


- Jonathan M Davis

Re: How to do unittests

[Namal via Digitalmars-d-learn]

On Wednesday, 30 September 2015 at 14:44:20 UTC, qsdf wrote:

On Wednesday, 30 September 2015 at 14:20:28 UTC, Namal wrote:
On Wednesday, 30 September 2015 at 13:03:52 UTC, Rikki 
Cattermole wrote:

On 01/10/15 1:59 AM, Namal wrote:

Hello,

can someone give me a complete example please how to do 
unittests? I
tried this with the example from german wikipedia, but the 
flag

-unittest didn't make any difference.


Example file with loads of unittests: 
https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/uri.d


If you were to compile it e.g. dmd uri.d it won't be much use 
(unittest wise). You will need to dmd -unittest uri.d to 
compile them in. Don't forget to do the same for your main 
function. When you run the final executable the tests will 
execute before your main function does.


can't I do unittest in the main?


D unit tests are like a stack of free functions. You put them 
separatly.



when there's a main: dmd -unittest a.d
--
module a;
void main(){}

unittest{}
--


when there is no main: (like std.uri): dmd -main -unittest a.d
--
module a;
unittest{}
--

the -main switch adds a dummy main function so that the output 
can be executed.


But most of the time you'll think that nothing happens because 
the tests succeed...


So do I understand it right that it stops after the first failed 
test? Is it possible to continue and get a list of all failed 
tests?

Re: Checking that a template parameter is an enum

[John Colvin via Digitalmars-d-learn]

On Thursday, 1 October 2015 at 22:26:39 UTC, Nordlöw wrote:

On Thursday, 1 October 2015 at 02:06:48 UTC, Fusxfaranto wrote:

/** Returns: true iff all values $(D V) are the same. */
template allSame(V...)  // TODO restrict to values 
only

{
static if (V.length <= 1)
enum bool allSame = true;
else
enum bool allSame = V[0] == V[1] && allSame!(V[1..$]);
}


std.traits to the rescue!

http://dlang.org/phobos/std_traits.html#isExpressions

Using isExpressions!V as a template constraint looks like the 
behavior you're looking for.


Thanks!

BTW: Is there some way to turn the recursive definition of 
`allSame`


template allSame(V...)
if (isExpressions!(V))
{
static if (V.length <= 1)
enum allSame = true;
else
enum allSame = V[0] == V[1] && allSame!(V[1..$]);
}

into an iterative definition?


Why? To avoid slowing down compilation with all those template 
instantiations?


How about a O(log2(N)) depth recursive version, something like 
this:


template allSame(V ...)
if (isExpressions!V)
{
static if (V.length <= 1)
enum allSame = true;
else static if(V.length & 1)
enum allSame = V[$-1] == V[0]
&& V[0 .. $/2] == V[$/2 .. $-1]
&& allSame!(V[0 .. $/2]);
else
enum allSame = V[0..$/2] == V[$/2 .. $]
&& allSame!(V[0 .. $/2]);
}

chunkBy limitation?

[Dmitri via Digitalmars-d-learn]

I wondered if this is a current limitation of chunkBy 
implementation:


// http://dpaste.dzfl.pl/52d6a0c5d0ab
void bar(int[] foo)
{
bool less(int a, int b) // contrived
{
return a < b;
};

foo.sort!less.groupBy;
}

resulting in:

/opt/compilers/dmd2/include/std/algorithm/iteration.d(1529): 
Error: function f351.bar.SortedRange!(int[], 
less).SortedRange.groupBy!().groupBy.ChunkByImpl!(__lambda1, 
int[]).ChunkByImpl.Group.popFront cannot access frame of function 
f351.bar.SortedRange!(int[], less).SortedRange.groupBy!().groupBy

...

I can see that the implementation of chunkBy is nested:
struct ChunkByImpl
{
static struct Group {}
}

and that the predicate (less in this case) is accessed from the 
nested struct Group which is, probably, what's causing the 
compilation error.


The question is if this is an implementation error (i.e. Group 
should probably be moved to the top level) or a compiler issue?


Thanks in advance.

Re: Improving assert-printing in DMD

[Atila Neves via Digitalmars-d]

On Friday, 2 October 2015 at 11:22:00 UTC, Andrei Alexandrescu 
wrote:

On 10/02/2015 05:32 AM, Atila Neves wrote:


I like the idea, I just have a practical question on
std.experimental.testing: should it go ahead as-is? Should the 
custom
assertions be removed and the rest kept? Should they go in 
as-is and

then deleted when/if this DIP is implemented?


As long as it's in experimental, proceed as you find fit. We 
can decide later whether changes are in order. -- Andrei


That's what I was hoping for. Good, unless anybody has comments 
to make on the current state of the PR, I'll leave everything as 
it is now.


Atila

Re: Improving assert-printing in DMD

[Per Nordlöw via Digitalmars-d]

On Friday, 2 October 2015 at 12:15:13 UTC, Per Nordlöw wrote:
I guess we only need on symbol name for `onAssertFailed` then 
instead of `assertBinOp` and `assertUnOp`, right?


And two overloads

Binary case:

onAssertFailed(string op)(e1, e2, __FILE__, ...)

Unary case:

onAssertFailed(string op)(e, __FILE__, ...)

I presume?

Because number of arguments to each overload will be fixed, right?

What about the case

assert(f(expr))
assert(symbol)

Should `op` be empty in that casesor should we use yet another 
overload


onAssertFailed(e, __FILE__, ...)

for that case?

Re: Improving assert-printing in DMD

[Per Nordlöw via Digitalmars-d]

On Friday, 2 October 2015 at 11:54:31 UTC, Atila Neves wrote:
That's what I was hoping for. Good, unless anybody has comments 
to make on the current state of the PR, I'll leave everything 
as it is now.


Fine with me :)

Re: Walter and I talk about D in Romania

[Dicebot via Digitalmars-d-announce]

If only this was mentioned at least few weeks earlier I'd try to 
attend :(

Re: Walter and I talk about D in Romania

[Per Nordlöw via Digitalmars-d-announce]

On Friday, 2 October 2015 at 11:25:44 UTC, Andrei Alexandrescu 
wrote:
Walter and I will travel to Brasov, Romania to hold an 
evening-long event on the D language. There's been strong 
interest in the event with over 300 registrants so far.


Great!

Will there be video recordings?

Re: 1st Ever Artificial Consciousness to be Written in D Language

[burjui via Digitalmars-d-announce]

On Wednesday, 30 September 2015 at 06:55:47 UTC, Grand_Axe wrote:
I am slightly behind schedule with the coding. The main logic 
is only getting completed today.


The system should be ready for first looks by the 9th of 
October.


Surprise, dlang hacker! :)
Let me guess: you'll spend all October and most likely much more 
time debugging your AI and the result will be far from what you 
promised, assuming you're just too naive and confident, and not 
trying to bullshit us. I'll be the first to apologize if you'll 
*ever* reach your declared goals, let alone 9th October.

Meh

[Issue 15132] std.algorithm.sort crash on windows

[via Digitalmars-d-bugs]

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

--- Comment #3 from mzfh...@foxmail.com ---
(In reply to Steven Schveighoffer from comment #1)
> 1. You are not calling std.algorithm.sort, you are calling builtin array
> sort. You need to add the parentheses.
> 
> 2. I don't know that we need to concern ourselves with invalid opCmp

yes,i call the builtin array sort...
my actual opCmp code is quite complicated,i check the code a long time
and find there are different results on different platforms.

--

Re: Interval Arithmetic

[ponce via Digitalmars-d-learn]

On Thursday, 1 October 2015 at 21:13:30 UTC, Marco Leise wrote:


Nice to have in Phobos. I assume you have to set the correct 
control word depending on whether you perform math on the FPU 
or via SSE (as is standard for x86_64)? And I assume further 
that DMD always uses FPU math and other compilers provide flags 
to switch between FPU and SSE?


I don't know which compiler use which. On x86_64, a compiler is 
in practice free to mix-and-match FPU and SSE, the instructions 
are still there and working.

Re: Improving assert-printing in DMD

[Jacob Carlborg via Digitalmars-d]

On 2015-10-02 08:31, Per Nordlöw wrote:


Could explain what you mean by *lowering*, please?


"lowering" means that a feature is implemented using another feature. 
For example, "foreach" is lowered to a for-loop:


foreach(i ; 0 .. 10){}

Is lowered to:

for (int i = 0; i < 10; i++) {}

The compiler rewrites the AST of the foreach-loop to the same AST that 
the corresponding for-loop would have. After that lowering step, the 
compiler doesn't need to know anything about foreach-loops.


--
/Jacob Carlborg

Re: Walter and I talk about D in Romania

[Rikki Cattermole via Digitalmars-d-announce]

On 03/10/15 12:25 AM, Andrei Alexandrescu wrote:

Walter and I will travel to Brasov, Romania to hold an evening-long
event on the D language. There's been strong interest in the event with
over 300 registrants so far.

http://curiousminds.ro

Scott Meyers will guest star in a panel following the talks. We're all
looking forward to it!


Andrei


Awesome! Keep us updated on how it goes. Via e.g. twitter.

Linker error with dmd

[Chris via Digitalmars-d-learn]

Why do I get this error msg with dmd 2.067.1 and 2.068.0 in 
release mode:


$ dub --build=release

(.data._D65TypeInfo_xC3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ+0x10):
 undefined reference to 
`_D64TypeInfo_C3std5range10interfaces18__T10InputRangeTiZ10InputRange6__initZ'
collect2: error: ld returned 1 exit status
--- errorlevel 1
dmd failed with exit code 1.

It works fine with the latest version of ldc2.

Re: How to do unittests

[Atila Neves via Digitalmars-d-learn]

On Friday, 2 October 2015 at 10:22:40 UTC, Namal wrote:

On Wednesday, 30 September 2015 at 14:44:20 UTC, qsdf wrote:

On Wednesday, 30 September 2015 at 14:20:28 UTC, Namal wrote:

[...]


D unit tests are like a stack of free functions. You put them 
separatly.



when there's a main: dmd -unittest a.d
--
module a;
void main(){}

unittest{}
--


when there is no main: (like std.uri): dmd -main -unittest a.d
--
module a;
unittest{}
--

the -main switch adds a dummy main function so that the output 
can be executed.


But most of the time you'll think that nothing happens because 
the tests succeed...


So do I understand it right that it stops after the first 
failed test? Is it possible to continue and get a list of all 
failed tests?


http://code.dlang.org/packages/unit-threaded
https://github.com/D-Programming-Language/phobos/pull/3207

Atila

Re: Is Anything Holding you back?

[Kagamin via Digitalmars-d]

On Friday, 2 October 2015 at 08:23:56 UTC, Sönke Ludwig wrote:

http://code.dlang.org/?sort=name=library.database


Unfortunately not everybody is using sqlite and postgresql.

Re: Is Anything Holding you back?

[ponce via Digitalmars-d]

On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
Are there any critical frameworks or libraries that are holding 
you back in fully investing in D? Obviously I think D is an 
awesome language, but some frameworks/libraries hold me back, 
wish I could do everything in D.


I'd say kickass codegen from DMD but it seems it's getting 
improvements.


Nothing held me back :) Now writing D full-time.

Re: Improving assert-printing in DMD

[Jacob Carlborg via Digitalmars-d]

On 2015-10-02 11:32, Atila Neves wrote:


I like the idea, I just have a practical question on
std.experimental.testing: should it go ahead as-is?


Yes, as-is. That's the whole point of std.experimental.

--
/Jacob Carlborg

problem with exceptions

[steven kladitis via Digitalmars-d-learn]

C:\d\examples>pb2
=>main's first line
  =>makeOmelet's first line
=>prepareAll's first line
  =>prepareEggs's first line
object.Exception@pb2.d(64): Cannot take -8 eggs from the fridge

0x00402252
0x0040512F
0x00405043
0x00403E48
0x7600338A in BaseThreadInitThunk
0x77A497F2 in RtlInitializeExceptionChain
0x77A497C5 in RtlInitializeExceptionChain


- I always see the info at the bottom. Is this normal. I was 
thinkig I should only the the exception message itself.

---  this is windows 7 32 bit.

Re: problem with exceptions

[Dmitri via Digitalmars-d-learn]

On Friday, 2 October 2015 at 11:44:21 UTC, steven kladitis wrote:

C:\d\examples>pb2
=>main's first line
  =>makeOmelet's first line
=>prepareAll's first line
  =>prepareEggs's first line
object.Exception@pb2.d(64): Cannot take -8 eggs from the fridge

0x00402252
0x0040512F
0x00405043
0x00403E48
0x7600338A in BaseThreadInitThunk
0x77A497F2 in RtlInitializeExceptionChain
0x77A497C5 in RtlInitializeExceptionChain


- I always see the info at the bottom. Is this normal. I 
was thinkig I should only the the exception message itself.

---  this is windows 7 32 bit.


that would the stack of the thread leading up to the exception. I 
think you get that if you dump the exception object itself (not 
just the message).

Re: Improving assert-printing in DMD

[Per Nordlöw via Digitalmars-d]

On Friday, 2 October 2015 at 11:19:51 UTC, Andrei Alexandrescu 
wrote:

assert(e1 == e2)

could be lowered into:

{
  auto a = e1, b = e2;
  if (a == b) return;
  onAssertFailed!"=="(a, b, __FILE__, __LINE__, __FUNCTION__, 
__MODULE__);

}()


So lowering is kind of like macro expansion for AST-nodes, then?

Is DMD clever enough to avoid trigger postblits for


  auto a = e1, b = e2;
  if (a == b) return;


? Or is that part of the question whether this will work?

I guess we only need on symbol name for `onAssertFailed` then 
instead of `assertBinOp` and `assertUnOp`, right?

Re: Is Anything Holding you back?

[Kagamin via Digitalmars-d]

On Friday, 2 October 2015 at 08:03:03 UTC, Dmitry Olshansky wrote:

On 02-Oct-2015 10:49, Kagamin wrote:

On Friday, 2 October 2015 at 05:15:26 UTC, luminousone wrote:

vibe.d compatible sqlite, postgresql, and oracle sql drivers.


An ODBC driver would be fine too, anything that can connect to 
a database.


http://dlang.org/phobos/etc_c_odbc_sql.html


http://wiki.dlang.org/Libraries_and_Frameworks#Databases

Re: How to break gdb on D exception ?

[Dmitri via Digitalmars-d-learn]

On Friday, 2 October 2015 at 04:50:59 UTC, BBasile wrote:

On Friday, 2 October 2015 at 04:46:51 UTC, BBasile wrote:

On Friday, 2 October 2015 at 04:24:11 UTC, Adam D. Ruppe wrote:

On Friday, 2 October 2015 at 03:58:45 UTC, BBasile wrote:

none of the following GB commands work:


give

break d_throw

or maybe `break d_throwc` a try


unfortunately it doesn't work, i get

---
(gdb) Function "d_throw"/"d_throwc" not defined.


it was almost that actually,
'break _d_throwc


Or you could break on a specific exception class's constructor.

Re: Is Anything Holding you back?

[Atila Neves via Digitalmars-d]

On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
Are there any critical frameworks or libraries that are holding 
you back in fully investing in D? Obviously I think D is an 
awesome language, but some frameworks/libraries hold me back, 
wish I could do everything in D.


Sadly, the preprocessor, and it just happened to me today. In 
C++, I include the header and I'm done. In D, I have to either 
manually duplicate the C declarations or use dstep. I'm more than 
ok with the latter option, but my environment is weird (doesn't 
use the system libc) and dstep didn't work. Doing it manually 
would be so much work that I gave up for this project in 
particular.


Mostly I write everything in D these days though.

Atila

Re: Is Anything Holding you back?

[Márcio Martins via Digitalmars-d]

On Friday, 2 October 2015 at 09:44:00 UTC, ponce wrote:

On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
Are there any critical frameworks or libraries that are 
holding you back in fully investing in D? Obviously I think D 
is an awesome language, but some frameworks/libraries hold me 
back, wish I could do everything in D.


I'd say kickass codegen from DMD but it seems it's getting 
improvements.


Nothing held me back :) Now writing D full-time.


That, and the very poor debugging experience.

Our web company is also 100% D, minus a few javascript and css 
tools that we currently use node.js for.

Re: Improving assert-printing in DMD

[Andrei Alexandrescu via Digitalmars-d]

On 10/02/2015 05:32 AM, Atila Neves wrote:


I like the idea, I just have a practical question on
std.experimental.testing: should it go ahead as-is? Should the custom
assertions be removed and the rest kept? Should they go in as-is and
then deleted when/if this DIP is implemented?


As long as it's in experimental, proceed as you find fit. We can decide 
later whether changes are in order. -- Andrei

Re: Go, D, and the GC

[Tourist via Digitalmars-d]

On Friday, 2 October 2015 at 06:53:56 UTC, Iain Buclaw wrote:
On 1 Oct 2015 11:35 am, "Tourist via Digitalmars-d" < 
digitalmars-d@puremagic.com> wrote:

[...]
good GC. And they keep working on it, e.g. 
https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md

[...]

https://github.com/golang/go/blob/master/LICENSE

[...]
Wouldn't it largely benefit D? I guess that I'm not the first 
one to think about it. Thoughts?


Why do you think Go's GC might be better than D's?  Is it 
because we lack the PR when changes/innovations are done to the 
GC in druntime?  Do you *know* about anything new that has 
changed or improved in D's GC over the last two years?


I'd be interested to hear about this.


I know that it has the reputation of being of the simplest kind. 
Haven't looked at the code actually (and I wouldn't understand 
much even if I did).

Walter and I talk about D in Romania

[Andrei Alexandrescu via Digitalmars-d-announce]

Walter and I will travel to Brasov, Romania to hold an evening-long 
event on the D language. There's been strong interest in the event with 
over 300 registrants so far.


http://curiousminds.ro

Scott Meyers will guest star in a panel following the talks. We're all 
looking forward to it!



Andrei

Re: Compile failing with D 2.068.2 works with 2.068.1

[Meta via Digitalmars-d]

On Friday, 2 October 2015 at 15:04:37 UTC, Meta wrote:

On Thursday, 1 October 2015 at 23:01:59 UTC, Zz wrote:>

I traced it to when JSONValue get is being used.

{
  import stdx.data.json;

  string str = `{"a": true, "b": "test"}`;
  auto v = parseJSONValue(str);

  // The following line causes the problem in 2.068.2
  auto obj = v.get!(JSONValue[string]);
}

Zz


I just tried it with 2.068.2 on my system and get the same 
error. This definitely shouldn't be occurring and is a 
regression from 2.068.1.


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

Re: How to do unittests

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, October 02, 2015 10:22:38 Namal via Digitalmars-d-learn wrote:
> So do I understand it right that it stops after the first failed
> test? Is it possible to continue and get a list of all failed
> tests?

Once a unittest block within a module has a failure in it, then no more
unittest blocks within that module are run. However, unittest blocks in
other modules will still be run. So, if you have failures across multiple
modules, then you'll see multiple failures, but if it's just one module,
then you'll only see the first one, because any further tests within the
module won't even have been run.

- Jonathan M Davis

Re: Improving assert-printing in DMD

[Andrei Alexandrescu via Digitalmars-d]

On 10/02/2015 10:30 AM, Nordlöw wrote:

On Friday, 2 October 2015 at 14:08:06 UTC, Jacob Carlborg wrote:

On 2015-10-02 14:15, Per Nordlöw wrote:


So lowering is kind of like macro expansion for AST-nodes, then?

Is DMD clever enough to avoid trigger postblits for


The compiler just rewrites the AST.


So you mean that no postblits are called and we should go with Andreis
first lowering proposal?


My first proposed lowering creates more copies than needed. My second 
one is therefore probably better, without resorting to compiler magic. 
-- Andrei

Multiple alias this redux

[Andrei Alexandrescu via Digitalmars-d]

Following the approval of his DIP66, Igor Stepanov proceeded with an 
implementation at https://github.com/D-Programming-Language/dmd/pull/3998.


Walter and I objected that the implementation is overly complex. My 
opinion is much weaker than his; I'm not deeply familiar with the dmd 
internals. Iain Buclaw seems to agree with Walter. and Igor has replied 
with additional explanations for the added complexity.


As a result:

* We have no alias this

* The compiler is 2 KLOC smaller/simpler

* The PR has bitrotten

* Igor is probably frustrated

So this is a stalemate that I'd like to see broken. The best solution I 
see with this is a core compiler contributor reviewing Igor's code and 
either:


(a) Assuming Igor is still interested, give concrete, actionable 
guidance to Igor so he can simplify the PR and follow through 
shepherding the PR into dmd;


(b) If Igor is no longer interested, either take over the PR and modify 
it for approval, or implement DIP66 from first principles;


(c) Review the code and discussion, and reach the conclusion the 
proposed implementation is appropriate and no radical simplifications 
are within reach.


Please chime in if you'd like to take this over.


Thanks,

Andrei

Re: Compile failing with D 2.068.2 works with 2.068.1

[Meta via Digitalmars-d]

On Thursday, 1 October 2015 at 23:01:59 UTC, Zz wrote:>

I traced it to when JSONValue get is being used.

{
  import stdx.data.json;

  string str = `{"a": true, "b": "test"}`;
  auto v = parseJSONValue(str);

  // The following line causes the problem in 2.068.2
  auto obj = v.get!(JSONValue[string]);
}

Zz


I just tried it with 2.068.2 on my system and get the same error. 
This definitely shouldn't be occurring and is a regression from 
2.068.1.

[Issue 15137] core.time: Support Duration/Duration and Duration%Duration

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Vladimir Panteleev  ---
https://github.com/D-Programming-Language/druntime/pull/1401

--

Re: Checking that a template parameter is an enum

[Meta via Digitalmars-d-learn]

On Friday, 2 October 2015 at 07:52:22 UTC, Nordlöw wrote:

On Friday, 2 October 2015 at 02:39:56 UTC, Meta wrote:
Highly doubtful as CTFE already allocates like there's no 
tomorrow.


Could that memory usage be tested somehow?


Your favourite process monitor I guess.

Re: Walter and I talk about D in Romania

[Jonathan M Davis via Digitalmars-d-announce]

On Friday, October 02, 2015 07:25:44 Andrei Alexandrescu via 
Digitalmars-d-announce wrote:
> Walter and I will travel to Brasov, Romania to hold an evening-long
> event on the D language. There's been strong interest in the event with
> over 300 registrants so far.
>
> http://curiousminds.ro
>
> Scott Meyers will guest star in a panel following the talks. We're all
> looking forward to it!

Wow. That's a lot of people.

- Jonathan M Davis

[Issue 15137] New: core.time: Support Duration/Duration and Duration%Duration

[via Digitalmars-d-bugs]

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

  Issue ID: 15137
   Summary: core.time: Support Duration/Duration and
Duration%Duration
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: thecybersha...@gmail.com
CC: issues.dl...@jmdavisprog.com

Currently porting some D1 code to D2, and some of the D1 code is quite annoying
as rewritten to use core.time.

Example 1:

auto units = [
"days" : TicksPerDay,
"hours" : TicksPerHour,
"seconds" : TicksPerSecond,
];
d_time d = 1234567890;
foreach (name, duration; units)
writefln("%d %s", d/duration, name);

Converting between time units when you don't know the unit during compilation
using core.time is excessively verbose - you have to use something like:
duration.total!"hnsecs" / unit.total!"hnsecs". This is also leaking a low-level
detail (that Duration is internally represented as hnsecs).

Example 2:

fiveMinuteTotals[delta % TicksPerDay / (5*TicksPerMinute)]++;

This calculates collective frequency when during the day events occur, with
five-minute granularity. With core.time, this becomes something like...

fiveMinuteTotals[delta.split!("days", "hnsecs").hnsecs /
5.minutes.total!"hnsecs"]++;

I really don't see any reason why Duration should not support binary / and %
with two Durations.

--

Re: problem with exceptions

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, October 02, 2015 11:44:19 steven kladitis via Digitalmars-d-learn 
wrote:
> C:\d\examples>pb2
> =>main's first line
>=>makeOmelet's first line
>  =>prepareAll's first line
>=>prepareEggs's first line
> object.Exception@pb2.d(64): Cannot take -8 eggs from the fridge
> 
> 0x00402252
> 0x0040512F
> 0x00405043
> 0x00403E48
> 0x7600338A in BaseThreadInitThunk
> 0x77A497F2 in RtlInitializeExceptionChain
> 0x77A497C5 in RtlInitializeExceptionChain
>
>
> - I always see the info at the bottom. Is this normal. I was
> thinkig I should only the the exception message itself.
> ---  this is windows 7 32 bit.

If you don't want to see a stack trace, then catch the exception and just
print its msg property. And if you want the file and line number in addition
to the message, then you can access those file the exception's file and line
properties. But the toString function on exceptions is always going to print
out the stack trace in addition to the message, which usually pretty useful,
though in this case, you didn't get the function names as part of the stack
trace, which is less useful. You probably need to build with the debug info
turned on to get it.

- Jonathan M Davis

[Issue 15138] New: ICE with basic use of stdx.data.json

[via Digitalmars-d-bugs]

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

  Issue ID: 15138
   Summary: ICE with basic use of stdx.data.json
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: monkeywork...@hotmail.com

The following code:

import stdx.data.json;

void main()
{
  string str = `{"a": true, "b": "test"}`;
  auto v = parseJSONValue(str);

  // The following line causes the problem in 2.068.2
  auto obj = v.get!(JSONValue[string]);
}


Fails to compile with the following error:

Assertion failure: 'minst->isRoot() || minst->rootImports()' on line 8013 in
file 'template.c'


stdx.data.json can be found here: 

https://github.com/s-ludwig/std_data_json

--

[Issue 15138] ICE with basic use of stdx.data.json

[via Digitalmars-d-bugs]

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

--- Comment #1 from monkeywork...@hotmail.com ---
This is using DMD 2.068.2. The code reportedly works with 2.068.1.

--

Re: Walter and I talk about D in Romania

[Radu via Digitalmars-d-announce]

On Friday, 2 October 2015 at 11:25:44 UTC, Andrei Alexandrescu 
wrote:
Walter and I will travel to Brasov, Romania to hold an 
evening-long event on the D language. There's been strong 
interest in the event with over 300 registrants so far.


http://curiousminds.ro

Scott Meyers will guest star in a panel following the talks. 
We're all looking forward to it!



Andrei


Awesome! To bad I will not be in Romania at the time, I bet will 
be a great event.


Mult succes!

Re: Shout out to D at cppcon, when talkign about ranges.

[Eric Niebler via Digitalmars-d]

On Thursday, 1 October 2015 at 21:03:16 UTC, Walter Bright wrote:
I don't see evidence that C++ had ranges before D. Boost ranges 
are not what we think of as ranges.


Why not?

Re: Pathing in the D ecosystem is generally broken (at least on windows)

[Nick Sabalausky via Digitalmars-d]

On 09/30/2015 06:34 AM, Walter Bright wrote:

On 9/29/2015 11:03 PM, Dmitry Olshansky wrote:

When that happens to me I use Abbyy FineReader to OCR the screenshot,
there is
even a special screenshot reader app. Sometimes it's a lifesaver.


I use a flamethrower to light cigarettes, too!



Best comeback ever. :)

[Issue 15132] std.algorithm.sort crash on windows

[via Digitalmars-d-bugs]

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

--- Comment #4 from Steven Schveighoffer  ---
(In reply to mzf from comment #3)
> yes,i call the builtin array sort...
> my actual opCmp code is quite complicated,i check the code a long time
> and find there are different results on different platforms.

Any chance you can try the std.algorithm.sort? It may have more useful error
(or more consistent behavior at least).

Also, can you narrow down the code to a minimal example that causes the
undesired behavior?

It's possible there is an issue with the builtin sort. But sort really does
require that items it has already sorted are sorted. I'm not sure what steps it
assumes are correct.

An access violation doesn't seem like it should happen, but it's possibly due
to an optimization that is invalid with an invalid opCmp.

--

Re: Pathing in the D ecosystem is generally broken (at least on windows)

[Nick Sabalausky via Digitalmars-d]

On 09/29/2015 10:27 PM, Walter Bright wrote:


Microsoft should:
1. fix it so it is the default behavior.
2. list it in their guidelines for how dialog boxes should work.



There's a LOT of things Microsoft really should do. Even having been a 
Win guy for a long, long time, I've long since given up on MS ever doing 
nearly any of the things they really should. (Not to specifically single 
MS out, lot of other companies/groups are much the same.)

Re: Is Anything Holding you back?

[deadalnix via Digitalmars-d]

On Friday, 2 October 2015 at 12:54:30 UTC, Jack Stouffer wrote:

On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
Are there any critical frameworks or libraries that are 
holding you back in fully investing in D? Obviously I think D 
is an awesome language, but some frameworks/libraries hold me 
back, wish I could do everything in D.


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

This is honestly embarrassing for me when ever I mention D to 
someone.


This, and debug support in general. I have no idea how to get 
line number for stack traces on OSX, let alone run GDB or LLDB, 
but even on linux where the support is better, I need to use a 
specific set of linker flag + use command lines tools to get line 
number from stack traces.

Re: Is Anything Holding you back?

[luminousone via Digitalmars-d]

On Friday, 2 October 2015 at 08:23:56 UTC, Sönke Ludwig wrote:

Am 02.10.2015 um 10:15 schrieb Kagamin:
On Friday, 2 October 2015 at 08:03:03 UTC, Dmitry Olshansky 
wrote:

On 02-Oct-2015 10:49, Kagamin wrote:

On Friday, 2 October 2015 at 05:15:26 UTC, luminousone wrote:
vibe.d compatible sqlite, postgresql, and oracle sql 
drivers.


An ODBC driver would be fine too, anything that can connect 
to a

database.


http://dlang.org/phobos/etc_c_odbc_sql.html


http://wiki.dlang.org/Libraries_and_Frameworks#Databases


http://code.dlang.org/?sort=name=library.database


Looks like an async postgresql driver is in their, but i don't 
see sqlite supported in this fashion yet. I would love to use 
vibe.d(we currently use java/tomcat with spring framework) in 
some of the projects at work, but most of this would require 
connecting to an oracle server, I will re-examine the pgsql 
situation.


We have several projects coming up where we will get a dataset 
from the Utah department of environmental quality and we will 
build a small website around it for the public to query and look 
at the data in a user friendly fashion. Assuming pgsql support is 
up to snuff, I can get away with using vibe.d. And I believe 
anyway that I could finish the project faster with vibe.d then 
java/tomcat/spring.

Re: chunkBy limitation?

[Ali Çehreli via Digitalmars-d-learn]

On 10/02/2015 02:21 AM, Dmitri wrote:
> I wondered if this is a current limitation of chunkBy implementation:
>
> // http://dpaste.dzfl.pl/52d6a0c5d0ab
> void bar(int[] foo)
> {
>  bool less(int a, int b) // contrived
>  {
>  return a < b;
>  };
>
>  foo.sort!less.groupBy;
> }
>
> resulting in:
>
> /opt/compilers/dmd2/include/std/algorithm/iteration.d(1529): Error:
> function f351.bar.SortedRange!(int[],
> less).SortedRange.groupBy!().groupBy.ChunkByImpl!(__lambda1,
> int[]).ChunkByImpl.Group.popFront cannot access frame of function
> f351.bar.SortedRange!(int[], less).SortedRange.groupBy!().groupBy
> ...
>
> I can see that the implementation of chunkBy is nested:
> struct ChunkByImpl
> {
>  static struct Group {}
> }
>
> and that the predicate (less in this case) is accessed from the nested
> struct Group which is, probably, what's causing the compilation error.
>
> The question is if this is an implementation error (i.e. Group should
> probably be moved to the top level) or a compiler issue?
>
> Thanks in advance.

This is a known D issue. Currently, objects have a single context 
pointer. Here is a bug discussion about it:


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

A workaround for your example is making less() static, which removes its 
context pointer:


void bar(int[] foo)
{
import std.algorithm : sort;

static bool less(int a, int b) // contrived
{
return a < b;
}

foo.sort!less.groupBy;
}

void main() {}

I've just realized that I don't know how to handle the case where less() 
really needs some other state (e.g. it may need to use a local variable 
in main). What can we do?


Ali

Re: Is Anything Holding you back?

[Wyatt via Digitalmars-d]

On Friday, 2 October 2015 at 17:17:07 UTC, Jonathan M Davis wrote:


Now, using D at work is another thing entirely, but that has 
more to do with there being existing codebases and it being 
very difficult to talk coworkers into using a new language or 
technology than there necessarily being any technical issues.


Same boat here, only with the added pain that most of our current 
stuff is a terrifying tower of Java trash.  I'm not even sure 
what could be done to ease this situation.


-Wyatt

Re: Looking for someone that could work on 32 bits support for SDC

[deadalnix via Digitalmars-d]

On Friday, 2 October 2015 at 03:40:39 UTC, rsw0x wrote:

On Thursday, 1 October 2015 at 18:12:50 UTC, deadalnix wrote:
Right now, I'm focusing on the GC. This may not seem like the 
priority #1, but that's pretty much he approach that I've 
taken with SDC so far: tackle difficult problem first, as 
these are the one more likely to impact the overall design of 
the thing.


I contacted you on twitter about D's GC design a month or two 
ago - if you would like to collaborate on this feel free to 
send me a tweet @rsw0x

Bye.


Well at this stage, the plan is pretty much down. At this stage, 
GC allocation, explicit free and collection for thread local 
heap. The next big step is to have some heuristic to trigger the 
collection when appropriate.

Re: Is Anything Holding you back?

[Jan Johansson via Digitalmars-d]

On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
Are there any critical frameworks or libraries that are holding 
you back in fully investing in D? Obviously I think D is an 
awesome language, but some frameworks/libraries hold me back, 
wish I could do everything in D.


I want a really good communication stack, doing SOAP (no - I 
don't want the dry old 'JSON' is best, 'SOAP' is bad argument - I 
got enough reasons to use SOAP in many solutions) and the one 
really good stack I've seen so far on SOAP is WCF.


It would be a dream to be able to define service contracts and 
data contracts in a smooth and slick way in D, but maybe it's too 
heavy. It took MS about 5 years to create.

Re: Is Anything Holding you back?

[Jonathan M Davis via Digitalmars-d]

On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
Are there any critical frameworks or libraries that are holding 
you back in fully investing in D? Obviously I think D is an 
awesome language, but some frameworks/libraries hold me back, 
wish I could do everything in D.


Nothing is holding me back from using D on my personal projects. 
At this point, all of them are in D. The primary thing that I'm 
lacking is time to work on them.


Now, using D at work is another thing entirely, but that has more 
to do with there being existing codebases and it being very 
difficult to talk coworkers into using a new language or 
technology than there necessarily being any technical issues.


Sure, there are some things that would be easier to do if they 
were written in D or if we had better wrappers for existing C++ 
stuff (e.g. it would be great to be able to fully use Qt from D), 
but because it's trivial to call C functions, and even 
interacting with C++ is possible on some level, it's not really a 
blocker when something isn't in D - just annoying.


- Jonathan M Davis

Re: Is Anything Holding you back?

[deadalnix via Digitalmars-d]

On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
Are there any critical frameworks or libraries that are holding 
you back in fully investing in D? Obviously I think D is an 
awesome language, but some frameworks/libraries hold me back, 
wish I could do everything in D.


1/ Debug support. It is truly bad. Does not work on OSX as far as 
I know how, and works tediously on linux (line numbers are often 
wrong in GDB and do not appear ins tack trace, need to use 
specific linkers flags for this to work at all).


2/ Null reference types. Seriously. Everything is null by 
default, you get an error where the pointer is used, not where 
the problem is (and these 2 points can be fairly remote) and, 
associated with 1) , hard to track. 99% of the time, the thing is 
null due to a stupid mistake and the compiler could have catched 
it.


3/ Templates error messages. Especially when you pass closures as 
alias and the compiler decide to dump them with fucked up 
indentation all in the middle of the error message. Probably good 
for these that enjoy Klingon opera, but my taste differs.


4/ There used to be a fair amount of codegen bugs in closures, 
but these seems mostly fixed at this stage. However, there is 
still a lot of weirdness going on with them. Symbol in enclosing 
scope will be resolved, but not alias this for instance. 
Sometime, the closure will refuse to capture something for 
unknown reasons and one need to rely on ugly hacks.


5/ mixins are not hygienic. It is often not possible to get the 
symbols you are interested in at the site where they are going to 
be resolved. For instance (toy example, but I have various real 
world example of this in my code) :


module a;

struct S {}

import b;
MixinFail!S mf;

module b;

struct MixinFail(T) {
mixin(T.stringof ~ " t;");
}

This limitation, forces me jump through all kind of hoops, or 
make various part of phobos unusable at even moderate scale (the 
problem in already big in SDC, which is a bit more than 40 kLOC 
at this stage).


6/ This is not a specific problem, but the general attitude that 
consist in taking care of details without looking at the big 
picture. Or to quote a coworker about "One will take great care 
in a bakery to put presents cackes and sweets nicely, sell them 
in a pretty box to customers, but do not care that there is a 
dogshit on the pavement at the entrance".


The recent assert message thread is a good example of that. 6 
pages in 2 days about how to best analyze the expression in the 
assert to get a better error messages (the nice box), when we 
don't even have line number in the trace that lead to this assert 
(the dogshit).

Re: Is Anything Holding you back?

[Timon Gehr via Digitalmars-d]

On 10/02/2015 03:24 PM, Andrei Alexandrescu wrote:

On 10/02/2015 09:11 AM, Dmitry Olshansky wrote:

On 02-Oct-2015 05:25, Yaser wrote:

Are there any critical frameworks or libraries that are holding you back
in fully investing in D? Obviously I think D is an awesome language, but
some frameworks/libraries hold me back, wish I could do everything in D.


My personal favorite (8+ years old OMG):
https://issues.dlang.org/show_bug.cgi?id=1238

Makes me want to laugh every time we discuss "problems" of D. Bugs are
as usual at the top of problems in my book.


I agree it's a hole in the module system, but it's not quite something
that prevents work from being done.


It slows it down. The most annoying part of it is that it introduces 
clashes with private aliases introduced for disambiguation. I.e., the 
mechanism that most conveniently deals with ambiguous symbols is 
basically defunct because of spurious ambiguous symbol errors.

Re: Checking that a template parameter is an enum

[Meta via Digitalmars-d-learn]

On Friday, 2 October 2015 at 18:52:22 UTC, Nordlöw wrote:

On Friday, 2 October 2015 at 16:21:22 UTC, Meta wrote:

Could that memory usage be tested somehow?


Your favourite process monitor I guess.


Any suggestions on an evil D snippet that stress tests 
different implementations of the above mentioned traits?


I don't know off the top of my head, but I remember somebody on 
these forums mentioning a certain CTFE program that caused DMD to 
take up over 100GB in RAM before the process was killed.