Re: So... add maxCount and maxPos?
On Thursday, 21 January 2016 at 14:04:58 UTC, Andrei Alexandrescu wrote: On 01/21/2016 08:42 AM, Era Scarecrow wrote: I'd almost say lowestCount and highestCount would almost be better, but i am not sure. minCount is already a given. -- Andrei countMost!less and posMost!less
Re: Why do some attributes start with '@' while others done't?
On Friday, 22 January 2016 at 04:30:33 UTC, tsbockman wrote: On Friday, 22 January 2016 at 02:13:56 UTC, Ola Fosheim Grøstad wrote: [...] I don't necessarily disagree with your overall point, but I think the question of whether a few attributes have an @ attached to them or not ranks pretty low on the list of "70% solutions with marginal support" that need fixing/fleshing out. If this is truly among the most pressing issues with D, then D must be in great shape. It seems like poor allocation of resources (both those of the D development team, and those of the D users who would be forced to update their code) to put much effort into this right now, when there are so many other issues of greater practical import to work on. It's just another straw on the 'language being woefully underdefined/unimplemented' camel right next to shared, SafeD, no defined memory model, etc. What are we plebs supposed to do about such things besides wait around for Walter or Andrei to address it?
Re: Why do some attributes start with '@' while others done't?
On Friday, 22 January 2016 at 02:13:56 UTC, Ola Fosheim Grøstad wrote: On Thursday, 21 January 2016 at 23:48:14 UTC, tsbockman wrote: It wouldn't be too bad, as such things go. But it also serves little practical purpose; why break people's code for purely aesthetic reasons? 1. Because it isn't purely aesthetic, it is also a question of usability. 2. Because very little code has been written in D. 3. Because D stands no chance of widespread adoption without fixing the usability issues. 4. Because you can have two parsers in the same compiler, one for legacy source files and one for contemporary code. The only code that will break is code that relies on string mixins, which is a horrible idea anyway. But D should fix all the semantic issues first. Unfortunately there is no focus on this, only on adding new features. IMHO: D is a dying language until there is a focus on bringing both coherent semantics and syntax to the language. It is not like adding C++ linkage without bringing semantics closer to C++ will be a saviour. There is too much focus on having a wide range of 70% solutions with marginal support. I don't necessarily disagree with your overall point, but I think the question of whether a few attributes have an @ attached to them or not ranks pretty low on the list of "70% solutions with marginal support" that need fixing/fleshing out. If this is truly among the most pressing issues with D, then D must be in great shape. It seems like poor allocation of resources (both those of the D development team, and those of the D users who would be forced to update their code) to put much effort into this right now, when there are so many other issues of greater practical import to work on.
Re: Why do some attributes start with '@' while others done't?
On Friday, 22 January 2016 at 03:18:29 UTC, Timon Gehr wrote: On 01/22/2016 03:20 AM, Dicebot wrote: I'd definitely place something like `@safe` in type constructors @safe(int) ? Normally I rely on this definition: feature .. builds new types from old ones (https://en.m.wikipedia.org/wiki/Type_constructor) That matches my intuitive expectations. I.e. plain 'extern' is a storage class because for `const int x; extern int y;` type of y is still plain into but x is const(int) @safe functions do have distinct type thus I'd expect it to be type qualifier/constructor. However D seems to use different classification that isn't documented anywhere.
Should phobos functions generally be @safe or @trusted?
I wanted to use std.array.insertInPlace in a @safe module. It's not marked @safe or @trusted. The string implementation uses pointer arithmetic, and the non-string implementation uses memmove. Should things like this be marked @trusted in general? Presumably if a function isn't memory-safe, it doesn't just cause memory errors arbitrarily; there's likely something the caller has to do to ensure the function doesn't crash or cause memory corruption. It seems like that should be documented. When it's not documented, I start feeling a bit paranoid. Should it be a bug if a non-@safe, non-@trusted function doesn't document what you need to do to call it safely?
Re: Why do some attributes start with '@' while others done't?
On 01/22/2016 03:20 AM, Dicebot wrote: I'd definitely place something like `@safe` in type constructors @safe(int) ?
Re: extern(C++) multiple inheritence
On Wednesday, 20 January 2016 at 00:45:34 UTC, Walter Bright
wrote:
On 1/19/2016 1:59 PM, Daniel Murphy wrote:
On 19/01/2016 8:04 PM, Walter Bright wrote:
On 1/19/2016 12:34 AM, Daniel Murphy wrote:
Yeah, it never has. No attempt has ever been made to make
it work.
Actually, as I recall it was made to match what DMC++
generates for Win32.
Wasn't that from before we had extern(C++) classes? I did the
extern(C++)
single inheritance class layout but didn't touch interfaces.
We had COM, which was an earlier form of C++ class support.
BTW, in docs I saw the following example:
Calling D Virtual Functions From C++
```
Given D code like:
extern (C++) int callE(E);
extern (C++) interface E
{
int bar(int i, int j, int k);
}
class F : E
{
extern (C++) int bar(int i, int j, int k)
{
writefln("i = %s", i);
writefln("j = %s", j);
writefln("k = %s", k);
return 8;
}
}
void main()
{
F f = new F();
callE(f);
}
```
```
The C++ code to access it looks like:
class E
{
public:
virtual int bar(int i, int j, int k);
};
int callE(E *e)
{
return e->bar(11,12,13);
}
```
In this example C++ class E hasn't fields and another stuff. What
happens if I change E?
class E
{
std::string s;
public:
virtual int bar(int i, int j, int k);
int strageHash()
{
return s.length() + bar(0, 0, 0);
}
};
int callE(E *e)
{
return e->strageHash();
}
AFAIK, D can't generate correct F layout. D doesn't know
sizeof(E), D doesn't know E ctor (the second one is fixable).
As result, new F() object can be smaller that E and this code has
an unexpected behaviour.
Ok, we aren't gods and we can't suggest something better
(exclusive of moveing multiple inheritance and C++ layout to D :).
However we may and should alert user about this limitation and
about another limitations like this.
And when we add a new C++-related feature, we should declare
C++-side limitations, in the first place, because they can't be
enforced by D compiler.
And have someone any ideas about C++ to D interface generator?
Re: Why do some attributes start with '@' while others done't?
On Friday, 22 January 2016 at 02:12:27 UTC, Adam D. Ruppe wrote: Well, technically, since UDAs exist, every new @thing is potential breakage too, though of course, limited in scope. (If I was doing it, I'd actually make the ones be implicitly imported names, so you could disambiguate with teh module system like normal if that did happen, but meh.) Putting built-in @-attributes in a runtime module publicly imported from object.d is a very long proposal but last time it was discussed Walter wasn't convinced it is of much gain AFAIR. May get there eventually, I hope.
Re: Why do some attributes start with '@' while others done't?
On Friday, 22 January 2016 at 00:11:02 UTC, Brian Schott wrote: I wrote up the details of this idea as a DIP many months ago: http://wiki.dlang.org/DIP64 It's already implemented in dfix. You can run "dfix --dip64 file.d" and the changes will be made automatically. The problem with DIP64 isn't that it breaks the code but that it doesn't propose any meaningful system as a replacement. "Keywords that are only attributes (i.e. they are not also storage classes or type constructors)" doesn't sound as straightforward to me considering https://dlang.org/spec/declaration.html#StorageClass lists @-properties as storage classes and there isn't any other list in spec I could find. There isn't even any strict definition of "storage class" and "type qualifier / type constructor" in language spec that could explain existing classification. For example, I'd definitely place something like `@safe` in type constructors but it seems to be considered a storage class. That was the reason why I was insisting on reverting last attempt to change @ requirements in dmd - breaking the code can be ok, but not having a clear explanation of new design (and still breaking the code) is not ok at all.
Re: Website contains a virus?
On 1/21/2016 10:57 AM, Brad Anderson wrote: New results: https://www.virustotal.com/en/file/45e01e0eba641b02874d84fafceefac2b53a28add31ceeef2a4bfce13c1440d7/analysis/1453402410/ Now to decide if it's a false positive... (we use NSIS which I could easily see being an easily thing to have false positives with). Note that different tools find different "viruses" Comodo Heur.Packed.Unknown 20160121 DrWeb Trojan.Packed.196 20160121 McAfee-GW-Edition BehavesLike.Win32.Tool.tc 20160121 Rising PE:Malware.XPACK/RDM!5.1 [F] 20160121 Symantec Trojan.Gen.2 20160121 TrendMicro Possible_Virus 20160121 Meaning they don't know what they're doing. In the past some of these were driven by Optlink making an executable that is not quite like what MS tools make, so, hey, "Possible Virus". Blech.
Re: Why do some attributes start with '@' while others done't?
On Thursday, 21 January 2016 at 23:19:19 UTC, Brian Schott wrote: Every time a new keyword is added to the language some working code will become invalid. Well, technically, since UDAs exist, every new @thing is potential breakage too, though of course, limited in scope. (If I was doing it, I'd actually make the ones be implicitly imported names, so you could disambiguate with teh module system like normal if that did happen, but meh.)
Re: Why do some attributes start with '@' while others done't?
On Thursday, 21 January 2016 at 23:48:14 UTC, tsbockman wrote: It wouldn't be too bad, as such things go. But it also serves little practical purpose; why break people's code for purely aesthetic reasons? 1. Because it isn't purely aesthetic, it is also a question of usability. 2. Because very little code has been written in D. 3. Because D stands no chance of widespread adoption without fixing the usability issues. 4. Because you can have two parsers in the same compiler, one for legacy source files and one for contemporary code. The only code that will break is code that relies on string mixins, which is a horrible idea anyway. But D should fix all the semantic issues first. Unfortunately there is no focus on this, only on adding new features. IMHO: D is a dying language until there is a focus on bringing both coherent semantics and syntax to the language. It is not like adding C++ linkage without bringing semantics closer to C++ will be a saviour. There is too much focus on having a wide range of 70% solutions with marginal support.
Re: [dlang.org] Let's talk about the logo
On Thursday, 21 January 2016 at 23:46:26 UTC, anonymous wrote: ... bottom two are the best. mixing matte and glossy is just *ugly*
Re: Why do some attributes start with '@' while others done't?
On Thursday, 21 January 2016 at 23:05:51 UTC, Dibyendu Majumdar wrote: I am puzzled as to why there is @nogc on the one hand and simply nothrow on the other? Why are some attributes prefixed with '@' while others aren't? Regards "breakage" that could be fixed in a few minutes with grep meanwhile, I typically can't go a D version without actual breakage that takes hours to debug.
Re: JMH
On Thu, 21 Jan 2016 13:17:04 +0100, Jacob Carlborg wrote: > On 2016-01-20 22:05, Robert burner Schadek wrote: > >> The problem was that the user had to create a custom main that listed >> all modules to check for tests or use a build tool with some globbing >> commands. Both not perfect. > > What we need is this: > https://github.com/D-Programming-Language/dmd/pull/2271 https://issues.dlang.org/show_bug.cgi?id=10023 for more context. In short, this makes user-defined attributes discoverable at runtime at the module level, if the attribute has opted in. I think. I'm not sure how it would help here, though, so I kind of doubt my interpretation.
Re: Please change alias ReplaceArrayWithPointer = Flag!"replaceArrayWithPointer"
On 01/21/2016 03:42 PM, Jack Stouffer wrote: On Thursday, 21 January 2016 at 19:31:19 UTC, Andrei Alexandrescu wrote: * Do NOT alias Flag!"frob" to a new name. This is unnecessary, unhelpful, and wasteful. I disagree. Making an alias means the user does not have to import std.typecons in their code, and as a purely subjective measure, ReplaceArrayWithPointer.Yes looks better than Flag!"replaceArrayWithPointer".Yes. That would be Yes.replaceArrayWithPointer. -- Andrei
Re: opIndex, opSlice, length for joiner?
On 01/21/2016 05:22 PM, Maverick Chardet wrote: Just a question: is it possible for a range to be considered infinite and at the same time have a length? I suppose that if it is possible, such a range would be ill-formed... Indeed that range would be ill-formed. -- Andrei
Re: Please change alias ReplaceArrayWithPointer = Flag!"replaceArrayWithPointer"
On 01/21/2016 04:58 PM, H. S. Teoh via Digitalmars-d wrote:
auto myFunc(T)(T data, Flag!"replaceArrayWithPointer" replaceArrayWithPointer =
Flag!"replaceArrayWithPointer".Yes)
{ ... }
auto myFunc(T)(T data,
Flag!"replaceArrayWithPointer" flag = Yes.replaceArrayWithPointer)
Andrei
Re: [dlang.org] Let's talk about the logo
On Thursday, 21 January 2016 at 23:46:26 UTC, anonymous wrote: ... For me the last one. It's simple and clear. I really don't think the currently Logo is good for the new layout, I really dislike the black border. I don't know what the big deal with changing the Logo, since any big company out there change theirs from time to time (Coca-Cola, Microsoft, HP, Google and so on). Bubbasaur.
Re: Why do some attributes start with '@' while others done't?
On Thursday, 21 January 2016 at 23:18:16 UTC, tsbockman wrote: A revision of D that wasn't constrained by backwards compatibility would almost certainly either require all attributes to be prefixed by @, or change the grammar such that attribute names could be reused as identifier names without introducing ambiguities. It seems to me that '@' could be allowed as optional prefix to attributes that currently don't have it without breaking code - or am I being naïve?
Re: Why do some attributes start with '@' while others done't?
On Thursday, 21 January 2016 at 23:48:03 UTC, Brian Schott wrote: On Thursday, 21 January 2016 at 23:25:01 UTC, Era Scarecrow wrote: I'm almost tempted to suggest a tool that would update changes to source code when some of these things happen, dealing with most of these types of problems. Wit. Hang on. *I* wrote something like that. The problem is that nobody wants to make breaking changes even though dfix exists. https://github.com/Hackerpilot/dfix If the fixes are easily automated requiring no intervention (other than running a tool) then i would totally push for these changes; Probably have a reminder notes during each release for people unaware of dfix that it will fix these changes to source code. Worst case for not breaking code ultimately goes to users not updating the compiler.
Re: Why do some attributes start with '@' while others done't?
On Thursday, 21 January 2016 at 23:58:31 UTC, jmh530 wrote: Perhaps they could begin a process, like adding @pure and @nothrow. Then, people at least people can update source code at their own pace. I doubt adding those would break much code (which makes me wonder if it would be possible to do something like go through all of the dub repository and estimate if any code would get broken by it). I wrote up the details of this idea as a DIP many months ago: http://wiki.dlang.org/DIP64 It's already implemented in dfix. You can run "dfix --dip64 file.d" and the changes will be made automatically.
Re: [dlang.org] Let's talk about the logo
On Thursday, 21 January 2016 at 23:49:39 UTC, cym13 wrote: On Thursday, 21 January 2016 at 23:46:26 UTC, anonymous wrote: The logo is repeatedly being called out as a weak spot of the D brand. But so far Walter has been adamant about keeping it the way it is. [...] I love the third one from the top, it is close enough from the official logo to identify it with no difficulty and yet fits really well in the bar. Yes, the third is the best. The Martian horizon in the background is also a part of the core design of the logo; please don't drop it.
Re: Why do some attributes start with '@' while others done't?
On Thursday, 21 January 2016 at 23:48:03 UTC, Brian Schott wrote: Yeah. Somebody should write something like that. Wit. Hang on. *I* wrote something like that. The problem is that nobody wants to make breaking changes even though dfix exists. https://github.com/Hackerpilot/dfix Perhaps they could begin a process, like adding @pure and @nothrow. Then, people at least people can update source code at their own pace. I doubt adding those would break much code (which makes me wonder if it would be possible to do something like go through all of the dub repository and estimate if any code would get broken by it).
Re: Why do some attributes start with '@' while others done't?
On Thursday, 21 January 2016 at 23:25:01 UTC, Era Scarecrow wrote: I have to wonder if it would be that bad, since if you're aware of where it breaks (which source code) wouldn't a bulk search/replace of the sources to resolve that? It wouldn't be too bad, as such things go. But it also serves little practical purpose; why break people's code for purely aesthetic reasons? Although I'll be honest, breaking code is never fun, and making people scour their code to fix something that worked before is just an annoyance. On the other hand I'm almost tempted to suggest a tool that would update changes to source code when some of these things happen, dealing with most of these types of problems. https://code.dlang.org/packages/dfix
Re: Why do some attributes start with '@' while others done't?
On Thursday, 21 January 2016 at 23:25:01 UTC, Era Scarecrow wrote: Although I'll be honest, breaking code is never fun, and making people scour their code to fix something that worked before is just an annoyance. On the other hand I'm almost tempted to suggest a tool that would update changes to source code when some of these things happen, dealing with most of these types of problems. Yeah. Somebody should write something like that. Wit. Hang on. *I* wrote something like that. The problem is that nobody wants to make breaking changes even though dfix exists. https://github.com/Hackerpilot/dfix
Re: [dlang.org] Let's talk about the logo
On Thursday, 21 January 2016 at 23:46:26 UTC, anonymous wrote: The logo is repeatedly being called out as a weak spot of the D brand. But so far Walter has been adamant about keeping it the way it is. [...] I love the third one from the top, it is close enough from the official logo to identify it with no difficulty and yet fits really well in the bar.
[dlang.org] Let's talk about the logo
The logo is repeatedly being called out as a weak spot of the D brand. But so far Walter has been adamant about keeping it the way it is. I agree with him that changing it to a completely different one would probably not be a good move, losing whatever brand recognition we have. But I think we should adapt the logo to the needs at hand. It's obvious to me that the D and the moons (the two circles to the upper right of the D) make the recognizable core of the logo. I know that others see it the same way. That means, the D and the moons should be kept intact. Their shapes and positions should not change. However, I believe we can take away a lot of the decorations of the current logo, and it will still be recognized immediately as the same brand. Here's a little progression of simplifications, in the context of dlang.org: http://i.imgur.com/eJaKFtx.png The first one is the current logo. The last one shows just the core shape (D + moons), of course. I'm not nearly the first one to do this, but I'd like to propose adopting the core shape as the official logo. Then specify some specific shade of red as the official brand color. (We're using #B03931 on dlang.org.) We could provide multiple variants of the logo for different use cases, and with varying levels of decoration: * Core shape in different color combinations (black one white, red on white, white on red). * Versions that include the background arc (I'm interpreting that as Mars), possibly in different colors. * The full version with border and shadow. I.e. the current logo with adjusted colors, and maybe some details changed, like number of borders or amount of shininess. For dlang.org, I'd choose the version with the wide background arc. I think it looks nice on the menu bar, and it puts a little more emphasis there than just the core shape. But just the core shape looks fine, too.
Re: Why do some attributes start with '@' while others done't?
On Thursday, 21 January 2016 at 23:18:16 UTC, tsbockman wrote: Adding the @ to the old attributes was discussed as well, but it didn't seem worth the code breakage. I have to wonder if it would be that bad, since if you're aware of where it breaks (which source code) wouldn't a bulk search/replace of the sources to resolve that? Although I'll be honest, breaking code is never fun, and making people scour their code to fix something that worked before is just an annoyance. On the other hand I'm almost tempted to suggest a tool that would update changes to source code when some of these things happen, dealing with most of these types of problems.
Re: [dlang.org] new forum design
On Thursday, 21 January 2016 at 21:29:19 UTC, Vladimir Panteleev wrote: Noted. This seems to be a highly requested feature. Thanks. I didn't see a reply from you, so I wasn't sure if you had noticed the earlier questions about this.
Re: Why do some attributes start with '@' while others done't?
On Thursday, 21 January 2016 at 23:14:14 UTC, Dibyendu Majumdar wrote: I see. And which approach is considered better? Personally don't see why the '@' prefix is necessary. Regards Without the "@", the following valid code would break: bool safe = !aIsDangerous && !bIsDangerous; Every time a new keyword is added to the language some working code will become invalid.
Re: Why do some attributes start with '@' while others done't?
On Thursday, 21 January 2016 at 23:05:51 UTC, Dibyendu Majumdar
wrote:
I am puzzled as to why there is @nogc on the one hand and
simply nothrow on the other? Why are some attributes prefixed
with '@' while others aren't?
Regards
Short answer: It's for historical reasons; it would not be done
this way today, but cannot be changed without breaking valid code
already in the wild.
Longer answer: The ones prefixed with @ are not keywords. This is
good, because it means that they are not reserved, and may be
used as identifiers as well.
This will compile fine:
void nogc(int nogc) @nogc nothrow {
}
This won't, though:
void nothrow(int nothrow) @nogc nothrow {
}
When the process of designing D began, people didn't realize just
how many attributes would end up being added to the language. At
some point, it became clear that it was both undesirable and
unnecessary to forbid all attribute names from being used for
other purposes elsewhere in D's grammar. The solution was to
begin prefixing @ to new attributes.
Adding the @ to the old attributes was discussed as well, but it
didn't seem worth the code breakage.
A revision of D that wasn't constrained by backwards
compatibility would almost certainly either require all
attributes to be prefixed by @, or change the grammar such that
attribute names could be reused as identifier names without
introducing ambiguities.
Re: Why do some attributes start with '@' while others done't?
On Thursday, 21 January 2016 at 23:08:07 UTC, Brad Anderson wrote: On Thursday, 21 January 2016 at 23:05:51 UTC, Dibyendu Majumdar wrote: I am puzzled as to why there is @nogc on the one hand and simply nothrow on the other? Why are some attributes prefixed with '@' while others aren't? For historical reasons, basically. There have been some calls to make it uniform but nothing has really happened. I see. And which approach is considered better? Personally don't see why the '@' prefix is necessary. Regards
Re: Why do some attributes start with '@' while others done't?
On Thursday, 21 January 2016 at 23:05:51 UTC, Dibyendu Majumdar wrote: I am puzzled as to why there is @nogc on the one hand and simply nothrow on the other? Why are some attributes prefixed with '@' while others aren't? Regards For historical reasons, basically. There have been some calls to make it uniform but nothing has really happened.
Why do some attributes start with '@' while others done't?
I am puzzled as to why there is @nogc on the one hand and simply nothrow on the other? Why are some attributes prefixed with '@' while others aren't? Regards
Re: JMH
I can only suspect, but I think they use maven to collect all functions that use @Benchmark. And this leads to the problem the unittest library proposal for phobos had. No that is the job of the Java compiler. Actually, annotations in Java can be both read at runtime or compile time. As far as I know, you cannot hook into the compiler to check for annotations, so most Java frameworks scan for annotations at startup time. Not that it matters much, anyways.
Re: opIndex, opSlice, length for joiner?
On Thursday, 21 January 2016 at 01:22:43 UTC, Andrei Alexandrescu wrote: Thanks for askin. Consider chain(), which currently DOES offer random access if its constituents to. In that case, the number of ranges chained is a compile-time constant dictated by the source code being compiled; no data dependency. In contrast, the performance of joiner()'s proposed primitives would be dependent on the data. For your simplest example, length would be linear in the number of ranges. One way to improve on that would be to compute length upon the first call and then memoize (and update) it. There is a risk it could go out of sync if someone changes the ranges involved surreptitiously. One good thing to do here would be to specialize joiner().walkLength. Then people writing r.walkLength would benefit from the quicker specialized version. For indexed access, things get a fair amount more complicated. You can't afford linear time, so you need some serious data structure to ensure good performance there. That seems to take joiner() in a design space that makes it less attractive; currently it's a simple spec with a somewhat straightforward implementation. Andrei Thank you for your remarks! I just finished to implement the specialized version of walkLength (this was a great idea), I just have to write a few comments and clever unittests before the PR, I may send it later today or tomorrow! Just a question: is it possible for a range to be considered infinite and at the same time have a length? I suppose that if it is possible, such a range would be ill-formed... I'm asking because for my specialized version to compile in the case where there is no separator, I require hasLength!(ElementType!RoR) (otherwise the specialization is useless), and I'm wondering wether testing for !isInfinite!(ElementType!RoR) for the version with no "upTo" parameter is useful or not at all... Maverick Chardet
Re: Please change alias ReplaceArrayWithPointer = Flag!"replaceArrayWithPointer"
On Thu, Jan 21, 2016 at 08:42:17PM +, Jack Stouffer via Digitalmars-d wrote:
> On Thursday, 21 January 2016 at 19:31:19 UTC, Andrei Alexandrescu wrote:
> >* Do NOT alias Flag!"frob" to a new name. This is unnecessary,
> >unhelpful, and wasteful.
>
> I disagree. Making an alias means the user does not have to import
> std.typecons in their code, and as a purely subjective measure,
> ReplaceArrayWithPointer.Yes looks better than
> Flag!"replaceArrayWithPointer".Yes.
Yeah, and it looks even worse in function signatures, especially when
default arguments are present:
auto myFunc(T)(T data, Flag!"replaceArrayWithPointer"
replaceArrayWithPointer = Flag!"replaceArrayWithPointer".Yes)
{ ... }
vs.
alias ReplaceArrayWithPointer = Flag!"replaceArrayWithPointer";
auto myFunc(T)(T data, ReplaceArrayWithPointer replaceArrayWithPointer
= ReplaceArrayWithPointer.Yes)
{ ... }
Still pretty bad, but at least it's a few characters less.
On a tangential note, default arguments seriously should allow
abbreviated syntax, to prevent the blatant violation of DRY as shown
above:
auto myFunc(T)(T data, ReplaceArrayWithPointer replaceArrayWithPointer
= .Yes)
{ ... }
Basically, inside a default argument spec, it should be as though the
delcaration were encased in a `with(T) { ... }` block where T is the
type of the argument.
Even better would be a way to not have to type out the variable name
when it is just the type name camelcased, but I haven't thought of a way
of doing this that fits in with D's current syntax just yet. Some
manner of "eponymous variable", along the same idea as eponymous
templates.
T
--
Programming is not just an act of telling a computer what to do: it is also an
act of telling other programmers what you wished the computer to do. Both are
important, and the latter deserves care. -- Andrew Morton
Re: [dlang.org] new forum design
On Thursday, 21 January 2016 at 21:21:18 UTC, Vladimir Panteleev wrote: On Thursday, 21 January 2016 at 21:14:34 UTC, mate wrote: Thank you to anonymous and yourself for the hard work. On the mobile version (Android) the “Replies” column has gone, and with it the link to the first unread message. Is there any plan to add it back? This link was useful to me. Yet the link to the last message is still present in the “Last Post” column, but it is of low value in my opinion. OK, I added it back. I confirmed it’s back. Thank you very much.
Re: [dlang.org] new forum design
On Thursday, 21 January 2016 at 21:27:31 UTC, tsbockman wrote: On Thursday, 21 January 2016 at 21:21:18 UTC, Vladimir Panteleev wrote: [...] The "Thread Overview" bar is only visible on the first page of a thread. Is this by design? Yes, currently by design. It would be really nice if it appeared at the top of every page, rather than just the first. Noted. This seems to be a highly requested feature.
Re: [dlang.org] new forum design
On Thursday, 21 January 2016 at 21:21:18 UTC, Vladimir Panteleev wrote: [...] The "Thread Overview" bar is only visible on the first page of a thread. Is this by design? It would be really nice if it appeared at the top of every page, rather than just the first.
Re: [dlang.org] new forum design
On Thursday, 21 January 2016 at 21:14:34 UTC, mate wrote: Thank you to anonymous and yourself for the hard work. On the mobile version (Android) the “Replies” column has gone, and with it the link to the first unread message. Is there any plan to add it back? This link was useful to me. Yet the link to the last message is still present in the “Last Post” column, but it is of low value in my opinion. OK, I added it back.
Re: Please change alias ReplaceArrayWithPointer = Flag!"replaceArrayWithPointer"
On Thursday, 21 January 2016 at 20:42:56 UTC, jmh530 wrote: On Thursday, 21 January 2016 at 19:31:19 UTC, Andrei Alexandrescu wrote: The correct idiom involving Flag is: * Use the name Flag!"frob" for the type of the flag * Use Yes.frob and No.frob for the flag values * Do NOT alias Flag!"frob" to a new name. This is unnecessary, unhelpful, and wasteful. Can somebody please change the respective code in std.experimental.ndslice? Thanks, Andrei Perhaps https://dlang.org/phobos/std_typecons.html#.Flag should be adjusted. It recommends aliasing. https://github.com/D-Programming-Language/phobos/pull/3947
Re: [dlang.org] new forum design
On Thursday, 21 January 2016 at 06:24:04 UTC, Vladimir Panteleev wrote: On Wednesday, 20 January 2016 at 19:04:18 UTC, Jacob Carlborg wrote: On 2016-01-19 20:59, Vladimir Panteleev wrote: Yep, plus now that we use a narrow font :P Made it narrower + hid it on very narrow viewports (incl. portrait iPhone). Thanks. But now when the column is removed, it's not enough margin/padding on the right side, for the "Last Post" column. Sorry, I don't understand. I don't see a problem in the iOS simulator in neither portrait or landscape mode. Can you elaborate or post a screenshot? Thank you to anonymous and yourself for the hard work. On the mobile version (Android) the “Replies” column has gone, and with it the link to the first unread message. Is there any plan to add it back? This link was useful to me. Yet the link to the last message is still present in the “Last Post” column, but it is of low value in my opinion.
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 15:32:10 UTC, Dibyendu Majumdar wrote: On Thursday, 14 January 2016 at 14:40:05 UTC, bachmeier wrote: On Thursday, 14 January 2016 at 13:47:39 UTC, Dibyendu Majumdar wrote: I did find that I had to go through many articles, video presentations etc. to form my conclusions - it would have been nice if there was a single page on the D website that explained why D should be chosen over the other competing languages. The information is all there but scattered all over the place. Do you have specific suggestions for improvements? The difficulty is predicting where someone will look for that information. I think a prominent Link saying - Why choose D? on the home page. and maybe initially this could take to another page with links to articles, videos etc. But longer term it would better to have a more structured presentation of the benefits. Example - show with examples what can be done with D templates that is hard or not possible with C++. And similarly with other languages. I would suggest very aggressive 'marketing' of D advantages. Regards A set of 'channels' for different use cases might be helpful. Eg bioinformatics, numerical computing, web, etc. Both for tutorials and setting out the advantages.
Re: Please change alias ReplaceArrayWithPointer = Flag!"replaceArrayWithPointer"
On Thursday, 21 January 2016 at 19:31:19 UTC, Andrei Alexandrescu wrote: The correct idiom involving Flag is: * Use the name Flag!"frob" for the type of the flag * Use Yes.frob and No.frob for the flag values * Do NOT alias Flag!"frob" to a new name. This is unnecessary, unhelpful, and wasteful. Can somebody please change the respective code in std.experimental.ndslice? Thanks, Andrei Perhaps https://dlang.org/phobos/std_typecons.html#.Flag should be adjusted. It recommends aliasing.
Re: Please change alias ReplaceArrayWithPointer = Flag!"replaceArrayWithPointer"
On Thursday, 21 January 2016 at 19:31:19 UTC, Andrei Alexandrescu wrote: * Do NOT alias Flag!"frob" to a new name. This is unnecessary, unhelpful, and wasteful. I disagree. Making an alias means the user does not have to import std.typecons in their code, and as a purely subjective measure, ReplaceArrayWithPointer.Yes looks better than Flag!"replaceArrayWithPointer".Yes.
Re: Please change alias ReplaceArrayWithPointer = Flag!"replaceArrayWithPointer"
On Thursday, 21 January 2016 at 19:31:19 UTC, Andrei Alexandrescu wrote: The correct idiom involving Flag is: * Use the name Flag!"frob" for the type of the flag * Use Yes.frob and No.frob for the flag values * Do NOT alias Flag!"frob" to a new name. This is unnecessary, unhelpful, and wasteful. Can somebody please change the respective code in std.experimental.ndslice? Thanks, Andrei Found these guidelines useful: http://p0nce.github.io/d-idioms/#Using-std.typecons.Flag-like-a-pro
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 16:08:24 UTC, Joakim wrote: On Thursday, 14 January 2016 at 15:32:10 UTC, Dibyendu Majumdar I think a prominent Link saying - Why choose D? on the home page. and maybe initially this could take to another page with links to articles, videos etc. But longer term it would better to have a more structured presentation of the benefits. Example - show with examples what can be done with D templates that is hard or not possible with C++. And similarly with other languages. I would suggest very aggressive 'marketing' of D advantages. You're right, D's not very good at marketing. On the other hand, have you ever found what you're suggesting on any other programming language's website? I haven't, so they're all in the same boat, each one as bad as the next. Sort of sounds like he wants something in this vein, only as part of the site: http://fsharpforfunandprofit.com/ -Wyatt
Re: Please change alias ReplaceArrayWithPointer = Flag!"replaceArrayWithPointer"
On Thursday, 21 January 2016 at 19:31:19 UTC, Andrei Alexandrescu wrote: The correct idiom involving Flag is: * Use the name Flag!"frob" for the type of the flag * Use Yes.frob and No.frob for the flag values * Do NOT alias Flag!"frob" to a new name. This is unnecessary, unhelpful, and wasteful. Can somebody please change the respective code in std.experimental.ndslice? Thanks, Andrei https://github.com/D-Programming-Language/phobos/pull/3946
Re: [dlang.org] new forum design
On 2016-01-21 07:24, Vladimir Panteleev wrote: Sorry, I don't understand. I don't see a problem in the iOS simulator in neither portrait or landscape mode. Can you elaborate or post a screenshot? I created an issue [1] to have somewhere to upload the images. [1] https://github.com/CyberShadow/DFeed/issues/54 -- /Jacob Carlborg
Re: Please change alias ReplaceArrayWithPointer = Flag!"replaceArrayWithPointer"
On Thursday, 21 January 2016 at 19:31:19 UTC, Andrei Alexandrescu wrote: The correct idiom involving Flag is: * Use the name Flag!"frob" for the type of the flag * Use Yes.frob and No.frob for the flag values * Do NOT alias Flag!"frob" to a new name. This is unnecessary, unhelpful, and wasteful. Can somebody please change the respective code in std.experimental.ndslice? Thanks, Andrei OK --Ilya
Re: Request for new Deimos repository
On 2016-01-21 01:33, Brian Schott wrote: EMSI has a D version of rec.h from GNU recutils[1]. If somebody creates a repository for this I can get these bindings into Deimos pretty quickly. [1] https://www.gnu.org/software/recutils/manual/recutils.html#Purpose I don't see a point in having a special Deimos repository. Just put it on GitHub and Dub. -- /Jacob Carlborg
Re: Website contains a virus?
On Thursday, 21 January 2016 at 19:23:50 UTC, Walter Bright wrote: On 1/21/2016 10:46 AM, Dominikus Dittes Scherkl wrote: I'm using Norton Security from Symantec, and it claims that the current compiler dmd-2.069.2.exe is infected with the "Trojan.Gen.2". Not a particularly harmful virus, but nevertheless I hope that's not true or you can fix that rather soon! I've had virus checkers claim Digital Mars software had viruses before. They were all false positives. That doesn't prove this one is a false positive, but I've heard "wolf" cried enough times that I'm pretty jaundiced about it. Yeah. The problem is, Norton is rather wide-spread and it put a big warning before this site now, which is rather annoing even if you are convinced it's a false positive :-( I suspect this can do much harm to the D community if we can't manage to get rid of the warning. But only the site-owner can get a re-evaluation from Norton.
Please change alias ReplaceArrayWithPointer = Flag!"replaceArrayWithPointer"
The correct idiom involving Flag is: * Use the name Flag!"frob" for the type of the flag * Use Yes.frob and No.frob for the flag values * Do NOT alias Flag!"frob" to a new name. This is unnecessary, unhelpful, and wasteful. Can somebody please change the respective code in std.experimental.ndslice? Thanks, Andrei
Re: Website contains a virus?
On 1/21/2016 10:46 AM, Dominikus Dittes Scherkl wrote: I'm using Norton Security from Symantec, and it claims that the current compiler dmd-2.069.2.exe is infected with the "Trojan.Gen.2". Not a particularly harmful virus, but nevertheless I hope that's not true or you can fix that rather soon! I've had virus checkers claim Digital Mars software had viruses before. They were all false positives. That doesn't prove this one is a false positive, but I've heard "wolf" cried enough times that I'm pretty jaundiced about it.
Re: Website contains a virus?
On Thursday, 21 January 2016 at 18:57:27 UTC, Brad Anderson wrote: Hold on, that may not have scanned like I expected since I used a URL...rerunning using a file upload... New results: ... Now to decide if it's a false positive... (we use NSIS which I could easily see being an easily thing to have false positives with). Results against: 2.060: https://www.virustotal.com/en/file/8da5b46e34e476c29155eff8507aa7a6a82545b1e236f27bad2b6613d2165498/analysis/1453403420/ 2.066.1: https://www.virustotal.com/en/file/a06d989365e77b46900c45ded383d16292e2ed92aba98621bc89861cc60082e3/analysis/1453403539/ Bubbasaur.
Re: Website contains a virus?
On Thursday, 21 January 2016 at 18:58:04 UTC, Vladimir Panteleev wrote: You could also check that the download has not been modified in-flight using the provided signature files. Here are my hashes: MD5: 1f6a138851c7d27bc7df637126008614 SHA1: 5d76851618adc8c2c2cccab5111ea7f35a020002 SHA256: 45e01e0eba641b02874d84fafceefac2b53a28add31ceeef2a4bfce13c1440d7 Code signing would help protect against this. Norton also takes whether a file has code signing into account (though I believe you need a class 3 for it to really help your rating).
Re: Website contains a virus?
On Thursday, 21 January 2016 at 18:46:15 UTC, Dominikus Dittes Scherkl wrote: Hi. I'm using Norton Security from Symantec, and it claims that the current compiler dmd-2.069.2.exe is infected with the "Trojan.Gen.2". Not a particularly harmful virus, but nevertheless I hope that's not true or you can fix that rather soon! I just ran it through VirusTotal and nothing came up: https://www.virustotal.com/en/url/e4fb12ce95fb0234554339a5162e736d5f337b427214b58d5bc10122fcb83435/analysis/1453402206/
Re: Website contains a virus?
On Thursday, 21 January 2016 at 18:46:15 UTC, Dominikus Dittes Scherkl wrote: Hi. I'm using Norton Security from Symantec, and it claims that the current compiler dmd-2.069.2.exe is infected with the "Trojan.Gen.2". That would be a false positive. Not a particularly harmful virus, but nevertheless I hope that's not true or you can fix that rather soon! Unfortunately software writers do not have many options when false positives occur against their software. Please report this false positive to your antivirus vendor. You could also check that the download has not been modified in-flight using the provided signature files. Here are my hashes: MD5: 1f6a138851c7d27bc7df637126008614 SHA1: 5d76851618adc8c2c2cccab5111ea7f35a020002 SHA256: 45e01e0eba641b02874d84fafceefac2b53a28add31ceeef2a4bfce13c1440d7
Re: Website contains a virus?
On Thursday, 21 January 2016 at 18:55:16 UTC, Brad Anderson wrote: On Thursday, 21 January 2016 at 18:50:48 UTC, Brad Anderson wrote: On Thursday, 21 January 2016 at 18:46:15 UTC, Dominikus Dittes Scherkl wrote: Hi. I'm using Norton Security from Symantec, and it claims that the current compiler dmd-2.069.2.exe is infected with the "Trojan.Gen.2". Not a particularly harmful virus, but nevertheless I hope that's not true or you can fix that rather soon! I just ran it through VirusTotal and nothing came up: https://www.virustotal.com/en/url/e4fb12ce95fb0234554339a5162e736d5f337b427214b58d5bc10122fcb83435/analysis/1453402206/ Hold on, that may not have scanned like I expected since I used a URL...rerunning using a file upload... New results: https://www.virustotal.com/en/file/45e01e0eba641b02874d84fafceefac2b53a28add31ceeef2a4bfce13c1440d7/analysis/1453402410/ Now to decide if it's a false positive... (we use NSIS which I could easily see being an easily thing to have false positives with).
Re: Website contains a virus?
On Thursday, 21 January 2016 at 18:50:48 UTC, Brad Anderson wrote: On Thursday, 21 January 2016 at 18:46:15 UTC, Dominikus Dittes Scherkl wrote: Hi. I'm using Norton Security from Symantec, and it claims that the current compiler dmd-2.069.2.exe is infected with the "Trojan.Gen.2". Not a particularly harmful virus, but nevertheless I hope that's not true or you can fix that rather soon! I just ran it through VirusTotal and nothing came up: https://www.virustotal.com/en/url/e4fb12ce95fb0234554339a5162e736d5f337b427214b58d5bc10122fcb83435/analysis/1453402206/ Hold on, that may not have scanned like I expected since I used a URL...rerunning using a file upload...
Re: Website contains a virus?
On Thursday, 21 January 2016 at 18:51:34 UTC, sclytrack wrote: On Thursday, 21 January 2016 at 18:46:15 UTC, Dominikus Dittes Scherkl wrote: Hi. I'm using Norton Security from Symantec, and it claims that the current compiler dmd-2.069.2.exe is infected with the "Trojan.Gen.2". Not a particularly harmful virus, but nevertheless I hope that's not true or you can fix that rather soon! Does this pose a problem for the linux variant? Hm. The .exe is precompiled for Windows only, so I suppose not. But the one generating it should have a look, would be likely his machine is infected too.
Re: Website contains a virus?
On Thursday, 21 January 2016 at 18:46:15 UTC, Dominikus Dittes Scherkl wrote: Hi. I'm using Norton Security from Symantec, and it claims that the current compiler dmd-2.069.2.exe is infected with the "Trojan.Gen.2". Not a particularly harmful virus, but nevertheless I hope that's not true or you can fix that rather soon! Does this pose a problem for the linux variant?
Website contains a virus?
Hi. I'm using Norton Security from Symantec, and it claims that the current compiler dmd-2.069.2.exe is infected with the "Trojan.Gen.2". Not a particularly harmful virus, but nevertheless I hope that's not true or you can fix that rather soon!
Re: forum.dlang.org is now available via HTTPS
This is pretty cool. We should maybe see if we can add it to the "HTTPS Everywhere" plugin. Does anyone else use that? I've always found it so hard to just add a new domain to its rule list.
Re: forum.dlang.org is now available via HTTPS
On Thursday, 21 January 2016 at 17:09:55 UTC, Bubbasaur wrote: On Thursday, 21 January 2016 at 17:02:39 UTC, Vladimir Panteleev wrote: I'm guessing you have an outdated certificate store. Make sure "DST Root CA X3" is in the list of your trusted root certificates. Do you have different certificates for the dlang.org and the forum? Because like I said: https://dlang.org works while the forum doesn't. Yes, of course. The website and the forum are hosted by different people on different machines.
Re: forum.dlang.org is now available via HTTPS
On Thursday, 21 January 2016 at 17:02:39 UTC, Vladimir Panteleev wrote: I'm guessing you have an outdated certificate store. Make sure "DST Root CA X3" is in the list of your trusted root certificates. Do you have different certificates for the dlang.org and the forum? Because like I said: https://dlang.org works while the forum doesn't. Bubbasaur.
Re: forum.dlang.org is now available via HTTPS
On Thursday, 21 January 2016 at 12:41:21 UTC, Era Scarecrow wrote: Note: I'm using Firefox v25, and v15... That's pretty old. You may want to update.
Re: Compile-Time RNG
On Thursday, 21 January 2016 at 09:29:38 UTC, Matthias Bentrup wrote: That aspect can easily be replaced by __LINE__ and __FILE__. A supported way to generate new names at compile time would be nice. It would, but in this particular case __LINE__ and __FILE__ actually provide a more natural way of solving the problem. The idea of generating new symbols to increment the counter is clever, but it's also an awkward hack. __LINE__ already does pretty much what he needed by itself.
Re: forum.dlang.org is now available via HTTPS
On Thursday, 21 January 2016 at 16:55:49 UTC, Bubbasaur wrote: On Wednesday, 20 January 2016 at 18:36:12 UTC, Vladimir Panteleev wrote: It took a while but I finally got around to adapting a Let's Encrypt ACME client to my hosting system with automatic renewals etc. Enjoy! https://forum.dlang.org/ Adam, your turn! I'm not Adam, but anyway I tried the link above and I've got: NET::ERR_CERT_INVALID http://i.imgur.com/7z3JZXn.png Bubbasaur. I'm guessing you have an outdated certificate store. Make sure "DST Root CA X3" is in the list of your trusted root certificates.
Re: forum.dlang.org is now available via HTTPS
On Wednesday, 20 January 2016 at 18:36:12 UTC, Vladimir Panteleev wrote: It took a while but I finally got around to adapting a Let's Encrypt ACME client to my hosting system with automatic renewals etc. Enjoy! https://forum.dlang.org/ Adam, your turn! I'm not Adam, but anyway I tried the link above and I've got: NET::ERR_CERT_INVALID http://i.imgur.com/7z3JZXn.png Bubbasaur.
Re: forum.dlang.org is now available via HTTPS
I forgot to say that the https://dlang.org works, so It's something with the Forums. Bubbasaur.
Re: Idea: limited template expansion
On 1/21/16 10:02 AM, David Nadlinger wrote: On Thursday, 21 January 2016 at 13:36:28 UTC, Steven Schveighoffer wrote: On 1/20/16 6:01 PM, David Nadlinger wrote: How would the client code be simpler with a built-in language feature? The use case I have in mind is a parser, let's say an xml parser. […] I still don't see how a language feature as described in your first post would make this any easier than using a template for that exact purpose (switching between methods to call). It may not be an "easier" thing to have the compiler do this instead of the user, but conceptually to me it reads better. One can write foreach loops as for loops also, it's not really hard. Yet foreach loops read and write better conceptually than a for loop. And the boilerplate is cut down significantly. I'm simply trying to get rid of the boiler plate that one would need for such a thing. And I'm wondering if this is a unique situation for my use case, or if there are other use cases. If it's just for this one case, it's likely not worth exploring a modification to the language. If what you are trying to say is that you want the different template function instantiations to return incompatible types in addition to that, the feature from your initial post won't help you there either. Values can't have different types in non-template code, so you'd necessarily need to make the client code a template too. Streamlining the runtime -> compile time value dispatch process (as shown in your initial example) doesn't change the fact that the type of a given value cannot be influenced by runtime decisions. The client code would be a template. Essentially, the compiler would rewrite the block as a template function and call the appropriate one. But the code itself would look like an inline block. -Steve
Re: Idea: limited template expansion
On Thursday, 21 January 2016 at 13:36:28 UTC, Steven Schveighoffer wrote: On 1/20/16 6:01 PM, David Nadlinger wrote: How would the client code be simpler with a built-in language feature? The use case I have in mind is a parser, let's say an xml parser. […] I still don't see how a language feature as described in your first post would make this any easier than using a template for that exact purpose (switching between methods to call). If what you are trying to say is that you want the different template function instantiations to return incompatible types in addition to that, the feature from your initial post won't help you there either. Values can't have different types in non-template code, so you'd necessarily need to make the client code a template too. Streamlining the runtime -> compile time value dispatch process (as shown in your initial example) doesn't change the fact that the type of a given value cannot be influenced by runtime decisions. — David
Re: So... add maxCount and maxPos?
On 01/21/2016 08:42 AM, Era Scarecrow wrote: I'd almost say lowestCount and highestCount would almost be better, but i am not sure. minCount is already a given. -- Andrei
Re: So... add maxCount and maxPos?
On Wednesday, 20 January 2016 at 17:29:28 UTC, H. S. Teoh wrote:
On Wed, Jan 20, 2016 at 12:16:00PM -0500, Andrei Alexandrescu
via Digitalmars-d wrote:
This is one of those cases in which we were pedantically right
to not add them, but their equivalents look like crap.
I don't like this. I'd much rather we rename those functions
to be something more generic. After all, minPos is a horrible
name when the predicate has nothing to do with minimum values.
What about extremumPos? (Though that's rather ugly to type.)
maxCount sounds too much like it's suppose to be a function in
SQL querying, and minCount... ugg... now I wonder what in the
world we're talking about.
From algorithm.d:
int[] a = [ 2, 3, 4, 1, 2, 4, 1, 1, 2 ];
// Minimum is 1 and occurs 3 times
assert(a.minCount == tuple(1, 3));
// Maximum is 4 and occurs 2 times
assert(a.maxCount == tuple(4, 2));
// Minimum is 1 and first occurs in position 3
assert(a.minPos == [ 1, 2, 4, 1, 1, 2 ]);
// Maximum is 4 and first occurs in position 2
assert(a.maxPos == [ 4, 1, 2, 4, 1, 1, 2 ]);
These unittests make it completely clear what it wants to do. I'd
almost say lowestCount and highestCount would almost be better,
but i am not sure. or just unitCount? Or countOf and posOf? which
make a lot more sense when instantiated: So a.countOf!("a < b")?
I'm seriously behind on all of this.
Re: Idea: limited template expansion
On 1/20/16 6:01 PM, David Nadlinger wrote:
On Wednesday, 20 January 2016 at 22:00:45 UTC, Steven Schveighoffer wrote:
Imagine if you such a call returned something, and you simply used it
throughout the rest of your function. The compiler could rewrite this
as a template and compile all three versions and branch to the
appropriate one, but your code would simply read as a straightforward
procedural function.
But if you abstract away the dispatch part into a (meta)template
function like I suggested, the caller would still be just as linear, right?
How would the client code be simpler with a built-in language feature?
The use case I have in mind is a parser, let's say an xml parser.
You have a file, it could be UTF8, UTF16, UTF32 (not to mention
endianness, but that just adds to the number of finite possibilities)
Once you have determined the encoding, it doesn't change. So it's not
advantageous to store the encoding in a runtime variable and check it at
every turn. It makes more sense to templatize the code that deals with
the XML parsing based on the code unit type, once that has been determined.
But client code ALSO has to deal with this, not just the library. So the
implementation details sort of leak out into the caller.
Let's say there is a function parseXML that returns a range (a la
byLine) that gives you elements from the xml tree.
Instead of a nice thing like:
foreach(element; file.asUTFX.parseXML)
{
... client code
}
you have to do something like this:
switch(file.detectBOM)
{
case UTF8:
foreach(element; file.asUTF8.parseXML)
{
... client code
}
break;
case UTF16:
foreach(element; file.asUTF16.parseXML)
{
... client code
}
break;
case UTF32:
foreach(element; file.asUTF32.parseXML)
{
... client code
}
break;
}
In other words, the API *requires* you to write this switch thingy (and
obviously to break up your client code into another function), or use
some other mechanism. I want to hide the details of what is happening
there in a simple call so the code is easy to read/write.
-Steve
Re: Idea: limited template expansion
On 1/21/16 7:18 AM, Sebastiaan Koppe wrote: On Wednesday, 20 January 2016 at 21:44:06 UTC, David Nadlinger wrote: Can't you just write a wrapper function that takes the template function as a compile-time argument and generates the switch for you by iterating over the std.traits.EnumMembers of said compile-time parameter? Something like `enumTemplateDispatch!foo(detectBOM(buffer), ))`. I have used EnumMembers a few times and it definitely saved me the hassle of writing the switch myself. However, in this case, isn't there a mapping between enums and types that one still needs to specify? That is: ( UTF8=>char[], UTF16=>wchar[], UTF32=>dchar[] ). Yeah, you really need an enum to make this make sense (there's not a great way to tell the compiler "I only mean char types"). I didn't show what it would look like, but one is trivial to write. -Steve
Re: forum.dlang.org is now available via HTTPS
On Thursday, 21 January 2016 at 12:41:21 UTC, Era Scarecrow wrote: On Thursday, 21 January 2016 at 12:08:23 UTC, Sebastiaan Koppe wrote: On Wednesday, 20 January 2016 at 18:36:12 UTC, Vladimir Panteleev wrote: It took a while but I finally got around to adapting a Let's Encrypt ACME client to my hosting system with automatic renewals etc. Enjoy! https://forum.dlang.org/ Adam, your turn! Any reason for not forcing https? Secure Connection failed! Cannot communicate securely with peer: no common encryption algorithm(s). Note: I'm using Firefox v25, and v15... I clicked on the link, and it works on Firefox v43.0.4.
Re: So... add maxCount and maxPos?
On Thursday, 21 January 2016 at 12:17:26 UTC, default0 wrote: On Thursday, 21 January 2016 at 02:36:05 UTC, Ivan Kazmenko wrote: An alternative would be to define min(one argument) to just be that argument. That would be consistent with what we have now, but violates the principle of least astonishment for newcomers: why would min ([3, 1, 2]) return [3, 1, 2] and not 1? Currently, it just does not compile. As a newcomer to the language, and as a reader of https://dlang.org/phobos/std_algorithm_comparison.html#min which states "Iterates the passed arguments and returns the minimum value." my intuitive understanding would be that yes of course min(x) returns x. However the above could of course also be reworded as "Iterates the passed list of arguments and returns the minimum value." to be even more clear about it NOT iterating individual arguments but the argument list as a whole :-) If I were to be a newcomer to programming in general this might be confusing, though. However, it's certainly consistent and easy to wrap your head around and also what I would have expected it to do the first time I came across the function. Still, looks like Java, C# and Python have min work this way: given a single argument which is a collection, it returns the minimum in that collection, not the collection itself. A Python example: min ([1]) // 1 min ([2, 1]) // 1 min ((([1, 2], [2, 3]))) // [1, 2] min ((([1, 2]))) // 1 min ((([1, 2],),)) // ([1, 2],) In Python, the what happens is also tricky: def g(): return (1, 2) // tuple of two values g() // (1, 2) min (g()) // 1 from tuple min (*g()) // 1 from expanded tuple def f(): return (1,) // tuple of a single value f() // (1,) min (f()) // 1 min (*f()) // error, cannot expand
Re: forum.dlang.org is now available via HTTPS
On Thursday, 21 January 2016 at 12:08:23 UTC, Sebastiaan Koppe wrote: On Wednesday, 20 January 2016 at 18:36:12 UTC, Vladimir Panteleev wrote: It took a while but I finally got around to adapting a Let's Encrypt ACME client to my hosting system with automatic renewals etc. Enjoy! https://forum.dlang.org/ Adam, your turn! Any reason for not forcing https? Secure Connection failed! Cannot communicate securely with peer: no common encryption algorithm(s). Note: I'm using Firefox v25, and v15...
Re: So... add maxCount and maxPos?
On Thursday, 21 January 2016 at 02:36:05 UTC, Ivan Kazmenko wrote: An alternative would be to define min(one argument) to just be that argument. That would be consistent with what we have now, but violates the principle of least astonishment for newcomers: why would min ([3, 1, 2]) return [3, 1, 2] and not 1? Currently, it just does not compile. As a newcomer to the language, and as a reader of https://dlang.org/phobos/std_algorithm_comparison.html#min which states "Iterates the passed arguments and returns the minimum value." my intuitive understanding would be that yes of course min(x) returns x. However the above could of course also be reworded as "Iterates the passed list of arguments and returns the minimum value." to be even more clear about it NOT iterating individual arguments but the argument list as a whole :-) If I were to be a newcomer to programming in general this might be confusing, though. However, it's certainly consistent and easy to wrap your head around and also what I would have expected it to do the first time I came across the function.
Re: JMH
On 2016-01-20 22:05, Robert burner Schadek wrote: The problem was that the user had to create a custom main that listed all modules to check for tests or use a build tool with some globbing commands. Both not perfect. What we need is this: https://github.com/D-Programming-Language/dmd/pull/2271 -- /Jacob Carlborg
Re: Idea: limited template expansion
On Wednesday, 20 January 2016 at 21:44:06 UTC, David Nadlinger wrote: Can't you just write a wrapper function that takes the template function as a compile-time argument and generates the switch for you by iterating over the std.traits.EnumMembers of said compile-time parameter? Something like `enumTemplateDispatch!foo(detectBOM(buffer), ))`. I have used EnumMembers a few times and it definitely saved me the hassle of writing the switch myself. However, in this case, isn't there a mapping between enums and types that one still needs to specify? That is: ( UTF8=>char[], UTF16=>wchar[], UTF32=>dchar[] ).
Re: forum.dlang.org is now available via HTTPS
On Wednesday, 20 January 2016 at 18:36:12 UTC, Vladimir Panteleev wrote: It took a while but I finally got around to adapting a Let's Encrypt ACME client to my hosting system with automatic renewals etc. Enjoy! https://forum.dlang.org/ Adam, your turn! Any reason for not forcing https?
Re: Compile-Time RNG
On Thursday, 21 January 2016 at 01:49:27 UTC, Timon Gehr wrote: On 01/21/2016 01:32 AM, tsbockman wrote: On Wednesday, 20 January 2016 at 23:21:04 UTC, CTRNG wrote: Just thought this might be of interest to some of you here. That's clever (and devious). It only works because compile-time introspection is ill-defined though. I don't expect it to keep working indefinitely. Hmm it does seem having an RNG during compile-time would be useful, although I'm trying to come up with a use-case for when it would actually work, or how you'd use it.
Re: Choosing D over C++, Go, Rust, Swift
On Thu, 2016-01-21 at 09:05 +, Markus via Digitalmars-d wrote: > From my point of view is the biggest disadvantage in D marketing, > that D is only placed as a "systems programming language". The > fact is, that D is very usable for numeric and large scale data > processing -- so called business software -- but if a manager > takes a look on the D homepage he will only see: "D is a systems > programming language..." This is also Go and Rust's problem. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: JMH
On Wed, 2016-01-20 at 21:05 +, Robert burner Schadek via Digitalmars-d wrote: > Yes, something like that would be nice. But as the website states > you need to use maven to build the project that uses that library. Or Gradle. (Technically: or Ant, or Gant, but hopefully the number of people using Ant is tending to zero very rapidly, and the number of Gant users is already 1.) > I can only suspect, but I think they use maven to collect all > functions that use @Benchmark. And this leads to the problem the > unittest library proposal for phobos had. No that is the job of the Java compiler. Gradle/Maven is just the dependency manager and build system. Think Dub. > The problem was that the user had to create a custom main that > listed all modules to check for tests or use a build tool with > some globbing commands. Both not perfect. I'll check this, I thought there was a "run everything" mode avoiding the need for custom suites. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: So... add maxCount and maxPos?
On Thursday, 21 January 2016 at 01:11:19 UTC, Andrei Alexandrescu wrote: On 01/20/2016 04:22 PM, Ivan Kazmenko wrote: 2. The index of minimum or maximum element, mostly using plain array as a range. I write "a.length - a.minPos.length", and it looks completely unintuitive. Additionally, when compiling to 64 bits, I usually still want an int to use with other ints around (longs are overkill most of the time), and the cast adds more clobber. Again, is there a better way to express that? No better way currently. We could add (min|max)Index but I like (min|max)Pos quite a bit. They offer more flexibility for non-random access ranges. But (min|max)(Index|Key) offer different type of flexibility as those make sense for associative containers.
Re: extern(C++, ns)
On 21/01/2016 9:15 AM, Walter Bright wrote: On 1/20/2016 8:38 AM, Marc Schütz wrote: IMO his description was already quite clear, but here you are: What's missing is why this is a *serious* problem. All you've got to do is add a qualifier. The *serious* problem is that the added scope does not appear to add practical value, yet has a non-zero cost. And yes I've seen your example with two same-named symbols in the same module, but I really don't understand why *that* is a serious problem that the namespace scope is worth introducing to solve. And I am not personally arguing for D modules mapping to C++ namespaces - the alternative feature I have in mind is extern(C++, "namespace") affecting mangling and *nothing else*.
Re: Compile-Time RNG
On Thursday, 21 January 2016 at 07:43:13 UTC, tsbockman wrote: On Thursday, 21 January 2016 at 01:49:27 UTC, Timon Gehr wrote: It only works because compile-time introspection is ill-defined though. I don't expect it to keep working indefinitely. That aspect can easily be replaced by __LINE__ and __FILE__. A supported way to generate new names at compile time would be nice.
Re: Choosing D over C++, Go, Rust, Swift
From my point of view is the biggest disadvantage in D marketing, that D is only placed as a "systems programming language". The fact is, that D is very usable for numeric and large scale data processing -- so called business software -- but if a manager takes a look on the D homepage he will only see: "D is a systems programming language..." Regards Markus
