Re: "I made a game using Rust"

[JN via Digitalmars-d]

On Wednesday, 10 May 2017 at 18:20:01 UTC, zetashift wrote:

On Wednesday, 10 May 2017 at 12:52:34 UTC, JN wrote:
I wonder, would it be possible for D in the current state to 
achieve the same? I imagine iOS isn't possible yet and Android 
is just getting there?


Reading this thread while going through the online D book I 
wonder;
Would one recommend D for gamedev? I was thinking of writing 
small games with the help of SFML to learn D better and try to 
get better at programming game logic(DLang is my second 
programming language).


I've been using D for little 2D games for Windows and it's an 
excellent choice. I never bothered to set up debugging properly, 
I mostly rely on printf debugging and stacktrace after crashes 
though. But you have access to libraries like SDL/SFML, 
Box2D/Chipmunk, for 2D game you don't really need much more. And 
it's definitely more fun than C/C++.

Re: Access specifiers and visibility

[Jesse Phillips via Digitalmars-d-learn]

On Wednesday, 10 May 2017 at 13:29:40 UTC, Andrew Edwards wrote:

On Wednesday, 10 May 2017 at 13:13:46 UTC, Jesse Phillips wrote:
On Wednesday, 10 May 2017 at 01:42:47 UTC, Andrew Edwards 
wrote:
Attempting to update a git repo to current D, I encounter the 
following deprecation messages:


src/glwtf/signals.d-mixin-256(256,2): Deprecation: 
glwtf.input.BaseGLFWEventHandler._on_key_down is not visible 
from module glwtf.signals


Thanks,
Andrew


This comes from:
http://dlang.org/changelog/2.071.0.html#dip22

The module glwtf.signals needs to import glwtf.input. One of 
the other imports was contaminating the namespace.


I actually attempted solve the issue with selective import as 
such::


import glwtf.input : BaseGLFWEventHandler;

but it did not work. Importing the entire module does not work 
either.


I'm not sure the library you're using but this like the one:
https://github.com/Dav1dde/glwtf/blob/master/glwtf/input.d#L163

This code says that the function is protected.

https://github.com/Dav1dde/glwtf/blob/master/glwtf/signals.d#L254

This line is probably mixing in a call to that function into a 
struct


https://github.com/Dav1dde/glwtf/blob/master/glwtf/signals.d#L229

But that struct doesn't inherit from the class so it can't access 
protected fields.

Re: DIP 1007 Preliminary Review Round 1

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/25/2017 08:33 AM, Steven Schveighoffer wrote:


In the general case, one year is too long. A couple compiler releases
should be sufficient.



* When the @future attribute is added, would one add it on a dummy
symbol or would one provide the implementation as well?


dummy symbol. Think of it as @disable, but with warning output instead
of error.



This is a pointless limitation. What is the benefit of requiring the 
author to *not* provide an implementation until the transition period is 
over? It runs counter to normal workflow.


Instead, why not just say "Here's a new function. But !!ZOMG!! what if 
somebody is already using a function by that name??!? They'd have use 
FQNs to disambiguate! Gasp!!! We can't have that! So, fine, if it's that 
big of a deal, we'll just instruct the compiler to just NOT pick up this 
function unless it's specifically requested via FQN".


That sounds FAR better to me than "Here's a new function, but we gotta 
keep it hidden in a separate branch/version/etc and not let anyone use 
it until we waste a bunch of time making sure everyone's code is all 
updated and ready so that once we let people use it nobody will have to 
update their code with FQNs, because we can't have that, can we?"


Pardon me for saying so, and so bluntly, but honestly, this whole 
discussion is just stupid. It's full-on C++-grade anti-breakage 
hysteria. There are times when code breakage is a legitimate problem. 
This is not REMOTELY one of them.

Re: Problems with Array Assignment?

[Samwise via Digitalmars-d-learn]

On Wednesday, 10 May 2017 at 20:01:16 UTC, Adam D. Ruppe wrote:

...


Thanks loads. Thanks to this my next commit is going to have 
quite a few improvements that clean up the engine code 
considerably. I appreciate the help.

Re: DIP 1007 Preliminary Review Round 1

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/10/2017 11:04 PM, Nick Sabalausky (Abscissa) wrote:

On 05/10/2017 09:51 PM, Nick Sabalausky (Abscissa) wrote:

This is what FQNs are for. At least, it was before FQNs were broken,
first by an incomplete "package.d" system and second by a goofy
half-baked change to import rules.

FQNs need fixed. This DIP is just a questionable workaround for our
borked FQNs that that smacks of C++-style "no breakage at all costs"
design philosophies being applied to both D language and D libraries.


I guess that's my overview. More specifically, what I mean is this:



Ugh, frustrating... Seems like every time I try to clarify something I 
manage to make a jumbled mess of it. Lemme see one last time if I can 
distill that down my basic counter-arguments:


1. Why are FQNs alone (assume they still worked like they're supposed 
to) not good enough? Needs to be addressed in DIP. Currently isn't.


2. The library user is already going to be informed they need to fix an 
ambiguity anyway, with or without this DIP.


3. Updating code to fix the ambiguity introduced by a new symbol is 
always trivial (or would be if FQNs were still working properly and 
hadn't become needlessly broken) and inherently backwards-compatible 
with the previous version of the lib.


3. Unlike deprecations, this only provides a heads-up for trivial 
matters that don't really need a heads-up notice:


Unlike when symbols being added to a lib, the fix in user-code for a 
deprecation *can* be non-trivial and *can* be non-backwards-compatible 
with the previous version of the lib, depending on the exact 
circumstances. Therefore, unlike added symbols, the "deprecation" 
feature for removed symbols is justified.


4. Unlike deprecation, this feature works contrary to the actual flow of 
development and basic predictability:


When a lib author wants to remove a symbol, they already what the symbol 
is, what it's named and that they have X or Y reason to remove it. But 
when a lib author wants to add a symbol, it's more speculative: They 
don't actually KNOW such details until some feature is actually written, 
implemented and just about ready for release. At which point it's a bit 
late, and awkward, to go putting in a "foo *will* be added".

Re: "I made a game using Rust"

[rikki cattermole via Digitalmars-d]

On 10/05/2017 7:20 PM, zetashift wrote:

On Wednesday, 10 May 2017 at 12:52:34 UTC, JN wrote:

I wonder, would it be possible for D in the current state to achieve
the same? I imagine iOS isn't possible yet and Android is just getting
there?


Reading this thread while going through the online D book I wonder;
Would one recommend D for gamedev? I was thinking of writing small games
with the help of SFML to learn D better and try to get better at
programming game logic(DLang is my second programming language).


Well, I wouldn't be working on[0] and [1] if I didn't think D could be 
used for game dev. Yes it has some work to do to make it nice, but over 
all its workable.


[0] http://spew.cf
[1] https://github.com/rikkimax/ogl_gen

Re: "I made a game using Rust"

[evilrat via Digitalmars-d]

On Wednesday, 10 May 2017 at 22:13:29 UTC, Lewis wrote:

On Wednesday, 10 May 2017 at 12:52:34 UTC, JN wrote:

PROS


The Rust article mentions build times as a downside. In 
contrast, that has been one of the upsides of D for me. My 
build time is ~1.75s for a usual-case rebuild (all the game 
files), and ~4.5s for a full rebuild (the game, plus all heavy 
templates (like regexes), and all library glue code (like 
derelict)). Rapid build times are one of the killer features of 
DMD, and it makes me happy to know it will continue to be a 
focus as development continues.


I have played recently with one D game engine and result was 
frustrating. My compile time was about 45 sec! Engine split in 
core and actual game module, every time i build game module it 
recompiles the engine. Great compile times, yay! The engine 
itself is just ~12k LOC, "game" roughly 200 lines. For example 
UE4 project with same line count compiles within 50 secs! Of 
cource whole D engine takes just 20 secs on single core, while 
C++ project takes all my 8 cores. (and for example building whole 
UE4 takes almost hour on SSD)


Every changed line of code triggers full rebuild in D (remember, 
it does this twice, one for engine, second for game). As C++ user 
I find it unacceptable, simply because with PCH such changes is 
usually takes 2-3 secs if one don't touch the headers (well okay, 
more like 10 secs, still twice faster than D on edit-build-debug 
runs).





CONS

The debugger. Rainers is doing great work with Mago, I suspect 
it simply needs more developers giving it some love. It's 
currently a far cry from the MSVC debugger.


There is no sane x64 debugging on Windows. structs doesn't shows 
at all, that just top of the list... But I remember what's was 
back in 2011, now we at least can do full debug for x86! And last 
time I used OS X(in 2013) that was... well I prefer not to 
comment, there was simply no debugging at all.



DLL support. I've made a handful of hacks to druntime to allow 
me to implement hot-reloading via a DLL (a la Handmade Hero). 
My problems all stem from the fact that a D DLL has its own 
copy of the runtime and GC. I use the GC proxy to redirect 
calls from the DLL's GC to the EXE's GC, and have hacked 
together a similar solution for redirecting the spawning of 
threads. On top of that I had to completely disable finalizers, 
and pretty much avoid using classes altogether (at least any 
that might need to outlive a frame or survive a hot reload). 
I'll bet it's no easy task to implement, but if D supported 
"light" DLLs (ie DLLs that just work out of the executable's 
druntime), probably 2/3 my hacks to
D would evaporate. This all being said, the hot reloading works 
marvellously with these changes, and it combined with a <2s 
build time makes day-to-day development far more of a joy than 
at work.


How did you managed using classes from DLL? I mean in its current 
state D unable to cast anything that comes through process/shared 
lib boundaries(except on Linux) due to missing type info, right?
And this is serious issue, this is really blocks D from 
commercial usage, simply because there is no way to add plugin 
support (from user's point of view).


And realistically this is also not so trivial, this requires 
making special 'core' library with common classes and interfaces 
to include in every DLL and app itself, because one would need to 
use both .d and compiled module .obj (for type info, that 
annoying unresolved _ClassZ and others) and current build systems 
doesn't helps with that all, so all by hand it seems...



Overall, I really like D, but its like feeding on cactus...

Re: DIP 1007 Preliminary Review Round 1

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/10/2017 09:51 PM, Nick Sabalausky (Abscissa) wrote:

This is what FQNs are for. At least, it was before FQNs were broken,
first by an incomplete "package.d" system and second by a goofy
half-baked change to import rules.

FQNs need fixed. This DIP is just a questionable workaround for our
borked FQNs that that smacks of C++-style "no breakage at all costs"
design philosophies being applied to both D language and D libraries.


I guess that's my overview. More specifically, what I mean is this:

D's system of fully-qualified names ("FQNs") was intended to address the 
matter of conflicting symbols: When a symbol name is ambiguous, instead 
of blindly choosing one, the compiler errors and forces the programmer 
to clarify.


For this DIP to be convincing, I would need to see this DIP address the 
following:


1. Why it would be insufficient to simply rely on D's system of FQNs (if 
fixed from their current admittedly half-broken state)? Currently, FQNs 
are not addressed, or even mentioned at all, in the "Existing solutions" 
section.


2. Why having to disambiguate a symbol with a FQN when upgrading a 
library is a sufficiently large problem to justify a new language 
feature. (This would seem very difficult to justify, since with or 
without this DIP, programmer will be informed by the compiler either way 
that they need to disambiguate which symbol they want).


Aside from FQNs, I have additional concerns:

3. Can we even except a library's author to *reliably* know ahead of 
time they're going to add a symbol with a particular name? Seems to me a 
library author would need a magic crystal ball to make effective use of 
this feature...


4. Unless...once they've developed a new version of their lib that's 
sufficiently close to release that they know that their API changes 
won't...umm...change any further, then they retroactively create an 
interim "transition" release which adds these "future" declarations...so 
that the programmer knows they need to adjust their code to 
disambiguate. But again, as in #2, the programmer will be told that 
*anyway* when compiling with the new version. So what's the point?


5. Once the programmer *is* informed they need to disambiguate a symbol 
(via this DIP or via a normal ambiguous symbol error), it's an 
inherently trivial (and inherently backwards-compatible) fix (which 
can't always be said of fixing removed-symbol deprecations - as this DIP 
tries to draw parallels to). So, unlike deprecated symbols, I fail to 
see what non-trivial benefit is to be gained by an "early notification" 
of a to-be-added symbol.


I think this DIP would have merit in a language that had a tendency for 
symbols to hijack each other. But D's module system already eliminates 
that, so AFAICT, the only thing this DIP is left "improving" is to allow 
lib authors, only under very select circumstances, to go out of their 
way to provide ahead-of-time notice of a guaranteed-trivial fix they 
must make (at least once FQNs are actually fixed). Therefore, I find the 
whole idea extremely unconvincing.

NetBSD amd64: which way is the best for supporting 80 bits real/double?

[Nikolay via Digitalmars-d]

I am porting LDC to NetBSD amd64, and I ask advice how to handle 
real type. NetBSD has limited support for this type. This type 
exists, but standard library does not provide full set of math 
functions for it (e.g. sinus, cosinus, and etc). Currently I just 
forward all function calls to 64 bits version counterparts, but 
in this case a set of unit tests are failing. I see following 
approaches to handle this issue:
   - Totally remove 80 bit real type from NetBSD port (make 
real==double)

   - Change tests and skip asserts for NetBSD

There is one additional approach: implement these functions in 
druntime, but it is too big/massive work for me.

Re: DIP 1007 Preliminary Review Round 1

[Nick Sabalausky (Abscissa) via Digitalmars-d]

This is what FQNs are for. At least, it was before FQNs were broken, 
first by an incomplete "package.d" system and second by a goofy 
half-baked change to import rules.


FQNs need fixed. This DIP is just a questionable workaround for our 
borked FQNs that that smacks of C++-style "no breakage at all costs" 
design philosophies being applied to both D language and D libraries.

Re: alloca without runtime?

[岩倉 澪 via Digitalmars-d-learn]

On Wednesday, 10 May 2017 at 20:25:45 UTC, aberba wrote:

On Thursday, 4 May 2017 at 14:54:58 UTC, 岩倉 澪 wrote:

On Thursday, 4 May 2017 at 12:50:02 UTC, Kagamin wrote:

You can try ldc and llvm intrinsics
http://llvm.org/docs/LangRef.html#alloca-instruction
http://llvm.org/docs/LangRef.html#llvm-stacksave-intrinsic


Ah, yep!

pragma(LDC_alloca) void* alloca(size_t);

This appears to work with ldc. It would be nice if there was a 
way to do this with dmd/other compilers as well though. If it 
were up to me I'd have alloca defined by the language standard 
and every compiler would have to provide an implementation 
like this. At the very least I'd like to have an alloca that 
works with dmd, as I want to do debug builds with dmd and 
release builds with ldc.


embedded platform?


An embedded platform would be a good use-case for this, but I'm 
just trying to do this on Linux x86_64 personally. It's a fun 
experiment to see how far I can push D to give me low-level 
control without dependencies

[Issue 16588] uniq's BidirectionalRange behavior is inconsistent with its InputRange behavior

[via Digitalmars-d-bugs]

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

greensunn...@gmail.com changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--

Re: DIP 1007 Preliminary Review Round 1

[Steven Schveighoffer via Digitalmars-d]

On 5/10/17 11:15 AM, Dicebot wrote:

On Tuesday, 25 April 2017 at 12:33:44 UTC, Steven Schveighoffer wrote:

Actually, that brings up a problem with this, what is the mechanism to
say "maybe override"? Let's say you have:

// in imported library
class Base
{
   void foo() @future;
}

// in user library
class Derived : Base
{
   void foo() {...} // triggers warning
}

What is the next step the user has to take to remove the deprecation
warning, but still have valid code?


Right now I have two possible approaches in mind.

One is to simply allow overriding `@future` symbol which doesn't require
any extra stuff but can be viewed sub-optimal because it couples two
loosely related concepts and would require special cases in how future
symbols are handled inside compiler (they stop being completely ephemeral).

Other would be an accompanying DIP to be able to specify
`overide(strict)` (default, same as plain `override`) vs
`override(optional)` to be able to define methods that may or may not
override base one, with no specific relation to `@future`.

I don't have any hard opinion on the matter of my own, what do you think?


I prefer the first one. The reason is simply because it doesn't require 
any new grammar. The override requirement is already a protection 
against changing base class. In this case, we have two possible outcomes:


1. The base class finally implements the method and removes future. In 
this case, the derived class continues to function as expected, 
overriding the new function.


2. The base class removes the method. In this case, the override now 
fails to compile. This is not as ideal, as this does not result in a 
version that will compile with two consecutive versions of the base. But 
there is a possible path for this too -- mark it as @deprecated @future :)


-Steve

Re: "I made a game using Rust"

[H. S. Teoh via Digitalmars-d]

On Wed, May 10, 2017 at 07:52:53PM -0400, Steven Schveighoffer via 
Digitalmars-d wrote:
[...]
> I'll reiterate here: if the compiler's sanity is suspect, there's nothing
> much for it to do except crash. hard. And tell you where to look.
[...]

OTOH, it's not very nice from a user's POV.  It would be nice(r) if this
PR could be looked at and brought to a mergeable state:

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


T

-- 
Programming is not just an act of telling a computer what to do: it is also an 
act of telling other programmers what you wished the computer to do. Both are 
important, and the latter deserves care. -- Andrew Morton

[Issue 16588] uniq's BidirectionalRange behavior is inconsistent with its InputRange behavior

[via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

[Issue 16588] uniq's BidirectionalRange behavior is inconsistent with its InputRange behavior

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||thecybersha...@gmail.com
 Resolution|FIXED   |---

--- Comment #5 from Vladimir Panteleev  ---
Reverted by https://github.com/dlang/phobos/pull/5384

--

[Issue 17264] [REG2.073] uniq fails with const elements

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/113502af744fb82d68e8f51fd73831b628dcc1eb
std.algorithm.iteration: Add test for issue 17264

Fixes Issue 17264 - [REG2.073] uniq fails with const elements

--

Re: "I made a game using Rust"

[Steven Schveighoffer via Digitalmars-d]

On 5/10/17 10:37 AM, Ethan Watson wrote:

On Wednesday, 10 May 2017 at 14:31:28 UTC, Vladimir Panteleev wrote:

Internal compiler errors (ICEs) are bugs which are generally treated
as high priority. Please report them.


See my previous rant on this subject.

http://forum.dlang.org/post/qkxyfiwjwqklftcwt...@forum.dlang.org


And my previous answer:

http://forum.dlang.org/post/nqc4tg$12im$1...@digitalmars.com

I'll reiterate here: if the compiler's sanity is suspect, there's 
nothing much for it to do except crash. hard. And tell you where to look.


Fortunately for the current state of affairs, if the error is in the 
front-end, it's D. And it should give you a stack trace.


Your previous example seems to be in C++ part of it, so no stack trace.

-Steve

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

[Jesse Phillips via Digitalmars-d-learn]

On Wednesday, 10 May 2017 at 22:20:52 UTC, 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

?


You can't really parse a CSV file line-by-line.

H.S. Teoh mentioned fastcsv but requires all the data to be in 
memory.


If you can get the zip to decompress into a range of dchar then 
std.csv will work with it. It is by far not the fastest, but much 
speed is lost since it supports input ranges and doesn't 
specialize on any other range type.

Re: concepts v0.0.6: use a run-time interface to specify a compile-time one

[Luís Marques via Digitalmars-d-announce]

On Wednesday, 10 May 2017 at 10:53:59 UTC, Atila Neves wrote:
concepts is a dub package and library that allows one to 
declare that a struct conforms to a "compile-time interface" 
such as `isInputRange`.


Awesome!

Re: Kafka site needs to be updated with D modules

[Ali Çehreli via Digitalmars-d]

Ping...

On 04/28/2017 11:36 AM, Ali Çehreli wrote:

There are three D modules that I could identify that provide Kafka
bindings[1] by searching for "kafka" on the code registry:

  http://code.dlang.org/

Could people in the know please update the Kafka site with necessary
information like what version of Kafka they support, etc.

Thank you,
Ali

[1] https://cwiki.apache.org/confluence/display/KAFKA/Clients

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

[Seb via Digitalmars-d-learn]

On Wednesday, 10 May 2017 at 23:19:15 UTC, H. S. Teoh wrote:
Also, if you need to parse lots of CSV data very fast, you 
might be interested in this:


https://github.com/quickfur/fastcsv


T


Or asdf: https://github.com/tamediadigital/asdf

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

[H. S. Teoh via Digitalmars-d-learn]

On Wed, May 10, 2017 at 11:17:44PM +, Nicholas Wilson via 
Digitalmars-d-learn wrote:
> On Wednesday, 10 May 2017 at 22:20:52 UTC, 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
> > 
> > ?
> 
> I suggest you take a look at Steven's iopipe (also watch his Dconf
> presentation). should be very simple.

Also, if you need to parse lots of CSV data very fast, you might be
interested in this:

https://github.com/quickfur/fastcsv


T

-- 
Just because you can, doesn't mean you should.

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

[Nicholas Wilson via Digitalmars-d-learn]

On Wednesday, 10 May 2017 at 22:20:52 UTC, 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

?


I suggest you take a look at Steven's iopipe (also watch his 
Dconf presentation). should be very simple.

[Issue 17391] SECURITY: XSS through DDOC comments

[via Digitalmars-d-bugs]

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

--- Comment #7 from Cédric Picard  ---
(In reply to Vladimir Panteleev from comment #5)
> (In reply to Cédric Picard from comment #4)
> > Not at all, while what you describe is the most common case there are many
> > things that are possible through XSS that do not target the current domain.
> 
> Could you provide some examples which would be applicable to us?

Well, I'm not sure this is the right place to talk about that, but it's an XSS,
it can do anything JS in a webpage can, so making external calls to APIs,
executing an IRC bot, delivering malware...

With some timing tricks it is also possible to scan the user's network for
available ports on local and nearby computers.

With a browser bug such as
https://www.brokenbrowser.com/sop-bypass-uxss-stealing-credentials-pretty-fast/
(taking one from today, those are pretty common) it's possible to bypass any
security tying the code to the local domain. From there you can get data from
other pages, read and send local files etc.

Anything a normal malicious webpage can do, this is in no way specific to D.

--

[Issue 16746] Please output Makefile-style depfiles for ninja and make

[via Digitalmars-d-bugs]

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

--- Comment #13 from Vladimir Panteleev  ---
(In reply to Matthias Klumpp from comment #12)
> Sounds really good, but AFAIK this is still in the far future...
> GDC supports writing depfiles properly, and having this feature in DMD would
> enable it for DMD and LDC at the same time, making depfiles work for all D
> compilers.

That's true.

> Usually in distributions we package just the minimal amount of things
> necessary to compile a certain leaf package (e.g. all the stuff one needs to
> compile Vibe.d/Tilix/...) and more is added when another package requires
> the feature.

That makes sense if you treat D purely as a dependency, but I think it's worth
looking at it as a software application package as well. rdmd is mentioned in
TDPL, so it is essentially part of D. This is why I'm uneasy about the idea of
splitting up the tools that dlang.org ships together.

> At the moment, nothing uses rdmd, and adding it would mean someone would
> need to maintain the package over the lifetime of the distro release.

Why a separate package? Why not ship it with dmd? Is it just because it's
useful not just for dmd, but also ldc/gdc? If so, why not have a dtools package
like Arch Linux, which includes rdmd, dustmite, ddemangle, etc.?

--

[Issue 16746] Please output Makefile-style depfiles for ninja and make

[via Digitalmars-d-bugs]

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

--- Comment #12 from Matthias Klumpp  ---
(In reply to Vladimir Panteleev from comment #11)
> (In reply to Matthias Klumpp from comment #10)
> > Because the wrapper is not available everywhere, and going through a wrapper
> > in order to fix a missing thing in dmd is just a workaround. DMD(FE) should
> > be able to do this natively.
> > When adding support to Meson/CMake/Automake/Makefiles, telling users that
> > they need the compiler but also this other tool which - in the Meson world -
> > has the sole purpose of supplying a missing functionality in DMD is pretty
> > cumbersome. It's a workaround, but no real solution to the issue.
> 
> I'm not sure about referring to a requested feature as "missing
> functionality", but thanks for the clarification.
> 
> Regardless, we will hopefully one day have rdmd as part of dmd itself, or
> use the compiler as a library, so duplicating functionality in both dmd and
> rdmd right now does not look very appealing; until then, you may want to
> look into more pragmatic solutions, such as using rdmd.

Sounds really good, but AFAIK this is still in the far future...
GDC supports writing depfiles properly, and having this feature in DMD would
enable it for DMD and LDC at the same time, making depfiles work for all D
compilers.

> > At the moment, Debian/Uhuntu/Fedora/OpenSUSE and probably a couple of other
> > don't ehip rdmd at all, which makes demanding it just to work around this
> > bug not worthwile anyway.
> 
> I think rdmd should be shipped in the same package as dmd. This is how the
> binary packages from dlang.org for all platforms are. Picking and choosing
> which utilities the distribution considers useful will inevitably lead to
> confusion and a poorer user experience.

Usually in distributions we package just the minimal amount of things necessary
to compile a certain leaf package (e.g. all the stuff one needs to compile
Vibe.d/Tilix/...) and more is added when another package requires the feature.
At the moment, nothing uses rdmd, and adding it would mean someone would need
to maintain the package over the lifetime of the distro release.

Personally I try to avoid taking on new packages on a "could be useful" basis,
because the time I can invest in maintenance is limited, and it's better to
have fewer well-supported packages than lots of them which are poorly
maintained.
(Team maintenance helps a lot with this, but only if the team is actually big
enough, which isn't the case in with D yet).

--

[Issue 16746] Please output Makefile-style depfiles for ninja and make

[via Digitalmars-d-bugs]

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

--- Comment #11 from Vladimir Panteleev  ---
(In reply to Matthias Klumpp from comment #10)
> Because the wrapper is not available everywhere, and going through a wrapper
> in order to fix a missing thing in dmd is just a workaround. DMD(FE) should
> be able to do this natively.
> When adding support to Meson/CMake/Automake/Makefiles, telling users that
> they need the compiler but also this other tool which - in the Meson world -
> has the sole purpose of supplying a missing functionality in DMD is pretty
> cumbersome. It's a workaround, but no real solution to the issue.

I'm not sure about referring to a requested feature as "missing functionality",
but thanks for the clarification.

Regardless, we will hopefully one day have rdmd as part of dmd itself, or use
the compiler as a library, so duplicating functionality in both dmd and rdmd
right now does not look very appealing; until then, you may want to look into
more pragmatic solutions, such as using rdmd.

> At the moment, Debian/Uhuntu/Fedora/OpenSUSE and probably a couple of other
> don't ehip rdmd at all, which makes demanding it just to work around this
> bug not worthwile anyway.

I think rdmd should be shipped in the same package as dmd. This is how the
binary packages from dlang.org for all platforms are. Picking and choosing
which utilities the distribution considers useful will inevitably lead to
confusion and a poorer user experience.

--

[Issue 16746] Please output Makefile-style depfiles for ninja and make

[via Digitalmars-d-bugs]

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

--- Comment #10 from Matthias Klumpp  ---
(In reply to Vladimir Panteleev from comment #9)
> (In reply to Matthias Klumpp from comment #8)
> > Yes, it doesn't support all command-line flags one would use with ldc, gdc
> > or dmd.
> 
> rdmd simply forwards flags it doesn't recognize to the compiler.
> 
> > Any wrapper is not an option.
> 
> Why?

Because the wrapper is not available everywhere, and going through a wrapper in
order to fix a missing thing in dmd is just a workaround. DMD(FE) should be
able to do this natively.
When adding support to Meson/CMake/Automake/Makefiles, telling users that they
need the compiler but also this other tool which - in the Meson world - has the
sole purpose of supplying a missing functionality in DMD is pretty cumbersome.
It's a workaround, but no real solution to the issue.

At the moment, Debian/Uhuntu/Fedora/OpenSUSE and probably a couple of other
don't ehip rdmd at all, which makes demanding it just to work around this bug
not worthwile anyway.

--

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

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

[Nordlöw via Digitalmars-d-learn]

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

?

Re: "I made a game using Rust"

[Lewis via Digitalmars-d]

On Wednesday, 10 May 2017 at 12:52:34 UTC, JN wrote:
I wonder, would it be possible for D in the current state to 
achieve the same? I imagine iOS isn't possible yet and Android 
is just getting there?


I've been developing a small 2D PC-only game in my free time over 
the last year or so (10 kLOC so far). It's very much still in the 
early stages, but I'll add some of my experiences here in case 
it's useful.


For context, I'm a developer of 2.5 years at a medium-sized 
studio that ships full-price games. At work we use C++ (msvc) for 
the engine, Lua for scripting, and C# for tools.


TLDR: You can totally make a game in D right now. However, it's 
definitely not ideal. Be ready to deal with untested 
tools/libraries, wrangling with how you call out to C libraries, 
and a couple hacks to the D source to make things work the way 
you want.



PROS

I'll skim this section, because you all know the pros of D at 
this point :) No header files, sane templates, way better 
introspection, the list goes on. D is one of the nicest 
programming languages I've had the pleasure of working in. It's 
not without its faults, but my experience so far is that it's the 
language I most want to be developing a game in right now. We'll 
see if Jai might take that throne some day, but I reserve 
judgement until I can actually get my hands on it, and even that 
might still be years out.


The Rust article mentions build times as a downside. In contrast, 
that has been one of the upsides of D for me. My build time is 
~1.75s for a usual-case rebuild (all the game files), and ~4.5s 
for a full rebuild (the game, plus all heavy templates (like 
regexes), and all library glue code (like derelict)). Rapid build 
times are one of the killer features of DMD, and it makes me 
happy to know it will continue to be a focus as development 
continues.



CONS

The debugger. Rainers is doing great work with Mago, I suspect it 
simply needs more developers giving it some love. It's currently 
a far cry from the MSVC debugger. Mago crashes/hangs regularly 
for me, doesn't step in and out of functions consistently (and 
you can't reposition the instruction pointer by dragging if you 
miss a function call you want to re-run), is inconsistant about 
which variables I can see and which I can't, and lacks features I 
miss greatly (like data breakpoints). This is *by far* my biggest 
pain point. I'd like to look at it at some point and try to 
improve some of the low-hanging fruit, but debugging a debugger 
is a daunting proposition.


DLL support. I've made a handful of hacks to druntime to allow me 
to implement hot-reloading via a DLL (a la Handmade Hero). My 
problems all stem from the fact that a D DLL has its own copy of 
the runtime and GC. I use the GC proxy to redirect calls from the 
DLL's GC to the EXE's GC, and have hacked together a similar 
solution for redirecting the spawning of threads. On top of that 
I had to completely disable finalizers, and pretty much avoid 
using classes altogether (at least any that might need to outlive 
a frame or survive a hot reload). I'll bet it's no easy task to 
implement, but if D supported "light" DLLs (ie DLLs that just 
work out of the executable's druntime), probably 2/3 my hacks to
D would evaporate. This all being said, the hot reloading works 
marvellously with these changes, and it combined with a <2s build 
time makes day-to-day development far more of a joy than at work.


The GC. This is an issue in games for reasons already tread many 
times over. It's lower on my list because it's relatively 
straightforward for me to intercept GC calls and do my own memory 
management instead. I've hacked in a setup that lets me swap 
allocators at runtime. For example, I can add a line at the top 
of a scope that says "for the duration of this scope, allocate 
into the scrapheap" (a bump-the-pointer stack that gets wiped at 
the end of each frame). I currently use the GC by default, and 
manually specify an allocator to use anywhere I'm generating 
excessive garbage, but this strategy will likely change as 
development continues and performance constraints start becoming 
more strict.


Library support. Basically the same as mentioned in the Rust 
article. I regularly try out libraries where I find a critical 
bug within an hour of using the library. I've used libraries 
(plural) that interface to C but use the wrong calling 
convention, so before I discovered the problem, every function I 
called was a crapshoot as to whether or not some subtle 
misbehaviour or outright crash would occur.


For reference, the libraries I'm using are:

- SFML (graphics/windowing, misc utilities)
- FMOD (audio)
- dear imgui (debug UI)
- msgpack-d (save game/state serialization)
- OpenGL (just tiny bits here and there for stuff SFML and imgui 
don't handle out of the box)
- speech4d (TTS for placeholder dialogue, I heavily modified this 
library to fix some critical bugs and make it work better for my 
purposes)

[Issue 17391] SECURITY: XSS through DDOC comments

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #6 from Vladimir Panteleev  ---
https://github.com/dlang/dlang.org/pull/1649

--

Re: Error writing file a *.obj

[Stanislav Blinov via Digitalmars-d-learn]

On Tuesday, 9 May 2017 at 14:08:48 UTC, bachmeier wrote:

On Tuesday, 9 May 2017 at 02:33:06 UTC, dummy wrote:

On Monday, 8 May 2017 at 12:29:27 UTC, bachmeier wrote:

On Monday, 8 May 2017 at 11:56:10 UTC, dummy wrote:


When i build some application with dub, i got this error:


I'm not a Dub user, but it has its own forum, so you might 
want to try there:

http://forum.rejectedsoftware.com/


Oh, i solve this problem my self...
because, the 'Ransomeware Protection' feature of Bitdefender 
InternetSecurity 2017.

dub and dmd working pretty when i turn off this feature.

Very sorry for noob question :/


This is not really a noob question. Since it affects new users 
trying to run a Hello World program, I wonder if it would be 
worthwhile to add that information to the error message. Most 
of the people trying out D will simply give up and blame the 
language.


It's not. It's not the job of the linker to go rummaging through 
all user's processes to find out which one is locking the file, 
even if it's possible.
What could be improved is the clarity, i.e. "Could not write the 
file due to it being locked for writing/lack of space on 
device/etc.".

[Issue 17391] SECURITY: XSS through DDOC comments

[via Digitalmars-d-bugs]

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

--- Comment #5 from Vladimir Panteleev  ---
(In reply to Cédric Picard from comment #4)
> Not at all, while what you describe is the most common case there are many
> things that are possible through XSS that do not target the current domain.

Could you provide some examples which would be applicable to us?

> Given how DDOC
> works I don't think it is fixable at all if not dropping all support for
> inlined html which I didn't realize was an issue at the time.
> 
> I suppose it's a won't fix, at least a bug report will be there for the next
> person to discover this.

Yep, I think documenting this is the immediate fix.

--

Re: How to avoid throwing an exceptions for a built-in function?

[Ali Çehreli via Digitalmars-d-learn]

On 05/10/2017 05:40 AM, k-five wrote:
> I have a line of code that uses "to" function in std.conv for a purpose
> like:
>
> int index = to!int( user_apply[ 4 ] ); // string to int
>
> When the user_apply[ 4 ] has value, there is no problem; but when it is
> empty: ""
> it throws an ConvException exception and I want to avoid this exception.
>
> currently I have to use a dummy catch:
> try{
> index = to!int( user_apply[ 4 ] );
> } catch( ConvException conv_error ){
> // nothing
> }

Are you really fine with 'index' being left with its previous value? If 
so, you can write a function like the following:


void setMaybe(To, From)(ref To var, From from) {
import std.conv : to, ConvException;
try {
var = to!To(from);
} catch( ConvException conv_error ) {
}
}

unittest {
int index = 41;
index.setMaybe("42");
assert(index == 42);
index.setMaybe("forty three");
assert(index == 42);
index.setMaybe("");
assert(index == 42);
}

void main() {
}

If you want the variable to be set to a default value (perhaps .init), 
then here is an idea:


void setMaybe(To, From)(ref To var, From from, To def = To.init) {
import std.conv : to, ConvException;
try {
var = to!To(from);
} catch( ConvException conv_error ) {
var = def;
}
}

unittest {
int index = 41;
index.setMaybe("42");
assert(index == 42);

index.setMaybe("forty three");
assert(index == 0);

index.setMaybe(7);
index.setMaybe("", 8);
assert(index == 8);
}

void main() {
}

Ali

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

[Seb via Digitalmars-d]

On Wednesday, 10 May 2017 at 21:29:24 UTC, Laeeth Isharc wrote:

On Wednesday, 10 May 2017 at 16:20:24 UTC, Seb wrote:

On Wednesday, 10 May 2017 at 11:51:03 UTC, Atila Neves wrote:
I'm using Trusty, and that works. But... it's a matter of 
time before most people are on newer versions of everything 
and dmd won't be buildable on Linux.


Maybe add newer distros on the autotester?


Hehe, that's nearly not possible. Since a couple of months 
there's an ongoing effort to change the directory layout to 
src/ddmd, which is been blocked by necessary changes the 
autotester.
Travis doesn't support newer distros easily as well, but e.g. 
CircleCi 2 does as they have native integration with Docker:


https://docs.travis-ci.com/user/docker/

Atila can give you our Arch builder builder script if it's 
helpful.


Thanks a lot for the info, but unfortunately the DMD repo already 
overuses Travis's free contingent of five parallel jobs per 
organization - that's why during DConf the slides sometimes 
weren't deployed immediately (dconf.org belongs to the dlang 
organization and thus is affected by this limit).
Moreover, there are already several tricks in place to reduce the 
time of the test suite to avoid running for more than 60 minutes 
and thus into termination. Sadly, this still happens from time to 
time for macOS.
Lastly, the Dlang-Bot has to actively cancel previous builds on 
new pushes to keep the build queue slim.
Hence, such experiments, which are very welcome, are probably 
better done on a different CI provider ;-)

[Issue 17391] SECURITY: XSS through DDOC comments

[via Digitalmars-d-bugs]

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

--- Comment #4 from Cédric Picard  ---
(In reply to Vladimir Panteleev from comment #3)
> As I understand, this only matters from a security standpoint when DDoc
> output is placed on the same domain as some dynamic content being targeted.

Not at all, while what you describe is the most common case there are many
things that are possible through XSS that do not target the current domain.
Also bugs in browsers are a common thing.

> > Limiting the use to some tags would help the usability issue but not the
> > security one.
> 
> As I understand, there is no usability issue here because it's working as
> designed. Use $(LT) and $(GT) (or  and  if you don't care about any
> output formats other than HTML) for < and >.

Well, I first discovered the thing because I hit it. But sure, if it's as
designed, no comment here.

> Anyway, limiting the use of some tags probably wouldn't work because the
> document template is likely to have some macros involving script tags (or
> allowing constructing aribitrary HTML tags, such as dlang.org's $(TAG)
> macro). Fixing it from this angle would be much more complicated.

Indeed, also there are much more subtle XSSs than 

Re: How to avoid throwing an exceptions for a built-in function?

[Andrei Alexandrescu via Digitalmars-d-learn]

On 5/10/17 3:40 PM, k-five wrote:
I have a line of code that uses "to" function in std.conv for a purpose 
like:


int index = to!int( user_apply[ 4 ] ); // string to int

When the user_apply[ 4 ] has value, there is no problem; but when it is 
empty: ""

it throws an ConvException exception and I want to avoid this exception.

currently I have to use a dummy catch:
try{
 index = to!int( user_apply[ 4 ] );
} catch( ConvException conv_error ){
 // nothing
}

I no need to handle that, so is there any way to prevent this exception?


Use the "parse" family: https://dlang.org/phobos/std_conv.html#parse -- 
Andrei

Re: How to avoid throwing an exceptions for a built-in function?

[Moritz Maxeiner via Digitalmars-d-learn]

On Wednesday, 10 May 2017 at 21:19:21 UTC, Stanislav Blinov wrote:
"nothrow" does not turn off exceptions, it simply forbids 
throwing them in the enclosing scope (i.e. calling anything 
that might throw is not allowed).


nothrow disallows the function scope to throw exceptions not 
derived from core.object.Error. It makes no claim about what 
happens *inside* the scope; you can throw as much as you want 
inside nothrow, as long as you take care to catch anything that's 
not a core.object.Error (which is what 
std.exception.assumeWontThrow essentially does).

Re: Error writing file a *.obj

[Jesse Phillips via Digitalmars-d-learn]

On Tuesday, 9 May 2017 at 02:33:06 UTC, dummy wrote:

On Monday, 8 May 2017 at 12:29:27 UTC, bachmeier wrote:

On Monday, 8 May 2017 at 11:56:10 UTC, dummy wrote:


When i build some application with dub, i got this error:


I'm not a Dub user, but it has its own forum, so you might 
want to try there:

http://forum.rejectedsoftware.com/


Oh, i solve this problem my self...
because, the 'Ransomeware Protection' feature of Bitdefender 
InternetSecurity 2017.

dub and dmd working pretty when i turn off this feature.

Very sorry for noob question :/


Not at all, I got hit by Bitdefender when upgrading the compiler 
and took a while to find why my files weren't extracting. I 
submitted the DMD zip to them to fix it since I couldn't submit 
the files the AV was deleting. Definitely submit your 
executables/libs/objects.


https://www.bitdefender.com/submit/

[Issue 17391] SECURITY: XSS through DDOC comments

[via Digitalmars-d-bugs]

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

--- Comment #3 from Vladimir Panteleev  ---
(In reply to Cédric Picard from comment #2)
> I was not aware that it is so by design. However if it is a design decision
> I believe the security consequences should be made very explicit and clear
> in DDOC's documentation so that people avoid distributing third-party
> projects' documentation or do it very carefuly.

As I understand, this only matters from a security standpoint when DDoc output
is placed on the same domain as some dynamic content being targeted.

> Limiting the use to some tags would help the usability issue but not the
> security one.

As I understand, there is no usability issue here because it's working as
designed. Use $(LT) and $(GT) (or  and  if you don't care about any
output formats other than HTML) for < and >.

Anyway, limiting the use of some tags probably wouldn't work because the
document template is likely to have some macros involving script tags (or
allowing constructing aribitrary HTML tags, such as dlang.org's $(TAG) macro).
Fixing it from this angle would be much more complicated.

--

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

[Laeeth Isharc via Digitalmars-d]

On Wednesday, 10 May 2017 at 16:20:24 UTC, Seb wrote:

On Wednesday, 10 May 2017 at 11:51:03 UTC, Atila Neves wrote:
I'm using Trusty, and that works. But... it's a matter of time 
before most people are on newer versions of everything and dmd 
won't be buildable on Linux.


Maybe add newer distros on the autotester?


Hehe, that's nearly not possible. Since a couple of months 
there's an ongoing effort to change the directory layout to 
src/ddmd, which is been blocked by necessary changes the 
autotester.
Travis doesn't support newer distros easily as well, but e.g. 
CircleCi 2 does as they have native integration with Docker:


https://docs.travis-ci.com/user/docker/

Atila can give you our Arch builder builder script if it's 
helpful.

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

[Laeeth Isharc via Digitalmars-d]

On Wednesday, 10 May 2017 at 16:20:24 UTC, 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

So I went "I know, I'll just use a container". I tried Ubuntu 
Zesty in docker. That doesn't build dmd off the bat either, it 
fails with PIC errors.


AFAIK this bug should have been fixed. However, IIRC 2.073.2 or 
2.074 as host compiler is required.


I'm using Trusty, and that works. But... it's a matter of time 
before most people are on newer versions of everything and dmd 
won't be buildable on Linux.


Maybe add newer distros on the autotester?


Hehe, that's nearly not possible. Since a couple of months 
there's an ongoing effort to change the directory layout to 
src/ddmd, which is been blocked by necessary changes the 
autotester.
Travis doesn't support newer distros easily as well, but e.g. 
CircleCi 2 does as they have native integration with Docker:


https://circleci.com/blog/say-hello-to-circleci-2-0/
https://circleci.com/docs/2.0/

PRs are welcome ;-)


Atila


Hi Seb.

Travis CI commercial does work with Docker - I think we used it 
before and Atila would know about that.  We build the builder 
binary image using Arch pacstrap and then run that binary 
container using Docker.  I don't know if Travis open source 
allows Docker, but if not it's probably a matter of time.


Laeeth.

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

[Stanislav Blinov via Digitalmars-d]

On Wednesday, 10 May 2017 at 21:03:30 UTC, 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?


What, in half a year or more? :) I'd say we're safe.

[Issue 17391] SECURITY: XSS through DDOC comments

[via Digitalmars-d-bugs]

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

--- Comment #2 from Cédric Picard  ---
I was not aware that it is so by design. However if it is a design decision I
believe the security consequences should be made very explicit and clear in
DDOC's documentation so that people avoid distributing third-party projects'
documentation or do it very carefuly.

Limiting the use to some tags would help the usability issue but not the
security one.

--

Re: How to avoid throwing an exceptions for a built-in function?

[Stanislav Blinov via Digitalmars-d-learn]

On Wednesday, 10 May 2017 at 15:35:24 UTC, k-five wrote:
On Wednesday, 10 May 2017 at 14:27:46 UTC, Stanislav Blinov 
wrote:

On Wednesday, 10 May 2017 at 13:27:17 UTC, k-five wrote:

Thanks, but I know about what are you saying. The 
user_apply[4] has so many possibilities and I cannot use 
if-else


That doesn't sound right. Either you've already handled all 
the possible cases and thus expect the to! to not throw (can 
specify that i.e. via std.exception.assumeWontThrow), or, as 
you're saying, it's much more than an if-else, but in that 
case exception will be thrown on invalid input.


--

I know. But I am saying that I do not want to take care of any 
exceptions.

I just wanted to write:

int variable = to!int( string-type );

In fact something like using "no throw" is a function:
void init( ... ) nothrow {
...
int variable = to!int( string-type );
...
}

but this is not valid.

Thanks anyway and I will test: Function 
std.exception.assumeWontThrow at this link:

https://dlang.org/library/std/exception/assume_wont_throw.html


I don't understand. If you don't want to take care of exceptions, 
then you just don't do anything, simply call to!int(str). If an 
exception is thrown, it'll propagate further up the stack, until 
you either handle it or abort the program. "nothrow" does not 
turn off exceptions, it simply forbids throwing them in the 
enclosing scope (i.e. calling anything that might throw is not 
allowed).
Or do you mean that you've already made sure that the user input 
is valid such that to!int() will never throw with it? In that 
case, yes, assumeWontThrow is a way to express that. But then, 
the only way you can be sure of that is if you've already parsed 
the input yourself, so I'm not clear on the intent.
Alternatively, if what you're calling still might throw but you 
don't want to deal with try/catch blocks, there's 
collectException function in std.exception that'll give you the 
exception if it was thrown and let you deal with it without using 
try/catch.

[Issue 17391] SECURITY: XSS through DDOC comments

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #1 from Vladimir Panteleev  ---
Hmm... DDoc allows embedding HTML "by design", so this is not a bug. 

It might be an issue for websites which display documentation of third-party
packages though.

Perhaps it would make sense to forbid certain HTML tags in .d files (i.e.
inline documentation comments and the "Macros" section), while still allowing
them in macro definitions in .ddoc files.

--

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

[Marco Leise via Digitalmars-d]

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?

-- 
Marco

[Issue 17391] New: SECURITY: XSS through DDOC comments

[via Digitalmars-d-bugs]

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

  Issue ID: 17391
   Summary: SECURITY: XSS through DDOC comments
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: cpic...@openmailbox.org

DDOC comments are not escaped and this results in a XSS vulnerability.

Proof of concept:

test.d:

/// alert(2)
void f() {
return;
}

$ dmd -D test.d
$ firefox test.html  -> an alert box appears

The security issue is clear although it requires manipulating the user to
compile and display malicious comments. But as compiling the documentation is
something many do before thoroughly reading the code it's still a valid
security issue.

Also, aside from that, it breaks valid documentation so there's a usability
issue as well.

--

Re: alloca without runtime?

[aberba via Digitalmars-d-learn]

On Thursday, 4 May 2017 at 14:54:58 UTC, 岩倉 澪 wrote:

On Thursday, 4 May 2017 at 12:50:02 UTC, Kagamin wrote:

You can try ldc and llvm intrinsics
http://llvm.org/docs/LangRef.html#alloca-instruction
http://llvm.org/docs/LangRef.html#llvm-stacksave-intrinsic


Ah, yep!

pragma(LDC_alloca) void* alloca(size_t);

This appears to work with ldc. It would be nice if there was a 
way to do this with dmd/other compilers as well though. If it 
were up to me I'd have alloca defined by the language standard 
and every compiler would have to provide an implementation like 
this. At the very least I'd like to have an alloca that works 
with dmd, as I want to do debug builds with dmd and release 
builds with ldc.


embedded platform?

Re: Productive vibe.d dev environment (IDE, debugger) on Linux?

[aberba via Digitalmars-d-learn]

On Wednesday, 3 May 2017 at 17:43:07 UTC, kinke wrote:

Hey guys,

can anyone recommend a more or less production-ready dev 
environment for vibe.d on Linux?
I'm evaluating vibe.d against Phoenix (Elixir/Erlang) for a new 
project. Today I gave Visual Studio Code a quick shot (with LDC 
1.1.1 and DMD 2.071/72/74), with Webfreak's plugins, but I'm 
not happy at all (gdb/lldb crashing most of the time incl. 
debugged process, no AutoComplete/IntelliSense due to problems 
when building some of the plugin dependencies etc.).


Any hints are greatly appreciated, as I'm really impressed by 
vibe.d itself so far.


I use sublime on ubuntu with D plugins. No phobos or vibe.d 
autocompletion though. I ok with it for now.


I was using php but vibe.d and D are more productive and capable 
plus phobos has useful stuff in it. DaemonizeD package is also 
very handy.

Re: The cost of doing compile time introspection

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 10 May 2017 at 14:03:58 UTC, Biotronic wrote:
On Wednesday, 10 May 2017 at 11:45:05 UTC, Moritz Maxeiner 
wrote:

[CTFE slow]

First, as you may know, Stefan Koch is working on an improved 
CTFE engine that will hopefully make things a lot better.


As he already pointed out, it won't help with the introspection 
template costs, though.




As for making the code faster right now, could this be done 
with mixin templates instead?


Something like:

[...]


This will move from CTFE to templates, sure, but templates aren't 
that fast, either.
I'll experiment with your suggestion regardless to see what it'll 
result in, but I'm not very optimistic about that solving the 
issue.




(tests indicate this compiles but doesn't run, and I'm helping 
you on company time, so I can't fix everything right now :p)




Thank you, I'll gladly take any advice and try to optimize 
things, though my primary purpose with this post was not to ask 
for help (for once :p ), but to publicize my experience with 
compile time introspection costs as a reference for others (and 
because a certain someone asked me too - you know who you are).





[...]


A few things here - functions.fn would not do what you want, 
and neither would __traits(identifier).
functions.fn would treat "fn" like a part of name, not a string 
value, so this will make the poor compiler barf.
__traits(identifier, fn) expects fn to be a symbol, while here 
it's a string. In fact, it's exactly the string you want 
__traits to return.
Lastly, you'll still need a mixin, whether it's for 
__traits(identifier, fn) or just fn - they're just strings.


Right, but it'll still be one fairly short, readable line in the 
end (that should be faster than CTFE).

Re: DConf 2017 Hackathon report

[David Nadlinger via Digitalmars-d]

On Wednesday, 10 May 2017 at 19:46:01 UTC, Joseph Rushton 
Wakeling wrote:
Ironically, given that I'd always been worried this would be 
the most finnicky compiler snap to create, it's actually the 
simplest package definition out of all the Big 3 ;-)


Without even having seen your snap file, I can confidently say 
that this is just due to the idiosyncrasies of the snap 
environment, though.


Oh wait, no, GDC is still stuck on an ancient C++-based frontend. 
Not too surprising, then. ;P


 — David

Re: Problems with Array Assignment?

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 10 May 2017 at 17:26:09 UTC, Samwise wrote:
I wondered about that when I did it, but I assumed (wrongly) 
that since the name of the array was the same, it would 
override it.


Nope, this is a somewhat common mistake coming from Python users, 
but it can't work that way in D since it would break static type 
guarantees - even if D did allow overriding variables, it would 
actually still flag your code as an error (try changing to a 
property getter, then you can override it, and you'll see it is 
an error).


So what happens here is the child class just adds a new variable. 
You can access them individually through 
`yourvar.ClassName.tiles` - parent and child accessible but 
separate. In the child class though, `this` automatically binds 
to the most-local variable.


A similar thing is this:

class Foo {
   int a;
   this(int a) {
  a = a; // will compile but does nothing
   }
}

Inside that constructor, `a` refers to the local parameter, not 
the class member. So you'd have to write `this.a = a;` to assign 
it.


(this is a FAQ too, so if you ever see a null that you could 
swear you initialized, this kind of mistake is usually the 
problem!)



But same deal with child class members. Local ones can have the 
same name but are separate.




Now, why would it be an error if it were allowed, like in the 
case of the property? It is because the base class can add ANY 
subclass of Tile, but the derived one assumes theya re all CTile:


Derived derived = new Derived();
Base base = derived; // allowed, now goes through base class 
interface


base.tiles ~= new OtherDerived(); // allowed, OtherDerived still 
comes from the same base class...


CTile = derived.tiles[0]; // uh oh, it is actually OtherDerived, 
not CTile!!!




In Python, since it is dynamically typed anyway, you don't have 
to worry about this as much, but in D since the base interface 
must still be usable, it would let you sidestep the child 
constraint entirely.






I'm probably not explaining this well, but you can read about the 
same principle from Java sources like this Wikipedia link:


https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)#Arrays

D works the same way for the same reasons.

Just to clarify, you can use a superclass variable to reference 
a member of a subclass? That seems to be what's happening.


Only if it is a virtual method. What's really happening here is 
that superclass and subclass have their own tiles arrays so you 
override the function but not the member and the data gets split 
up.


tbh I kinda wish D would just call it an error to prevent the 
confusion.

Re: Fantastic exchange from DConf

[Atila Neves via Digitalmars-d]

On Wednesday, 10 May 2017 at 18:58:35 UTC, H. S. Teoh wrote:
On Wed, May 10, 2017 at 11:16:57AM +, Atila Neves via 
Digitalmars-d wrote: [...]

[...]


Very nice!  Reminds me of an incident many years ago where I 
"optimized" a shell script that took >2 days to generate a 
report by rewriting it Perl, which produced the report in 2 
mins. (Don't ask why somebody thought it was a good idea to 
write a report generation script as a *shell script*, of all 
things. You really do not want to know.)


[...]



Hmm. What would giving them D be equivalent to, then? :-D


I'm not sure! If I knew you were going to ask that I'd probably 
have picked a different analogy ;)


Atila

Re: DConf 2017 Hackathon report

[Joseph Rushton Wakeling via Digitalmars-d]

On Tuesday, 9 May 2017 at 04:35:40 UTC, Ali Çehreli wrote:
Please list what we've achieved during the hackathon, including 
what is started but is likely to be finished in the coming days 
or months.


Created a working snap package definition for GDC.  I'm 
coordinating with Iain on how to get this into the snap store 
most effectively (having spent a fair bit of the hackathon 
pestering him with questions about the GDC build procedure:-).


Ironically, given that I'd always been worried this would be the 
most finnicky compiler snap to create, it's actually the simplest 
package definition out of all the Big 3 ;-)


I also had a play with using the new `scope return` etc. 
functionality to prototype a safe design for random algorithms 
that wrap a pointer to an RNG.  That's probably going to take a 
while longer to put together, as I've run into some issues that I 
really need to reduce to a very simple test case.

Re: Static foreach pull request

[Stefan Koch via Digitalmars-d]

On Wednesday, 10 May 2017 at 18:41:30 UTC, Timon Gehr wrote:

On 10.05.2017 16:21, Stefan Koch wrote:

On Wednesday, 10 May 2017 at 14:13:09 UTC, Timon Gehr wrote:

On 10.05.2017 15:18, Stefan Koch wrote:


if you try assert([] is null), it should fail.


It doesn't. I have tried to make that point before, 
unsuccessfully.
Empty arrays may or may not be null, but the empty array 
literal is

always null.

cat t3.d 
static assert([] is null);
---
dmd t.d -c ---
t3.d(1): Error: static assert  ([] is null) is false



void main(){
import std.stdio;
enum x = [] is null;
auto y = [] is null;
writeln(x," ",y); // "false true"
}


Oh fudge.
Another case where the ctfe-engine goes the right way;
And the runtime version does not ... we should fix this one of 
these days.

Re: Simulating reference variables using `alias this`

[Carl Sturtivant via Digitalmars-d]

On Wednesday, 10 May 2017 at 17:48:53 UTC, MrSmith wrote:
On Wednesday, 10 May 2017 at 17:12:11 UTC, Carl Sturtivant 
wrote:
Here's the beginning of an interesting little experiment to 
simulate reference variables using `alias this` to disguise a 
pointer as a reference. Could add a destructor to set the 
pointer to null when a reference goes out of scope.

...


I've used this code for similar purpose:

alias TextEditorSettingsRef = TextEditorSettings*;
alias TextEditorSettingsConstRef = const(TextEditorSettings)*;
struct TextEditorSettings
{}

But you need to have two aliases (templates) for const and 
non-const refs, since using:

const TextEditorSettingsRef editor;
does:
const(TextEditorSettings*)
not
const(TextEditorSettings)*

What do you think?


Works if you use new to get struct pointers. And . knows it's a 
pointer so you get the right effect. But I want to see if D can 
simulate general reference variables safely.

Re: Fantastic exchange from DConf

[H. S. Teoh via Digitalmars-d]

On Wed, May 10, 2017 at 12:06:46PM +, Patrick Schluter via Digitalmars-d 
wrote:
> On Wednesday, 10 May 2017 at 06:28:31 UTC, H. S. Teoh wrote:
> > On Tue, May 09, 2017 at 09:19:08PM -0400, Nick Sabalausky
> [...]
> > Perhaps I'm just being cynical, but my current unfounded hypothesis
> > is that the majority of C/C++ programmers ...
> 
> Just a nitpick, could we also please stop conflating C and C++
> programmers?  My experience is that C++ programmer are completely
> clueless when it comes to C programming? They think they know C but
> it's generally far away. The thing is, that C has evolved with C99 and
> C11 and the changes have not all been adopted by C++ (and Microsoft
> actively stalling the adoption of C99 in Visual C didn't help either).

OK, I'll try to stop conflating them... but the main reason for that is
because I find myself stuck in-between the two, having started myself on
C (well, assembly before that, but anyway) then moved on to C++, only to
grow skeptical of C++'s direction of development and eventually settling
on a hybrid of the two commonly known as "C with classes" (i.e., a
dialect of C++ without some of what I consider to be poorly-designed
features).  Recently, though, I've mostly been working on pure C because
of my job. I used to still use "C with classes" in my own projects but
after I found D, I'd essentially swore myself off ever using C++ in my
own projects again.

My experience reviewing the C++ code that comes up every now and then at
work, though, tells me that the average typical C++ programmer is
probably worse than the average typical C programmer when it comes to
code quality.  And C++ gives you just so many more ways to shoot
yourself in the foot.  The joke used to go that C gives you many ways to
shoot yourself in the foot, but C++ gives you many ways to shoot
yourself in the foot and then encapsulate all the evidence away, all
packaged in one convenient wrapper.

(And don't get me started on C++ "experts" who invent extravagantly
over-engineered class hierarchies that nobody can understand and 90% of
which is actually completely irrelevant to the task at hand, resulting
in such abysmal performance that people just bypassed the whole thing in
the first place and revert to copy-pasta-ism and using C hacks in C++
code, causing double the carnage.  Once I had to invent a stupendous
hack to bridge a C++ daemon with a C module whose owners flatly refused
to link in any C++ libraries. The horrendous result had 7 layers of
abstraction just to make a single function call, one of which involved
fwrite()-ing function arguments to a file, fork-and-exec'ing, and
fread()-ing it from the other end. Why didn't I just open a socket to
the daemon directly? Because the ridiculously over-engineered daemon
only understands the reverse-encrypted Klingon protocol spoken by a
makefile-generated IPC wrapper file containing 2000
procedurally-generated templates (I kid you not, I'm not talking about
2000 instantiations of one template, I'm talking about 2000 templates
which are themselves procedurally generated), and the only way you could
speak this protocol was to use the resultant ridiculously bloated C++
library. Which the PTBs have dictated that I cannot link into the C
module. What else was a man to do?)


T

-- 
Try to keep an open mind, but not so open your brain falls out. -- theboz

Re: DConf 2017 Hackathon report

[Adrian Matoga via Digitalmars-d]

On Tuesday, 9 May 2017 at 13:19:12 UTC, Steven Schveighoffer 
wrote:


But it was very awesome to be able to go around and find the 
people to discuss a PR/idea without going through a forum 
thread. I think there's a psychological barrier that happens 
when you post a complete argument, and then your counterpart 
forms an interpretation in their mind of what the argument 
means, forms their complete counter argument, and neither side 
really understands what the other is saying or willing to do. 
Doing it in person allows so much more interaction -- you can 
cut off early any misinterpretations. It's also harder to be 
nasty in person :)


+1!
For the same reasons, it's also a lot easier for people who don't 
use English as their 1st language to express their ideas as one 
doesn't need to spend time carefully looking up the meaning of 
words to make sure the "complete argument" will be understood as 
intended. :)

Re: DConf 2017 Hackathon report

[Adrian Matoga via Digitalmars-d]

On Tuesday, 9 May 2017 at 04:35:40 UTC, Ali Çehreli wrote:
Please list what we've achieved during the hackathon, including 
what is started but is likely to be finished in the coming days 
or months.


For me:

- Finished updating "Programming in D" to 2.074.0 (the HTML is 
now up to date but I could not get to the still manual work of 
preparing the ebooks)


- Contributed to the logo and branding discussions

- Opened two bugs

- Ate German cookies :)

Ali


I:

1. Started a PR adding -Xcc switch to LDC [1].

2. Discussed a solution to [2] and [3] with Sönke, implementation 
is in progress.


3. Briefly went through sources of Stefan's CTFE implementation. 
To me it was also a good quick lesson about part of DMD internals 
I didn't know yet, and I hope I'll be able to review his code 
from time to time and motivate him.


4. Got a ton of inspiration and motivation.

[1] https://github.com/ldc-developers/ldc/pull/2104
[2] https://github.com/dlang/dub/issues/628
[3] https://github.com/dlang/dub/issues/228

Re: Thoughts on some code breakage with 2.074

[Ali Çehreli via Digitalmars-d]

On 05/10/2017 11:49 AM, Jonathan M Davis via Digitalmars-d wrote:
> On Wednesday, May 10, 2017 05:05:59 Ali Çehreli via Digitalmars-d wrote:
>> On 05/09/2017 10:34 AM, H. S. Teoh via Digitalmars-d wrote:

>>  > After upgrading the compiler, I get a warning that using a 
pointer as a

>>  > condition is deprecated.

> I think that that's the one that Andrei and Vladimir didn't like, because
> they actually used the conversion to bool correctly in their code a bunch
> (whereas most everyone else thought that it was too error prone), and the
> deprecation ended up being removed.
>
> - Jonathan M Davis

Bummer for H. S. Teoh I guess... :/

Although I prefer explicit over implicit in most cases, I've never 
graduated from if(p) and still using it happily. :)


Ali

Re: Fantastic exchange from DConf

[H. S. Teoh via Digitalmars-d]

On Wed, May 10, 2017 at 11:16:57AM +, Atila Neves via Digitalmars-d wrote:
[...]
> The likelihood of a randomly picked C/C++ programmer not even knowing
> what a profiler is, much less having used one, is extremely high in my
> experience.  I worked with a lot of embedded C programmers with
> several years of experience who knew nothing but embedded C. We're
> talking dozens of people here. Not one of them had ever used a
> profiler. In fact, a senior developer (now tech lead) doubted I could
> make our build system any faster. I did by 2 orders of magnitude.

Very nice!  Reminds me of an incident many years ago where I "optimized"
a shell script that took >2 days to generate a report by rewriting it
Perl, which produced the report in 2 mins. (Don't ask why somebody
thought it was a good idea to write a report generation script as a
*shell script*, of all things. You really do not want to know.)


> When I presented the result to him he said in disbelief: "But, how? I
> mean, if it's doing exactly the same thing, how can it be faster?".
> Big O?  Profiler? What are those? I actually stood there for a few
> seconds with my mouth open because I didn't know what to say back to
> him.

Glad to hear I'm not the only one faced with senior programmers who show
surprising ignorance in matters you'd think they really ought to know
like the back of their hand.


> These people are also likely to raise concerns about performance
> during code review despite having no idea what a cache line is. They
> still opine that one shouldn't add another function call for
> readability because that'll hurt performance. No need to measure
> anything, we all know calling functions is bad, even when they're in
> the same file and the callee is `static`.

Yep, typical C coder premature optimization syndrome.

I would not be surprised if today there's still a significant number of
C coders who believe that writing "i++;" is faster than writing
"i=i+1;".  Ironically, these same people would also come up with
harebrained schemes of avoiding something they are prejudiced against,
like C++ standard library string types, while ignoring the cost of
needing to constantly call O(n) algorithms for string processing
(strlen, strncpy, etc.).

I remember many years ago when I was still young and naïve, in one of
projects, I spent days micro-optimizing my code to eliminate every last
CPU cycle I could from my linked-list type, only to discover to my
chagrin that the bottleneck was nowhere near it -- it was caused by a
debugging fprintf() that I had forgotten to take out.  And I had only
found this out because I finally conceded to run a profiler.  That was
when this amazing concept finally dawned on me that I could possibly be
*wrong* about my ideas of performant code, imagine that!

(Of course, then later on I discovered that my meticulously optimized
linked list was ultimately worthless, because it has O(n) complexity,
whereas had I just used a library type instead, I could've had O(log n)
complexity.  But I had dismissed the library type because it was
obviously "too complex" to possibly be performant enough for my
oh-so-performance-critical code. (Ahem.  It was a *game*, and not even a
good one. But it absolutely needed every last drop of juice I could
squeeze from the CPU.  Oh yes.))


> I think a lot of us underestimate just how bad the "average" developer
> is. A lot of them write C code, which is like giving chainsaws to
> chimpanzees.
[...]

Hmm. What would giving them D be equivalent to, then? :-D


T

-- 
If you're not part of the solution, you're part of the precipitate.

Re: Problems with Array Assignment?

[Samwise via Digitalmars-d-learn]

On Wednesday, 10 May 2017 at 17:54:38 UTC, Adam D. Ruppe wrote:

On Wednesday, 10 May 2017 at 17:47:57 UTC, Samwise wrote:
The expected behavior for this is to just see "Different Text" 
and "Other Text", instead of having any time to see just 
"Text". However, it seems that the second update method is 
having the effect that the first call should, and then the 
second is being called after the waiting.


My guess is just output buffering from consoled.

Try `import std.stdio;` and `stdout.flush();` after each update 
and see what happens.


I'm in a work meeting right now, i can look more after if this 
isn't it (and I will answer your other email too)


Thanks a lot, that hit the nail on the head. Behaves exactly as I 
expected it to.

Re: Thoughts on some code breakage with 2.074

[Jonathan M Davis via Digitalmars-d]

On Wednesday, May 10, 2017 05:05:59 Ali Çehreli via Digitalmars-d wrote:
> On 05/09/2017 10:34 AM, H. S. Teoh via Digitalmars-d wrote:
>  > I even appreciate breakages that eventually force me to write more
>  >
>  > readable code!  A not-so-recent example:
>  >/* Used to work, oh, I forget which version now, but it used to
>  >
>  > * work: */
>  >
>  >MyType* ptr = ...;
>  >if (someCondition && ptr) { ... }
>  >
>  > After upgrading the compiler, I get a warning that using a pointer as a
>  > condition is deprecated.  At first I was mildly annoyed... but then to
>  >
>  > make the warning go away, I wrote this instead:
>  >/* Look, ma! Self-documenting, readable code! */
>  >MyType* ptr = ...;
>  >if (someCondition && ptr !is null) { ... }
>
> Can you show an example please. I don't see this being required by
> 2.074.0 (compiled with -w -de).

I think that that's the one that Andrei and Vladimir didn't like, because
they actually used the conversion to bool correctly in their code a bunch
(whereas most everyone else thought that it was too error prone), and the
deprecation ended up being removed.

- Jonathan M Davis

Re: Static foreach pull request

[Timon Gehr via Digitalmars-d]

On 10.05.2017 16:21, Stefan Koch wrote:

On Wednesday, 10 May 2017 at 14:13:09 UTC, Timon Gehr wrote:

On 10.05.2017 15:18, Stefan Koch wrote:


if you try assert([] is null), it should fail.


It doesn't. I have tried to make that point before, unsuccessfully.
Empty arrays may or may not be null, but the empty array literal is
always null.

cat t3.d 
static assert([] is null);
---
dmd t.d -c ---
t3.d(1): Error: static assert  ([] is null) is false



void main(){
import std.stdio;
enum x = [] is null;
auto y = [] is null;
writeln(x," ",y); // "false true"
}

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

[Brad Roberts via Digitalmars-d]

On 5/10/2017 9:20 AM, Seb via Digitalmars-d wrote:

On Wednesday, 10 May 2017 at 11:51:03 UTC, Atila Neves wrote:


Maybe add newer distros on the autotester?


Hehe, that's nearly not possible. Since a couple of months there's an 
ongoing effort to change the directory layout to src/ddmd, which is 
been blocked by necessary changes the autotester.


Yup, but not on my side for a change. :)

The first pull request was broken in that it unilaterally broke old 
branches (ie, stable would have been broken since it still had the old 
layout).  Then it turned out that the windows new layout doesn't match 
the posix new layout, so still broken at the packages to be tested 
layer.  I'm confident that one day the directory layout changes will 
actually be completed and consistent.

Re: "I made a game using Rust"

[Joakim via Digitalmars-d]

On Wednesday, 10 May 2017 at 12:52:34 UTC, JN wrote:
Interesting thread I got from Reddit, someone made a game for 
PC and mobiles fully in Rust.


https://michaelfairley.com/blog/i-made-a-game-in-rust/

"Last week, I released A Snake’s Tale on iOS, Android, Windows, 
Mac, and Linux.".


I wonder, would it be possible for D in the current state to 
achieve the same? I imagine iOS isn't possible yet and Android 
is just getting there?


iOS is possible, though that cross-compiler hasn't been updated 
in a year:


https://github.com/smolt/ldc-iphone-dev/releases

Cross-compiling for Android has been available for awhile, and I 
got JNI working late last year:


https://github.com/joakim-noah/android/releases

That game programmer mentions wanting more control over 
optimizing methods in Rust.  Funnily enough, I've been messing 
with pragma(inline, true) just today to track down a bug related 
to inlining, and Johan added an attribute called optStrategy to 
ldc last summer, which lets you selectively turn on or off 
optimizations for a method:


https://github.com/ldc-developers/ldc/pull/1637

Radu used it when debugging ldc on an ARMv5 microcontroller 
recently.  Not available standardized across D compilers 
obviously, but could be some day.

Re: Fantastic exchange from DConf

[H. S. Teoh via Digitalmars-d]

On Wed, May 10, 2017 at 12:34:05PM +, Guillaume Boucher via Digitalmars-d 
wrote:
[...]
> In modern C and with GLib (which makes use of a gcc/clang extension) you can
> write this as:
> 
> gboolean myfunc(blah_t *blah, bleh_t *bleh, bluh_t *bluh) {
> /* Cleanup everything automatically at the end */
> g_autoptr(GResource) resource1 = NULL, resource2 = NULL, resource3 =
> NULL;
> gboolean ok;
> 
> /* Vet arguments */
> g_return_if_fail(blah != NULL, FALSE);
> g_return_if_fail(bleh != NULL, FALSE);
> g_return_if_fail(bluh != NULL, FALSE);
> 
>   /* Acquire resources */
>   ok = acquire_resource(resource1, blah->blah);
>   g_return_if_fail(ok, FALSE);
> 
> ok = acquire_resource(resource2, bleh->bleh);
>   g_return_if_fail(ok, FALSE);
> 
>   ok = acquire_resource(resource3, bluh->bluh);
>   g_return_if_fail(ok, FALSE);
> 
> /* Do actual work */
>   ok = do_step1(blah, resource1);
>   g_return_if_fail(ok, FALSE);
> 
>   ok = do_step2(blah, resource1);
>   g_return_if_fail(ok, FALSE);
> 
>   return do_step3(blah, resource1);
> }
[...]

Yes, this would address the problem somewhat, but the problem is again,
this is programming by convention.  The language doesn't enforce that
you have to write code this way, and because it's not enforced,
*somebody* will ignore it and write things the Bad Ole Way.  You're
essentially writing in what amounts to a subdialect of C using Glib
idioms, and that's not a bad thing in and of itself. But the larger
language that includes all the old unsafe ways of writing code is still
readily accessible.  By Murphy's Law, somebody will eventually write
something that breaks the idiom and causes problems.

Also, because this way of writing code is not part of the language, the
compiler cannot verify that you're using the macros correctly.  And it
cannot verify that you didn't write goto labels or other things that
might conflict with the way the macros are implemented. Lack of hygiene
in C macros does not help in this respect.

I don't dispute that there are ways of writing correct (or mostly
correct) C code.  But the problem is that these ways of writing correct
C code are (1) non-obvious to someone not already in the know, and so
you will always have people who either don't know about them or aren't
sufficiently well-versed in them to use them effectively; and (2) not
statically enforceable because they are not a part of the language.
Lack of enforcement, in the long run, can only end in disaster, because
programming by convention does not work.  It works as long as the
convention is kept, but humans are fallible, and we all know how well
humans are at keeping conventions over a sustained period of time (or
even just short periods of time).

Not even D is perfect in this regard, but it has taken significant steps
in the right directions.  Correct-by-default (well, for the most part
anyway, barring compiler bugs / spec issues) and static guarantees
(verified by the compiler -- again barring compiler bugs) are major
steps forward.  Ultimately, I'm unsure how far a language can go at
static guarantees: I think somewhere along the line human error will
still be unpreventable because you start running into the halting
problem when verifying certain things. But I certainly think there's
still a LOT that can be done by the language between here and there,
much more than what we have today.


T

-- 
Mediocrity has been pushed to extremes.

Re: "I made a game using Rust"

[zetashift via Digitalmars-d]

On Wednesday, 10 May 2017 at 12:52:34 UTC, JN wrote:
I wonder, would it be possible for D in the current state to 
achieve the same? I imagine iOS isn't possible yet and Android 
is just getting there?


Reading this thread while going through the online D book I 
wonder;
Would one recommend D for gamedev? I was thinking of writing 
small games with the help of SFML to learn D better and try to 
get better at programming game logic(DLang is my second 
programming language).

Re: Fantastic exchange from DConf

[H. S. Teoh via Digitalmars-d]

On Wed, May 10, 2017 at 04:38:48AM -0700, Ali Çehreli via Digitalmars-d wrote:
> On 05/09/2017 10:26 PM, H. S. Teoh via Digitalmars-d wrote:
> > On Wed, May 10, 2017 at 01:32:33AM +, Jack Stouffer via Digitalmars-d
> wrote:
> >> On Wednesday, 10 May 2017 at 00:30:42 UTC, H. S. Teoh wrote:
[...]
> >>>   strncpy(tmp, desc->data2, bufsz);
> >>>   if (fwrite(tmp, strlen(tmp), 1, fp) != 1)
> >>>   {
> >>>   fclose(fp);
> >>>   unlink("blah");
> >>>   return IO_ERROR;
> >>>   }
> >>
> >> I think you cause a memory leak in these branches because you
> >> forget to free tmp before returning.
> >
> > Well, there ya go. Case in point.
> 
> I caught that too but I thought you were testing whether we were
> listening.  ;)

Haha, I guess I'm not as good of a C coder as I'd like to think I am.
:-D


[...]
> > /* Acquire resources */
> > resource1 = acquire_resource(blah->blah);
> > if (!resource1) goto EXIT;
> >
> > resource2 = acquire_resource(bleh->bleh);
> > if (!resource1) goto EXIT;
> 
> Copy paste error! :p (resource1 should be resource2.)
> 
> >
> > resource3 = acquire_resource(bluh->bluh);
> > if (!resource1) goto EXIT;
> 
> Ditto.

Ouch.  Ouch.  :-D

But then again, I've actually seen similar copy-paste errors in real
code before, too. Sometimes they could be overlooked for >5 years (I kid
you not, I actually checked the date in svn blame / svn log).


[...]
> As an improvement, consider hiding the checks and the goto statements
> in macros:
> 
> resource2 = acquire_resource(bleh->bleh);
> exit_if_null(resource1);
> 
> err = do_step2(blah, resource1);
> exit_if_error(err);
> 
> Or something similar... Obviously, it requires certain standardization
> like functions never having a goto statement, yet all having an EXIT
> area, etc.  It makes C code very uniform, which is a good thing as you
> notice nonstandard idioms quickly.

Yes, eventually this is the only sane and consistent way to deal with
these problems.  Unfortunately, in C this can only be done by
convention, which means that some non-conforming code will inevitably
slip through and cause havoc.

Also, this starts running dangerously near the slippery slope down into
macro hell, where the project accretes its own idiomatic set of
inscrutable macro usage conventions and eventually almost all of the C
syntax has disappeared and the code no longer looks like C.  Then along
comes New Recruit, and he makes a right mess with it because he doesn't
understand the 15-level-deep nested macros in the global
include/macros.h file that's become a 5200-line monstrosity of
unreadable CPP hacks.  (Also not exaggerating: the very project I'm
working on has a module that's written this way, and only the initiated
dare dream of fixing bugs in those macros. Fortunately, they have not
yet nested to 15 levels deep, so for the most part you just copy and
paste existing working code and pray that it will Just Work by analogy.
Actually understand what you just wrote? Pfeh! You don't have time for
that. The customer wants the release by last week. Copy-n-paste cargo
cult FTW!)


> This safer way of needing to do everything in steps of two lines is
> one of the reasons why I was convinced that exceptions are superior to
> return codes.
[...]

Yeah, once practically every single statement in your function is an
if-statement checking for error codes, you start wondering, why can't
the language abstract this nasty boilerplate away for me?! And then the
need for exceptions becomes clear.


T

-- 
Written on the window of a clothing store: No shirt, no shoes, no service.

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: Simulating reference variables using `alias this`

[Carl Sturtivant via Digitalmars-d]

On Wednesday, 10 May 2017 at 17:12:11 UTC, Carl Sturtivant wrote:
Here's the beginning of an interesting little experiment to 
simulate reference variables using `alias this` to disguise a 
pointer as a reference. Could add a destructor to set the 
pointer to null when a reference goes out of scope.


Here's a better version. Improvements? This can still behave as 
badly as a pointer, e.g. if returned from a function.


```
struct reference(T)
{
T* ptr;
this(ref T x)
{
ptr = 
}
~this()
{
ptr = null;
}
import std.exception : enforce;

ref T cnvrt() @property
{
enforce( ptr !is null);
return *ptr;
}
ref T cnvrt(T x) @property
{
enforce( ptr !is null);
return *ptr = x;
}
ref reference!T opAssign(T t)
{
enforce( ptr !is null);
*ptr = t;
return this;
}
ref reference!T opAssign(ref reference!T r)
{
enforce( ptr !is null && r.ptr !is null);
*ptr = *r.ptr;
return this;
}
alias cnvrt this;
}

void main()
{
int i;
auto ri = reference!int(i);
auto ri2 = reference!int(ri);

assert(ri.ptr==ri2.ptr);

i = 99;
assert(i==ri && i==ri2 && ri==ri2);

ri = 100;
assert(i==ri && i==ri2 && ri==ri2);

ri2 = 101;
assert(i==ri && i==ri2 && ri==ri2);

int j = -1;
auto rj = reference!int(j);

ri = rj;

assert(ri==rj);
assert(ri.ptr!=rj.ptr);
}
```

Re: Problems with Array Assignment?

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 10 May 2017 at 17:47:57 UTC, Samwise wrote:
The expected behavior for this is to just see "Different Text" 
and "Other Text", instead of having any time to see just 
"Text". However, it seems that the second update method is 
having the effect that the first call should, and then the 
second is being called after the waiting.


My guess is just output buffering from consoled.

Try `import std.stdio;` and `stdout.flush();` after each update 
and see what happens.


I'm in a work meeting right now, i can look more after if this 
isn't it (and I will answer your other email too)

Re: Simulating reference variables using `alias this`

[MrSmith via Digitalmars-d]

On Wednesday, 10 May 2017 at 17:12:11 UTC, Carl Sturtivant wrote:
Here's the beginning of an interesting little experiment to 
simulate reference variables using `alias this` to disguise a 
pointer as a reference. Could add a destructor to set the 
pointer to null when a reference goes out of scope.

...


I've used this code for similar purpose:

alias TextEditorSettingsRef = TextEditorSettings*;
alias TextEditorSettingsConstRef = const(TextEditorSettings)*;
struct TextEditorSettings
{}

But you need to have two aliases (templates) for const and 
non-const refs, since using:

const TextEditorSettingsRef editor;
does:
const(TextEditorSettings*)
not
const(TextEditorSettings)*

What do you think?

Re: Problems with Array Assignment?

[Samwise via Digitalmars-d-learn]

I'm also having another problem with this program that is 
(sorta?) related. If you notice in my main (minus all the 
comments...), the code creates two tiles, then updates the 
renderer so that it renders those tiles. Then I create another 
tile in the same place as one of the first ones (not strictly 
relevant) and updates. Then the program pauses before it exits.


The expected behavior for this is to just see "Different Text" 
and "Other Text", instead of having any time to see just "Text". 
However, it seems that the second update method is having the 
effect that the first call should, and then the second is being 
called after the waiting.


Could anyone offer any insight on this? Again I'm sure it's an 
issue that I could have avoided had I known more when I wrote the 
code, but just don't yet. Thanks again for the help.

~Sam

[Issue 16746] Please output Makefile-style depfiles for ninja and make

[via Digitalmars-d-bugs]

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

--- Comment #9 from Vladimir Panteleev  ---
(In reply to Matthias Klumpp from comment #8)
> Yes, it doesn't support all command-line flags one would use with ldc, gdc
> or dmd.

rdmd simply forwards flags it doesn't recognize to the compiler.

> Any wrapper is not an option.

Why?

--

Re: subtlety or bug?

[Carl Sturtivant via Digitalmars-d-learn]

Aha, https://dlang.org/spec/struct.html#struct-destructor says 
that


An identity assignment overload is required for a struct if one 
or more of these conditions hold:


* it has a destructor

so this is the above condition coming into play.

Re: Problems with Array Assignment?

[Samwise via Digitalmars-d-learn]

On Wednesday, 10 May 2017 at 13:43:54 UTC, Adam D. Ruppe wrote:

In your code, I see one big mistake:

---
class TileRenderer
{
private Tile[] tiles;
/*...*/
}

class CTileRenderer : TileRenderer
{
private CTile[] tiles;
/*...*/
}
---


Those are two separate arrays! Stuff examined through 
TileRenderer will be looking at a different array than looking 
through CTileRenderer.


I wondered about that when I did it, but I assumed (wrongly) that 
since the name of the array was the same, it would override it.


Thank you for suggesting that I make rendering a tile's 
responsibility instead of the renderer's. It honestly makes more 
sense that way, and my code is cleaner because of it. I did 
actually get it working because of that.


Just to clarify, you can use a superclass variable to reference a 
member of a subclass? That seems to be what's happening.


Thanks so much guys, I really appreciate it. My code it working 
now, and it's committed to github, so you can check it out if 
you'd like. Thanks!

~Sam

subtlety or bug?

[Carl Sturtivant via Digitalmars-d-learn]

The following compiles and runs correctly.
https://forum.dlang.org/post/tzwsohkcqrkqotbwn...@forum.dlang.org

But if I add a destructor to the reference struct template as 
follows, it no longer compiles, and the complaints are not about 
the destructor.

```
~this()
{
ptr = null;
}
```
refsim.d(39): Error: generated function 
refsim.reference!int.reference.opAssign (reference!int p) is not 
callable using argument types (int)
refsim.d(42): Error: generated function 
refsim.reference!int.reference.opAssign (reference!int p) is not 
callable using argument types (int)


These are complaining about lines where reference!int variables 
are assigned integers.


What's going on?

Here's the code linked to above without the destructor that works.
```
struct reference(T)
{
T* ptr;
this(ref T x)
{
ptr = 
}
import std.exception : enforce;

ref T cnvrt() @property
{
enforce( ptr !is null);
return *ptr;
}
ref T cnvrt(T x) @property
{
enforce( ptr !is null);
return *ptr = x;
}
alias cnvrt this;
}

void main()
{
int i;
auto ri = reference!int(i);
auto ri2 = reference!int(ri);

assert(ri.ptr==ri2.ptr);

i = 99;
assert(i==ri && i==ri2 && ri==ri2);

ri = 100;
assert(i==ri && i==ri2 && ri==ri2);

ri2 = 101;
assert(i==ri && i==ri2 && ri==ri2);
}
```

Simulating reference variables using `alias this`

[Carl Sturtivant via Digitalmars-d]

Here's the beginning of an interesting little experiment to 
simulate reference variables using `alias this` to disguise a 
pointer as a reference. Could add a destructor to set the pointer 
to null when a reference goes out of scope.


```
struct reference(T)
{
T* ptr;
this(ref T x)
{
ptr = 
}
import std.exception : enforce;

ref T cnvrt() @property
{
enforce( ptr !is null);
return *ptr;
}
ref T cnvrt(T x) @property
{
enforce( ptr !is null);
return *ptr = x;
}
alias cnvrt this;
}

void main()
{
int i;
auto ri = reference!int(i);
auto ri2 = reference!int(ri);

assert(ri.ptr==ri2.ptr);

i = 99;
assert(i==ri && i==ri2 && ri==ri2);

ri = 100;
assert(i==ri && i==ri2 && ri==ri2);

ri2 = 101;
assert(i==ri && i==ri2 && ri==ri2);
}
```

Re: "I made a game using Rust"

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 10 May 2017 at 15:50:06 UTC, Adrian Matoga wrote:
In this simple case above, I actually prefer DMD's messages, as 
there's simply less text for my eyes to read and brain to 
parse, so I can quickly spot where the problem is.



Well, even here, I'd prefer a small tweak:

lll.d(6): Error: none of the overloads of 'foo' match
given:foo(int  , double)
 lll.d(1):lll.foo(int a, int a)
 lll.d(2):lll.foo(int a, string s)

The alignment would make it easier to eyeball the matches and 
options... though that fails on longer lines too.


Another option is using colors (or something) to highlight which 
ones in the candidates matched and which didn't.


The difference is small in a short case like this... but even 
here, I'd call it slightly better, and in a big case, it is much 
better.


It's indeed painful, but I found UDAs to be useful in dealing 
with it.


Oh, that's on the declaration side, but this error message is on 
the call side.


Suppose I pass an input range to sort(). I prove it is an input 
range with UDAs or static asserts or whatever, yet the call to 
sort fails. Why?


It is because sort requires more than just an input range, but 
just whate is difficult to determine from the error message. So a 
legible error message tells you WHAT you need to test on the 
declaration ("must be random access"), then the udas can handle 
those error messages (so like "it is not a random access range 
because opIndex is not implemented")



Of course, the sort() function could check `isSortable` instead 
of everything it lists in its constraint... and I think I'd like 
that, but still, a more readable error message would be a big win.



The llvm people are just annihilating us in the error messages 
and that's a bigger day-to-day boost than it seems.



So yeah, we should do both: make the decls nicer with UDAs, but 
also make the error messages nicer for all cases.




oh another class of error messages that suck: "@nogc function 
cannot call non-@nogc function map". but map is inferred so why 
did it fail? wrote this up in bugzilla: 
https://issues.dlang.org/show_bug.cgi?id=17374



I think RangeError could be solved without much effort by 
changing the compiler/runtime interface at _d_arraybounds*. 
Assertions are probably harder.


yeah, I actually tried to implement it one time and failed though 
- the compiler code is a bit more fragile than I thought. Still 
shouldn't be too hard, if I had a few hours to spend on it I 
could prolly do it.

Re: Lookahead in unittest

[Raiderium via Digitalmars-d-learn]

On Wednesday, 10 May 2017 at 16:32:11 UTC, Adam D. Ruppe wrote:

On Wednesday, 10 May 2017 at 16:09:06 UTC, Raiderium wrote:

I can't figure out if this is intended behaviour.


It is. A unittest is a function, and in functions, all 
declarations must be defined before used (just like local 
variables).


Sometimes, you can wrap it in a struct:

unittest {
  struct Decls {
// put your decls here
  }

  with(Decls()) {
   // call funcs here
  }
}


Ah. I wasn't aware class declarations within functions (including 
unittest) were sensitive to their order, so that's something I've 
learned today. :)


I tried the with(Decls()) syntax and it worked perfectly, thanks 
Adam. I'd been haphazardly nesting unittest{} blocks within the 
struct, and it felt less than sanitary.


For full disclosure, the test I'm writing needs to create a 
reference cycle (as in, class B holding a reference to A), and it 
works properly if the classes are declared at module/class/struct 
level, but then either the class names pollute the module (which 
is just eww) or they're nested within a class/struct, which leads 
me to the current situation.


Consider my problem solved :) Thanks again Stefan and Adam for 
the replies.

Re: Override @property

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 10 May 2017 at 16:40:09 UTC, Aldo wrote:

class PictureBox : Control
{
@property
public override void texture(Texture value)
{
writeln("override");
this.m_texture = value;
}
}

Error: function f340.PictureBox.texture (Texture value) is not 
callable using argument types ()



Yes, that's normal. If you override one function in a child 
class, you need to explicitly bring in the other overrides by 
adding


alias texture = Control.texture; // I think you can also use 
`super.texture`


in the class with the new override. That tells it to look up the 
name from the parent as well.


The rationale is here: http://dlang.org/hijack.html

It isn't just properties btw, any case of overloads is subject to 
the same rule.

Override @property

[Aldo via Digitalmars-d-learn]

Hello,

can you tell me if this compilation error is normal ?

class Texture
{
public this()
{

}
}

class Control
{
private Texture m_texture;

@property
{
public Texture texture()
{
return this.m_texture;
}

public void texture(Texture value)
{
this.m_texture = value;
}
}
}

class PictureBox : Control
{
@property
public override void texture(Texture value)
{
writeln("override");
this.m_texture = value;
}
}

import std.stdio;

void main()
{
auto picture = new PictureBox();

writeln(picture.texture is null);

}

Error: function f340.PictureBox.texture (Texture value) is not 
callable using argument types ()


Complete code : https://dpaste.dzfl.pl/aa7bf25548e8

I can't use property getter if I override the setter property.

Re: Lookahead in unittest

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 10 May 2017 at 16:09:06 UTC, Raiderium wrote:

I can't figure out if this is intended behaviour.


It is. A unittest is a function, and in functions, all 
declarations must be defined before used (just like local 
variables).


Sometimes, you can wrap it in a struct:

unittest {
  struct Decls {
// put your decls here
  }

  with(Decls()) {
   // call funcs here
  }
}

Re: "I made a game using Rust"

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/10/2017 11:50 AM, Adrian Matoga wrote:

On Wednesday, 10 May 2017 at 15:03:19 UTC, Adam D. Ruppe wrote:


lll.d(5): Error: function lll.foo (Color c) is not callable using
argument types (Color)

WTF, right? Well, I have a locally defined `struct Color` and an
imported one. Same name, but different type. The error message doesn't
tell me which one is which.


Yeah, that one was funny. :)


It's not so funny when you're new to that error and don't already know 
to look for two types from different modules with the same name. :(



Same with assertions. I usually end up adding wrappers like assertEqual,
and the more I use them, the more I feel like switching to something
like [3] or [4], as much as I normally prefer to keep the number of
dependencies low.

[3] https://code.dlang.org/packages/fluent-asserts
[4] http://code.dlang.org/packages/unit-threaded


Unit-threaded rocks my world. First I've heard of fluent-asserts but it 
looks interesting.

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

[Seb via Digitalmars-d]

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

So I went "I know, I'll just use a container". I tried Ubuntu 
Zesty in docker. That doesn't build dmd off the bat either, it 
fails with PIC errors.


AFAIK this bug should have been fixed. However, IIRC 2.073.2 or 
2.074 as host compiler is required.


I'm using Trusty, and that works. But... it's a matter of time 
before most people are on newer versions of everything and dmd 
won't be buildable on Linux.


Maybe add newer distros on the autotester?


Hehe, that's nearly not possible. Since a couple of months 
there's an ongoing effort to change the directory layout to 
src/ddmd, which is been blocked by necessary changes the 
autotester.
Travis doesn't support newer distros easily as well, but e.g. 
CircleCi 2 does as they have native integration with Docker:


https://circleci.com/blog/say-hello-to-circleci-2-0/
https://circleci.com/docs/2.0/

PRs are welcome ;-)


Atila

Re: Lookahead in unittest

[Stefan Koch via Digitalmars-d-learn]

On Wednesday, 10 May 2017 at 16:09:06 UTC, Raiderium wrote:

Heyo,

On 2.074.0, the following test fails with "Error: undefined 
identifier 'B' "


unittest
{
class A { B b; }
class B { }
}

I can't figure out if this is intended behaviour. It's making a 
template-heavy module difficult to test. Would appreciate any 
help.


First post here, be gentle :)


It looks like this unitest-test block are treated like a function.

What is the surrounding code ?

If this is at module level then it is a bug.

Lookahead in unittest

[Raiderium via Digitalmars-d-learn]

Heyo,

On 2.074.0, the following test fails with "Error: undefined 
identifier 'B' "


unittest
{
class A { B b; }
class B { }
}

I can't figure out if this is intended behaviour. It's making a 
template-heavy module difficult to test. Would appreciate any 
help.


First post here, be gentle :)

Re: "I made a game using Rust"

[Adrian Matoga via Digitalmars-d]

On Wednesday, 10 May 2017 at 15:03:19 UTC, Adam D. Ruppe wrote:

On Wednesday, 10 May 2017 at 14:02:38 UTC, Adrian Matoga wrote:

Would you mind giving some examples?


What bothers me on a regular basis is overloading. Basic case:

$ dmd lll
lll.d(6): Error: none of the overloads of 'foo' are callable 
using argument types (int, double), candidates are:

lll.d(1):lll.foo(int a, int a)
lll.d(2):lll.foo(int a, string s)

Contrast that to g++:

$ g++ lll.cpp
lll.cpp: In function ‘int main()’:
lll.cpp:7:14: error: no matching function for call to ‘foo(int, 
Foo)’

  foo(0, Foo());
  ^
lll.cpp:7:14: note: candidates are:
lll.cpp:1:6: note: void foo(int, char*)
 void foo(int a, char* b);
  ^
lll.cpp:1:6: note:   no known conversion for argument 2 from 
‘Foo’ to ‘char*’

lll.cpp:2:6: note: void foo(int, float)
 void foo(int a, float b);
  ^
lll.cpp:2:6: note:   no known conversion for argument 2 from 
‘Foo’ to ‘float’




The g++ example isn't great either... but is better because of 
this: "no known conversion for argument 2 from ‘Foo’ to ‘float’"



It actually told me which argument didn't match! clang is 
similar:


$ clang lll.cpp
lll.cpp:7:2: error: no matching function for call to 'foo'
foo(0, Foo());
^~~
lll.cpp:1:6: note: candidate function not viable: no known 
conversion from 'Foo' to 'char *' for 2nd argument

void foo(int a, char* b);
 ^
lll.cpp:2:6: note: candidate function not viable: no known 
conversion from 'Foo' to 'float' for 2nd argument

void foo(int a, float b);



With the dmd one, especially on a long function, it is hard to 
tell just which argument is giving trouble. The C++ errors just 
flat out tell me which argument didn't match for each candidate.


In this simple case above, I actually prefer DMD's messages, as 
there's simply less text for my eyes to read and brain to parse, 
so I can quickly spot where the problem is.
I agree, though, that with longer argument lists, especially with 
const vs. non-const or template constraints, trying to figure out 
what's wrong could be at least frustrating.



Templates with constraints are even worse.

lll.d(3): Error: template std.algorithm.sorting.sort cannot 
deduce function from argument types !()(int), candidates are:

/home/me/d/dmd2/linux/bin32/../../src/phobos/std/algorithm/sorting.d(1830):std.algorithm.sorting.sort(alias less = "a 
< b", SwapStrategy ss = SwapStrategy.unstable, Range)(Range r) if ((ss == SwapStrategy.unstable && 
(hasSwappableElements!Range || hasAssignableElements!Range) || ss != SwapStrategy.unstable && hasAssignableElements!Range) 
&& isRandomAccessRange!Range && hasSlicing!Range && hasLength!Range)


What a mess! Just formatting that output might help, but I'd 
especially love it if it told me which individual boolean 
elements failed, passed, and were short-circuited. The compiler 
knows this, it had to evaluate that to figure out it didn't 
match, but it doesn't tell me.


At a glance, can you even tell what I passed to the function?

Bonus points would be it telling me why, for example, 
`isInputRange` failed, but I understand that is an even bigger 
problem to solve.


It's indeed painful, but I found UDAs to be useful in dealing 
with it.

First, I'm sure you know Atila's concepts [1].

I also use UDAs in flod [2], so instead of checking whether the 
implementation satisfies a constraint, I only check if it's 
explicitly tagged with a specific UDA. Now, I immediately see 
whether it's a method that I forgot to implement or just a typo, 
instead of being forced to guess by a "missing overload" message.




Of course, C++ doesn't have constraints so there's no 
comparison there.



Lastly, check this out:

lll.d(5): Error: function lll.foo (Color c) is not callable 
using argument types (Color)


WTF, right? Well, I have a locally defined `struct Color` and 
an imported one. Same name, but different type. The error 
message doesn't tell me which one is which.


Yeah, that one was funny. :)

These are the top 3 dmd error messages that bother me 
regularly. At runtime, little drives me more nuts than 
RangeError not telling me the index and the length. Again, it 
knows, the code checked it, but it didn't report it.


Same with assertions. I usually end up adding wrappers like 
assertEqual, and the more I use them, the more I feel like 
switching to something like [3] or [4], as much as I normally 
prefer to keep the number of dependencies low.


I think RangeError could be solved without much effort by 
changing the compiler/runtime interface at _d_arraybounds*. 
Assertions are probably harder.



[1] 
http://forum.dlang.org/post/eoxerbkaowxpgjubh...@forum.dlang.org

[2] https://github.com/epi/flod/blob/develop/source/flod/package.d
[3] https://code.dlang.org/packages/fluent-asserts
[4] http://code.dlang.org/packages/unit-threaded

[Issue 14639] Assigning init value to struct uses stack, causing segfault

[via Digitalmars-d-bugs]

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

--- Comment #3 from Walter Bright  ---
The code:

biggy = Biggy.init;

gets rewritten to be:

biggy = Biggy([0LU, ...]);

which is a construction. The postblit caused an opAssign() to be created, and
the expression is further rewritten to:

biggy.opAssign(Biggy([0LU, ...]));

which blows up the parameter stack because Biggy([0LU, ...]) is too big for it.
The operation is not disabled because it gets constructed in place - a copy is
not being made.

A possible compiler fix is to figure out that the generated opAssign is trivial
and can be replaced with a bit copy. The code in opover.d:

if (sd && !sd.hasIdentityAssign)
{
/* This is bitwise struct assignment. */
return;
}

can be modified to test for triviality of identity assign, and use a bitwise
copy.

--

Re: How to avoid throwing an exceptions for a built-in function?

[k-five via Digitalmars-d-learn]

On Wednesday, 10 May 2017 at 14:27:46 UTC, Stanislav Blinov wrote:

On Wednesday, 10 May 2017 at 13:27:17 UTC, k-five wrote:

Thanks, but I know about what are you saying. The 
user_apply[4] has so many possibilities and I cannot use 
if-else


That doesn't sound right. Either you've already handled all the 
possible cases and thus expect the to! to not throw (can 
specify that i.e. via std.exception.assumeWontThrow), or, as 
you're saying, it's much more than an if-else, but in that case 
exception will be thrown on invalid input.


--

I know. But I am saying that I do not want to take care of any 
exceptions.

I just wanted to write:

int variable = to!int( string-type );

In fact something like using "no throw" is a function:
void init( ... ) nothrow {
...
int variable = to!int( string-type );
...
}

but this is not valid.

Thanks anyway and I will test: Function 
std.exception.assumeWontThrow at this link:

https://dlang.org/library/std/exception/assume_wont_throw.html

Re: DConf 2017 Hackathon report

[Joakim via Digitalmars-d]

On Tuesday, 9 May 2017 at 17:50:06 UTC, ANtlord wrote:

On Tuesday, 9 May 2017 at 04:35:40 UTC, Ali Çehreli wrote:
Please list what we've achieved during the hackathon, 
including what is started but is likely to be finished in the 
coming days or months.


For me:

- Finished updating "Programming in D" to 2.074.0 (the HTML is 
now up to date but I could not get to the still manual work of 
preparing the ebooks)


- Contributed to the logo and branding discussions

- Opened two bugs

- Ate German cookies :)

Ali


Is there some news about compiling dmd as library?


There was a talk about this, one of the interns is working on it:

http://dconf.org/2017/talks/nitu.html

No idea when it'll be done.

Re: Mir Algorithm v0.5.8: Interpolation, Timeseries and 17 new functions

[jmh530 via Digitalmars-d-announce]

On Wednesday, 10 May 2017 at 11:16:37 UTC, 9il wrote:


I have fixed small parts. I have invited you to the Mir Github 
team. Would be awesome to see your documentation PRs) You can 
always ask me about implementation details in the Gitter


Thanks,
Ilya


Thanks. Your documentation seems like it assumes that the person 
reading it is as great a programmer as you are. And I am most 
assuredly not.


More generally, I sometimes get frustrated with the documentation 
on dlang, but I'm not as pro-active as I should be in trying to 
improve it. It might be less frustrating to help with yours than 
dlang.

Re: DIP 1007 Preliminary Review Round 1

[Dicebot via Digitalmars-d]

On Tuesday, 25 April 2017 at 12:33:44 UTC, Steven Schveighoffer 
wrote:
Actually, that brings up a problem with this, what is the 
mechanism to say "maybe override"? Let's say you have:


// in imported library
class Base
{
   void foo() @future;
}

// in user library
class Derived : Base
{
   void foo() {...} // triggers warning
}

What is the next step the user has to take to remove the 
deprecation warning, but still have valid code?


Right now I have two possible approaches in mind.

One is to simply allow overriding `@future` symbol which doesn't 
require any extra stuff but can be viewed sub-optimal because it 
couples two loosely related concepts and would require special 
cases in how future symbols are handled inside compiler (they 
stop being completely ephemeral).


Other would be an accompanying DIP to be able to specify 
`overide(strict)` (default, same as plain `override`) vs 
`override(optional)` to be able to define methods that may or may 
not override base one, with no specific relation to `@future`.


I don't have any hard opinion on the matter of my own, what do 
you think?

Re: "I made a game using Rust"

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 10 May 2017 at 14:02:38 UTC, Adrian Matoga wrote:

Would you mind giving some examples?


What bothers me on a regular basis is overloading. Basic case:

$ dmd lll
lll.d(6): Error: none of the overloads of 'foo' are callable 
using argument types (int, double), candidates are:

lll.d(1):lll.foo(int a, int a)
lll.d(2):lll.foo(int a, string s)

Contrast that to g++:

$ g++ lll.cpp
lll.cpp: In function ‘int main()’:
lll.cpp:7:14: error: no matching function for call to ‘foo(int, 
Foo)’

  foo(0, Foo());
  ^
lll.cpp:7:14: note: candidates are:
lll.cpp:1:6: note: void foo(int, char*)
 void foo(int a, char* b);
  ^
lll.cpp:1:6: note:   no known conversion for argument 2 from 
‘Foo’ to ‘char*’

lll.cpp:2:6: note: void foo(int, float)
 void foo(int a, float b);
  ^
lll.cpp:2:6: note:   no known conversion for argument 2 from 
‘Foo’ to ‘float’




The g++ example isn't great either... but is better because of 
this: "no known conversion for argument 2 from ‘Foo’ to ‘float’"



It actually told me which argument didn't match! clang is similar:

$ clang lll.cpp
lll.cpp:7:2: error: no matching function for call to 'foo'
foo(0, Foo());
^~~
lll.cpp:1:6: note: candidate function not viable: no known 
conversion from 'Foo' to 'char *' for 2nd argument

void foo(int a, char* b);
 ^
lll.cpp:2:6: note: candidate function not viable: no known 
conversion from 'Foo' to 'float' for 2nd argument

void foo(int a, float b);



With the dmd one, especially on a long function, it is hard to 
tell just which argument is giving trouble. The C++ errors just 
flat out tell me which argument didn't match for each candidate.




Templates with constraints are even worse.

lll.d(3): Error: template std.algorithm.sorting.sort cannot 
deduce function from argument types !()(int), candidates are:

/home/me/d/dmd2/linux/bin32/../../src/phobos/std/algorithm/sorting.d(1830):std.algorithm.sorting.sort(alias less = "a 
< b", SwapStrategy ss = SwapStrategy.unstable, Range)(Range r) if ((ss == SwapStrategy.unstable && 
(hasSwappableElements!Range || hasAssignableElements!Range) || ss != SwapStrategy.unstable && hasAssignableElements!Range) 
&& isRandomAccessRange!Range && hasSlicing!Range && hasLength!Range)


What a mess! Just formatting that output might help, but I'd 
especially love it if it told me which individual boolean 
elements failed, passed, and were short-circuited. The compiler 
knows this, it had to evaluate that to figure out it didn't 
match, but it doesn't tell me.


At a glance, can you even tell what I passed to the function?

Bonus points would be it telling me why, for example, 
`isInputRange` failed, but I understand that is an even bigger 
problem to solve.


Of course, C++ doesn't have constraints so there's no comparison 
there.



Lastly, check this out:

lll.d(5): Error: function lll.foo (Color c) is not callable using 
argument types (Color)


WTF, right? Well, I have a locally defined `struct Color` and an 
imported one. Same name, but different type. The error message 
doesn't tell me which one is which.





These are the top 3 dmd error messages that bother me regularly. 
At runtime, little drives me more nuts than RangeError not 
telling me the index and the length. Again, it knows, the code 
checked it, but it didn't report it.

[Issue 17390] New: Pass flags to linker driver without -Xlinker

[via Digitalmars-d-bugs]

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

  Issue ID: 17390
   Summary: Pass flags to linker driver without -Xlinker
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: adr...@matoga.info

There's an open PR to LDC [1] to allow passing options to the linker driver
without -Xlinker on non-Windows platforms.
This is required e.g. for flags like --sysroot=path [2] or flags from
pkg-config [3] to work as expected.

The PR [1] adds option '-Xcc OPT', which passes OPT directly to the linker
driver (e.g. gcc or clang) without prepending it with -Xlinker. The global
order of flags passed via '-Xcc' and '-L' is preserved, and libraries requested
via pragma(lib) are appended after those flags.

The choice of '-Xcc' was motivated by clang's convention [4].

A similar feature would probably be useful also for DMD users. Since '-Xcc'
doesn't look consistent with current use of '-X' in DMD, DMD probably should
use a different switch for it.

W.r.t. order of linker (or linker driver) flags, there're a few related DMD
issues [5].

[1] https://github.com/ldc-developers/ldc/pull/2104
[2] https://github.com/ldc-developers/ldc/issues/2093
[3] https://github.com/ldc-developers/ldc/issues/1700
[4] https://github.com/ldc-developers/ldc/issues/2093#issuecomment-299707520
[5] https://issues.dlang.org/show_bug.cgi?id=15574
[6] https://issues.dlang.org/show_bug.cgi?id=15531
[7] https://issues.dlang.org/show_bug.cgi?id=7044

--