Re: Compile-Time Sort in D

[MysticZach via Digitalmars-d-announce]

On Tuesday, 6 June 2017 at 01:08:45 UTC, Mike Parker wrote:

On Monday, 5 June 2017 at 17:54:05 UTC, Jon Degenhardt wrote:



Very nice post!


Thanks! If it gets half as many page views as yours did, I'll 
be happy. Yours is the most-viewed post on the blog -- over 
1000 views more than #2 (my GC post), and 5,000 more than #3 (A 
New Import Idiom).


Seems like this crowd-editing stuff really works!

[Issue 17479] Public constructor for std.process.Pid

[via Digitalmars-d-bugs]

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

Chris Wright  changed:

   What|Removed |Added

   Priority|P1  |P3

--

[Issue 17479] New: Public constructor for std.process.Pid

[via Digitalmars-d-bugs]

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

  Issue ID: 17479
   Summary: Public constructor for std.process.Pid
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: dhase...@gmail.com

I am trying to create a program that handles two types of processes:

* Scripts and executables that it runs directly
* Daemons that fork and exit, with a pid file containing the pid of the
lingering daemon process

I want to handle them in the same fashion. It would be convenient to use
std.process to do so.

I can easily parse an integer from a pid file, but in order to construct a
std.process.Pid from that, I need to resort to tupleof hacks and manually
constructing class instances.

It would be better if std.process.Pid exposed its constructors publicly.

For now, I'm using core.sys.posix directly. If I wanted to support Windows,
though, I'd have to copy std.process into my project and make the relevant
constructors public to handle things in a reasonable fashion.

--

Re: .sort vs sort(): std.algorithm not up to the task?

[Andrew Edwards via Digitalmars-d-learn]

On Thursday, 8 June 2017 at 04:15:12 UTC, Stanislav Blinov wrote:


Earns you nothing? How about not performing an allocation and 
copy?


Seen through the eyes of a complete beginner, this means 
absolutely nothing. Those are the eyes I am using as I'm reading 
a book and simply following the instructions provided. I took 
care of the problem with the first thing that came to mind, 
because that all that's required.



aa.keys.sort().release;


somehow, I missed the point that actually came as a byproduct of 
importing sort. When I tried it in the original code it 
"ostensibly" did not work because, i recompiled the edited 
version posed here.



No need to import anything but std.algorithm : sort.

But it doesn't, it decides what i'm gonna get like it or not. 
But the fact, a lot of times I just want to work with the 
underlying data after the operation is performed. And it 
should be noted that this applies to Ranges in general not 
just sort.


A crucial point of any good design is to *not rob the caller of 
useful information*. sort() follows that philosophy. If you 
don't need the extra information, you're free to get rid of it. 
The other way around that you seem to be proposing would 
require having a ton of overloads for sort() for any imaginable 
use case.


No I'm not proposing that at all, if the predicate is initialized 
such that it functions the exact same way it does now, then only 
in instances where necessary would the user need to specify 
anything. Anyway, the functionality I'm asking for is the one 
forded by release so i'm satisfied.


Thank you.

Re: .sort vs sort(): std.algorithm not up to the task?

[Stanislav Blinov via Digitalmars-d-learn]

On Thursday, 8 June 2017 at 04:07:22 UTC, Andrew Edwards wrote:

On Thursday, 8 June 2017 at 03:40:08 UTC, Jonathan M Davis


sort() returns a SortedRange so that other algorithms can 
know...


Yes, I understand that. Again, using "std.range: release" earns 
me nothing more than I already get from "std.array: array" or 
if you prefer "std.range: array".


Earns you nothing? How about not performing an allocation and 
copy?


I can understand if sort returns Range by default but can be 
instructed to return the original representation.




 aa.keys.sort!returnOriginalRepresentation; // or something 
to that effect


"Something to that effect" is exactly this:

aa.keys.sort().release;

No need to import anything but std.algorithm : sort.

But it doesn't, it decides what i'm gonna get like it or not. 
But the fact, a lot of times I just want to work with the 
underlying data after the operation is performed. And it should 
be noted that this applies to Ranges in general not just sort.


A crucial point of any good design is to *not rob the caller of 
useful information*. sort() follows that philosophy. If you don't 
need the extra information, you're free to get rid of it. The 
other way around that you seem to be proposing would require 
having a ton of overloads for sort() for any imaginable use case.

Re: .sort vs sort(): std.algorithm not up to the task?

[Andrew Edwards via Digitalmars-d-learn]

On Thursday, 8 June 2017 at 03:40:08 UTC, Jonathan M Davis wrote:
On Thursday, June 08, 2017 03:15:11 Andrew Edwards via 
Digitalmars-d-learn wrote:


I completely understand the differences between ranges and 
arrays... the thing is, I wasn't working with ranges but 
arrays instead. If sort understands a string or array as a 
sort of range, then given one of those entities, it should 
manipulate it internally and return it in it's original 
flavor. Given an array, return an array unless specifically 
told to do otherwise.


sort() returns a SortedRange so that other algorithms can know 
that the range is sorted and take advantage of that. If sort() 
returned the original range type, it would be detrimental for 
other algorithms. But you can just use the array directly again 
after calling sort or call release() on the SortedRange to get 
the array out of it.


- Jonathan M Davis


Yes, I understand that. Again, using "std.range: release" earns 
me nothing more than I already get from "std.array: array" or if 
you prefer "std.range: array". I can understand if sort returns 
Range by default but can be instructed to return the original 
representation.


 aa.keys.sort!returnOriginalRepresentation; // or something 
to that effect


But it doesn't, it decides what i'm gonna get like it or not. But 
the fact, a lot of times I just want to work with the underlying 
data after the operation is performed. And it should be noted 
that this applies to Ranges in general not just sort.

Re: .sort vs sort(): std.algorithm not up to the task?

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, June 08, 2017 03:15:11 Andrew Edwards via Digitalmars-d-learn 
wrote:
> On Thursday, 8 June 2017 at 02:31:43 UTC, Stanislav Blinov wrote:
> > On Thursday, 8 June 2017 at 02:25:17 UTC, Jonathan M Davis
> > wrote:
> >
> > Oh I see, the was error related to iteration, not sorting.
> >
> >> Ranges do not support iterating with an index. The workaround
> >> if you want to have an index with ranges and foreach, then you
> >> should use lockstep:
> >>
> >> http://dlang.org/phobos/std_range.html#lockstep
> >>
> >> e.g.
> >>
> >> foreach(i, v; lockstep(iota!size_t(0), s))
> >> {}
> >>
> >> or
> >>
> >> foreach(i, v; lockstep(iota(0), s))
> >> {}
> >
> > There's an enumerate():
> > https://dlang.org/phobos/std_range.html#enumerate
> >
> > import std.algorithm : sort;
> > import std.range : enumerate;
> >
> > foreach(i, k; aa.keys.sort().enumerate) {
> >
> > /* ... */
> >
> > }
>
> Note that I already demonstrated the same functionality by
> importing "std.array: array" to get the job done. Neither
> lockstep nor enumerate gets me more benefit in this particular
> situation that array doesn't already get me. My question here is
> not whether the job can get done or not, it's simply why the
> extra work? I still have to import two modules, when before I
> didn't have to import any.
>
> I completely understand the differences between ranges and
> arrays... the thing is, I wasn't working with ranges but arrays
> instead. If sort understands a string or array as a sort of
> range, then given one of those entities, it should manipulate it
> internally and return it in it's original flavor. Given an array,
> return an array unless specifically told to do otherwise.

sort() returns a SortedRange so that other algorithms can know that the
range is sorted and take advantage of that. If sort() returned the original
range type, it would be detrimental for other algorithms. But you can just
use the array directly again after calling sort or call release() on the
SortedRange to get the array out of it.

- Jonathan M Davis

Re: .sort vs sort(): std.algorithm not up to the task?

[Era Scarecrow via Digitalmars-d-learn]

On Thursday, 8 June 2017 at 02:19:15 UTC, Andrew Edwards wrote:
Pretty funny. But seriously, this is something that should just 
work. There is now to layers of indirection to achieve what I 
used to do quite naturally in the language.


 Hmmm while working on my recent sudoku solver using pointers to 
structs, i had opCmp defined, but it was still sorting by pointer 
address rather than how i told it to sort; I had to give it the 
hint of sort!"*a < *b" for it to work right.


 It does seem like a little more duct-tape on the wizard is 
needed in some cases. Thankfully it isn't too complex to know 
where to tape the wand into the wizard's hand.

Re: .sort vs sort(): std.algorithm not up to the task?

[Andrew Edwards via Digitalmars-d-learn]

On Thursday, 8 June 2017 at 02:31:43 UTC, Stanislav Blinov wrote:
On Thursday, 8 June 2017 at 02:25:17 UTC, Jonathan M Davis 
wrote:


Oh I see, the was error related to iteration, not sorting.

Ranges do not support iterating with an index. The workaround 
if you want to have an index with ranges and foreach, then you 
should use lockstep:


http://dlang.org/phobos/std_range.html#lockstep

e.g.

foreach(i, v; lockstep(iota!size_t(0), s))
{}

or

foreach(i, v; lockstep(iota(0), s))
{}


There's an enumerate(): 
https://dlang.org/phobos/std_range.html#enumerate


import std.algorithm : sort;
import std.range : enumerate;

foreach(i, k; aa.keys.sort().enumerate) {
/* ... */
}


Note that I already demonstrated the same functionality by 
importing "std.array: array" to get the job done. Neither 
lockstep nor enumerate gets me more benefit in this particular 
situation that array doesn't already get me. My question here is 
not whether the job can get done or not, it's simply why the 
extra work? I still have to import two modules, when before I 
didn't have to import any.


I completely understand the differences between ranges and 
arrays... the thing is, I wasn't working with ranges but arrays 
instead. If sort understands a string or array as a sort of 
range, then given one of those entities, it should manipulate it 
internally and return it in it's original flavor. Given an array, 
return an array unless specifically told to do otherwise.

[Issue 17478] New: Socket.select return a write status change, but no connection is established.

[via Digitalmars-d-bugs]

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

  Issue ID: 17478
   Summary: Socket.select return a write status change, but no
connection is established.
   Product: D
   Version: D2
  Hardware: x86_64
OS: Other
Status: NEW
  Severity: critical
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: encounterspr...@gmail.com

OS : debian 8


code below:

import std.socket;
import std.stdio;
import std.conv;

bool connect(string host , ushort port , int seconds)
{
 import std.stdio;

 string strPort = to!string(port);
 AddressInfo[] arr = getAddressInfo(host , strPort ,
AddressInfoFlags.CANONNAME);
 if(arr.length == 0)
 {
writeln("getAddressInfo error");
return false;

 }

Socket socket = new Socket(arr[0].family , arr[0].type , arr[0].protocol);
socket.blocking(false);
socket.connect(arr[0].address);

SocketSet writesets = new SocketSet();
writesets.reset();

writesets.add(socket);


TimeVal val;

val.seconds = seconds ;
val.microseconds = 0;


int ret = Socket.select(null ,writesets , null  , );
if(ret < 0)
{
writeln("some error or interput");
return false;

}
else if(ret == 0)
{
writeln("timeout");
return false;

}
else
{
if(writesets.isSet(socket))
{
writeln("connected");
return true;   
}

return false;   
}   
}

void main()
{
//1234 not listen in my OS. but socket.select show me connected.
connect("127.0.0.1" , 1234 ,3);
}

--

Re: .sort vs sort(): std.algorithm not up to the task?

[Seb via Digitalmars-d-learn]

On Thursday, 8 June 2017 at 01:57:47 UTC, Andrew Edwards wrote:
Ranges may be finite or infinite but, while the destination may 
be unreachable, we can definitely tell how far we've traveled. 
So why doesn't this work?

...
If I hand you a chihuahua for grooming, why am I getting back a 
pit bull? I simply want a groomed chihuahua. Why do I need to 
consult a wizard to get back a groomed chihuahua?


A magician should never reveal his secrets, but this I do share.
.sort() returns a SortedRange [1] that encapsulates the range.
The trick is to use .release() to release the controlled range 
and return it, e.g.


import std.algorithm : sort;
auto keys = aa.keys.sort().release;

[1] https://dlang.org/phobos/std_range.html#SortedRange

Re: .sort vs sort(): std.algorithm not up to the task?

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, June 08, 2017 02:31:43 Stanislav Blinov via Digitalmars-d-learn 
wrote:
> On Thursday, 8 June 2017 at 02:25:17 UTC, Jonathan M Davis wrote:
>
> Oh I see, the was error related to iteration, not sorting.
>
> > Ranges do not support iterating with an index. The workaround
> > if you want to have an index with ranges and foreach, then you
> > should use lockstep:
> >
> > http://dlang.org/phobos/std_range.html#lockstep
> >
> > e.g.
> >
> > foreach(i, v; lockstep(iota!size_t(0), s))
> > {}
> >
> > or
> >
> > foreach(i, v; lockstep(iota(0), s))
> > {}
>
> There's an enumerate():
> https://dlang.org/phobos/std_range.html#enumerate
>
> import std.algorithm : sort;
> import std.range : enumerate;
>
> foreach(i, k; aa.keys.sort().enumerate) {
>  /* ... */
> }

Even better. I hadn't realized that such a function had been added.

- Jonathan M Davis

[Issue 15692] Allow struct member initializer everywhere

[via Digitalmars-d-bugs]

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

greensunn...@gmail.com changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #4 from greensunn...@gmail.com ---
I just revived a DIP that deals with this topic:
https://github.com/dlang/DIPs/pull/71

Help to polish it is welcome ;-)

--

Re: .sort vs sort(): std.algorithm not up to the task?

[Stanislav Blinov via Digitalmars-d-learn]

On Thursday, 8 June 2017 at 02:25:17 UTC, Jonathan M Davis wrote:

Oh I see, the was error related to iteration, not sorting.

Ranges do not support iterating with an index. The workaround 
if you want to have an index with ranges and foreach, then you 
should use lockstep:


http://dlang.org/phobos/std_range.html#lockstep

e.g.

foreach(i, v; lockstep(iota!size_t(0), s))
{}

or

foreach(i, v; lockstep(iota(0), s))
{}


There's an enumerate(): 
https://dlang.org/phobos/std_range.html#enumerate


import std.algorithm : sort;
import std.range : enumerate;

foreach(i, k; aa.keys.sort().enumerate) {
/* ... */
}

Re: Compile-Time Sort in D

[Jonathan M Davis via Digitalmars-d-announce]

On Thursday, June 08, 2017 01:08:42 Jon Degenhardt via Digitalmars-d-
announce wrote:
> I was surprised as well, pleasantly of course. Using a simple
> example may have helped. Personally, I'm not bothered by the
> specific instances of negative feedback on Reddit. It's hard to
> write a post that manages to avoid that sort of thing entirely.
> It was also nice to see related follow-up in the D forums ("how
> to count lines fast" and "std.csv Performance Review"). It's less
> if the case for how well suited D's facilities are for the type
> of problem came across. It's much more clear in the Compile-Time
> Sort post.

And even the reddit discussion on the compile-time sort post devolved a bit
into arguments over stuff like enums as manifest constants. Using reddit to
get information out there is useful, but from what I've seen, the comments
usually devolve into a fairly negative discussion. I don't spend much time
on reddit though.

- Jonathan M Davis

Re: .sort vs sort(): std.algorithm not up to the task?

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, June 08, 2017 01:57:47 Andrew Edwards via Digitalmars-d-learn 
wrote:
> Ranges may be finite or infinite but, while the destination may
> be unreachable, we can definitely tell how far we've traveled. So
> why doesn't this work?
>
> import std.traits;
> import std.range;
>
> void main()
> {
>  string[string] aa;
>
>  // what others have referred to as
>  // standard sort works but is deprecated
>  //auto keys = aa.keys.sort;
>
>  // Error: cannot infer argument types, expected 1 argument,
> not 2
>  import std.algorithm: sort;
>  auto keys = aa.keys.sort();
>
>  // this works but why should I have to?
>  //import std.array: array;
>  //auto keys = aa.keys.sort().array;
>
>  foreach (i, v; keys){}
> }

Ranges do not support iterating with an index. The workaround if you want to
have an index with ranges and foreach, then you should use lockstep:

http://dlang.org/phobos/std_range.html#lockstep

e.g.

foreach(i, v; lockstep(iota!size_t(0), s))
{}

or

foreach(i, v; lockstep(iota(0), s))
{}

if you don't mind i being an int instead of a size_t.

Now, with your example, there are two other solutions that are even easier.
sort() sorts the range that it's given in place but returns a wrapper range
so that other algorithms can recognize the range as sorted. So, if you did

auto keys = aa.keys;
sort(keys);

foreach(i; v)
{}

then it will work just fine, because you're still dealing with an array.
Alternatively, you could use SortedRange's release function to get the array
out of the SortedRange (though note if you do that, you shouldn't then use
the SortedRange anymore, since it does a move call to actual move the
wrapped range out of the SortedRange). e.g.

auto keys = aa.keys.sort().release();

foreach(i; v)
{}

and that would allow you to still do it in one line.

- Jonathan M Davis

Re: .sort vs sort(): std.algorithm not up to the task?

[Andrew Edwards via Digitalmars-d-learn]

On Thursday, 8 June 2017 at 02:21:03 UTC, Stanislav Blinov wrote:


aa.keys.sort() should just work as is: aa.keys returns a 
string[], and that's a random access range that can be sorted. 
What exactly is the error?


It does not ... I provided the code and related error message. 
See the line right above "import std.algorith: sort;".

Re: .sort vs sort(): std.algorithm not up to the task?

[Stanislav Blinov via Digitalmars-d-learn]

On Thursday, 8 June 2017 at 01:57:47 UTC, Andrew Edwards wrote:
Ranges may be finite or infinite but, while the destination may 
be unreachable, we can definitely tell how far we've traveled. 
So why doesn't this work?


import std.traits;
import std.range;

void main()
{
string[string] aa;

// what others have referred to as
// standard sort works but is deprecated
//auto keys = aa.keys.sort;

// Error: cannot infer argument types, expected 1 argument, 
not 2

import std.algorithm: sort;
auto keys = aa.keys.sort();

// this works but why should I have to?
//import std.array: array;
//auto keys = aa.keys.sort().array;

foreach (i, v; keys){}
}

If I hand you a chihuahua for grooming, why am I getting back a 
pit bull? I simply want a groomed chihuahua. Why do I need to 
consult a wizard to get back a groomed chihuahua?


aa.keys.sort() should just work as is: aa.keys returns a 
string[], and that's a random access range that can be sorted. 
What exactly is the error?

Re: .sort vs sort(): std.algorithm not up to the task?

[Andrew Edwards via Digitalmars-d-learn]

On Thursday, 8 June 2017 at 02:19:15 UTC, Andrew Edwards wrote:
Pretty funny. But seriously, this is something that just work. 
There is now to layers of indirection to achieve what I used to 
do quite naturally in the language.


*should just work

Re: .sort vs sort(): std.algorithm not up to the task?

[Andrew Edwards via Digitalmars-d-learn]

On Thursday, 8 June 2017 at 02:07:07 UTC, Mike B Johnson wrote:

On Thursday, 8 June 2017 at 01:57:47 UTC, Andrew Edwards wrote:
If I hand you a chihuahua for grooming, why am I getting back 
a pit bull? I simply want a groomed chihuahua. Why do I need 
to consult a wizard to get back a groomed chihuahua?


Because is like a poodle and unless you get your hair cut in a 
special way you won't be considered for the job! The wizard 
only exists to balance the symmetric arrangement of the 
interplanetary forces, don't fear him, he does his job in a 
very predictable way.


Pretty funny. But seriously, this is something that just work. 
There is now to layers of indirection to achieve what I used to 
do quite naturally in the language.

Re: .sort vs sort(): std.algorithm not up to the task?

[Mike B Johnson via Digitalmars-d-learn]

On Thursday, 8 June 2017 at 01:57:47 UTC, Andrew Edwards wrote:
If I hand you a chihuahua for grooming, why am I getting back a 
pit bull? I simply want a groomed chihuahua. Why do I need to 
consult a wizard to get back a groomed chihuahua?


Because is like a poodle and unless you get your hair cut in a 
special way you won't be considered for the job! The wizard only 
exists to balance the symmetric arrangement of the interplanetary 
forces, don't fear him, he does his job in a very predictable way.

.sort vs sort(): std.algorithm not up to the task?

[Andrew Edwards via Digitalmars-d-learn]

Ranges may be finite or infinite but, while the destination may 
be unreachable, we can definitely tell how far we've traveled. So 
why doesn't this work?


import std.traits;
import std.range;

void main()
{
string[string] aa;

// what others have referred to as
// standard sort works but is deprecated
//auto keys = aa.keys.sort;

// Error: cannot infer argument types, expected 1 argument, 
not 2

import std.algorithm: sort;
auto keys = aa.keys.sort();

// this works but why should I have to?
//import std.array: array;
//auto keys = aa.keys.sort().array;

foreach (i, v; keys){}
}

If I hand you a chihuahua for grooming, why am I getting back a 
pit bull? I simply want a groomed chihuahua. Why do I need to 
consult a wizard to get back a groomed chihuahua?

Re: [Solved] Confusing error message

[bachmeier via Digitalmars-d-learn]

On Wednesday, 7 June 2017 at 21:13:37 UTC, H. S. Teoh wrote:
On Wed, Jun 07, 2017 at 11:16:14PM +0300, drug via 
Digitalmars-d-learn wrote:

07.06.2017 22:40, bachmeier пишет:

[...]
> In any event, I made a second suggestion that would always 
> work. If it can't find a match, it asks if you're missing an 
> import statement, as a way to provide the new D programmer a 
> hint of what to look for.

That's a good point.


Does that mean that every time you make a typo or pass wrong 
arguments to a template function, the compiler will ask if 
you're missing an import?



T


Is there a reason to not do that? The lengthy error messages 
don't mean much to new D programmers now. Adding a few additional 
words to help them shouldn't be a problem.

Re: better string

[Mike B Johnson via Digitalmars-d]

On Thursday, 8 June 2017 at 00:59:06 UTC, Stanislav Blinov wrote:

On Wednesday, 7 June 2017 at 23:57:44 UTC, Mike B Johnson wrote:

Or will simply setting "alias string = wstring;" at the top of 
my program end up having the entire program, regardless of 
what it is, use wstring's instead of strings?


It doesn't work that way and it can't work that way: you'd 
never be able to link against anything if it did.




Not true, way to overgeneralize!

The reason I say this is because I converted my program to use 
wstrings...


Why? Why trade one variable-width encoding for another, 
especially a nasty one like UTF-16?


um, because I'm god and I get to wear the big boy pants.

Re: Compile-Time Sort in D

[Jon Degenhardt via Digitalmars-d-announce]

On Wednesday, 7 June 2017 at 20:59:50 UTC, Joakim wrote:

On Tuesday, 6 June 2017 at 01:08:45 UTC, Mike Parker wrote:

On Monday, 5 June 2017 at 17:54:05 UTC, Jon Degenhardt wrote:



Very nice post!


Thanks! If it gets half as many page views as yours did, I'll 
be happy. Yours is the most-viewed post on the blog -- over 
1000 views more than #2 (my GC post), and 5,000 more than #3 
(A New Import Idiom).


I was surprised it's so popular, as the proggit thread didn't 
do that great, but it did well on HN and I now see it inspired 
more posts for Rust (written by bearophile, I think) and Go, in 
addition to the Nim post linked here before:


https://users.rust-lang.org/t/faster-command-line-tools-in-d-rust/10992
https://aadrake.com/posts/2017-05-29-faster-command-line-tools-with-go.html


I was surprised as well, pleasantly of course. Using a simple 
example may have helped. Personally, I'm not bothered by the 
specific instances of negative feedback on Reddit. It's hard to 
write a post that manages to avoid that sort of thing entirely. 
It was also nice to see related follow-up in the D forums ("how 
to count lines fast" and "std.csv Performance Review"). It's less 
if the case for how well suited D's facilities are for the type 
of problem came across. It's much more clear in the Compile-Time 
Sort post.


--Jon

Re: better string

[Stanislav Blinov via Digitalmars-d]

On Wednesday, 7 June 2017 at 23:57:44 UTC, Mike B Johnson wrote:

Or will simply setting "alias string = wstring;" at the top of 
my program end up having the entire program, regardless of what 
it is, use wstring's instead of strings?


It doesn't work that way and it can't work that way: you'd never 
be able to link against anything if it did.


The reason I say this is because I converted my program to use 
wstrings...


Why? Why trade one variable-width encoding for another, 
especially a nasty one like UTF-16?

Re: better string

[Jonathan M Davis via Digitalmars-d]

On Wednesday, June 07, 2017 10:58:06 Mike B Johnson via Digitalmars-d wrote:
> Why not alias string so that one can easily switch from the old
> string or wstring, etc?
>
> e.g., rename string internally to sstring or whatever.
>
> then globally define
>
> alias string = sstring;
>
> Which can be over realiased to wstring to affect the whole program
>
> alias string = wstring;
>
> Or use a command line to set it or whatever makes you happy.
>
> I'm in the progress of converting a large source code database to
> use the above technique so we can move to using wstring... it is
> not fun. Most code that works with a string should with any
> string encoding, so it shouldn't matter. Making D string
> agnostic(after all, the only main different in 99% of programs is
> the space they take up).
>
> If you are worried about it causing subtle bugs, then don't...
> because those same bugs would occur if one manually had to switch.
>
> By designing techniques to use strings that are agnostic of there
> internal representation should save a lot of headache. For those
> few cases that it matters, simple static analysis works fine.

The official solution for handling multiple string types is to templatize
code and operate on ranges of charaters.

Regardless, all string is is an alias. All of the problems that you're
running into relate to the fact that all built-in D facilities use UTF-8
when they have to choose a character type. Most would agree that if you have
to pick, UTF-8 is the better choice. And it doesn't make sense for something
like .stringof or toString to vary in string type, because D doesn't
overload based on return type, and making those change based on a compiler
flag would make D libraries incompatible with one another if they're not
built exactly the same way. In addition, we'd get yet more problems akin to
what happens with size_t when someone always builds their code on 32-bit or
always on 64-bit and never on the other. Not many types in D vary based on
platform, but the ones that do tend to result in bugs due to folks not
building and testing their code on enough platforms.

In D, it is generally considered best practice to use UTF-8 everywhere in
your code except in places where you need to use UTF-16 or UTF-32. For a lot
of programs, that means using UTF-8 everywhere and then the standard library
functions deal with system APIs for stuff like dealing with files, since
Windows uses UTF-16 for many of its APIs. If you're using the Windows API
directly, that then means doing the conversion yourself with functions like
toUTFz, but most programs don't have to worry about that, and it's still
considered best practice for those that do to convert to UTF-16 when they
have to but to use UTF-8 as much as possible.

If you want to use UTF-16 everywhere throughout your program, then you
certainly can, and many of the standard library facilities will work just
fine that way, because they're templatized and deal with the differences in
character types, but the language and runtime use UTF-8 when they had to
make a choice, and most any library you're going to find for D is going to
use UTF-8 in its API when it's not templated code. I don't think that you're
going to find much support for the idea that you can change all of the
string types in a program with a compiler switch.

D provides solid facilities for converting between different UTF character
encodings, and templates allow you to write code that is encoding-agnostic,
but doing something like Windows' TCHAR is a whole other kettle of fish.

D's general approach is to make it so that the types do not vary from
platform to platform. There are a few cases where it's done to get at the
full address space (size_t) or to get full access to the hardware's
capabilities (real) - or simply because there is no way around it (e.g.
pointers are going to be 32-bits on 32-bit systems and 64-bit or 64-bit
systems) - but in general, the idea has been to make the types vary based on
the platform as little as reasonably possible, and nowhere do the built-in
types vary based on compiler flags. And I would not expect that to change.

But if you feel strongly about it, you can certainly create a DIP and try to
get your proposed changes into the language:

https://github.com/dlang/DIPs

- Jonathan M Davis

Re: DIP 1007--"future symbol"--Formal Review

[Walter Bright via Digitalmars-d]

On 6/7/2017 3:36 AM, Mike Parker wrote:
The first stage of the formal review for DIP 1007 [1], "'future symbol' Compiler 
Concept", is now underway. From now until 11:59 PM ET on June 21 (3:59 AM GMT on 
June 22), the community has the opportunity to provide last-minute feedback. If 
you missed the preliminary review [2], this is your chance to provide input.


At the end of the feedback period, I will submit the DIP to Walter and Andrei 
for their final decision. Thanks in advance to those of you who participate.


[1] 
https://github.com/dlang/DIPs/blob/4ae4b8c4ebc69d46b4801856b01474367065e7b6/DIPs/DIP1007.md 


[2] http://forum.dlang.org/post/hjdstwzhcbrektlij...@forum.dlang.org


And an implementation too, which has been around for a while:

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

Re: better string

[Mike B Johnson via Digitalmars-d]

On Wednesday, 7 June 2017 at 21:32:25 UTC, ag0aep6g wrote:

On 06/07/2017 12:58 PM, Mike B Johnson wrote:
Why not alias string so that one can easily switch from the 
old string or wstring, etc?


e.g., rename string internally to sstring or whatever.

then globally define

alias string = sstring;

Which can be over realiased to wstring to affect the whole 
program


alias string = wstring;

Or use a command line to set it or whatever makes you happy.


I'm not sure what exactly you're asking for, but `string` is an 
alias already (of `immutable(char)[]`). And you can define your 
own `string` as you like. `alias string = wstring;` works.


But that isn't program/compiler wide. e.g., stringof won't return 
a wstring if you do the alias, will it?


Or will simply setting "alias string = wstring;" at the top of my 
program end up having the entire program, regardless of what it 
is, use wstring's instead of strings?


e.g.,

when I do a string literal

"This is a string" but do your alias, is the literal a string or 
wstring?


The reason I say this is because I converted my program to use 
wstrings but I got many errors because of string literals being 
interpreted as strings and no automatic conversion took place, I 
had to append w to turn then in to wstrings.

Re: Ali's slides from his C++Now talk

[Ali Çehreli via Digitalmars-d]

On 06/07/2017 09:56 AM, Ali Çehreli wrote:

On 06/07/2017 08:58 AM, Steven Schveighoffer wrote:


The video is up: https://www.youtube.com/watch?v=vYEKEIpM2zo


Ali, what was the fiber question you couldn't answer?

-Steve


I wouldn't remember the question even when watching it myself, except
for one word that I luckily repeated: "symmetric". So, the question was
whether D's fibers were symmetric, a concept totally alien to me... :)
I've now learned that yes, D's fibers are symmetrical:


https://stackoverflow.com/questions/41891989/what-is-the-difference-between-asymmetric-and-symmetric-coroutines


Ali



Reading it again, now I think D's fibers are asymmetric. Any experts in 
the house?


Ali

[Issue 17477] DMD error message for delegate with wrong attributes is very confusing

[via Digitalmars-d-bugs]

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

Eyal  changed:

   What|Removed |Added

   Keywords||diagnostic

--

[Issue 17477] New: DMD error message for delegate with wrong attributes is very confusing

[via Digitalmars-d-bugs]

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

  Issue ID: 17477
   Summary: DMD error message for delegate with wrong attributes
is very confusing
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@weka.io

When compiling this invalid program:

void f(void delegate(int) nothrow dlg) {}

void main() {
void g(int x) {}
f((x){ g(x); });
}

The error reported is:

Error: function f (void delegate(int) nothrow dlg) is not callable using
argument types (void)

This is wrong, as the argument type is not (void). It is also very difficult to
figure out what is wrong with this program from this error (when the code is
far more complicated).

A better error would be:

Error: function f expects (void delegate(int) **nothrow** dlg) but was given
(void delegate(int))

--

[Issue 17473] foreach on delegates incorrectly rejected

[via Digitalmars-d-bugs]

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

--- Comment #5 from Eyal  ---
(In reply to Vladimir Panteleev from comment #4)
> Adding `ref` to `char a` fixes compilation, but it's still weird that
> `ref`'s presence is inconsistently needed.

It also changes the meaning of the program in an undesired way.

--

Re: Compile-Time Sort in D

[Stefan Koch via Digitalmars-d-announce]

On Wednesday, 7 June 2017 at 21:47:58 UTC, John Carter wrote:

On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:

https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/


Seems like you have inspired people...

http://blog.zdsmith.com/posts/compiletime-sort-in-nim.html


We should make another post showing the string import feature.

[Issue 17473] foreach on delegates incorrectly rejected

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||ag0ae...@gmail.com

--

Re: Black Duck: DMD license corrected

[Walter Bright via Digitalmars-d-announce]

Thanks for taking care of this.

Re: Compile-Time Sort in D

[John Carter via Digitalmars-d-announce]

On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:

https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/


Seems like you have inspired people...

http://blog.zdsmith.com/posts/compiletime-sort-in-nim.html

Re: better string

[ag0aep6g via Digitalmars-d]

On 06/07/2017 12:58 PM, Mike B Johnson wrote:
Why not alias string so that one can easily switch from the old string 
or wstring, etc?


e.g., rename string internally to sstring or whatever.

then globally define

alias string = sstring;

Which can be over realiased to wstring to affect the whole program

alias string = wstring;

Or use a command line to set it or whatever makes you happy.


I'm not sure what exactly you're asking for, but `string` is an alias 
already (of `immutable(char)[]`). And you can define your own `string` 
as you like. `alias string = wstring;` works.

Re: vibe.d on Web Framework Benchmarks

[H. S. Teoh via Digitalmars-d]

On Thu, Jun 08, 2017 at 12:18:21AM +0300, ketmar via Digitalmars-d wrote:
> Ozan wrote:
> 
> > On Wednesday, 7 June 2017 at 09:44:55 UTC, Ali Çehreli wrote:
> > > Is there an issue with the tests? Surprised that vibe.d is not
> > > higher in the rating...
> > > 
> > > https://www.techempower.com/benchmarks/#section=data-r14=ph=fortune
> > > 
> > Same for me.
> > I used a lot of Java (Jetty, Tomcat) and Groovy (Grails) stuff
> > before using D (vibe.d).
> > On my machine I got a factor of 10-50 in difference. Vibe.d was
> > always much faster.
> > 
> > So where are the results coming from?
> 
> most of it came from microbenchmarking. "how fast can we parse json
> and query db?" wow, what a great benchmark! surely, we don't need to
> do any data processing, let's measure raw speed of parsing data, and
> then throwing it away!

Yes, data processing performance is not important; parsing is what we
must optimize!


T

-- 
A program should be written to model the concepts of the task it performs 
rather than the physical world or a process because this maximizes the 
potential for it to be applied to tasks that are conceptually similar and, more 
important, to tasks that have not yet been conceived. -- Michael B. Allen

Re: [Solved] Confusing error message

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

On Wed, Jun 07, 2017 at 11:16:14PM +0300, drug via Digitalmars-d-learn wrote:
> 07.06.2017 22:40, bachmeier пишет:
[...]
> > In any event, I made a second suggestion that would always work. If
> > it can't find a match, it asks if you're missing an import
> > statement, as a way to provide the new D programmer a hint of what
> > to look for.
> That's a good point.

Does that mean that every time you make a typo or pass wrong arguments
to a template function, the compiler will ask if you're missing an
import?


T

-- 
Being able to learn is a great learning; being able to unlearn is a greater 
learning.

Re: vibe.d on Web Framework Benchmarks

[ketmar via Digitalmars-d]

Ozan wrote:


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


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


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


So where are the results coming from?


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

Re: vibe.d on Web Framework Benchmarks

[bauss via Digitalmars-d]

On Wednesday, 7 June 2017 at 14:56:56 UTC, Ozan wrote:

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



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

Ali


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


So where are the results coming from?

Regards, Ozan


I second this.

I have always had better performance with vibe.d versus other 
frameworks.

Re: sqlite3 vs. sqlite-d

[H. S. Teoh via Digitalmars-d]

On Wed, Jun 07, 2017 at 08:40:12PM +, Stefan Koch via Digitalmars-d wrote:
> [...]  Also sqlite-d is inefficient in quite a few places and is
> slowed down by auto-decoding as I discovered just now.

*dreams of a day when we can finally be free of auto-decoding...*


T

-- 
If you think you are too small to make a difference, try sleeping in a closed 
room with a mosquito. -- Jan van Steenbergen

Re: Compile-Time Sort in D

[Joakim via Digitalmars-d-announce]

On Tuesday, 6 June 2017 at 01:08:45 UTC, Mike Parker wrote:

On Monday, 5 June 2017 at 17:54:05 UTC, Jon Degenhardt wrote:



Very nice post!


Thanks! If it gets half as many page views as yours did, I'll 
be happy. Yours is the most-viewed post on the blog -- over 
1000 views more than #2 (my GC post), and 5,000 more than #3 (A 
New Import Idiom).


I was surprised it's so popular, as the proggit thread didn't do 
that great, but it did well on HN and I now see it inspired more 
posts for Rust (written by bearophile, I think) and Go, in 
addition to the Nim post linked here before:


https://users.rust-lang.org/t/faster-command-line-tools-in-d-rust/10992
https://aadrake.com/posts/2017-05-29-faster-command-line-tools-with-go.html

Re: Concept proposal: Safely catching error

[ag0aep6g via Digitalmars-d]

On 06/07/2017 09:45 PM, ag0aep6g wrote:
When no @trusted code is involved, then catching an out-of-bounds error 
from a @safe function is safe. No additional rules are needed. Assuming 
no compiler bugs, a @safe function simply cannot corrupt memory without 
calling @trusted code.


Thinking a bit more about this, I'm not sure if it's entirely correct. 
Can a @safe language feature throw an Error *after* corrupting memory? 
For example, could `a[i] = n;` write the value first and do the bounds 
check afterwards? There's probably a better example, if this kind of 
"shoot first, ask questions later" style ever makes sense.


If bounds checking could be implemented like that, you wouldn't be able 
to ever catch the resulting error safely. Wouldn't matter if it comes 
from @safe or @trusted code. Purity wouldn't matter either, because an 
arbitrary write like that doesn't care about purity.

Re: sqlite3 vs. sqlite-d

[Stefan Koch via Digitalmars-d]

On Wednesday, 7 June 2017 at 20:12:22 UTC, cym13 wrote:

It should be noted that the benchmark isn't fair, it favours 
the sqlite3 implementation as parsing and preparing the 
statement isn't measured. And yes, it's still faster which is 
cool ^^




Yes the benchmark is biased slightly in favor of sqlite3 C 
implementation.
But sqlite-d does not have the ability to parse sql to the point 
where it could implement that functionality.
Also sqlite-d is inefficient in quite a few places and is slowed 
down by auto-decoding as I discovered just now.

Re: [Solved] Confusing error message

[drug via Digitalmars-d-learn]

07.06.2017 22:40, bachmeier пишет:

On Wednesday, 7 June 2017 at 19:02:59 UTC, drug wrote:

How do compiler know that you want use `std.conv.to` instead of 
_already imported_ `core.time.to`? In general it's impossible. There 
is no way for compiler to guess that you want some other symbol from 
out there. What if you've imported `std.conv.to` but want to use 
`core.time.to` - what should compiler do in this case?

What about `writeln` - it's too different.


The differences with writeln are not really relevant if we're talking 
about error messages. The compiler knows someone is calling function 
`to`. If you've already imported std.conv.to, then there's no reason to 
print anything.
Why? I have imported `std.conv.to`, but want `core.time.to` (inverted 
case), what should compiler do to be a good one for newcomers?


In any event, I made a second suggestion that would always work. If it 
can't find a match, it asks if you're missing an import statement, as a 
way to provide the new D programmer a hint of what to look for.

That's a good point.

Re: sqlite3 vs. sqlite-d

[cym13 via Digitalmars-d]

On Wednesday, 7 June 2017 at 17:51:30 UTC, Stefan Koch wrote:

Hi guys

I made a small video.
Mature and heavily optimized C library vs. young D upstart.

See for yourself how it turns out.

https://www.youtube.com/watch?v=mOeVftcVsvI

Cheers,
Stefan


It should be noted that the benchmark isn't fair, it favours the 
sqlite3 implementation as parsing and preparing the statement 
isn't measured. And yes, it's still faster which is cool ^^


Also for the lazy ones that like reading code: 
https://github.com/UplinkCoder/sqlite-d

Black Duck: DMD license corrected

[Andre Pany via Digitalmars-d-announce]

Hi,

Black duck is a software and a service for enterprises to 
evaluate the usage of OSS in their products to avoid legal risks. 
DMD license type is now corrected.


There is also a non commercial public available service of Black 
duck called OpenHub. Here is DMD still listed with the old 
license, but that will change in the next weeks with the next 
knowledge base update.

https://www.openhub.net/p/dmd

Kind regards
André

Re: Can assumeSafeAppend() grab more and more capacity?

[Steven Schveighoffer via Digitalmars-d-learn]

On 6/7/17 3:56 AM, Biotronic wrote:

On Wednesday, 7 June 2017 at 05:43:06 UTC, ag0aep6g wrote:

[snip]


It seems to me this is a topic worthy of a more in-depth article. If
only I felt up to that. :p


Your understanding and explanation is excellent actually!



When you create a slice 'a' in D (with the current GC and druntime, at
least), what happens behind the scenes is the allocator chops off a
block of N bytes, where N is some number larger than
a.length*typeof(a[0]).sizeof. For an array of two ints, N is 16.
For good measure, let's make a copy 'b' of that slice (it will come in
handy later):

int[] a = [1, 2];
int[] b = a;

import std.stdio;
writeln(a.capacity);

3

writeln(b.capacity);

3


The capacity is 3. Intriguing, as a block of 16 bytes should be able to
hold 4 ints.

We can ask the GC for more info on this block:

import core.memory;
auto info = GC.query(a.ptr);
writefln("0x%x, %s, %s ", info.base, info.size, info.attr);

0x2211010, 16, 10


That's the pointer to the start of the block, the size of the block, and
various attributes (appendable, e.g.).
We can get the raw data of the block:

auto block = (cast(ubyte*)info.base)[0..info.size];
writeln(block);

[1, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 8]


We can see our 1 and 2 in there, and a curious 8 at the end. That's the
currently used data, in bytes. That's also the reason the capacity is 3,
not 4 - this info has to live somewhere. If we were to append another
element, and print the data again:

a ~= 3;
writeln(block);

[1, 0, 0, 0, 2, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 12]


See how the last byte changed to a 12? That just so happens to be
a.length*int.sizeof.


To be more specific, for blocks <= 256 bytes, 1 byte is reserved at the 
end of the array to store the length. For blocks > 256 bytes and <= 2048 
bytes, 2 bytes are reserved at the end of the block to store the length 
of the array. For larger blocks, those are PAGE size and larger, and 
they have a special feature. Such blocks are not limited to a power of 
2, and can be extended literally in-place by tacking on additional 
PAGEs. I wanted to just put a size_t at the end, but my problem with 
this is that the length then would move around as you appended or shrunk 
blocks. Given how the runtime works, it's possible that 2 threads could 
be potentially appending at the same time to a shared array, so I 
decided to store it at the beginning of the block instead.


I would actually like to replace this mechanism with one that stores the 
length outside the block and into a separate memory space, as it is 
horrible for caches. Allocate a page of bytes, and you actually get 2 
pages - size_t.sizeof.


Note, for types with destructors, more bytes are reserved to store the 
type info of the array elements. I didn't write that part, so I'm not 
100% sure how it works.



Now for a curious thing: what happens to a's capacity when we append to b?

b ~= 4;
writeln(a.capacity);

3


As above, the length of a in bytes equals the used bytes in the
allocated memory block, and so both a and b have capacity again.


Yes, for this reason, calling assumeSafeAppend is unsafe and can *never* 
be part of the normal treatment of arrays. It is on you, the programmer, 
to ensure that no references to the no-longer-allocated portion of the 
array exist. The compiler can't ensure it, a library function can't 
ensure it, and they are similar to dangling pointers.


Only a library type which encapsulates the array completely can use 
assumeSafeAppend.


For example, imagine if these are immutable arrays, you have now 
overwritten immutable data!


-Steve

Re: Concept proposal: Safely catching error

[ag0aep6g via Digitalmars-d]

On 06/07/2017 05:19 PM, Olivier FAURE wrote:
How does `@trusted` fit into this? The premise is that there's a bug 
somewhere. You can't assume that the bug is in a `@system` function. 
It can just as well be in a `@trusted` one. And then `@safe` and 
`pure` mean nothing.


I think I mistyped there. Makes more sense this way: "You can't assume 
that the bug is in a **`@safe`** function. It can just as well be in a 
`@trusted` one."


The point of this proposal is that catching Errors should be considered 
@safe under certain conditions; code that catch Errors properly would be 
considered as safe as any other code, which is, "as safe as the @trusted 
code it calls".


When no @trusted code is involved, then catching an out-of-bounds error 
from a @safe function is safe. No additional rules are needed. Assuming 
no compiler bugs, a @safe function simply cannot corrupt memory without 
calling @trusted code.


You gave the argument against catching out-of-bounds errors as: "it 
means an invariant is broken, which means the code surrounding it 
probably makes invalid assumptions and shouldn't be trusted."


That line of reasoning applies to @trusted code. Only @trusted code can 
lose its trustworthiness. @safe code is guaranteed trustworthy (except 
for calls to @trusted code).


So the argument against catching out-of-bounds errors is that there 
might be misbehaving @trusted code. And for misbehaving @trusted code 
you can't tell the reach of the potential corruption by looking at the 
function signature.


I think the issue of @trusted is tangential to this. If you (or the 
writer of a library you use) are using @trusted to cast away pureness 
and then have side effects, you're already risking data corruption and 
undefined behavior, catching Errors or no catching Errors.


It's not about intentional misuse of the @trusted attribute. @trusted 
functions must be safe.


The point is that an out-of-bounds error implies a bug somewhere. If the 
bug is in @safe code, it doesn't affect safety at all. There is no 
explosion. But if the bug is in @trusted code, you can't determine how 
large the explosion is by looking at the function signature.

Re: [Solved] Confusing error message

[bachmeier via Digitalmars-d-learn]

On Wednesday, 7 June 2017 at 19:02:59 UTC, drug wrote:

How do compiler know that you want use `std.conv.to` instead of 
_already imported_ `core.time.to`? In general it's impossible. 
There is no way for compiler to guess that you want some other 
symbol from out there. What if you've imported `std.conv.to` 
but want to use `core.time.to` - what should compiler do in 
this case?

What about `writeln` - it's too different.


The differences with writeln are not really relevant if we're 
talking about error messages. The compiler knows someone is 
calling function `to`. If you've already imported std.conv.to, 
then there's no reason to print anything.


In any event, I made a second suggestion that would always work. 
If it can't find a match, it asks if you're missing an import 
statement, as a way to provide the new D programmer a hint of 
what to look for.

Re: rawRead using a struct with variable leght

[Era Scarecrow via Digitalmars-d-learn]

On Wednesday, 7 June 2017 at 18:31:41 UTC, H. S. Teoh wrote:
"Structs" with variable size fields have no direct equivalent 
in D's type system, so you'll probably have a hard time mapping 
this directly.


What you *could* do, though, is to load the data into a ubyte[] 
buffer, then create a proxy struct containing arrays where you 
have variable-sized fields, with the arrays slicing the ubyte[] 
buffer appropriately.  Unfortunately, yes, this means you have 
to parse the fields individually in order to construct these 
slices.


 I'm reminded a little bit of how I ended up handling the records 
and subrecords for Morrowind files; I ended up creating a range 
type which recognized the different types and returned the 
records, then a second one that cycled through the sub records 
and generated the structs as it went.


 Although those were incredibly simple, it was 2 fields, the name 
of the field and then the length of the whole thing together for 
the record (char, int). For subrecords it was the same, except 
additional int and other string fields, all fixed length, no 
weird dynamic allocation required.


 Unless the arrays are stored/saved after the rest of the data, I 
don't see how you could bulk load the other fields so easily.

Re: sqlite3 vs. sqlite-d

[Stefan Koch via Digitalmars-d]

On Wednesday, 7 June 2017 at 19:10:26 UTC, Ozan wrote:

On Wednesday, 7 June 2017 at 17:51:30 UTC, Stefan Koch wrote:

Hi guys

I made a small video.
Mature and heavily optimized C library vs. young D upstart.

See for yourself how it turns out.

https://www.youtube.com/watch?v=mOeVftcVsvI

Cheers,
Stefan


Great. I like it (not the color of the terminal font - green!!! 
;-)
What is the cause for different benchmark results (from 30us up 
to 48us)?


With your small number lines, do you implement the complete 
sqlite functionality?


Regards, Ozan


It's the Matrix-Movie green ;)

I only implement reading the file format.
And a few convenience functions for finding a table, iterating by 
rows, and extracting columns.


The cause for the different results it like the scheduling of the 
OS.

Since we do issue quite a large read before iterating.
most of our time-slice has been used.
which makes it possible for us to get swapped out during 
processing.

Re: sqlite3 vs. sqlite-d

[Ozan via Digitalmars-d]

On Wednesday, 7 June 2017 at 17:51:30 UTC, Stefan Koch wrote:

Hi guys

I made a small video.
Mature and heavily optimized C library vs. young D upstart.

See for yourself how it turns out.

https://www.youtube.com/watch?v=mOeVftcVsvI

Cheers,
Stefan


Great. I like it (not the color of the terminal font - green!!! 
;-)
What is the cause for different benchmark results (from 30us up 
to 48us)?


With your small number lines, do you implement the complete 
sqlite functionality?


Regards, Ozan

Re: Mutiple AliasSeq as input to template

[David Sanders via Digitalmars-d-learn]

On Thursday, 25 May 2017 at 17:56:12 UTC, jmh530 wrote:

On Thursday, 25 May 2017 at 16:36:45 UTC, jmh530 wrote:

[snip]


I haven't played around with it fully, but it seems like the 
following resolves my issue in a sort of manual way:


template Process1(A, B)
{
static if (!isIndex!B)
alias Process1 = A;
else
alias Process1 = B;
}

template Process(size_t n, A...)
if (n > 0)
{
import std.meta : AliasSeq;

alias B = A[0..n];
alias C = A[n..$];

static if (n == 1)
{
alias Process = AliasSeq!(Process1!(B[0], C[0]));
}
else static if (n > 1)
{
alias Process = AliasSeq!(Process1!(B[0], C[0]),
  Process!(n - 
1, B[1..$], C[1..$]));
}
}


You can use nested templates to process multiple AliasSeqs like 
so:


enum isIndex(I) = is(I : size_t);

template Process(A...)
{
template With(B...)
{
import std.meta : AliasSeq;

static if (A.length == 0 || B.length == 0)
alias With = AliasSeq!();
else
{
static if(!isIndex!(B[0]))
alias Process1 = A[0];
else
alias Process1 = B[0];
alias With = AliasSeq!(Process1, 
Process!(A[1..$]).With!(B[1..$]));

}
}
}

void main()
{
import std.meta : AliasSeq;

alias T = AliasSeq!(int[], int[]);
alias U = AliasSeq!(int, string);
static assert(is(Process!(T).With!(U) == AliasSeq!(int, 
int[])));

}

Re: [Solved] Confusing error message

[drug via Digitalmars-d-learn]

07.06.2017 21:07, bachmeier пишет:

On Wednesday, 7 June 2017 at 14:58:26 UTC, drug wrote:


For me it's a good message.


Messages like this were an annoyance when I started out. If you don't 
import std.stdio, you get the error message


Error: 'writeln' is not defined, perhaps you need to import std.stdio; ?

That's a very helpful error message if you're new to D, and especially 
helpful if you're new to programming. This particular error is likely a 
common one, and adding "perhaps you need to import std.conv" would help 
a lot. Even a generic "perhaps you forgot an import statement" would 
tell new users what the error might be. Making it worse is that it says 
core.time.to but there was no import of core.time.


How do compiler know that you want use `std.conv.to` instead of _already 
imported_ `core.time.to`? In general it's impossible. There is no way 
for compiler to guess that you want some other symbol from out there. 
What if you've imported `std.conv.to` but want to use `core.time.to` - 
what should compiler do in this case?

What about `writeln` - it's too different.

Re: rawRead using a struct with variable leght

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

On Wed, Jun 07, 2017 at 06:24:22PM +, ade90036 via Digitalmars-d-learn 
wrote:
> On Monday, 5 June 2017 at 16:30:53 UTC, Era Scarecrow wrote:
> > On Monday, 5 June 2017 at 16:04:28 UTC, ade90036 wrote:
> > 
> > > Unfortunately the struct doesn't know at compile time what the
> > > size of the constant_pool array, or at-least was not able to
> > > specify it dynamically.
> > 
> >  It also won't know ahead of time how many fields, methods or
> >  attributes you have either.
> > 
> >  First I'd say all the arrays will have to be redefined to use [],
> >  rather than a fixed size.
> > 
> >  Glancing at the chapter information, you're probably not going to
> >  have an easy time, and will have to simply have to fill in the
> >  fields individually in order followed by allocating the arrays and
> >  probably filling/loading those immediately (although it's possible
> >  the array contents are done at the end, though it seems doubtful).
> 
> Thanks for the reply.
> 
> I guess i didnt pick such an easy task afterall.
> 
> I shall parse each fields individually.
[...]

"Structs" with variable size fields have no direct equivalent in D's
type system, so you'll probably have a hard time mapping this directly.

What you *could* do, though, is to load the data into a ubyte[] buffer,
then create a proxy struct containing arrays where you have
variable-sized fields, with the arrays slicing the ubyte[] buffer
appropriately.  Unfortunately, yes, this means you have to parse the
fields individually in order to construct these slices.


T

-- 
This is a tpyo.

Re: rawRead using a struct with variable leght

[ade90036 via Digitalmars-d-learn]

On Monday, 5 June 2017 at 16:30:53 UTC, Era Scarecrow wrote:

On Monday, 5 June 2017 at 16:04:28 UTC, ade90036 wrote:

Unfortunately the struct doesn't know at compile time what the 
size of the constant_pool array, or at-least was not able to 
specify it dynamically.


 It also won't know ahead of time how many fields, methods or 
attributes you have either.


 First I'd say all the arrays will have to be redefined to use 
[], rather than a fixed size.


 Glancing at the chapter information, you're probably not going 
to have an easy time, and will have to simply have to fill in 
the fields individually in order followed by allocating the 
arrays and probably filling/loading those immediately (although 
it's possible the array contents are done at the end, though it 
seems doubtful).


Thanks for the reply.

I guess i didnt pick such an easy task afterall.

I shall parse each fields individually.

Thanks again..

Re: [Solved] Confusing error message

[bachmeier via Digitalmars-d-learn]

On Wednesday, 7 June 2017 at 14:58:26 UTC, drug wrote:

07.06.2017 16:27, Wulfklaue пишет:

Some of the dmd error messages need some tweaking.


import std.datetime;

auto t = Clock.currStdTime;
writeln(to!string(t));


Result in:

Error: template core.time.to cannot deduce function from 
argument types !(string)(long), candidates are:

C:\D\dmd2\windows\bin\..\..\src\druntime\import\core\time.d(1709):core.time.to(string units, T, D)(D td) if (is(_Unqual!D == 
TickDuration) && (units == "seconds" || units == "msecs" || units == "usecs" || units == 
"hnsecs" || units == "nsecs"))


[...]


For me it's a good message.


Messages like this were an annoyance when I started out. If you 
don't import std.stdio, you get the error message


Error: 'writeln' is not defined, perhaps you need to import 
std.stdio; ?


That's a very helpful error message if you're new to D, and 
especially helpful if you're new to programming. This particular 
error is likely a common one, and adding "perhaps you need to 
import std.conv" would help a lot. Even a generic "perhaps you 
forgot an import statement" would tell new users what the error 
might be. Making it worse is that it says core.time.to but there 
was no import of core.time.

Re: The reason for SIGSEGV function pointer problem

[Mike Wey via Digitalmars-d-learn]

On 06/07/2017 06:50 PM, Russel Winder via Digitalmars-d-learn wrote:

So why isn't  a thing of type check_frontend_t*


AFAIK, you would usually translate:


typedef int (check_frontend_t*)(void *args, struct dvb_v5_fe_parms *parms);

into:

alias check_frontend_t = extern(C) int function (void* args, 
dvb_v5_fe_parms* parms);


The problem there is that libdvdv5 defines it as (check_frontend_t) and 
not (check_frontend_t*).
To get around that you can ommit the * in the declaration of 
dvb_scan_transponder, and then you should be able to pass  
to it.


--
Mike Wey

sqlite3 vs. sqlite-d

[Stefan Koch via Digitalmars-d]

Hi guys

I made a small video.
Mature and heavily optimized C library vs. young D upstart.

See for yourself how it turns out.

https://www.youtube.com/watch?v=mOeVftcVsvI

Cheers,
Stefan

Re: The reason for SIGSEGV function pointer problem

[ag0aep6g via Digitalmars-d-learn]

On 06/07/2017 06:50 PM, Russel Winder via Digitalmars-d-learn wrote:

So why isn't  a thing of type check_frontend_t*?


It's a thing of type `check_frontend_t`, which is a function pointer 
already. When you add an asterisk, you get a pointer to a function pointer.

Re: import statement placement

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

On Wed, Jun 07, 2017 at 01:17:39PM +, Nicholas Wilson via 
Digitalmars-d-learn wrote:
> On Wednesday, 7 June 2017 at 12:39:07 UTC, Russel Winder wrote:
> > Are there any idiom rules as to where to put import statements in D?
> > 
> > In Python they can go anywhere but PEP-8 suggests they should all go
> > at the top of a file, just after the module documentation string.
> 
> Well for ones that aren't scoped (i.e. used pervasively throughout the
> module) I always put them after the module declaration (if not the
> file containing main) and doc comment.
> 
> For scoped imports they go either on the line after the opening brace
> of the enclosing scope, or the line before the (selectively) imported
> symbol is used (if there is a reasonable amount of code preceding the
> opening brace).
[...]

I follow the same convention.

Though lately, I've been finding myself moving away more and more from
global imports, and moving imports into the scope in which they're
actually used.  While that sometimes necessitates more typing, I find
that it also improves code readability and movability: having scoped
imports in the block in which the symbol is used means reducing the
likelihood of overload conflicts with unfortunately-named symbols (there
are a few of these in Phobos). And I can easily move that code into a
different source file and have it Just Work, instead of having to
twiddle with the import statements at the top of the file (and
inadvertently leave useless imports in the original file where they are
no longer needed).

Nowadays I generally only use module-level import for things that are
truly used pervasively, like std.range.primitives, and std.stdio in the
module where main() is defined.  I try to avoid importing std.stdio
anywhere else, unless that module is directly concerned with I/O, and
force myself to structure the code such that such a dependency is not
needed in the first place -- e.g., write generic range-based algorithms
instead of code sprinkled with calls writeln.  I found that this has
helped improve my code quality significantly, and my code has become
much more reusable.


T

-- 
The best compiler is between your ears. -- Michael Abrash

[Issue 17476] Static fields don't seem to be reliably initialized when using parallel()

[via Digitalmars-d-bugs]

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

--- Comment #8 from Vladimir Panteleev  ---
(In reply to Mathias Lang from comment #7)
> How can
> "foobar" be printed twice if it's only set for one thread ?

Because both times "foobar" is written are done from the same (main) thread.
parallel() can (and does) reuse threads.

--

[Issue 17476] Static fields don't seem to be reliably initialized when using parallel()

[via Digitalmars-d-bugs]

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

--- Comment #7 from Mathias Lang  ---
When a thread runs I would expect the following (simplified) course of action:
- Initialize the TLS data
- Do the writeln
- Exit

Given the original code, I would then expect the code to print 3 times
"/some/string/initializer" and one time "foobar". I would not expect any order.

Which means the first 2 runs give a perfectly valid output. However, the 3rd
run outputs "/some/string/initializer" twice, and "foobar" twice. How can
"foobar" be printed twice if it's only set for one thread ? If the delegate
generated from the `foreach` body would capture the static instance of the main
thread, we would get 4 "foobar". but we don't.

--

Re: The reason for SIGSEGV function pointer problem

[Paolo Invernizzi via Digitalmars-d-learn]

On Wednesday, 7 June 2017 at 16:50:26 UTC, Russel Winder wrote:

In the constructor of an object to abstract the result of a 
call to the C library code, the parameter is:


check_frontend_t* cf



You should remove the pointer here...

/Paolo

Re: Ali's slides from his C++Now talk

[Ali Çehreli via Digitalmars-d]

On 06/07/2017 08:58 AM, Steven Schveighoffer wrote:

>> The video is up: https://www.youtube.com/watch?v=vYEKEIpM2zo
>
> Ali, what was the fiber question you couldn't answer?
>
> -Steve

I wouldn't remember the question even when watching it myself, except 
for one word that I luckily repeated: "symmetric". So, the question was 
whether D's fibers were symmetric, a concept totally alien to me... :) 
I've now learned that yes, D's fibers are symmetrical:



https://stackoverflow.com/questions/41891989/what-is-the-difference-between-asymmetric-and-symmetric-coroutines

Ali

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

[Meta via Digitalmars-d-announce]

On Friday, 2 June 2017 at 14:17:10 UTC, Mike Parker wrote:
Congratulations are in order for Jared Hanson. Walter and 
Andrei have approved his proposal to remove body as a keyword. 
I've added a summary of their decision to the end of the DIP 
for anyone who cares to read it. In short:


* body temporarily becomes a contextual keyword and is 
deprecated

* do is immediately allowed in its place
* body is removed and do replaces it fully

Congratulations, Jared!

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md


Well, guess I'm a bit late to the party but I just wanted to echo 
the sentiment that Mike has done a great job stepping up to 
oversee the DIP process. All I had to do was write it, and he did 
the rest. I'm very pleased with how smoothly things went and how 
easy Mike made the whole process. Thanks Mike!

The reason for SIGSEGV function pointer problem

[Russel Winder via Digitalmars-d-learn]

OK, so I have narrowed down my SIGSEGV problem to having no real idea
how to do C function pointers in D code.

So I have a callback function that will be called from C library code.
It currently has signature:

extern(C) int checkFrontend(void* _arguments, dvb_v5_fe_parms* 
frontendParameters)
 
because of the extern(C) I believe you have to use a type alias in
order to specify the type in function definitions. Hence:

alias check_frontend_t = extern(C) int function (void* args, 
dvb_v5_fe_parms* parms);

In the constructor of an object to abstract the result of a call to the
C library code, the parameter is:

check_frontend_t* cf

in the creation of the object using the constructor, I am using the
argument:



However. This gives me a type error:

extern (C) int function(void*, dvb_v5_fe_parms*)* cf

is not callable using argument type:

extern (C) int function(void*, dvb_v5_fe_parms*)

all the other arguments/parameters types match exactly, this is the
only difference.

So why isn't  a thing of type check_frontend_t*?

-- 
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

[Issue 17476] Static fields don't seem to be reliably initialized when using parallel()

[via Digitalmars-d-bugs]

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

--- Comment #6 from Andrej Mitrovic  ---
> In main, you set the TLS instance of path corresponding to the main thread to 
> "foobar". The "parallel" loop body will use the current thread's TLS 
> instance, but because the order of execution of threads is of course 
> undefined, you get inconsistent results.

I was initially confused not by the order of things, but by the multiple
printouts of "foobar". However this explains everything:

-
import std.concurrency;
import std.stdio;
import std.parallelism;

struct Params
{
static string path = "/some/string/initializer";
}

void main()
{
Params.path = "foobar";

foreach (_; parallel([1, 2, 3, 4]))
{
writefln("%s %s", thisTid(), Params.path);
}
}
-

Tid(7fe4c452e800) foobar
Tid(7fe4c452e800) foobar
Tid(7fe4c452e900) /some/string/initializer
Tid(7fe4c452ea00) /some/string/initializer

It's a non-issue, we were just puzzled at first. :)

--

[Issue 17476] Static fields don't seem to be reliably initialized when using parallel()

[via Digitalmars-d-bugs]

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

--- Comment #5 from Vladimir Panteleev  ---
(In reply to Mathias Lang from comment #4)
> So you can implicitly capture TLS variables and use them from other thread ?
> Doesn't that completely defeat the purpose of thread locality ?

I don't understand your question.

If you want to always refer to the main thread's TLS instance of "path" inside
the parallel foreach body, you can explicitly save a copy or a pointer to it
outside the foreach body on main's stack, then refer to it inside the foreach
body.

--

[Issue 17469] View source code

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dlang.org/commit/d02045747db953d021649f222e07c71c0705dbb0
Fix Issue 17469 - View source code for object.d is broken

--

[Issue 17476] Static fields don't seem to be reliably initialized when using parallel()

[via Digitalmars-d-bugs]

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

Mathias Lang  changed:

   What|Removed |Added

 CC||mathias.l...@sociomantic.co
   ||m

--- Comment #4 from Mathias Lang  ---
> In main, you set the TLS instance of path corresponding to the main thread to 
> "foobar". The "parallel" loop body will use the current thread's TLS 
> instance, but because the order of execution of threads is of course 
> undefined, you get inconsistent results.

So you can implicitly capture TLS variables and use them from other thread ?
Doesn't that completely defeat the purpose of thread locality ?

--

Re: Concept proposal: Safely catching error

[Olivier FAURE via Digitalmars-d]

On Monday, 5 June 2017 at 14:05:27 UTC, Steven Schveighoffer 
wrote:


I don't think this will work. Only throwing Error makes a 
function nothrow. A nothrow function may not properly clean up 
the stack while unwinding. Not because the stack unwinding code 
skips over it, but because the compiler knows nothing can 
throw, and so doesn't include the cleanup code.


If the function is @pure, then the only things it can set up will 
be stored on local or GC data, and it won't matter if they're not 
properly cleaned up, since they won't be accessible anymore.


I'm not 100% sure about that, though. Can a pure function do 
impure things in its scope(exit) / destructor code?


Not to mention that only doing this for pure code eliminates 
usages that sparked the original discussion, as my code 
communicates with a database, and that wouldn't be allowed in 
pure code.


It would work for sending to a database; but you would need to 
use the functional programming idiom of "do 99% of the work in 
pure functions, then send the data to the remaining 1% for impure 
tasks".


A process's structure would be:
- Read the inputs from the socket (impure, no catching errors)
- Parse them and transform them into database requests (pure)
- Send the requests to the database (impure)
- Parse / analyse / whatever the results (pure)
- Send the results to the socket (impure)

And okay, yeah, that list isn't realistic. Using functional 
programming idioms in real life programs can be a pain in the 
ass, and lead to convoluted callback-based scaffolding and weird 
data structures that you need to pass around a bunch of functions 
that don't really need them.


The point is, you could isolate the pure data-manipulating parts 
of the program from the impure IO parts; and encapsulate the 
former in Error-catching blocks (which is convenient, since those 
parts are likely to be more convoluted and harder to foolproof 
than the IO parts, therefore likely to throw more Errors).


Then if an Error occurs, you can close the connection the client 
(maybe send them an error packet beforehand), close the database 
file descriptor, log an error message, etc.

[Issue 17476] Static fields don't seem to be reliably initialized when using parallel()

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||thecybersha...@gmail.com
 Resolution|--- |INVALID

--- Comment #3 from Vladimir Panteleev  ---
No bug here.

path in a TLS variable, so there is one instance per thread.

In main, you set the TLS instance of path corresponding to the main thread to
"foobar". The "parallel" loop body will use the current thread's TLS instance,
but because the order of execution of threads is of course undefined, you get
inconsistent results.

I'm not sure what you expect - that the order of thread execution is
deterministic? This is of course impossible. Or do you want one instance of
"path" per the entire program, shared across threads? Then move it out of the
TLS into the stack or data segment (but watch out for data races).

--

Re: DIP 1007--"future symbol"--Formal Review

[Olivier FAURE via Digitalmars-d]

On Wednesday, 7 June 2017 at 14:42:24 UTC, Mike Parker wrote:


I'll be revising it a bit in the near future based on the 
lessons I've learned so far to clarify the process, but I want 
to keep this thread focused on feedback. Thanks!


https://github.com/dlang/DIPs/blob/master/README.md


Sorry, my question was poorly formulated. What I meant was it 
would be nice if you gave us either a short explanation of what 
these processes are, or a link to one (which you just did, thank 
you!), and more importantly, it would be nice to do this 
systematically with each of these announcements :)

[Issue 17475] [REG2.075] linker error on specific code

[via Digitalmars-d-bugs]

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

--- Comment #3 from Vladimir Panteleev  ---
(In reply to b2.temp from comment #2)
> Are you sure ?

Yes:

~/work/Digger/work/repo » git checkout 13da2d4e97bf15c7049138012bde243a221be117
; git submodule update ; git submodule status
Mdlang.org
HEAD is now at 13da2d4e97... phobos: Merge pull request #5444 from
klickverbot/quad-lrint
Submodule path 'dlang.org': checked out
'9f1f0155b03141dd842cd9664e1fc638c1a1aa9c'
 9f1f0155b03141dd842cd9664e1fc638c1a1aa9c dlang.org (v2.074.1-82-g9f1f0155)
 5f2f2811a3d756777bcf098983b94db543f1dfcf dmd (v2.074.1-347-g5f2f2811a)
 2b14f6cd6b3ed338bbb54b0a3fe30427cf050d0b druntime (v2.074.1-60-g2b14f6cd)
 19843d82476837ede8f2079fa8e5b405d481235a installer (v2.074.1-7-g19843d8)
 f036ef12eafda45b9bcb31c4d06975adb6313e6a phobos (v2.074.1-326-gf036ef12e)
 ed24fb441744a6c168d394970186456ae1484f5c tools (v2.073.2-26-ged24fb4)

~/work/Digger/work/repo » digger build 13da2d4e97bf15c7049138012bde243a221be117
...

~/tmp/2017-06-07-scratch/15:52:31 » ( d-digger ; dmd --version ; dmd -run
test.d )
DMD64 D Compiler v2.075.0-devel-5f2f2811a-dirty
Copyright (c) 1999-2017 by Digital Mars written by Walter Bright
digitalMars

> The script i use to build worked well since months.

I can't vouch for your script. If it's broken, it's your problem.

--

Re: Concept proposal: Safely catching error

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 7 June 2017 at 15:35:56 UTC, Olivier FAURE wrote:

On Monday, 5 June 2017 at 12:59:11 UTC, Moritz Maxeiner wrote:

Anyway, I don't think this would happen. Most forms of memory 
allocations are impure,


Not how pure is currently defined in D, see the referred spec; 
allocating memory is considered pure (even if it is impure with 
the theoretical pure definition).

This is something that would need to be changed in the spec.



I consider there to be value in allowing users to say "this is 
not a contract, it is a valid use case" (-> wrapper), but a 
broken contract being recoverable violates the entire concept 
of DbC.


There *should* be a way to say "okay, the contract is broken, 
let's get rid of all data associated with it, log an error 
message to explain what went wrong, then kill *the specific 
thread/process/task* and let the others keep going".


The goal isn't to ignore or bypass Errors, it's to 
compartmentalize the damage.


The problem is that in current operating systems the finest 
scope/context of computation you can (safely) kill / 
compartmentalize the damage in in order to allow the rest of the 
system to proceed is a process (-> process isolation).
Anything finer than that (threads, fibers, etc.) may or may not 
work in a particular use case, but you can't guarantee/proof that 
it works in the majority of use cases (which is what the runtime 
would have to be able to do if we were to allow that behaviour as 
the default).
Compartmentalizing like this is your job as the programmer imho, 
not the job of the runtime.

[Issue 17475] [REG2.075] linker error on specific code

[via Digitalmars-d-bugs]

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

--- Comment #2 from b2.t...@gmx.com ---
(In reply to Vladimir Panteleev from comment #1)
> You have a mismatching libphobos again.
> 
> In the future, please test with a D build tool that removes the possibility
> of user errors, such as Digger.

Are you sure ? See here:

https://forum.dlang.org/thread/dbmroothueyaexzqk...@forum.dlang.org

The script i use to build worked well since months.

--

Re: Ali's slides from his C++Now talk

[Steven Schveighoffer via Digitalmars-d]

On Wednesday, 7 June 2017 at 07:53:25 UTC, Bastiaan Veelo wrote:

On Wednesday, 24 May 2017 at 02:42:47 UTC, Jack Stouffer wrote:

On Wednesday, 24 May 2017 at 00:05:54 UTC, Ali Çehreli wrote:

...


Any videos up?


The video is up: https://www.youtube.com/watch?v=vYEKEIpM2zo


Ali, what was the fiber question you couldn't answer?

-Steve

[Issue 17475] [REG2.075] linker error on specific code

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||thecybersha...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #1 from Vladimir Panteleev  ---
You have a mismatching libphobos again.

In the future, please test with a D build tool that removes the possibility of
user errors, such as Digger.

--

Re: Concept proposal: Safely catching error

[Olivier FAURE via Digitalmars-d]

On Monday, 5 June 2017 at 13:13:01 UTC, ketmar wrote:
this still nullifies the sense of Error/Exception differences. 
not all errors are recoverable, even in @safe code.


...

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


I don't think this is a workaround, or that it goes against the 
purpose of Errors.


The goal would still be to bomb out, cancel whatever you were 
doing, print a big red error message to the coder / user, and 
exit.


A program that catches an Error would not try to use the data 
that broke a contract; in fact, the program would not have access 
to the invalid data, since it would be thrown away. It's natural 
progression would be to log the error, and quit whatever it was 
doing.


The point is, if the program needs to free system resources 
before shutting down, it could do so; or if the program is a 
server or a multi-threaded app dealing with multiple clients at 
the same time, those clients would not be affected by a crash 
unrelated to their data.

Re: Concept proposal: Safely catching error

[Olivier FAURE via Digitalmars-d]

On Monday, 5 June 2017 at 12:59:11 UTC, Moritz Maxeiner wrote:

On Monday, 5 June 2017 at 12:01:35 UTC, Olivier FAURE wrote:
Another problem is that non-gc memory allocated in the try 
block would be irreversibly leaked when an Error is thrown 
(though now that I think about it, that would probably count 
as impure and be impossible anyway).


D considers allocating memory as pure[1].

...

Sure, but with regards to long running processes that are 
supposed to handle tens of thousands of requests, leaking 
memory (and continuing to run) will likely eventually end up 
brutally shutting down the process on out of memory errors. But 
yes, that is something that would have to be evaluated on a 
case by case basis.


Note that in the case you describe, the alternative is either 
"Brutally shutdown right now", or "Throwaway some data, 
potentially some memory as well, and maybe brutally shut down 
later if that happens too often". (although in the second case, 
there is also the trade-off that the leaking program "steals" 
memory from the other routines running on the same computer)


Anyway, I don't think this would happen. Most forms of memory 
allocations are impure, and wouldn't be allowed in a try {} 
catch(Error) block; C's malloc() is pure, but C's free() isn't, 
so the thrown Error wouldn't be skipping over any calls to 
free(). Memory allocated by the GC would be reclaimed once the 
Error is caught and the data thrown away.


Arrays aside, I think there's some use in being able to safely 
recover from (or safely shut down after) the kind of broken 
contracts that throw Errors.


I consider there to be value in allowing users to say "this is 
not a contract, it is a valid use case" (-> wrapper), but a 
broken contract being recoverable violates the entire concept 
of DbC.


I half-agree. There *should not* be way to say "Okay, the 
contract is broken, but let's keep going anyway".


There *should* be a way to say "okay, the contract is broken, 
let's get rid of all data associated with it, log an error 
message to explain what went wrong, then kill *the specific 
thread/process/task* and let the others keep going".


The goal isn't to ignore or bypass Errors, it's to 
compartmentalize the damage.

Re: Concept proposal: Safely catching error

[Olivier FAURE via Digitalmars-d]

On Monday, 5 June 2017 at 12:51:16 UTC, ag0aep6g wrote:

On 06/05/2017 11:50 AM, Olivier FAURE wrote:
In other words, @safe functions would be allowed to catch 
Error after try blocks if the block only mutates data declared 
inside of it; the code would look like:


 import vibe.d;

 // ...

 string handleRequestOrError(in HTTPServerRequest req) 
@safe {

 ServerData myData = createData();

 try {
...
 }
 catch (Error) {
 throw new SomeException("Oh no, a system error 
occured");

 }
 }

 ...



But `myData` is still alive when `catch (Error)` is reached, 
isn't it?


Good catch; yes, this example would refuse to compile; myData 
needs to be declared in the try block.


How does `@trusted` fit into this? The premise is that there's 
a bug somewhere. You can't assume that the bug is in a 
`@system` function. It can just as well be in a `@trusted` one. 
And then `@safe` and `pure` mean nothing.


The point of this proposal is that catching Errors should be 
considered @safe under certain conditions; code that catch Errors 
properly would be considered as safe as any other code, which is, 
"as safe as the @trusted code it calls".


I think the issue of @trusted is tangential to this. If you (or 
the writer of a library you use) are using @trusted to cast away 
pureness and then have side effects, you're already risking data 
corruption and undefined behavior, catching Errors or no catching 
Errors.

fluent-asserts 0.5.0 released

[Szabo Bogdan via Digitalmars-d-announce]

Hi,

I just released a new version of fluent-asserts: 
https://github.com/gedaiu/fluent-asserts


Since the previous announce, I improved the error messages and I 
added a new function `.because()` that allows you to add custom 
messages.


If you are interested in writing better asserts in your unit 
tests you should check this out.


Thanks,
Bogdan

Re: Why does phobos have collisions?

[drug via Digitalmars-d]

07.06.2017 17:57, Ivan Kazmenko пишет:

On Wednesday, 7 June 2017 at 10:01:30 UTC, Mike B Johnson wrote:
Error: template std.algorithm.mutation.strip cannot deduce function 
from argument types !()(string), candidates are:
src\phobos\std\algorithm\mutation.d(2280): 
std.algorithm.mutation.strip(Range, E)(Range range, E element) if 
(isBidirectionalRange!Range && is(typeof(range.front == element) : bool))
\src\phobos\std\algorithm\mutation.d(2287): 
std.algorithm.mutation.strip(alias pred, Range)(Range range) if 
(isBidirectionalRange!Range && is(typeof(pred(range.back)) : bool))


This is on a line of code that simply strips away a string...

and works fine when using standard strip(without importing 
std.algorithm)... but when importing std.algorithm too, those errors 
pop up... seems like a defect.


Actually, it looks like the std.algorithm[.mutation] is imported but 
std.string isn't.
As std.algorithm's strip is more generic, it cannot assume what's the 
"whitespace" to be stripped, so it's not callable without explicitly 
specifying what to strip.


I've experienced this too, and it's really a bit confusing the first 
time it happens.


Ivan Kazmenko.


Selective imports are good in this case.

Re: Why does phobos have collisions?

[Ivan Kazmenko via Digitalmars-d]

On Wednesday, 7 June 2017 at 10:01:30 UTC, Mike B Johnson wrote:
Error: template std.algorithm.mutation.strip cannot deduce 
function from argument types !()(string), candidates are:
src\phobos\std\algorithm\mutation.d(2280):
std.algorithm.mutation.strip(Range, E)(Range range, E element) 
if (isBidirectionalRange!Range && is(typeof(range.front == 
element) : bool))
\src\phobos\std\algorithm\mutation.d(2287):
std.algorithm.mutation.strip(alias pred, Range)(Range range) if 
(isBidirectionalRange!Range && is(typeof(pred(range.back)) : 
bool))


This is on a line of code that simply strips away a string...

and works fine when using standard strip(without importing 
std.algorithm)... but when importing std.algorithm too, those 
errors pop up... seems like a defect.


Actually, it looks like the std.algorithm[.mutation] is imported 
but std.string isn't.
As std.algorithm's strip is more generic, it cannot assume what's 
the "whitespace" to be stripped, so it's not callable without 
explicitly specifying what to strip.


I've experienced this too, and it's really a bit confusing the 
first time it happens.


Ivan Kazmenko.

Re: vibe.d on Web Framework Benchmarks

[Ozan via Digitalmars-d]

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



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

Ali


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


So where are the results coming from?

Regards, Ozan

Re: [Solved] Confusing error message

[drug via Digitalmars-d-learn]

07.06.2017 16:27, Wulfklaue пишет:

Some of the dmd error messages need some tweaking.


import std.datetime;

auto t = Clock.currStdTime;
writeln(to!string(t));


Result in:

Error: template core.time.to cannot deduce function from argument 
types !(string)(long), candidates are:
C:\D\dmd2\windows\bin\..\..\src\druntime\import\core\time.d(1709):
core.time.to(string units, T, D)(D td) if (is(_Unqual!D == 
TickDuration) && (units == "seconds" || units == "msecs" || units == 
"usecs" || units == "hnsecs" || units == "nsecs"))




import std.datetime;
import std.conv;

auto t = Clock.currStdTime;
writeln(to!string(t));


Solves the issue but its strange that there is no error message 
indicating that to! needs the std.conv included. Technically one can 
argue that the original message mean that but its very, very unclear.
Error is right indicating that _available_ function `core.time.to` can 
not deduce from given types. It's impossible for compiler to know that 
you want use `std.conv.to` symbol.
In other words compiler says that it knows only one function `to` and 
this function are in `core.time.` module. And this function can not be 
called with given args. I prefer to use selective imports and in this 
case compiler would say it doesn't know function `to`.


For me it's a good message.

Re: Why does phobos have collisions?

[Dukc via Digitalmars-d]

On Wednesday, 7 June 2017 at 10:01:30 UTC, Mike B Johnson wrote:
template std.algorithm.mutation.strip cannot deduce function 
from argument types !()(string)


Judging by that you correctly passed a string to strip, but did 
not specify what to strip from it. You can either specify an 
example of characters you want to strip off, or an alias 
predicate which judges whether an element should go.

Re: DIP 1007--"future symbol"--Formal Review

[Andrei Alexandrescu via Digitalmars-d]

On 06/07/2017 10:42 AM, Mike Parker wrote:

On Wednesday, 7 June 2017 at 13:47:41 UTC, Olivier FAURE wrote:


This has probably been said somewhere before, but could you give a 
short explanation of what the formal review is, and how it's supposed 
to be different from the preliminary review? Thank you in advance.


The basic idea is in the README. I'll be revising it a bit in the near 
future based on the lessons I've learned so far to clarify the process, 
but I want to keep this thread focused on feedback. Thanks!


https://github.com/dlang/DIPs/blob/master/README.md


Ah never mind :o). -- Andrei

Re: DIP 1007--"future symbol"--Formal Review

[Andrei Alexandrescu via Digitalmars-d]

On 06/07/2017 09:47 AM, Olivier FAURE wrote:

On Wednesday, 7 June 2017 at 10:36:05 UTC, Mike Parker wrote:
The first stage of the formal review for DIP 1007 [1], "'future 
symbol' Compiler Concept", is now underway. From now until 11:59 PM ET 
on June 21 (3:59 AM GMT on June 22), the community has the opportunity 
to provide last-minute feedback. If you missed the preliminary review 
[2], this is your chance to provide input.


This has probably been said somewhere before, but could you give a short 
explanation of what the formal review is, and how it's supposed to be 
different from the preliminary review? Thank you in advance.


@Mike that would make a good wiki page. -- Andrei

Re: DIP 1007--"future symbol"--Formal Review

[Mike Parker via Digitalmars-d]

On Wednesday, 7 June 2017 at 13:47:41 UTC, Olivier FAURE wrote:


This has probably been said somewhere before, but could you 
give a short explanation of what the formal review is, and how 
it's supposed to be different from the preliminary review? 
Thank you in advance.


The basic idea is in the README. I'll be revising it a bit in the 
near future based on the lessons I've learned so far to clarify 
the process, but I want to keep this thread focused on feedback. 
Thanks!


https://github.com/dlang/DIPs/blob/master/README.md

Re: Why does phobos have collisions?

[Dukc via Digitalmars-d]

On Wednesday, 7 June 2017 at 10:01:30 UTC, Mike B Johnson wrote:
and works fine when using standard strip(without importing 
std.algorithm)... but when importing std.algorithm too, those 
errors pop up... seems like a defect.


What do you mean with "standard strip"? In my vocabulary, 
functions in std.algorithm ARE the standard ones.


It is not a name clash. If it were, the compiler would announce 
"ambiquous name lookup" or something like that. The error you 
have tells that none of the names fit, not that many of them did. 
Yes, the name matched, but the static types of arguments (either 
compile-time or runtime) you passed did not.


I think you should copy here what you wote, so we can get a 
better picture where the problem is.

Re: [Solved] Confusing error message

[bachmeier via Digitalmars-d-learn]

On Wednesday, 7 June 2017 at 13:27:05 UTC, Wulfklaue wrote:

Some of the dmd error messages need some tweaking.


import std.datetime;

auto t = Clock.currStdTime;
writeln(to!string(t));


Result in:

Error: template core.time.to cannot deduce function from 
argument types !(string)(long), candidates are:

C:\D\dmd2\windows\bin\..\..\src\druntime\import\core\time.d(1709):core.time.to(string units, T, D)(D td) if (is(_Unqual!D == 
TickDuration) && (units == "seconds" || units == "msecs" || units == "usecs" || units == 
"hnsecs" || units == "nsecs"))




import std.datetime;
import std.conv;

auto t = Clock.currStdTime;
writeln(to!string(t));


Solves the issue but its strange that there is no error message 
indicating that to! needs the std.conv included. Technically 
one can argue that the original message mean that but its very, 
very unclear.


Best to report it and make a suggestion of what it should say. 
Nothing will happen if you post here.


https://issues.dlang.org/

Re: DMD is now part of the doc pages on dlang.org

[Seb via Digitalmars-d]

On Wednesday, 7 June 2017 at 11:30:47 UTC, Wulfklaue wrote:
Slightly offtopic but why are there two documentation 
libraries. I found the dlang.org/library version way more 
readable. Did not even realized this existed.


Mass dumped documentation in a single document is so year 2000 
:)


Ddoc (/phobos, aka the builtin -D flag in the compiler) was first 
and the process of replacing it with DDox 
(https://github.com/rejectedsoftware/ddox) is taking quite some 
time, because the output isn't identical and there are still some 
"design" issues with Ddox, see e.g. this PR for an overview:


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

The transition started about three years ago and I think it just 
doesn't bother anyone enough to work on it:


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



Second question:

I wanted to add a simple example to:

https://dlang.org/library/std/datetime/date.to_string.html


But the link "Improve this page" results in a dead page.

https://github.com/dlang/phobos/edit/master/std/datetime.d#L13022

The datatime file is not located in that position.

https://github.com/dlang/phobos/blob/master/std/datetime/date.d

This is the correct location.


The "View the source" code link uses a link to the latest stable 
release (i.e. the one that is deployed on dlang.org, currently 
2.074.1):


https://github.com/dlang/phobos/blob/v2.074.1/std/datetime.d#L13022

The "Improve this page" links to `master`, because you want to 
improve the file at the `master` branch, which admittedly can be 
a bit tricky.
When you want to modify `master` branch, the `-prerelease` pages 
are your friend, e.g.


https://dlang.org/library-prerelease/std/datetime/date/date.to_string.html

[Issue 16566] hasLength should enforce that length has type size_t

[via Digitalmars-d-bugs]

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

--- Comment #5 from Andrei Alexandrescu  ---
(In reply to Vladimir Panteleev from comment #4)
> What about e.g. ranges representing files over 4GB on 32-bit architectures?

Those are not supported.

--

[Issue 16566] hasLength should enforce that length has type size_t

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #4 from Vladimir Panteleev  ---
What about e.g. ranges representing files over 4GB on 32-bit architectures?

--

Re: DIP 1007--"future symbol"--Formal Review

[Olivier FAURE via Digitalmars-d]

On Wednesday, 7 June 2017 at 10:36:05 UTC, Mike Parker wrote:
The first stage of the formal review for DIP 1007 [1], "'future 
symbol' Compiler Concept", is now underway. From now until 
11:59 PM ET on June 21 (3:59 AM GMT on June 22), the community 
has the opportunity to provide last-minute feedback. If you 
missed the preliminary review [2], this is your chance to 
provide input.


This has probably been said somewhere before, but could you give 
a short explanation of what the formal review is, and how it's 
supposed to be different from the preliminary review? Thank you 
in advance.


Otherwise, the whole DIP seems pretty well thought-out to me. I 
particularly like the idea of a core-only @__future attribute, 
that can be replaced with a globally available @future attribute 
eventually.