Re: dmd -betterC

[ketmar via Digitalmars-d]

Kagamin wrote:


On Wednesday, 21 June 2017 at 06:21:37 UTC, ketmar wrote:

but refusing to generate such strings for *all* code


They are not useful enough for that, in 99% of cases location of assert 
is enough to know what's wrong, when it isn't, the string is not going to 
tell where it went wrong, so you need to debug it, in which case there's 
no difference again.


there, of course, *IS* The difference. besides the aesthetical one (seeing 
failed condition immediately "clicks" in your head, and generic "assertion 
failed" message is only frustrating), there may be the case when source 
code changed since binary was built. here, line number gives you zero 
information, and you have to checkout that exact version, and go check the 
line. but when failed condition dumped, most of the time it allows you to 
see what is wrong even without switching to the old codebase (yes, "most of 
the time" is from RL -- it is literally *most* of the time for me, for 
example).



Don't fluent asserts already do what you want? See 
http://fluentasserts.szabobogdan.com/


nope. those aren't assertions at all, compiler cannot even remove 'em with 
"-release" flag (not that i'm using it much, but still no, thanks).


mind you, assertions is not only for unittesting.

Re: dmd -betterC

[ketmar via Digitalmars-d]

Sebastien Alaiwan wrote:


On Wednesday, 21 June 2017 at 05:35:42 UTC, ketmar wrote:
asserts on embedded systems? O_O code built without -release for 
embedded systems? O_O


embedded system != production system.

You still need to debug the code, and at some point, you have to load it 
on a real microcontroller ; this is where some of your assumptions about 
how the chip works might turn out to be false.


as i said, in "betterc" mode compiler can omit generation of assert 
condition strings.


but refusing to generate such strings for *all* code in favor of embedded 
cases is like "let's remove classes and exceptions from D, 'cause they're 
too costly for embedded code!"

Re: dmd -betterC

[ketmar via Digitalmars-d]

Sebastien Alaiwan wrote:


On Wednesday, 21 June 2017 at 03:57:46 UTC, ketmar wrote:
"bloatsome"? i don't think so. those generated messages is small 
(usually 20-30 bytes), and nothing comparing to druntime/phobos size.


Yeah, but what if you're already working without runtime and phobos?


it doesn't matter, `assert()` is impemented as `throw` anyway. and in 
"betterc" mode compiler can just omit generation of such messages, 
resorting to what it does now.


(some embedded systems only have 32Kb program memory, and yes these are 
up-to-date ones)


asserts on embedded systems? O_O code built without -release for embedded 
systems? O_O

Re: dmd -betterC

[ketmar via Digitalmars-d]

Walter Bright wrote:


On 6/20/2017 3:07 PM, Adam D. Ruppe wrote:

On Tuesday, 20 June 2017 at 20:50:14 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6901
We should generate the default string from the expression for D too. (at 
a minimum, I'd actually like to see every variable printed out too, but 
this is already written)


Those strings eat up space and are of pretty marginal utility. Don't want 
to make assert's so bloatsome that people are discouraged from using them.


nope, they aren't. but they are immediately helpful. i integrated such 
patch to my dmd ages ago, and i'm not speaking out of nothing -- they *are* helful.


and i can't see how *adding* *useful* *info* to assertion will discourage 
people from using 'em.


"bloatsome"? i don't think so. those generated messages is small (usually 
20-30 bytes), and nothing comparing to druntime/phobos size.

Re: Analysis of D GC

[ketmar via Digitalmars-d]

Dmitry Olshansky wrote:

My take on D's GC problem, also spoiler - I'm going to build a new one 
soonish.


http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html


"...the dubious optimization of no interior pointers..."

this is the ONLY (i emphasise it!) way i were able to make my e-mail and 
irc clients to not leak memory, and keep using GC. on 32-bit systems false 
pointers *is* a problem, and NO_INTERIOR really helps.


turning NO_INTERIOR into something dog-slow (or noop) will make D unusable 
on 32-bit systems for anything more complex than helloworld and throwaway 
scripts. particularly, any app that should work for weeks or monthes 
without restart (yep, i want my mail client to Just Work, and i'm not 
rebooting my PC that often) will be *forced* to ditch GC.


while NO_INTERIOR requires some coding discipline, it is invaluable in IRL apps.

Re: Analysis of D GC

[ketmar via Digitalmars-d]

safety0ff wrote:


On Monday, 19 June 2017 at 23:39:54 UTC, H. S. Teoh wrote:
On Mon, Jun 19, 2017 at 10:50:05PM +, Adam D. Ruppe via 
Digitalmars-d wrote:
What is it about Windows that makes you call it a distant possibility? 
Is it just that you are unfamiliar with it or is there some specific OS 
level feature you plan on needing?


AFAIK, Windows does not have equivalent functionality to this.



I've read that there is such a function on Windows but you need to use 
undocumented/unofficial API to access it:


e.g. 
https://github.com/opencollab/scilab/blob/master/scilab/modules/parallel/src/c/forkWindows.c


it is higly depends of undocumented windows internals, and not portable 
between windows versions. more-or-less working implementations of `fork()` 
were existed at least since NT3 era, but nobody considered 'em as more than 
a PoC, and even next service pack can break everything.

Re: Analysis of D GC

[ketmar via Digitalmars-d]

H. S. Teoh wrote:


He mentioned the "fork trick", which I assume refers to how Linux's
implementation of fork() uses copy-on-write rather than immediately
duplicating the parent process' memory structures.  There was a D1 GC
some time ago that depended on this behaviour to speed up the collection
cycle.


and it was even ported to D2, and worked. sadly, using `fork()` has it's 
own set of problems -- `fork()` itself is in no way  a flawless expirience. 
like you can fork while other thread is inside glibc's `malloc()`, and 
BOOM! alot of glibc is locked forever, as `malloc()` lock is never released 
in child process. some other libraries may try to intercept `fork()` to 
do unnecessary "cleanup", and so on.


so using "forking GC" require alot of discipline in coding and library use, 
or it will be an endless source of heisenbugs.


new linux kernels got userfaultfd API (so code can simply `select()` on fd, 
and process protection violation from `mprotect()` without tricks with 
signals), but... to much of my joy and hapiness, the proposed API was just 
fine to create GC with mprotect barriers, and the final API that was 
included gladly omited that exactly necessary API call which allows to make 
it happen. great work, yeah. it may changed since then, tho, i didn't 
rechecked.

Re: Operator Overloading + / ~

[ketmar via Digitalmars-d-learn]

Martin Tschierschke wrote:


Just a thought it might be useful for cut-n-paste when porting code:

Would it be possible to define an operator overloading for '+'-Operator 
for strings to work as append? (like ~).
I understand, that '~' is in general a better choice than '+', so this is 
of more theoretical interest.

It is clear to me, that when I define my own string type this is possible.

Regards mt.


nope. it is not possible to overload operators for built-in types (and 
string is just an aliased array).

Re: core.math.rndtonl: invalid return type or description?

[ketmar via Digitalmars-d]

ag0aep6g wrote:


On 06/19/2017 12:45 PM, ketmar wrote:

ag0aep6g wrote:

[...]
If this is the same function: 
, then it should 
return a C long, which I guess is a D int on 32 bits. And surprise: 
that works.
no, there is `rndtol()` and `rndtonl()` in `core.math`,  they are 
different functions.


The link covers both. See the Prototype and Description sections.


ah, sorry, i should really read linked text instead of guessing from the 
name only. ;-)



also, `rndtol()` should return D `long` (i.e. 64 bit value). at least 
this is what `core.math` says.


Sure, but it doesn't work with D long. It works with D int, which makes 
sense when the function actually returns a C long (assuming that DMC's 
long has 32 bits).


then it is yet another bug in `core.math`...

Re: core.math.rndtonl: invalid return type or description?

[ketmar via Digitalmars-d]

p.s.: it is *important* to use `core.math.rndtonl`! this is compiler 
intrinsic (or at least it should be), and it won't be detected as intrinsic 
outside of `core.math`.

Re: core.math.rndtonl: invalid return type or description?

[ketmar via Digitalmars-d]

ag0aep6g wrote:


On 06/19/2017 10:04 AM, ketmar wrote:

core.math.rndtonl is declared as this:
extern (C) real rndtonl(real x);


Is rndtonl a Digital Mars C thing?


yes, it looks like DMC library function. thus, is should be versioned out 
on non-DMC builds. another bug. ;-)


It has no implementation in druntime, and I get an undefined reference  
when I try to call it on Linux.


It compiles on Windows (wine, -m32), but only ever returns -nan.


If this is the same function: 
, then it should 
return a C long, which I guess is a D int on 32 bits. And surprise: that 
works.


no, there is `rndtol()` and `rndtonl()` in `core.math`,  they are different 
functions.

also, `rndtol()` should return D `long` (i.e. 64 bit value). at least this 
is what `core.math` says.

core.math.rndtonl: invalid return type or description?

[ketmar via Digitalmars-d]

core.math.rndtonl is declared as this:

extern (C) real rndtonl(real x);

yet it's description says: "...If the integer value of x is greater than 
long.max, the result is indeterminate."


it looks like it either should return `long`, or this part of description 
was copypasted from `rndtol`. and if it *really* has such limitation, but 
returns `real`, i think it should be clarified in documentation, 'cause 
right now it is somewhat confusing.

Re: Life in the Fast Lane (@nogc blog post)

[ketmar via Digitalmars-d-announce]

Guillaume Piolat wrote:


On Saturday, 17 June 2017 at 13:05:50 UTC, Adam D. Ruppe wrote:


This is why I consider @nogc to be an *extremely* niche feature and 
generally harmful. It makes things look a lot harder than it really is - 
people confuse `@nogc` with "no gc". Instead, I suggest just minding the 
list and using runtime profiling and debugging to ensure your needs are 
met in actual practice.




As a counterpoint: It's true that it's a bit niche, but when you have "no 
gc" then @nogc really helps with peace of mind (only one allocation and 
you may crash).


yeah, it helps a little... in (let's be honest) rare situations where you 
really want to be *completely* free of any possible gc allocation. in most 
real-life scenarios you're ok with "mostly gc-free, except for exceptional 
cases" (like writeln, for example), and you have no way to express it. i 
end up not using @nogc at all (except on simple `return a` getters), 
despite the fact that many of my code rarely allocates.


there should be a way to say "i don't want gc on this code path, but it is 
ok for this one" (like throwing), without resorting to dirty tricks with 
casting and lambdas. something like `@raregc` ;-).


but then, how we should define "rare"? that attribute will quickly become 
useless, as people will mark arbitrary code with it.


so, `@nogc` is mostly useless IRL (you can't even `enforce` with it), and 
`@raregc` will become useless if introduced. and the sole reason (as i see 
it) of introducing `@nogc` was to please people complaining about gc 
allocations, no matter how often they're done, and on which code path. i 
myself see it as "PR design", which attracts people only to make them find 
that using D with `@nogc` is a PITA, due to `@nogc` being too restrictive.


what `@nogc` *really* does now is dividing codebases into "i will do all 
kind of dirty tricks to avoid GC at all costs, even if it is not really 
necessary", and into "ah, screw it, i don't care". to me, it looks like 
`@nogc` does more bad than good now.

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Moritz Maxeiner wrote:

Is D perfect? No, not by any stretch of the definition, but it is still 
(by far) the least worst choice out there, no matter how good the tooling 
for other languages is or becomes.


exactly my feelings! ;-)

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Wulfklaue wrote:


On Wednesday, 14 June 2017 at 21:20:58 UTC, ketmar wrote:
yeah. D should silently miscompile old code too: it seems that this is 
exactly what people want!


Please point out the people who advocate for D silently miscompiling old 
code... Because i have yet to see anybody in this topic advocate this.


we were talking about broken C code. that was a joke about what C commitee 
did with it's "UB" defintion, and allowing compilers to act as if code never 
ever can have "UB" in it.

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

H. S. Teoh wrote:


On Wed, Jun 14, 2017 at 11:45:43PM +0300, ketmar via Digitalmars-d wrote:

Ola Fosheim Grøstad wrote:


On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:

If a code is to be left untouched but the compiler not archived
then the code must be recompiled and amended as needed with each
new compiler that is accepted in the workflow.

I don't disagree with the general sentiment than one have to evolve
the codebase along with the tooling, but if C, C++, Python and
JavaScript didn't provide backwards compatibility in their
maintained "production lines"

at least C doesn't: almost all old-enough code is broken by various
"UB".


The difference is that unlike D deprecations, the C code will still
compile and appear to work (for the most part, anyway), thus giving
people the illusion that their old code is still "OK".  When actually,
the compiler may have done something unexpected with the UBs and thus
inadvertently introduced security holes.

Of course, none of this matters, since when was the last time bad C code
has caused security problems? :-P


yeah. D should silently miscompile old code too: it seems that this is 
exactly what people want!

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Ola Fosheim Grøstad wrote:


On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
If a code is to be left untouched but the compiler not archived then the 
code must be recompiled and amended as needed with each new compiler 
that is accepted in the workflow.


I don't disagree with the general sentiment than one have to evolve the 
codebase along with the tooling, but if C, C++, Python and JavaScript 
didn't provide backwards compatibility in their maintained "production 
lines"


at least C doesn't: almost all old-enough code is broken by various "UB".

Re: Implementing interfaces using alias this

[ketmar via Digitalmars-d-learn]

Balagopal Komarath wrote:


On Wednesday, 14 June 2017 at 11:40:02 UTC, ketmar wrote:
interfaces *require* a full-featured class, with VMT, and some hidden 
pointers to support hidden interface machinery.


I don't think that is the problem here. The type Test!Duck is a class and 
that type is the one implementing the interface.


*sighs*

Re: Implementing interfaces using alias this

[ketmar via Digitalmars-d-learn]

Mike B Johnson wrote:


I don't think it has to do with pasting code.

d.Quack() is well defined through the alias. Inheritance requires that a 
Quack() exists, and it does, through the alias.


The compiler could easily create an implementation wrapper that uses the 
alias this.


this is called "code pasting".

Re: Implementing interfaces using alias this

[ketmar via Digitalmars-d-learn]

Balagopal Komarath wrote:


On Wednesday, 14 June 2017 at 09:41:49 UTC, ketmar wrote:

Balagopal Komarath wrote:

Why doesn't this work? The Test!Duck type has a void quack() method but 
the compiler says it is not implemented.


'cause `alias this` is *not* a tool that can be used to emulate 
inheritance. no, `quack` is NOT impemented. `alias this` won't 
automagically paste the code.


Thanks for the reply. Is there any reason for disallowing this? AFAIK, 
the alias this guarantees that the interface provided by Test!T is a 
superset of the interface provided by T. And, when T = Duck, T provides 
everything required by IDuck. Couldn't the compiler check while 
instantiating that Test!Duck provides all methods required by IDuck?


besides improper using of `alias this`, there is a technical reason too: 
`struct` is not a `class`, it doesn't have VMT, and other class goodies. as 
i said, `alias this` is not a macro, it doesn't paste code, it just tells 
the compiler to make "symbol redirection" on typechecking. interfaces 
*require* a full-featured class, with VMT, and some hidden pointers to 
support hidden interface machinery.

Re: Implementing interfaces using alias this

[ketmar via Digitalmars-d-learn]

Balagopal Komarath wrote:

Why doesn't this work? The Test!Duck type has a void quack() method but 
the compiler says it is not implemented.


'cause `alias this` is *not* a tool that can be used to emulate 
inheritance. no, `quack` is NOT impemented. `alias this` won't 
automagically paste the code.

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Wulfklaue wrote:


On Tuesday, 13 June 2017 at 20:51:37 UTC, ketmar wrote:

Patrick Schluter wrote:
the main reason for D3 is not language changes, but workarounding "don't 
break user code" thingy. it is completely impossible to experiment 
freely or introduce breaking changes in D2 (for a reason, there is 
nothing bad in it).


Can you actually show us examples of what you think needs to break?


it would be a very long post. ;-) i scratched it a little above, though. my 
private dmd fork has 100+ patches only to dmd itself, for example, and some 
are disruptive enough that alot of my code is marked with `module a is aliced;`.


Frankly one of the reasons why i ended up with D. It has the kitchen and 
sink, has everything from generics, meta programming and beyond. And the 
most import factor, it is STABLE. I am working on a big project that 
needs stability for the next 10+ years. This D3 discussion is 
discouraging to read.


and one of mine reasons was "yay, it is relatively new, unencumbered with 
alot of legacy, and *evolving*!" none of it (our reasoning) is better over 
another. ;-)



D its flaws are the Phobos documentation layout


one of the things i absolutely don't care about, for example. ;-) besides, 
dpldocs rox.



So call me confused as to what is missing and needs such radical changes?


evolving. something very opposite to "stability", as expected by some 
enterprise users. remember, not all D users are enterprise users. ;-) some 
of us (me!) came here 'cause D is fun, not 'cause D is "stable", and we may 
value stability much less than other kinds of users.


Unless i am wrong there seem to be only one or two people actually 
pushing this D3 idea...


as for me, i'm not "pushing" it, i am merely "supporting" it. just to make 
sure that other optinions besides "no, we don't need D3" are not seeing as 
non-existant only due to their bearers being silent. ;-)

Re: Makefile experts, unite!

[ketmar via Digitalmars-d]

Ralph Amissah wrote:

On Sun, Jun 11 2017, Jonathan M Davis via Digitalmars-d 
 wrote:


And where do existing D build systems fit into the picture, I seem to
recall this general discussion around the announcement of "button", which
seems interesting, potentially awesome even:

Button announcement
https://forum.dlang.org/post/uhozcvatvyztfuhiv...@forum.dlang.org


"tracing system calls". a no-no for any general solution. no sane person 
with even rudimentary care for privaly will give *build* *system* 
privileges for injecting .so libraries or trace system calls.


actually, requiring such privileges is my main objection agains any "modern 
automagic build system".

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

crimaniak wrote:


If it depended on me, I would declare an embargo on language changes


that's why we (me, and others like me ;-) need D3. i don't need "better 
phobos", for example ('cause i'm trying to aboid using phobos anyway), but 
i really need named arguments (`foo(a:42, b:"hello")`). i want '=>' to be 
usable for any method/free function, not only for lambdas. i want $-expands 
in mixin strings. warnings on unary minus on byte/short types (do you know 
that D doesn't do int promition in this case, and C does? it bites me 
several times!). i want `foreach_reverse` to be replaced with `foreach 
(auto a; b; reverse)` (and *require* type, modifier or `auto` there). i 
want optional `ref` and `out` marks for function *calls*. i want... i want 
alot of things, i'm not even started yet. especially not started to talk 
about breaking changes. i cannot do that now (i have my private fork of 
dmd), 'cause i need to keep compatibility with vanilla, and i have zero 
hopes to see it all introduced in D2 (language stability, etc.). with D2, 
i'll have a chance to bring 'em on a table.

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Patrick Schluter wrote:

Before even contemplating a big disrupting language split like proposed 
by the OP, wouldn't it first more appropriate to write a nice article, 
DIP, blog, whatever, listing the defects of the current language that can 
not be solved by progressive evolution?
I haven't the impression that the *language* itself suffer from so big 
flaws that it would warrant to fork it in a way that will lead to a lot 
frustration and bewilderment.
D is not perfect, no question, but it is not in a state that would 
jusrify such a harsh approach.


the main reason for D3 is not language changes, but workarounding "don't 
break user code" thingy. it is completely impossible to experiment freely 
or introduce breaking changes in D2 (for a reason, there is nothing bad in it).

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

jmh530 wrote:


Nevertheless, C++ is still a constantly evolving language.


one of the key features of evolution is removing old and rudimentary 
things. without this, it is not evolution, it is mutilation...

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Sebastien Alaiwan wrote:

My point precisely was that "not splitting D1/D2" might correspond to 
"doing things right".


"not splitting" here means "we're stuck with D1". deprecation cycle of 
several years (not counting the time required to actually *start* the 
process) means "no evolution".


i must make myself clear here, i guess: i value "good language" way more 
than "stable language". i absolutely don't mind fixing my code if it makes 
it better/more clear/etc. while it's hard to sell "constantly evolving" 
language to Big Enterprise Wheels, not making breaking changes means 
cloning worst C++ feature. ;-)

Re: Makefile experts, unite!

[ketmar via Digitalmars-d]

Sebastien Alaiwan wrote:


On Monday, 12 June 2017 at 06:38:34 UTC, ketmar wrote:

Sebastien Alaiwan wrote:


The selling points, to me, are:
1) the automatic dependency detection through filesystem hooks
2) recipes also are dependencies
3) the genericity/low-level. I believe build systems should let me 
define my own abstractions, instead of trying to define for me what an 
"executable" or a "static library" should be.


i'm not that all excited by "1", though. tbh, i prefer simplier things, 
like regexp scanning. while regexp scanners may find more dependencies 
than there really are, they doesn't require any dirty tricks to work.


I understand your point ; I was explaining to my colleagues yesterday 
that "1" was a "good step in the wrong direction".

..
However: "1" is still a "good" step. Compared to where we are now, it's 
in theory equivalent to perfectly doing regexp/gcc-MM scanning, in a 
langage agnostic way. It's a net win!


it is still a kludge. and it has a huge chance to stay with us for a very 
long time -- this is what usually happens with kludges. ;-)

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Sebastien Alaiwan wrote:


On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote:

Guillaume Piolat wrote:


On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
I realize that there are people who want to continue using D as it is, 
but those people may continue to use D2.


Well, no thanks.
The very same strategy halved the community for D1/D2 split and almost 
killed D.


as you can see, D is alive and kicking, and nothing disasterous or fatal 
happens.
Yes, but could it have been a lot more alive and kicking, hadn't we shot 
ourselves in the foot with this D1/D2 split?


this question has no answer. can we do better if we will do everything 
right on the first try? of course!

Re: Makefile experts, unite!

[ketmar via Digitalmars-d]

H. S. Teoh wrote:

i'm pretty sure that i *don't* want to know more. ;-)

Re: Weird template instantiation problem

[ketmar via Digitalmars-d-learn]

Arafel wrote:


I actually found a workaround for the original issue:


yeah, sorry for not proposing a workaround: i thought that you already did 
it, and now you're just interested why the original code doesn't work. ;-)


i think that this is a bug (or, rather, unimplemented feature).

Re: Generic operator overloading for immutable types?

[ketmar via Digitalmars-d-learn]

Gary Willoughby wrote:

In the following code is there any way to make the `opBinary` method 
generic to be able to accept immutable as well as a standard type? The 
code currently passes the unit test but I wonder if I could get rid of 
the duplication to overload the operator? I'm failing badly.


public inout(Rational) opBinary(string op)(inout(Rational) rhs) inout {
  static if (op == "+") {
return Rational(0, 0);
  } else {
static assert(0, "Operator '" ~ op ~ "' not implemented");
  }
}

Re: Makefile experts, unite!

[ketmar via Digitalmars-d]

p.s.: btw, k8jam is not a "make wrapper", it is a self-contained build 
system, in one ~100 kb binary. ;-)

Re: Makefile experts, unite!

[ketmar via Digitalmars-d]

H. S. Teoh wrote:


and i really mean it: it was less than a second even for a huge
projects, where linking alone took long enough that i could get coffee
and cigarette.  ;-)

[...]

Your project is not huge enough. :-D


~20MB, >2000 source files. for *this* it was something like 0.5-3 seconds 
(it obviously oscillates). and of course, i'm not talking about full 
rebuilds. this is *all* the time k8jam spent before invoking compiler/linker.


and for pathological 800MB use cases... don't do that. you obviously don't 
need to have thing thing as a one huge project (althru i'm sure that k8jam 
can do it).


k8jam can use timestamps and md5 sums to detect changes (althru i'm usually 
using only timestamps, and had zero problems with it ever), and it can 
optionally cache gathered info.


note that even for small "helloworld" C project, k8jam also checks *all* 
standard libc include files that which brought into the project even by 
simple `#inlcude `! and i never bothered to optimize this, 'cause 
it takes no time anyway.

Re: Weird template instantiation problem

[ketmar via Digitalmars-d-learn]

p.s.: while i understand the technical reason for second error message, it 
is still random and confusing.

Re: Weird template instantiation problem

[ketmar via Digitalmars-d-learn]

more funny compiler messages:

alias xx = size_t function (int[]);
struct S1(T, typeof(xx) X) {}
void main() {
  S1!(int, defaultChooser!int) s;
}

Error: type uint function(int[]) is not an expression

but:

struct S2(T, typeof(defaultChooser!T) chooser=defaultChooser!T) {}
void main() {
  S2!int s;
}

Error: undefined identifier T

error messages are totally random (and why `typeof()` is not allowed there?)

Re: Makefile experts, unite!

[ketmar via Digitalmars-d]

p.s.: like, i've seen one Fallout 2 recreatoin project where they're doing 
translation of screen coords to hex coords not with two simple formulas, 
but by looping over 4 (200x200) hex objects (objects!), and calling 
*virtual* method to ask if a hex contains such coords. and you know what? 
*nobody* noticed any slowdown. 'cause there is none.


it took me ~5 mins to visualise scewed coordinate axes and derive the 
formulas. it took 'em ~30 seconds to write a loop (i guess). and their work 
is actually *better* than mine: they had 4.30 mins free, while i was doing 
useless things.

Re: Makefile experts, unite!

[ketmar via Digitalmars-d]

H. S. Teoh wrote:


Don't forget tup, and others inspired by it, which use modern OS
features to reduce the cost of determining what to build to an O(1)
database lookup rather than an O(n) whole-source tree scan.


added complexity for nothing. disks gradually replacing with ssd, amount of 
RAM allows to cache alot, and CPUs are faster and faster (and has more cores).


i still have HDD, 8GB of RAM, and 32-bit system. and it even worse some 
time ago. in the last ~8 years i was using my k8jam for various projects: 
several kb to multimegabytes of code and thousand files/alot of subdirs. 
source tree scanning and dependency resolving NEVER was any significant 
factor.


and i really mean it: it was less than a second even for a huge projects, 
where linking alone took long enough that i could get coffee and cigarette. ;-)


worse is better. i hate to admit it, but most tricks we're learned over the 
years becomes more and more useless. it doesn't matter if the program will 
do it's work in 0.001 msecs or in 0.0001 msecs: this is not even a 
difference between 10 minutes and 5 minutes anymore.

Re: Makefile experts, unite!

[ketmar via Digitalmars-d]

Sebastien Alaiwan wrote:


On Monday, 12 June 2017 at 06:30:16 UTC, ketmar wrote:

Jonathan M Davis wrote:


It's certainly a pain to edit the makefiles though


and don't forget those Great Copying Lists to copy modules. forgetting 
to include module in one of the lists was happened before, not once or 
twice...


I don't get it, could you please show an example?


ah, nope, not killed. it's just me being blind. look at druntime/mak 
directory, for example. those lists are *required*, and they are maintained 
MANUALLY.

Re: Makefile experts, unite!

[ketmar via Digitalmars-d]

Sebastien Alaiwan wrote:


On Monday, 12 June 2017 at 06:30:16 UTC, ketmar wrote:

Jonathan M Davis wrote:


It's certainly a pain to edit the makefiles though


and don't forget those Great Copying Lists to copy modules. forgetting 
to include module in one of the lists was happened before, not once or 
twice...


I don't get it, could you please show an example?


ah, lol, those lists were killed some time ago, and i failed to notice it. 
silly me. sorry. but they *were* a PITA back then, and memory remains. ;-)

Re: Makefile experts, unite!

[ketmar via Digitalmars-d]

Sebastien Alaiwan wrote:


The selling points, to me, are:
1) the automatic dependency detection through filesystem hooks
2) recipes also are dependencies
3) the genericity/low-level. I believe build systems should let me define 
my own abstractions, instead of trying to define for me what an 
"executable" or a "static library" should be.


i'm not that all excited by "1", though. tbh, i prefer simplier things, 
like regexp scanning. while regexp scanners may find more dependencies than 
there really are, they doesn't require any dirty tricks to work.


i have my own fork of Perforce Jam, and such scanners works surprisingly 
well with it (for years). i even extended it to support D.


one of the great things in Jam is that it can simply call a "rule" (this is 
jam's name for something like function) when it need to get dependencies. 
and i can do regexp scan there, or run arbitrary system command and get 
it's result. also, while my jam comes with a set of predefined rules, there 
is nothing hardcoded, and everything can be redefined. it is also highly 
extensible via special "hook rules", which are empty by default.


the simpliest Jamrule can be as simple as this:

Main myapp : [ Glob src/*.c ] ;

it also correctly processes subdirs (not via recursive invocations), can 
replace "configure" to some extend, and so on. i was using it exclusively 
for years before i completely switched to D (and even after the switch, to 
build projects with GDC).

Re: Makefile experts, unite!

[ketmar via Digitalmars-d]

Jonathan M Davis wrote:


It's certainly a pain to edit the makefiles though


and don't forget those Great Copying Lists to copy modules. forgetting to 
include module in one of the lists was happened before, not once or twice...

Re: Makefile experts, unite!

[ketmar via Digitalmars-d]

Ali Çehreli wrote:


On 06/11/2017 12:27 PM, ketmar wrote:


p.s.: or replacing make-based build system with D-based. as we need
working D compiler to compile dmd anyway, i see no reason to not use it
more.


I had the pleasure of working with Eyal Lotem, main author of buildsome. 
The buildsome team are aware of all pitfalls of all build systems and 
offer build*some* as an awe*some* ;) and correct build system:


   http://buildsome.github.io/buildsome/


haskell? no, thanks. sorry.

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

solidstate1991 wrote:

E already exists (https://en.wikipedia.org/wiki/E_(programming_language) 
+ AmigaE), two things having the same name often doom one of them into 
obscurity (see SDLang, which originally was called SDL).

and there were several "D"s too. ;-)

There were already a few changes in the language (use of static imports 
instead of directly accessing functions/libraries, etc), just as we're 
adding to the language, we can remove rarely used functions by first 
making them deprecated, then removing them altogether as time passes on.


sometimes it is hard or even impossible to change something and keep old 
feature still working. it also require considerably more efforts to support 
old and new feature set simultaneously. while D2 can continue evolving (and 
it surely will!), having D3, where keeping old code working is not a 
concern, can be useful.


nobody says that we should abandon D2 tomorrow and switch everything to D3. 
it's more about exploring new ways without constant pressure of "don't 
break the code" mantra.


don't get me wrong, tho: "don't break the code" is good. but it limits 
possible ways D can evolve (or greatly slows it all down). D3 can be 
"experimental research project", where some of the dreams can come true. it 
may won't even reach the state where it will replace D2, instead D2 may 
adopt some D3 features, and D3 will be scrapped (or restarted). there is 
nothing wrong with it. also, i don't expect D3 to be developed in "full 
speed" too.

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Guillaume Piolat wrote:


On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote:

Well, no thanks.
The very same strategy halved the community for D1/D2 split and almost 
killed D.


as you can see, D is alive and kicking, and nothing disasterous or fatal 
happens.


https://forum.dlang.org/search?q=%22D2%22+destroyed+author%3AWalter+author%3ABright=Search


so what? "nearly destroyed" != "destroyed". as i said, D is alive and ok, 
nothing fatal happens. backing fear of changes with "last time it almost 
destroyed us" won't do any good in the long term: it will ultimately end 
with having no changes at all, D will stagnate and die.


changing is a natural thing for evolution, even breaking change. evaluating 
was what done wrong/inoptimal, and improving on that it the thing that will 
keep D not only alive, but will make it better and better. otherwise, 
accumulated legacy will inevitably turn D into another C++, and somebody 
will create E (or something ;-). why don't create E outselves, and call it 
D3 instead?

Re: Expressing range constraints in CNF form

[ketmar via Digitalmars-d]

Walter Bright wrote:


On 6/11/2017 8:25 AM, Andrei Alexandrescu wrote:

Ostensibly the function is trivial:
bool msg(string) { return true; }
It doesn't change the semantics. The compiler would recognize it as an 
intrinsic and would print the message if the clause to its left has 
failed.


There was a proposal a while back to enable CTFE to print messages, which 
is probably a better solution. msg() could be something along the lines 
of:


 bool msg(string) { __ctfeprint(string); return true; }

which would involve considerably less compiler magic. Furthermore, `msg` 
could be a local private function, which would avoid "but I'm already 
using `msg`" problems.


i think, that something like `__constraint(condition, "message")` is ok, 
and it should be built-in, just like `__traits()`. so compiler can collect 
those messages, and only show 'em if the matcher is failed to find 
anything. yeah, another hack in interpreter, but fairly small, and should 
solve "what constraint is really failed" problem.

Re: Expressing range constraints in CNF form

[ketmar via Digitalmars-d]

Walter Bright wrote:


On 6/11/2017 8:25 AM, Andrei Alexandrescu wrote:

Ostensibly the function is trivial:
bool msg(string) { return true; }
It doesn't change the semantics. The compiler would recognize it as an 
intrinsic and would print the message if the clause to its left has 
failed.


There was a proposal a while back to enable CTFE to print messages, which 
is probably a better solution. msg() could be something along the lines 
of:


 bool msg(string) { __ctfeprint(string); return true; }

which would involve considerably less compiler magic. Furthermore, `msg` 
could be a local private function, which would avoid "but I'm already 
using `msg`" problems.


that has another problem: there may be overload set, where some overloads 
are failed, but one is fitting. using `ctfeprint` will spam user with alot 
of non-sensical messages about failed constraints.

Re: Makefile experts, unite!

[ketmar via Digitalmars-d]

Andrei Alexandrescu wrote:


Phobos' posix.mak offers the ability to only run unittests for one module:

make std/range/primitives.test BUILD=debug -j8

... or package:

make std/range.test BUILD=debug -j8

It runs module tests in parallel and everything. This is definitely 
awesome. But say I misspell things by using a dot instead of the slash:


make std.range.test BUILD=debug -j8

Instead of an error, I get a no-op result that looks like success. How 
can that situation be converted to an error?


p.s.: or replacing make-based build system with D-based. as we need working 
D compiler to compile dmd anyway, i see no reason to not use it more.

Re: Makefile experts, unite!

[ketmar via Digitalmars-d]

Andrei Alexandrescu wrote:


Phobos' posix.mak offers the ability to only run unittests for one module:

make std/range/primitives.test BUILD=debug -j8

... or package:

make std/range.test BUILD=debug -j8

It runs module tests in parallel and everything. This is definitely 
awesome. But say I misspell things by using a dot instead of the slash:


make std.range.test BUILD=debug -j8

Instead of an error, I get a no-op result that looks like success. How 
can that situation be converted to an error?


maybe by creating phony targets with such names?

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Mike B Johnson wrote:


On Sunday, 11 June 2017 at 06:14:43 UTC, ketmar wrote:

Mike B Johnson wrote:

Yeah, sounds good, because to make progress, progress has to be made. 
Most people are very shortsighted and live in a fear based mentality. 
Mention any type of change and they nearly shit themselves and never 
actually think about the consequence of those changes. They just assume 
it means change and it's something they can't handle.


Having an "experimental" D allows those crazy and potentially "mind 
altering" advancements to be worked on, advanced, and polished. It 
takes time for ideas to grow(because, ultimately, it involves learning 
and learning takes time).


yeah. this is exactly the mentality i want to fight with. in my opition, 
having such forum "officially blessed" will encourage people to 
experiment. or at least i hope so. ;-)


It's an uphill battle. You are fighting human nature/evolution/ignorance 
;/ The good news is that humans are good at mountain climbing when they 
want to be.


yeah. i don't have enough energy to keep a *real* fight going, but i at 
least poping up with my "experimental forum" idea from time to time. i'm in 
no hurry, and i'm sure that slow, but constant efforts will won the battle. 
10 years, 100 years, 1000 years... as i said, i'm in no hurry at all. ;-)

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Guillaume Piolat wrote:


On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
I realize that there are people who want to continue using D as it is, 
but those people may continue to use D2.


Well, no thanks.
The very same strategy halved the community for D1/D2 split and almost 
killed D.


as you can see, D is alive and kicking, and nothing disasterous or fatal 
happens.

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Ola Fosheim Grøstad wrote:


On Sunday, 11 June 2017 at 05:24:25 UTC, ketmar wrote:
and D1.5 too. sure it should be forked from D2, and then it should be 
made *smaller*. which, essentially, makes it D1.5, not D3. besides, it 
will be very fun explaining people that we


D--?

Out of curiosity; wouldn't it be better to start with one of the 
alternative compilers that are being worked on (SDC or others), or are 
they no longer active?


to remove features, it is nice to *have* those features first. and there 
are no other feature-complete frontends besides dmdfe.

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Mike B Johnson wrote:

Yeah, sounds good, because to make progress, progress has to be made. 
Most people are very shortsighted and live in a fear based mentality. 
Mention any type of change and they nearly shit themselves and never 
actually think about the consequence of those changes. They just assume 
it means change and it's something they can't handle.


Having an "experimental" D allows those crazy and potentially "mind 
altering" advancements to be worked on, advanced, and polished. It takes 
time for ideas to grow(because, ultimately, it involves learning and 
learning takes time).


yeah. this is exactly the mentality i want to fight with. in my opition, 
having such forum "officially blessed" will encourage people to experiment. 
or at least i hope so. ;-)

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Seb wrote:


On Sunday, 11 June 2017 at 00:37:09 UTC, ketmar wrote:

Adam D. Ruppe wrote:
I think dev resources are thin because of mismanagement by the core 
team failing to attract and retain contributors. Part of this 
mismanagement is a really discouraging attitude toward positive yet 
breaking change; I propose that mere willingness to shake up the status 
quo would help to solve the resource shortage.


+1

actually, some time ago i proposed to create "experimental and breaking 
language changes" subforum, where people can go with their wild ideas, 
and other people can post patches/builds with those (or other) ideas 
imlemented/half-implemented.


That's called a feature-branch ;-)


not everybody in the world is github-centric.

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Liam McGillivray wrote:


On Sunday, 11 June 2017 at 00:27:06 UTC, ketmar wrote:
..and it actually should be D1.5, not D3. ;-) 'cause D3 implies even 
more features, and i feel that the way to get The Perfect D (sorry! ;-) 
is trying to cut all the features that aren't strictly necessary 
(including fat-free stdlib too: i see stdlib as a part of the language).


D1.5? What?  This has nothing to do with D1. 


and D1.5 too. sure it should be forked from D2, and then it should be made 
*smaller*. which, essentially, makes it D1.5, not D3. besides, it will be 
very fun explaining people that we have D1, then D2, and the newest version 
is D1.5. people will blog/tweet this, for sure. free PR!

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Adam D. Ruppe wrote:


On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote:
Dev resources are stretched thin as it is, I doubt the core team would 
go for it.


I think dev resources are thin because of mismanagement by the core team 
failing to attract and retain contributors. Part of this mismanagement is 
a really discouraging attitude toward positive yet breaking change; I 
propose that mere willingness to shake up the status quo would help to 
solve the resource shortage.


actually, some time ago i proposed to create "experimental and breaking 
language changes" subforum, where people can go with their wild ideas, and 
other people can post patches/builds with those (or other) ideas 
imlemented/half-implemented.


this way we can gather some feedback from someone who is really using new 
feature, and have a better vision if it worth further time investments or 
not. 'cause having a live compiler with new feature to play with is not the 
same as simply dicussing the possible feature in NG. i maintain my private 
fork of dmd/druntime/phobos, and this is the way i evaluate features: just 
add what i can, and then see if i'll start using it in my code. if not, the 
feature is cutted, otherwise it is retained.


and ah, building dmd from sources is not something many people want/can to 
do. sure, downloading binaries from random people over the net is not the 
safest thing to do, but if there will be patch+binary combos, it may work.


i.e. i see that "experimental" subforum as a place for ideas *and* 
implementations. and implementors can provide built binaries for people to 
play, or other people can build binaries ('cause if you built it for 
yourself, why don't share it with others?).


i know that this forum is actually a newsgroup, and it can't host files. 
but i believe that this problem can be solved -- either by using some 
simple js-free (for download; yeah, there are such things! ;-) service to 
host binaries, or by some other means.

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Liam McGillivray wrote:

I feel like D3 would see significantly wider adoption than D2 ever got, 
as long as it successfully solves the problems of D2.


..and it actually should be D1.5, not D3. ;-) 'cause D3 implies even more 
features, and i feel that the way to get The Perfect D (sorry! ;-) is 
trying to cut all the features that aren't strictly necessary (including 
fat-free stdlib too: i see stdlib as a part of the language).

Re: DMD test suite not runnable on Debian/Linux

[ketmar via Digitalmars-d]

H. S. Teoh wrote:


On Sat, Jun 10, 2017 at 02:27:13AM +0300, ketmar via Digitalmars-d wrote:

H. S. Teoh wrote:


On a tangential note, now that I finally got the miserable test
suite running, I've managed to figure out that the problem in my dmd
PR was caused by src/ddmd/globals.h not being auto-generated from
src/ddmd/globals.d, so when I added new fields to the Global struct,
the C++ code that use globals.h with the old definition crashed. I
suppose this is just a relic from the pre-self-hosting days, but it
would be nice if these last .h files were gotten rid of in the near
future.
That, or we should (ab)use the .di generation facility or some sed
script to generate these .h files, so that they won't go out-of-sync
inadvertently.

we can use UDAs to do that! just make the generator import the
relevand dmd parts, and then use compile-time introspection to build
tables, so generator can just write 'em to file in runtime. ;-)


Sure!  But ... uhm... what has UDAs gotta do with that? A straight
`foreach (memb; __traits(allMembers, T))` should do the trick.


i thought about situations where you may need to exclude something from 
generated header... but this surely has no sense, as one cannot exclude 
fields or virtual methods from generated classes, so `extern(C++)` is 
surely enough. well, i like to overengineer! ;-)

Re: DMD test suite not runnable on Debian/Linux

[ketmar via Digitalmars-d]

H. S. Teoh wrote:


On a tangential note, now that I finally got the miserable test suite
running, I've managed to figure out that the problem in my dmd PR was
caused by src/ddmd/globals.h not being auto-generated from
src/ddmd/globals.d, so when I added new fields to the Global struct, the
C++ code that use globals.h with the old definition crashed. I suppose
this is just a relic from the pre-self-hosting days, but it would be
nice if these last .h files were gotten rid of in the near future.

That, or we should (ab)use the .di generation facility or some sed
script to generate these .h files, so that they won't go out-of-sync
inadvertently.


we can use UDAs to do that! just make the generator import the relevand dmd 
parts, and then use compile-time introspection to build tables, so 
generator can just write 'em to file in runtime. ;-)

Re: DMD test suite not runnable on Debian/Linux

[ketmar via Digitalmars-d]

it's even worser than that: unittests ultimatively fails with binutils 2.28 
(at least on x86 without PIC), so i was forced to downgrade binutils to 2.26.

Re: a way to specily floating-point numbers as bit patters

[ketmar via Digitalmars-d-learn]

Honey wrote:


On Friday, 9 June 2017 at 16:34:28 UTC, ketmar wrote:

Try -0.1685f.


it doesn't matter if i can find the decimal representation for the given 
bit pattern or not. the whole post is about removing the need to rely on 
lossy binary->decimal->binary conversions.


Lossless turn-around is guaranteed if you are using sufficiently many 
digits. In case of IEEE-754 single precision it's 8 significant decimal 
digits.


it is highly platform-dependent. and both bin->dec, and dec->bin conversion 
routines can contain errors, btw. so using decimal forms for exact 
bit-patterns is the last thing i want to do, as i know how fragile they are.

Re: a way to specily floating-point numbers as bit patters

[ketmar via Digitalmars-d-learn]

Basile B. wrote:


On Friday, 9 June 2017 at 17:18:43 UTC, ketmar wrote:

Basile B. wrote:


 enum binFloat = *cast(float*) 


i was SO sure that this won't work in CTFE that i didn't even tried to 
do it. "it will fail anyway, there is no reason in trying!" ;-)


You can do the arithmetic as well. I don't know why but i supposed that 
my static asserts were a proof of CTFE-ability.


yeah, it is CTFEable. now i recall that such casting for floats was 
special-cased in interpreter exactly to allow this kind of things. my bad.

Re: a way to specily floating-point numbers as bit patters

[ketmar via Digitalmars-d-learn]

Basile B. wrote:


 enum binFloat = *cast(float*) 


i was SO sure that this won't work in CTFE that i didn't even tried to do 
it. "it will fail anyway, there is no reason in trying!" ;-)

Re: a way to specily floating-point numbers as bit patters

[ketmar via Digitalmars-d-learn]

Petar Kirov [ZombineDev] wrote:


Do HexFloats (http://dlang.org/spec/lex#HexFloat) help?


hm. i somehow completely missed "%a" format specifier! yeah, 
"-0x1.6ep-3" did the trick.


tnx. i should do my homework *before* posting big rants, lol.

Re: a way to specily floating-point numbers as bit patters

[ketmar via Digitalmars-d-learn]

Basile B. wrote:


ps. "-0.17 0xBE2AAAC1". it's not the same! (and yes, it matters).


-0.17f is not representable as a 32 bit float. The actuall value 
that's stored is -0.169994592259765625, hence the difference. See 
https://www.h-schmidt.net/FloatConverter/IEEE754.html and enter your 
value in the field labeled "You entered".


i'm completely aware about floating point values representation, and 
problems with bin->dec->bin conversions of floats. the post is about 
avoiding those conversions at all.


and this means that i can't inline my calculated values! each time i 
want to get floating value with a known bit-pattern, i have to store it 
as uint, and resort to ugly hack: 
`*cast(immutable(float)*)([2])`.


and i can't do this trick in CTFE, as such pointer tricks aren't 
permitted.


i tried different workarounds, but they're all ugly. it would be very 
nice to have a way to define IEEE floating point numbers as bit-patterns 
in the language itself. what do you think?


Yes, easy to do, a template alà octal or hexString.


can you show it, please? remember, CTFE-able!

Re: a way to specily floating-point numbers as bit patters

[ketmar via Digitalmars-d-learn]

Honey wrote:


On Friday, 9 June 2017 at 16:07:36 UTC, ketmar wrote:
one of my calculated values is `-0.17`, which has bit-pattern of 
0xBE2AAAB7.

now, let's say i want to use this number in my code:

float v = -0.17f;
writefln("%f 0x%08X", v, *cast(uint*));

ps. "-0.17 0xBE2AAAC1". it's not the same! (and yes, it matters).


Try -0.1685f.


it doesn't matter if i can find the decimal representation for the given 
bit pattern or not. the whole post is about removing the need to rely on 
lossy binary->decimal->binary conversions.

a way to specily floating-point numbers as bit patters

[ketmar via Digitalmars-d-learn]

let's say that i have precomputed some `float`-typed tables, and now i want 
to use 'em in my code. for example, a table for Lagrange series. the table 
itself is like 10 numbers, but the code calculating it rather big, and it 
depends of architecture (so it can yield different results on different 
arch). yet i want the same IEEE numbers everywhere.


the code problem is that i really can't express *exactly* *the* *same* IEEE float 
with D. let me illustrate this.


one of my calculated values is `-0.17`, which has bit-pattern of 0xBE2AAAB7.
now, let's say i want to use this number in my code:

float v = -0.17f;
writefln("%f 0x%08X", v, *cast(uint*));

ps. "-0.17 0xBE2AAAC1". it's not the same! (and yes, it matters).

and this means that i can't inline my calculated values! each time i want 
to get floating value with a known bit-pattern, i have to store it as uint, 
and resort to ugly hack: `*cast(immutable(float)*)([2])`.


and i can't do this trick in CTFE, as such pointer tricks aren't permitted.

i tried different workarounds, but they're all ugly. it would be very nice 
to have a way to define IEEE floating point numbers as bit-patterns in the 
language itself. what do you think?


yes, i know that floating numbers has to be loaded from memory anyway, so 
my trick is not really worse than specifying the constant directly. but it 
is still dirty trick, and i cannot use it in @safe code too, so i have to 
mark my code as @trusted, which is not the same at all. there probably may 
be other trick such this for @safe code, but... you got the idea, i think.

Re: Compile-Time Sort in D

[ketmar via Digitalmars-d-announce]

Steven Schveighoffer wrote:

At least in terms of i/o printing to the console or whatnot, it would be 
cool to be able to do so at compile-time just directly with writeln. As 
of now, a CTFE function can't call writeln, and it also can't pragma(msg, 
...) because it has to be written as a runtime function.


yeah, `ctfeWriteln()`, even in very rudimentary form, will be priceless for 
debugging CTFE code. sure, CTFE code can be called in runtime and debugged, 
but sometimes it require alot of bouncing back and forth, like "let's 
replace all `enum` values with `auto` down the code, and then back", 'cause 
result of one CTFE call may be used in another CTFE call, and so on...

Re: DMD [-O flag] vs. [memory allocation in a synchronized class]

[ketmar via Digitalmars-d-learn]

realhet wrote:


On Thursday, 8 June 2017 at 10:48:41 UTC, ketmar wrote:

worksforme with -O, and with -O -inline.


I forgot to mention, that I'm generating win32 output.
DMD32 D Compiler v2.074.0


mine: GNU/Linux, 32 bit, dmd git HEAD.

Re: DMD [-O flag] vs. [memory allocation in a synchronized class]

[ketmar via Digitalmars-d-learn]

worksforme with -O, and with -O -inline.

Re: vibe.d on Web Framework Benchmarks

[ketmar via Digitalmars-d]

Ozan wrote:


On Wednesday, 7 June 2017 at 09:44:55 UTC, Ali Çehreli wrote:
Is there an issue with the tests? Surprised that vibe.d is not higher in 
the rating...


https://www.techempower.com/benchmarks/#section=data-r14=ph=fortune


Same for me.
I used a lot of Java (Jetty, Tomcat) and Groovy (Grails) stuff before 
using D (vibe.d).
On my machine I got a factor of 10-50 in difference. Vibe.d was always 
much faster.


So where are the results coming from?


most of it came from microbenchmarking. "how fast can we parse json and 
query db?" wow, what a great benchmark! surely, we don't need to do any 
data processing, let's measure raw speed of parsing data, and then throwing 
it away!

Re: Alias this and inheritance

[ketmar via Digitalmars-d]

Jacob Carlborg wrote:


The following code does not compile:

void foo(string a) {}

class Base
{
 alias bar this;

 string bar()
 {
 return "";
 }
}

class Sub : Base {}

void main()
{
 auto sub = new Sub;
 foo(sub);
}

But if the "alias this" is copied/moved to the subclass it works. Is this 
expected behavior?


yes, afaik. the reasons are similar to not automatically bringing overloads 
when you're doing override, and avoiding other "automatic helpers" most of 
the time: it can quickly get out of control.

Re: Label as Values in D ?

[ketmar via Digitalmars-d]

Patric Dexheimer wrote:


https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

Is possible to use Label as Values in D?
Or there is a way to do dynamic goto statements?

Ps: This is out of curiosity / performance reasons. I know the potential 
of bad design / ugly code ;)


as we have nested functions, you can just initialize a table with function 
pointers, and use it instead of computed goto. this is way more powerful 
trick, as you can actually use any selector you want, in any way you want, 
and still have the speed of computed goto (most of the time).

Re: Concept proposal: Safely catching error

[ketmar via Digitalmars-d]

Olivier FAURE wrote:


On Monday, 5 June 2017 at 10:09:30 UTC, ketmar wrote:


tbh, i think that it adds Yet Another Exception Rule to the language, 
and this does no good in the long run. "oh, you generally cannot do 
that, except if today is Friday, it is rainy, and you've seen pink 
unicorn at the morning." the more exceptions to general rules language 
has, the more it reminds Dragon Poker game from Robert Asprin books.


Fair enough. A few counterpoints:

- This one special case is pretty self-contained. It doesn't require 
adding annotations (unlike, say, DIP PR #61*), won't impact code that 
doesn't use it, and the users most likely to hear about it are the one 
who need to recover from Errors in their code.


- It doesn't introduce elaborate under-the-hood tricks (unlike DIP 
1008*). It uses already-existing concepts (@safe and @pure), and is in 
fact closer to the intuitive logic behind Error recovery than the current 
model; instead of "You can't recover from Errors" you have "You can't 
recover from Errors unless you flush all data that might have been 
affected by it".


*Note that I am not making a statement for or against those DIPs. I'm 
only using them as examples to compare my proposal against.


So while this would add feature creep to the language, but I'd argue that 
feature creep would be pretty minor and well-contained, and would 
probably be worth the problem it would solve.


this still nullifies the sense of Error/Exception differences. not all 
errors are recoverable, even in @safe code. assuming that it is safe to 
catch any Error in @safe immediately turns it no unsafe. so... we will need 
to introduce RecoverableInSafeCodeError class, and change runtime to throw 
it instead of Error (sometimes). and even more issues follows (it's 
avalanche of changes, and possible code breakage too).


so, in the original form your idea turns @safe code into unsafe, and with 
more changes it becomes a real pain to implement, and adds more complexity 
to the language (another Dragon Poker modifier).


using wrappers and carefully checking preconditions looks better to me. 
after all, if programmer failed to check some preconditions, the worst 
thing to do is trying to hide that by masking errors. bombing out is *way* 
better, i believe, 'cause it forcing programmer to really fix the bugs 
instead of creating hackish workarounds.

Re: Concept proposal: Safely catching error

[ketmar via Digitalmars-d]

Olivier FAURE wrote:


What do you think? Does the idea have merit? Should I make it into a DIP?


tbh, i think that it adds Yet Another Exception Rule to the language, and 
this does no good in the long run. "oh, you generally cannot do that, 
except if today is Friday, it is rainy, and you've seen pink unicorn at the 
morning." the more exceptions to general rules language has, the more it 
reminds Dragon Poker game from Robert Asprin books. any exception will 
usually have a strong rationale behind it, of course, so it will be a 
little reason to not accept it, especially if we had accepted some 
exceptions before. i think it is better to not follow that path, even if 
this one idea looks nice.

Re: D and GDB

[ketmar via Digitalmars-d-learn]

Russel Winder wrote:


I thought I had left SIGSEGV debugging behind, but it seems not.
However whilst the C++/CLion debug tooling is excellent, D seems to be
without. I guess there must be some gdb magic I am missing, but:


Program received signal SIGSEGV, Segmentation fault.
0x7fffc788 in ?? ()
gdb>b
Breakpoint 1 at 0x7fffc788
gdb>

Not the most illuminating backtrace I have seen.


maybe 'cause backtrace is called with `bt` command? ;-)

Re: C macros vs D can't do the right thing

[ketmar via Digitalmars-d-learn]

Jacob Carlborg wrote:

Perhaps using the variadic template with a constraint on one element 
trick will work. Ugly, but I think that will work.


yeah. that's what Phobos does, for example.

Re: C macros vs D can't do the right thing

[ketmar via Digitalmars-d-learn]

Russel Winder wrote:


Now the D Way says...

..use templates! ;-)

it is not really possible to guess what macro author means (to do that, 
dstep should be able to actually *understand* the code), so it tries to do 
what is used more often.


that is, it's dstep failed guess.

Re: DIP 1003 (Remove body as a Keyword) Accepted!

[ketmar via Digitalmars-d-announce]

Petar Kirov [ZombineDev] wrote:

Personally, making contracts less verbose and more powerful is much 
higher on my list (I don't remember ever needing to use 'body' as an 
identifier, but I see why is it important for many domains)


yeah. i'm really tired to use `flesh` instead of it. and i have bodies 
literally everywhere: active, sleeping, dead, broken... several of my game 
engines has more-or-less physics-based simulations, so i need `body`! ;-)

Re: Erroneous usage of variable capture in loops

[ketmar via Digitalmars-d]

FreeSlave wrote:


As known this code will not work as we may expect:

import std.stdio;

void main(string[] args)
{
 void delegate ()[] delegates;
 foreach(i; 0..10) {
 int j = i;
 delegates ~= delegate() {
 writeln(j);
 };
 }
 foreach(dlgt; delegates) {
 dlgt();
 }
}

All delegates will capture the last value of 'j'.

dmd does not complain about such case at all. Once I made this mistake 
myself but noticed it thanks to unittesting. Recently I found similar 
erroneous code in dlangui (no PR yet). Probably there are more projects 
that have the same mistake unnoticed.


May be compiler should produce error or at least generate warning on this 
code.


i'm not even sure that it is detectable. what if i'll insert:

if (i == args.length) break;

i.e. i *know* about the effect, and still want to do it? i can use it to 
capture some struct and break, for example. detecting this is kind of 
halting problem. and there is absolutely no way to hush the compiler, so it 
will always emit warning.

Re: Bad array indexing is considered deadly

[ketmar via Digitalmars-d]

Steven Schveighoffer wrote:


On 5/31/17 10:07 AM, Steven Schveighoffer wrote:


Here is complete implementation (should be @safe too):

struct ExArr(T, size_t dim)
{
T[dim] _value;
alias _value this;
ref inout(T) opIndex(size_t idx, string fname = __FILE__, size_t
linenum = __LINE__) inout
{
if(idx >= dim)
throw new Exception("Index out of bounds", fname, linenum);
static ref x(ref inout(T[dim]) val, size_t i) @trusted { return
val.ptr[i]; }
return x(_value, idx);
}
}


Just realized, that @trusted escape is just so unnecessarily verbose.

struct ExArr(T, size_t dim)
{
 T[dim] _value;
 alias _value this;
 ref inout(T) opIndex(size_t idx, string fname = __FILE__, size_t 
linenum = __LINE__) inout @trusted

 {
 if(idx >= dim)
 throw new Exception("Index out of bounds", fname, linenum);
 return _value.ptr[idx];
 }
}

-Steve


bonus point: you can include index and length in error message! (something 
i really miss in dmd range error)

Re: Bad array indexing is considered deadly

[ketmar via Digitalmars-d]

Steven Schveighoffer wrote:


On 5/31/17 9:37 AM, Adam D. Ruppe wrote:

On Wednesday, 31 May 2017 at 13:04:52 UTC, Steven Schveighoffer wrote:

What are your thoughts? Have you run into this? If so, how did you
solve it?


I don't use vibe, but my cgi.d just catches RangeError, kills the
individual connection, and lets the others carry on. Can you do the same
thing?


There are a couple issues with this. At least from the perspective of 
vibe.d attempting to be a mainstream base library.


1. You can mark a function nothrow that throws a RangeError. So the 
compiler is free to assume the function won't throw and build faster code 
that won't properly clean up if an Error is thrown.


2. Technically, there is no guarantee by the runtime to unwind the stack. 
So at some point, your workaround may not even work. And even if it does, 
things like RAII may not work.


-Steve


that is, the question reduces to "should out-of-bounds be Error or Exception"?

i myself see no easy way to customize this with language attribute 
(new/delete disaster immediately comes to mind). so i'd say: "create your 
own array wrapper/implementation, and hope that all the functions you need 
are rangified, so they'll be able to work with YourArray".

Re: purity question

[ketmar via Digitalmars-d-learn]

Rene Zwanenburg wrote:


On Tuesday, 30 May 2017 at 11:34:52 UTC, ketmar wrote:
If malloc were marked as pure, wouldn't that mean it must return the 
same pointer every time you call it with the same size?


of course. but D "pure" is not what other world knows as "pure". we love 
to mess with words.


Well, there's the ability to modify non-const reference parameters from a 
pure function, but that's not applicable to malloc. Are there any other 
special rules?


"pure" methods can mutate object state.

Re: purity question

[ketmar via Digitalmars-d-learn]

Rene Zwanenburg wrote:


On Monday, 29 May 2017 at 01:36:24 UTC, Jonathan M Davis wrote:

A simple example: anything that has a malloc/free pair.


Yeah, if you do it right, you should be fine, but you have to do it 
right, and it's very easy to miss some detail that makes it wrong to 
insist to the compiler that what you're doing is pure.


If malloc were marked as pure, wouldn't that mean it must return the same 
pointer every time you call it with the same size?


of course. but D "pure" is not what other world knows as "pure". we love to 
mess with words.

Re: purity question

[ketmar via Digitalmars-d-learn]

Ola Fosheim Grøstad wrote:


On Monday, 29 May 2017 at 08:49:07 UTC, ketmar wrote:
pure. and while various functions in std.math, for example, are marked 
`pure`, they aren't too.


Out of curiosity, which functions in std.math aren't "pure" in the D 
sense?


almost all of them, 'cause they depends on FPU rounding settings.

Re: purity question

[ketmar via Digitalmars-d-learn]

Brad Roberts wrote:

libraries that themselves aren't marked pure, there's a real need for 
escape hatches.  A simple example: anything that has a malloc/free pair.


they aren't pure. it is a sad misconception about purity, which D makes 
even more complex by allowing to mark, for example, *setters* as pure. but 
still, `malloc()` and `free()` aren't pure. and while various functions in 
std.math, for example, are marked `pure`, they aren't too.

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

[ketmar via Digitalmars-d]

Nick Sabalausky (Abscissa) wrote:

In response to any claim that this isn't a real problem in practice, I 
submit the possibility that, if it indeed isn't a real problem, maybe 
that's *because* of people (like Stefan and ketmar) simply avoiding the 
feature entirely so that it *doesn't* become a problem.


exactly! you can include Adam here too, btw. we all prefer to use pointer 
args exactly to avoid *the* *problem*. so it is not a problem for us 
anymore... but we aren't solved it, we simply cheated. basically, my only 
`ref` usage is `in auto ref` (which is not a "real" ref anyway, as argument 
cannot be changed).


side note: also, with pointers i can do `void foo (int a, bool* res=null) 
{...}`. not a big deal: one can always create set of overloads to get the 
same effect with ref, but -- less typing! ;-)


yet i must say that using pointers in a code where they should be 
references makes me... nervous. it just doesn't feel right. but meh, i'll 
trade that (and safety, 'cause `&` is unsafe) for "call site ref indicator".


that's why i don't bother writing @safe code, btw: in one or another way i 
will be forced to hack aroung @safe restrictions, so no reason to start 
that dance at all. (or just mark the whole thing as @trusted and hope for 
the best)

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

[ketmar via Digitalmars-d]

Nicholas Wilson wrote:


On Sunday, 28 May 2017 at 17:54:30 UTC, WebFreak001 wrote:

Imagine you wrote a function

void foo(ref int a) {
  if (std.random.uniform(0, 10) == 0)
a = 0;
  // Actual code doing something
}

[...]


It seems nice in theory but how will it interact with generic code?
Perhaps it should be optional and purely documentative.


exactly like "&" does.

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

[ketmar via Digitalmars-d]

Ola Fosheim Grostad wrote:


This is information that a good IDE could be designed to provide.


when people start talking about how IDE can help to solve particular 
language problem, it is a clear sign of bad language design.

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

[ketmar via Digitalmars-d]

Meta wrote:


On Sunday, 28 May 2017 at 19:10:49 UTC, ketmar wrote:

Meta wrote:

If a parameter is marked as ref then you have to assume it will be 
modified by the function (unless it's const/inout/immutable). If it's 
marked as out then you know it will be. If you didn't know that the 
function takes its parameters by ref or out... You're should've RTFM.


now imagine that you're reading some code:

foo(a);

vs:

foo(ref a);

which code style is easier to read without constant jumping into 
documentation?


Is this ever actually a problem in practice?


yes. aliced has this syntax for a long time. for a reason. and i must say 
that i'm adding alot of random features to aliced, but very little of 'em 
survives.


Anyway, having to add ref or out at the call site will greatly hamper 
metaprogramming.


not more then "&" does. except with `auto ref` -- which is misdesigned 
feature anyway (forcing programmer to do the work compiler can do without 
any external help is not a good design; besides, compiler can do that work *better*).

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

[ketmar via Digitalmars-d]

Stefan Koch wrote:

Personally I stay away from ref precisely because of it's silent caller 
syntax.


same here. i prefer to use pointers instead, 'cause they are visible at the 
calling site.

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

[ketmar via Digitalmars-d]

Meta wrote:

If a parameter is marked as ref then you have to assume it will be 
modified by the function (unless it's const/inout/immutable). If it's 
marked as out then you know it will be. If you didn't know that the 
function takes its parameters by ref or out... You're should've RTFM.


now imagine that you're reading some code:

foo(a);

vs:

foo(ref a);

which code style is easier to read without constant jumping into 
documentation?

Re: DMD now has colorized syntax highlighting in error messages

[ketmar via Digitalmars-d-announce]

Walter Bright wrote:


https://github.com/dlang/dmd/pull/6777

It turned out to be unexpectedly easy to implement.

The only downside is now we have to rather tediously tweak the error 
message texts so they use backticks.


sorry for being rude, but this is exactly the example of things programmers 
like to write: fun, quite easy, and absolutely useless. most of the time it 
will be filtered away by ide/editor, and otherwise it is *harder* to read, 
'cause it will almost certainly not match editor's syntax coloring settings, 
so reader will have to mentally strip the colors first.


while much harder task -- showing which exactly template failed in template 
constraint -- is very hard to implement (i tried it, i know it), but will 
immediately benefit *anyone*, and will be really useful.


i'm not trying to say that you should drop the things you like to work on, 
and switch to the things i like, of course. but this patch, IMO, doesn't 
deserve a dedicated NG post.


sorry again, i'm frustrated by dmd inability to generate valid .o file from 
completely valid source, so can be harsh today.

Re: Processing a gzipped csv-file by line-by-line

[ketmar via Digitalmars-d-learn]

Nordlöw wrote:

What's fastest way to on-the-fly-decompress and process a gzipped csv-fil 
line by line?


Is it possible to combine

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

with some stream variant of

File(path).byLineFast

?


iv.vfs[0] can do that (transparently decompress gzip files, and more). yet it 
is far from "fastest", so i don't think that it will fit. yet i can't miss 
such a great opportunity for self-promotion.



[0] http://repo.or.cz/iv.d.git/tree/HEAD:/vfs

Re: dmd: can't build on Arch Linux or latest Ubuntu

[ketmar via Digitalmars-d]

Marco Leise wrote:


Am Wed, 10 May 2017 20:59:33 +0300
schrieb ketmar :

On Wednesday, 10 May 2017 at 11:51:03 UTC, Atila Neves wrote:  
I can't build dmd on Arch Linux anymore. I'm told it's because of a 
binutils update. Annoying.  


yeah, the great thing. i was hit by that bus too, and had to mutilate 
druntime to make unittests work again. lucky me, i'm using static 
phobos. don't even want to think about the scale of the disaster for 
people with libphobos2.so...


O.O

Like what will happen to us on Gentoo with libphobos2.so when
binutils-2.8 moves to stable here? And can it all be solved by
compiling with -fPIC, like is required for hardened
installations anyways or are there dmd versions that flat out
wont work any longer?


sorry, i don't know about PIC (not using it). otherwise, you won't be able 
to run anything with shared phobos: druntime conflict scanner will always 
find a conflict and abort (that is what happening with test_runner). at 
least 2.074 is affected. i "solved" it by commenting out druntime checker, 
but this cannot be used as a general solution, of course: the checker 
should be fixed. yet i don't know enough about elf and .so (and, tbh, i 
don't even *want* to dive there).


bugreport says that PIC is a working solution (i.e. binaries and libraries 
built with -fPIC should work). i didn't checked it, tho (not a big fan of 
PIC).

Re: dmd: can't build on Arch Linux or latest Ubuntu

[ketmar via Digitalmars-d]

Seb wrote:


On Wednesday, 10 May 2017 at 11:51:03 UTC, Atila Neves wrote:
I can't build dmd on Arch Linux anymore. I'm told it's because of a 
binutils update. Annoying.


Yep, at least running the tests on Phobos fails due to changes in 
binutils 2.28, see this bug report for more details:


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


yeah, the great thing. i was hit by that bus too, and had to mutilate 
druntime to make unittests work again. lucky me, i'm using static phobos. 
don't even want to think about the scale of the disaster for people with 
libphobos2.so...

Re: readf interferes with readln

[ketmar via Digitalmars-d-learn]

Bastiaan Veelo wrote:


Hi,

I am having trouble explaining the following to someone learning D. Can 
someone explain why readln has different behaviour when it is preceded by 
readf?


Suppose we want to not end the program before the user presses Enter by 
having readln at the end of main():


```
import std.stdio;

void main()
{
 int num;
 write("Give a number ");
 readf(" %s", num);
 writeln("Thanks");
 readln;
 readln;
}
```

In this example this requires twice readln. When you comment out readf, 
you need readln only once.


Thanks!


'cause your `readf()` stops before consuming `'\n`. i.e. EOL is still in 
input buffer, and first `readln()` will immediately consume it.

Re: Python : Pythonista / Ruby: Rubyist : / D : ?

[ketmar via Digitalmars-d]

Vasudev Ram wrote:


Hi list,

I hope the question is self-evident from the message subject. If not, it 
means: what are D developers generally called (to indicate that they 
develop in D)? The question occurred to me somehow while browsing some D 
posts on the forums just now.


DLanger? DLangist? D'er? Doer? :)

I tend to favor DLanger, FWIW.

Interested to know, just for fun ...

I do realize that there may not be commonly known or accepted terms like 
this for all languages. For example, I don't know if there is such a term 
for a C or C++ developer. Might make for an interesting thread.


we are usually called "programmers".

Re: Interpolated strings

[ketmar via Digitalmars-d]

Gary Willoughby wrote:

Go and Rust are both smashing D in popularity and user share, maybe we 
could learn why that's the case.


'cause go backed by google, and rust backed by mozilla.

Re: Playing arround with mixin - alias?

[ketmar via Digitalmars-d-learn]

Martin Tschierschke wrote:


i doubt so.

So my "solution" on how to get a short cut for using:

writeln(mixin(interp!"${name} you are app. ${age*365} days old"));

..

NEVER. EVER. USE. THE. FOLOWING. IN. YOUR. CODE.
NEVER!!!


import std.stdio;

mixin template usesexpand() {
import std.format : format;
string sexpand1(string s) () {
char[] res;
res.length = s.length+1024;
auto rused = res.length;
auto rpos = rused*0; // i really HAET `size_t`!
void put(bool escape=true) (const(char)[] s...) {
foreach (char ch; s) {
static if (escape) {
if (ch == '"' || ch == '\\') {
if (rpos == rused) { rused += 
1024; res.length = rused; }
res[rpos++] = '\\';
}
}
if (rpos == rused) { rused += 1024; res.length 
= rused; }
res[rpos++] = ch;
}
}

char[] fmt;
fmt.length = 256;
auto fused = fmt.length;
auto fpos = fused*0; // i really HAET `size_t`!
void putfmt (const(char)[] s...) {
foreach (char ch; s) {
if (fpos == fused) { fused += 1024; fmt.length 
= fused; }
fmt[fpos++] = ch;
}
}

putfmt(`format("`);

auto pos = rpos, epos = rpos;
pos = 0;
while (pos < s.length) {
epos = pos;
while (epos < s.length && s[epos] != '$') ++epos;
putfmt("%s");
put!false(`, "`);
if (epos+1 >= s.length || s[epos+1] != '{') {
put(s[pos..epos+1]);
put!false(`"`);
pos = epos+1;
continue;
}
put(s[pos..epos]);
put!false(`"`);
pos = epos+2;
while (epos < s.length && s[epos] != '}') ++epos;
if (epos > pos) {
putfmt("%s");
put(`, `);
put(s[pos..epos]);
}
pos = epos+1;
}
put(`)`);
putfmt(`"`);
return cast(string)fmt[0..fpos]~cast(string)res[0..rpos]; // it 
is safe to cast here
}
enum sexpandstr(string s) = sexpand1!s;
enum sexpand(string s) = mixin(sexpand1!s);
void echo(string s) () { writeln(mixin(sexpand1!s)); }
}

mixin usesexpand;
immutable n = 40;

enum nstr = sexpand!"n is ${n+2}";

void main () {
mixin usesexpand;
int a = 42/2;
echo!"a is ${a*2}"; //writeln(mixin(sexpandstr!"a is ${a*2}"));
writeln(nstr);
}