On Mon, Sep 05, 2016 at 03:08:53PM +1000, Manu via Digitalmars-d wrote:
> I mostly code like this now:
> data.map!(x => transform(x)).copy(output);
>
> It's convenient and reads nicely, but it's generally inefficient.
> This sort of one-by-one software design is the core performance
> problem wi
On 9/4/2016 9:23 PM, Manu via Digitalmars-d wrote:
I already worked-around my problems. But the point of my post is that
I feel the problem is of very high importance. I don't think the
situation is okay, since we're making design recommendations that lead
straight to these problems. And these mo
On 05/09/2016 5:20 PM, Walter Bright wrote:
On 9/4/2016 5:15 PM, w0rp wrote:
A noble goal. The trick is probably all in careful use of markup. alt
tags, aria
text, tab ordering. You can probably test various pages on the site by
listening
to the output of screen readers.
The thing is, I have n
On 9/4/2016 5:15 PM, w0rp wrote:
A noble goal. The trick is probably all in careful use of markup. alt tags, aria
text, tab ordering. You can probably test various pages on the site by listening
to the output of screen readers.
The thing is, I have no idea how experienced screen reader programm
On 05/09/2016 5:08 PM, Manu via Digitalmars-d wrote:
I mostly code like this now:
data.map!(x => transform(x)).copy(output);
It's convenient and reads nicely, but it's generally inefficient.
This sort of one-by-one software design is the core performance
problem with OOP. It seems a shame to b
On Sunday, 4 September 2016 at 12:51:05 UTC, Andrei Alexandrescu
wrote:
See
http://forum.dlang.org/post/ymkehalxcigswvltl...@forum.dlang.org
There are a few cases I can think of:
The classical ones, but again the question was for introspection
without access (b/c named access through getMemb
I mostly code like this now:
data.map!(x => transform(x)).copy(output);
It's convenient and reads nicely, but it's generally inefficient.
This sort of one-by-one software design is the core performance
problem with OOP. It seems a shame to be suffering OOP's failures even
when there is no OOP in
On 4 September 2016 at 03:44, Marco Leise via Digitalmars-d
wrote:
> Am Sat, 3 Sep 2016 16:01:26 +1200
> schrieb rikki cattermole :
>
>> On 03/09/2016 12:17 PM, Manu via Digitalmars-d wrote:
>> ...snip...
>>
>> > I think the presence of all this colour space information as type
>> > arguments shou
On 5 September 2016 at 10:50, Walter Bright via Digitalmars-d
wrote:
> On 9/4/2016 2:36 PM, Timon Gehr wrote:
>>
>> Declare-call ordering issues for overload sets are not limited to local
>> scopes.
>> This problem needs to be solved anyway. The fact that the scope is local
>> adds
>> exactly zero
On 5 September 2016 at 14:05, Manu wrote:
>
> I've seen this one. Again, we're not talking about C++. It hasn't been
> explored (to my knowledge) how a similar mechanism it would look and
> affect D. I suspect (with no evidence) it would be relatively benign
> by comparison to the problems ADL int
On 4 September 2016 at 07:38, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 9/3/16 11:31 AM, Manu via Digitalmars-d wrote:
>>>
>>> > In any case, these difficulties are the consequence of trying to write
>>> > C++
>>> > code in D.
>>
>> You've told me this before, and I find it kind of offensi
On 9/4/2016 1:48 PM, Ethan Watson wrote:
Chipping in to say that I currently do something this with Binderoo templates...
and it sucks.
What about using this template?
// Find module in which T was defined
template ModuleOf(alias T)
{
import std.traits : moduleName;
mixin("import " ~ m
On 9/4/2016 2:36 PM, Timon Gehr wrote:
Declare-call ordering issues for overload sets are not limited to local scopes.
This problem needs to be solved anyway. The fact that the scope is local adds
exactly zero additional complications.
I know that static if brings with it ordering problems. Tha
On Sunday, 4 September 2016 at 20:01:21 UTC, Walter Bright wrote:
https://news.ycombinator.com/item?id=12424656
It is our ethical duty to make D and dlang.org usable for
visually impaired programmers. If any of you are visually
impaired, or have programmer friends/colleagues who are, a
review
On 04.09.2016 22:22, Walter Bright wrote:
On 9/4/2016 5:30 AM, Andrei Alexandrescu wrote:
Might be a sensible enhancement. Removing artificial limitations is good
programming language design. Turtles! -- Andrei
The design of executable function bodies is very much "declare before
use", quite u
On Saturday, 3 September 2016 at 01:09:18 UTC, Walter Bright
wrote:
Fourth solution:
module myalgorithm;
void test(T)(T t)
{
import std.traits;
mixin("import " ~ std.traits.moduleName!T ~ ";");
mixin("alias M = " ~ std.traits.moduleName!T ~ ";");
// T
On 9/4/2016 5:30 AM, Andrei Alexandrescu wrote:
Might be a sensible enhancement. Removing artificial limitations is good
programming language design. Turtles! -- Andrei
The design of executable function bodies is very much "declare before use",
quite unlike at the declaration levels which is a
On 9/4/2016 5:31 AM, Andrei Alexandrescu wrote:
On 9/4/16 3:26 AM, Walter Bright wrote:
On 9/3/2016 4:46 PM, Andrei Alexandrescu wrote:
On 9/4/16 12:28 AM, Walter Bright wrote:
On 9/3/2016 1:43 PM, Andrei Alexandrescu wrote:
On 9/3/16 10:43 PM, Walter Bright wrote:
On 9/3/2016 8:34 AM, Manu
On 9/4/2016 10:56 AM, David Nadlinger wrote:
This is short-sighted, for the reason I pointed out in my earlier post. How
would you go about reporting an ICE for a 100k LOC test case without any idea
about where to start looking?
I do that often. Binary search quickly reduces even the biggest co
https://news.ycombinator.com/item?id=12424656
It is our ethical duty to make D and dlang.org usable for visually impaired
programmers. If any of you are visually impaired, or have programmer
friends/colleagues who are, a review of what we can do to improve would be
appreciated.
On Sunday, 4 September 2016 at 12:38:05 UTC, Andrei Alexandrescu
wrote:
On 9/4/16 6:14 AM, Stefan Koch wrote:
writeln and __ctfeWriteln are to be regarded as completely
different
things.
__ctfeWriteln is a debugging tool only!
It should not be used in any production code.
Well I'm not sure ho
On Sunday, 4 September 2016 at 17:56:08 UTC, David Nadlinger
wrote:
On Saturday, 3 September 2016 at 22:39:22 UTC, Walter Bright
wrote:
Because it's useless to anyone but the compiler devs, and it
adds cruft to the compiler. And even worse than useless, it
confuses the user into thinking it is
On Saturday, 3 September 2016 at 22:39:22 UTC, Walter Bright
wrote:
Because it's useless to anyone but the compiler devs, and it
adds cruft to the compiler. And even worse than useless, it
confuses the user into thinking it is a meaningful message.
This is short-sighted, for the reason I point
On Sunday, 4 September 2016 at 17:37:28 UTC, David Nadlinger
wrote:
In this case, it's seems to be a race condition between Travis
trying to check out the branch to test, and GitHub actually
serving it up (or you removing it again).
Oh, wait, this is on a branch in the main dlang repo, as crea
On Sunday, 4 September 2016 at 14:46:56 UTC, Andrei Alexandrescu
wrote:
Can we do the same? How can we make sure that a Travis failure
always is legit and needs action?
In this case, it's seems to be a race condition between Travis
trying to check out the branch to test, and GitHub actually
s
I'm getting emails about Travis CI builds failing, even for changes that
clearly cause no breakage (e.g.
https://travis-ci.org/dlang/dmd/builds/157445381).
After a few of those, what I feared will happen has happened: I
effectively treat all similar messages as noise I just delete from
Inbox.
On Sunday, 4 September 2016 at 10:33:44 UTC, Walter Bright wrote:
As I mentioned before, assert failures are usually the result
of the last edit one did. The problem is already narrowed down.
I got the error at the start of the thread because I added a
variable to a class. The class is having
On Sunday, 4 September 2016 at 05:13:49 UTC, Walter Bright wrote:
If you're willing to look at the file/line of where the assert
tripped, I don't see how a message would save any time at all.
The level builders at Remedy are going to be using D as a
scripting language. If they get an error lik
On 05/09/2016 2:19 AM, Shachar Shemesh wrote:
I understand you don't see the need, but I'd like you to consider the
possibility that having more people able to hack the front end is also
something that would help to give D a boost. If the cost of becoming a
compiler developer was lower, wouldn't
On Sunday, 4 September 2016 at 00:09:50 UTC, Stefan Koch wrote:
Perhaps the best error message would be "Please post this as a
bug to bugzilla."
I'd say that's in addition to getting rid of assert(0), not
instead of.
On Saturday, 3 September 2016 at 22:53:25 UTC, Walter Bright
wrote:
Adding more text to the assert message is not helpful to end
users.
Really? I've highlighted several cases just in this one function
in glue.c that would have saved me hours of time.
On 04/09/16 01:39, Walter Bright wrote:
On 9/3/2016 6:14 AM, Jacob Carlborg wrote:
What kind of issue due you see with trying to print some form of
information
when an assertion fails?
Because it's useless to anyone but the compiler devs, and it adds cruft
to the compiler. And even worse than
On 9/4/16 2:37 PM, David Nadlinger wrote:
On Sunday, 4 September 2016 at 12:33:07 UTC, Andrei Alexandrescu wrote:
Thanks for answering. Yes, we really need introspection of private
members. One way or another we need to support that.
Do we, though? It's easy to state a general claim like this,
On 9/4/16 5:45 AM, Martin Nowak wrote:
A public setter for private members is weird
How do you mean that? It's an absolute classic. Please elaborate,
thanks. -- Andrei
On 9/4/16 11:09 AM, Martin Nowak wrote:
On Saturday, 3 September 2016 at 16:52:50 UTC, Martin Nowak wrote:
On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote:
Well let's come up with a better solution then.
Let's start by finding some proper use-cases that require
introspection on pri
On Sunday, 4 September 2016 at 12:37:47 UTC, David Nadlinger
wrote:
Do we, though? It's easy to state a general claim like this,
but I find it hard to actually justify.
(And to pre-empt the collective freak-out, note that this
statement is coming from somebody who has done quite a bit of
pion
On 9/4/16 6:14 AM, Stefan Koch wrote:
writeln and __ctfeWriteln are to be regarded as completely different
things.
__ctfeWriteln is a debugging tool only!
It should not be used in any production code.
Well I'm not sure how that would be reasonably enforced. -- Andrei
On Sunday, 4 September 2016 at 12:33:07 UTC, Andrei Alexandrescu
wrote:
Thanks for answering. Yes, we really need introspection of
private members. One way or another we need to support that.
Do we, though? It's easy to state a general claim like this, but
I find it hard to actually justify.
On 9/4/16 5:56 AM, Martin Nowak wrote:
On Saturday, 3 September 2016 at 19:31:12 UTC, Jacob Carlborg wrote:
That can usually be solved using .tupleof[i], but I agree.
Well, .tupleof gives you a typed representation of the memory layout, to
me it's something different than qualified access of f
On 9/4/16 6:10 AM, rikki cattermole wrote:
On 04/09/2016 2:08 PM, Stefan Koch wrote:
On Sunday, 4 September 2016 at 02:06:55 UTC, Stefan Koch wrote:
This works already.
Anything placed in a debug {} block will be considered pure regardless.
Opps your comment was about the debate.
I would say
On 9/4/16 5:14 AM, Martin Nowak wrote:
If we really need introspection of private members than we might need to
go back to the drawing board and modify the visibility concept
introduced with DIP22.
Thanks for answering. Yes, we really need introspection of private
members. One way or another w
On 9/4/16 3:26 AM, Walter Bright wrote:
On 9/3/2016 4:46 PM, Andrei Alexandrescu wrote:
On 9/4/16 12:28 AM, Walter Bright wrote:
On 9/3/2016 1:43 PM, Andrei Alexandrescu wrote:
On 9/3/16 10:43 PM, Walter Bright wrote:
On 9/3/2016 8:34 AM, Manu via Digitalmars-d wrote:
And if either module do
On 9/4/16 2:36 AM, Timon Gehr wrote:
On 03.09.2016 13:24, Walter Bright wrote:
Something like:
void foo(T,U)(T t, U u)
{
alias func = ModuleOf!T.func;
alias func = ModuleOf!U.func;
func(t, u);
}
Does not work. Local overloads are not supported.
Might be a sensible enhancement.
On 2016-09-04 05:45, Martin Nowak wrote:
A public setter for private members is weird, but well.
The setter can do validations, manipulation and other kinds of
calculations based on the given value.
--
/Jacob Carlborg
On 2016-09-04 09:39, Johannes Pfau wrote:
Allowing access to private fields / functions also means that
those members are part of the public API/ABI of a library. So changing
private members can break dependent libraries...
They've always been accessible using .tupleof and taking the address o
On Sunday, 4 September 2016 at 10:33:44 UTC, Walter Bright wrote:
On 9/4/2016 2:17 AM, John Colvin wrote:
On Sunday, 4 September 2016 at 05:13:49 UTC, Walter Bright
wrote:
On 9/3/2016 7:35 PM, John Colvin wrote:
In my experience getting a clue as to what is was the
compiler didn't like is
very
On Sunday, 4 September 2016 at 10:46:25 UTC, develop32 wrote:
Certainly just stating that an assert was triggered in this and
this line of the backend is not enough?
Often it is actually enough because compiler developer can check
last changes to related code and propose simple checks to nail
On Sunday, 4 September 2016 at 10:33:44 UTC, Walter Bright wrote:
As I mentioned before, assert failures are usually the result
of the last edit one did. The problem is already narrowed down.
That's just not true in my case. Most of the asserts I triggered
were after updating to a newer compi
On 9/4/2016 2:17 AM, John Colvin wrote:
On Sunday, 4 September 2016 at 05:13:49 UTC, Walter Bright wrote:
On 9/3/2016 7:35 PM, John Colvin wrote:
In my experience getting a clue as to what is was the compiler didn't like is
very useful. Often the only way I can find a workaround is by locating
On Sunday, 4 September 2016 at 05:13:49 UTC, Walter Bright wrote:
On 9/3/2016 7:35 PM, John Colvin wrote:
In my experience getting a clue as to what is was the compiler
didn't like is
very useful. Often the only way I can find a workaround is by
locating the
assert in the compiler source and wo
On Saturday, 3 September 2016 at 16:52:50 UTC, Martin Nowak wrote:
On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote:
Well let's come up with a better solution then.
Let's start by finding some proper use-cases that require
introspection on private members w/o having access to them.
On Sunday, 4 September 2016 at 08:42:43 UTC, Martin Nowak wrote:
On Sunday, 4 September 2016 at 07:24:42 UTC, Basile B. wrote:
The introspection creates a special structure for each
property annotated with @Set, @Get, or @SetGet. This is a kind
of interface for serialization/binding/object insp
On Sunday, 4 September 2016 at 07:24:42 UTC, Basile B. wrote:
The introspection creates a special structure for each property
annotated with @Set, @Get, or @SetGet. This is a kind of
interface for serialization/binding/object inspector (a bit
like "published" in Object Pascal).
But you can't
On 9/3/2016 2:54 PM, Jacob Carlborg wrote:
On 2016-09-03 22:40, Andrei Alexandrescu wrote:
That... doesn't sound good. I wonder how such important changes slip by
Walter and myself unnoticed.
Here's the PR that introduced the change: https://github.com/dlang/dmd/pull/6078
Looks like I'm to
On 8/31/2016 7:31 AM, Ethan Watson wrote:
On Wednesday, 31 August 2016 at 14:05:16 UTC, Chris Wright wrote:
Specifying the default value for the type.
Alias has the same problem in this case.
Alias is not a different type from the underlying type. So having a different
default value makes n
Am Sun, 04 Sep 2016 03:29:59 +
schrieb Martin Nowak :
> On Sunday, 4 September 2016 at 03:21:05 UTC, Stefan Koch wrote:
> > While I do understand, that there could be a potential
> > performance when private members could be changed around
> > because they are not visible form outside.
> >
On Sunday, 4 September 2016 at 03:45:50 UTC, Martin Nowak wrote:
On Saturday, 3 September 2016 at 17:23:53 UTC, Basile B. wrote:
On Saturday, 3 September 2016 at 16:52:50 UTC, Martin Nowak
wrote:
On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote:
I don't agree with the current solu
On 9/3/2016 10:57 PM, ZombineDev wrote:
What do you think about making overloading and UFCS work with local symbols?
I'd rather not. Let's make what we have work. There's an unending demand for new
features in the core language.
> There are workarounds, but nothing pretty.
I don't regard t
58 matches
Mail list logo
