Re: Accessing COM Objects

[Inquie via Digitalmars-d-learn]

On Friday, 17 June 2016 at 08:09:42 UTC, John wrote:
On Wednesday, 15 June 2016 at 21:06:01 UTC, Joerg Joergonson 
wrote:
My thinking is that CoCreateinstance is suppose to give us a 
pointer to the interface so we can use it, if all this stuff 
is crashing does that mean the interface is invalid or not 
being assigned properly or is there far more to it than this?


The problem is Photoshop hasn't provided an interface with 
methods that can be called directly. They don't exist on the 
interface, hence them being commented out. It's a mechanism 
known as late binding (everything is done at runtime rather 
than compile time). You need to ask the interface for the 
method's ID, marshal the parameters into a specific format, and 
then "invoke" the method using that ID.


And you're not going to like it. Here's an example just to call 
the "Load" method:


  // Initialize the Photoshop class instance
  IDispatch psApp;
  auto iid = IID__Application;
  auto clsid = CLSID_Application;
  assert(SUCCEEDED(CoCreateInstance(, null, CLSCTX_ALL, 
, cast(void**;

  scope(exit) psApp.Release();

  // Get the ID of the Load method
  auto methodName = "Load"w.ptr;
  auto dispId = DISPID_UNKNOWN;
  iid = IID_NULL;
  assert(SUCCEEDED(psApp.GetIDsOfNames(, , 1, 0, 
)));


  // Put the parameters into the expected format
  VARIANT fileName = {
vt: VARENUM.VT_BSTR,
bstrVal: SysAllocString("ps.psd"w.ptr)
  };
  scope(exit) VariantClear();

  DISPPARAMS params = {
rgvarg: ,
cArgs: 1
  };

  // Finally call the method
  assert(SUCCEEDED(psApp.Invoke(dispId, , 0, 
DISPATCH_METHOD, , null, null, null)));


tlb2d only outputs the late-bound methods as a hint to the user 
so they know the names of the methods and the expected 
parameters (well, it saves looking them up in OleView). Had 
Photoshop supplied a compile-time binding, you could have just 
called psApp.Load(fileName) like you tried.


It's possible to wrap that ugly mess above in less verbose code 
using native D types, and the Juno COM library mentioned 
earlier enabled that, but the code is quite ancient (and is 
part of and depends on a larger library). I've been slowly 
working on a more modern library. You'd be able to just write 
this:


  auto psApp = makeReference!"Photoshop.Application"();
  psApp.Load("ps.psd");

But I don't know when it'll be ready.


So, I was playing around with this method and was able to get 
things to work. Have you been able to automate this properly? 
Seems like if we have the interface and methods, we can create an 
implementation that automates the above marshaling and stuff 
automatically using reflection?


e.g., give

interface _Application : IDispatch {
...
  /*[id(0x4C64536C)]*/ void Load(BSTR Document);
...
  /*[id(0x71756974)]*/ void Quit();
...
}

it shouldn't be too hard to generate a class like

Generated code:

class PSAppication : _Application
{
...
void Load(BSTR Document)
{
   // The invoking and marshaling code automatically 
generated //

}
...
void Quit()
{
   // The invoking and marshaling code automatically 
generated //

}

...
}

? I assume this is what you said you were working on, more or 
less? Would be awesome if you already had this up and running! If 
not, I guess I'll try to implement something like it ;/



If you haven't worked on this, I have a few questions for ya:

1. Do we have to cocreateinit every time or can we just do it 
once? Seems like it could be a major performance issue if we have 
to call it each time?


2. Marshaling the paramters seems like it could be tricky as we 
would have to know each case? Scanning the photoshop idl file 
suggests there are many different parameter and return 
types(strings, ints, VARIANT_BOOL, com interfaces, enum, etc).


A few are easy to handle and you showed how to handle strings, 
but some of the others I wouldn't know how to do.


3. Does the juno code handle this well enough to copy and paste 
most of the labor?


4. Any pitfalls to worry about?

Thanks.

Re: Accessing COM Objects

[Inquie via Digitalmars-d-learn]

On Friday, 17 June 2016 at 08:09:42 UTC, John wrote:
On Wednesday, 15 June 2016 at 21:06:01 UTC, Joerg Joergonson 
wrote:

[...]


The problem is Photoshop hasn't provided an interface with 
methods that can be called directly. They don't exist on the 
interface, hence them being commented out. It's a mechanism 
known as late binding (everything is done at runtime rather 
than compile time). You need to ask the interface for the 
method's ID, marshal the parameters into a specific format, and 
then "invoke" the method using that ID.


[...]



Any news on this? I'd like to do some photoshop programming in D 
too but it seems like a mess?!?

Re: Rename 'D' to 'D++'

[Ola Fosheim Grostad via Digitalmars-d]

On Friday, 10 March 2017 at 23:00:16 UTC, XavierAP wrote:
IMHO... Only from a typical C++ centric perspective can it be 
claimed that C++11 and higher have not copied (not from D which 
was most of the time not first).


Neither C++ or D have any significant original features.

the first. And everything can be called "syntactic sugar" over 
assembly, nay machine code.


This isn't right though. Modern C++ has added some semantic 
additions and adjustments to enable new patterns (or stricter 
typing).


And yes often D has implemented them first, which can only be 
blamed on C++ itself. C++ was designed to be


Not sure what you mean. Features are proposed decades before they 
get standardized and gets implemented as experimental features as 
well, often years before. In general a standardization process 
expects multiple independent implementations to exist before 
acceptance...


time it could be kicked only with the approval of an ISO 
committee.


Not really, there are multiple non standard features in all the 
C++ compilers and people use them. Each of those compilers are 
more widespread than D, so if you want a fair conparison you'd 
have to compare the dialects and not an ISO standard (which 
always will be a shared subset of the implementations)

Re: [Tidbit] making your D code more modular & unittestable

[Walter Bright via Digitalmars-d]

On 3/8/2017 1:34 PM, H. S. Teoh via Digitalmars-d wrote:

[...]


Bingo.

If your algorithmic code includes code to read / write files, that's a big sign 
things are not properly encapsulated in the code.


Using ranges is a great way to accomplish this, and as you discovered, a bonus 
is that the range can be replaced with an array for easy unit testing.

Re: Comparing Instances of Classes

[DRex via Digitalmars-d-learn]

On Friday, 10 March 2017 at 20:27:09 UTC, Meta wrote:

On Friday, 10 March 2017 at 17:08:42 UTC, Whatsthisnow wrote:
I guess i am just too used to the java way of x.equals(object) 
which at the source  is exactly 'return this == object'


Java would return false here too, though, if it actually did 
`this == object` in its default compare method. If I remember 
correctly, comparing two objects with == in Java compares their 
addresses, not their contents.


I must be losing my mind then

Re: From the D Blog: Editable and Runnable Doc Examples on dlang.org

[Joakim via Digitalmars-d-announce]

On Wednesday, 8 March 2017 at 22:16:56 UTC, Seb wrote:

On Wednesday, 8 March 2017 at 20:12:51 UTC, Joakim wrote:

On Wednesday, 8 March 2017 at 13:24:15 UTC, Mike Parker wrote:
Sebastian Wilzbach lays out how the new editable & runnable 
documentation examples came to be.


The blog:
https://dlang.org/blog/2017/03/08/editable-and-runnable-doc-examples-on-dlang-org/

Reddit:
https://www.reddit.com/r/programming/comments/5y7umk/editable_and_runnable_doc_examples_on_dlangorg/


Nice writeup.  One issue: if I change the values in the test 
arrays for the linked example, it usually doesn't compile 
anymore.  I noticed this when this feature was first 
announced, but forgot to mention it then.


Other than that, nice work, especially with the writeln 
rewriting to show the output.


Thanks for the kind feedback.
Could you please explain the bit of the not-compiling examples 
again?

(it works for me)


If I go to the linked minElement example, click Edit, delete the 
1 in the first example and replace it with a 5 or 7, and hit Run, 
I fairly consistently get a compilation error about not expecting 
a ",".  It doesn't fail every time, but most of the time.


I'm doing this from an Android device: could it be some mobile 
text input issue?  Let me know if you can reproduce.

Re: DMD win32.mak error

[Paul D Anderson via Digitalmars-d-learn]

On Saturday, 11 March 2017 at 00:34:03 UTC, Paul D Anderson wrote:

On Friday, 10 March 2017 at 22:04:23 UTC, Paul D Anderson wrote:
While building DMD -- "make -fwin32.mak release" -- I received 
the following error message:


echo "2.073.2" > verstr.h
Error: don't know how to make '../res/default_ddoc_theme/ddoc'
--- error level 1

I'm guessing it might be a build configuration problem on my 
end, but what is the problem?


Paul


I see John Colvin has already filed a bug report (issue 17165) 
addressing this. Apparently the missing file is available on 
GitHub.


I copied the missing file John referenced to my src/dmd file but 
this did not have any effect.


I've created a bug report (17253) addressing this problem.

Paul

[Issue 17253] New: dmd win32.mak error in 2.073.2

[via Digitalmars-d-bugs]

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

  Issue ID: 17253
   Summary: dmd win32.mak error in 2.073.2
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: paul.d.ander...@comcast.net

I downloaded the latest D version (2.073.2) to my Windows 10 computer, and
issued the following commands in a terminal window:

set DM_HOME=C:\D
cd %DM_HOME%\dmd2\src\dmd
set HOST_DC=dmd
make -fwin32.mak release

The following error is generated:

echo "2.073.2" > verstr.h
Error: don't know how to make '../res/default_ddoc/theme.ddoc'

John Colvin created a related issue 17165, indicating that a the
../res/default_ddoc_theme.ddoc file was missing from the download. I copied the
file to my the dmd2\src\dmd directory but this had no effect.

There was a recent pull request (#6580) to dmd, which seems to be the source of
a change in the line (line no. 167) in the win32.mak file. I don't know if this
is the ultimate cause of the error.

--

Re: DMD + Dynamic Library.

[Cassio Butrico via Digitalmars-d-learn]

On Wednesday, 8 March 2017 at 18:21:35 UTC, Damien Gibson wrote:

On Wednesday, 8 March 2017 at 06:28:47 UTC, Jerry wrote:
You have to use "export" for any symbol to be visible from a 
dll. On Windows by default nothing is exported.


Would "export" and "export extern(D):" not be the same? Im 
confuseled..


You have to use


extern (C) {
 import std.stdio;
export{

void dllprint() {
writeln("\nmydll.dll read ok!!!\n");
}

int Myadd(int x, int y) {
return x + y;
}

}
}

Re: opIndex() may hide opSlice()

[Jonathan M Davis via Digitalmars-d]

On Friday, March 10, 2017 14:07:59 H. S. Teoh via Digitalmars-d wrote:
> On Fri, Mar 10, 2017 at 12:36:35PM -0800, Jonathan M Davis via 
Digitalmars-d wrote:
> > I can certainly understand that there are folks who really do care
> > about this stuff, but it's completely outside of what I deal with, and
> > for anything I've ever dealt with, making opIndex be for _slicing_
> > makes no sense whatsoever, and the added functionality to the language
> > with regards to multi-dimensional arrays is useless. So, this whole
> > mess has always felt like I've had something nonsensical thrown at me
> > because of a use case that I don't even properly understand.
>
> Please don't denigrate something as useless without at least trying to
> understand it first.

As I said, for what _I_ deal with, it's useless. It's obviously useful to
some subset of programmers - particularly folks doing scientific stuff based
on what I've seen about posts about multi-dimensional arrays - but it's
useless to me. I did not mean to denigrate anything, so sorry if that wasn't
clear. My point is that I don't want to have to worry about it or be
affected by it when it is useless to me - particularly when I'd have to
spend some time studying it to understand it properly. About the only time
I've dealt with matrices in any real way was when I took linear algebra, and
I've forgotten almost everything from that class. It simply has nothing to
do with anything that I've ever needed to program, and I'd just as soon
avoid any kind of math that would require it. So, as long as the
multi-dimensional slicing stuff sits in its own little corner of the
language where I don't have to deal with it, I'm fine. I just want to keep
using opSlice for slicing and opIndex for indexing, because that makes sense
to me and my needs, whereas using opIndex for a slicing operation just seems
wrong, much as it apparently has a benefit for generic code dealing with
multi-dimensional indexing and slicing.

And as long as the current situation with opSlice working for slicing like
it always has continues, I don't care what the subset of programmers who
care about multi-dimensional arrays do with opIndex. Unfortunately, it comes
up periodically that someone pushes for everything to change to use opIndex
for slicing or even to deprecate opSlice for slicing even when the code has
nothing to do with multi-dimensional indexing or slicing, and I do object to
that. If no multi-dimensional indexing or slicing is involved, I think that
opSlice should be used for slicing, not opIndex. Fortunately though, there
hasn't been a real push to move everything to use opIndex instead of opSlice
and get rid of the original behavior, and I hope that that stays the case.

Regardless, thank you for your thorough explanation as to why it was changed
so that opIndex could be used for a slicing operation.

- Jonathan M Davis

Re: DMD win32.mak error

[Paul D Anderson via Digitalmars-d-learn]

On Friday, 10 March 2017 at 22:04:23 UTC, Paul D Anderson wrote:
While building DMD -- "make -fwin32.mak release" -- I received 
the following error message:


echo "2.073.2" > verstr.h
Error: don't know how to make '../res/default_ddoc_theme/ddoc'
--- error level 1

I'm guessing it might be a build configuration problem on my 
end, but what is the problem?


Paul


I see John Colvin has already filed a bug report (issue 17165) 
addressing this. Apparently the missing file is available on 
GitHub.

Re: Rename 'D' to 'D++'

[XavierAP via Digitalmars-d]

On Friday, 10 March 2017 at 20:31:59 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 10 March 2017 at 19:53:52 UTC, Ali Çehreli wrote:

- constexpr (a poor man's CTFE)
- Type inference
- Range-based for
- Lambdas


As far as I can tell C++11 was mostly an absorption of existing 
practices, largely syntactical in nature. Lambdas are only 
syntactical sugar over function objects (which  in turn is a 
weak version of Beta patterns, a language Bjarne most certainly 
knew of as he has complained about someone running off with his 
book on the language and the fact  that he shows a lot of 
respect for Kristen Nygaard). The for loop was pure syntactical 
sugar over STL iterators, on the level of a C-macro...


IMHO... Only from a typical C++ centric perspective can it be 
claimed that C++11 and higher have not copied (not from D which 
was most of the time not first). The fact that these features are 
theorized outside of languages doesn't mean that the last 
language to implement them can claim the same originality as the 
first. And everything can be called "syntactic sugar" over 
assembly, nay machine code.
Even C# had lambdas, type inference, some constant folding etc 
etc years before C++


D has copied these from other languages/theories as well, but the 
language has been designed from the beginning to accommodate 
them. And yes often D has implemented them first, which can only 
be blamed on C++ itself. C++ was designed to be a superset of C 
including pre-processor, without any foresight, and the can has 
been kicked down the road since -- and each time it could be 
kicked only with the approval of an ISO committee.

Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

[H. S. Teoh via Digitalmars-d]

On Fri, Mar 10, 2017 at 09:07:36PM +, XavierAP via Digitalmars-d wrote:
> On Friday, 10 March 2017 at 19:02:06 UTC, H. S. Teoh wrote:
[...]
> > AFAIK Walter's stance is that overloading operators with semantics
> > other than generalizations of arithmetic operators are a bad idea.
> > This is why D uses opCmp for overloading <, <=, ==, >=, >, instead
> > of one overload per operator like C++ has.  Separately overloading <
> > and <=, for example, means that the programmer can do truly weird
> > things with it, which makes code hard to read (when you see "a < b"
> > and "a <= b", you have no idea what they *really* mean).
> 
> * D does not use opCmp for == but I'm sure it slipped your tongue ;)

Haha, you got me there. :-P

But in fact, the very fact that == is handled by opEquals and
inequalities are handled by opCmp has led to some amount of debate some
time ago, because it's possible for them to be inconsistent with each
other.  (Sorry, I'm too lazy to look up the thread right now, but you
can search the forum archives for the (rather lengthy!) discussion.)
This goes to show that overloading individual operators separately from
other related operators can eventually become a source of problems.


> I agree with that stance on style myself, and also with the hard
> restriction to keep the (in)equality and comparison operators
> consistent with each other. But the question is whether to restrict
> programmers further with no other reason than style. D's philosophy is
> maximum @system freedom (just like C/C++) within sanity.
> 
> Also operator overloading style may depend on each engineer's
> background.  Walter's education is mechanical engineering and
> mathematics (coincidentally just like myself), so he dislikes usage of
> operators not analogous to algebra or set theory. Me too; beyond that
> I would rather create methods with self-documenting names.
> 
> But there are software engineers and computer scientists who don't
> care about math, and they may even love iostream's "arrows" indicating
> the direction of the "stream". Leaving aside the specific example of
> iostream, this style discussion is not one where anyone can prove or
> claim to be right. Live and let live.

It's not only about style or math, though.  You may or may not have
encountered lovely C++ snippets like this one:

int x, y, bitmask;
cout << x & bitmask << y;   // what do you think this does?
// vs. what it actually does?

The problem is that "<<" was designed to be a bit-shift operator, and as
such it has a specific precedence level in the hierarchy of operators.
Overloading it to mean something completely unrelated like "output" may
not give it a "sensible" precedence relative to its new meaning. You end
up needing to add parentheses everywhere just to be sure (unless you can
memorize the entire C/C++ operator precedence chart -- I can't).

Operators also have their own associativity according to their intended
semantics; this can make code that abuse operator overloading outside
its intended usage quite unreadable, if the built-in associativity
doesn't match its new meaning.

Basically, operator syntax is just too specific to the arithmetical
meanings of the operators that overloading them to mean something else
seems like just asking for trouble.


T

-- 
The volume of a pizza of thickness a and radius z can be described by the 
following formula: pi zz a. -- Wouter Verhelst

Re: opIndex() may hide opSlice()

[H. S. Teoh via Digitalmars-d]

On Fri, Mar 10, 2017 at 12:36:35PM -0800, Jonathan M Davis via Digitalmars-d 
wrote:
> On Friday, March 10, 2017 10:43:43 H. S. Teoh via Digitalmars-d wrote:
[...]
> Well, thanks for the explanation, but I'm sure that part of the
> problem here is that an operation like arr[x, y..z] doesn't even make
> sense to me. I have no idea what that does.

That's a subdimensional slice. In this case, we're dealing with a 2D
array -- you can think of it as a matrix -- and extracting the y'th to
z'th elements from column x.  Conversely, arr[x..y, z] extracts the x'th
to y'th elements from row z.  This kind of subdimensional slicing is
pretty common when you work with things like tensors.


> But I don't normally do anything with multidimensional arrays, and in
> the rare case that I do, I certainly don't need to overload anything
> for them. I just slap together a multidimensional array of whatever
> type it is I want in a multidimensional array.

If by "multidimensional arrays" you mean arrays of arrays, then I can
understand your sentiment.

But when dealing with high-dimensional tensors, storing them explicitly
may not always be the best approach. Think sparse matrices, for example.
You want to be able to provide array indexing / slicing operations to
user types apart from the built-in arrays.

Not to mention that there are many problems with using arrays of arrays
as "multidimensional" arrays, besides storage issues. One being that you
can't easily represent a slice of an array of arrays across the minor
dimension (i.e., a slice of every i'th element of each array in an
int[][]).  For things like that, you *really* want to be able to write
arr[x, y..z] and arr[x..y, z] rather than arr[x][y..z] and arr[x..y][z].
Doing it the latter way means you need to implement arr.opSlice that
returns a proxy type that implements opIndex.  Kenji's design allows you
to implement all of these cases (and more) by just implementing a single
type with a single opSlice and single opIndex, and no proxy types, to
boot. It's clean and elegant.


> I can certainly understand that there are folks who really do care
> about this stuff, but it's completely outside of what I deal with, and
> for anything I've ever dealt with, making opIndex be for _slicing_
> makes no sense whatsoever, and the added functionality to the language
> with regards to multi-dimensional arrays is useless. So, this whole
> mess has always felt like I've had something nonsensical thrown at me
> because of a use case that I don't even properly understand.

Please don't denigrate something as useless without at least trying to
understand it first.


[...]
> Well, I'd prefer that the original way be left, since that's all I've
> ever needed. If the new way makes life easier for the scientific
> programmers and whatnot, then great, but from the standpoint of anyone
> not trying to provide multi-dimensional overloads, using opIndex for
> slicing is just plain bizarre.

Actually, it's the distinction between opSlice and opIndex in the old
scheme that's what's bizarre. It's like saying that to implement
userType(x) you need to declare userType.opSingleArgCall and to
implement userType(x,y) you need to declare userType.opTwoArgCall, just
because there happens to be 2 arguments instead of 1.  Why not just
unify the two under a single opCall, just with two overloads depending
on what arguments you want to pass to it?

In the same vein, requiring two different methods to implement arr[x]
vs. arr[x..y] is bizarre.  They should be unified under a single method
-- I don't care what you call it, maybe opIndex is a bad name because it
gives the wrong connotation for what it does, maybe it should be named
opSquareBrackets or something. But the point is that this distinction
between how arr[x] and arr[x..y] are handled is artificial and needless,
and does not easily generalize to higher dimensions.  Kenji's design is
far superior.


> That being said, I'm fine with the compiler detecting if opIndex and
> opSlice are declared in a way that they conflict and then giving an
> error. I just don't want to be forced to use opIndex for slicing.
[...]

Nobody is forcing you to use opIndex for slicing right now, because the
compiler currently accepts the old syntax for 1-dimensional arrays. And
I already said it's probably a bad idea to deprecate the old syntax.


T

-- 
What do you mean the Internet isn't filled with subliminal messages? What about 
all those buttons marked "submit"??

DMD win32.mak error

[Paul D Anderson via Digitalmars-d-learn]

While building DMD -- "make -fwin32.mak release" -- I received 
the following error message:


echo "2.073.2" > verstr.h
Error: don't know how to make '../res/default_ddoc_theme/ddoc'
--- error level 1

I'm guessing it might be a build configuration problem on my end, 
but what is the problem?


Paul

Re: TLS

[sarn via Digitalmars-d-learn]

On Friday, 10 March 2017 at 19:24:29 UTC, bauss wrote:
Mark your variables with __gshared. I would say shred, but it 
has some restrictions to it, where __gshared is the equivalent 
to global variables in C.


immutable variables are also not put in TLS.

Re: opIndex() may hide opSlice()

[XavierAP via Digitalmars-d]

On Friday, 10 March 2017 at 20:36:35 UTC, Jonathan M Davis wrote:


problem here is that an operation like arr[x, y..z] doesn't 
even make sense to me. I have no idea what that does.


https://www.mathworks.com/help/matlab/math/matrix-indexing.html#f1-85544

You can stop reading as soon as it starts talking about "linear 
indexing". However if you're also curious what that means: 
https://www.mathworks.com/help/matlab/math/matrix-indexing.html#f1-85511

Re: CTFE Status 2

[Nordlöw via Digitalmars-d]

On Friday, 10 March 2017 at 11:32:14 UTC, Stefan Koch wrote:
Also work is underway to finally support slicing, which is 
crucial to using phobos algorithms.


Incredible diligence.

Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

[XavierAP via Digitalmars-d]

On Friday, 10 March 2017 at 19:02:06 UTC, H. S. Teoh wrote:
On Fri, Mar 10, 2017 at 07:47:43AM +, XavierAP via 
Digitalmars-d wrote:

On Thursday, 9 March 2017 at 15:42:22 UTC, qznc wrote:

[...]
> Maybe we want to support weird DSLs, where operators are 
> reused with very different semantics? For example, the 
> pyparsing parser generator allows you to write a grammar 
> like [0] this:


Maybe... I usually hate that stuff a-la-C++ iostream but, 
inverting the question, do you want to disallow it?


AFAIK Walter's stance is that overloading operators with 
semantics other than generalizations of arithmetic operators 
are a bad idea.  This is why D uses opCmp for overloading <, 
<=, ==, >=, >, instead of one overload per operator like C++ 
has.  Separately overloading < and <=, for example, means that 
the programmer can do truly weird things with it, which makes 
code hard to read (when you see "a < b" and "a <= b", you have 
no idea what they *really* mean).


* D does not use opCmp for == but I'm sure it slipped your tongue 
;)


I agree with that stance on style myself, and also with the hard 
restriction to keep the (in)equality and comparison operators 
consistent with each other. But the question is whether to 
restrict programmers further with no other reason than style. D's 
philosophy is maximum @system freedom (just like C/C++) within 
sanity.


Also operator overloading style may depend on each engineer's 
background. Walter's education is mechanical engineering and 
mathematics (coincidentally just like myself), so he dislikes 
usage of operators not analogous to algebra or set theory. Me 
too; beyond that I would rather create methods with 
self-documenting names.


But there are software engineers and computer scientists who 
don't care about math, and they may even love iostream's "arrows" 
indicating the direction of the "stream". Leaving aside the 
specific example of iostream, this style discussion is not one 
where anyone can prove or claim to be right. Live and let live.

[Issue 16642] byCodeUnit doesn't work AutodecodableStrings unless they're actually strings or alias a variable that's a string

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/6e3d41cfe92d0af0360002db6436d2ec98f503af
Fix issue 16642: byCodeUnit doesn't work properly with alias this.

If a template is going to allow implicit conversions, it really needs to
force the conversion in order to avoid subtle bugs. This fixes
byCodeUnit so that it forces the conversion to a string type for types
that convert implicitly. It also fixes it so that types which implicitly
convert to a string type but are also ranges of characters without the
conversion will not be converted by byCodeUnit.

https://github.com/dlang/phobos/commit/13b3da64a81360e96bab3d1bb09a3a42b751da36
Merge pull request #4879 from jmdavis/issue_16642

Fix Issue 16642  - byCodeUnit doesn't work properly with alias this.

--

Re: opIndex() may hide opSlice()

[Jonathan M Davis via Digitalmars-d]

On Friday, March 10, 2017 10:43:43 H. S. Teoh via Digitalmars-d wrote:
> On Fri, Mar 10, 2017 at 07:41:31AM -0800, Jonathan M Davis via 
Digitalmars-d wrote:
> > On Friday, March 10, 2017 14:15:45 Nick Treleaven via Digitalmars-d 
wrote:
> > > On Friday, 10 March 2017 at 01:10:21 UTC, H. S. Teoh wrote:
> [...]
>
> > > > Using opSlice() for slicing (i.e., arr[]) is old,
> > > > backward-compatible behaviour.
> > >
> > > This seems non-intuitive to me (at least for single dimension
> > > containers) - when you see var[], do you think var is being
> > > indexed or do you think var is being sliced like an array
> > > (equivalent to var[0..$])?
> >
> > Yeah, I've never understood how it made any sense for opIndex to be
> > used for slicing, and I've never used it that way.
>
> It's very simple, really.  Under the old behaviour, you have:
>
>   arr[]   --->arr.opSlice()
>   arr[x]  --->arr.opIndex(x)
>   arr[x..y]   --->arr.opSlice(x,y)
>
> This made implementing higher-dimensional slicing operators hard to
> define, especially if you want mixed slicing and indexing (aka
> subdimensional slicing):
>
>   arr[x, y]   --->arr.opIndex(x, y)
>   arr[x, y..x]--->?
>   arr[x..y, z]--->?
>   arr[w..x, y..z] --->arr.opSlice(w, x, y, z)  // ?
>
> Kenji's insight was that we can solve this problem by homogenizing
> opSlice and opIndex, such that [] *always* translates to opIndex, and ..
> always translates to opSlice.
>
> So, under the new behaviour:
>
>   arr[]   --->arr.opIndex()
>   arr[x]  --->arr.opIndex(x)
>   arr[x,y]--->arr.opIndex(x,y)
>
>   arr[x..y]   --->arr.opIndex(arr.opSlice(x,y))
>   arr[x, y..z]--->arr.opIndex(x, arr.opSlice(y,z))
>   arr[x..y, z]--->arr.opIndex(arr.opSlice(x,y), z)
>
> This allows mixed-indexing / subdimensional slicing to consistently use
> opIndex, with opSlice returning objects representing index ranges, so
> that in a multidimensional user type, you could unify all the cases
> under a single definition of opIndex:
>
>   IndexRange opSlice(int x, int y) { ... }
>
>   auto opIndex(I...)(I indices)
>   {
>   foreach (idx; indices) {
>   static if (is(typeof(idx) == IndexRange))
>   {
>   // this index is a slice
>   }
>   else
>   {
>   // this index is a single index
>   }
>   }
>   }
>
> Without this unification, you'd have to implement 2^n different
> overloads of opIndex / opSlice in order to handle all cases of
> subdimensional slicing in n dimensions.
>
> So you can think of it simply as:
>
>   []  ==  opIndex
>   ..  ==  opSlice
>
> in all cases.
>
> It is more uniform this way, and makes perfect sense to me.

Well, thanks for the explanation, but I'm sure that part of the problem here
is that an operation like arr[x, y..z] doesn't even make sense to me. I have
no idea what that does. But I don't normally do anything with
multidimensional arrays, and in the rare case that I do, I certainly don't
need to overload anything for them. I just slap together a multidimensional
array of whatever type it is I want in a multidimensional array. I can
certainly understand that there are folks who really do care about this
stuff, but it's completely outside of what I deal with, and for anything
I've ever dealt with, making opIndex be for _slicing_ makes no sense
whatsoever, and the added functionality to the language with regards to
multi-dimensional arrays is useless. So, this whole mess has always felt
like I've had something nonsensical thrown at me because of a use case that
I don't even properly understand.

> > I generally forget that that change was even made precisely because it
> > makes no sense to me, whereas using opSlice for slicing makes perfect
> > sense. I always use opIndex for indexing and opSlice for slicing just
> > like they were originally designed.
>
> [...]
>
> This is probably why Kenji didn't deprecate the original use of opSlice,
> since for the 1-dimensional case the homogenization of opSlice / opIndex
> is probably unnecessary and adds extra work for the programmer: if you
> want to implement arr[x..y] you have to write both opSlice and an
> opIndex overload that accepts what opSlice returns, as opposed to just
> writing a single opSlice.
>
> So probably we should leave it the way it is (and perhaps clarify that
> in the spec), as deprecating the "old" use of opSlice in the
> 1-dimensional case would cause problems.

Well, I'd prefer that the original way be left, since that's all I've ever
needed. If the new way makes life easier for the scientific programmers and
whatnot, then great, but from the standpoint of anyone not trying to provide
multi-dimensional overloads, using opIndex for slicing is just plain
bizarre.

That being said, I'm fine with the compiler detecting if opIndex and opSlice
are declared in a way that they conflict and then giving an error. I just
don't want to be forced to use 

Re: Rename 'D' to 'D++'

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 10 March 2017 at 19:53:52 UTC, Ali Çehreli wrote:

- constexpr (a poor man's CTFE)
- Type inference
- Range-based for
- Lambdas


As far as I can tell C++11 was mostly an absorption of existing 
practices, largely syntactical in nature. Lambdas are only 
syntactical sugar over function objects (which  in turn is a weak 
version of Beta patterns, a language Bjarne most certainly knew 
of as he has complained about someone running off with his book 
on the language and the fact  that he shows a lot of respect for 
Kristen Nygaard). The for loop was pure syntactical sugar over 
STL iterators, on the level of a C-macro...



- (Not sure about D timeline here) Explicit overrides and final


Beta has it.


- Null pointer constant


Simula. Which C++ is a direct descendant of.

At this point it feels like copying almost the entire list so I 
stop. :)


Well, the only big thing in C++11 was standardization of 
ownership mechanisms and getting more compact syntax for function 
objects (lambdas).


The C++ language semantics didn't change much IMO. The idioms has 
changed a lot though. Although it isn't as visible in the 
codebases on github yet...

Re: Comparing Instances of Classes

[Meta via Digitalmars-d-learn]

On Friday, 10 March 2017 at 17:08:42 UTC, Whatsthisnow wrote:
I guess i am just too used to the java way of x.equals(object) 
which at the source  is exactly 'return this == object'


Java would return false here too, though, if it actually did 
`this == object` in its default compare method. If I remember 
correctly, comparing two objects with == in Java compares their 
addresses, not their contents.

Re: opIndex() may hide opSlice()

[jmh530 via Digitalmars-d]

On Friday, 10 March 2017 at 18:43:43 UTC, H. S. Teoh wrote:


So probably we should leave it the way it is (and perhaps 
clarify that in the spec), as deprecating the "old" use of 
opSlice in the 1-dimensional case would cause problems.




ndslice just recently added an indexed function
http://docs.algorithm.dlang.io/latest/mir_ndslice_topology.html#.indexed
that is like slicing based on some index. Other languages have 
something similar.


However, it's not something that's built-in in D. Thus, given the 
indexed example:


auto source = [1, 2, 3, 4, 5];
auto indexes = [4, 3, 1, 2, 0, 4].sliced;
auto ind = source.indexed(indexes);

there's way to instead write

auto source = [1, 2, 3, 4, 5];
auto indexes = [4, 3, 1, 2, 0, 4].sliced;
auto ind = source[indexes];

So to me, there does seem scope for some changes, even if they 
aren't the changes you mentioned in your post.

Re: Rename 'D' to 'D++'

[Ali Çehreli via Digitalmars-d]

On 03/10/2017 11:43 AM, Ola Fosheim Grøstad wrote:

On Friday, 10 March 2017 at 19:15:49 UTC, Ali Çehreli wrote:

C++11 was a big step forward for C++ that closed the gap with D. At
the time, it felt to me like they copied everything from D but now I
know that programming language ideas are everywhere and it's hard to
pinpoint who borrowed what from whom.


It is rather obvious that D2 leans heavily on pre-C++11... Not sure what
C++11 would have borrowed from D though.


Browsing here:

  https://en.wikipedia.org/wiki/C%2B%2B11

- constexpr (a poor man's CTFE)
- Type inference
- Range-based for
- Lambdas
- Ability to call constructors from constructors
- (Not sure about D timeline here) Explicit overrides and final
- Null pointer constant
- Strongly typed enumerations
- Explicit conversion operators
- Template aliases
- Variadic templates
- ...

At this point it feels like copying almost the entire list so I stop. :)

Ali

Re: Rename 'D' to 'D++'

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 10 March 2017 at 19:15:49 UTC, Ali Çehreli wrote:
C++11 was a big step forward for C++ that closed the gap with 
D. At the time, it felt to me like they copied everything from 
D but now I know that programming language ideas are everywhere 
and it's hard to pinpoint who borrowed what from whom.


It is rather obvious that D2 leans heavily on pre-C++11... Not 
sure what C++11 would have borrowed from D though.

Re: CTFE Status 2

[H. S. Teoh via Digitalmars-d]

On Fri, Mar 10, 2017 at 11:32:14AM +, Stefan Koch via Digitalmars-d wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> > [ ... ]
> 
> Time for an update.
> 
> I am currently working on integrating 64bit values into codegen API.
> However, a backend may not have native 64bit registers or arithmetic
> (the x86/arm architectures come to mind) For those a common fallback
> is to be implemented such that not every architecture has to implement
> their 64bit arithmetic on their own.

Makes sense to me.


> Also work is underway to finally support slicing, which is crucial to
> using phobos algorithms.

This is awesome news!  Glad to hear there's steady progress being made
on the new CTFE engine.  Can't wait for it to be done and merged into
master!  There are so many awesome things I wanna do with CTFE that
currently would be unacceptably slow.  Can't wait to take D compile-time
capabilities to a whole 'nother level!


T

-- 
"A one-question geek test. If you get the joke, you're a geek: Seen on a 
California license plate on a VW Beetle: 'FEATURE'..." -- Joshua D. Wachs - 
Natural Intelligence, Inc.

Re: Rename 'D' to 'D++'

[H. S. Teoh via Digitalmars-d]

On Fri, Mar 10, 2017 at 05:11:39PM +, Jack Stouffer via Digitalmars-d wrote:
[...]
> Only expect meaningful replies to threads with meaning.

As the geek would say:

ASCII stupid question, getty stupid ANSI.

:-D


T

-- 
EMACS = Extremely Massive And Cumbersome System

Re: Comparing Instances of Classes

[Ali Çehreli via Digitalmars-d-learn]

On 03/10/2017 08:22 AM, DRex wrote:


Error: function app.A.opEquals does not override any function, did you
mean to override 'object.Object.opEquals'?

My A class appears exactly as mentioned in your comment...


FWIW, here's some other info:

  http://ddili.org/ders/d.en/object.html#ix_object.opEquals

Ali

Re: TLS

[bauss via Digitalmars-d-learn]

On Friday, 10 March 2017 at 07:33:44 UTC, M-exe wrote:
On Friday, 10 March 2017 at 07:17:22 UTC, rikki cattermole 
wrote:

D does not support Windows XP.
If you absolutely require it, you will have to contact Walter 
about support.


Let me care about it ;)
I just need help with the TLS :)


Mark your variables with __gshared. I would say shred, but it has 
some restrictions to it, where __gshared is the equivalent to 
global variables in C.

Re: Rename 'D' to 'D++'

[Ali Çehreli via Digitalmars-d]

On 03/10/2017 10:48 AM, Bastiaan Veelo wrote:

> You say D is an expanded version of C++. I think it's more an expanded
> version of C, surpassing C++.

C++11 was a big step forward for C++ that closed the gap with D. At the 
time, it felt to me like they copied everything from D but now I know 
that programming language ideas are everywhere and it's hard to pinpoint 
who borrowed what from whom.


Regarding the name, I propose "1F44D  THUMBS UP SIGN" but it's not in 
common fonts yet. :o)


import std.stdio;

void main() {
// Repeat the character according to excitement level
writeln("D\U0001f44d");
}

Ali

Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

[H. S. Teoh via Digitalmars-d]

On Fri, Mar 10, 2017 at 07:47:43AM +, XavierAP via Digitalmars-d wrote:
> On Thursday, 9 March 2017 at 15:42:22 UTC, qznc wrote:
[...]
> > Maybe we want to support weird DSLs, where operators are reused with
> > very different semantics? For example, the pyparsing parser
> > generator allows you to write a grammar like [0] this:
> 
> Maybe... I usually hate that stuff a-la-C++ iostream but, inverting
> the question, do you want to disallow it?

AFAIK Walter's stance is that overloading operators with semantics other
than generalizations of arithmetic operators are a bad idea.  This is
why D uses opCmp for overloading <, <=, ==, >=, >, instead of one
overload per operator like C++ has.  Separately overloading < and <=,
for example, means that the programmer can do truly weird things with
it, which makes code hard to read (when you see "a < b" and "a <= b",
you have no idea what they *really* mean).

For DSLs, the official D recommendation is to use string mixins and CTFE
instead. This gives you the flexibility to use *any* syntax you want for
your DSL, including syntax that doesn't even fit in D syntax. You could
even implement Unicode operators.  CTFE lets you parse such strings at
compile-time and emit code for them via string mixins, so runtime
performance is not a concern.

And I would tend to agree: I find iostream's (ab)use of << and >> to
mean anything other than bitshifting very ugly and hard to read.  Look
at the Boost.Xpressive library for an even more extreme example of this.
(Though thankfully, they appear to be moving towards string DSLs by
taking advantage of the latest C++ features, so there is hope that this
will soon be just an ugly footnote in history.)

A long-standing item on my todo list is to implement compile-time
writefln format strings using this technique.  I don't even want to
imagine how ugly code will become if I were to do compile-time format
strings the C++ way by overloading arithmetic operators... imagine
format strings written using operators... Ugh!


T

-- 
He who sacrifices functionality for ease of use, loses both and deserves 
neither. -- Slashdotter

Re: opIndex() may hide opSlice()

[H. S. Teoh via Digitalmars-d]

On Fri, Mar 10, 2017 at 07:41:31AM -0800, Jonathan M Davis via Digitalmars-d 
wrote:
> On Friday, March 10, 2017 14:15:45 Nick Treleaven via Digitalmars-d wrote:
> > On Friday, 10 March 2017 at 01:10:21 UTC, H. S. Teoh wrote:
[...]
> > > Using opSlice() for slicing (i.e., arr[]) is old,
> > > backward-compatible behaviour.
> >
> > This seems non-intuitive to me (at least for single dimension
> > containers) - when you see var[], do you think var is being
> > indexed or do you think var is being sliced like an array
> > (equivalent to var[0..$])?
> 
> Yeah, I've never understood how it made any sense for opIndex to be
> used for slicing, and I've never used it that way.

It's very simple, really.  Under the old behaviour, you have:

arr[]   --->arr.opSlice()
arr[x]  --->arr.opIndex(x)
arr[x..y]   --->arr.opSlice(x,y)

This made implementing higher-dimensional slicing operators hard to
define, especially if you want mixed slicing and indexing (aka
subdimensional slicing):

arr[x, y]   --->arr.opIndex(x, y)
arr[x, y..x]--->?
arr[x..y, z]--->?
arr[w..x, y..z] --->arr.opSlice(w, x, y, z)  // ?

Kenji's insight was that we can solve this problem by homogenizing
opSlice and opIndex, such that [] *always* translates to opIndex, and ..
always translates to opSlice.

So, under the new behaviour:

arr[]   --->arr.opIndex()
arr[x]  --->arr.opIndex(x)
arr[x,y]--->arr.opIndex(x,y)

arr[x..y]   --->arr.opIndex(arr.opSlice(x,y))
arr[x, y..z]--->arr.opIndex(x, arr.opSlice(y,z))
arr[x..y, z]--->arr.opIndex(arr.opSlice(x,y), z)

This allows mixed-indexing / subdimensional slicing to consistently use
opIndex, with opSlice returning objects representing index ranges, so
that in a multidimensional user type, you could unify all the cases
under a single definition of opIndex:

IndexRange opSlice(int x, int y) { ... }

auto opIndex(I...)(I indices)
{
foreach (idx; indices) {
static if (is(typeof(idx) == IndexRange))
{
// this index is a slice
}
else
{
// this index is a single index
}
}
}

Without this unification, you'd have to implement 2^n different
overloads of opIndex / opSlice in order to handle all cases of
subdimensional slicing in n dimensions.

So you can think of it simply as:

[]  ==  opIndex
..  ==  opSlice

in all cases.

It is more uniform this way, and makes perfect sense to me.


> I generally forget that that change was even made precisely because it
> makes no sense to me, whereas using opSlice for slicing makes perfect
> sense. I always use opIndex for indexing and opSlice for slicing just
> like they were originally designed.
[...]

This is probably why Kenji didn't deprecate the original use of opSlice,
since for the 1-dimensional case the homogenization of opSlice / opIndex
is probably unnecessary and adds extra work for the programmer: if you
want to implement arr[x..y] you have to write both opSlice and an
opIndex overload that accepts what opSlice returns, as opposed to just
writing a single opSlice.

So probably we should leave it the way it is (and perhaps clarify that
in the spec), as deprecating the "old" use of opSlice in the
1-dimensional case would cause problems.


T

-- 
Chance favours the prepared mind. -- Louis Pasteur

Re: Rename 'D' to 'D++'

[Bastiaan Veelo via Digitalmars-d]

On Friday, 10 March 2017 at 15:16:56 UTC, Traktor TOni wrote:
D has chosen to use the naming scheme of C and as such it 
should be honest and use D++ because that's what D is: An 
expanded version of the former language.


"D is C++ done right", that used to be one of D's slogans. It 
doesn't mean that is sees itself as being branched off of C++ 
though. I see it as being branched off of C, with similar 
intentions as had Bjarne Stroustrup, but making better choices 
and thereby, arguably, taking a bigger leap forward. So, I think 
"D" fits perfectly, any "++" suffix makes no sense to me.


You say D is an expanded version of C++. I think it's more an 
expanded version of C, surpassing C++.

Re: Intellij D Language plugin v1.11 released

[singingbush via Digitalmars-d-announce]

On Friday, 10 March 2017 at 13:16:45 UTC, Martin Tschierschke 
wrote:

On Thursday, 9 March 2017 at 22:46:12 UTC, singingbush wrote:
the new build fixes compatibility issues with Intellij IDEA 
2016.3.* versions. It should be in the plugin repo soon but in 
meantime can be downloaded from


https://github.com/kingsleyh/DLanguage/releases


Looks nice! I have zero experience with  Intellij IDEA until 
now, so I installed it following the ubuntu wiki. Now one 
question do you know a way to support .dt (diet template files) 
for use with vibe.d?
I thought it should be possible to use a .pug plugin (former 
known as jade .js template engine) has anyone used it this way?


There's an open issue for supporting diet templates but it's not 
an immediate priority. I found using the jade plugin enough for 
my needs. See: https://github.com/kingsleyh/DLanguage/issues/94


You need to associate the .dt extension as being Jade

[Issue 17252] Invalid PATH variable in build script

[via Digitalmars-d-bugs]

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

Rainer Koschnick  changed:

   What|Removed |Added

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

--

[Issue 17252] New: Invalid PATH variable in build script

[via Digitalmars-d-bugs]

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

  Issue ID: 17252
   Summary: Invalid PATH variable in build script
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: visuald
  Assignee: nob...@puremagic.com
  Reporter: ar...@gmx.net

Somehow the PATH variable contains a garbage character which in turn leads to
an error message from OPTLINK.

This gets added to build.cmd:

set PATH=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin;C:\Program
Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE;C:\Program Files
(x86)\Windows Kits\8.1\bin\x86;D:\Dlang\dmd2\windowsin;%PATH%

D:\Dlang\dmd2\windowsin should actually be D:\Dlang\dmd2\windows\bin

--

Berlin D Meetup March 2017

[Ben Palmer via Digitalmars-d-announce]

Hi All,

The Berlin March D meetup is happening on Friday the 17th at 
19:30 at Berlin Co-Op (http://co-up.de/) on the fifth floor. This 
meetup features the return of Prof Brus to continue talking about 
game development.


"A followup to my previous talk, simply titled "Intro to game 
development". This talk will build on what we learned there, and 
we will go from having set up SDL bindings and a basic game loop, 
to building a proper game. Having attended the previous talk is 
not a requirement, but it will be helpful. The talk can also be 
found online here: https://www.youtube.com/watch?v=-mX6lIJqKhI;


As always we will have both alcoholic and non-alcoholic drinks 
available and time for discussions after the talk.


The meetup page is: 
https://www.meetup.com/Berlin-D-Programmers/events/238293017/


Thanks,
Ben.

Re: opIndex() may hide opSlice()

[Patrick Schluter via Digitalmars-d]

On Friday, 10 March 2017 at 15:41:31 UTC, Jonathan M Davis wrote:
On Friday, March 10, 2017 14:15:45 Nick Treleaven via 
Digitalmars-d wrote:

On Friday, 10 March 2017 at 01:10:21 UTC, H. S. Teoh wrote:
> On Fri, Mar 10, 2017 at 01:07:33AM +, XavierAP via
>
> Digitalmars-d wrote:
>> The web reference tersely says under its *Slice* Operator 
>> Overloading chapter [1]: "To overload a[], simply define 
>> opIndex with no parameters."

>>
>> Should not the overload of opSlice() with no arguments be
>> deprecated?
>> Am I missing something?
>
> Using opSlice() for slicing (i.e., arr[]) is old,
> backward-compatible
> behaviour.

This seems non-intuitive to me (at least for single dimension 
containers) - when you see var[], do you think var is being 
indexed or do you think var is being sliced like an array 
(equivalent to var[0..$])?


Yeah, I've never understood how it made any sense for opIndex 
to be used for slicing, and I've never used it that way. I 
generally forget that that change was even made precisely 
because it makes no sense to me, whereas using opSlice for 
slicing makes perfect sense. I always use opIndex for indexing 
and opSlice for slicing just like they were originally designed.


- Jonathan M Davis


Indexing is a bit like slicing with only 1 element. Slicing is 
the generalisation of the indexing operation. I think it's quite 
logical. This said I know nothing about the rationale and 
discussions about that subject. This was purely my wag (wild ass 
guess).

[Issue 17251] New: Appender.put errors out with const input range elements

[via Digitalmars-d-bugs]

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

  Issue ID: 17251
   Summary: Appender.put errors out with const input range
elements
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: slud...@outerproduct.org

The following snippet:
---
import std.array : appender;
static struct R {
int front() const { return 0; }
bool empty() const { return true; }
void popFront() {}
}
auto app = appender!(R[]);
const(R)[1] r;
app.put(r[0]);
app.put(r[]);
---

Results in:
---
Error: std.array.Appender!(R[]).Appender.put called with argument types
(const(R)) matches both:
array.d(2821,10):
std.array.Appender!(R[]).Appender.put!(const(R)).put(const(R) item)
and:
array.d(2849,10):
std.array.Appender!(R[]).Appender.put!(const(R)).put(const(R) items)
Error: template std.array.Appender!(R[]).Appender.put cannot deduce function
from argument types !()(const(R)[]), candidates are:
array.d(2821,10):std.array.Appender!(R[]).Appender.put(U)(U item) if
(canPutItem!U)
array.d(2849,10):std.array.Appender!(R[]).Appender.put(Range)(Range
items) if (canPutConstRange!Range)
array.d(2858,10):std.array.Appender!(R[]).Appender.put(Range)(Range
items) if (canPutRange!Range)
---

Putting non-const items on the other hand works fine.

--

Re: [Tidbit] making your D code more modular & unittestable

[bpr via Digitalmars-d]

On Friday, 10 March 2017 at 14:58:09 UTC, Nick Treleaven wrote:

On Thursday, 9 March 2017 at 20:54:23 UTC, Nick Sabalausky
Wishlist for D3: Some brilliant form of sugar for declaring a 
function that takes a range.


auto parseFile()(auto input if isRandomAccessRangeOf!ubyte && 
hasSlicing) {


My spin on an inline parameter constraint idea by Kenji (his 
doesn't use auto and also has more concept-like sugar):


https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint

As mentioned in the link, inline constraints can help make more 
specific error messages when constraints fail.


That looks like a useful DIP. What has to happen to move it to 
the DIP repository 
https://github.com/dlang/DIPs/blob/master/GUIDELINES.md ?

Re: Rename 'D' to 'D++'

[Jack Stouffer via Digitalmars-d]

On Friday, 10 March 2017 at 16:08:15 UTC, Traktor TOni wrote:

Please stop spamming my thread with joke responses.


When you play stupid games, you win stupid prizes.

"Hey everyone, why don't you completely abandon 15+ years of 
building your brand on the name D and change it to D++, which 
will inevitably lead to confusion by almost everyone? Why? 
Because I think you should!"


Simple answer: no.

Only expect meaningful replies to threads with meaning.

Re: Comparing Instances of Classes

[Whatsthisnow via Digitalmars-d-learn]

On Friday, 10 March 2017 at 16:47:47 UTC, Adam D. Ruppe wrote:

On Friday, 10 March 2017 at 16:36:17 UTC, DRex wrote:
I'm fairly new to D, but this seems to be quite a pain in the 
rear for a simple comparison of instances of classes...really 
odd that comparing instances of classes in D requires that 
messing around when D seems all about simplifying things...


There often is no sensible default comparison for class 
contents (now structs on the other hand do have a default 
comparison that usually works, but structs don't have to worry 
about polymorphism), so you just need to specify what fields 
actually matter to your code...


I guess i am just too used to the java way of x.equals(object) 
which at the source  is exactly 'return this == object'

Re: Comparing Instances of Classes

[Adam D. Ruppe via Digitalmars-d-learn]

On Friday, 10 March 2017 at 16:36:17 UTC, DRex wrote:
I'm fairly new to D, but this seems to be quite a pain in the 
rear for a simple comparison of instances of classes...really 
odd that comparing instances of classes in D requires that 
messing around when D seems all about simplifying things...


There often is no sensible default comparison for class contents 
(now structs on the other hand do have a default comparison that 
usually works, but structs don't have to worry about 
polymorphism), so you just need to specify what fields actually 
matter to your code...

Re: Comparing Instances of Classes

[DRex via Digitalmars-d-learn]

On Friday, 10 March 2017 at 16:30:00 UTC, Adam D. Ruppe wrote:

On Friday, 10 March 2017 at 16:22:18 UTC, DRex wrote:
Error: function app.A.opEquals does not override any function, 
did you mean to override 'object.Object.opEquals'?


Oh sorry, maybe I messed up the const. Try:

override bool opEquals(A rhs) { ... }


and if the compiler still complains change the A to Object and 
cast it inside (but I'm pretty sure that will work, I think it 
is just const it is picky about)


Thanks.

I'm fairly new to D, but this seems to be quite a pain in the 
rear for a simple comparison of instances of classes...really odd 
that comparing instances of classes in D requires that messing 
around when D seems all about simplifying things...

Re: Ocean v3.0.0: First fully public release!

[Andrea Fontana via Digitalmars-d-announce]

On Friday, 10 March 2017 at 15:19:51 UTC, Leandro Lucarella wrote:

Hi dear D community!

We wanted to share with you some nice news and big milestone: 
we are (finally!) going completely public with Ocean 
development!


From github page:
General purpose, platform-dependant, high-performance library for 
D


You missed it :)

Re: Comparing Instances of Classes

[Adam D. Ruppe via Digitalmars-d-learn]

On Friday, 10 March 2017 at 16:22:18 UTC, DRex wrote:
Error: function app.A.opEquals does not override any function, 
did you mean to override 'object.Object.opEquals'?


Oh sorry, maybe I messed up the const. Try:

override bool opEquals(A rhs) { ... }


and if the compiler still complains change the A to Object and 
cast it inside (but I'm pretty sure that will work, I think it is 
just const it is picky about)

Re: Rename 'D' to 'D++'

[Andrea Fontana via Digitalmars-d]

On Friday, 10 March 2017 at 14:29:27 UTC, Chris wrote:

According to Wikipedia, D was influenced by:

C, C++, C#, Eiffel, Java, Python (English version)
C, C++, Java, C#, Python, Ruby (Spanish and German version)


According to italian wikipedia instead:
C, C++, C#, Eiffel, Java, Python, Ruby

Re: opIndex() may hide opSlice()

[XavierAP via Digitalmars-d]

On Friday, 10 March 2017 at 14:15:45 UTC, Nick Treleaven wrote:


Also deprecating nullary opSlice() would work against defining 
opSlice(int low = 0, int high = length).


The same call [] can go to a variadic opIndex(T[] indices ...)

So many possibilities :_)

Re: Comparing Instances of Classes

[DRex via Digitalmars-d-learn]

On Friday, 10 March 2017 at 16:13:21 UTC, Adam D. Ruppe wrote:

On Friday, 10 March 2017 at 16:08:05 UTC, DRex wrote:

Am I missing something here?


Yeah, you need to implement a custom equality operator.

class A {
   int member;
   override bool opEquals(const A rhs) {
return this.member == rhs.member; // and other members 
that need to be equal

   }
}


The default opEquals sees if they are the same *instance* (same 
as `a is b`), and does not look at contents. You need to define 
that yourself.


I tried the above class A, and now the compiler fails with the 
following error:


Error: function app.A.opEquals does not override any function, 
did you mean to override 'object.Object.opEquals'?


My A class appears exactly as mentioned in your comment...

Re: Comparing Instances of Classes

[Adam D. Ruppe via Digitalmars-d-learn]

On Friday, 10 March 2017 at 16:08:05 UTC, DRex wrote:

Am I missing something here?


Yeah, you need to implement a custom equality operator.

class A {
   int member;
   override bool opEquals(const A rhs) {
return this.member == rhs.member; // and other members 
that need to be equal

   }
}


The default opEquals sees if they are the same *instance* (same 
as `a is b`), and does not look at contents. You need to define 
that yourself.

Re: opIndex() may hide opSlice()

[Adam D. Ruppe via Digitalmars-d]

On Friday, 10 March 2017 at 15:41:31 UTC, Jonathan M Davis wrote:
Yeah, I've never understood how it made any sense for opIndex 
to be used for slicing, and I've never used it that way.


Yeah, I just saw that yesterday in a Phobos type and was like 
"wtf did they misname it"... but it worked.


However, I can get used to it, [] going to opIndex() isn't really 
a stretch anyway, I would just like if it was better known and 
the compiler talked about it.

Re: Rename 'D' to 'D++'

[Traktor TOni via Digitalmars-d]

On Friday, 10 March 2017 at 15:33:14 UTC, Abdulhaq wrote:

On Friday, 10 March 2017 at 11:25:11 UTC, Traktor TOni wrote:
I think the name is just misleading, the D developers should 
at least be honest with themselves.


well the tractor derives from the shire horse and Toni comes 
from Antonius so you should be honest too and rename yourself 
to Shirehorse++ Antonius--.


Please stop spamming my thread with joke responses.

Comparing Instances of Classes

[DRex via Digitalmars-d-learn]

Hi,

I am trying to compare two instances of a class.  I created a 
test program to try this, but every method I use to compare the 
instances always returns false.


this is my code to test comparison

class A
{
this()
{

}
}

void main()
{
A a = new A();
A a2 = new A();

writeln(equals(a, a2));
}

bool equals(Object obj1, Object obj2)
{
return (obj1 is obj2);
}

I have tried 'a is a2', I have tried 'a1 == a2' and many other 
ways (including opEquals from object.d) among other things and 
every single time the comparison returns false.  The comparison 
always fails and never returns true.


I am trying to do something like Object.equals(Object o) in java, 
but so far, no success.


Am I missing something here?

Re: opIndex() may hide opSlice()

[XavierAP via Digitalmars-d]

On Friday, 10 March 2017 at 15:41:31 UTC, Jonathan M Davis wrote:
On Friday, March 10, 2017 14:15:45 Nick Treleaven via 
Digitalmars-d wrote:

On Friday, 10 March 2017 at 01:10:21 UTC, H. S. Teoh wrote:
>
> Using opSlice() for slicing (i.e., arr[]) is old,
> backward-compatible
> behaviour.

This seems non-intuitive to me (at least for single dimension 
containers) - when you see var[], do you think var is being 
indexed or do you think var is being sliced like an array 
(equivalent to var[0..$])?


Yeah, I've never understood how it made any sense for opIndex 
to be used for slicing, and I've never used it that way. I 
generally forget that that change was even made precisely 
because it makes no sense to me, whereas using opSlice for 
slicing makes perfect sense. I always use opIndex for indexing 
and opSlice for slicing just like they were originally designed.


I agree, the problem is that the current behavior prefers 
opIndex(), so deprecating that one would break compatibility. 
Could be done in phases then.


But this isn't really worth much bother of course.

Re: opIndex() may hide opSlice()

[Jonathan M Davis via Digitalmars-d]

On Friday, March 10, 2017 14:15:45 Nick Treleaven via Digitalmars-d wrote:
> On Friday, 10 March 2017 at 01:10:21 UTC, H. S. Teoh wrote:
> > On Fri, Mar 10, 2017 at 01:07:33AM +, XavierAP via
> >
> > Digitalmars-d wrote:
> >> The web reference tersely says under its *Slice* Operator
> >> Overloading chapter [1]: "To overload a[], simply define
> >> opIndex with no parameters."
> >>
> >> Should not the overload of opSlice() with no arguments be
> >> deprecated?
> >> Am I missing something?
> >
> > Using opSlice() for slicing (i.e., arr[]) is old,
> > backward-compatible
> > behaviour.
>
> This seems non-intuitive to me (at least for single dimension
> containers) - when you see var[], do you think var is being
> indexed or do you think var is being sliced like an array
> (equivalent to var[0..$])?

Yeah, I've never understood how it made any sense for opIndex to be used for
slicing, and I've never used it that way. I generally forget that that
change was even made precisely because it makes no sense to me, whereas
using opSlice for slicing makes perfect sense. I always use opIndex for
indexing and opSlice for slicing just like they were originally designed.

- Jonathan M Davis

Re: Rename 'D' to 'D++'

[Abdulhaq via Digitalmars-d]

On Friday, 10 March 2017 at 11:25:11 UTC, Traktor TOni wrote:
I think the name is just misleading, the D developers should at 
least be honest with themselves.


well the tractor derives from the shire horse and Toni comes from 
Antonius so you should be honest too and rename yourself to 
Shirehorse++ Antonius--.

Ocean v3.0.0: First fully public release!

[Leandro Lucarella via Digitalmars-d-announce]

Hi dear D community!

We wanted to share with you some nice news and big milestone: we 
are (finally!) going completely public with Ocean development!


Starting with the new v3.0.0 release all the development done to 
the library will go to the public repository (and actually this 
goes too for the older versions still in maintenance mode, v2.5.x 
and v2.6.x at the time, and in development mode, v2.x.x). No more 
internal development and sync points from time to time.


Because of this you should start seeing a *LOT* more activity on 
the project from now on, and we encourage the community to once 
again have a look at it.


Standard disclaimer: to be used with D2 there still an automatic 
conversion step that needs to be done, and you'll need a slightly 
older and modified dmd, but we were (are?) working on that too 
with Walter / Andrei / Martin on how we can push for the changes 
we need in D2 to be able to use the vanilla compiler.


I won't bother you with the changelog for v3.0.0 (is packed with 
more than a dozen of new features, the release notes themselves 
are about 200 lines long :D), but if you are curious you can have 
a look at it: 
https://github.com/sociomantic-tsunami/ocean/releases/tag/v3.0.0


Contributions are more welcome than ever.

Happy hacking!

Re: Rename 'D' to 'D++'

[rikki cattermole via Digitalmars-d]

On 11/03/2017 4:16 AM, Traktor TOni wrote:

On Friday, 10 March 2017 at 15:10:34 UTC, Chris wrote:

Why, then, is Rust called "Rust"? "C++" was chosen to signal that it's
an improvement of C. "D++" would mean an improvement of D. If D is
improved C++, then we would have to call it "C".

This thread is absurd and leads nowhere.


Rust has its own name, they don't have to follow any idea.
D has chosen to use the naming scheme of C and as such it should be
honest and use D++ because that's what D is: An expanded version of the
former language.


D was originally called Mars.
No the community choose to call it D, we're not renaming.

Re: Rename 'D' to 'D++'

[Traktor TOni via Digitalmars-d]

On Friday, 10 March 2017 at 15:10:34 UTC, Chris wrote:
Why, then, is Rust called "Rust"? "C++" was chosen to signal 
that it's an improvement of C. "D++" would mean an improvement 
of D. If D is improved C++, then we would have to call it 
"C".


This thread is absurd and leads nowhere.


Rust has its own name, they don't have to follow any idea.
D has chosen to use the naming scheme of C and as such it should 
be honest and use D++ because that's what D is: An expanded 
version of the former language.

Re: Rename 'D' to 'D++'

[Chris via Digitalmars-d]

On Friday, 10 March 2017 at 14:39:18 UTC, Traktor TOni wrote:

On Friday, 10 March 2017 at 14:29:27 UTC, Chris wrote:

On Friday, 10 March 2017 at 14:22:52 UTC, TooHuman wrote:

On Friday, 10 March 2017 at 14:19:17 UTC, Traktor TOni wrote:

On Friday, 10 March 2017 at 12:23:11 UTC, Ethan Watson wrote:

[...]


I am not sure what this has anything to do with version 
numbers? My point is that D is much more like C++ than it is 
like C, I think D should be honest and reflect that in its 
name. That's all I'm saying.


So should Java be renamed to Java++? Or maybe D should be 
D-Java++?


According to Wikipedia, D was influenced by:

C, C++, C#, Eiffel, Java, Python (English version)
C, C++, Java, C#, Python, Ruby (Spanish and German version)

I suggest to call it "DythonubyavaC#++" henceforth.


You dont have to get all salty about it, just admit that D is 
more like C++ and then we can propose the name change 
officially on github. Maybe this would help with adoption too, 
Rust has no problem calling itself a successor to C++ rather 
than C, so D shouldnt be afraid of this legacy either.


Why, then, is Rust called "Rust"? "C++" was chosen to signal that 
it's an improvement of C. "D++" would mean an improvement of D. 
If D is improved C++, then we would have to call it "C".


This thread is absurd and leads nowhere.

Re: [Tidbit] making your D code more modular & unittestable

[Nick Treleaven via Digitalmars-d]

On Thursday, 9 March 2017 at 20:54:23 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 03/08/2017 04:34 PM, H. S. Teoh via Digitalmars-d wrote:

auto parseFile(Slice)(Slice input)
if (isRandomAccessRange!Slice && hasSlicing!Slice &&
is(ElementType!Slice : ubyte))
{
... // use nice input[x .. y] syntax, yay!
return result;
}



Wishlist for D3: Some brilliant form of sugar for declaring a 
function that takes a range.


auto parseFile()(auto input if isRandomAccessRangeOf!ubyte && 
hasSlicing) {


My spin on an inline parameter constraint idea by Kenji (his 
doesn't use auto and also has more concept-like sugar):


https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint

As mentioned in the link, inline constraints can help make more 
specific error messages when constraints fail.

Re: Rename 'D' to 'D++'

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 10 March 2017 at 14:39:18 UTC, Traktor TOni wrote:
You dont have to get all salty about it, just admit that D is 
more like C++ and then we can propose the name change 
officially on github. Maybe this would help with adoption too, 
Rust has no problem calling itself a successor to C++ rather 
than C, so D shouldnt be afraid of this legacy either.


C+1 == D

C++
C == D

Re: Rename 'D' to 'D++'

[XavierAP via Digitalmars-d]

http://i0.kym-cdn.com/photos/images/original/000/233/260/687.jpg

ok I'll bite 0:)

On Friday, 10 March 2017 at 14:19:17 UTC, Traktor TOni wrote:

My point is that D is much more like C++ than it is like C


Exactly. So that you understand, let's say "C" means "horse", 
"C++" means "cyborg wheeled horse", and "D" means "car"


https://c1.staticflickr.com/9/8193/8148618536_2128988e76.jpg

Re: Where do you test syntax of D regexp online?

[Suliman via Digitalmars-d-learn]

On Friday, 10 March 2017 at 14:36:48 UTC, Suliman wrote:

On Thursday, 9 March 2017 at 16:47:18 UTC, Adam D. Ruppe wrote:

On Thursday, 9 March 2017 at 16:40:13 UTC, Suliman wrote:

How should I write to file result without \r\n\ symbols?

auto x = content.matchFirst(bigCodeBlock);

File f = File("foo.txt", "w");
f.write(x);


Just

f.write(x[0]);


to write out the whole hit instead of the collection of 
references.


What can be wrong with this regexp? 
https://regex101.com/r/8e7nPL/3

it's crush D compiler, and I can't find out why


I need simply select parts from one first-level # to another.

like:
#header
some text
and some code

^ first matching


#header2
some text2
and some code2

^ second matching

Re: Rename 'D' to 'D++'

[Traktor TOni via Digitalmars-d]

On Friday, 10 March 2017 at 14:29:27 UTC, Chris wrote:

On Friday, 10 March 2017 at 14:22:52 UTC, TooHuman wrote:

On Friday, 10 March 2017 at 14:19:17 UTC, Traktor TOni wrote:

On Friday, 10 March 2017 at 12:23:11 UTC, Ethan Watson wrote:

On Friday, 10 March 2017 at 11:25:11 UTC, Traktor TOni wrote:
I think the name is just misleading, the D developers 
should at least be honest with themselves.


D++ - Because no language has version numbers. Not even C#. 
Any proof to the contrary is clearly fake proof.


I am not sure what this has anything to do with version 
numbers? My point is that D is much more like C++ than it is 
like C, I think D should be honest and reflect that in its 
name. That's all I'm saying.


So should Java be renamed to Java++? Or maybe D should be 
D-Java++?


According to Wikipedia, D was influenced by:

C, C++, C#, Eiffel, Java, Python (English version)
C, C++, Java, C#, Python, Ruby (Spanish and German version)

I suggest to call it "DythonubyavaC#++" henceforth.


You dont have to get all salty about it, just admit that D is 
more like C++ and then we can propose the name change officially 
on github. Maybe this would help with adoption too, Rust has no 
problem calling itself a successor to C++ rather than C, so D 
shouldnt be afraid of this legacy either.

Re: Where do you test syntax of D regexp online?

[Suliman via Digitalmars-d-learn]

On Thursday, 9 March 2017 at 16:47:18 UTC, Adam D. Ruppe wrote:

On Thursday, 9 March 2017 at 16:40:13 UTC, Suliman wrote:

How should I write to file result without \r\n\ symbols?

auto x = content.matchFirst(bigCodeBlock);

File f = File("foo.txt", "w");
f.write(x);


Just

f.write(x[0]);


to write out the whole hit instead of the collection of 
references.


What can be wrong with this regexp? 
https://regex101.com/r/8e7nPL/3

it's crush D compiler, and I can't find out why

Re: How can D Forum load so fast?

[bachmeier via Digitalmars-d]

On Friday, 10 March 2017 at 07:51:30 UTC, Anon wrote:
The whole webpage https://forum.dlang.org/ has only 300KB in 
size. It not only supports mobile devices, but also loads much 
faster than general modern web pages.


How can they achieve such result?


This is how Vladimir answered before:

"No rocket science here, just general optimization common sense. 
Look at what CPU and web profilers (e.g. Google PageSpeed) say 
and optimize accordingly, rinse and repeat."


http://forum.dlang.org/post/mgehxkddgybngulpm...@forum.dlang.org

Re: Rename 'D' to 'D++'

[TooHuman via Digitalmars-d]

On Friday, 10 March 2017 at 14:19:17 UTC, Traktor TOni wrote:

On Friday, 10 March 2017 at 12:23:11 UTC, Ethan Watson wrote:

On Friday, 10 March 2017 at 11:25:11 UTC, Traktor TOni wrote:
I think the name is just misleading, the D developers should 
at least be honest with themselves.


D++ - Because no language has version numbers. Not even C#. 
Any proof to the contrary is clearly fake proof.


I am not sure what this has anything to do with version 
numbers? My point is that D is much more like C++ than it is 
like C, I think D should be honest and reflect that in its 
name. That's all I'm saying.


So should Java be renamed to Java++? Or maybe D should be 
D-Java++?

Re: Rename 'D' to 'D++'

[Chris via Digitalmars-d]

On Friday, 10 March 2017 at 14:22:52 UTC, TooHuman wrote:

On Friday, 10 March 2017 at 14:19:17 UTC, Traktor TOni wrote:

On Friday, 10 March 2017 at 12:23:11 UTC, Ethan Watson wrote:

On Friday, 10 March 2017 at 11:25:11 UTC, Traktor TOni wrote:
I think the name is just misleading, the D developers should 
at least be honest with themselves.


D++ - Because no language has version numbers. Not even C#. 
Any proof to the contrary is clearly fake proof.


I am not sure what this has anything to do with version 
numbers? My point is that D is much more like C++ than it is 
like C, I think D should be honest and reflect that in its 
name. That's all I'm saying.


So should Java be renamed to Java++? Or maybe D should be 
D-Java++?


According to Wikipedia, D was influenced by:

C, C++, C#, Eiffel, Java, Python (English version)
C, C++, Java, C#, Python, Ruby (Spanish and German version)

I suggest to call it "DythonubyavaC#++" henceforth.

Re: Rename 'D' to 'D++'

[Traktor TOni via Digitalmars-d]

On Friday, 10 March 2017 at 12:23:11 UTC, Ethan Watson wrote:

On Friday, 10 March 2017 at 11:25:11 UTC, Traktor TOni wrote:
I think the name is just misleading, the D developers should 
at least be honest with themselves.


D++ - Because no language has version numbers. Not even C#. Any 
proof to the contrary is clearly fake proof.


I am not sure what this has anything to do with version numbers? 
My point is that D is much more like C++ than it is like C, I 
think D should be honest and reflect that in its name. That's all 
I'm saying.

Re: opIndex() may hide opSlice()

[Nick Treleaven via Digitalmars-d]

On Friday, 10 March 2017 at 01:10:21 UTC, H. S. Teoh wrote:
On Fri, Mar 10, 2017 at 01:07:33AM +, XavierAP via 
Digitalmars-d wrote:
The web reference tersely says under its *Slice* Operator 
Overloading chapter [1]: "To overload a[], simply define 
opIndex with no parameters."


Should not the overload of opSlice() with no arguments be 
deprecated?

Am I missing something?


Using opSlice() for slicing (i.e., arr[]) is old, 
backward-compatible

behaviour.


This seems non-intuitive to me (at least for single dimension 
containers) - when you see var[], do you think var is being 
indexed or do you think var is being sliced like an array 
(equivalent to var[0..$])?


Also deprecating nullary opSlice() would work against defining 
opSlice(int low = 0, int high = length).

Re: How can D Forum load so fast?

[Vasudev Ram via Digitalmars-d]

On Friday, 10 March 2017 at 13:57:06 UTC, Vasudev Ram wrote:

On Friday, 10 March 2017 at 07:51:30 UTC, Anon wrote:
The whole webpage https://forum.dlang.org/ has only 300KB in 
size. It not only supports mobile devices, but also loads much 
faster than general modern web pages.


How can they achieve such result?


I think (not verified scientifically) that it is due to the 
forum software (DFeed) being written in D and hence compiled,


Just remembered - the "About this forum" link at the bottom of D 
forum pages (like this one) is where I read what I said in my 
previous post.


https://forum.dlang.org/help#about

Re: How can D Forum load so fast?

[Vasudev Ram via Digitalmars-d]

On Friday, 10 March 2017 at 07:51:30 UTC, Anon wrote:
The whole webpage https://forum.dlang.org/ has only 300KB in 
size. It not only supports mobile devices, but also loads much 
faster than general modern web pages.


How can they achieve such result?


I think (not verified scientifically) that it is due to the forum 
software (DFeed) being written in D and hence compiled, vs. a lot 
of other forum software that may be written in interpreted 
languages. I too have noticed its speed. Plus of course, all the 
points that others have said about a lot of extra stuff on other 
sites, like 2 MB pages, JS, video, ads, trackers, etc. I also 
read somewhere that DFeed is open source, so anyone who wants to 
study it, can do so. If I ever setup a forum, I'll try using 
DFeed for it.

Re: Intellij D Language plugin v1.11 released

[Martin Tschierschke via Digitalmars-d-announce]

On Thursday, 9 March 2017 at 22:46:12 UTC, singingbush wrote:
the new build fixes compatibility issues with Intellij IDEA 
2016.3.* versions. It should be in the plugin repo soon but in 
meantime can be downloaded from


https://github.com/kingsleyh/DLanguage/releases


Looks nice! I have zero experience with  Intellij IDEA until now, 
so I installed it following the ubuntu wiki. Now one question do 
you know a way to support .dt (diet template files) for use with 
vibe.d?
I thought it should be possible to use a .pug plugin (former 
known as jade .js template engine) has anyone used it this way?

How to write document for methods under static if?

[Yuxuan Shui via Digitalmars-d-learn]

Example:

/**
  test type
*/
struct A(bool T) {
static if (T) {
/// Case 1
int ok(){ return 1; }
} else {
/// case 2
int notok(){ return 1; }
}

/// Other
int other() { return 0; }
}

///
unittest {
A!true x;
A!false y;
}

In documents generated by ddoc, only case 1 is included. In 
documents generated by ddox, none of the cases is included.


What's the proper way to write document in this case?

Re: Rename 'D' to 'D++'

[Chris via Digitalmars-d]

On Friday, 10 March 2017 at 12:23:11 UTC, Ethan Watson wrote:

On Friday, 10 March 2017 at 11:25:11 UTC, Traktor TOni wrote:
I think the name is just misleading, the D developers should 
at least be honest with themselves.


D++ - Because no language has version numbers. Not even C#. Any 
proof to the contrary is clearly fake proof.


Don't feed the trolls++.

Re: Rename 'D' to 'D++'

[Ethan Watson via Digitalmars-d]

On Friday, 10 March 2017 at 11:25:11 UTC, Traktor TOni wrote:
I think the name is just misleading, the D developers should at 
least be honest with themselves.


D++ - Because no language has version numbers. Not even C#. Any 
proof to the contrary is clearly fake proof.

[Issue 17226] Exception during the generation of an assert message hides AssertError

[via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #3 from RazvanN  ---
Not sure if this is a dmd error. I think this might be druntime related :-?

--

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:

[ ... ]


Time for an update.

I am currently working on integrating 64bit values into codegen 
API.
However, a backend may not have native 64bit registers or 
arithmetic (the x86/arm architectures come to mind)
For those a common fallback is to be implemented such that not 
every architecture has to implement their 64bit arithmetic on 
their own.


Also work is underway to finally support slicing, which is 
crucial to using phobos algorithms.

Rename 'D' to 'D++'

[Traktor TOni via Digitalmars-d]

I think the name is just misleading, the D developers should at 
least be honest with themselves.

Re: How can D Forum load so fast?

[Chris via Digitalmars-d]

On Friday, 10 March 2017 at 08:05:27 UTC, Stefan Koch wrote:

On Friday, 10 March 2017 at 07:51:30 UTC, Anon wrote:
The whole webpage https://forum.dlang.org/ has only 300KB in 
size. It not only supports mobile devices, but also loads much 
faster than general modern web pages.


How can they achieve such result?


By not using tons of java-script libraries.


I use vibe.d and very little JS (mainly my own) for new projects. 
If I do something with vibe.d instead of JS it's infinitely more 
elegant and efficient. But you cannot do without JS. Sometimes 
it's handy, sometimes it's easier to change things on the fly, 
you can include things with a simple reference to a script etc. 
But heavy reliance on JS is a recipe for disaster. Not only does 
your code become unmaintainable, you always have issues with 
different browsers (mobile vs. desktop etc.)

Re: How can D Forum load so fast?

[Era Scarecrow via Digitalmars-d]

On Friday, 10 March 2017 at 09:08:16 UTC, CasparKielwein wrote:

On Friday, 10 March 2017 at 09:00:15 UTC, Era Scarecrow wrote:
 I'd rather we backtrack to more basic Apache/PHP/MySQL and 
minimal JS without cross scripting or the like.


The Forum is actually written in D. As far as I know the author 
is Vladimir Panteleev.


 I was actually referring in general for the majority of the web, 
not for the D Forums.

Re: How can D Forum load so fast?

[Walter Bright via Digitalmars-d]

On 3/9/2017 11:51 PM, Anon wrote:

The whole webpage https://forum.dlang.org/ has only 300KB in size. It not only
supports mobile devices, but also loads much faster than general modern web 
pages.

How can they achieve such result?


It doesn't have popup ads, autorun videos, trackers, large jpegs, Web 2.0 crap, 
spyware, or a web design team that has to justify their $ bill.

Re: How can D Forum load so fast?

[Shachar Shemesh via Digitalmars-d]

On 10/03/17 09:51, Anon wrote:

The whole webpage https://forum.dlang.org/ has only 300KB in size. It
not only supports mobile devices, but also loads much faster than
general modern web pages.

How can they achieve such result?


Maybe, but the NNTP interface routinely has "connection refused" problems.

Shachar

Re: How can D Forum load so fast?

[CasparKielwein via Digitalmars-d]

On Friday, 10 March 2017 at 09:00:15 UTC, Era Scarecrow wrote:

On Friday, 10 March 2017 at 08:05:27 UTC, Stefan Koch wrote:

On Friday, 10 March 2017 at 07:51:30 UTC, Anon wrote:

How can they achieve such result?


By not using tons of java-script libraries.


Not having it bogged down certainly makes a huge difference. I 
can't stand that websites want to be 2Mb per page to view it, 
and then have a bunch of JS in the background to do very little 
beneficial work.


 I'd rather we backtrack to more basic Apache/PHP/MySQL and 
minimal JS without cross scripting or the like.


The Forum is actually written in D. As far as I know the author 
is Vladimir Panteleev.
I could only find an old post on Hackernews about it, where 
someone noted its performance.


( https://news.ycombinator.com/item?id=3592769 )

Re: How can D Forum load so fast?

[Era Scarecrow via Digitalmars-d]

On Friday, 10 March 2017 at 08:05:27 UTC, Stefan Koch wrote:

On Friday, 10 March 2017 at 07:51:30 UTC, Anon wrote:

How can they achieve such result?


By not using tons of java-script libraries.


Not having it bogged down certainly makes a huge difference. I 
can't stand that websites want to be 2Mb per page to view it, and 
then have a bunch of JS in the background to do very little 
beneficial work.


 I'd rather we backtrack to more basic Apache/PHP/MySQL and 
minimal JS without cross scripting or the like.

Re: How can D Forum load so fast?

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 10 March 2017 at 07:51:30 UTC, Anon wrote:
The whole webpage https://forum.dlang.org/ has only 300KB in 
size. It not only supports mobile devices, but also loads much 
faster than general modern web pages.


How can they achieve such result?


Depends on your location, it loads in 253ms for me, which is 
typical for a page without graphics.

Re: How can D Forum load so fast?

[Stefan Koch via Digitalmars-d]

On Friday, 10 March 2017 at 07:51:30 UTC, Anon wrote:
The whole webpage https://forum.dlang.org/ has only 300KB in 
size. It not only supports mobile devices, but also loads much 
faster than general modern web pages.


How can they achieve such result?


By not using tons of java-script libraries.

Re: Better ddoc defaults?

[via Digitalmars-d]

On Thursday, 9 March 2017 at 21:08:17 UTC, Yuxuan Shui wrote:
I'm using ddoc for the first time. I was naively expecting 
something resembles dlang.org, and the results is a bit 
disappointing. So I looked at dlang.org and realized lots and 
lots of ddoc templates are required to achieve that.


As the developer of a tiny package that nobody cares, I want to 
have a nice looking documents page, but I don't want put too 
much (or any!) time into it. And I don't care whether my 
documents have any "personality". I guess a lot people would 
agree.


So why don't we make the defaults more beautiful? Or make the 
dlang.org templates easier to adopt for average users?


My favorite one is: https://github.com/MartinNowak/scod.

BTW, the default ddox (the one that comes with dub) is getting an 
upgrade soon: https://github.com/rejectedsoftware/ddox/pull/149

https://github.com/rejectedsoftware/ddox/pull/150.