Jacoby Ellsbury and Chase Headley: in opposition to legal responsibility in the direction of trustworthiness?
Keep in mind the phone calls for Chase Headley process again inside of May possibly and June, and the gloom that hung around 3rd foundation Though Gleyber Torres was loft for the yr, leaving the Yankees tuckwith the having difficulties Headley?Recall at the time Jacoby Ellsbury was the greatest high priced fourth outfielder in just the majors, and his deficiency of offensive output led in direction of him wasting his setting up task, and his standing currently being stated within some of the worst absolutely free representative signings inside workers historical past?All right, potentially Ellsbury and his nuts agreement is nevertheless a fairly legitimate criticism, however these types of 2 veterans incorporate long gone in opposition to useless body weight in the direction of the shed one-way links within a Yankee lineup as the employees appears toward capture hearth and chase down the section name.The Yankees are continue to alive inside the divisional race due in the direction of a enormous weekend wherever they took a few out of 4 video games towards Boston. Headley, getting rediscovered his stroke for the reason that the advent of Todd Frazier, recorded several hits inside a few of the 4 game titles, all of them contributing in the direction of a earn for the Yanks. Headley was batting with a slugging proportion of .364 basically prior to the All-Star crack. He consists of simply because elevated individuals totals toward and due towards a Terrific minute 50 percent inside which he is batting with 7 homers, 2 of them coming within that critical sequence very last weekend.Ellsbury, who batted inside July, contains occur alive a short while ago and is hitting inside of his final 9 game titles, together with a 3-strike night time within just the sequence finale in opposition to Boston upon Sunday night time. With a heavier workload because of toward a different indirect harm in the direction of Aaron Hicks, Ellsbury incorporates stored his simplest game titles for the moment he is made up of been necessary the utmost https://www.redsoxfanteamshop.com/Rafael_Devers_Apparel-52 , substantially such as Headley.Conversing of Headley, his advancement versus the immediately aspect of the plate incorporates been outstanding, which we observed versus Chris Sale upon Sunday. His the moment microscopic batting regular towards the instantly facet is made up of been increased in direction of a far more authentic . Should really Joe Girardi elect toward chill out Greg Chook towards a lefty, he can presently sense a lot further guaranteed placing Headley inside at initial if he can proceed swinging the route he consists of been. Considering that he as well been a superior hitter than Todd Frazier given that the exchange, his electricity toward engage in 3rd foundation provides in direction of his overall flexibility and present-day worthy of.Both of those Headley and Ellsbury include obtained significant complaint for considerably of the period, and rightfully as a result. Headley seemed misplaced at the plate for 2 weeks though Ellsbury was effectively a multi-million greenback bench bat Nomar Garciaparra Jersey, considering that he was serving no favourable motive inside the each day lineup. For the year currently being, that narrative consists of significantly modified. With the starting up rotation accomplishing Really perfectly just lately, some additional offense will Deliver the Yanks a substantial improve down the extend David Ortiz Jersey, particularly if they can proceed in direction of take aid versus such 2 veterans who were being pronounced useless previous inside of the period. Even more Versus Pinstripe Alley More than the Empire: Yankees information - 4/17/18 Let be accurate relating to Sonny Grey The Yankees don have to have Jacoby Ellsbury any more Yankees 12, Marlins 1: Aaron Choose, Didi Gregorius glow within just rout of Miami Among arranging woes, Yankees followers shouldn pine for the retractable roof Dissecting Giancarlo Stanton commence Greatest Examine Searching back again at the Yankeesexchange for Gleyber Torres Let appearance again toward the moment the Yankees learned Gleyber Torres at present that there chatter in excess of a speak to up https://www.redsoxfanteamshop.com/Robbie_Ross_Jr_Apparel-45 . NYY information: Sir Walks-a-Great deal Gregorius provides toward his skillset; Kahnle in direction of the DL, Cessa recalled-ish; Grey in direction of check out staying additional competitive; Boone may perhaps shed Stanton inside lineup; Cashman discusses Gleyber Torres The Yankees don need to have Jacoby Ellsbury any more Ellsbury is just turning out to be even more harm at this issue, therefore the Yankees are much better off with no him.
Re: Are Fibers just broken in D?
On 4/23/18 8:46 PM, Byron Heads wrote:
Fibers on Win32 have a memory leak for sure:
import core.thread : Fiber;
void main() {
foreach(ulong i; 0..99_999) {
auto foo = new Foo();
foo.call();
foo.call();
}
}
It sure looks like this should be fine, the GC should clean up all the
unused fibers.
Running this with -m64 on windows runs without a problem, but with -m32
it failes aith a Memory Allocation failed error.
How many loops until you get a failure?
Is there a particular reason you need to use 32-bit Windows?
-Steve
Re: How array concatenation works... internally
On Monday, 23 April 2018 at 23:27:17 UTC, Steven Schveighoffer wrote: ... If you want to know more about the array runtime, I suggest this article: https://dlang.org/articles/d-array-article.html ... Thanks for replying and this article is what I was looking for.
Re: Are Fibers just broken in D?
On Friday, 20 April 2018 at 20:52:17 UTC, Byron Moxie wrote:
On Friday, 20 April 2018 at 20:46:20 UTC, Steven Schveighoffer
wrote:
On 4/20/18 2:58 PM, Byron Moxie wrote:
[...]
It sounds like the problems may be due to Win32 and not the
other pieces. Have you tried on a Win64 build? Even if that's
not your target, at least it can help you discover whether
that is the problem or not. The DMC runtime is the default on
Win32, and it's not especially thread-safe in all places.
FWIW, I'm using vibe.d on Linux 64 bit with no problems (and
I've NEVER heard of atomicLoad and atomicStore not working on
any arch).
-Steve
I had move the data I wanted to sync with atomicLoad/Store into
a shared struct and pass a pointer to this struct to the other
fibers. Not sure if this was an issue with TLS messing with
class object I was passing around.
Fibers on Win32 have a memory leak for sure:
import core.thread : Fiber;
void main() {
foreach(ulong i; 0..99_999) {
auto foo = new Foo();
foo.call();
foo.call();
}
}
class Foo : Fiber {
this() {
super();
}
void run() {
Fiber.yield();
}
}
Running this with -m64 on windows runs without a problem, but
with -m32 it failes aith a Memory Allocation failed error.
Re: How array concatenation works... internally
On 4/23/18 7:15 PM, Dnewbie wrote:
Hi,
I'd like to understand how array concatenation works internally, like
the example below:
//DMD64 D Compiler 2.072.2
import std.stdio;
void main(){
string[] arr;
arr.length = 2;
arr[0] = "Hello";
arr[1] = "World";
writeln(arr.length);
arr = arr[0..1] ~ "New String" ~ arr[1..2];
writeln(arr.length);
foreach(string a; arr){
writeln(a);
}
}
http://rextester.com/DDW84343
The code above prints:
2
3
Hello
New String
World
So, It changes the "arr" length and put the "New String" between the
other two. It's very fast with some other tests that I made.
What it has done is built a completely new array, with the new 3
elements. The old array is still there. You can witness this by keeping
a reference to the old array:
auto arr2 = arr;
arr = arr[0 .. 1] ~ "New String" ~ arr[1 .. 2];
writeln(arr2);
writeln(arr);
Now I'm curious to know what's happening under the hood. It's related to
memcpy?
There's not much copying going on here, each string is stored in the arr
as a pointer and length pair. So you are just making a copy of those.
On Phobos "array.d" source I've found this:
/// Concatenation with rebinding.
void opCatAssign(R)(R another)
{
auto newThis = this ~ another;
move(newThis, this);
}
This is different. The builtin arrays are not part of phobos, they are
defined by the compiler. std.array.Array is a different type.
If you want to know more about the array runtime, I suggest this
article: https://dlang.org/articles/d-array-article.html
But now I'm having problem to find how I can reach this "move" function,
since I couldn't find any "move" on the "std" folder.
Move is std.algorithm.move:
https://dlang.org/phobos/std_algorithm_mutation.html#.move
-Steve
Re: How array concatenation works... internally
On Monday, 23 April 2018 at 23:15:13 UTC, Dnewbie wrote: It's related to memcpy? By the way... It's related to realloc and memcpy?
How array concatenation works... internally
Hi,
I'd like to understand how array concatenation works internally,
like the example below:
//DMD64 D Compiler 2.072.2
import std.stdio;
void main(){
string[] arr;
arr.length = 2;
arr[0] = "Hello";
arr[1] = "World";
writeln(arr.length);
arr = arr[0..1] ~ "New String" ~ arr[1..2];
writeln(arr.length);
foreach(string a; arr){
writeln(a);
}
}
http://rextester.com/DDW84343
The code above prints:
2
3
Hello
New String
World
So, It changes the "arr" length and put the "New String" between
the other two. It's very fast with some other tests that I made.
Now I'm curious to know what's happening under the hood. It's
related to memcpy?
On Phobos "array.d" source I've found this:
/// Concatenation with rebinding.
void opCatAssign(R)(R another)
{
auto newThis = this ~ another;
move(newThis, this);
}
But now I'm having problem to find how I can reach this "move"
function, since I couldn't find any "move" on the "std" folder.
Thanks in advance.
Re: Getting the overload set of a template
On Monday, 23 April 2018 at 17:46:10 UTC, Arafel wrote:
You could also argue that function overloads are just
semantically equivalent to a single function with variadic
arguments.
It is not. As there are exact known, distinct, finite numbers and
types of arguments of functions, which can be used. For example,
zero and one.
So:
void foo(){}
void foo(int){}
How this is achievable with variadic functions?
Whether the compiler actually lowers it like that or not should
be just an implementation detail, and thus simply not relevant.
Right.
And from a syntactical point of view, it wouldn't make any
sense if the following "overloads" were treated differently:
```
class A {
@("int", "odd")
template Foo1(int N) if (N & 1){
enum Foo1 = "A";
}
@("int", "even")
template Foo1(int N) if (!(N & 1)){
enum Foo1 = "B";
}
@("string", "+")
template Foo1(string op) if (op == "+") {
enum Foo1 = "C";
}
@("multi", "string")
template Foo1(T...) if (allSatisfy!(isSomeString, typeof(T))
&& T.length > 1) {
enum Foo1 = "D";
}
@("multi", "double")
template Foo1(T...) if (allSatisfy!(isFloatingPoint,
typeof(T)) && T.length > 1) {
enum Foo1 = "E";
}
}
```
So, in my opinion, a callable object is overloaded, when there
exist more then one interface how to call it.
Before a template is instantiated, no callable objects exist.
Now, you can go on say well, a template defines a family of
objects, which build up an overload set. This is not doable, see
the discussion before.
But of course, you can go the other way and say well, if there
exist a declaration then, based on the declaration inspection,
let us define an overload set, based on the same symbol names.
This is a different way of defining an overload, which is not
obvious, especially if you see the pragma output from a former
post. Therein the pragmas, which act also before runtime do not
differ between declarations, but only between instantiations.
Re: Doxygen newbie
Oh goodness. I thought D was using Doxygen! Thanks.
Re: Getting the overload set of a template
On Monday, 23 April 2018 at 16:52:11 UTC, Alex wrote:
On Monday, 23 April 2018 at 16:16:09 UTC, Arafel wrote:
```
import std.meta;
void main()
{
pragma(msg, __traits(getMember, A, "Foo1").stringof); //
Foo1(int N) if (N & 1)
pragma(msg, __traits(getAttributes, __traits(getMember, A,
"Foo1"))[0]); // tuple("int", "odd")
alias f1a = Instantiate!(__traits(getMember, A, "Foo1"),
1); // This is expected
pragma(msg, f1a); // A
alias f1b = Instantiate!(__traits(getMember, A, "Foo1"),
"+"); // Why would I know that I can even instantiate?? Also,
can I haz UDA plz?
pragma(msg, f1b); // B
}
class A {
@("int", "odd")
template Foo1(int N) if (N & 1){
enum Foo1 = "A";
}
@("string", "+")
template Foo1(string op) if (op == "+") {
enum Foo1 = "B";
}
}
```
I'm not arguing about the case of different interfaces. It is
more or less ok, as from different argument types it will be
unambiguous which template will be instantiated. It is the case
of differentiating templates by their structure and/or
constraints.
In this case, it is almost sure, that more then one form of
implementation exists. However, the forms will yield the same
semantic result. And I'm wondering why the implementation form
alone leads to differentiation.
Well, with templates the overload resolution must be always
unambiguous:
```
import std.stdio;
void main()
{
pragma(msg, A.Foo1!2);
pragma(msg, A.Foo1!3);
static assert(!is (typeof(A.Foo1!6))); // Compilation failure if
there is any ambiguity
}
class A {
template Foo1(int N) if ((N % 2) == 0){
enum Foo1 = "A";
}
template Foo1(int N) if ((N % 3) == 0) {
enum Foo1 = "B";
}
}
```
Also, you can try without a constraint, it will still complain.
But you are arguing from the point of view of a hypothetical
semantical equivalence that I don't think it's so clear. Both are
tools that in some cases can lead to the same result, but there
are also cases where they don't math.
You could also argue that function overloads are just
semantically equivalent to a single function with variadic
arguments. Whether the compiler actually lowers it like that or
not should be just an implementation detail, and thus simply not
relevant.
And from a syntactical point of view, it wouldn't make any sense
if the following "overloads" were treated differently:
```
class A {
@("int", "odd")
template Foo1(int N) if (N & 1){
enum Foo1 = "A";
}
@("int", "even")
template Foo1(int N) if (!(N & 1)){
enum Foo1 = "B";
}
@("string", "+")
template Foo1(string op) if (op == "+") {
enum Foo1 = "C";
}
@("multi", "string")
template Foo1(T...) if (allSatisfy!(isSomeString, typeof(T)) &&
T.length > 1) {
enum Foo1 = "D";
}
@("multi", "double")
template Foo1(T...) if (allSatisfy!(isFloatingPoint, typeof(T))
&& T.length > 1) {
enum Foo1 = "E";
}
}
```
How would you know which ones are "real" overloads (in your
meaning)?
A.
Re: Getting the overload set of a template
On Monday, 23 April 2018 at 16:16:09 UTC, Arafel wrote:
```
import std.meta;
void main()
{
pragma(msg, __traits(getMember, A, "Foo1").stringof); //
Foo1(int N) if (N & 1)
pragma(msg, __traits(getAttributes, __traits(getMember, A,
"Foo1"))[0]); // tuple("int", "odd")
alias f1a = Instantiate!(__traits(getMember, A, "Foo1"),
1); // This is expected
pragma(msg, f1a); // A
alias f1b = Instantiate!(__traits(getMember, A, "Foo1"),
"+"); // Why would I know that I can even instantiate?? Also,
can I haz UDA plz?
pragma(msg, f1b); // B
}
class A {
@("int", "odd")
template Foo1(int N) if (N & 1){
enum Foo1 = "A";
}
@("string", "+")
template Foo1(string op) if (op == "+") {
enum Foo1 = "B";
}
}
```
I'm not arguing about the case of different interfaces. It is
more or less ok, as from different argument types it will be
unambiguous which template will be instantiated. It is the case
of differentiating templates by their structure and/or
constraints.
In this case, it is almost sure, that more then one form of
implementation exists. However, the forms will yield the same
semantic result. And I'm wondering why the implementation form
alone leads to differentiation.
Re: Getting the overload set of a template
On Monday, 23 April 2018 at 15:44:10 UTC, Simen Kjærås wrote: Ah, but I'm not looking to instantiate the templates, but to learn about them - how many parameters do they take? Are their UDAs different, so that I should warn the programmer? Must I wrap them in different ways? So... Do I have to correct my semantic equality assumptions? There should be a large chapter in the docu about this. It would change at the same time with your feature and the things which are implied and which are not would be evident to the world...
Re: Getting the overload set of a template
I think both versions are not equivalent at all. Consider [1]:
```
import std.meta;
void main()
{
pragma(msg, __traits(getMember, A, "Foo1").stringof); // Foo1(int
N) if (N & 1)
pragma(msg, __traits(getAttributes, __traits(getMember, A,
"Foo1"))[0]); // tuple("int", "odd")
alias f1a = Instantiate!(__traits(getMember, A, "Foo1"), 1); //
This is expected
pragma(msg, f1a); // A
alias f1b = Instantiate!(__traits(getMember, A, "Foo1"), "+"); //
Why would I know that I can even instantiate?? Also, can I haz UDA plz?
pragma(msg, f1b); // B
}
class A {
@("int", "odd")
template Foo1(int N) if (N & 1){
enum Foo1 = "A";
}
@("string", "+")
template Foo1(string op) if (op == "+") {
enum Foo1 = "B";
}
}
```
In this case you could perhaps use an alias parameter to achieve a
similar effect. I haven't tried it but it would be really messy, if it
even works.
What seems clear to me from this case is that *internally* the compiler
sees a *set* of "overloads" (change that word if you think it should
only apply to functions), but I can only get the first of the batch!
For example, I might want to add some information in the UDA on how to
instantiate the template, but then I can't get the UDA either. I'm sure
it's somewhere, just that we get no access to it, and that shouldn't be
too hard to add.
I think this clarifies a bit the problem I see.
A.
[1]: https://run.dlang.io/is/zRDHGn
On 04/23/2018 05:00 PM, Alex wrote:
On Monday, 23 April 2018 at 14:22:13 UTC, Simen Kjærås wrote:
As with all things D, the only real spec is the compiler source code.
:p :(
:p
Proving that two templates are equivalent is in general impossible,
since any amount of wasted computation could be performed before the
end result is returned, and inputs must be tested exhaustively for the
proof to be valid. The fact that two templates give the same result in
one special case does not mean that they are equivalent in the general
case, and the compiler needs to care about the general case.
Ok, thats exactly the point. If you have functions
void foo() {}
void foo(int n) {}
There is no ambiguity which function will be chosen if it will be called.
If you have templates
// form 1
template Foo(int N) if (N & 1) {} // A
template Foo(int N) if (!(N & 1)) {} // B
OR
// form 2
template foo(int N)
{
static if(N & 1){} // A
else{} // B
}
There is also no ambiguity which will be called.
However, getOverloads will behave differently.
This is not bad at all. But you have to admit, that while now, there is
no way to distinguish form 1 and form 2, with the new getOverloads there
will be.
This seems strange to me, because there is no reason to distinguish form
1 and form 2. (Because the callable code, which will be generated is the
same, I hope... ?)
So, in particular, I'm not against the feature. And if the equivalence
between form 1 and form 2 is gone, so what. But I don't understand the
reasoning why something which is now equal won't be equal any more later?
Re: Getting the overload set of a template
On Monday, 23 April 2018 at 15:00:38 UTC, Alex wrote:
Ok, thats exactly the point. If you have functions
void foo() {}
void foo(int n) {}
There is no ambiguity which function will be chosen if it will
be called.
If you have templates
// form 1
template Foo(int N) if (N & 1){} // A
template Foo(int N) if (!(N & 1)) {} // B
OR
// form 2
template foo(int N)
{
static if(N & 1){} // A
else{} // B
}
There is also no ambiguity which will be called.
However, getOverloads will behave differently.
Now I understand what you are getting at. Thanks a bunch for
being so patient with me. :)
And you are right, of course. But I'm just as interested in the
templates themselves as the instantiated results.
This is not bad at all. But you have to admit, that while now,
there is no way to distinguish form 1 and form 2, with the new
getOverloads there will be.
This seems strange to me, because there is no reason to
distinguish form 1 and form 2. (Because the callable code,
which will be generated is the same, I hope... ?)
So, in particular, I'm not against the feature. And if the
equivalence between form 1 and form 2 is gone, so what. But I
don't understand the reasoning why something which is now equal
won't be equal any more later?
Ah, but I'm not looking to instantiate the templates, but to
learn about them - how many parameters do they take? Are their
UDAs different, so that I should warn the programmer? Must I wrap
them in different ways?
I hope we now both understand what the other person means and
want to achieve. :)
--
Simen
Re: Static Array with negative index results in a strange error-message
On 4/23/18 11:09 AM, Dgame wrote: It's really fun playing around: char[int.max - 1] c; results in Internal error: dmd/backend/cgcod.c 634 with DMD 2.079. Guess I or somebody else should report this. Yes, this is an ICE (Internal compiler error). Those should ALWAYS be reported. -Steve
Re: Static Array with negative index results in a strange error-message
It's really fun playing around: char[int.max - 1] c; results in Internal error: dmd/backend/cgcod.c 634 with DMD 2.079. Guess I or somebody else should report this.
Re: Getting the overload set of a template
On Monday, 23 April 2018 at 14:22:13 UTC, Simen Kjærås wrote:
As with all things D, the only real spec is the compiler source
code. :p :(
:p
Proving that two templates are equivalent is in general
impossible, since any amount of wasted computation could be
performed before the end result is returned, and inputs must be
tested exhaustively for the proof to be valid. The fact that
two templates give the same result in one special case does not
mean that they are equivalent in the general case, and the
compiler needs to care about the general case.
Ok, thats exactly the point. If you have functions
void foo() {}
void foo(int n) {}
There is no ambiguity which function will be chosen if it will be
called.
If you have templates
// form 1
template Foo(int N) if (N & 1){} // A
template Foo(int N) if (!(N & 1)) {} // B
OR
// form 2
template foo(int N)
{
static if(N & 1){} // A
else{} // B
}
There is also no ambiguity which will be called.
However, getOverloads will behave differently.
This is not bad at all. But you have to admit, that while now,
there is no way to distinguish form 1 and form 2, with the new
getOverloads there will be.
This seems strange to me, because there is no reason to
distinguish form 1 and form 2. (Because the callable code, which
will be generated is the same, I hope... ?)
So, in particular, I'm not against the feature. And if the
equivalence between form 1 and form 2 is gone, so what. But I
don't understand the reasoning why something which is now equal
won't be equal any more later?
Re: Static Array with negative index results in a strange error-message
On Monday, 23 April 2018 at 13:48:07 UTC, Steven Schveighoffer wrote: On 4/23/18 9:32 AM, Dgame wrote: char[-1] c; results in Error: char[18446744073709551615LU] size 1 * 18446744073709551615 exceeds 0x7fff size limit for static array Should we fix that? A negative index should be IMO detected sooner/with a cleaner error message. Hm.. at least it's detected. I actually don't think the message is wrong: -1 is a valid size_t literal, and results in that number. if you did: enum size_t x = -1; char[x] c; You would get the same result, and I don't know how we would fix that. -Steve C's error message is error: 'c' declared as an array with a negative size char c[-1]; That is more understandable.
Re: Getting the overload set of a template
On Monday, 23 April 2018 at 13:32:49 UTC, Alex wrote:
On Monday, 23 April 2018 at 10:57:59 UTC, Simen Kjærås wrote:
There is no official definition. That's because some natural
rewrite rules are implied, which are very general, I assume...
How official do you want it to be? That's the only definition
in common use by others in the context of compilers.
Stating the existence of rewriting rules is a complex thing.
They is no place in the docu (which I could find until now)
where they are defined. Therefore, I rely on something which is
common.
https://en.wikipedia.org/wiki/Natural_transformation
We can discuss, whether a template is a functor, but I think
this would go beyond the scope of this thread.
You mentioned a limited set of lowerings, defined by the
language. Where can I find them? I'm very interested in that.
As with all things D, the only real spec is the compiler source
code. :p :(
Again, lowerings are a compiler technique where one syntax is
rewritten into a different syntax. They are hard-coded into the
language (and optionally in the compiler - if a compiler writer
finds an opportunity to use lowerings to simplify or otherwise
improve the compiler without such a lowering being defined in the
language, and with the same behavior, all the more power to
him/her). Only these things are called lowerings. Template
instantiations are not lowerings. Function inlining is not a
lowering. Constant folding is not a lowering.
As far as I know, there is no canonical list of lowerings
anywhere. :(
There is no template rewriting taking place in the language
today - that seems to be a feature you are arguing for.
Semantic rewriting is not something which one can take control
of. Either you have semantically equal constructs or not.
And we don't, so don't worry about it. :p
getOverloads should return the overloads of a template as they
are defined in the language today.
This is the topic of discussion. I argue, that getOverloads can
(so far) act only on functions, because only there the term
overload is well defined. I see, that it could be defined on
templates too, but not in the way you do.
But why not? Consider this case:
template foo() {}
template foo(int n) {}
In the compiler, this results in two `TemplateDeclaration`s being
instantiated. Since they share the 'foo' name, they are
considered an overload set by the compiler. The specific overload
is chosen by overload resolution. They are iterated by the
function overloadApply. The term template overload is also widely
used in C++, from which D has inherited much.
Simply put, template overloads are clearly defined, everyone
knows what they are, and many of us want a way to iterate over
them, choose a specific overload in a different template, and
just plain do sensible work with them.
If not how I define it, then how would the term 'overload' be
defined for templates? We've established that creating a new
overload for every potential static if breaks down in the
presence of mixins, and is questionable in their absence. What
I'm reading from your post is simply 'the current way is wrong,
and there exists a better way'. If that's true, I'd love to hear
what the better way is, but I fail to see that you've described
it.
Template overloads are mentioned in the D spec[0], and are
clearly a real thing that it's useful to be able to manipulate.
Yes. But using the term "overload" for templates with the same
name does not justify to wrongly apply existing features to
more abstract objects. This is what you try to do by using
getOverloads with templates.
It's a term with decades of history in C++, and has been used in
D since its inception. Even C# mentions overloads for generic
functions or types with different constraints.
You seem to be arguing against a feature on the basis that if
the language were significantly different from what it is, the
feature would be confusing. The language isn't that way, so
the feature isn't confusing in that way.
Well, as we both saw with the pragma output, the language is
exactly that way I'm describing it.
Then, once more, I must have misunderstood your description.
Proving that two templates are equivalent is in general
impossible, since any amount of wasted computation could be
performed before the end result is returned, and inputs must be
tested exhaustively for the proof to be valid. The fact that two
templates give the same result in one special case does not mean
that they are equivalent in the general case, and the compiler
needs to care about the general case.
New getOverload functionality would introduce a new constraint
in comparison to the current state.
The new functionality does not in any way stop you from using
getOverloads in exactly the way it's been used before. In
addition to that, you may pass an additional argument to it to
get template overloads (actually, every symbol by that name in
the
Re: static array of pointers to dynamic arrays of ints problem...
On 4/22/18 2:00 AM, WhatMeForget wrote:
Surely a stupid mistake on my part, but why is the first array repeated?
In addition to what Neia said, you shouldn't use pointers to dynamic
arrays. Such things are really hard to allocate on the heap, since new
int[] just makes an array, not a pointer to an array. You're way more
likely to accidentally store pointers to stack variables (as demonstrated).
The only way 2 ways I know of to do it are to a) allocate a
multi-dimensional array, and take it's pointer (e.g. (new int[][1]).ptr)
or b) create a dummy struct with an array in it, and new that:
Struct Dummy { int[] array; }
auto p = new Dummy;
auto ptr =
Just use int[][2] a, you will be better off.
-Steve
Re: Static Array with negative index results in a strange error-message
On 4/23/18 9:32 AM, Dgame wrote: char[-1] c; results in Error: char[18446744073709551615LU] size 1 * 18446744073709551615 exceeds 0x7fff size limit for static array Should we fix that? A negative index should be IMO detected sooner/with a cleaner error message. Hm.. at least it's detected. I actually don't think the message is wrong: -1 is a valid size_t literal, and results in that number. if you did: enum size_t x = -1; char[x] c; You would get the same result, and I don't know how we would fix that. -Steve
Static Array with negative index results in a strange error-message
char[-1] c; results in Error: char[18446744073709551615LU] size 1 * 18446744073709551615 exceeds 0x7fff size limit for static array Should we fix that? A negative index should be IMO detected sooner/with a cleaner error message.
Re: Getting the overload set of a template
On Monday, 23 April 2018 at 10:57:59 UTC, Simen Kjærås wrote: There is no official definition. That's because some natural rewrite rules are implied, which are very general, I assume... How official do you want it to be? That's the only definition in common use by others in the context of compilers. Stating the existence of rewriting rules is a complex thing. They is no place in the docu (which I could find until now) where they are defined. Therefore, I rely on something which is common. https://en.wikipedia.org/wiki/Natural_transformation We can discuss, whether a template is a functor, but I think this would go beyond the scope of this thread. You mentioned a limited set of lowerings, defined by the language. Where can I find them? I'm very interested in that. There is no template rewriting taking place in the language today - that seems to be a feature you are arguing for. Semantic rewriting is not something which one can take control of. Either you have semantically equal constructs or not. getOverloads should return the overloads of a template as they are defined in the language today. This is the topic of discussion. I argue, that getOverloads can (so far) act only on functions, because only there the term overload is well defined. I see, that it could be defined on templates too, but not in the way you do. Template overloads are mentioned in the D spec[0], and are clearly a real thing that it's useful to be able to manipulate. Yes. But using the term "overload" for templates with the same name does not justify to wrongly apply existing features to more abstract objects. This is what you try to do by using getOverloads with templates. You seem to be arguing against a feature on the basis that if the language were significantly different from what it is, the feature would be confusing. The language isn't that way, so the feature isn't confusing in that way. Well, as we both saw with the pragma output, the language is exactly that way I'm describing it. New getOverload functionality would introduce a new constraint in comparison to the current state. Having getOverloads return template overloads solves a real issue right now, and would be useful even if your suggested change were implemented (though the behavior would be slightly different). What I'm saying is: it would be useful only then, if my suggested change were implemented. Otherwise, it is a new constraint and not a feature. [0]: https://dlang.org/concepts.html
Re: Getting the overload set of a template
On Monday, 23 April 2018 at 08:07:52 UTC, Alex wrote: On Monday, 23 April 2018 at 07:49:39 UTC, Simen Kjærås wrote: That's not the definition of lowering used elsewhere, and so will lead to confusion and misunderstanding. I would strongly suggest you rethink your definition of lowering. There is no official definition. That's because some natural rewrite rules are implied, which are very general, I assume... How official do you want it to be? That's the only definition in common use by others in the context of compilers. My point, is that if it is impossible to catch all cases of template rewriting (which I'm advocating from the beginning) getOverloads should not be extended to templates, as this would be a fundamental change in the language. There is no template rewriting taking place in the language today - that seems to be a feature you are arguing for. getOverloads should return the overloads of a template as they are defined in the language today. Template overloads are mentioned in the D spec[0], and are clearly a real thing that it's useful to be able to manipulate. You seem to be arguing against a feature on the basis that if the language were significantly different from what it is, the feature would be confusing. The language isn't that way, so the feature isn't confusing in that way. Having getOverloads return template overloads solves a real issue right now, and would be useful even if your suggested change were implemented (though the behavior would be slightly different). If your suggested feature is impossible to implement, are you suggesting we simply throw our hands in the air and give up, instead of implementing a useful feature? -- Simen [0]: https://dlang.org/concepts.html
Re: Doxygen newbie
On Monday, April 23, 2018 07:49:00 Chris Katko via Digitalmars-d-learn wrote: > I'm a complete doxygen newbie. But my first thought when writing > comments is... why not use Markdown? (Which has become almost > universal online these days.) > > So I google it and Moxygen comes up. Which seems pretty good. > > https://sourcey.com/generating-beautiful-markdown-documentation-with-moxyg > en/ > > So my question is, can you use Markdown with normal Doxygen? Is > Moxygen needed? And if so, would I run into any complications > using D instead of C/C++ with Doxygen and Moxygen? > > Would there be any strange demangling issues or anything like > that? Historically, doxygen would not have interacted well with markdown at all, but it looks like they added some markdown support with doxygen 1.8.0. This page discusses it: http://doxygen.nl/markdown.html If you want to use doxygen with D, it should work just fine, but it's a pretty atypical thing to do. D has its own built-in documentation generation system, ddoc: https://dlang.org/spec/ddoc.html However, there are some alternatives that some in the D community use - the most notable ones being ddox and adrdox. Several are listed on the dlang wiki: https://wiki.dlang.org/Documentation_Generators - Jonathan M Davis
Re: Getting the overload set of a template
On Monday, 23 April 2018 at 07:49:39 UTC, Simen Kjærås wrote:
On Monday, 23 April 2018 at 04:58:38 UTC, Alex wrote:
On Monday, 23 April 2018 at 00:26:23 UTC, Simen Kjærås wrote:
There is a limited set of lowerings, and they are defined in
the language, not in user code. They include operator
overloading (where `a op b` is translated to
`a.opBinary!op(b)`), foreach over ranges (where `foreach(e;
range) { }` becomes `for (auto e = range.front;
!range.empty(); range.popFront()) { }`), string switching
(which is forwarded to a template in druntime), and more that
I can't recall right now. This is compiler magic meant to
make implementating new features and reasoning about existing
features, easier. They are briefly described in the article
you linked, but I agree it offers limited insight. I've not
found any other great sources of information about it, sadly.
This is not true, in my opinion.
As an example, Walter gives the rewrite of a while-loop and a
foreach-loop into a for-loop, stating that by the ability to
do this, the for-loop is more basic than both of the former.
So, in my mind, every action of rewriting of something into
something else is "lowering". And if you can do this (of
course, maintaining the full semantic equivalence), available
actions have to remain the same.
That's not the definition of lowering used elsewhere, and so
will lead to confusion and misunderstanding. I would strongly
suggest you rethink your definition of lowering.
There is no official definition. That's because some natural
rewrite rules are implied, which are very general, I assume...
Said this, I'm not against the new getOverloads. On the
contrary, I find the feature cool. But if it is present, it
has to yield the same results for foo1 and foo2, just like the
pragmas.
In the general case, this is impossible. Even just limiting
ourselves to simple usages of static if it gets unwieldy. This
template is from Phobos (all unnecessary code removed). It has
224 different possible combinations of features:
private struct _Cache(R, bool bidir)
{
static if (bidir) {}
else {}
static if (isInfinite!R) {}
else {}
static if (hasLength!R) {}
version(assert) {}
static if (isForwardRange!R) {}
static if (hasSlicing!R) {
static if (hasEndSlicing) {}
static if (!isInfinite!R) {}
else static if (hasEndSlicing) {}
}
}
And that's before we even instantiate any templates that this
template references - any templates used inside _Cache could
increase the number of combinations.
But wait, there's more! How many does this have?
struct Bar(string s) {
mixin(s);
}
If that's just one overload because of the impossibility of
generating the options, what if we introduce a single static if
inside it? Is that still one, or is it two? Do we count the
possibilities introduced by a template mixin, but not by a
string mixin? What if the template mixin comes from a template
argument?
Sorry if I come off as very dismissive right now - I kind of
like the idea, but it seems impossible in practice.
I'm not sure about the procedure... should I post this as a
question to the GitHub, so it can be discussed? pull 2351 or
8195?
What you are suggesting would be a fundamental change in the
language, and should be discussed in the digitalmars.D forum.
Either PR is not the right place to discuss it. If there's any
interest, you will have to write a DIP for how the change will
work.
--
Simen
My point, is that if it is impossible to catch all cases of
template rewriting (which I'm advocating from the beginning)
getOverloads should not be extended to templates, as this would
be a fundamental change in the language.
Re: Getting the overload set of a template
On Monday, 23 April 2018 at 04:58:38 UTC, Alex wrote:
On Monday, 23 April 2018 at 00:26:23 UTC, Simen Kjærås wrote:
There is a limited set of lowerings, and they are defined in
the language, not in user code. They include operator
overloading (where `a op b` is translated to
`a.opBinary!op(b)`), foreach over ranges (where `foreach(e;
range) { }` becomes `for (auto e = range.front;
!range.empty(); range.popFront()) { }`), string switching
(which is forwarded to a template in druntime), and more that
I can't recall right now. This is compiler magic meant to make
implementating new features and reasoning about existing
features, easier. They are briefly described in the article
you linked, but I agree it offers limited insight. I've not
found any other great sources of information about it, sadly.
This is not true, in my opinion.
As an example, Walter gives the rewrite of a while-loop and a
foreach-loop into a for-loop, stating that by the ability to do
this, the for-loop is more basic than both of the former.
So, in my mind, every action of rewriting of something into
something else is "lowering". And if you can do this (of
course, maintaining the full semantic equivalence), available
actions have to remain the same.
That's not the definition of lowering used elsewhere, and so will
lead to confusion and misunderstanding. I would strongly suggest
you rethink your definition of lowering.
Said this, I'm not against the new getOverloads. On the
contrary, I find the feature cool. But if it is present, it has
to yield the same results for foo1 and foo2, just like the
pragmas.
In the general case, this is impossible. Even just limiting
ourselves to simple usages of static if it gets unwieldy. This
template is from Phobos (all unnecessary code removed). It has
224 different possible combinations of features:
private struct _Cache(R, bool bidir)
{
static if (bidir) {}
else {}
static if (isInfinite!R) {}
else {}
static if (hasLength!R) {}
version(assert) {}
static if (isForwardRange!R) {}
static if (hasSlicing!R) {
static if (hasEndSlicing) {}
static if (!isInfinite!R) {}
else static if (hasEndSlicing) {}
}
}
And that's before we even instantiate any templates that this
template references - any templates used inside _Cache could
increase the number of combinations.
But wait, there's more! How many does this have?
struct Bar(string s) {
mixin(s);
}
If that's just one overload because of the impossibility of
generating the options, what if we introduce a single static if
inside it? Is that still one, or is it two? Do we count the
possibilities introduced by a template mixin, but not by a string
mixin? What if the template mixin comes from a template argument?
Sorry if I come off as very dismissive right now - I kind of like
the idea, but it seems impossible in practice.
I'm not sure about the procedure... should I post this as a
question to the GitHub, so it can be discussed? pull 2351 or
8195?
What you are suggesting would be a fundamental change in the
language, and should be discussed in the digitalmars.D forum.
Either PR is not the right place to discuss it. If there's any
interest, you will have to write a DIP for how the change will
work.
--
Simen
Doxygen newbie
I'm a complete doxygen newbie. But my first thought when writing comments is... why not use Markdown? (Which has become almost universal online these days.) So I google it and Moxygen comes up. Which seems pretty good. https://sourcey.com/generating-beautiful-markdown-documentation-with-moxygen/ So my question is, can you use Markdown with normal Doxygen? Is Moxygen needed? And if so, would I run into any complications using D instead of C/C++ with Doxygen and Moxygen? Would there be any strange demangling issues or anything like that? Thanks
