On 12/31/13 11:51 AM, H. S. Teoh wrote:
On Tue, Dec 31, 2013 at 09:08:07AM -0800, Andrei Alexandrescu wrote:
On 12/31/13 4:26 AM, Jacob Carlborg wrote:
[...]
4. It doesn't rely on embedded HTML, as such will impede extraction
and formatting for other purposes.
As far as I know this isn't ver
On Tuesday, 31 December 2013 at 10:37:23 UTC, Sönke Ludwig wrote:
Am 31.12.2013 11:05, schrieb Vladimir Panteleev:
P.S. How come your user agent (Thunderbird) is not emitting
format=flowed messages? According to [1], it supports
format=flowed, and
can only be disabled via editing option string
http://code2013.herokuapp.com/
Get tweeting :-)
D is currently sitting with 33 mentions, just below OCaml and
just above ML.
For reference, Rust has 76 mentions and Go has 346.
On Tuesday, December 31, 2013 13:39:25 John Colvin wrote:
> On Tuesday, 31 December 2013 at 12:55:59 UTC, Jacob Carlborg
>
> wrote:
> > On 2013-12-31 13:42, Supernova wrote:
> >> Why do associative arrays throw an Error (RangeError) on value
> >> not found?
> >>
> >> This seems like it would be i
On 12/31/2013 1:17 PM, Jacob Carlborg wrote:
So which macro should I use to make cross referencing for arbitrary deep
hierarchies?
I used this one in std.datetime:
LREF2=$(D $2)
On Tuesday, 31 December 2013 at 20:29:34 UTC, Chris Cain wrote:
On Tuesday, 31 December 2013 at 19:53:29 UTC, Ola Fosheim
Grøstad wrote:
I think many optimizations become more valuable when you start
doing whole program anlysis.
You're correct, but I think the value only comes if it's
actuall
On 2013-12-31 21:52, Walter Bright wrote:
You don't need an efficient solution for ddoc files of readable size. It
only takes a few moments. I've spent far, far more time typing about it
here than it took to do. Some solutions are simply not worth the bother.
I've probably spent at least as mu
On 2013-12-31 19:16, Andrei Alexandrescu wrote:
Agreed. In all likelihood I misunderstood something because I thought
you were referring to cross-referencing text without any user intervention.
I made two suggestions, one which is completely automatic and one which
requires some syntax. It se
On 12/31/2013 4:14 AM, Jacob Carlborg wrote:
If Ddoc requires post processing to be useful it's a complete failure.
Not at all. The same ddoc sources are used to generate an ebook and a Windows
help file - which are based on html but require different html to be generated,
a difference handle
On 12/31/2013 4:37 AM, Jacob Carlborg wrote:
That doesn't sound very efficient.
You don't need an efficient solution for ddoc files of readable size. It only
takes a few moments. I've spent far, far more time typing about it here than it
took to do. Some solutions are simply not worth the bot
On Tuesday, 31 December 2013 at 19:53:29 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 31 December 2013 at 17:52:56 UTC, Chris Cain wrote:
1. The compiler writer will actually do this analysis and
write the optimization (my bets are that DMD will likely not
do many of the things you suggest).
I
On Tuesday, 31 December 2013 at 17:52:56 UTC, Chris Cain wrote:
Well, that's certainly a good point. There's _probably_ some
extra optimizations that could be done with a compiler
supported new. Maybe it could make some significantly faster
code, but this assumes many things:
1. The compiler
On Tue, Dec 31, 2013 at 09:08:07AM -0800, Andrei Alexandrescu wrote:
> On 12/31/13 4:26 AM, Jacob Carlborg wrote:
[...]
> >>>4. It doesn't rely on embedded HTML, as such will impede extraction
> >>>and formatting for other purposes.
> >
> >As far as I know this isn't very useful. For the other form
On Tuesday, 31 December 2013 at 09:04:58 UTC, Dmitry Olshansky
wrote:
31-Dec-2013 05:53, Joseph Cassman пишет:
On Sunday, 29 December 2013 at 22:02:57 UTC, Dmitry Olshansky
wrote:
I'm thinking there might be a way to bridge the new range type
with ForwardRange but not directly as defined at t
On 12/31/13 9:39 AM, Sönke Ludwig wrote:
Am 31.12.2013 17:48, schrieb Andrei Alexandrescu:
In a nutshell, "good cross-referencing is hard".
I don't think so at all (on the technical level). What is the issue with
using the #identifier.chain pattern for example? It seems simple enough
and I can
On Tuesday, 31 December 2013 at 06:28:40 UTC, Ola Fosheim Grøstad
wrote:
A flexible new and good compiler level memory management
support that cannot be overridden gives the compiler some
optimization opportunities. E.g. putting objects on the stack,
allocating a single chunk for multiple objec
Am 31.12.2013 17:48, schrieb Andrei Alexandrescu:
On 12/31/13 1:28 AM, Sönke Ludwig wrote:
Am 31.12.2013 05:39, schrieb Andrei Alexandrescu:
On 12/30/13 1:00 PM, Walter Bright wrote:
On 12/30/2013 8:23 AM, Andrei Alexandrescu wrote:
Oh the default is to link and then disable manually? That's
On 12/31/13 4:26 AM, Jacob Carlborg wrote:
On 2013-12-31 01:05, Sönke Ludwig wrote:
Also, the official first four goals of DDOC are:
1. It looks good as embedded documentation, not just after it is
extracted and processed.
It certainly does not. Just have a look at the top of std.algori
On 12/31/13 1:28 AM, Sönke Ludwig wrote:
Am 31.12.2013 05:39, schrieb Andrei Alexandrescu:
On 12/30/13 1:00 PM, Walter Bright wrote:
On 12/30/2013 8:23 AM, Andrei Alexandrescu wrote:
Oh the default is to link and then disable manually? That's still
manual, just
the default is different :o). I
On 28/12/2013 16:49, Jeroen Bollen wrote:
Why is when you do readln() the newline character (\n) gets read too?
Wouldn't it make more sense for that character to be stripped off?
The newline character needs to be read - how else will it know when it's
got to the end of the line? :)
Of course
Stewart Gordon:
I'd be inclined to define a function like
string stripLineBreak(string s) {
while (s.length != 0 && s[$-1] != '\n' && s[$-1] != '\r') {
s = s[0..$-1];
}
return s;
}
See the chop and chomp functions in std.string.
Bye,
bearophile
Am Tue, 31 Dec 2013 16:21:14 +
schrieb Stewart Gordon :
> On 31/12/2013 14:45, Marco Leise wrote:
>
> > I guess I just don't see what an immutable string buys you.
> > The mutable part in a string is just a pointer and length pair.
> > Just write:
> >
> >immutable s = readln()[0 .. $-1];
On 31/12/2013 14:45, Marco Leise wrote:
I guess I just don't see what an immutable string buys you.
The mutable part in a string is just a pointer and length pair.
Just write:
immutable s = readln()[0 .. $-1];
and you have an immutable string at no cost.
What if the line is at EOF and doe
Am Tue, 31 Dec 2013 13:09:34 +
schrieb "Jeroen Bollen" :
> On Monday, 30 December 2013 at 02:59:23 UTC, Marco Leise wrote:
> > Am Sun, 29 Dec 2013 22:03:14 +
> > schrieb "Jeroen Bollen" :
> >
> >> On Sunday, 29 December 2013 at 18:13:30 UTC, Jakob Ovrum wrote:
> >> > On Sunday, 29 December
John Colvin:
Doesn't that duplicate the work of discovering whether the key
is there or not? I guess it would depend on the implementation.
If you compile the code with ldc2, the compiler in most cases is
able to perform the associative array lookup only once. Elsewhere
I suggested to add th
On Tuesday, 31 December 2013 at 12:42:33 UTC, Supernova wrote:
Why do associative arrays throw an Error (RangeError) on value
not found?
This seems like it would be inefficient to check for, so a
recoverable Exception (ItemNotFoundException?) would seem to be
more appropriate.
Or is Array[K
On Tuesday, 31 December 2013 at 12:55:59 UTC, Jacob Carlborg
wrote:
On 2013-12-31 13:42, Supernova wrote:
Why do associative arrays throw an Error (RangeError) on value
not found?
This seems like it would be inefficient to check for, so a
recoverable
Exception (ItemNotFoundException?) would s
Am Tue, 31 Dec 2013 13:27:17 +0100
schrieb Jacob Carlborg :
> On 2013-12-31 10:31, Marco Leise wrote:
>
> > I am VERY much in favor of a more MarkDown style syntax and #
> > for identifier references! It is also very verbose to create
> > bullet-point lists and you always have to double-check you
On Monday, 30 December 2013 at 02:59:23 UTC, Marco Leise wrote:
Am Sun, 29 Dec 2013 22:03:14 +
schrieb "Jeroen Bollen" :
On Sunday, 29 December 2013 at 18:13:30 UTC, Jakob Ovrum wrote:
> On Sunday, 29 December 2013 at 17:25:39 UTC, Jeroen Bollen
> wrote:
>> Wouldn't byline return an empty
On 2013-12-31 13:42, Supernova wrote:
Why do associative arrays throw an Error (RangeError) on value not found?
This seems like it would be inefficient to check for, so a recoverable
Exception (ItemNotFoundException?) would seem to be more appropriate.
How would ItemNotFoundException be any mo
Why do associative arrays throw an Error (RangeError) on value
not found?
This seems like it would be inefficient to check for, so a
recoverable Exception (ItemNotFoundException?) would seem to be
more appropriate.
Or is Array[Key] with a key that is not in the array and bounds
checking dis
On 2013-12-30 23:10, Walter Bright wrote:
The "query" part, meaning it highlighted each one and asked for yes/no.
http://www.gnu.org/software/emacs/manual/html_node/emacs/Query-Replace.html
That doesn't sound very efficient. Regardless of that, the current
macros still don't work. How do you
On 2013-12-31 11:05, Vladimir Panteleev wrote:
I agree that a good compromise would be to lighten the syntactic overhead.
How about using the $(D) macro instead of $(REF)? This macro
syntax-highlights its parameter as D code, and in Phobos it is already
used for identifiers, so I think a good s
On 2013-12-31 10:31, Marco Leise wrote:
I am VERY much in favor of a more MarkDown style syntax and #
for identifier references! It is also very verbose to create
bullet-point lists and you always have to double-check you
don't forget to replace all ) with $(RPAREN). If you misspell
anything it
On Tuesday, 31 December 2013 at 12:22:54 UTC, Iain Buclaw wrote:
Also Brad, I haven't received any ML messages since 29th? :-)
Oh never mind,, I think I know the problem. :(
On 2013-12-31 01:05, Sönke Ludwig wrote:
Also, the official first four goals of DDOC are:
1. It looks good as embedded documentation, not just after it is
extracted and processed.
It certainly does not. Just have a look at the top of std.algorithm or
std.uni. Hundreds of lines of Ddoc m
On Monday, 30 December 2013 at 12:57:57 UTC, Jacob Carlborg wrote:
On 2013-12-30 13:24, Iain Buclaw wrote:
However I'm not sure if the names are sufficient, and whether
or not
they should really be prefixed with a double underscore to
ensure that
they don't conflict with user-declared members
On 2013-12-31 00:37, Walter Bright wrote:
I don't see any particular advantage to using (name) rather than $(REF
name), and some serious disadvantages with false positives like
func(param). Oops! A markup language should really strive to minimize
special syntax. (I'm often tripped up by false po
On Tuesday, 31 December 2013 at 02:28:45 UTC, Ritu wrote:
1. The ability to have a user-defined default constructor for
structs. I believe this is not possible since it does not go
well with D's metaprogramming.
If this is for a DSL, can't you make it so situations that lower
to default const
On Tuesday, 31 December 2013 at 09:29:20 UTC, Sönke Ludwig wrote:
My favorite solution would be to introduce a simple
#identifier.chain or
@identifier.chain syntax to let the compiler or documentation
generator
insert the proper links or macro calls. Using a sepecial $(REF
identifier.chain) pse
Am Tue, 31 Dec 2013 10:28:46 +0100
schrieb Sönke Ludwig :
> Am 31.12.2013 05:39, schrieb Andrei Alexandrescu:
> > On 12/30/13 1:00 PM, Walter Bright wrote:
> >> On 12/30/2013 8:23 AM, Andrei Alexandrescu wrote:
> >>> Oh the default is to link and then disable manually? That's still
> >>> manual, j
Am Tue, 31 Dec 2013 00:13:41 +0100
schrieb Sönke Ludwig :
> [...] I very much agree with them, but the
> current reality looks like the opposite - lots of macro-pseudo-HTML
> markup, very difficult to read unprocessed in many places. So something
> like using "#" or "()" to mark symbols + automati
Am 31.12.2013 05:39, schrieb Andrei Alexandrescu:
> On 12/30/13 1:00 PM, Walter Bright wrote:
>> On 12/30/2013 8:23 AM, Andrei Alexandrescu wrote:
>>> Oh the default is to link and then disable manually? That's still
>>> manual, just
>>> the default is different :o). I can work with that.
>>
>> As
31-Dec-2013 05:51, Brad Anderson пишет:
On Sunday, 29 December 2013 at 22:02:57 UTC, Dmitry Olshansky wrote:
Proposal
Having never written any parser I'm not really qualified to seriously
give comments or review it but it all looks very nice to me.
Speaking as just an end user of these things
31-Dec-2013 05:53, Joseph Cassman пишет:
On Sunday, 29 December 2013 at 22:02:57 UTC, Dmitry Olshansky wrote:
[...]
Interesting idea. Seems to fill a need I have been facing with some
parsing code.
Since I was unclear about how its functionality compares to ForwardRange
I took a look through
Am Mon, 30 Dec 2013 13:52:28 +
schrieb "ponce" :
> > http://www.reddit.com/r/programming/comments/1tzk5j/the_m_error_model/
> As compared with D:
>
> - unrecoverable errors crash immediately like they should. I like
> it since the most sensible reason to catch Error in D is to crash
> any
46 matches
Mail list logo
