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?
On Thursday, 9 March 2017 at 15:42:22 UTC, qznc wrote:
On Tuesday, 7 March 2017 at 15:34:54 UTC, ketmar wrote:
Jack Stouffer wrote:
On Tuesday, 7 March 2017 at 15:05:45 UTC, ketmar wrote:
only for primitive types, sadly.
void main () {
Object a, b;
a == b;
}
oops. no more error messages. ye
On Fri, Mar 10, 2017 at 03:45:37AM +, Ivan Kazmenko via Digitalmars-d wrote:
> On Thursday, 9 March 2017 at 15:42:22 UTC, qznc wrote:
> > I'm curious. Where does it make sense for opEquals to be non-pure?
> > Likewise opCmp, etc.
>
> An example would be tracking the number of comparisons made.
On Fri, Mar 10, 2017 at 01:34:13AM +, XavierAP 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:
> > >
> > > Should not the overload of opSlice() with no arguments be
> > >
On Thursday, 9 March 2017 at 15:42:22 UTC, qznc wrote:
I'm curious. Where does it make sense for opEquals to be
non-pure? Likewise opCmp, etc.
An example would be tracking the number of comparisons made.
This sounds like debug information (and then, debug statement can
be used to escape puri
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:
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-c
On Fri, Mar 10, 2017 at 01:07:33AM +, XavierAP via Digitalmars-d wrote:
> In their versions without parameters, these two operators would be
> called in the same way. If both are defined, opIndex() is called,
> regardless of lexical definition order, according to my test with DMD.
>
> If both
In their versions without parameters, these two operators would
be called in the same way. If both are defined, opIndex() is
called, regardless of lexical definition order, according to my
test with DMD.
If both (again I'm just talking about the overloads with no
arguments) are defined within
On Thursday, 9 March 2017 at 21:43:00 UTC, Yuxuan Shui wrote:
Also this page looks kind of broken?
The text is unreadably small in places, not sure why. I just ran
my file through dmd -D with the newest version, so I assume it is
the new default macros.
I don't use ddoc for myself though, I
On Thursday, 9 March 2017 at 21:17:11 UTC, Adam D. Ruppe wrote:
On Thursday, 9 March 2017 at 21:08:17 UTC, Yuxuan Shui wrote:
So why don't we make the defaults more beautiful?
ddoc DID just recently get an overhaul... do your pages look
like
http://arsdnet.net/dcode/simpledisplay.html
Yes
On Thu, Mar 09, 2017 at 09:08:17PM +, Yuxuan Shui via Digitalmars-d 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
On Thursday, 9 March 2017 at 21:08:17 UTC, Yuxuan Shui wrote:
So why don't we make the defaults more beautiful?
ddoc DID just recently get an overhaul... do your pages look like
http://arsdnet.net/dcode/simpledisplay.html
or like this
http://arsdnet.net/ddoc/simpledisplay.html
?
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
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!
On 03/08/2017 07:31 PM, H. S. Teoh via Digitalmars-d wrote:
I did learn a
thing or two about what std.range considers to satisfy hasSlicing... it
wasn't quite as obvious as I had thought.
Do tell!
On Thursday, 9 March 2017 at 16:12:46 UTC, bachmeier wrote:
On Thursday, 9 March 2017 at 11:52:42 UTC, thedeemon wrote:
On Wednesday, 8 March 2017 at 20:00:54 UTC, aberba wrote:
[...]
This is mostly a psychological effect of C++ folks having
aversion to any GC.
It is interesting to have wa
On Thursday, 9 March 2017 at 17:31:53 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 4 March 2017 at 07:09:17 UTC, Nick Sabalausky
(Abscissa) wrote:
In a similar vein, I have to say I'm thoroughly impressed with
what I've learned of Mir. AIUI, aside from being a fantastic
lib, it looks like a too
On Saturday, 4 March 2017 at 07:09:17 UTC, Nick Sabalausky
(Abscissa) wrote:
In a similar vein, I have to say I'm thoroughly impressed with
what I've learned of Mir. AIUI, aside from being a fantastic
lib, it looks like a tool with very high widespread potential
that's written in D, yet also ta
John Colvin wrote:
On Thursday, 9 March 2017 at 15:55:07 UTC, deadalnix wrote:
On Thursday, 9 March 2017 at 15:42:22 UTC, qznc wrote:
I'm curious. Where does it make sense for opEquals to be non-pure?
Likewise opCmp, etc.
When the object need some kind of normalization to be comparable and
On Thursday, 9 March 2017 at 15:55:07 UTC, deadalnix wrote:
On Thursday, 9 March 2017 at 15:42:22 UTC, qznc wrote:
I'm curious. Where does it make sense for opEquals to be
non-pure? Likewise opCmp, etc.
When the object need some kind of normalization to be
comparable and you don't want to d
On Thursday, 9 March 2017 at 15:54:04 UTC, dewitt wrote:
I don't think the community should think in terms of "threat"
or "competition" I mean languages are basically tools to get a
job done.
Yeah, and that is a trend that is increasing as the cost of
developing new languages are falling. No
On Thursday, 9 March 2017 at 15:54:04 UTC, dewitt wrote:
Also how many times a week can the same questions be asked on
this forum about the same topics? I feel I am re-reading the
same stuff weekly
That's a good sign. It comes with the territory when a language
starts to see serious conside
On Thursday, 9 March 2017 at 11:52:42 UTC, thedeemon wrote:
On Wednesday, 8 March 2017 at 20:00:54 UTC, aberba wrote:
From a technical and experience point of view (those with
experience in large D code-base), how is only D's GC &
optional MMM a significant production-use blocker?
This is mos
On Thursday, 9 March 2017 at 15:42:22 UTC, qznc wrote:
I'm curious. Where does it make sense for opEquals to be
non-pure? Likewise opCmp, etc.
When the object need some kind of normalization to be comparable
and you don't want to do the normalization every single time.
On 4/03/2017 7:10 PM, Patrick Schluter wrote:
The compiler front-end did just that. I can not comment on the quality
of the code but on the speed of compilation, wow, just wow.
Building v2.067 takes 1'38" on the server at work (westmere at 2.2 GHz,
gcc 6.2, dmd v2.073, single core build).
Buildi
On Thursday, 9 March 2017 at 13:36:28 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 9 March 2017 at 12:27:30 UTC, Guillaume Piolat
wrote:
The competition is clever enough to emphasize that D is 14
years old and has a GC, so they don't even try it.
The competition doesn't smack talk D, I think.
On Wednesday, 8 March 2017 at 15:48:47 UTC, Timon Gehr wrote:
What I'm not buying is that the existence of UB in some
circumstances justifies introducing more cases where UB is
unexpectedly introduced. It's a continuum. Generally, if you
add more failure modes, you will have more exploits.
Wi
On Tuesday, 7 March 2017 at 15:34:54 UTC, ketmar wrote:
Jack Stouffer wrote:
On Tuesday, 7 March 2017 at 15:05:45 UTC, ketmar wrote:
only for primitive types, sadly.
void main () {
Object a, b;
a == b;
}
oops. no more error messages. yes, i know that this invokes
`opEquals()`, and `opEquals
On Thursday, 9 March 2017 at 14:38:32 UTC, Guillaume Piolat wrote:
On Thursday, 9 March 2017 at 14:08:00 UTC, Ola Fosheim Grøstad
wrote:
I don't really want to talk with you.
Whatever suits you, but don't pretend that people that express
views about D online are the competition. They are ove
On Thursday, 9 March 2017 at 13:46:57 UTC, Ilya Yaroshenko wrote:
`stack` was renamed to `concatenation` to much numpy and Matlab
Numpy does have stack, but this is more similar to the
concatenate function (I'd prefer this to concatenation). Matlab
just calls it cat, which is easier to type,
On Thursday, 9 March 2017 at 14:08:00 UTC, Ola Fosheim Grøstad
wrote:
I am speaking of what they are perceiving not what I think.
They don't perceive D as a threat, why would they feel a need
to smack talk D?
I don't really want to talk with you.
On Thursday, 9 March 2017 at 13:40:09 UTC, Guillaume Piolat wrote:
On Thursday, 9 March 2017 at 13:36:28 UTC, Ola Fosheim Grøstad
wrote:
It's not like D is threat to them anyway.
I'm not sure why you would think that, if anything that
reinforced my point.
I am speaking of what they are p
On Thursday, 9 March 2017 at 08:59:28 UTC, Ilya Yaroshenko wrote:
Hello
Ndslice got [1] lazy multidimensional concatenation and padding
utilities:
1. stack
2. pad
2. padEdge
3. padSymmetric
4. padWrap
`stack` can be used for ndslices instead of `chain`.
---
import mir.ndslice.allocatio
On Thursday, 9 March 2017 at 08:59:28 UTC, Ilya Yaroshenko wrote:
[1] http://docs.algorithm.dlang.io/latest/mir_ndslice_stack.html
renamed:
http://docs.algorithm.dlang.io/latest/mir_ndslice_concatenation.html
On Thursday, 9 March 2017 at 13:36:28 UTC, Ola Fosheim Grøstad
wrote:
It's not like D is threat to them anyway.
I'm not sure why you would think that, if anything that
reinforced my point.
On Thursday, 9 March 2017 at 12:27:30 UTC, Guillaume Piolat wrote:
The competition is clever enough to emphasize that D is 14
years old and has a GC, so they don't even try it.
The competition doesn't smack talk D, I think. If they mention D
they tend to do so in a friendly way. It's not like
On Wednesday, 8 March 2017 at 20:00:54 UTC, aberba wrote:
(To make my problem clear, how is D's current state not going
to allow / make it so difficult for developers (who know what
they are doing) to write say Photoshop-scale software:
excluding those *so* realtime use cases?)
Well, I don't
On Thursday, 9 March 2017 at 12:07:54 UTC, Ola Fosheim Grøstad
wrote:
"template>struct mystuff ..."
"template struct mystuff > ..."
"template struct mystuff > ..."
Gah, that made no sense, meant something like this:
"template>struct mystuff ..."
"template struct mystuffT::Fish>> > ..."
"templa
On Tuesday, 7 March 2017 at 17:45:13 UTC, Atila Neves wrote:
write code. Something like "Do you know how to use
std::enable_if without looking at cppreference.com? No? Fail."
(I'd fail, I _always_ have to look up how to use enable_if.
Then again, it _is_ a horrible hacky hack of a hack based on
On Thursday, 9 March 2017 at 11:52:42 UTC, thedeemon wrote:
On Wednesday, 8 March 2017 at 20:00:54 UTC, aberba wrote:
From a technical and experience point of view (those with
experience in large D code-base), how is only D's GC &
optional MMM a significant production-use blocker?
This is mos
On Wednesday, 8 March 2017 at 20:00:54 UTC, aberba wrote:
From a technical and experience point of view (those with
experience in large D code-base), how is only D's GC & optional
MMM a significant production-use blocker?
This is mostly a psychological effect of C++ folks having
aversion to a
On Thursday, 9 March 2017 at 08:57:39 UTC, XavierAP wrote:
Just like Andrei at Facebook.
Just a FYI, Andrei *used* to work at Facebook.
https://www.reddit.com/r/programming/comments/3ioy9b/andrei_alexandrescu_c_guru_leaves_facebook_to/
On Thursday, 9 March 2017 at 09:10:47 UTC, Nordlöw wrote:
On Thursday, 9 March 2017 at 08:59:28 UTC, Ilya Yaroshenko
wrote:
Ndslice got [1] lazy multidimensional concatenation and
padding utilities:
Nice. Is this dependent on choosing either RC- or GC-based
allocation?
... continue prev. re
On Thursday, 9 March 2017 at 09:10:47 UTC, Nordlöw wrote:
On Thursday, 9 March 2017 at 08:59:28 UTC, Ilya Yaroshenko
wrote:
Ndslice got [1] lazy multidimensional concatenation and
padding utilities:
Nice. Is this dependent on choosing either RC- or GC-based
allocation?
No, they are complete
On Tuesday, 7 March 2017 at 05:44:49 UTC, Walter Bright wrote:
https://makebitcoingreatagain.wordpress.com/2017/02/18/is-the-zcoin-bug-in-checktransaction/#update6
The error is here:
https://github.com/zcoinofficial/zcoin/blob/81a667867b5d8489...
and the line of code:
zccoinSpend.de
On Thursday, 9 March 2017 at 08:59:28 UTC, Ilya Yaroshenko wrote:
Ndslice got [1] lazy multidimensional concatenation and padding
utilities:
Nice. Is this dependent on choosing either RC- or GC-based
allocation?
Hello
Ndslice got [1] lazy multidimensional concatenation and padding
utilities:
1. stack
2. pad
2. padEdge
3. padSymmetric
4. padWrap
`stack` can be used for ndslices instead of `chain`.
---
import mir.ndslice.allocation: slice;
import mir.ndslice.stack: stack;
auto d = stack(a, b, c)
On Thursday, 9 March 2017 at 07:24:12 UTC, aberba wrote:
So technically and from experience, the current state of D is
not the primary issue?
I don't have enough experience with D yet, hopefully someone else
can tell you better. But my two cents.
"Current state" is a very general thing. Goin
48 matches
Mail list logo
