Re: Meaning of DMD flag -transition=safe

[Seb via Digitalmars-d-learn]

On Thursday, 15 September 2016 at 21:36:07 UTC, Nordlöw wrote:

What's the meaning of the DMD flag

-transition=safe

?

Is it new? I haven't seen it before.


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

[Issue 16193] opApply() doesn't heap allocate closure

[via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 16193] opApply() doesn't heap allocate closure

[via Digitalmars-d-bugs]

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

--- Comment #11 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/f7819c898a05d28297024b7355d4ace94f1e4465
fix Issue 16193 - opApply() doesn't heap allocate closure

https://github.com/dlang/dmd/commit/946a8f4e0eb488313e53da41ad6f81e3a778b9a8
Merge pull request #6135 from WalterBright/fix16193

fix Issue 16193 - opApply() doesn't heap allocate closure

--

Vibe.d: Jade has become pug

[Intersteller via Digitalmars-d-learn]

Might want to update the docs!

Re: What is the most stable D compiler

[Sai via Digitalmars-d]

If stability is more important, I recommend to only update to 
x.y.2 or higher releases, just don't update to x.y.0 releases.


yes, reliability is more important, could you, please, point 
out the link where i can read about versions?


Here is the changelog page:

https://dlang.org/changelog/2.071.1.html

Re: ddoc latex/formulas?

[Manu via Digitalmars-d]

On 15 September 2016 at 23:48, Andrei Alexandrescu via Digitalmars-d
 wrote:
> On 09/15/2016 09:12 AM, Manu via Digitalmars-d wrote:
>>
>> On 15 September 2016 at 22:40, Adam D. Ruppe via Digitalmars-d
>>  wrote:
>>>
>>> On Wednesday, 14 September 2016 at 15:49:27 UTC, bachmeier wrote:


 I agree. That's why I quickly gave up on ddoc.
>>>
>>>
>>>
>>> My doc generator just pipes special input text through the latex program
>>> to
>>> generate an image, which is then inlined in the html:
>>>
>>> http://dpldocs.info/experimental-docs/test.html
>>
>>
>> Now we're talking!
>
>
> That strikes me as an inferior solution to what's available today, which is
> used at http://erdani.com/d/DIP1000-typing-baseline.html.

I'm guessing that's mathjax? Strangely, it renders really badly on my
system. I can barely read it.
I'd still rather use latex to produce images for my own docs.

Re: Using OpenGL

[Mike Parker via Digitalmars-d-learn]

On Thursday, 15 September 2016 at 19:03:22 UTC, Darren wrote:



This is the code I'm using: 
https://dfcode.wordpress.com/2016/09/15/texcodewip/

(The code for the shaders is at the bottom)

For comparison, this is the code I'm trying to make work:
http://www.learnopengl.com/code_viewer.php?code=getting-started/textures


I don't have time to try and test this myself, but this looks 
like a potential problem here:


```
auto textureFormat = surface.format.format;
glTexImage2D(GL_TEXTURE_2D, 0, surface.format.BytesPerPixel, 
surface.w, surface.h, 0, textureFormat, GL_UNSIGNED_BYTE, 
surface.pixels);

```

You're passing an SDL enum value to OpenGL, which knows 
absolutely nothing about SDL enum values. Rather than passing 
surface.format.format directly to OGL, you need to first match it 
to the appropriate OGL format enum and pass *that*, which is what 
I tried to explain in my previous post. This is easily done by 
making a function which contains a switch statement iterating all 
of the SDL_PIXELFORMAT_* values and returning the equivalent GL_* 
value.


At any rate, if you're using the same image as the example, you 
don't need to do that in this specific case. You can safely 
ignore surface.format.format and simply pass GL_RGB, which is 
what the example uses. You only need to do the SDL->GL conversion 
for a texture loader that is intended to load multiple pixel 
formats.

Re: iPhone vs Android

[Chris Wright via Digitalmars-d]

On Wed, 14 Sep 2016 13:37:03 +, Laeeth Isharc wrote:

> On Wednesday, 14 September 2016 at 13:28:45 UTC, finalpatch wrote:
>> On Tuesday, 13 September 2016 at 18:24:26 UTC, deadalnix wrote:
>>> No you don't, as how often the GC kicks in depend of the rate at which
>>> you produce garbage, which is going to be very low with an hybrid
>>> approach.
>>
>> This is simply not true.
>>
>> Assume in a pure GC program the GC heap can grow up to X Mb before a
>> collection cycle happens, which has to scan X Mb of memory.
>>
>> Now let's say we have a hybrid program that uses 0.5X Mb of RCed memory
>> and 0.5X Mb of GC memory so the total memory consumption is still X Mb.
>> When the GC heap reaches 0.5X Mb, it has to scan both RC and GC memory.
> 
> Could you elaborate?

You can store a pointer to a GC-owned memory block inside an RCed object, 
just like how you can store a pointer to a GC-owned memory block on the 
stack.

There are three ways to handle this:

* Keep a pointer to the GCed object inside GCed memory.
* Tell the GC to pin the object, preventing it from being collected.
* Have the GC scan RCed memory as well as GC-owned memory.

Re: Critque of Rust's collection types

[sarn via Digitalmars-d]

On Thursday, 15 September 2016 at 10:13:47 UTC, cym13 wrote:
DoS by collision attack are a form of preimage. The idea is to 
generate intentional collisions to force heavy computations on 
serveur side. It only works if finding collisions many 
collisions for the same hash is cheap which is directly linked 
to the ability to find a value that gives a given hash 
(although it doesn't have to be easy to find any hash).


As a counterexample, collision attacks on MD5 are cheap and 
practical, but preimage attacks are still theoretical.


Self-plug, but I wrote a bit more about hash function attacks a 
little while back:

https://theartofmachinery.com/2016/01/03/what_difference_can_order_make_when_hashing.html

Re: The worst Phobos template (in binderoo)

[Stefan Koch via Digitalmars-d]

On Thursday, 15 September 2016 at 23:25:34 UTC, Stefan Koch wrote:
On Thursday, 15 September 2016 at 23:08:54 UTC, Andrei 
Alexandrescu wrote:


Yes, that DIP.[http://wiki.dlang.org/DIP57] It would need some 
more formal work before defining an implementation. Stefan, 
would you want to lead that effort? -- Andrei


I am not good at defining semantics, yet I would participate in 
a joint effort with Timon.


I thought some more about this. static foreach is probably not a 
good idea at this point.


We should focus on getting the existing features to do their job 
properly and we won't have to add yet more meanings to the word 
static.


Our code-generation facilities with CTFE and mixins are very good 
indeed.
When polished CTFE can totally be used as a serious workhorse for 
cases that would have fallen intro the static foreach category.

Re: vibe.d maxRequestSize

[sarn via Digitalmars-d-learn]

I hope this isn't too obvious, but I have to ask because it's 
such a common gotcha:


Are you reverse proxying through a server like nginx by any 
chance?  There are default request size limits there.  (For nginx 
specifically, it's this one:

https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size)

Re: colour lib needs reviewers

[Walter Bright via Digitalmars-d]

On 9/15/2016 4:59 AM, Nemanja Boric wrote:

On Thursday, 15 September 2016 at 09:45:26 UTC, Marco Leise wrote:

Am Wed, 14 Sep 2016 23:44:16 -0700
schrieb Walter Bright :

I suspect that adding Markdown would help a lot (yes, I changed my mind about
that).




https://github.com/kiith-sa/harbored-mod provides support for mixing ddoc and
markdown. That's what we're using, and it's nice (especially because docs in
source files look very close to generated ones), but it would be nicer if we
could just use dmd for that, of course.


It looks like you've done some great work with this! And Boost licensed, too! I 
think we can leverage this for Ddoc markdown support. Thanks!

Re: colour lib needs reviewers

[Walter Bright via Digitalmars-d]

On 9/15/2016 7:37 AM, Jacob Carlborg wrote:

Yeah, if you already have defined all the standard ddoc macros because the
default styling is not useful at all.


The default styling was set up to produce legible output while not requiring any 
configuration file, nor a .css style file nor any knowledge of HTML at all.

Re: colour lib needs reviewers

[Walter Bright via Digitalmars-d]

Started a new thread on this, "Ddoc macro syntax". Please direct further 
discussion there.

Ddoc macro syntax

[Walter Bright via Digitalmars-d]

On 9/15/2016 4:06 AM, Andrei Alexandrescu wrote:
> I was thinking more about it and figured we could introduce a special macro at
> the very beginning of a .ddoc file or "Macros:" section called
> DDOC_MACRO_CALL_SYNTAX. It may be defined one of the following:
>
> DDOC_MACRO_CALL_SYNTAX = DDOC
>
> That's today's syntax.
>
> DDOC_MACRO_CALL_SYNTAX = CPP
>
> A macro will be invoked as MACRO(a1, a2).

That will break every usage of function calling examples. (It works in CPP 
because if MACRO is not a macro, the text is left unchanged. In Ddoc, a 
non-existent macro is replaced by the empty string.)



> DDOC_MACRO_CALL_SYNTAX = $CPP
>
> A macro will be invoked as $MACRO(a1, a2)
>
> DDOC_MACRO_CALL_SYNTAX = LaTeX
>
> Macro invocation is \MACRO{a1}{a2}.
>
> This definition is modular, i.e. it doesn't carry beyond the current document
> (otherwise the semantics of a .dd file depends on the .ddoc file(s) it's used
> with).
>
> Macro definitions stay the same using $1, $2 etc. but macros invoked by them
> would need to obey the DDOC_MACRO_CALL_SYNTAX defined at the top.


Alternatives:
1. accept more than one syntax
2. have the first encountered usage set the mode

Re: DIP1000

[Timon Gehr via Digitalmars-d]

On 16.09.2016 01:07, Andrei Alexandrescu wrote:

On 9/15/16 5:14 PM, Timon Gehr wrote:

struct can either be annotated or not annotated, the fields cannot be
treated independently (which is one of the weaknesses of DIP1000).


I was planning to allow scope annotations for struct fields. -- Andrei


I see. In that case, single-parameter functions only is probably okay.

Re: The worst Phobos template (in binderoo)

[Stefan Koch via Digitalmars-d]

On Thursday, 15 September 2016 at 23:08:54 UTC, Andrei 
Alexandrescu wrote:


Yes, that DIP. It would need some more formal work before 
defining an implementation. Stefan, would you want to lead that 
effort? -- Andrei


I am not good at defining semantics, yet I would participate in a 
joint effort with Timon.


Be aware though that I am currently working at improving 
templates.

And there might a significant win to be had.

Re: The worst Phobos template (in binderoo)

[Stefan Koch via Digitalmars-d]

On Thursday, 15 September 2016 at 22:58:12 UTC, Stefan Koch wrote:

The Performance-Penalty will be less then on templates.
Let me add a disclaimer, I _think_ the performance penalty _can_ 
be less then the penalty on templates.


Also static if can sometimes lead to counter-intuitive situations,
static foreach will likely be worse in that regard.

Implementation issues aside, and the DIP aside.
What would be the semantics you would want for this ?

Re: ddox table issue

[Andrei Alexandrescu via Digitalmars-d]

On 9/15/16 4:17 PM, Andrei Alexandrescu wrote:

Lodovoco noticed that ddox renders a table wrongly, see the first (and
incomplete) table at


Sorry for misspelling Lodovico's name. BTW is he still around? -- Andrei

Re: The worst Phobos template (in binderoo)

[Andrei Alexandrescu via Digitalmars-d]

On 9/15/16 7:08 PM, Andrei Alexandrescu wrote:

Yes, that DIP. It would need some more formal work before defining an
implementation. Stefan, would you want to lead that effort? -- Andrei


Actually I see Timon authored that (I thought it's an older DIP by 
Walter). Timon, would you want to finalize the definition so Stefan can 
write an implementation? Thx! -- Andrei

Re: The worst Phobos template (in binderoo)

[Andrei Alexandrescu via Digitalmars-d]

On 9/15/16 6:58 PM, Stefan Koch wrote:

On Thursday, 15 September 2016 at 14:43:16 UTC, Stefan Koch wrote:

On Thursday, 15 September 2016 at 14:38:41 UTC, Andrei Alexandrescu
wrote:

On 09/15/2016 10:08 AM, Stefan Koch wrote:

static foreach on the other hand is a whole new can of worms.
As walter will be able to tell you.


It's time to open it. -- Andrei


Please give me an example on how it should work.


Are we talking about http://wiki.dlang.org/DIP57 ?

I think I can give you a partial solution for that.
The Performance-Penalty will be less then on templates.

However I can smell a bunch of un-intuitive corner-cases hiding in there.


Yes, that DIP. It would need some more formal work before defining an 
implementation. Stefan, would you want to lead that effort? -- Andrei

Re: DIP1000

[Andrei Alexandrescu via Digitalmars-d]

On 9/15/16 5:14 PM, Timon Gehr wrote:

struct can either be annotated or not annotated, the fields cannot be
treated independently (which is one of the weaknesses of DIP1000).


I was planning to allow scope annotations for struct fields. -- Andrei

Re: The worst Phobos template (in binderoo)

[Stefan Koch via Digitalmars-d]

On Thursday, 15 September 2016 at 14:43:16 UTC, Stefan Koch wrote:
On Thursday, 15 September 2016 at 14:38:41 UTC, Andrei 
Alexandrescu wrote:

On 09/15/2016 10:08 AM, Stefan Koch wrote:

static foreach on the other hand is a whole new can of worms.
As walter will be able to tell you.


It's time to open it. -- Andrei


Please give me an example on how it should work.


Are we talking about http://wiki.dlang.org/DIP57 ?

I think I can give you a partial solution for that.
The Performance-Penalty will be less then on templates.

However I can smell a bunch of un-intuitive corner-cases hiding 
in there.

Re: Meaning of DMD flag -transition=safe

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, September 15, 2016 21:36:07 Nordlöw via Digitalmars-d-learn 
wrote:
> What's the meaning of the DMD flag
>
> -transition=safe
>
> ?
>
> Is it new? I haven't seen it before.

Well, it wasn't in 2.071. I would guess that it has to do with some of the
work that Walter has been doing to tighten up @safe. A number of things that
were incorrectly considered @safe are now considered @system, and that will
potentially break a lot of code. So, that flag is probably for managing that
transitition (Walter has made a lot of PRs for druntime and phobos to fix
@safe related issues because of it).

- Jonathan M Davis

[Issue 16193] opApply() doesn't heap allocate closure

[via Digitalmars-d-bugs]

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

--- Comment #9 from Walter Bright  ---
Related spec change:

https://github.com/dlang/dlang.org/pull/1473

--

Re: ddox table issue

[Andrei Alexandrescu via Digitalmars-d]

On 9/15/16 5:29 PM, ag0aep6g wrote:

On Thursday, 15 September 2016 at 20:17:54 UTC, Andrei Alexandrescu wrote:

http://dtest.thecybershadow.net/artifact/website-b243266be0bd9e2a1d56da2d9e76c9e44689e1dd-17113e48d3b1f18b74e0fea1fa8e64ab/web/library-prerelease/std/experimental/checkedint.html


The table abruptly end with  upon seeing the first comma. I
looked to see whether ddox defines TABLE, TR, or TD differently but it
all looks legit. Does anyone know what's going on?


Care to link the source, too?


https://github.com/dlang/phobos/pull/4613

Re: bug?

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, September 15, 2016 15:15:49 Jonathan M Davis via Digitalmars-d-
learn wrote:
> On Thursday, September 15, 2016 18:15:52 deed via Digitalmars-d-learn wrote:
> > I'm curious when you would need to do only `new Struct[](1000);`
> > instead of
> > `auto structs = new Struct[](1000);`?
>
> Need to do? Probably never. It would be a pretty weird thing to do. But if
> Struct has a destructor that actually does stuff, then
>
> new Struct[](1000);
>
> does not have no effect. Because the array is allocated on the GC heap, it's
> unknown when the destructors will run (and they may not ever actually run,
> because they'll only be run if a collection is run, and it collects that
> array), but it's still the case that removing that line will potentially
> change what the program does beyond just perfomance.
>
> For instance, as dumb as it would be, the destructor for Struct could do
> something like send an e-mail when it's run, and so if the compiler
> optimized out the array of Structs being allocated, those e-mails would not
> be sent, and the behavior of the program would change substantially.
>
> It would be a pretty rare case where it actually made sense for the
> programmer to just allocate an array like that and the let it go away. But
> the compiler has no way of knowing what the programmer intended. And if
> there's code that's actually run as a result of that line, then it's not
> true that it doesn't have any effect, and creating an error over it would be
> a bit much. Some compilers might warn about it, because the odds are very
> high that it was not intended, but Walter isn't big on warnings, and dmd
> didn't even have any for a long time - though he eventually did get worn
> down enough by requests for them that he gave in and added a few.
>
> The problem with warnings is that it's bad practice to leave warnings in
> your code (otherwise, it becomes way to easy to miss legitimate things that
> you've been warned about). And if you're not leaving warnings in your code,
> then they're really not any different from errors except for the fact that
> you don't have to immediately fix them to get your code to compile. So,
> arguably, warnings are pretty pointless, and that sort of thing is better
> left to a linter tool.  And something like _that_ probably would warn about
> code like this, because the odds are quite high that it's not what you meant
> to do.
>
> In general though, dmd tends to tell you when you did something definitely
> wrong but not say anything when you did something that you probably didn't
> mean to do but was perfectly legal.

I should probably point out that the issue here isn't really specifically
with

new Struct[](100);

but rather with any statement that "has no effect." Once you start warning
about that, it can open a bit of a pandora's box - especially when it comes
to metaprogramming, which will often purposefully have statements that have
no effect, just so that it can test whether they compile.

But even without that, once you take stuff like constructors and destructors
into account, most statements potentially have an effect, making it so that
the number warnings that you could actualy give isn't necessarily all that
high. In comparison to C++, the fact that we don't have default constructors
for structs increases the number of cases where code can legitimately be
determined to have no effect, and the fact that we have pure functions can
do the same, but it's still the case that most statements that realistically
have no effect do run arbitrary code that the compiler would have to have
access to (which it doesn't always) and do a thorough examination of in
order to be sure that it truly has no effect. So, even if we had lots of
warnings in dmd and were looking to warn about something like this, it would
probably only make sense to warn for the really basic cases; otherwise, the
compiler ends up doing a lot of extra work for virtually no benefit, and in
many cases would be forced to assume that the code is doing something
anyway, because D's compilation model does not lend itself to deep
inspection of functions.

- Jonathan M Davis

Re: bug?

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, September 15, 2016 18:15:52 deed via Digitalmars-d-learn wrote:
> I'm curious when you would need to do only `new Struct[](1000);`
> instead of
> `auto structs = new Struct[](1000);`?

Need to do? Probably never. It would be a pretty weird thing to do. But if
Struct has a destructor that actually does stuff, then

new Struct[](1000);

does not have no effect. Because the array is allocated on the GC heap, it's
unknown when the destructors will run (and they may not ever actually run,
because they'll only be run if a collection is run, and it collects that
array), but it's still the case that removing that line will potentially
change what the program does beyond just perfomance.

For instance, as dumb as it would be, the destructor for Struct could do
something like send an e-mail when it's run, and so if the compiler
optimized out the array of Structs being allocated, those e-mails would not
be sent, and the behavior of the program would change substantially.

It would be a pretty rare case where it actually made sense for the
programmer to just allocate an array like that and the let it go away. But
the compiler has no way of knowing what the programmer intended. And if
there's code that's actually run as a result of that line, then it's not
true that it doesn't have any effect, and creating an error over it would be
a bit much. Some compilers might warn about it, because the odds are very
high that it was not intended, but Walter isn't big on warnings, and dmd
didn't even have any for a long time - though he eventually did get worn
down enough by requests for them that he gave in and added a few.

The problem with warnings is that it's bad practice to leave warnings in
your code (otherwise, it becomes way to easy to miss legitimate things that
you've been warned about). And if you're not leaving warnings in your code,
then they're really not any different from errors except for the fact that
you don't have to immediately fix them to get your code to compile. So,
arguably, warnings are pretty pointless, and that sort of thing is better
left to a linter tool.  And something like _that_ probably would warn about
code like this, because the odds are quite high that it's not what you meant
to do.

In general though, dmd tends to tell you when you did something definitely
wrong but not say anything when you did something that you probably didn't
mean to do but was perfectly legal.

- Jonathan M Davis

Re: Metaprogramming with traits

[Ram_B via Digitalmars-d-learn]

On Thursday, 15 September 2016 at 15:56:56 UTC, Gary Willoughby 
wrote:

On Thursday, 15 September 2016 at 15:07:09 UTC, Ram_B wrote:
How i can get fields of derived classes in runtime? This not 
works


What about something like this:

import std.traits;
import std.stdio;

class A {
int a,b;
this(){}
void fields(this T)(){
writeln(FieldNameTuple!(T));
foreach(Class; TransitiveBaseTypeTuple!(T)) {
writeln(FieldNameTuple!(Class));
}
}
}

class B : A{
int c;
this(){}
}

class C : B{
int d;
this(){}
}
void main(){
C c = new C();
c.fields();
}


This works, but i can't use (get|has)Member
class A{
int a, b;
Array!string fields(this T)(){
Array!string list;
foreach(field; FieldNameTuple!(T)){
list.insertBack(field);
}
foreach(Class; TransitiveBaseTypeTuple!(T)){
foreach(field; FieldNameTuple!(Class)){
list.insertBack(field);
}
}
return list;
}
void t(this T)(){
foreach(f; this.fields()){
log(__traits(hasMember, T, f)); 
}
}
}

class B : A{
int c;
this(){}
}

void main(){
B b = new B();
b.t();
}

test.d(33): Error: variable f cannot be read at compile time
test.d(33): Error: string expected as second argument of __traits 
hasMember instead of __error
test.d(46): Error: template instance test.A.t!(B) error 
instantiating

Window x64, LDC, Derelict : unable to compile

[Patric Dexheimer via Digitalmars-d-learn]

LLVM D compiler (1a7070): based on DMD v2.071.2-b2 and LLVM 
3.9.0git-fbbabf3


command: dub run --build=release --arch=x86_64 
--compiler=D:/ldc/bin/ldc2.exe


Output:

Performing "release" build using D:/ldc/bin/ldc2.exe for x86_64.
derelict-util 2.0.6: building configuration "library"...
Error: failed to create path to file: 
.dub\obj\..\..\AppData\Roaming\dub\packages\derelict-util-2.0.6\derelict-util\.dub\build\library-release-windows-x86_64-ldc_0-E1A9179AF0D6E609F102DF89BE3F74F1\DerelictUtil.lib

no such file or directory
D:/ldc/bin/ldc2.exe failed with exit code 1.


changing to DMD compiler works properly.

Re: iPhone vs Android

[R via Digitalmars-d]

On Monday, 12 September 2016 at 22:57:23 UTC, Andrei Alexandrescu 
wrote:
[snip] If it is, that provides more impetus for reference 
counting for D by the following logic: (a) it is likely that in 
the future more code will run on portable, battery-powered 
systems; (b) battery power does not follow a Moore trajectory, 
so at this point in history demand for battery lifetime is 
elastic.



Andrei


I'm keen on reference counting because of embedded and bare-metal 
programming so I'm super keen on D having a short reference long 
garbage standard. I guess we already do this to some extent with 
scope etc.


Battery life can last for years in some of the new embedded 
devices but most languages targeting the M0 etc are really 
archaic, I have seen a rust port somewhere... but if I'm honest I 
only really care for D so I really want LDC -> ARM M0 etc... :D

Re: colour lib needs reviewers

[Bastiaan Veelo via Digitalmars-d]

On Thursday, 15 September 2016 at 09:46:07 UTC, Patrick Schluter 
wrote:
There are also some niceties like auto brief and 
autoreferencing (when a symbol is written in a text will be 
clickable if its body was reachable during generation of the 
doc).


Not only that, by using tag files [1] Doxygen even generates 
clickable symbols to third party libraries and other online 
documentation, without having access to the respective code.


[1] 
http://www.stack.nl/~dimitri/doxygen/manual/config.html#config_external

Meaning of DMD flag -transition=safe

[Nordlöw via Digitalmars-d-learn]

What's the meaning of the DMD flag

-transition=safe

?

Is it new? I haven't seen it before.

Re: ddox table issue

[ag0aep6g via Digitalmars-d]

On Thursday, 15 September 2016 at 20:17:54 UTC, Andrei 
Alexandrescu wrote:

http://dtest.thecybershadow.net/artifact/website-b243266be0bd9e2a1d56da2d9e76c9e44689e1dd-17113e48d3b1f18b74e0fea1fa8e64ab/web/library-prerelease/std/experimental/checkedint.html

The table abruptly end with  upon seeing the first 
comma. I looked to see whether ddox defines TABLE, TR, or TD 
differently but it all looks legit. Does anyone know what's 
going on?


Care to link the source, too?

Re: struct dynamic allocation error

[Steven Schveighoffer via Digitalmars-d]

On 9/15/16 4:38 PM, Dechcaudron wrote:

I believe there is some kind of weird issue that won't allow for struct
instances to be dynamically allocated in a proper way via the 'new'
keyword. It does actually allocate them and return a valid pointer to
operate the instances, but whenever the program is exited I get the
following exception:

core.exception.InvalidMemoryOperationError@src/core/exception.d(693):
Invalid memory operation


This is because you are allocating in the destructor.



Calling 'destroy' on the returned pointer only seems to set it to null,
but it definitely doesn't call the destructor, neither does it prevent
said exception from being raised. Code to reproduce:

```
import std.conv;
import std.stdio;

struct Foo
{
int a;

this(int a)
{
this.a = a;
}

~this()
{
writeln("a is " ~ to!string(a));
}
}

void main()
{
Foo a = Foo(5);
Foo* b = new Foo(10);
writeln("Allocation complete");
destroy(b); //Does nothing
//Destructor for a is called
}
```


You need to destroy structs by passing them by reference. Passing a 
pointer just destroys the pointer.


In this example, you can destroy what b points at (and call its 
destructor) via:


destroy(*b);

However, this will not fix the issue. This is because the memory block 
is not marked as being destroyed already (so it will run the dtor 
again). Class instances have a feature whereby when you call destroy it 
marks the memory block as already having the destructor run. Structs do 
not have this feature. Classes can afford to store extra metadata, 
structs cannot.


So the true fix here is to avoid allocating in the destructor (which is 
a no-no for heap-allocated items). This may work, it may not:


writefln("a is %s", a);

I'm not sure if any memory allocation happens there, but if not, you 
should be OK.


-Steve

Re: struct dynamic allocation error

[Ali Çehreli via Digitalmars-d]

On 09/15/2016 01:38 PM, Dechcaudron wrote:

I believe there is some kind of weird issue that won't allow for struct
instances to be dynamically allocated in a proper way via the 'new'
keyword. It does actually allocate them and return a valid pointer to
operate the instances, but whenever the program is exited I get the
following exception:

core.exception.InvalidMemoryOperationError@src/core/exception.d(693):
Invalid memory operation

Calling 'destroy' on the returned pointer only seems to set it to null,
but it definitely doesn't call the destructor, neither does it prevent
said exception from being raised. Code to reproduce:

```
import std.conv;
import std.stdio;

struct Foo
{
int a;

this(int a)
{
this.a = a;
}

~this()
{
writeln("a is " ~ to!string(a));


That operation allocates from the GC, which is not allowed when GC is 
doing a collection. In this case, you can replace with the following:


fprintf(stdout.getFP, "a is %d\n", a);


}
}

void main()
{
Foo a = Foo(5);
Foo* b = new Foo(10);
writeln("Allocation complete");
destroy(b); //Does nothing


That's a common gotcha. Unfortunately, you're destroying the pointer 
itself. :/ Try this:


destroy(*b);
assert(b.a == int.init);


//Destructor for a is called
}
```


I describe the destroy() with struct pointer problem here:

  http://ddili.org/ders/d.en/memory.html#ix_memory.destroy

Lastly, we have the Learn forum where this question would be more 
appreciated. :)


Ali

Re: DIP1000

[Timon Gehr via Digitalmars-d]

On 15.09.2016 14:57, Andrei Alexandrescu wrote:



Multiparameter functions can be declared to be equivalent to

struct P { S* s; int* r; }
P p;
p.s = 
p.r = getPayload(s);
f(p); //as if f(S*,int*)


Thanks for making this point.


This fails when considering scope and return annotations though. 
Parameters can be annotated or not annotated with scope/return scope 
independently, but the struct can either be annotated or not annotated, 
the fields cannot be treated independently (which is one of the 
weaknesses of DIP1000).

Re: struct dynamic allocation error

[Stefan Koch via Digitalmars-d]

On Thursday, 15 September 2016 at 20:38:45 UTC, Dechcaudron wrote:
I believe there is some kind of weird issue that won't allow 
for struct instances to be dynamically allocated in a proper 
way via the 'new' keyword. It does actually allocate them and 
return a valid pointer to operate the instances, but whenever 
the program is exited I get the following exception:


[...]


I would think the GC tries to collect the object which you 
destroyed before.


But I cannot be sure. I avoid the gc.

Re: Can vibe d leverage existing web technologies?

[Intersteller via Digitalmars-d-learn]

On Thursday, 15 September 2016 at 14:31:28 UTC, Martin 
Tschierschke wrote:
On Tuesday, 13 September 2016 at 23:45:18 UTC, Intersteller 
wrote:
vibe.d does not have much lateral support as the most commons 
web technologies do.  Can vibe.d leverage pre-existing techs 
such as php, ruby/rails, etc? Starting from scratch and having 
to build a robust and secure framework is really not the way 
to go.


A good way to mix different technologies is to use a Apache or 
nginx proxy on the same server, so you can start using vibe.d 
for some parts and keep the rest at its place.


Regards mt.


How is this done? How can it be done smoothly? I'm not sure how 
to partition the work load. While, say, some pages might be 
served from php, and others from vibe2, etc, it seems like it 
would be nightmare to maintain consistency and interactivity.

Re: D Boston September Meetup

[Steven Schveighoffer via Digitalmars-d-announce]

On 9/6/16 10:01 AM, Steven Schveighoffer wrote:

Posted here:
https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/233871852/


A reminder that this is happening tonight!

See you there.

-Steve

Re: Metaprogramming with traits

[Ram_B via Digitalmars-d-learn]

On Thursday, 15 September 2016 at 15:56:56 UTC, Gary Willoughby 
wrote:

On Thursday, 15 September 2016 at 15:07:09 UTC, Ram_B wrote:
How i can get fields of derived classes in runtime? This not 
works


What about something like this:

import std.traits;
import std.stdio;

class A {
int a,b;
this(){}
void fields(this T)(){
writeln(FieldNameTuple!(T));
foreach(Class; TransitiveBaseTypeTuple!(T)) {
writeln(FieldNameTuple!(Class));
}
}
}

class B : A{
int c;
this(){}
}

class C : B{
int d;
this(){}
}
void main(){
C c = new C();
c.fields();
}


Thanks very much! :3

struct dynamic allocation error

[Dechcaudron via Digitalmars-d]

I believe there is some kind of weird issue that won't allow for 
struct instances to be dynamically allocated in a proper way via 
the 'new' keyword. It does actually allocate them and return a 
valid pointer to operate the instances, but whenever the program 
is exited I get the following exception:


core.exception.InvalidMemoryOperationError@src/core/exception.d(693): Invalid 
memory operation

Calling 'destroy' on the returned pointer only seems to set it to 
null, but it definitely doesn't call the destructor, neither does 
it prevent said exception from being raised. Code to reproduce:


```
import std.conv;
import std.stdio;

struct Foo
{
int a;

this(int a)
{
this.a = a;
}

~this()
{
writeln("a is " ~ to!string(a));
}
}

void main()
{
Foo a = Foo(5);
Foo* b = new Foo(10);
writeln("Allocation complete");
destroy(b); //Does nothing
//Destructor for a is called
}
```

Aerpspike for vibe.d?

[Intersteller via Digitalmars-d-learn]

Anyone got any info on it?

Re: checkedint submission

[jmh530 via Digitalmars-d]

On Thursday, 15 September 2016 at 20:07:40 UTC, Robert burner 
Schadek wrote:
The last commit to https://github.com/andralex/checkedint was 
21 days ago? Something is off! Or was the last change to 
checkedint 21 days ago?


The first post has him committing to std.experimental.checkedint.

Re: checkedint submission

[Robert burner Schadek via Digitalmars-d]

Who is your review manager?

ddox table issue

[Andrei Alexandrescu via Digitalmars-d]

Lodovoco noticed that ddox renders a table wrongly, see the first (and 
incomplete) table at


http://dtest.thecybershadow.net/artifact/website-b243266be0bd9e2a1d56da2d9e76c9e44689e1dd-17113e48d3b1f18b74e0fea1fa8e64ab/web/library-prerelease/std/experimental/checkedint.html

The table abruptly end with  upon seeing the first comma. I 
looked to see whether ddox defines TABLE, TR, or TD differently but it 
all looks legit. Does anyone know what's going on?



Thanks,

Andrei

Re: checkedint submission

[Robert burner Schadek via Digitalmars-d]

The last commit to https://github.com/andralex/checkedint was 21 
days ago? Something is off! Or was the last change to checkedint 
21 days ago?

[Issue 16499] New: Useless error message for 'in' expressions

[via Digitalmars-d-bugs]

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

  Issue ID: 16499
   Summary: Useless error message for 'in' expressions
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: yshu...@gmail.com

struct B {
int k;
void* opBinaryRight(string op)(int x) if (op == "in") {
return 
}
}
void main() {
B c;

import std.stdio;
writeln(10 in c);
writeln(1.0 in c);
}

The error reported is:

"Error: rvalue of in expression must be an associative array, not B"

Which is not true, and useless.

--

Re: Using OpenGL

[Darren via Digitalmars-d-learn]

On Thursday, 15 September 2016 at 02:11:03 UTC, Mike Parker wrote:

//snip


Okay the crashing was my fault, more or less a copy-paste error.  
The program now runs but has a black rectangle where a texture 
should be.


This is the code I'm using: 
https://dfcode.wordpress.com/2016/09/15/texcodewip/

(The code for the shaders is at the bottom)

For comparison, this is the code I'm trying to make work:
http://www.learnopengl.com/code_viewer.php?code=getting-started/textures

Re: New reviewing flow on github

[Robert burner Schadek via Digitalmars-d]

They also have kanban style project management stuff now.
I would really like to see anything (bugzilla, trello) moved to 
github.

Re: checkedint submission

[Andrei Alexandrescu via Digitalmars-d]

On 09/15/2016 02:38 PM, Robert burner Schadek wrote:

could you please update the dub package


Did this just now:

git commit -am "Add const/immutable support"
git tag v0.0.3
git push -u origin master
git push --tags

Is this all? Thx!


Andrei

Re: colour lib needs reviewers

[Andrei Alexandrescu via Digitalmars-d]

On 09/15/2016 02:34 PM, Jacob Carlborg wrote:

On 2016-09-15 14:54, Andrei Alexandrescu wrote:


Yah, this is terrible (it happens with http: all the time). We need to
suppress the special meaning of ":" to only the cases when it's preceded
by only one word and followed by a newline, e,g, "\ncolor:\n".


It's useful for many of the sections to allow the section name on the
same line as the content:

/// Returns: some useful value
int foo();

See the Ddoc documentation for more examples [1].


That's fine because "Returns" is special-cased. Random words at the 
beginning of a line followed by ":" should not receive special treatment.



Can this be done by defining the expansion macros appropriately?


What are "the expansion macros" ?


Those DDOC_XXX things that are used for formatting declarations.


Slashes are tolerable. The underscore I agree it's a quirk.


There are several (other) problems:

* How do I know I should use slashes? There's no documentation


"Monkey see, monkey do." :o)


* It's not a standard macro. If it's not here [2] nobody will find it or
use it


Guess we can improve the (d)docs.


That's a fair assessment, and an actionable one.


Perhaps the current implementation of Ddoc could be moved to a separate
tool that would focus on being a macro system. That can still be used
for the site and other documents. Ddoc in the compiler could be improved
to be a better tool for documenting code. I think these are two separate
use cases that might not be best accomplished with the same tool.


That'd be neat. As always, somebody's got to do it...


Andrei

Re: checkedint submission

[Robert burner Schadek via Digitalmars-d]

could you please update the dub package

Re: colour lib needs reviewers

[Jacob Carlborg via Digitalmars-d]

On 2016-09-15 16:45, Andrei Alexandrescu wrote:


Glad to hear that. It becomes a matter of improving the default-provided
macros and/or distribute some .ddoc batteries.

Jacob, I'd also like to thank for the great constructive ideas for
improving things and for formulating them as enhancement requests on
bugsilla. This is the kind of communication that pushes things forward.


The oldest bugzilla issue I referred to is more than four years old and 
this is not the first discussion on the topic :(


--
/Jacob Carlborg

Re: colour lib needs reviewers

[Jacob Carlborg via Digitalmars-d]

On 2016-09-15 14:54, Andrei Alexandrescu wrote:


Yah, this is terrible (it happens with http: all the time). We need to
suppress the special meaning of ":" to only the cases when it's preceded
by only one word and followed by a newline, e,g, "\ncolor:\n".


It's useful for many of the sections to allow the section name on the 
same line as the content:


/// Returns: some useful value
int foo();

See the Ddoc documentation for more examples [1].


Can this be done by defining the expansion macros appropriately?


What are "the expansion macros" ?


Slashes are tolerable. The underscore I agree it's a quirk.


There are several (other) problems:

* How do I know I should use slashes? There's no documentation
* It's not a standard macro. If it's not here [2] nobody will find it or 
use it



That's a fair assessment, and an actionable one.


Perhaps the current implementation of Ddoc could be moved to a separate 
tool that would focus on being a macro system. That can still be used 
for the site and other documents. Ddoc in the compiler could be improved 
to be a better tool for documenting code. I think these are two separate 
use cases that might not be best accomplished with the same tool.


[1] http://dlang.org/spec/ddoc.html#standard_srction
[2] http://dlang.org/spec/ddoc.html#predefined_macros

--
/Jacob Carlborg

Re: colour lib needs reviewers

[Meta via Digitalmars-d]

On Wednesday, 14 September 2016 at 20:14:48 UTC, Andrei 
Alexandrescu wrote:

On 09/14/2016 09:47 AM, Meta wrote:

On Wednesday, 14 September 2016 at 13:28:23 UTC, Manu wrote:

Cheers.
Yeah, I need to do better with ddoc.

... I'm just gonna go on the record and say that I am really, 
really

not enjoying ddoc ;)


I can't say I'm a fan either.


Why? -- Andrei


The syntax is clunky and it's poorly documented. I've been 
lurking this mailing list since late 2012 and sporadically 
contributing since late 2013, and I had no idea you could do 
something like your example for Manu using DDOC. It seems like a 
real case of NiH syndrome; there are plenty of more widely used 
systems that would probably fit D just fine, but instead we have 
our own special macro documentation language. Really the only 
thing DDOC has going for it in comparison to something like 
Doxygen, IMO, is momentum. It's just too much of a pain to switch 
now.

std.algorithm.iteration.each requires opApply to have ref elements?

[Q. Schroll via Digitalmars-d-learn]

Why does it do that?
And seemingly it does not require it for opApply with more than 
two arguments.

Re: bug?

[deed via Digitalmars-d-learn]

On Thursday, 15 September 2016 at 14:42:13 UTC, Jonathan M Davis 
wrote:
On Thursday, September 15, 2016 14:07:18 deed via 
Digitalmars-d-learn wrote:
On Thursday, 15 September 2016 at 13:57:13 UTC, rikki 
cattermole


wrote:
> Not a bug, it is never used.

I'd expect an "Error: ... no effect ..." from the compiler.


That would only work in fairly simplistic cases. For instance, 
if you were allocating an array of structs instead of an array 
of ints, then it _could_ have an effect. So, it's not an error 
that would catch much. And it's not like the code is doing 
anything illegal - just useless, which is why it gets optimized 
out.


- Jonathan M Davis


I dont't feel strongly about this at all, it was just my first 
reaction that it was a meaningless statement that the compiler 
should warn about or give an error on.


I'm curious when you would need to do only `new Struct[](1000);` 
instead of

`auto structs = new Struct[](1000);`?

In case it was not clear, the code was:
char[] str;
// ...
str.length = ...
str[i] = ...

and was intended to be updated to:
char[] str = new char[](len);
// ...
str[i] = ...

but somehow the line ended up as
char[] str; new char[](len);
// ..
str[i] = ... // oops.

Re: ddoc latex/formulas?

[Johan Engelen via Digitalmars-d]

On Thursday, 15 September 2016 at 16:35:53 UTC, Andrei 
Alexandrescu wrote:

On 09/15/2016 11:43 AM, Johan Engelen wrote:


- Perhaps we can "standardize" the MathJax thing for Phobos 
docs?


Johan, do you think I could impose on you to try your hand? The 
solution would redefine DDOC as above and involve dlang.org and 
(then) std.mathspecial.


I don't want to get involved in this further, as I am not going 
to be the one using it.

Maybe allocator.dispose could nullify its parameter?

[Yuxuan Shui via Digitalmars-d]

Looks like a reasonable thing to do, e.g.:

auto p = Mallocator.instance.make!ulong(0);
Mallocator.instance.dispose(p);
assert(p is null);

Proof of concept:

void disposeX(Allocator, T)(auto ref Allocator a, ref B b) {
a.dispose(b);
b = null;
}

Re: ddoc latex/formulas?

[Johan Engelen via Digitalmars-d]

On Thursday, 15 September 2016 at 16:35:53 UTC, Andrei 
Alexandrescu wrote:


- Also, how about that parameter name problem? Any good fix 
for that?


Let's see how the underscore does.


Underscore works, updating SO example.

Re: ddoc latex/formulas?

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 15 September 2016 at 14:40:24 UTC, Andrei 
Alexandrescu wrote:
Wait, but I just showed how with vanilla ddoc you can 
immediately use mathjax to do better than adrdox. No need for 
any pre/postprocessing or scripting, just one line of import.


mathjax IS postprocessing via scripting. And better is extremely 
dubious as it is unreliable and slow for the end user...


My method of automatic server-side image replacement gives fast, 
consistent results to the reader, while being equally simple to 
write for the author. It also has the advantage of working 
offline, which is a major point for my docs because I like to use 
them while on airplanes and such.


I'm aware of these other options. I also considered generating 
MathML or SVG and decided on png because it gives the best 
balance of benefits - a small image file that works everywhere 
(including offline), though doesn't scale font sizes or respond 
to other css instructions as well as the others, I deemed those 
to be less important overall than actually displaying correctly 
by default on a wide variety of devices without a massive 
download.

checkedint submission

[Andrei Alexandrescu via Digitalmars-d]

I added support for const and immutable qualifiers to Checked:

https://github.com/dlang/phobos/pull/4613/commits/be23323dc6d510503462ee11dbdb26b7af61aa61

It took 80 lines, which is only some 3% of the code base. Most 
aggravation was in fact caused by opBinary not accepting the "this" 
template parameter. @Walter does that qualify as a bug?


By this I am asking for std.experimental.checkedint to be considered for 
inclusion in Phobos.


Code: https://github.com/dlang/phobos/pull/4613
Docs: 
http://dtest.thecybershadow.net/artifact/website-b243266be0bd9e2a1d56da2d9e76c9e44689e1dd-17113e48d3b1f18b74e0fea1fa8e64ab/web/phobos-prerelease/std_experimental_checkedint.html
Dox: 
http://dtest.thecybershadow.net/artifact/website-b243266be0bd9e2a1d56da2d9e76c9e44689e1dd-17113e48d3b1f18b74e0fea1fa8e64ab/web/library-prerelease/std/experimental/checkedint.html



Thanks,

Andrei

Re: ddoc latex/formulas?

[Andrei Alexandrescu via Digitalmars-d]

On 09/15/2016 11:43 AM, Johan Engelen wrote:

On Thursday, 15 September 2016 at 14:42:37 UTC, Andrei Alexandrescu wrote:

On 09/15/2016 10:37 AM, Johan Engelen wrote:

Btw, Ddoc is perhaps a little more than a macro system, and that's why
using parameter names in equations is broken. Parameter names are
replaced by (wait for it) a macro, so disabling that macro "fixes" the
issue. See the stackoverflow example.
http://stackoverflow.com/a/39514239/3215806


Thanks for making that point. Does the underscore prefix work? (I'll 
note that DDOC_PARAM is one of those things in the vein that many clamor 
for - do things automatically without a macro in sight...)



So indeed, the DDoc system does provide a simple way to end up with
nice-looking equations: "import" MathJax, and just write \(...\).
Excellent.

- Is there a way to "import" MathJax without having to redefine the DDOC
macro?(seems a little brittle)


Yah, I think it's suboptimal to have to redefine DDOC (which in serious 
apps has a bunch of stuff) just for a few pages that need certain stuff 
in the html head. (This is a similar issue with various entities adding 
headers to http requests.)


What an application can do is this:

CUSTOM_DDOC =



$0
$(TITLE)

$(TITLE)$(BODY)

DDOC = $(CUSTOM_DDOC)

Then, the pages that want mathjax go:

Macros:
DDOC = $(CUSTOM_DDOC src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-MML-AM_CHTML";>)


In fact I think it would be a great idea to do this right now for Phobos 
and mathspecial.


Another solution is to define and use some macro a la DDOC_EXTRA_HEADER 
(and probably DDOC_EXTRA_FOOTER) but probably the one above is simpler 
and better.



- Perhaps we can "standardize" the MathJax thing for Phobos docs? Would
be nice for Manu's color lib and for Mir too. (where are the Mir guys
anyway in this discussion? ;)


Johan, do you think I could impose on you to try your hand? The solution 
would redefine DDOC as above and involve dlang.org and (then) 
std.mathspecial.



- Also, how about that parameter name problem? Any good fix for that?


Let's see how the underscore does.


Andrei