On 12/30/11 10:09 PM, Walter Bright wrote:
On 12/30/2011 7:30 PM, Jonathan M Davis wrote:
Yes, diligent programmers will generally find such problems, but with the
current scheme, it's _so_ easy to use length when you shouldn't, that
it's
pretty much a guarantee that it's going to happen.
I'm
On 12/30/2011 10:50 PM, Walter Bright wrote:
On 12/30/2011 8:34 PM, Timon Gehr wrote:
On 12/31/2011 05:19 AM, Walter Bright wrote:
On 12/30/2011 8:02 PM, Timon Gehr wrote:
On 12/31/2011 04:50 AM, Walter Bright wrote:
Because inevitably someone will write:
#define FOO a + FOO
and expect it t
On 12/30/2011 8:34 PM, Timon Gehr wrote:
On 12/31/2011 05:19 AM, Walter Bright wrote:
On 12/30/2011 8:02 PM, Timon Gehr wrote:
On 12/31/2011 04:50 AM, Walter Bright wrote:
Because inevitably someone will write:
#define FOO a + FOO
and expect it to work (the correct expansion would be "a + FO
On 12/31/2011 05:19 AM, Walter Bright wrote:
On 12/30/2011 8:02 PM, Timon Gehr wrote:
On 12/31/2011 04:50 AM, Walter Bright wrote:
Because inevitably someone will write:
#define FOO a + FOO
and expect it to work (the correct expansion would be "a + FOO", not a
stack overflow). The C preproces
On 12/30/2011 8:02 PM, Timon Gehr wrote:
On 12/31/2011 04:50 AM, Walter Bright wrote:
Because inevitably someone will write:
#define FOO a + FOO
and expect it to work (the correct expansion would be "a + FOO", not a
stack overflow). The C preprocessor works this way, as do makefile
macros, as
On 12/30/2011 7:30 PM, Jonathan M Davis wrote:
Yes, diligent programmers will generally find such problems, but with the
current scheme, it's _so_ easy to use length when you shouldn't, that it's
pretty much a guarantee that it's going to happen.
I'm not so sure about that. Timon Gehr's X macro
On 12/31/2011 04:50 AM, Walter Bright wrote:
On 12/30/2011 6:59 PM, Timon Gehr wrote:
On 12/31/2011 03:16 AM, Andrei Alexandrescu wrote:
On 12/30/11 6:25 PM, Timon Gehr wrote:
I'd be happy to extend the system, but currently I don't see it fall
short any of the three requirements. Can you help
On 12/31/2011 04:30 AM, Jonathan M Davis wrote:
On Friday, December 30, 2011 20:55:42 Timon Gehr wrote:
1. They don't notice. Then it is not a problem, because they are
obviously only using ASCII characters and it is perfectly reasonable to
assume that code units and characters are the same thin
On 12/30/2011 6:59 PM, Timon Gehr wrote:
On 12/31/2011 03:16 AM, Andrei Alexandrescu wrote:
On 12/30/11 6:25 PM, Timon Gehr wrote:
I'd be happy to extend the system, but currently I don't see it fall
short any of the three requirements. Can you help me out?
I think it would be great to reprod
On 12/30/2011 6:35 PM, so wrote:
With or without @inline i know fun should/will get folded away, then why should
i pay for the function call?
Because if the function did anything useful, the overhead of the function call
is insignificant.
I don't think that dealing with large, complex functi
On Friday, December 30, 2011 21:38:07 Jacob Carlborg wrote:
> On 2011-12-30 19:49, Jonathan M Davis wrote:
> > On Friday, December 30, 2011 13:41:37 Tobias Pankrath wrote:
> >> I really think it is and will use one for my D code. Since both worlds
> >> could live together peacefully there is absolu
On 2011-12-30 23:00:49 +, Andrei Alexandrescu
said:
Using .raw is /optimal/ because it states the assumption appropriately.
The user knows '$' cannot be in the prefix of any other symbol, so she
can state the byte alone is the character. If that were a non-ASCII
character, the assumption
On Friday, December 30, 2011 20:55:42 Timon Gehr wrote:
> 1. They don't notice. Then it is not a problem, because they are
> obviously only using ASCII characters and it is perfectly reasonable to
> assume that code units and characters are the same thing.
The problem is that what's more likely to
On 12/31/2011 03:16 AM, Andrei Alexandrescu wrote:
On 12/30/11 6:25 PM, Timon Gehr wrote:
I'd be happy to extend the system, but currently I don't see it fall
short any of the three requirements. Can you help me out?
I think it would be great to reproduce the expansion semantics of ddoc.
Andr
On Sat, 31 Dec 2011 04:30:01 +0200, Walter Bright
wrote:
On 12/30/2011 5:59 PM, so wrote:
Well not them but another dummy function, i didn't think it would
differ this much.
It differs that much because once it is inlined, the optimizer deletes
it because it does nothing.
I don't thin
On 12/30/2011 5:59 PM, so wrote:
Well not them but another dummy function, i didn't think it would differ this
much.
It differs that much because once it is inlined, the optimizer deletes it
because it does nothing.
I don't think it is a valid test.
On Sat, 31 Dec 2011 03:40:43 +0200, Iain Buclaw wrote:
Take a pick of any examples posted on this ML. They are far better
fit to use as a test bed. Ideally one that does number crunching and
can't be easily folded away.
I don't understand your point btw, why it shouldn't be easily folded aw
On 12/30/11 6:25 PM, Timon Gehr wrote:
I'd be happy to extend the system, but currently I don't see it fall
short any of the three requirements. Can you help me out?
I think it would be great to reproduce the expansion semantics of ddoc.
Andrei
On Sat, 31 Dec 2011 03:40:43 +0200, Iain Buclaw wrote:
Take a pick of any examples posted on this ML. They are far better
fit to use as a test bed. Ideally one that does number crunching and
can't be easily folded away.
Well not them but another dummy function, i didn't think it would diffe
On 31 December 2011 01:21, so wrote:
> On Sat, 31 Dec 2011 03:12:38 +0200, Iain Buclaw wrote:
>
>> On 31 December 2011 00:48, so wrote:
>>>
>>> On Fri, 30 Dec 2011 20:48:54 +0200, Walter Bright
>>> wrote:
>>>
On 12/30/2011 7:06 AM, so wrote:
>
>
> I agree @inline (which will pr
On Thu, 29 Dec 2011 23:59:46 +0200, Jonathan M Davis
wrote:
Introducing named arguments makes a function's parameters part of the
API and
introduces yet another point where code breakage can occur due to code
changes. And that is a _very_ negative aspect of named arguments IMHO.
Yes but l
On Sat, 31 Dec 2011 02:40:24 +0200, Don wrote:
I think: there are cases when named parameters are beneficial. There are
cases where they are detrimental.
Is it possible to get the first, without the second, and without much
complexity?
If we keep rules simple as possible i think it is poss
On Sat, 31 Dec 2011 03:12:38 +0200, Iain Buclaw wrote:
On 31 December 2011 00:48, so wrote:
On Fri, 30 Dec 2011 20:48:54 +0200, Walter Bright
wrote:
On 12/30/2011 7:06 AM, so wrote:
I agree @inline (which will probably be an extension) in D should mean
force-inline.
Ignoring the impossib
On 31 December 2011 00:48, so wrote:
> On Fri, 30 Dec 2011 20:48:54 +0200, Walter Bright
> wrote:
>
>> On 12/30/2011 7:06 AM, so wrote:
>>>
>>> I agree @inline (which will probably be an extension) in D should mean
>>> force-inline.
>>> Ignoring the impossible-to-inline cases (which in time shoul
On 12/31/2011 01:12 AM, Andrei Alexandrescu wrote:
On 12/30/11 6:07 PM, Timon Gehr wrote:
alias std.string.representation raw;
I meant your implementation is incomplete.
It was more a sketch than an implementation. It is not even type safe :o).
But the main point is that presence of repre
On Fri, 30 Dec 2011 20:48:54 +0200, Walter Bright
wrote:
On 12/30/2011 7:06 AM, so wrote:
I agree @inline (which will probably be an extension) in D should mean
force-inline.
Ignoring the impossible-to-inline cases (which in time should get
better),
adding @inline is a few minutes of edit
On 30.12.2011 07:36, Andrei Alexandrescu wrote:
On 12/30/11 12:25 AM, Derek wrote:
On Fri, 30 Dec 2011 16:22:49 +1100, Don wrote:
Some names are better than others. But are they part of the API?
That's the issue.
Yes, that is an issue.
Often, parameter names (such as in sin(x)) are arbit
On 12/31/2011 01:10 AM, Andrei Alexandrescu wrote:
On 12/30/11 5:21 PM, Timon Gehr wrote:
On 12/31/2011 12:02 AM, Andrei Alexandrescu wrote:
The library has a simple interface:
enum myMacro = q{... $1 $2 $(anotherMacro($1))... };
// To mixin
mixin(expand(myMacro, "argument one", "argument two
On 12/30/11 5:21 PM, Timon Gehr wrote:
On 12/31/2011 12:02 AM, Andrei Alexandrescu wrote:
The library has a simple interface:
enum myMacro = q{... $1 $2 $(anotherMacro($1))... };
// To mixin
mixin(expand(myMacro, "argument one", "argument two"));
Andrei
I understand, but compared to how I
On 12/30/11 6:07 PM, Timon Gehr wrote:
alias std.string.representation raw;
I meant your implementation is incomplete.
But the main point is that presence of representation/raw is not the
issue. The availability of good-for-nothing .length and operator[] are
the issue. Putting in place the c
On 12/31/2011 01:03 AM, Andrei Alexandrescu wrote:
On 12/30/11 5:07 PM, Timon Gehr wrote:
On 12/31/2011 12:00 AM, Andrei Alexandrescu wrote:
On 12/30/11 4:01 PM, Walter Bright wrote:
On 12/30/2011 11:55 AM, Timon Gehr wrote:
Me too. I think the way we have it now is optimal.
Consider your X
On 12/30/11 5:07 PM, Timon Gehr wrote:
On 12/31/2011 12:00 AM, Andrei Alexandrescu wrote:
On 12/30/11 4:01 PM, Walter Bright wrote:
On 12/30/2011 11:55 AM, Timon Gehr wrote:
Me too. I think the way we have it now is optimal.
Consider your X macro implementation. Strip out the utf.stride code
On 12/31/2011 12:34 AM, Walter Bright wrote:
On 12/30/2011 3:21 PM, Timon Gehr wrote:
2. it picks up all symbols used in $(...) from the caller's context
rather than
the callee's context and there is no way to get rid of that default,
because the
macro is unscoped.
That's characteristic of how
On 12/30/2011 3:21 PM, Timon Gehr wrote:
2. it picks up all symbols used in $(...) from the caller's context rather than
the callee's context and there is no way to get rid of that default, because the
macro is unscoped.
That's characteristic of how macros work, and people want it that way.
Ot
On 12/30/2011 3:00 PM, Andrei Alexandrescu wrote:
On 12/30/11 4:01 PM, Walter Bright wrote:
On 12/30/2011 11:55 AM, Timon Gehr wrote:
Me too. I think the way we have it now is optimal.
Consider your X macro implementation. Strip out the utf.stride code and
use plain indexing - it will not bre
On 12/31/2011 12:02 AM, Andrei Alexandrescu wrote:
On 12/30/11 3:51 PM, Timon Gehr wrote:
On 12/30/2011 09:51 PM, Andrei Alexandrescu wrote:
On 12/30/11 12:10 PM, Walter Bright wrote:
On 12/30/2011 4:05 AM, Timon Gehr wrote:
It certainly does. That is how all my code generation looks like. Th
On 12/31/2011 12:00 AM, Andrei Alexandrescu wrote:
On 12/30/11 4:01 PM, Walter Bright wrote:
On 12/30/2011 11:55 AM, Timon Gehr wrote:
Me too. I think the way we have it now is optimal.
Consider your X macro implementation. Strip out the utf.stride code and
use plain indexing - it will not br
On 12/30/11 3:51 PM, Timon Gehr wrote:
On 12/30/2011 09:51 PM, Andrei Alexandrescu wrote:
On 12/30/11 12:10 PM, Walter Bright wrote:
On 12/30/2011 4:05 AM, Timon Gehr wrote:
It certainly does. That is how all my code generation looks like. The
fact that
I am using string mixins to solve some p
On 12/30/11 4:01 PM, Walter Bright wrote:
On 12/30/2011 11:55 AM, Timon Gehr wrote:
Me too. I think the way we have it now is optimal.
Consider your X macro implementation. Strip out the utf.stride code and
use plain indexing - it will not break the code in any way. The naive
implementation st
On 12/30/2011 11:01 PM, Walter Bright wrote:
On 12/30/2011 11:55 AM, Timon Gehr wrote:
Me too. I think the way we have it now is optimal.
Consider your X macro implementation. Strip out the utf.stride code and
use plain indexing - it will not break the code in any way. The naive
implementation
On 12/30/2011 10:36 PM, deadalnix wrote:
Le 30/12/2011 20:55, Timon Gehr a écrit :
On 12/30/2011 08:33 PM, Joshua Reusch wrote:
Am 29.12.2011 19:36, schrieb Andrei Alexandrescu:
On 12/29/11 12:28 PM, Don wrote:
On 28.12.2011 20:00, Andrei Alexandrescu wrote:
Oh, one more thing - one good thi
On Saturday, 17 December 2011 at 22:25:07 UTC, Andrei
Alexandrescu wrote:
On 12/2/11 10:26 PM, dsimcha wrote:
I volunteered ages ago to manage the review for the second
round of
Jonas Drewsen's CURL wrapper. After the first round it was
decided that,
after a large number of minor issues were fi
On 12/30/2011 11:55 AM, Timon Gehr wrote:
Me too. I think the way we have it now is optimal.
Consider your X macro implementation. Strip out the utf.stride code and use
plain indexing - it will not break the code in any way. The naive implementation
still works correctly with ASCII and UTF-8.
On 12/30/2011 09:51 PM, Andrei Alexandrescu wrote:
On 12/30/11 12:10 PM, Walter Bright wrote:
On 12/30/2011 4:05 AM, Timon Gehr wrote:
It certainly does. That is how all my code generation looks like. The
fact that
I am using string mixins to solve some problems shows that those are not
'proble
Le 30/12/2011 20:55, Timon Gehr a écrit :
On 12/30/2011 08:33 PM, Joshua Reusch wrote:
Am 29.12.2011 19:36, schrieb Andrei Alexandrescu:
On 12/29/11 12:28 PM, Don wrote:
On 28.12.2011 20:00, Andrei Alexandrescu wrote:
Oh, one more thing - one good thing that could come out of this thread
is a
On 12/30/2011 07:10 PM, Walter Bright wrote:
On 12/30/2011 4:05 AM, Timon Gehr wrote:
It certainly does. That is how all my code generation looks like. The
fact that
I am using string mixins to solve some problems shows that those are not
'problems in D string mixins'.
I your solution to param
On 12/30/11 12:10 PM, Walter Bright wrote:
On 12/30/2011 4:05 AM, Timon Gehr wrote:
It certainly does. That is how all my code generation looks like. The
fact that
I am using string mixins to solve some problems shows that those are not
'problems in D string mixins'.
I your solution to paramet
On 12/30/11 1:55 PM, Timon Gehr wrote:
Me too. I think the way we have it now is optimal.
What we have now is adequate. The scheme I proposed is optimal.
I agree with all of your other remarks.
Andrei
On Friday, 30 December 2011 at 19:55:45 UTC, Timon Gehr wrote:
I think the way we have it now is optimal. The only reason we
are discussing this is because of fear that uneducated users
will write code that does not take into account Unicode
characters above code point 0x80. But what is the wor
On 2011-12-30 19:49, Jonathan M Davis wrote:
On Friday, December 30, 2011 13:41:37 Tobias Pankrath wrote:
I really think it is and will use one for my D code. Since both worlds
could live together peacefully there is absolutely no reason not to include
one in phobos.
It's one thing to use a fa
On 12/30/2011 08:33 PM, Joshua Reusch wrote:
Am 29.12.2011 19:36, schrieb Andrei Alexandrescu:
On 12/29/11 12:28 PM, Don wrote:
On 28.12.2011 20:00, Andrei Alexandrescu wrote:
Oh, one more thing - one good thing that could come out of this thread
is abolition (through however slow a deprecatio
Am 29.12.2011 19:36, schrieb Andrei Alexandrescu:
On 12/29/11 12:28 PM, Don wrote:
On 28.12.2011 20:00, Andrei Alexandrescu wrote:
Oh, one more thing - one good thing that could come out of this thread
is abolition (through however slow a deprecation path) of s.length and
s[i] for narrow string
On Monday, 19 December 2011 at 18:14:29 UTC, Somedude wrote:
Le 19/12/2011 19:05, Somedude a écrit :
Le 03/12/2011 05:26, dsimcha a écrit :
I volunteered ages ago to manage the review for the second
round of
Jonas Drewsen's CURL wrapper. After the first round it was
decided
that, after a larg
On Saturday, 17 December 2011 at 20:01:04 UTC, Jakob Ovrum wrote:
The docs for onReceiveHeader,
http://freeze.steamwinter.com/D/web/phobos/etc_curl.html#onReceiveHeader
explicitly says that the const string parameters are not valid
after the function returns. This is all well and good; but a
On 12/30/2011 01:48 PM, Walter Bright wrote:
> On 12/30/2011 7:06 AM, so wrote:
>> I agree @inline (which will probably be an extension) in D should mean
>> force-inline.
>> Ignoring the impossible-to-inline cases (which in time should get
>> better),
>> adding @inline is a few minutes of editing.
On 12/30/2011 02:00 PM, Walter Bright wrote:
> On 12/30/2011 10:31 AM, Chad J wrote:
>> As an aside, I think that people want forced inlining because it gives
>> them another tool to tweak with. My experiences with optimization tend
>> to suggest I can usually optimize things really well with a fe
On 12/30/2011 10:31 AM, Chad J wrote:
As an aside, I think that people want forced inlining because it gives
them another tool to tweak with. My experiences with optimization tend
to suggest I can usually optimize things really well with a few short
cycles of profile->experiment->profile. I don
On Friday, December 30, 2011 13:41:37 Tobias Pankrath wrote:
> When I first came to D, I read "unittest support" and thought that would
> be nice. But after I tried it, I realized it sucks and wrote something
> similar to Jacobs unittest framework.
>
> > I'm against it. I think that the compiler/r
On Friday, 16 December 2011 at 09:42:50 UTC, Jonathan M Davis
wrote:
Please make sure that you remove trailing whitespace from the
file. A lot of the lines have trailing whitespace. Also, make
sure that you don't have any tabs in the file. There are a few
places where you used tabs.
ok
Line#
On 12/30/2011 7:06 AM, so wrote:
I agree @inline (which will probably be an extension) in D should mean
force-inline.
Ignoring the impossible-to-inline cases (which in time should get better),
adding @inline is a few minutes of editing.
It will just bypass the cost function and if it is not possi
On 12/30/2011 04:13 AM, Walter Bright wrote:
> On 12/30/2011 12:16 AM, Vladimir Panteleev wrote:
>> I agree, but this wasn't as much about heuristics, but compiler
>> capabilities
>> (e.g. inlining assembler functions).
>
> Adding a keyword won't fix the current problem that the compiler won't
> i
On 12/30/2011 4:05 AM, Timon Gehr wrote:
It certainly does. That is how all my code generation looks like. The fact that
I am using string mixins to solve some problems shows that those are not
'problems in D string mixins'.
I your solution to parameterized strings is very nice. Can you write a
On 12/29/2011 9:13 PM, Alexander Malakhov wrote:
Hmm... If that's of no interest, could someone state it explicitly.
So that I'll be sure my message wasn't just overlooked or lost
I certainly don't mind using the D logo on the Wikipedia, I'm just not sure what
to do about it.
On Fri, 30 Dec 2011 16:11:54 +0200, Vladimir Panteleev
wrote:
On Friday, 30 December 2011 at 12:05:27 UTC, Timon Gehr wrote:
On 12/30/2011 06:58 AM, Vladimir Panteleev wrote:
On Thursday, 29 December 2011 at 23:47:08 UTC, Timon Gehr wrote:
** The X template
Good work, but I'm not sure if
On Fri, 30 Dec 2011 14:00:06 +0200, Vladimir Panteleev
wrote:
On Friday, 30 December 2011 at 09:13:05 UTC, Walter Bright wrote:
Also, if you are tweaking at such a level, every compiler is different
enough that your tweaks are likely to be counterproductive on another
compiler. Having a p
On Friday, 30 December 2011 at 12:05:27 UTC, Timon Gehr wrote:
On 12/30/2011 06:58 AM, Vladimir Panteleev wrote:
On Thursday, 29 December 2011 at 23:47:08 UTC, Timon Gehr
wrote:
** The X template
Good work, but I'm not sure if inventing a DSL to make up for
the
problems in D string mixins th
When I first came to D, I read "unittest support" and thought that would
be nice. But after I tried it, I realized it sucks and wrote something
similar to Jacobs unittest framework.
> I'm against it. I think that the compiler/runtime should be fixed so that
> each unit test block is run in a modu
On 12/30/2011 06:58 AM, Vladimir Panteleev wrote:
On Thursday, 29 December 2011 at 23:47:08 UTC, Timon Gehr wrote:
** The X template
Good work, but I'm not sure if inventing a DSL to make up for the
problems in D string mixins that C macros don't have qualifies as "doing
it right".
It certai
On Friday, 30 December 2011 at 12:00:07 UTC, Vladimir Panteleev
wrote:
Back to the macros vs.
Oops, didn't mean to send that. I was going to write that
comparing C macros with __forceinline functions is much more of a
level comparison.
On Friday, 30 December 2011 at 09:13:05 UTC, Walter Bright wrote:
Also, if you are tweaking at such a level, every compiler is
different enough that your tweaks are likely to be
counterproductive on another compiler. Having a portable syntax
for such tweaking is not going to help.
Which is ex
On Friday, 30 December 2011 at 00:34:13 UTC, Trass3r wrote:
The reason is druntime doesn't build separate libs like phobos
does.
A quick and dirty patch would be:
diff --git a/posix.mak b/posix.mak
index 5fd7fee..9ed2004 100644
--- a/posix.mak
+++ b/posix.mak
@@ -32,9 +32,9 @@ UDFLAGS=-m$(MODE
I completely agree that DMD's inliner is underpowered and needs
improvement. I am less sure that this demonstrates that the language
needs changes.
Functions below a certain size should be inlined if possible. Those
above that size do not benefit perceptibly from inlining. Where that
cert
there are lot of people suggesting to change how string behaves. but
remember, d is awesome compared to other languages for not wrapping
string in a class or struct.
you can use string/char[] without loosing your _nativeness_. programmers
targeting embedded systems are really happy because of this
On 30/12/11 9:13 AM, Walter Bright wrote:
And if one really wants to force an inline, one can do things like the C
memcpy using the preprocessor, or string mixins in D, or even cut&paste.
If you need to do that in more than a couple places in the code,
something else is wrong (that old saw about
Hmm... If that's of no interest, could someone state it explicitly.
So that I'll be sure my message wasn't just overlooked or lost
In my case it's "can't help with that".
Can't imagine anyone would mind having the logo in wikipedia though.
On Thu, 29 Dec 2011 18:36:27 -, Andrei Alexandrescu
wrote:
On 12/29/11 12:28 PM, Don wrote:
On 28.12.2011 20:00, Andrei Alexandrescu wrote:
Oh, one more thing - one good thing that could come out of this thread
is abolition (through however slow a deprecation path) of s.length and
s[i]
Andrei Alexandrescu wrote:
> is part of writing programs
If libraries from more than one author are used with named parameters,
inconsistencies in the naming will be a normal problem.
For example: a boolean parameter for generating ouput might be named
differently in two libraries as `print' (
On 12/30/2011 12:16 AM, Vladimir Panteleev wrote:
I agree, but this wasn't as much about heuristics, but compiler capabilities
(e.g. inlining assembler functions).
Adding a keyword won't fix the current problem that the compiler won't inline
inline assembler functions. It's an orthogonal issue
On Friday, 30 December 2011 at 06:53:06 UTC, Walter Bright wrote:
I think this criticism is off target, because the C example was
almost entirely macros - and macros that were used in the
service of evading C language limitations. The point wasn't to
use clever D features, the challenge was to
79 matches
Mail list logo
