Re: How to get return type of current method?

[Ali Çehreli via Digitalmars-d-learn]

On 04/18/2017 06:40 PM, Meta wrote:
> On Wednesday, 19 April 2017 at 00:22:14 UTC, Mike B Johnson wrote:
>> On Tuesday, 18 April 2017 at 23:49:35 UTC, ketmar wrote:
>>> Mike B Johnson wrote:
>>>
 How can I get the return type of the current method without
 specifying the name or any complexity? Similar to typeof(this).
>>>
>>> typeof(return)
>>
>> Thanks, sweet and simple!
>
> One note: if the function has a return type of `auto`, you cannot use
> `typeof(return)` within the function.

Actually that works but apparently order matters:

import std.stdio;

bool condition;

auto foo() {
// Compilation ERROR here
writeln(typeof(return).stringof);

if (condition) {
return 1.5;
}

return 42;
}

void main() {
foo();
}

Error: cannot use typeof(return) inside function foo with inferred 
return type


But if you move typeof(return) after the first return statement, which 
determines the return type of the function per spec, then it works:


auto foo() {
if (condition) {
return 1.5;
}

// Works here
writeln(typeof(return).stringof);

return 42;
}

Prints "double".

Ali

Re: Immovable types

[sarn via Digitalmars-d]

On Wednesday, 19 April 2017 at 02:53:18 UTC, Stanislav Blinov 
wrote:
I'd very much like to hear your thoughts on this, good/bad, if 
it already was proposed, anything. If it's found feasible, I 
could start a DIP. Destroy, please.


I don't have comments about the syntax, but I did want this 
feature when writing Xanthe (https://gitlab.com/sarneaud/xanthe). 
 In normal D you can make a struct instance effectively immovable 
by dynamically allocating it, but I had to allocate stuff 
statically or on the stack.

Re: hidden passing of __FILE__ and __LINE__ into function

[Dmitry via Digitalmars-d-learn]

On Tuesday, 18 April 2017 at 13:48:57 UTC, Stanislav Blinov wrote:
There's a much more concise workaround, both in code written 
and generated ;)


import std.stdio;

template func(string file = __FILE__, int line = __LINE__)
{
auto func(T...)(auto ref T args)
{
writeln("called func with ", T.length, " args at ",
file, ":", line);
}
}

void main()
{
func();
func(1, 2, 3);
}


Very nice. Thank you!

Re: Optilink bugs(or DMD)

[Stefan Koch via Digitalmars-d]

On Wednesday, 19 April 2017 at 03:52:54 UTC, Nierjerson wrote:
Major optilink bugs, blocker. Code is long but demonstrates the 
issue. Compiles with ldc.


[...]


There are two instances of void ForegroundColor(cSolidColor rhs)

Re: Optilink bugs(or DMD)

[ketmar via Digitalmars-d]

Nierjerson wrote:


Major optilink bugs, blocker.

not at optlink bug.

Optilink bugs(or DMD)

[Nierjerson via Digitalmars-d]

Major optilink bugs, blocker. Code is long but demonstrates the 
issue. Compiles with ldc.


The source is large so I uploaded it

https://ufile.io/odaee

or

https://files.fm/u/frmks29t




OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset 481D2H 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main12cApplication15ForegroundColorMFC4main11cSolidColorZv 
(void main.cApplication.ForegroundColor(main.cSolidColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset 49058H 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main12cApplication15BackgroundColorMFC4main11cSolidColorZv 
(void main.cApplication.BackgroundColor(main.cSolidColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset 89BFFH 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main9cTextItem5ColorMFC4main11cSolidColorZv (void 
main.cTextItem.Color(main.cSolidColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset A6CBEH 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main11cSolidColor3RGBMFC4main9cRGBColorZv (void 
main.cSolidColor.RGB(main.cRGBColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset A7B4BH 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main11cSolidColor4GrayMFC4main10cGrayColorZv (void 
main.cSolidColor.Gray(main.cGrayColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset A89C6H 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main11cSolidColor4CMYKMFC4main10cCMYKColorZv (void 
main.cSolidColor.CMYK(main.cCMYKColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset A9421H 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main11cSolidColor3LabMFC4main9cLabColorZv (void 
main.cSolidColor.Lab(main.cLabColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset AA29FH 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main11cSolidColor3HSBMFC4main9cHSBColorZv (void 
main.cSolidColor.HSB(main.cHSBColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset E2D37H 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main8cChannel5ColorMFC4main11cSolidColorZv (void 
main.cChannel.Color(main.cSolidColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset C1983H 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main24cExportOptionsSaveForWeb10MatteColorMFC4main9cRGBColorZv 
(void main.cExportOptionsSaveForWeb.MatteColor(main.cRGBColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset D33B4H 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main20cPresentationOptions14PDFFileOptionsMFC4main15cPDFSaveOptionsZv (void main.cPresentationOptions.PDFFileOptions(main.cPDFSaveOptions))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset D8777H 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main15cGalleryOptions13BannerOptionsMFC4main21cGalleryBannerOptionsZv (void main.cGalleryOptions.BannerOptions(main.cGalleryBannerOptions))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset D9617H 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main15cGalleryOptions13ImagesOptionsMFC4main21cGalleryImagesOptionsZv (void main.cGalleryOptions.ImagesOptions(main.cGalleryImagesOptions))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset DA4C2H 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main15cGalleryOptions16ThumbnailOptionsMFC4main24cGalleryThumbnailOptionsZv (void main.cGalleryOptions.ThumbnailOptions(main.cGalleryThumbnailOptions))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset DB36FH 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main15cGalleryOptions18CustomColorOptionsMFC4main26cGalleryCustomColorOptionsZv (void main.cGalleryOptions.CustomColorOptions(main.cGalleryCustomColorOptions))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset DC219H 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main15cGalleryOptions15SecurityOptionsMFC4main23cGallerySecurityOptionsZv (void main.cGalleryOptions.SecurityOptions(main.cGallerySecurityOptions))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset F078FH 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main26cGalleryCustomColorOptions15BackgroundColorMFC4main9cRGBColorZv (void main.cGalleryCustomColorOptions.BackgroundColor(main.cRGBColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset F163CH 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main26cGalleryCustomColorOptions11BannerColorMFC4main9cRGBColorZv (void main.cGalleryCustomColorOptions.BannerColor(main.cRGBColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset F24EAH 
Record Type 00C3
 Error 1: Previous Definition Different : 
_D4main26cGalleryCustomColorOptions9TextColorMFC4main9cRGBColorZv 
(void main.cGalleryCustomColorOptions.TextColor(main.cRGBColor))
Win32\Debug 

[Issue 17332] New: optilink or dmd bug

[via Digitalmars-d-bugs]

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

  Issue ID: 17332
   Summary: optilink or dmd bug
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: phreon...@gmail.com

Major optilink bugs, blocker. Code is long but demonstrates the issue. Compiles
with ldc.

The source is large so I uploaded it

https://ufile.io/odaee

or

https://files.fm/u/frmks29t




OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset 481D2H Record Type 00C3 
 Error 1: Previous Definition Different :
_D4main12cApplication15ForegroundColorMFC4main11cSolidColorZv (void
main.cApplication.ForegroundColor(main.cSolidColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset 49058H Record Type 00C3 
 Error 1: Previous Definition Different :
_D4main12cApplication15BackgroundColorMFC4main11cSolidColorZv (void
main.cApplication.BackgroundColor(main.cSolidColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset 89BFFH Record Type 00C3 
 Error 1: Previous Definition Different :
_D4main9cTextItem5ColorMFC4main11cSolidColorZv (void
main.cTextItem.Color(main.cSolidColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset A6CBEH Record Type 00C3 
 Error 1: Previous Definition Different :
_D4main11cSolidColor3RGBMFC4main9cRGBColorZv (void
main.cSolidColor.RGB(main.cRGBColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset A7B4BH Record Type 00C3 
 Error 1: Previous Definition Different :
_D4main11cSolidColor4GrayMFC4main10cGrayColorZv (void
main.cSolidColor.Gray(main.cGrayColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset A89C6H Record Type 00C3 
 Error 1: Previous Definition Different :
_D4main11cSolidColor4CMYKMFC4main10cCMYKColorZv (void
main.cSolidColor.CMYK(main.cCMYKColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset A9421H Record Type 00C3 
 Error 1: Previous Definition Different :
_D4main11cSolidColor3LabMFC4main9cLabColorZv (void
main.cSolidColor.Lab(main.cLabColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset AA29FH Record Type 00C3 
 Error 1: Previous Definition Different :
_D4main11cSolidColor3HSBMFC4main9cHSBColorZv (void
main.cSolidColor.HSB(main.cHSBColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset E2D37H Record Type 00C3 
 Error 1: Previous Definition Different :
_D4main8cChannel5ColorMFC4main11cSolidColorZv (void
main.cChannel.Color(main.cSolidColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset C1983H Record Type 00C3 
 Error 1: Previous Definition Different :
_D4main24cExportOptionsSaveForWeb10MatteColorMFC4main9cRGBColorZv (void
main.cExportOptionsSaveForWeb.MatteColor(main.cRGBColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset D33B4H Record Type 00C3 
 Error 1: Previous Definition Different :
_D4main20cPresentationOptions14PDFFileOptionsMFC4main15cPDFSaveOptionsZv (void
main.cPresentationOptions.PDFFileOptions(main.cPDFSaveOptions))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset D8777H Record Type 00C3 
 Error 1: Previous Definition Different :
_D4main15cGalleryOptions13BannerOptionsMFC4main21cGalleryBannerOptionsZv (void
main.cGalleryOptions.BannerOptions(main.cGalleryBannerOptions))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset D9617H Record Type 00C3 
 Error 1: Previous Definition Different :
_D4main15cGalleryOptions13ImagesOptionsMFC4main21cGalleryImagesOptionsZv (void
main.cGalleryOptions.ImagesOptions(main.cGalleryImagesOptions))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset DA4C2H Record Type 00C3 
 Error 1: Previous Definition Different :
_D4main15cGalleryOptions16ThumbnailOptionsMFC4main24cGalleryThumbnailOptionsZv
(void main.cGalleryOptions.ThumbnailOptions(main.cGalleryThumbnailOptions))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset DB36FH Record Type 00C3 
 Error 1: Previous Definition Different :
_D4main15cGalleryOptions18CustomColorOptionsMFC4main26cGalleryCustomColorOptionsZv
(void main.cGalleryOptions.CustomColorOptions(main.cGalleryCustomColorOptions))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset DC219H Record Type 00C3 
 Error 1: Previous Definition Different :
_D4main15cGalleryOptions15SecurityOptionsMFC4main23cGallerySecurityOptionsZv
(void main.cGalleryOptions.SecurityOptions(main.cGallerySecurityOptions))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset F078FH Record Type 00C3 
 Error 1: Previous Definition Different :
_D4main26cGalleryCustomColorOptions15BackgroundColorMFC4main9cRGBColorZv (void
main.cGalleryCustomColorOptions.BackgroundColor(main.cRGBColor))
Win32\Debug DMD\ConsoleApp1.obj(ConsoleApp1)  Offset F163CH Record Type 00C3 
 Error 1: Previous Definition Different :

Re: Interpolated strings

[bpr via Digitalmars-d]

On Wednesday, 19 April 2017 at 00:30:31 UTC, Walter Bright wrote:
I'm not saying you cannot do cool and useful things with AST 
macros. My position is it encourages absolutely awful code as 
(usually inexperienced) programmers compete to show how clever 
their macros are.


I'd think that that's a problem with community coding standards.

The language gets balkanized into a collection of dialects that 
are unrecognizable across user groups.


I'm pretty sure that hasn't happened with every language that 
supports macros. Even in the case of Scheme, I don't think it's 
the macros that are responsible for all of the dialects. It's the 
fact that the core language never includes enough (no records, 
exceptions, modules, ...) so every group adds their own versions 
of these features. Maybe if macros didn't make that easier then 
Schemers would have added those things to the core, but that's a 
counterfactual that I don't find convincing.


As a compiler dev who gets stuck figuring out users' bug 
reports, dealing with templates is bad enough (the first thing 
I do with a bug report is redo it to remove all the templates). 
I do not want to deal with some custom syntax. If I may pull 
the "I'm older" card, programmers will find as they gain 
experience that the AST macros are just not worth it.


Some programmers will not find that. Others will find that other 
features you value are just not worth it. There are absolutely no 
categorical statements. :-)


This disastrous state of affairs has occurred with every 
language that supports macros.


I don't think I've ever heard from Common Lisp, Scheme or Clojure 
programmers that they'd like to remove macros from their 
respective languages for the reasons you mention. I don't see the 
disasters there. The Julia folks looked at the Lisp experience 
and decided to include macros.


Both Rust and Nim support macros. Scala too. Not long enough for 
the disaster yet?


It's certainly not all roses, and writing and debugging macros 
can be a PITA. I try to avoid them, and consider them a tool of 
last resort. But they're very powerful, and sometimes I'm not 
smart enough to figure out how to do what I want cleanly with 
less powerful features.


If you want a nauseous example, check out the Boost C 
preprocessor metaprogramming library. Or C++ expression 
templates - so cool, and yet so utterly wretched.


Have you checked out examples of macros that are not so 
nauseating? I find Nim decent, and of course the Lisps have a 
long history of macrology. I think you're drawing a view of 
macros from cpp, and MASM, and such, and not so much from the 
Lisp family, or Nim. cpp macrology is very different!


D is interesting to me mostly because of it's powerful templates 
and CTFE. It seems a shame (to me, obviously) that such a 
powerful static metaprogramming feature as macros will not be a 
part of D, but it's your language!

Re: hidden passing of __FILE__ and __LINE__ into function

[Lewis via Digitalmars-d-learn]

On Monday, 17 April 2017 at 14:23:50 UTC, Jonathan M Davis wrote:
On Monday, April 17, 2017 13:45:18 Dmitry via 
Digitalmars-d-learn wrote:

[...]


Every time there's a new template instantiation, it's 
essentially copy-pasting the entire template. So, if you have 
the templated function


[...]


The other reason to avoid excessive template instantiation is 
that it inflates your compile time. A while back I changed my 
custom assertf() and logf() functions to be non-templated in 
exactly the way Jonathan M Davis described, and it shaved ~0.5s 
off my 3s build time. This particular project is currently only 
8000 LOC, but on a larger project you can see the hit could be 
pretty significant.

Immovable types

[Stanislav Blinov via Digitalmars-d]

Currently, we have the ability to disable postblit and/or 
assignments, thus create non-copyable types.
But it is always assumed that a value can be moved. Normally, 
this is great, as we don't have to deal with additional 
constructors explicitly. There are, however, occasions when move 
is undesirable (e.g. std.typecons.Scoped - class instance on the 
stack). What if a concept of immovable types was introduced? I.e. 
structs you can initialize, possibly copy, but never move. Having 
such types would e.g. disallow returning instances from 
functions, or make things like std.typecons.Scoped safe without 
relying on documented contract.
This would tie in with DIP1000, which seems not to propose using 
"scope" qualifier for type declarations.
Syntactically, this could be expressed by @disabling the rvalue 
ctor (e.g. @disable this(typeof(this))), similar to this() - a 
constructor which cannot be defined but can be @disable'd.


Consider:

// Code samples assume std.algorithm.move is additionally 
constrained

// w.r.t. disabled move construction

struct Scope(T)
{
T value;
this(T v) { value = v; }

@disable this(Scope);
}

auto takesScope(Scope!int i) {}

auto usage()
{
Scope!int i = 42;
auto copyOfI = i;  // Ok, Scope is copyable
takesScope(i); // Ok, Scope is copyable
takesScope(move(i));   // ERROR: Scope cannot be moved
takesScope(Scope!int(10)); // Ok, constructed in-place
return i;  // ERROR: Scope cannot be moved
}

Non-copyable and immovable types will have to be explicitly 
initialized, as if they had @disable this(), as they can't even 
be initialized with .init:


struct ScopeUnique(T)
{
T value;
this(T v) { value = v; }

@disable this(ScopeUnique);
@disable this(this);
}

auto takesScopeUnique(ScopeUnique!int i) {}

auto usage()
{
ScopeUnique!int i;// ERROR: i must be 
explicitly initialized
ScopeUnique!int j = ScopeUnique!int.init; // ERROR: 
ScopeUnique is non-copyable

ScopeUnique!int k = 42;   // Ok
k = ScopeUnique!int(30);  // ERROR: 
ScopeUnique is non-copyable


takesScopeUnique(k);   // ERROR: ScopeUnique 
is non-copyable
takesScopeUnique(move(k)); // ERROR: ScopeUnique 
cannot be moved
takesScopeUnique(ScopeUnique!int(10)); // Ok, constructed 
in-place
takesScopeUnique(ScopeUnique!int(ScopeUnique!int(10))); // 
ERROR: ScopeUnique cannot be moved
return k;  // ERROR: ScopeUnique 
cannot be moved.

}

This way, a type gains additional control over how it's instances 
can be passed around. At compile-time, it would help protect 
against escaping. At run-time, it opens a door for certain 
idioms, mainly more clearly expressing (transfer of) ownership.


It also brings certain symmetry: we already can differentiate 
between rvalue (copy) and lvalue assignments:


struct T
{
this(int) {}
void opAssign(T) {}
void opAssign(ref T) {}
}

T t1, t2;
t1 = T(10);// opAssign(T)
t2 = t1;   // opAssign(ref T)
t1 = move(t2); // opAssign(T)

but we cannot similarly differentiate the construction (move is 
always assumed to work):


T t;
T x = T(0);// this(int)
T y = t;   // this(this)
T w = move(t); // ??? no constructor call at all

With the proposed capability, we would be able to impose or infer 
additional restrictions at compile time as to how an instance can 
be (is being) constructed.


I'd very much like to hear your thoughts on this, good/bad, if it 
already was proposed, anything. If it's found feasible, I could 
start a DIP. Destroy, please.

[Issue 17331] appender can't be used for initialization twice

[via Digitalmars-d-bugs]

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

Heromyth  changed:

   What|Removed |Added

Summary|appender can't be use for   |appender can't be used for
   |initialization  |initialization twice

--

[Issue 17331] New: appender can't be use for initialization

[via Digitalmars-d-bugs]

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

  Issue ID: 17331
   Summary: appender can't be use for initialization
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: bitwo...@qq.com

Compiler: DMD32 D Compiler v2.074.0
OS: Windows, Ubuntu

Here is my test code.

import std.stdio;
import std.array;

struct PackageHandler
{
private auto buffer = appender!(ubyte[])();  // The bug is here
// private Appender!(ubyte[]) buffer;  // It's ok.

void test()
{
assert(buffer.data.length == 0);  // for test
}

void append(ubyte[] data)
{
buffer ~= data;
}

void reset()
{
buffer.clear();
}
}

class AppenderTester
{
private PackageHandler handler;

this()
{
handler.test();
}

void append()
{
handler.append([11, 12, 13]);
}

void clear()
{
handler.reset();
}
}

void main()
{
AppenderTester tester01 = new AppenderTester();
tester01.append();
// tester01.clear();

AppenderTester tester02 = new AppenderTester();
}

--

Re: Interpolated strings

[Jon Degenhardt via Digitalmars-d]

On Saturday, 15 April 2017 at 20:04:13 UTC, Jonas Drewsen wrote:
  I've been wanting to have support for interpolated strings in 
D for some time now that will allow you to write e.g.:

[...]


One place I'd appreciate interpolated strings is as an option 
when working with heredoc strings. These strings are often 
multiple lines or paragraphs, using format style construction is 
often error-prone due to length.


--Jon

Re: How to get return type of current method?

[Meta via Digitalmars-d-learn]

On Wednesday, 19 April 2017 at 00:22:14 UTC, Mike B Johnson wrote:

On Tuesday, 18 April 2017 at 23:49:35 UTC, ketmar wrote:

Mike B Johnson wrote:

How can I get the return type of the current method without 
specifying the name or any complexity? Similar to 
typeof(this).


typeof(return)


Thanks, sweet and simple!


One note: if the function has a return type of `auto`, you cannot 
use `typeof(return)` within the function.

Re: fluent-asserts released

[Szabo Bogdan via Digitalmars-d-announce]

On Wednesday, 12 April 2017 at 06:22:26 UTC, Ali Çehreli wrote:

On 04/11/2017 11:01 PM, Szabo Bogdan wrote:


should.not.throwAnyException({
  throw new Exception("test");
});


what do you mean, they are not documented? there is a md file 
fith some

examples here:
https://github.com/gedaiu/fluent-asserts/blob/v0.3.0/api/exceptions.md

What do you think I can do to have the exception asserts to 
fit the style?


The expression comes first in the other use cases. The 
following is not very pretty but seems to work with my proof of 
concept below:


({
throw new Exception("test");
}()).should.not.throwAnyException();

I checked the syntax with the following code:

struct Should {
Should not() {
return this;
}

Should throwAnyException() {
return this;
}
}

Should should(E)(lazy E expr) {
return Should();
}

void main() {
({
throw new Exception("test");
}()).should.not.throwAnyException();
}

Ali


Hi!

I managed to make another update to the library.

http://fluentasserts.szabobogdan.com/

Based on your feedback I updated the exception asserts and I 
added some new ones

like `Between` and `Approximately`.

Also now it works with unit-threaded.

Thanks for the feedback!

Re: Interpolated strings

[Walter Bright via Digitalmars-d]

On 4/18/2017 4:58 PM, bpr wrote:

Here's how it's done in Nim, a statically typed language similar to D, but with
Python syntax, and macros. It takes some knowledge to understand, sure, macros
are not a beginner tool, but wouldn't say this is extremely complex. I bet a
D-with-macros would have a similar complexity solution.


I'm not saying you cannot do cool and useful things with AST macros. My position 
is it encourages absolutely awful code as (usually inexperienced) programmers 
compete to show how clever their macros are.


The language gets balkanized into a collection of dialects that are 
unrecognizable across user groups.


As a compiler dev who gets stuck figuring out users' bug reports, dealing with 
templates is bad enough (the first thing I do with a bug report is redo it to 
remove all the templates). I do not want to deal with some custom syntax. If I 
may pull the "I'm older" card, programmers will find as they gain experience 
that the AST macros are just not worth it.


This disastrous state of affairs has occurred with every language that supports 
macros.


If you want a nauseous example, check out the Boost C preprocessor 
metaprogramming library. Or C++ expression templates - so cool, and yet so 
utterly wretched.


Reminds me of a story from the 1980s. Microsoft's MASM stood for "Macro 
Assembler". Inevitably, Microsoft programmers invented a pile of macros that 
sort of turned asm programming into a pseudo-high-level language. This was 
shipped with every copy of MASM.


A friend of mine who worked at MS was once given the task of fixing a bug in 50K 
of MASM code written in this macro language. The author of it had long since 
moved on. Every coder assigned to this task failed. My friend got it fixed in a 
couple hours. He was asked by his astonished manager how he'd managed to do it:


"I assembled the code into an object file. Then I disassembled it with Zortech's 
OBJ2ASM, figured out how to fix it, then submitted the disassembled code as the 
new source code."

Re: How to get return type of current method?

[Mike B Johnson via Digitalmars-d-learn]

On Tuesday, 18 April 2017 at 23:49:35 UTC, ketmar wrote:

Mike B Johnson wrote:

How can I get the return type of the current method without 
specifying the name or any complexity? Similar to typeof(this).


typeof(return)


Thanks, sweet and simple!

Re: Interpolated strings

[Walter Bright via Digitalmars-d]

On 4/18/2017 2:56 PM, Jonathan Marler wrote:

Have you thought about supporting format specifiers as well?  I looked at the C#
version and it looks like they can specify them using a colon like this:

$"{a} in hex is {a:x}"


There are additional problems, such as:

$"{a} in %s {b}"

and positional parameters:

$"{a} in {0}"

Of course, the easiest solution is to just disallow that stuff.

Re: Interpolated strings

[bpr via Digitalmars-d]

On Tuesday, 18 April 2017 at 08:01:14 UTC, Jacob Carlborg wrote:

On 2017-04-18 08:59, Stefan Koch wrote:


The corresponding ast-macros would be extremely complex


No, it's not that complex.


Here's how it's done in Nim, a statically typed language similar 
to D, but with Python syntax, and macros. It takes some knowledge 
to understand, sure, macros are not a beginner tool, but wouldn't 
say this is extremely complex. I bet a D-with-macros would have a 
similar complexity solution.


-- string_interpolation.nim 
--


import macros, parseutils, sequtils

macro exho(text: string{lit}): untyped =
  var nodes: seq[NimNode] = @[]
  # Parse string literal into "stuff".
  for k, v in text.strVal.interpolatedFragments:
if k == ikStr or k == ikDollar:
  nodes.add(newLit(v))
else:
  nodes.add(parseExpr("$(" & v & ")"))
  # Fold individual nodes into a statement list.
  result = newNimNode(nnkStmtList).add(
foldr(nodes, a.infix("&", b)))

const
  multiplier = 3.14
  message = exho"$multiplier times 2.5 is ${multiplier * 2.5}"
  foo = "foo"
  message2 = exho"$foo 3 times is ${foo & foo & foo}"

echo message
echo message2


Running gives

3.14 times 2.5 is 7.851
foo 3 times is foofoofoo

Re: How to get return type of current method?

[ketmar via Digitalmars-d-learn]

Mike B Johnson wrote:

How can I get the return type of the current method without specifying 
the name or any complexity? Similar to typeof(this).


typeof(return)

How to get return type of current method?

[Mike B Johnson via Digitalmars-d-learn]

How can I get the return type of the current method without 
specifying the name or any complexity? Similar to typeof(this).

Re: Interpolated strings

[Faux Amis via Digitalmars-d]

On 2017-04-18 23:56, Jonathan Marler wrote:
I've thought about it and decided, I like this idea.  I've only used 
interpolated strings in PHP which left a bad taste, but I realized that 
interpolating strings makes it impossible for your format string and 
your arguments to get out of sync. This makes interpolated strings 
harder to use incorrectly (Scott Meyers had a good talk on this, 
https://www.youtube.com/watch?v=5tg1ONG18H8).


++

(ps. named arguments ;)

Re: Interpolated strings

[H. S. Teoh via Digitalmars-d]

On Tue, Apr 18, 2017 at 09:56:28PM +, Jonathan Marler via Digitalmars-d 
wrote:
[...]
> I've thought about it and decided, I like this idea.  I've only used
> interpolated strings in PHP which left a bad taste, but I realized
> that interpolating strings makes it impossible for your format string
> and your arguments to get out of sync. This makes interpolated strings
> harder to use incorrectly (Scott Meyers had a good talk on this,
> https://www.youtube.com/watch?v=5tg1ONG18H8).
[...]

Phobos git HEAD now supports compile-time format strings of the form:

writefln!"My %s value is %d."("field", 123);

If your arguments are out of sync with the format string, this will
abort with a compilation error. So you won't end up in the situation
where the format string or arguments are wrong but you only find out
when it throws a runtime exception. Or worse, in the C situation where
mismatched format string / arguments can lead to stack overruns and
security exploits. (Though C compilers have been hacked to check this
and issue warnings. But that's veering offtopic.)

Having said that, though, there is still one problem where you can still
get into trouble:

writefln!"The date is %04d-%02d-%02d"(month, year, day);

It may not be immediately obvious that month and year have been
transposed (presumably by mistake), because the %d specifier happens to
work with both argument orderings. Whereas in an interpolated string, it
becomes painfully obvious:

// Using OP's tentative proposed syntax
writeln($"The date is {month}-{year}-{day}");
//^^ mistake is obvious here

This problem may be especially prominent in D because we're used to
writing %s as a general specifier that works for any argument type.


T

-- 
Long, long ago, the ancient Chinese invented a device that lets them see
through walls. It was called the "window".

Re: Interpolated strings

[Jonathan Marler via Digitalmars-d]

On Tuesday, 18 April 2017 at 08:50:07 UTC, Walter Bright wrote:

On 4/15/2017 4:51 PM, cym13 wrote:
Removing imports is a good point, the first concrete one to be 
mentionned. I'm
not sure it matters that much though as I think those imports 
are generic enough
that I believe they would be imported anyway, but it's a real 
point.


It may not be necessary to have any dependencies on any import.

$"{a} times 3 is {a*3}"

could be rewritten by the parser to:

"%s times 3 is %s", a, a * 3

and that is that. (I.e. just an AST rewrite.) It would be quite 
a bit simpler than Jonas' proposed implementation.


I've thought about it and decided, I like this idea.  I've only 
used interpolated strings in PHP which left a bad taste, but I 
realized that interpolating strings makes it impossible for your 
format string and your arguments to get out of sync. This makes 
interpolated strings harder to use incorrectly (Scott Meyers had 
a good talk on this, https://www.youtube.com/watch?v=5tg1ONG18H8).


The biggest drawback I could think of was overhead, but with an 
implementation like this there is NO RUNTIME OVERHEAD!  It's also 
simple (easy to implement and understand) and flexible (works 
with all existing functions that accept "format-like" arguments).


Have you thought about supporting format specifiers as well?  I 
looked at the C# version and it looks like they can specify them 
using a colon like this:


$"{a} in hex is {a:x}"

However this may create an ambiguity in the grammar, not sure. 
I'm not sure what kind of expression would be supported in the 
braces.  If the expression supported labels then this would 
definitely cause ambiguity.  In the example "{a:x}", the symbol 
"a" could just be parsed as a label.

Re: Out of data wiki

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, April 18, 2017 19:54:26 Mike B Johnson via Digitalmars-d-learn 
wrote:
> can this be updated to work?
>
> https://wiki.dlang.org/Timing_Code

Wow, that's using some old stuff - stuff older than the wiki. Weird. It was
probably ported from somewhere.

The best thing to use now is core.time.MonoTime. e.g.

MonoTime before = MonoTime.currTime();
...
MonoTime after = MonoTime.currTime();
Duration diff = before - after;

There are also some benchmarking functions in std.datetime, but they use
TickDuration (which is slated to be deprecated) and need to be replaced with
versions that use MonoTime.

- Jonathan M Davis

Re: Cap'n Proto for D v0.1.2

[Dmitry Olshansky via Digitalmars-d-announce]

On 4/18/17 9:14 PM, Swoorup Joshi wrote:

On Tuesday, 18 April 2017 at 18:09:54 UTC, Thomas Brix Larsen wrote:

"Cap’n Proto is an insanely fast data interchange format and
capability-based RPC system. Think JSON, except binary. Or think
Protocol Buffers, except faster."

This is the initial public release of my optimized port of the Java
implementation of Cap'n Proto.

State:
* Passes Cap'n Proto testsuite.
* Optimized. Just a little slower than the official C++ implementation
(see benchmarks on github).
* Missing RPC part of Cap'n Proto.

http://code.dlang.org/packages/capnproto-dlang
https://github.com/ThomasBrixLarsen/capnproto-dlang


Java?? Yikes


Risking a flamewar but what's wrong with Java?

---
Dmitry Olshansky

Re: Cap'n Proto for D v0.1.2

[Paolo Invernizzi via Digitalmars-d-announce]

On Tuesday, 18 April 2017 at 18:09:54 UTC, Thomas Brix Larsen 
wrote:
"Cap’n Proto is an insanely fast data interchange format and 
capability-based RPC system. Think JSON, except binary. Or 
think Protocol Buffers, except faster."


This is the initial public release of my optimized port of the 
Java implementation of Cap'n Proto.


State:
* Passes Cap'n Proto testsuite.
* Optimized. Just a little slower than the official C++ 
implementation (see benchmarks on github).

* Missing RPC part of Cap'n Proto.

http://code.dlang.org/packages/capnproto-dlang
https://github.com/ThomasBrixLarsen/capnproto-dlang


Great Job!

I'm following Cap'n Proto, and it's very very interesting...
I would love also the RPC part, maybe based on Vibe... have you 
any plan to implement that?


I'm really curious to try it!

---
Paolo

Out of data wiki

[Mike B Johnson via Digitalmars-d-learn]

can this be updated to work?

https://wiki.dlang.org/Timing_Code

Re: Cleaning up Dub/Dmd builds

[FreeSlave via Digitalmars-d-learn]

On Tuesday, 18 April 2017 at 17:58:32 UTC, WhatMeWorry wrote:
On Tuesday, 18 April 2017 at 15:15:47 UTC, Stanislav Blinov 
wrote:

On Tuesday, 18 April 2017 at 15:07:27 UTC, WhatMeWorry wrote:

When I try to upload these files to my new repo, GitHub 
(rightfully so) complains that
I have too many files. Since I'm using sdl and not json, can 
I safely delete all the files
that pertain to json?  Can I do this some way at the command 
line?



You shouldn't upload files from the .dub directory, that's 
local build cache that shouldn't  be published. You can simply 
add the .dub directory to your .gitignore file.


Thanks. That seems like an elegant solution.  Sorry if that is 
documented somewhere. I never came across it or didn't 
understand it when I did.


If you create dub project by "dub init" command it automatically 
creates .gitignore file.
Also github provides premade .gitignore files for many 
programming languages ("Add .gitignore" button on Create new 
repository). Those files are from 
https://github.com/github/gitignore repo.

Re: Cap'n Proto for D v0.1.2

[Swoorup Joshi via Digitalmars-d-announce]

On Tuesday, 18 April 2017 at 18:09:54 UTC, Thomas Brix Larsen 
wrote:
"Cap’n Proto is an insanely fast data interchange format and 
capability-based RPC system. Think JSON, except binary. Or 
think Protocol Buffers, except faster."


This is the initial public release of my optimized port of the 
Java implementation of Cap'n Proto.


State:
* Passes Cap'n Proto testsuite.
* Optimized. Just a little slower than the official C++ 
implementation (see benchmarks on github).

* Missing RPC part of Cap'n Proto.

http://code.dlang.org/packages/capnproto-dlang
https://github.com/ThomasBrixLarsen/capnproto-dlang


Java?? Yikes

[Issue 7102] std.numeric.gcd with BigInts too

[via Digitalmars-d-bugs]

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

--- Comment #5 from hst...@quickfur.ath.cx ---
To make matters worse, std.numeric.gcd has no sig constraints, so once you
import std.numeric.gcd, you cannot even define a BigInt specialization of gcd
in your own code without causing a conflict in the overload set. Unless you do
a static import or any of the other ways of working around the symbol conflict.

--

Cap'n Proto for D v0.1.2

[Thomas Brix Larsen via Digitalmars-d-announce]

"Cap’n Proto is an insanely fast data interchange format and 
capability-based RPC system. Think JSON, except binary. Or think 
Protocol Buffers, except faster."


This is the initial public release of my optimized port of the 
Java implementation of Cap'n Proto.


State:
* Passes Cap'n Proto testsuite.
* Optimized. Just a little slower than the official C++ 
implementation (see benchmarks on github).

* Missing RPC part of Cap'n Proto.

http://code.dlang.org/packages/capnproto-dlang
https://github.com/ThomasBrixLarsen/capnproto-dlang

Re: Cleaning up Dub/Dmd builds

[WhatMeWorry via Digitalmars-d-learn]

On Tuesday, 18 April 2017 at 15:15:47 UTC, Stanislav Blinov wrote:

On Tuesday, 18 April 2017 at 15:07:27 UTC, WhatMeWorry wrote:

When I try to upload these files to my new repo, GitHub 
(rightfully so) complains that
I have too many files. Since I'm using sdl and not json, can I 
safely delete all the files
that pertain to json?  Can I do this some way at the command 
line?



You shouldn't upload files from the .dub directory, that's 
local build cache that shouldn't  be published. You can simply 
add the .dub directory to your .gitignore file.


Thanks. That seems like an elegant solution.  Sorry if that is 
documented somewhere. I never came across it or didn't understand 
it when I did.

[Issue 7102] std.numeric.gcd with BigInts too

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Thoughts from newcommer

[Andrei Alexandrescu via Digitalmars-d]

On 04/18/2017 03:00 AM, Shachar Shemesh wrote:

D would have the ability to have a nice container that would do RAII
(for classes since for structs, __dtors are called automatically)


That's just it, though. They are not. Not reliably.


Yah, clearly there's a problem with the language implementation (and the 
definition that is incomplete, leaving too much leeway to the 
implementation). Clearly the way to go is fix the bug, which has been 
preapproved and of raised gravity. That would obviate the entire 
"implementation has a bug therefore language does not support RAII" line 
of reasoning. Thanks Stefan for looking into this! -- Andrei

Re: Thoughts from newcommer

[Andrei Alexandrescu via Digitalmars-d]

On 04/18/2017 10:55 AM, Russel Winder via Digitalmars-d wrote:

On Tue, 2017-04-18 at 09:23 -0400, Andrei Alexandrescu via Digitalmars-
d wrote:

On 4/18/17 8:48 AM, prdan wrote:

Thanks, maybe I will write a blog post about my experiences also.


That would be great! Michael Parker may be of help if you consider
publishing in the official D Blog. -- Andrei


And I am sure CVu or Overload can publish an article on this if you
were to write one.


That would be fantastic, thanks for this great idea. prdan please push 
this forward! -- Andrei

Re: D, SCons, Dub

[H. S. Teoh via Digitalmars-d]

On Tue, Apr 18, 2017 at 07:34:34AM +, Alex via Digitalmars-d wrote:
[...]
> I realise there are no headers, that is the problem. SCons can't tell
> whether a change to a module affects the interface, only affects the
> implementation or only affects a unit test. This means everything that
> imports a module is recompiled on every edit, even if only the unit
> test was modified, or a formatting change was made.

This is not a problem if you use env.Decider('content'), in which case
the worst that will happen is that the module with the whitespace /
unittest change will be recompiled, but everything else that depends on
that module won't be touched because the object file will have the same
content as before.


> I am not suggesting the D way is bad compared to C++, I am suggesting
> we can have the best of both worlds by automatically generating
> 'headers' or .di files from modules. Then having dependent modules
> read only the .di file instead of the .d file.
[...]

This is not workable for D code that uses a lot of templates. In my own
projects I never use .di files because it suffices to import the .d file
directly.  In the D world, generally the only time you'd use .di files
is (1) interfacing with proprietary libraries, or (2) interfacing with
C/C++ code (but even in this latter case, it's common practice to simply
declare C/C++ functions in extern(C) or extern(C++) blocks inside a .d
file, rather than have a .di file). It's pretty unnatural to use .di
files anywhere else in the typical D project.


T

-- 
"I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you 
already said that." -- User-Friendly

[Issue 17329] File.remove() has problems with long filenames (>128 bytes)

[via Digitalmars-d-bugs]

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

--- Comment #2 from Rainer Koschnick  ---
Thanks for the hint, but it doesn't change anything.

Error:
\\?\0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789.cbz:
The system cannot find the file specified.

Neither does...

Error:
.\0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789.cbz:
The system cannot find the file specified.

Nor using a complete path...

Error:
D:\_Development_\D\cbc\0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789.cbz:
The system cannot find the file specified.

--

Re: Cleaning up Dub/Dmd builds

[Stanislav Blinov via Digitalmars-d-learn]

On Tuesday, 18 April 2017 at 15:07:27 UTC, WhatMeWorry wrote:

When I try to upload these files to my new repo, GitHub 
(rightfully so) complains that
I have too many files. Since I'm using sdl and not json, can I 
safely delete all the files
that pertain to json?  Can I do this some way at the command 
line?



You shouldn't upload files from the .dub directory, that's local 
build cache that shouldn't  be published. You can simply add the 
.dub directory to your .gitignore file.

Cleaning up Dub/Dmd builds

[WhatMeWorry via Digitalmars-d-learn]

Just some basic questions regarding Dub projects with GitHub. I'm 
just getting

my toes wet with GitHub so these might be pretty naive questions.

I've got about 35 mini dub projects where each project holds an 
OpenGL tutorial.

like so:


01_01_hello_window
.dub
build
   
application-$DFLAGS-windows-x86_64-dmd_2071-090A2D44A9209535339D8167E6A96BA6"

   o  o  o
   
application-$DFLAGS-windows-x86_64-dmd_2071-D8ED32593AF993350341F03512FE4A7C"

dub.json
 source
 (all my .d files)
 01_01_hello_window.exe
 dub.sdl
 dub.selections.json
01_02_textures
.dub
 build
  (etc.)

When I try to upload these files to my new repo, GitHub 
(rightfully so) complains that
I have too many files. Since I'm using sdl and not json, can I 
safely delete all the files

that pertain to json?  Can I do this some way at the command line?

Also, I have tons of empty folders with cryptic names like
"application-$DFLAGS-windows-x86_64-dmd_2071-D8ED32593AF993350341F03512FE4A7C" 
above.
Is there some way to suppress these from even being created?

Finally, is it problematic to have so many little dub folders?  
Should I have organized

things in a different (better) manner?

Thanks.

Re: The app hanging after reach 1750MB of RAM

[Suliman via Digitalmars-d-learn]

On Tuesday, 18 April 2017 at 14:15:59 UTC, Stanislav Blinov wrote:
On Tuesday, 18 April 2017 at 14:09:28 UTC, Stanislav Blinov 
wrote:



foreach(row; result)
{
arr ~= row.toStruct(cargpspoint);
}


Sorry, this should be

foreach(row; result)
{
row.toStruct(cargpspoint);
arr ~= cargpspoint;
}


Thanks I will try! But why in my code memory do not released? Do 
you have any idea?

Re: Thoughts from newcommer

[Russel Winder via Digitalmars-d]

On Tue, 2017-04-18 at 09:23 -0400, Andrei Alexandrescu via Digitalmars-
d wrote:
> On 4/18/17 8:48 AM, prdan wrote:
> > Thanks, maybe I will write a blog post about my experiences also.
> 
> That would be great! Michael Parker may be of help if you consider 
> publishing in the official D Blog. -- Andrei

And I am sure CVu or Overload can publish an article on this if you
were to write one.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: hidden passing of __FILE__ and __LINE__ into function

[Solomon E via Digitalmars-d-learn]

On Tuesday, 18 April 2017 at 13:48:57 UTC, Stanislav Blinov wrote:

On Tuesday, 18 April 2017 at 13:28:06 UTC, Solomon E wrote:


I tried to produce an example of calling a function with
variadic template arguments using special tokens __FILE__ and 
__LINE__.


This compiles and runs, producing the output shown, using the 
default gdc
provided by Ubuntu 17.04. This appears to be a workaround for 
Issue 8687...


There's a much more concise workaround, both in code written 
and generated ;)


import std.stdio;

template func(string file = __FILE__, int line = __LINE__)
{
auto func(T...)(auto ref T args)
{
writeln("called func with ", T.length, " args at ",
file, ":", line);
}
}

void main()
{
func();
func(1, 2, 3);
}


Thank you for reminding me that templates can contain a 
definition of a function
of the same name, which still surprises me as convenient, not as 
a bad thing.


Unfortunately, when I tried it, I found that while that attempt 
at a workaround is
twice as concise in lines of code and symbols introduced, it is 
not acceptable.
It gets the lines reported wrong. It reports the line for where 
the template was
first instantiated for the same tuple of argument types, instead 
of exactly the line

of each call of `func`.

Re: The app hanging after reach 1750MB of RAM

[Stanislav Blinov via Digitalmars-d-learn]

On Tuesday, 18 April 2017 at 14:09:28 UTC, Stanislav Blinov wrote:


foreach(row; result)
{
arr ~= row.toStruct(cargpspoint);
}


Sorry, this should be

foreach(row; result)
{
row.toStruct(cargpspoint);
arr ~= cargpspoint;
}

Re: The app hanging after reach 1750MB of RAM

[Stanislav Blinov via Digitalmars-d-learn]

On Tuesday, 18 April 2017 at 13:28:57 UTC, Suliman wrote:
Also I can't understand why app take so much memory? I checked 
array of structures size with this code:


auto mymem = cargpspoints.length * 
typeof(cargpspoints[0]).sizeof;			

writeln(mymem);

And it's print: 16963440
it's about 16MB...

What is takes all other memory?


1. You're measuring it wrong. Array length is already measured in 
terms of type size. But remember that every call result.array 
will allocate, and very call coerce!string will also allocate.
2. Since you're iterating over every result once, there's no 
point in converting it to an array first.

3. Consider using the Row.toStruct() method for conversion.
4. Consider using std.array.appender instead of ~=.

void getSingleTrackInfo()
{

foreach(item; getTablesGPSSensorList)
{
ResultRange result = mysqlconnection.query(sqlquery);

carGPSPoint cargpspoint; // create struct
auto arr = appender!(carGPSPoint[]); // create array of 
structures


foreach(row; result)
{
arr ~= row.toStruct(cargpspoint);
}

// arr.data should hold the array of structures
}
}

Re: hidden passing of __FILE__ and __LINE__ into function

[Stanislav Blinov via Digitalmars-d-learn]

On Tuesday, 18 April 2017 at 13:28:06 UTC, Solomon E wrote:


I tried to produce an example of calling a function with
variadic template arguments using special tokens __FILE__ and 
__LINE__.


This compiles and runs, producing the output shown, using the 
default gdc
provided by Ubuntu 17.04. This appears to be a workaround for 
Issue 8687...


There's a much more concise workaround, both in code written and 
generated ;)


import std.stdio;

template func(string file = __FILE__, int line = __LINE__)
{
auto func(T...)(auto ref T args)
{
writeln("called func with ", T.length, " args at ",
file, ":", line);
}
}

void main()
{
func();
func(1, 2, 3);
}

Re: The app hanging after reach 1750MB of RAM

[Suliman via Digitalmars-d-learn]

Also I can't understand why app take so much memory? I checked 
array of structures size with this code:


auto mymem = cargpspoints.length * 
typeof(cargpspoints[0]).sizeof;			

writeln(mymem);

And it's print: 16963440
it's about 16MB...

What is takes all other memory?

Re: hidden passing of __FILE__ and __LINE__ into function

[Solomon E via Digitalmars-d-learn]

On Tuesday, 18 April 2017 at 10:13:09 UTC, Jonathan M Davis wrote:
On Monday, April 17, 2017 07:23:50 Jonathan M Davis via 
Digitalmars-d-learn wrote:
So, if you're okay with explicitly instantiating your variadic 
function template instead of having the types inferred, then 
it can work, but otherwise, no. Making it work would require a 
language enhancement


Actually, not only is there already a bug report for this

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

which is marked as a bug and not an enhancement, and when 
Walter commented on it when an ICE related to it was fixed, he 
didn't change it from a bug to an enhancement. So, it looks 
like he agrees that it's a bug rather than considering it an 
enhancement. It has yet to be fixed regardless though.


- Jonathan M Davis


import std.stdio: writeln;
import std.conv: to;

void main()
{
add("Scene 1", "Scene 2", "Scene 3");
add("Scene 3", "Scene 4", "Scene 5");
add(5, 6, 7);
add(7, "Scene 8", "Scene 9");
writeln("total scenes added: ", sceneCount);
}

struct Scene
{
string name;
string file;
size_t line;
}

Scene*[] listOfScenes;
int[string] indexOfScenes;
int sceneCount = 0;

void add_impl(T...)(string file, size_t line, T args)
{
foreach(arg; args)
{
static if (is(typeof(arg) == string))
{
auto name = arg;
}
else
{
auto name = "Scene " ~ arg.to!string;
}
if (name in indexOfScenes)
{
EError(file, line, "scene already exists", name);
}
else
{
indexOfScenes[name] = sceneCount;
listOfScenes ~= new Scene(name, file, line);
sceneCount += 1;
writeln("added " ~ name);
}
}
}

void add(string file = __FILE__, size_t line = __LINE__, T...)(T 
args)

{
add_impl!T(file, line, args);
}

void EError(string file, size_t line, string message, string name)
{
writeln(name, ": ", message,
" in file ", file, " in line ", line);
auto previous = listOfScenes[indexOfScenes[name]];
writeln("previous definition of ", previous.name,
" was in ", previous.file, " in line ", 
previous.line);

}

/* output:

added Scene 1
added Scene 2
added Scene 3
Scene 3: scene already exists in file vlf.d in line 7
previous definition of Scene 3 was in vlf.d in line 6
added Scene 4
added Scene 5
Scene 5: scene already exists in file vlf.d in line 8
previous definition of Scene 5 was in vlf.d in line 7
added Scene 6
added Scene 7
Scene 7: scene already exists in file vlf.d in line 9
previous definition of Scene 7 was in vlf.d in line 8
added Scene 8
added Scene 9
total scenes added: 9

*/


I tried to produce an example of calling a function with
variadic template arguments using special tokens __FILE__ and 
__LINE__.


This compiles and runs, producing the output shown, using the 
default gdc
provided by Ubuntu 17.04. This appears to be a workaround for 
Issue 8687.
The instantiations of the wrapper function `add` should only add 
minimally

to the compiled object code size, once per call of `add`.
I'm not sure about the quality of any of this code.

Re: Thoughts from newcommer

[Andrei Alexandrescu via Digitalmars-d]

On 4/18/17 8:48 AM, prdan wrote:

Thanks, maybe I will write a blog post about my experiences also.


That would be great! Michael Parker may be of help if you consider 
publishing in the official D Blog. -- Andrei

[Issue 17309] [REG 2.073.2] constructor template doesn't infer `pure`

[via Digitalmars-d-bugs]

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

--- Comment #4 from ag0ae...@gmail.com ---
(In reply to Walter Bright from comment #3)
> I think that trouble here is that attribute inference is not done until the
> template is instantiated. But the compiler does not instantiate a template
> until it matches a template, and
> 
> this(Range)(Range s)
> 
> does not match for constructing an immutable. I don't see a way out of this
> chicken-and-egg problem.
> 
> I'm going to mark this as invalid.

1) That's a major bummer.

2) It means that Russel's issue is a phobos regression. I've filed it
separately as issue 17330.

--

[Issue 17330] New: [REG 2.072] BigInt's constructor used to be pure

[via Digitalmars-d-bugs]

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

  Issue ID: 17330
   Summary: [REG 2.072] BigInt's constructor used to be pure
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

Found by Russel Winder who posted to D.learn:
http://forum.dlang.org/post/mailman.1458.1491584811.31550.digitalmars-d-le...@puremagic.com

This used to work, and it should be made to work again:


void main()
{
import std.bigint: BigInt;
auto b = immutable BigInt("123");
}


Fails compilation since 2.072.0. Regression was introduced by
.

The issue is that purity cannot be inferred for the constructor. It used to be
explicitly marked `pure` when it wasn't a template.

I've previously filed this as a compiler bug, thinking that a templated
constructor should infer `pure`. That issue has been closed as WONTFIX. See
issue 17309.

I'm not sure if this can be fixed satisfactorily. So this may end up as WONTFIX
as well. But that would be quite disappointing.

--

Re: Thoughts from newcommer

[prdan via Digitalmars-d]

On Tuesday, 18 April 2017 at 12:22:10 UTC, Andrei Alexandrescu 
wrote:


Cool, thanks for this work! However, a word of caution - 
experiments ran on different CPUs can't count as comparable.




I didn't compare D times to numbers from benchmarks game site.
I've ran other languages on the same CPU also, all the numbers 
I've posted are from the same CPU for those 3 languages so they 
are comparable in this case :)




That's an awesome initiative, please keep us posted!


Andrei


Thanks, maybe I will write a blog post about my experiences also.

Re: Thoughts from newcommer

[rikki cattermole via Digitalmars-d]

On 18/04/2017 1:22 PM, Andrei Alexandrescu wrote:

On 04/17/2017 10:57 PM, prdan wrote:

I've written multi-threaded regex-redux benchmark for D language and
made some tests. This is my first program written in D, I didn't know
much about D a week ago.

Here are the results for other languages:

http://benchmarksgame.alioth.debian.org/u64q/regexredux.html

I have newer CPU than one used on this page. Tests were made on Debian 8
with i7-3770 3.4 Ghz (4C/8T) CPU.


Cool, thanks for this work! However, a word of caution - experiments ran
on different CPUs can't count as comparable.


Even if the hardware is identical, all it takes is a setting changed in 
the thread scheduler of an OS and you will be getting wildly different 
results, beware of separate computers for benchmarking period.

Re: Thoughts from newcommer

[Andrei Alexandrescu via Digitalmars-d]

On 04/17/2017 10:57 PM, prdan wrote:

I've written multi-threaded regex-redux benchmark for D language and
made some tests. This is my first program written in D, I didn't know
much about D a week ago.

Here are the results for other languages:

http://benchmarksgame.alioth.debian.org/u64q/regexredux.html

I have newer CPU than one used on this page. Tests were made on Debian 8
with i7-3770 3.4 Ghz (4C/8T) CPU.


Cool, thanks for this work! However, a word of caution - experiments ran 
on different CPUs can't count as comparable.



I got inspired by those results that's why I thought I will write all
the other benchmarks from benchmarks game also for D and share the code
and results on github + comparison to couple other languages.


That's an awesome initiative, please keep us posted!


Andrei

Re: make Pid constructor public

[Domain via Digitalmars-d-learn]

On Monday, 17 June 2013 at 22:38:47 UTC, Timothee Cour wrote:

inside std.process it says:
// Pids are only meant to be constructed inside this module, so 
we make the

constructor private.
However, this makes a number of useful functions from 
std.process useless
unless the processes were created via one of std.process' 
functions.

Can we make std.process.Pid.this(int pid) public?

Use case:
int pid=...; //parse pid from call to 'ps au' for example
std.process.kill(pid);
std.process.wait(pid);
//etc


I know this is an old post, but I need this feature! Any plan to 
make this happen?

Re: Interpolated strings

[Kagamin via Digitalmars-d]

On Tuesday, 18 April 2017 at 08:50:07 UTC, Walter Bright wrote:

It may not be necessary to have any dependencies on any import.

$"{a} times 3 is {a*3}"

could be rewritten by the parser to:

"%s times 3 is %s", a, a * 3

and that is that. (I.e. just an AST rewrite.) It would be quite 
a bit simpler than Jonas' proposed implementation.


For, say, sql query generator it would be nice to have a rewrite 
like

sql!"select name from users where id={n}"
=>
auto q=query("select name from users where id=@p0");
q.addParameter("p0",n);

pragma(autoMixin)
template sql(string txt)
{
  enum string sql=generateCode(txt);
}

If this can be rewritten as automatic string mixin like so:
sql!"select name from users where id={n}"
=>
mixin(sql!"select name from users where id={n}")

The app hanging after reach 1750MB of RAM

[Suliman via Digitalmars-d-learn]

I am writing app that extract data from DB to array of structures.

void getSingleTrackInfo()
{

foreach(item; getTablesGPSSensorList)
{
ResultRange result = mysqlconnection.query(sqlquery);
auto MySQLPointsLonLat = result.array;

carGPSPoint cargpspoint; // create struct
carGPSPoint [] cargpspoints; // create array of 
structures

foreach(i, point;MySQLPointsLonLat)
{
cargpspoint.id = point[0].coerce!ulong;
cargpspoint.recordDate = point[1].coerce!string;
cargpspoint.velocity = point[2].coerce!double;
cargpspoint.lat = point[3].coerce!string;
cargpspoint.lon = point[4].coerce!string;
cargpspoints ~=cargpspoint;

}

}
}


I expected that on every step:
`foreach(item; getTablesGPSSensorList)` structures `carGPSPoint` 
will be recreated and memory will be free. But App after starting 
begin eat memory, and do it till reach 1750 of RAM. After it it's 
not crush, but simply stop other processing.


1. By the code on every iterate `carGPSPoint` should be recreated 
and memory should be free, why this does not happen?

2. How to free my memory?

Re: Interpolated strings

[Jacob Carlborg via Digitalmars-d]

On 2017-04-18 10:50, Walter Bright wrote:


It may not be necessary to have any dependencies on any import.

$"{a} times 3 is {a*3}"

could be rewritten by the parser to:

"%s times 3 is %s", a, a * 3

and that is that. (I.e. just an AST rewrite.) It would be quite a bit
simpler than Jonas' proposed implementation.


Then you would be forced to wrap it in a function call, to "format" or 
similar. The example of using "writeln" is not the best, a more useful 
example is when not printing the string immediately. For example:


auto s = $"{a} times 3 is {a*3}";

With your example that would need to be written as:

import std.format;
auto s = format($"{a} times 3 is {a*3}");

--
/Jacob Carlborg

Re: Thoughts from newcommer

[prdan via Digitalmars-d]

On Tuesday, 18 April 2017 at 07:22:29 UTC, thedeemon wrote:

Which compiler did you use for D?



I've used newest LDC.

In benchmarks where some fixed amount of work should be done as 
fast as possible low CPU usage is not a good sign, it just 
means some cores were idle when they could really be working.


Not in this case, there is a batch of the job that need to be 
done parallel but second part is done sequential (that takes 
majority of the time) so in this case this is good. Just look at 
source code of the algorithm in the link I've provided.
I've also looked at callgrind and majority of the time is spent 
in regex so it's good.

Re: Thoughts from newcommer

[Guillaume Piolat via Digitalmars-d]

On Tuesday, 18 April 2017 at 07:22:29 UTC, thedeemon wrote:
In benchmarks where some fixed amount of work should be done as 
fast as possible low CPU usage is not a good sign, it just 
means some cores were idle when they could really be working.


Minor note: sometimes high CPU usage isn't good either, if the 
CPU is used for multithreading overhead/bookkeeping (eg: 
scheduler).

Re: hidden passing of __FILE__ and __LINE__ into function

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, April 17, 2017 07:23:50 Jonathan M Davis via Digitalmars-d-learn 
wrote:
> So, if you're okay with explicitly instantiating your variadic function
> template instead of having the types inferred, then it can work, but
> otherwise, no. Making it work would require a language enhancement

Actually, not only is there already a bug report for this

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

which is marked as a bug and not an enhancement, and when Walter commented
on it when an ICE related to it was fixed, he didn't change it from a bug to
an enhancement. So, it looks like he agrees that it's a bug rather than
considering it an enhancement. It has yet to be fixed regardless though.

- Jonathan M Davis

[Issue 8687] Variadic templates do not work properly with default arguments

[via Digitalmars-d-bugs]

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #4 from Jonathan M Davis  ---
It looks like the status quo right now (with the development version of dmd
2.075) is that default arguments work with variadic templates if the template
is explicitly instantiated but not if IFTI is used. So,

-
void foo(T...)(T args, string file = __FILE__) { }

void main()
{
foo();
}
-

won't compile, but

-
void foo(T...)(T args, string file = __FILE__) { }

void main()
{
foo!int(42);
}
-

will. So, it looks like this is probably now purely an IFTI issue. And
presumably, IFTI could be made to just assume that the default arguments are
always used (since it has no way of differentiating between explicit arguments
for those parameters and variadic arguments that have the same type, and anyone
who wants to provid explicit arguments can always explicitly instantiate the
template, which even works right now). That _seems_ like it would be
straightforward, but I'm not at all familiar with how IFTI is implemented in
the compiler.

Regardless, having it fixed so that the default arguments compile when IFTI is
used would have a significant impact on stuff like std.experimental.logger,
which currently has __FILE__, __LINE__, __FUNCTION__, __PRETTY_FUNCTION__, and
__MODULE__ as default template arguments, which results in a function template
being instantiated for every log call.

--

[Issue 17309] [REG 2.073.2] constructor template doesn't infer `pure`

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 Resolution|FIXED   |WONTFIX

--

[Issue 17309] [REG 2.073.2] constructor template doesn't infer `pure`

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--- Comment #3 from Walter Bright  ---
I think that trouble here is that attribute inference is not done until the
template is instantiated. But the compiler does not instantiate a template
until it matches a template, and

this(Range)(Range s)

does not match for constructing an immutable. I don't see a way out of this
chicken-and-egg problem.

I'm going to mark this as invalid.

--

[Issue 17309] [REG 2.073.2] constructor template doesn't infer `pure`

[via Digitalmars-d-bugs]

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

--- Comment #2 from Walter Bright  ---
(In reply to Walter Bright from comment #1)
> It also compiles with dmd 2.070, didn't check other versions.

I don't know what I did there. I can't get it to compile with any dmd versions
I tried, so I don't think this is a regression.

--

[Issue 12115] Segfault in FormatSpec.fillUp

[via Digitalmars-d-bugs]

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

Daniel Čejchan  changed:

   What|Removed |Added

 CC||czda...@gmail.com

--

[Issue 17321] Example code for std.stdio.File fails to compile

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Walter Bright  ---
I'm going to abandon this.

--

[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

[via Digitalmars-d-bugs]

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

--- Comment #3 from Walter Bright  ---
The problem is I cannot get the DLL test cases into the autotester test suite,
which is why DLL support regularly breaks.

--

Re: Yu(玉) - 0.0.3 : A Dlang's Toolkit in My Used

[Dsby via Digitalmars-d-announce]

On Tuesday, 18 April 2017 at 09:24:39 UTC, Dsby wrote:

[...]


In github : https://github.com/dushibaiyu/yu
In dub : http://code.dlang.org/packages/yu

Yu(玉) - 0.0.3 : A Dlang's Toolkit in My Used

[Dsby via Digitalmars-d-announce]

algorithm
snowflkeId.d : Twitter's Snowflke ID generate 
algorithm.to generate only ID

container : the container base std.experimental.allocator
cirularqueue : Cirular Queue Struct Template.
vector : Like as C++'s std::vector
eventloop : the io(Net) event loop. support EPOLL, KQUEUE , 
IOCP.
asyncsocket : The async socket base std.scoket and 
yu.eventloop
client : the easy Use TCP client. Has time out and 
connect try, and mitil-client
server : the easy Use TCP server. Has Time out and auto 
close .

Acceptor : Tcp listen and accept
TCPClient : Base Tcp client
TCPSocket : Base TCP connection
UDPSocket : Base Udp connection
timer : Timer
eventlooptimer : the timer base yu.eventloop
timingwheeltimer : Time wheel algorithm . base 
std.experimental.allocator

memory
allictor : the yuAlloctor and easy make object base 
yuAlloctor. Base std.experimental.allocator

gc : gcFree to easy free the memory in GC
scopedref : the Unique Ptr/Ref like C++'s std::unique_ptr.
sharedref : the RC Ptr/Ref like C++'s std::shared_ptr
smartref : easy to create the scopedref and sharedref
array : Extend Phobos's std.array. IAppender base 
std.experimental.allocator

bytes : add find in byte or ubyte.
exception : Extend Phobos's std.exception.
functional : add bind use delegate.
string : Extend Phobos's std.string.
task : the task base std.experimental.allocator
thread : auto attach thread
traits : : Extend Phobos's std.traits.

Re: if auto and method call

[Andrea Fontana via Digitalmars-d-learn]

On Tuesday, 18 April 2017 at 09:05:10 UTC, Andrea Fontana wrote:

On Tuesday, 18 April 2017 at 00:48:05 UTC, Jethro wrote:
How to combine the need to localize a result for an if 
statement and have to call a method to get proper comparison:

[...]
which should simplify to

if ((auto x = foo()).valid())
{

}

but this code does not work.
[...]



for(auto x = foo(); foo.valid();)
{
   ... your code here ...
   break;
}

it would be useful if this syntax was supported:

for(auto x = foo(); foo.valid(); break)
{

}


Andrea


Whoops i mean:

for (auto x = foo(); x.valid;)
{
...
break;
}

Re: if auto and method call

[Andrea Fontana via Digitalmars-d-learn]

On Tuesday, 18 April 2017 at 00:48:05 UTC, Jethro wrote:
How to combine the need to localize a result for an if 
statement and have to call a method to get proper comparison:

[...]
which should simplify to

if ((auto x = foo()).valid())
{

}

but this code does not work.
[...]



for(auto x = foo(); foo.valid();)
{
   ... your code here ...
   break;
}

it would be useful if this syntax was supported:

for(auto x = foo(); foo.valid(); break)
{

}


Andrea

Re: Interpolated strings

[Walter Bright via Digitalmars-d]

On 4/15/2017 4:51 PM, cym13 wrote:

Removing imports is a good point, the first concrete one to be mentionned. I'm
not sure it matters that much though as I think those imports are generic enough
that I believe they would be imported anyway, but it's a real point.


It may not be necessary to have any dependencies on any import.

$"{a} times 3 is {a*3}"

could be rewritten by the parser to:

"%s times 3 is %s", a, a * 3

and that is that. (I.e. just an AST rewrite.) It would be quite a bit simpler 
than Jonas' proposed implementation.

Re: Interpolated strings

[Walter Bright via Digitalmars-d]

On 4/15/2017 1:04 PM, Jonas Drewsen wrote:

[...]


Thanks for doing the work to make a sample implementation, too. I don't know if 
this will make it into D, but Jonas is a fine example of a champion.

Re: Interpolated strings

[Jacob Carlborg via Digitalmars-d]

On 2017-04-18 08:59, Stefan Koch wrote:


The corresponding ast-macros would be extremely complex


No, it's not that complex.


, slow and worst
of all not checkable.


What do you mean "not checkable"?

--
/Jacob Carlborg

Re: D, SCons, Dub

[Russel Winder via Digitalmars-d]

On Tue, 2017-04-18 at 07:34 +, Alex via Digitalmars-d wrote:
> 
[…]
> I know, I have been using your work in SCons to build in this 
> mode since it was first available.

Excellent. :-)

[…]
> > > 
> I realise there are no headers, that is the problem. SCons can't 
> tell whether a change to a module affects the interface, only 
> affects the implementation or only affects a unit test. This 
> means everything that imports a module is recompiled on every 
> edit, even if only the unit test was modified, or a formatting 
> change was made.

SCons should be immune to whitespace changes, but actual reformatting
is likely to be a change.

Hummm… it is not clear in my mind just now whether that dependency is
build into the SCons build DAG. Whilst the C and C++ builders go to
great lengths to deal with the #include dependency tree, I am not sure
the D tools parse the D source import dependency tree. It probably
should, but just now – I believe – it is just module by module
compilation. If there are API changes then SCons will not follow that
through for D codes. 
 
> I am not suggesting the D way is bad compared to C++, I am 
> suggesting we can have the best of both worlds by automatically 
> generating 'headers' or .di files from modules. Then having 
> dependent modules read only the .di file instead of the .d file.
> This way SCons won't recompile dependencies unless necessary. 
> This is the main purpose of using SCons (perfect incremental 
> builds) which is largely defeated currently by D.

I have never trodden the .di file path and so the SCons tools do not
generate them. A flag could easily be added so that an emitter of the
builder could generate the .di as well as the .o file. The tools are
not set up for that as yet, but it could be done.

Being sent small projects as test cases to drive adding features is
likely the best route. Feel free to send in issues on  https://github.c
om/russel/SCons_D_Experiment

[…]
> I know, I have been working through the guts of SCons for (a 
> little bit too long to mention)  trying to make it both output 
> two products with proper dependencies (.o and .di) and to find 
> the di files correctly. SCons seems to have an ability to find 
> the original .d files in the project even if the compiler can't.

It maybe that the missing link here is that the D builders currently do
not have emitters. With an emitter added doing the .di as well as .o
files should be very straightforward – but maybe not easy.

[…]
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: D, SCons, Dub

[Alex via Digitalmars-d]

On Tuesday, 18 April 2017 at 06:51:51 UTC, Russel Winder wrote:
I have been trying to do the opposite with scons - incremental 
builds. In c++ the .h and .cpp files allowed the compilation 
from many edits to be limited to one translation unit.


Per module compilation then linking is the default for the 
Program builder in SCons, that is already there and has been 
for over a decade.


I know, I have been using your work in SCons to build in this 
mode since it was first available.


One thing people are often confused about is whether 
everything needs to be in the header (or di file).


Uuurrr… there is no separation of header and code in D, just 
modules. And packages. SCons currently has no "per package" 
builder. I guess I need to add this.


I realise there are no headers, that is the problem. SCons can't 
tell whether a change to a module affects the interface, only 
affects the implementation or only affects a unit test. This 
means everything that imports a module is recompiled on every 
edit, even if only the unit test was modified, or a formatting 
change was made.


I am not suggesting the D way is bad compared to C++, I am 
suggesting we can have the best of both worlds by automatically 
generating 'headers' or .di files from modules. Then having 
dependent modules read only the .di file instead of the .d file.
This way SCons won't recompile dependencies unless necessary. 
This is the main purpose of using SCons (perfect incremental 
builds) which is largely defeated currently by D.




Currently there is no explicit handling of di files in SCons.
I know, I have been working through the guts of SCons for (a 
little bit too long to mention)  trying to make it both output 
two products with proper dependencies (.o and .di) and to find 
the di files correctly. SCons seems to have an ability to find 
the original .d files in the project even if the compiler can't.


If you can come up with a small project that exhibits the 
problem you need solved, I can add it as a test case in the 
SCons system thereby creating a need for a fix.


Thanks for that kind offer Russel, I will make a minimal example 
project.


(Tests in SCons for the tools are end-to-end tests, so need a 
project

exhibiting a problem.)


OK.

Re: Thoughts from newcommer

[thedeemon via Digitalmars-d]

On Tuesday, 18 April 2017 at 02:57:59 UTC, prdan wrote:
I've written multi-threaded regex-redux benchmark for D 
language and made some tests.


Nice!


Rust version 1.16 (newest stable)
GCC ver 4.9.2 (newest debian 8 stable)


Which compiler did you use for D?

C was the fastest (1.32) but used the most CPU, D was second 
(1.45) with lowest CPU usage!


In benchmarks where some fixed amount of work should be done as 
fast as possible low CPU usage is not a good sign, it just means 
some cores were idle when they could really be working.

Re: Empty Result

[Russel Winder via Digitalmars-d-learn]

On Mon, 2017-04-17 at 15:10 -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
> alias RangeType = typeof(return);
>  return new RangeType(() {});


It appears the answer to my question is:

return typeof(return)();

Thanks to Ali and T for setting on the right path.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: Stuck with DMD, and Unit-Threaded

[Russel Winder via Digitalmars-d-learn]

On Mon, 2017-04-17 at 22:56 +, Atila Neves via Digitalmars-d-learn
wrote:
> 
[…]
> https://github.com/russel/ApproxGC/pull/2
> 
> Unfortunately the auto generated integration test main file 
> doesn't quite work (feel free to file a bug on unit-threaded) so 
> in that PR I disabled auto-generating it and force added my 
> edited version.
> 
> What I did there in dub.sdl is my current go-to solution for also 
> running integration tests with unit-threaded.
> 

Thanks for that, much appreciated. I am hesitant to commit the pull
request for now in case get_ut_main gets fixed fairly quickly. For the
moment I am progressing with the SCons build since I got it working.

As per your advice I wrote a SCons specific Python function to do the
same as get_ut_main – and it works, well for my very restricted test
cases anyway. I think my Python code only solves a part of the problem
your get_ut_main solves: I think I need to extend the Python function
to cover more cases. I'll do it on an as needed, only with a test case,
basis though.

The real joy is that I have Unit-Threaded working. It's extensions of
the unittest D language feature make testing D codes far more fun than
the basic feature. Thanks for putting in the effort.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: Thoughts from newcommer

[Shachar Shemesh via Digitalmars-d]

D would have the ability to have a nice container that would do RAII
(for classes since for structs, __dtors are called automatically)


That's just it, though. They are not. Not reliably.

Shachar

Re: Interpolated strings

[Stefan Koch via Digitalmars-d]

On Tuesday, 18 April 2017 at 06:54:11 UTC, Jacob Carlborg wrote:

On 2017-04-17 21:28, Jonas Drewsen wrote:


The page could also list pre-approved language
changes such as async functions (which Walter wants afaik).


Another feature that can be implemented with AST macros. This 
is starting to get ridicules. So many features have been added 
and are talked about that can be implemented with AST macros 
instead. Same as with the scope/safe related DIPs. Many 
smallish specialized features are added instead of a generic 
feature that can handle all of them. Increasing the complexity 
of the language.


The corresponding ast-macros would be extremely complex, slow and 
worst of all not checkable.

Re: D, SCons, Dub

[Russel Winder via Digitalmars-d]

On Mon, 2017-04-17 at 18:53 +, Nordlöw via Digitalmars-d wrote:
> 
[…]
> Nice. I'm using SCons in my everyday development. I'll give your 
> feature a try.

My pull request is currently being reviewed and some updates are
needed. These will appear immediately in the SCons_D_Experiment. I'll
post once the pull request gets merged into SCons mainline. Then it
just awaits a release, unless you use default/tip from the mainline
repository.

> Meson has recently added a similar feature. Meson calls it a 
> "unity build".

Is there documentation? I need this immediately as unit-threaded only
works with whole source compilation.

> > If you want to use it prior to it being accepted and released, 
> > then feel free to use the tools in the repository 
> > https://github.com/russel/ SCons_D_Experiment
> > 
> > Also in there you will spot a new tool dub. I am now using this 
> > to grab
> > unit-threaded from the Dub repository in a SCons build. See for 
> > example
> >  https://github.com/russel/ApproxGC
> 
> Cool.
> 

:-)

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: Interpolated strings

[Jacob Carlborg via Digitalmars-d]

On 2017-04-17 21:28, Jonas Drewsen wrote:


The page could also list pre-approved language
changes such as async functions (which Walter wants afaik).


Another feature that can be implemented with AST macros. This is 
starting to get ridicules. So many features have been added and are 
talked about that can be implemented with AST macros instead. Same as 
with the scope/safe related DIPs. Many smallish specialized features are 
added instead of a generic feature that can handle all of them. 
Increasing the complexity of the language.


--
/Jacob Carlborg

Re: D, SCons, Dub

[Russel Winder via Digitalmars-d]

On Mon, 2017-04-17 at 22:59 +, Atila Neves via Digitalmars-d wrote:
> […]
> In D, this is nearly always slower (I measured). Compiling per 
> package, however, is a lot faster.

I have only ever needed file-by-file or whole source compilation, I
have never needed package-oriented compilation. It sounds like this
needs adding to SCons and Meson. What is needed is a really small
project showing the idea so that it can be used as a test case.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: D, SCons, Dub

[Russel Winder via Digitalmars-d]

On Mon, 2017-04-17 at 20:56 +, Alex via Digitalmars-d wrote:
> On Monday, 17 April 2017 at 17:51:33 UTC, Russel Winder wrote:
> > Just in case anyone gives a :
> > 
> > I have submitted a pull request that adds ProgramAllAtOnce
> 
> I have been trying to do the opposite with scons - incremental 
> builds. In c++ the .h and .cpp files allowed the compilation from 
> many edits to be limited to one translation unit.

Per module compilation then linking is the default for the Program
builder in SCons, that is already there and has been for over a decade.

> One thing people are often confused about is whether everything 
> needs to be in the header (or di file).

Uuurrr… there is no separation of header and code in D, just modules.
And packages. SCons currently has no "per package" builder. I guess I
need to add this.

> An influence is that most of the code they see written by skilled 
> language users is libraries like the standard library. These 
> typically benefit little from interfaces files because everything 
> is templates and must be in the header to compile. Hence why 
> boost is mostly headers in c++ land and the D ecosystem 
> encourages all at once / all everytime compilation.
> 
> In a large code base this becomes cumbersome. Changing a unit 
> test should not result in everything recompiling.
> 
> I think there is a difference between library style code and 
> application code. My application code doesn't have templates and 
> can make use of di files. It makes sense that the language 
> developers spend most of their time on library type code, and 
> have been focused on it.
> 
> I just need to work out how to get scons to recognise two targets 
> from one builder properly : the object file and the di file.
> I can add DFLAGs to make a Object builder make the di files too, 
> and the d scanner finds di files where d files are not available, 
> but the build tree dependency from d to di file is missing. Dies 
> anyone know how to do this ?

Currently there is no explicit handling of di files in SCons. If you
can come up with a small project that exhibits the problem you need
solved, I can add it as a test case in the SCons system thereby
creating a need for a fix.

(Tests in SCons for the tools are end-to-end tests, so need a project
exhibiting a problem.)
 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part