On Tue, 27 Jan 2015 02:11:55 +, Jonathan Marler wrote:
> This has become quite frustrating. I'm not sure how else to explain
> myself so maybe I'm just being dumb.
you are dumb. you can be dumb for some time, and then BANG! your proposal
is silently made "right". yet you're still dumb. that
On Mon, 26 Jan 2015 17:56:00 -0800, Walter Bright wrote:
> On 1/26/2015 2:15 PM, Foo wrote:
>> Because you/we are community members and therefore "second-class
>> citizens". If we suggest or discuss something, it is not that
>> important. But if a small reddit post is made, it matters more.
>
> M
On 2015-01-26 17:10, Jonathan Marler wrote:
I agree with Jonathan's points, this solution doesn't seem like an
improvement. If I understand the problem, we don't want to make every
attribute use the '@' symbol because it looks bad and would cause a lot
of code changes for sake of consistency. H
On 1/26/15 10:32 PM, Mike wrote:
On Tuesday, 27 January 2015 at 03:58:34 UTC, Andrei Alexandrescu wrote:
On 1/26/15 5:32 PM, Mike wrote:
The future benefits of fixing this kind of crap, are huge.
IMHO this is myopic. We have much larger issues with e.g. safety,
shared, and the core threading
Am 26.01.2015 um 23:24 schrieb Walter Bright:
exporting a template and then having the user instantiate outside of the
library doesn't make a whole lot of sense, because the instantiation
won't be there in the library. The library will have to instantiate
every use case. If the compiler knows th
On Tuesday, 27 January 2015 at 03:58:34 UTC, Andrei Alexandrescu
wrote:
On 1/26/15 5:32 PM, Mike wrote:
The future benefits of fixing this kind of crap, are huge.
IMHO this is myopic. We have much larger issues with e.g.
safety, shared, and the core threading library, than syntactic
minutia.
On Tuesday, 27 January 2015 at 04:10:24 UTC, Andrei Alexandrescu
wrote:
I'm ready to commit to dfix. Problem is many of the changes
suggested are unlikely to mark much improvement, while miring
us in the perpetual illusion of making progress.
I don't think there's any illusion about D's great
There was also this one from 1998 that was very small
http://www.javaworld.com/article/2076641/learn-java/an-introduction-to-the-java-ring.html
Java has some history running on small devices.
Cheers,
uri
Indeed, and I remember that well.
However I was less interested in embedded devices a
On Tue, 2015-01-27 at 04:50 +, uri via Digitalmars-d wrote:
>
> Java has some history running on small devices.
And, after all, Java (née Oak) was invented for programming white goods
operating systems. Also set top boxes. The first tablet, Star7, appeared
long before iPad.
FTR JavaCard has
"Etienne" wrote in message news:m9lvn5$28cr$1...@digitalmars.com...
The el_match function on lines 2393-2615 of backend/el.c doesn't
elaborate cases for simd. I'm not going to make a pull request because I
don't have time to work through the lengthy process of isolating a
particular bug, so,
On Tuesday, 27 January 2015 at 04:10:24 UTC, Andrei Alexandrescu
wrote:
On 1/26/15 7:25 PM, Zach the Mystic wrote:
On Tuesday, 27 January 2015 at 02:40:16 UTC, Walter Bright
wrote:
On 1/26/2015 6:15 PM, Zach the Mystic wrote:
What's keeping you from committing to 'dfix' as the way to
solve
is
On Monday, 26 January 2015 at 22:53:15 UTC, Paulo Pinto wrote:
On Monday, 26 January 2015 at 22:12:24 UTC, Laeeth Isharc wrote:
" If Java consumes 15% more power doing it, does
it matter on a PC? Most people don't dare. Does it matter
for small-scale server environments? Maybe not. Does it
mat
On 1/26/2015 7:58 PM, Andrei Alexandrescu wrote:
On 1/26/15 5:32 PM, Mike wrote:
The future benefits of fixing this kind of crap, are huge.
IMHO this is myopic. We have much larger issues with e.g. safety, shared, and
the core threading library, than syntactic minutia. All of this changing wha
On 1/26/15 7:25 PM, Zach the Mystic wrote:
On Tuesday, 27 January 2015 at 02:40:16 UTC, Walter Bright wrote:
On 1/26/2015 6:15 PM, Zach the Mystic wrote:
What's keeping you from committing to 'dfix' as the way to solve
issues like the
one in this thread?
Inertia of people being reluctant to u
On Tuesday, 27 January 2015 at 03:54:09 UTC, Zach the Mystic
wrote:
On Tuesday, 27 January 2015 at 03:33:15 UTC, Jonathan Marler
wrote:
This has come up before. I believe if was at DConf 2014 that
Walter answered this question. If I remember, the gist was
that Walter didn't like the idea that t
On 1/26/15 5:45 PM, uri wrote:
I get the impression it will never be finished because too many are
afraid of important breaking changes that seem necessary to get through
the last 5%-10% of D2.
Fiddling with "@" is not important. -- Andrei
On Tuesday, 27 January 2015 at 03:41:51 UTC, weaselcat wrote:
FYI, Qatari Airway's GCEO Al Baker has repeatedly publicly
stated his opinion(on disliking) Boeing. Both Al Jazeera and
Qatari Airway are owned by the Qatari government.
Take an entire box of salt with that "documentary."
I won't.
On 1/26/15 5:32 PM, Mike wrote:
The future benefits of fixing this kind of crap, are huge.
IMHO this is myopic. We have much larger issues with e.g. safety,
shared, and the core threading library, than syntactic minutia. All of
this changing what works has its value, but that pales in compari
On Tuesday, 27 January 2015 at 03:33:15 UTC, Jonathan Marler
wrote:
This has come up before. I believe if was at DConf 2014 that
Walter answered this question. If I remember, the gist was that
Walter didn't like the idea that the compiler could rewrite a
user's code, he seemed kinda "creeped" o
On Tuesday, 27 January 2015 at 02:38:17 UTC, Zach the Mystic
wrote:
On Tuesday, 27 January 2015 at 01:41:31 UTC, Joakim wrote:
I was just surfing reddit and this exchange with Walter made
me LOL, talking about students who learn programming for the
first time in college:
Walter: Why would you
On Tuesday, 27 January 2015 at 03:25:59 UTC, Zach the Mystic
wrote:
On Tuesday, 27 January 2015 at 02:40:16 UTC, Walter Bright
wrote:
On 1/26/2015 6:15 PM, Zach the Mystic wrote:
What's keeping you from committing to 'dfix' as the way to
solve issues like the
one in this thread?
Inertia of p
On Tuesday, 27 January 2015 at 02:40:16 UTC, Walter Bright wrote:
On 1/26/2015 6:15 PM, Zach the Mystic wrote:
What's keeping you from committing to 'dfix' as the way to
solve issues like the
one in this thread?
Inertia of people being reluctant to use it. It's still work
for people to use,
"weaselcat" wrote in message news:ovwpcitsqbmpusckk...@forum.dlang.org...
Following this timeline, we should get std.allocator sometime
next year? : )
2019
On Tuesday, 27 January 2015 at 02:52:44 UTC, Walter Bright wrote:
On 1/26/2015 6:38 PM, Zach the Mystic wrote:
Unfortunately, even Boeing isn't what it used to be:
https://www.youtube.com/watch?v=rvkEpstd9os
One thing that one learns when working on engineering projects
is journalists have z
On 1/26/2015 5:41 PM, Joakim wrote:
I've often thought that it's precisely because Walter is not a CS grad and has a
real engineering background that D is so good, particularly since it means he's
less likely to go chasing the CS fad of the moment. Also, I'd guess that's
where his pragmatic bent
On 1/26/2015 6:38 PM, Zach the Mystic wrote:
Unfortunately, even Boeing isn't what it used to be:
https://www.youtube.com/watch?v=rvkEpstd9os
One thing that one learns when working on engineering projects is journalists
have zero engineering and mathematical knowledge, and what they write abo
On Tuesday, 27 January 2015 at 01:41:31 UTC, Joakim wrote:
I was just surfing reddit and this exchange with Walter made me
LOL, talking about students who learn programming for the first
time in college:
Walter: Why would you say that? Very few of them actually even
studied CS - they learned
On Tuesday, 27 January 2015 at 02:30:12 UTC, Zach the Mystic
wrote:
On Tuesday, 27 January 2015 at 01:31:07 UTC, Jonathan Marler
wrote:
Yes you're right it adds more inconsistency (sorry what I said
was wrong). However, no matter what solution you choose you
have to choose one of two evils. E
On 1/26/2015 6:15 PM, Zach the Mystic wrote:
What's keeping you from committing to 'dfix' as the way to solve issues like the
one in this thread?
Inertia of people being reluctant to use it. It's still work for people to use,
it's not part of their build process.
On Tuesday, 27 January 2015 at 01:41:31 UTC, Joakim wrote:
I was just surfing reddit and this exchange with Walter made me
LOL, talking about students who learn programming for the first
time in college:
Walter: Why would you say that? Very few of them actually even
studied CS - they learned
On Monday, 26 January 2015 at 20:55:14 UTC, Wyatt wrote:
On Monday, 26 January 2015 at 20:19:09 UTC, Laeeth Isharc wrote:
Does Rust have the productivity of D? And it doesn't have the
maturity, as I understand it.
This brings up something that's been bugging me. D has a pitch
for users of
On Tuesday, 27 January 2015 at 01:31:07 UTC, Jonathan Marler
wrote:
Yes you're right it adds more inconsistency (sorry what I said
was wrong). However, no matter what solution you choose you
have to choose one of two evils. Either add inconsistency or
break code. There's no way around it. I
On Mon, 26 Jan 2015 17:07:26 +
Nick Treleaven via Digitalmars-d wrote:
> > In fact, priore to this, @safe,
> > @trusted, @system, and @property were the_only_ function
> > attributes with @ on them.
>
> There's also @disable and more recently, @nogc.
You're right. I forgot about those two. B
On Monday, 26 January 2015 at 18:19:18 UTC, H. S. Teoh wrote:
On Mon, Jan 26, 2015 at 10:09:45AM -0800, Andrei Alexandrescu
via Digitalmars-d wrote:
...is what took to get std.experimental.logger in Phobos.
https://github.com/D-Programming-Language/phobos/pull/1500
A time to celebrate! Many th
On Tuesday, 27 January 2015 at 01:49:41 UTC, Walter Bright wrote:
On 1/26/2015 5:45 PM, uri wrote:
I get the impression it will never be finished because too
many are afraid of
important breaking changes that seem necessary to get through
the last 5%-10% of
D2.
Half want breaking changes, th
On Tuesday, 27 January 2015 at 01:55:30 UTC, Walter Bright wrote:
On 1/26/2015 3:07 PM, Jonathan Marler wrote:
Walter I hate to waste your time in answering my silly
questions. I know you
have a much deeper knowledge and understanding of the language
then I. I can
see that you believe my sugg
On 1/26/2015 3:07 PM, Jonathan Marler wrote:
Walter I hate to waste your time in answering my silly questions. I know you
have a much deeper knowledge and understanding of the language then I. I can
see that you believe my suggestion would create some unnecessary complexity
("It's like using a
On 1/26/2015 2:15 PM, Foo wrote:
Because you/we are community members and therefore "second-class citizens".
If we suggest or discuss something, it is not that important. But if a small
reddit post is made, it matters more.
Major contributors to D, like Don Clugston, advocated for it.
It comes
On 1/26/2015 2:57 PM, Mike wrote:
On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote:
if we deprecate pure and nothrow without @, then we'll be
forced to change pretty much every D program in existence.
A trivial search and replace. Some might be against this change now, but
On 01/26/15 23:10, Walter Bright via Digitalmars-d wrote:
> On 1/26/2015 1:45 PM, Artur Skawina via Digitalmars-d wrote:
>>> Just 'no' on context-sensitive tokens.
>> C. C++. D. Windows. Pascal. System. exit. success. failure.
>
> They're never keywords.
Hence, some other ones also don't really n
On 1/26/2015 5:45 PM, uri wrote:
I get the impression it will never be finished because too many are afraid of
important breaking changes that seem necessary to get through the last 5%-10% of
D2.
Half want breaking changes, the other half wants stability.
On Tuesday, 27 January 2015 at 01:32:23 UTC, Mike wrote:
On Monday, 26 January 2015 at 19:51:08 UTC, Walter Bright wrote:
On 1/26/2015 3:39 AM, Jonathan M Davis via Digitalmars-d wrote:
Personally, I'd much prefer that we not make this change.
It's good to have this discussion.
Previously, i
I was just surfing reddit and this exchange with Walter made me
LOL, talking about students who learn programming for the first
time in college:
Walter: Why would you say that? Very few of them actually even
studied CS - they learned programming on the side. As did I, my
degree is in mechanic
On Tuesday, 27 January 2015 at 01:14:01 UTC, Zach the Mystic
wrote:
On Tuesday, 27 January 2015 at 00:57:24 UTC, Jonathan Marler
wrote:
On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the Mystic
3. Singularity of usage also matters. There should only be one
way to mark a given attribute, eith
On Monday, 26 January 2015 at 19:51:08 UTC, Walter Bright wrote:
On 1/26/2015 3:39 AM, Jonathan M Davis via Digitalmars-d wrote:
Personally, I'd much prefer that we not make this change.
It's good to have this discussion.
Previously, it's all been advocacy and "break my code" by
forcing a ch
On Tuesday, 27 January 2015 at 00:57:24 UTC, Jonathan Marler
wrote:
On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the Mystic
3. Singularity of usage also matters. There should only be one
way to mark a given attribute, either with or without `@`.
I agree that the proposal doesn't solve the
On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the Mystic
wrote:
On Tuesday, 27 January 2015 at 00:05:17 UTC, Jonathan Marler
wrote:
Haha, ok, sorry for being too abstract.
I think a safe way to implement my proposal would be to do
what c++ did and only allow non-keyword function attributes
On Tuesday, 27 January 2015 at 00:05:17 UTC, Jonathan Marler
wrote:
Haha, ok, sorry for being too abstract.
I think a safe way to implement my proposal would be to do what
c++ did and only allow non-keyword function attributes to omit
the '@' symbol if they appear after the function signature:
Yup, most people like to shit on Java, but quite frankly, the
ecosystem is way ahead of what exists on most platform.
It is even fairly common to get a Java program up and running +
tweaking of the JVM is less time and with better performance than
what you would have in C++.
Obviously, given
On Monday, 26 January 2015 at 23:55:55 UTC, Zach the Mystic wrote:
On Monday, 26 January 2015 at 23:53:22 UTC, Jonathan Marler
wrote:
http://en.wikipedia.org/wiki/Straw_man
I'm not proposing that we don't allow attributes before a
function, I was mentioning an idea related to my proposal. I
On Monday, 26 January 2015 at 18:25:13 UTC, Robert burner Schadek
wrote:
thank you @!"In order of appearance on github"() { Dicebot,
JakobOvrum, monarchdodra, klamonte, grogancolin, fugalh,
Geod24, andralex, braddr, AndrejMitrovic, MetaLang, p0nce,
yglukhov, elendel-, sigod, sybrandy, DmitryOls
On Monday, 26 January 2015 at 20:26:02 UTC, Dicebot wrote:
It was sad that calls for more breakage were mostly ignored.
But there is one thing now that is even worse - referring to
#pleasebreakmycode as an excuse to introduce random changes
based on random reddit comment - and completely dismis
On Monday, 26 January 2015 at 23:53:22 UTC, Jonathan Marler wrote:
http://en.wikipedia.org/wiki/Straw_man
I'm not proposing that we don't allow attributes before a
function, I was mentioning an idea related to my proposal. I
agree with everything you said, you're just not addressing the
prop
On Monday, 26 January 2015 at 23:50:12 UTC, Zach the Mystic wrote:
Yes it *is* another debate. Now you can't add attributes at the
beginning:
// no can do anymore
nogc pure myUda
retType funcName() {
...
}
// must do this instead
retType funcName() nogc pure myUdal {
}
You're suggesting ca
On Monday, 26 January 2015 at 23:50:12 UTC, Zach the Mystic wrote:
On Monday, 26 January 2015 at 23:32:59 UTC, Jonathan Marler
wrote:
Copy/Paste:
solution). By restricting the attributes to only appear
after a function signature, it would also normalize the
issue of consistent location of at
On Monday, 26 January 2015 at 20:58:36 UTC, Dicebot wrote:
Don't forget that there is already
http://dlang.org/phobos/std_algorithm.html#.group which matches
groupBy in this context (only groups consequitive elements). It
would be totally awkward to have those named differently (which
was why
On Monday, 26 January 2015 at 23:32:59 UTC, Jonathan Marler wrote:
Copy/Paste:
solution). By restricting the attributes to only appear
after a function signature, it would also normalize the issue
of consistent location of attributes, but this is another
debate.
The return type doesn't app
On Monday, 26 January 2015 at 23:41:07 UTC, Zach the Mystic wrote:
On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler
wrote:
The lexer would recognize these attributes as normal ID tokens.
The grammar could be amended to allow a function to be
decorated with keywords and generic id tok
On Monday, 26 January 2015 at 20:55:14 UTC, Wyatt wrote:
On Monday, 26 January 2015 at 20:19:09 UTC, Laeeth Isharc wrote:
Does Rust have the productivity of D? And it doesn't have the
maturity, as I understand it.
This brings up something that's been bugging me. D has a pitch
for users of
On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler wrote:
The lexer would recognize these attributes as normal ID tokens.
The grammar could be amended to allow a function to be
decorated with keywords and generic id tokens. Then the
meaning of those tokens would be handled by semanti
On Monday, 26 January 2015 at 22:04:48 UTC, Zach the Mystic wrote:
On Monday, 26 January 2015 at 21:37:43 UTC, Jonathan Marler
wrote:
I think the short answer is that it's WAY too complicated for
the benefit. Also, why burden the syntax highlighter, let
alone the human reader, with ambiguities
On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi
wrote:
If someone is not following the merges, well... [1] !!
---
Paolo
[1]
http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034...@hookshot-fe4-cp1-prd.iad.github.net.mail
In case anybody was wondering, dfix has had the a
On Monday, 26 January 2015 at 22:09:44 UTC, Walter Bright wrote:
On 1/26/2015 1:25 PM, Jonathan Marler wrote:
The lexer would recognize these attributes as normal ID
tokens. The grammar
could be amended to allow a function to be decorated with
keywords and generic
id tokens. Then the meaning o
On Monday, 26 January 2015 at 21:51:03 UTC, Zach the Mystic wrote:
On Monday, 26 January 2015 at 19:50:39 UTC, H. S. Teoh wrote:
If it takes just as much effort to get it into
std.experimental as it
would take to get into std directly, I don't see the point of
the
additional hassle introduced
On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis
wrote:
if we deprecate pure and nothrow without @, then we'll be
forced to change pretty much every D program in existence.
A trivial search and replace. Some might be against this change
now, but 5 years from we'll profit from i
On Monday, 26 January 2015 at 22:12:24 UTC, Laeeth Isharc wrote:
" If Java consumes 15% more power doing it, does
it matter on a PC? Most people don't dare. Does it matter for
small-scale server environments? Maybe not. Does it matter
when you deploy Hadoop on a 10,000 node cluster, and the
ho
On 26.01.15 23:08, Walter Bright wrote:
>
> I strongly dislike context sensitive tokens, whether or not they are
> done by the lexer or the parser or the semantic analysis.
>
> It's like using a nail for a cotter pin.
I remember the first time I read about D was something like "make language
e
On Monday, 26 January 2015 at 18:31:05 UTC, Andrei Alexandrescu
wrote:
So the key (ahem) here is to make groupBy with unary predicate
different from groupBy with binary predicate. The former
returns the tuple, the latter is unchanged. Makes sense?
The current implementation has a certain bea
On 1/20/2015 4:23 AM, Benjamin Thaut wrote:
I'm currently working on Windows DLL support which has stronger rules than linux
shared objects for which symbols actually get exported from a shared library.
But as we want to replicate the same behaviour on linux using symbol visibility
(e.g. gcc 4 -f
https://www.reddit.com/r/programming/comments/2tqiaj/d_is_like_native_python/?sort=confidence
On Monday, 26 January 2015 at 20:08:44 UTC, Vladimir Panteleev
wrote:
On Monday, 26 January 2015 at 18:41:09 UTC, Laeeth Isharc wrote:
Why not create a bugzilla section for website and forum so it
is easier to report glitches and enhancement requests in a way
that you will quickly see without d
On Monday, 26 January 2015 at 21:41:31 UTC, Jonathan Marler wrote:
On Monday, 26 January 2015 at 21:28:14 UTC, Foo wrote:
On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler
wrote:
On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright
wrote:
On 1/26/2015 12:45 PM, Jonathan Marler w
On 1/26/2015 1:45 PM, Artur Skawina via Digitalmars-d wrote:
C. C++. D. Windows. Pascal. System. exit. success. failure.
They're never keywords.
" If Java consumes 15% more power doing it, does
it matter on a PC? Most people don't dare. Does it matter for
small-scale server environments? Maybe not. Does it matter
when you deploy Hadoop on a 10,000 node cluster, and the
holistic inefficiency (multiple things running concurrently)
goes t
On Monday, 26 January 2015 at 18:19:18 UTC, H. S. Teoh wrote:
Certainly, this deserves celebration!
But OTOH, if *this* is what it takes to contribute a new module
to
Phobos, then it's no wonder we have trouble finding
contributors...
Most would give up before they even try. I think there's an
On Monday, 26 January 2015 at 20:55:14 UTC, Wyatt wrote:
On Monday, 26 January 2015 at 20:19:09 UTC, Laeeth Isharc wrote:
Does Rust have the productivity of D? And it doesn't have the
maturity, as I understand it.
This brings up something that's been bugging me. D has a pitch
for users of
On 1/26/2015 1:29 PM, Dicebot wrote:
However my complaint is not about the change itself (though I personally
disagree with Don reasoning in that issue, it is a delicate matter) but about
the fact that it is again done as a casual PR and our breaking change culture
does not seem to change : it is
On 1/26/2015 1:25 PM, Jonathan Marler wrote:
The lexer would recognize these attributes as normal ID tokens. The grammar
could be amended to allow a function to be decorated with keywords and generic
id tokens. Then the meaning of those tokens would be handled by semantic
analysis.
Not going t
Examples:
[1]:
https://github.com/D-Programming-Language/druntime/blob/2024ca6d3e29362a2fc84ef51c0f73316259d645/src/core/internal/traits.d#L57
[2]:
https://github.com/D-Programming-Language/phobos/blob/de5d3392782c85e79e71e257b3ba607ccff852a5/std/typecons.d#L3240
On Monday, 26 January 2015
That's what pragma(mangle, "...")[1] is for. It is used at least
a couple of times in druntime (and probably elsewhere - e.g. in
library bindings).
[1]: http://dlang.org/pragma.html (at the bottom of the page)
On Monday, 26 January 2015 at 21:56:20 UTC, Ola Fosheim Grøstad
wrote:
On Monday,
On Monday, 26 January 2015 at 21:37:43 UTC, Jonathan Marler wrote:
I think the short answer is that it's WAY too complicated for
the benefit. Also, why burden the syntax highlighter, let
alone the human reader, with ambiguities like this?
I wasn't saying that we should introduce ambiguity, I w
On Sunday, 25 January 2015 at 21:50:53 UTC, Laeeth Isharc wrote:
The author talks about C++ performance but D can match it
whilst bringing scripting language style programmer
productivity, and arguably higher quality code (because you can
understand the code base as a coherent whole). Integra
On Monday, 26 January 2015 at 21:28:51 UTC, Zach the Mystic wrote:
I think the short answer is that it's WAY too complicated for
the benefit. Also, why burden the syntax highlighter, let alone
the human reader, with ambiguities like this?
There is no ambiguity in "object.body" or even "object.
On Monday, 26 January 2015 at 19:50:39 UTC, H. S. Teoh wrote:
If it takes just as much effort to get it into std.experimental
as it
would take to get into std directly, I don't see the point of
the
additional hassle introduced by std.experimental.
T
I agree - be shameless with what you put
On 1/22/15 11:37 AM, weaselcat wrote:
Might be of use to someone, but I was looking for ways to speed up dmd's
albeit already fast compilation times.
Just by dropping in jemalloc in place of glibc's malloc via LD_PRELOAD
on my linux machine I saw a 10-15% drop in compilation times across the
boa
As far as I know, the current groupBy docs explain quite
clearly what it
does. If you find it still inadequate or unclear, please file
bug against it so that we can look into improving the docs.
Read the docs now - they are perfect within the context of the
style of documentation (and these d
On 01/26/15 20:43, Walter Bright via Digitalmars-d wrote:
> On 1/26/2015 8:13 AM, Foo wrote:
>> You could do the same as C++ with override and final: they are only valid
>> attributes if they appear _after_ the function/method. Elsewhere they are
>> still
>> valid as identifiers for e.g. variables
On Monday, 26 January 2015 at 21:28:14 UTC, Foo wrote:
On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler
wrote:
On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright
wrote:
On 1/26/2015 12:45 PM, Jonathan Marler wrote:
Just because they are function attributes does not mean
they
On Monday, 26 January 2015 at 21:28:51 UTC, Zach the Mystic wrote:
On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler
wrote:
I agree with Jonathan's points, this solution doesn't seem
like an improvement. If I understand the problem, we don't
want to make every attribute use the '@'
On Monday, 26 January 2015 at 18:09:46 UTC, Andrei Alexandrescu
wrote:
...is what took to get std.experimental.logger in Phobos.
https://github.com/D-Programming-Language/phobos/pull/1500
A time to celebrate! Many thanks to Robert who carried it
through a long gestation, Dicebot for managing t
On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright wrote:
On 1/26/2015 12:45 PM, Jonathan Marler wrote:
Just because they are function attributes does not mean
they were tokenized as "keywords".
The lexer has no idea what a function attribute is or that now
it should be looking for att
On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler wrote:
On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright wrote:
On 1/26/2015 12:45 PM, Jonathan Marler wrote:
Just because they are function attributes does not mean
they were tokenized as "keywords".
The lexer has no idea wh
On Monday, 26 January 2015 at 21:17:50 UTC, Walter Bright wrote:
Donno If you are referring to this [1], but at least it's
about this pull...
[1]
http://forum.dlang.org/thread/bug-1338...@https.issues.dlang.org%2F?page=3#post-mailman.312.1409643575.5783.digitalmars-d-bugs:40puremagic.com
Yup,
On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler wrote:
I agree with Jonathan's points, this solution doesn't seem like
an improvement. If I understand the problem, we don't want to
make every attribute use the '@' symbol because it looks bad
and would cause a lot of code changes f
Walter Bright:
Previously, it's all been advocacy and "break my code"
Breaking the code should be justified by a worth gain. This patch
is of negative value.
Bye,
bearophile
On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright wrote:
On 1/26/2015 12:45 PM, Jonathan Marler wrote:
Just because they are function attributes does not mean
they were tokenized as "keywords".
The lexer has no idea what a function attribute is or that now
it should be looking for att
On 1/26/2015 1:07 PM, Paolo Invernizzi wrote:
On Monday, 26 January 2015 at 20:56:36 UTC, Walter Bright wrote:
On 1/26/2015 12:26 PM, Dicebot wrote:
It was sad that calls for more breakage were mostly ignored. But there is one
thing now that is even worse - referring to #pleasebreakmycode as an
On 1/26/2015 12:45 PM, Jonathan Marler wrote:
Just because they are function attributes does not mean
they were tokenized as "keywords".
The lexer has no idea what a function attribute is or that now it should be
looking for attributes and then it should not be.
On Monday, 26 January 2015 at 20:56:36 UTC, Walter Bright wrote:
On 1/26/2015 12:26 PM, Dicebot wrote:
It was sad that calls for more breakage were mostly ignored.
But there is one
thing now that is even worse - referring to #pleasebreakmycode
as an excuse to
introduce random changes based on r
Thank you for the thoughtful reply.
I meant lost in terms of extra processing time and memory
consumption in order to achieve the fairly common use case of a
groupby pivot table or pandas style (ie what you get if you sort
the data by group and then run D groupby)
If you first sort the data,
1 - 100 of 202 matches
Mail list logo
