Please let it go. There has been said enough to represent views
of different parties, and argument for the sake of the argument
is counterproductive.
On Fri, 02 Jan 2015 05:49:45 +
pops via Digitalmars-d wrote:
> Talks about switching from windows to Linux. There are
> positives, but the debugging is not one of them.
*nix cultire and windows culture are very different. when "switcher"
tries to use his windows habits in *nix world, he f
...and we, *nix people, thinking the same... about windows
debuggers.
so please, don't call the tool you aren't familiar with "stone
age
tool".
https://anteru.net/2014/12/13/2596/
Talks about switching from windows to Linux. There are
positives, but the debugging is not one of them.
On Fri, 02 Jan 2015 05:12:27 +
pops via Digitalmars-d wrote:
>Regarding debuggers: keep in mind, windows debuggers
> are light years ahead of GDB and friends.
>
>What Linux people refer to as a debugger looks like a stone age
> tool to me.
...and we, *nix people, thinking the same..
Regarding debuggers: keep in mind, windows debuggers
are light years ahead of GDB and friends.
What Linux people refer to as a debugger looks like a stone age
tool to me.
On 1/1/2015 5:47 PM, Mike Parker wrote:
On 1/2/2015 7:10 AM, Walter Bright wrote:
Besides, consider how many tasks the macros in Phobos handle that are common
enough for most projects to need them. Shouldn't that sort of thing be built in?
Why should we keep putting together LIST macros when a li
On 1/2/2015 7:10 AM, Walter Bright wrote:
On 1/1/2015 1:49 PM, H. S. Teoh via Digitalmars-d wrote:
The problem is that this is strictly speaking a hack, not a solution,
because in the output it's not tagged as a list. This may not be a
problem if the output is HTML for user consumption, but if y
On Thu, 01 Jan 2015 21:51:06 +0100
Jacob Carlborg via Digitalmars-d wrote:
> On 2015-01-01 16:09, Dicebot wrote:
> > My top list of md shortcuts for "casual" documentation:
> >
> > 1. `code`
> >
> > 2. * lists
> >
> > headers
> > 3. ===
>
> I prefer the hashtag syntax:
>
> # header
>
>
On Thu, 01 Jan 2015 11:57:37 -0800
Walter Bright via Digitalmars-d wrote:
> Is also hard to read. Yes, I'm being facetious, but take a look at those
> examples posted here about how ugly Ddoc is - they're of that category.
and you know why? 'cause nobody cares to make 'em human readable, as
it's
On Thu, 01 Jan 2015 15:40:30 +0100
Joseph Rushton Wakeling via Digitalmars-d
wrote:
> On 01/01/15 15:26, Adam D. Ruppe via Digitalmars-d wrote:
> > Again those are: *bold* and `code`.
>
> I would be inclined to prefer ``code`` or ```code```, simply because it's
> valid
> D syntax to have,
>
>
Hi,
I found an article today on reddit which I think it would be nice
to share:
http://hookrace.net/blog/what-is-special-about-nim/#good-performance
I'm pointing out this link because I think D should have some
articles like this too. It's comprehensive and it seems popular
to gather attent
On Thu, 01 Jan 2015 12:55:28 +
Gary Willoughby via Digitalmars-d wrote:
> Just because you contribute to D it doesn't give you any
> authority to get angry at users or:
that's really great. Dicebot wrote a long text explaining that he is
not a D dev team representative, he doesn't want to be
On 12/30/2014 01:04 PM, Andrei Alexandrescu wrote:
> With https://github.com/D-Programming-Language/dlang.org/pull/736,
> beautiful PDF generation via LaTeX is now possible.
>
> There are, of course, many details to tend to. For starters, currently
> the doc is overly sparse, which makes it large (
Thanks for the example. I'd not seen the trick with empty type
parameter lists before.
On 2 January 2015 at 05:42, Walter Bright via Digitalmars-d
wrote:
> On 1/1/2015 8:19 AM, Manu via Digitalmars-d wrote:
>>
>> I was thinking more along the lines of letting doxygen inspire
>> enhancements to ddoc, since as far as I can see, it's pretty much the
>> standard these days, and people a
On 1 January 2015 at 22:40, Joseph Rushton Wakeling via Digitalmars-d
wrote:
> On 01/01/15 15:43, Manu via Digitalmars-d wrote:
>>
>> Oh yeah, and a massive one that I've discussed with Ethan and I think
>> he's discussed with you; DMD likes to use the x87 in win64 builds...
>> that's really no go
On 2 January 2015 at 03:06, Joseph Rushton Wakeling via Digitalmars-d
wrote:
> On 01/01/15 17:16, Manu via Digitalmars-d wrote:
>>
>> Doxygen supports both @param and \param.
>
>
> Ah yes, I'd forgotten that. It's been a while :-\
>
>> It would be really good if doxygen supported D comprehensivel
On 01/01/15 15:43, Manu via Digitalmars-d wrote:
Oh yeah, and a massive one that I've discussed with Ethan and I think
he's discussed with you; DMD likes to use the x87 in win64 builds...
that's really no good. We can't be swapping between x87 and xmm regs.
float/double args are passed in xmm acc
On 2014-12-31 20:50, Andrei Alexandrescu wrote:
In wake of the recent discussions on improving ddoc syntax we're looking
at doing something about it. Please discuss any ideas you might have
here. Thanks!
I think there are two big issues with Ddoc: its syntax and its lack of
functionality. I t
On 31/12/14 12:25, Walter Bright via Digitalmars-d wrote:
What you can contribute that would be very valuable is what we've discussed
before - your simd expertise. Your influence is what has shaped the current simd
support. I don't know anyone who knows even half of what you do about simd. What
y
On 1/1/2015 6:43 AM, Manu via Digitalmars-d wrote:
Make it work in dmd (with my help, of course) and prove the design. Then GDC
will come along.
I can't do anything that isn't supported by the GCC backend; that's
the platform for almost all the cross-compilers, which I really care
about.
I also
On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via
Digitalmars-d wrote:
[snip]
Thoughts?
I don't think something like this belongs in phobos. It's not
universal enough to warrant all the extra work it would require
to add and maintain in phobos.
There are significant advantages to doing
On Thursday, 1 January 2015 at 19:54:56 UTC, Phil wrote:
Could you give a concrete example of using your Match template?
e.g. to perform a different action for floating point or
integral values.
auto f (T)(T n)
{
auto integral ()() {return integral_only_func (n);}
auto floatin
On 1/1/2015 1:49 PM, H. S. Teoh via Digitalmars-d wrote:
The problem is that this is strictly speaking a hack, not a solution,
because in the output it's not tagged as a list. This may not be a
problem if the output is HTML for user consumption, but if you're
outputting to XML, say, or if your HT
On 01/01/15 21:15, Walter Bright via Digitalmars-d wrote:
My point is there's ALWAYS going to be some sort of escaping mechanism, and it
is ALWAYS going to interfere with the look of anyone who wants to use the full
character set on the keyboard, which IS going to happen whenever you write math
t
On 1/1/2015 7:09 AM, Dicebot wrote:
headers
3. ===
headers:
On Thu, Jan 01, 2015 at 12:48:58PM -0800, Walter Bright via Digitalmars-d wrote:
[...]
> Can you do lists without macros in Ddoc? Sure:
>
> /**
>
> Description
>
> 1. first item
>
> 2. second item
>
> An unordered list:
>
> - first item
>
> - second i
How will you reach your a million users goal?
Please elaborate in detail - not digs. Please put
out an agenda/road map you'd like to see prioritized.
On 2014-12-31 20:50, Andrei Alexandrescu wrote:
One simple starter would be to allow one escape character, e.g. the
backtick (`), as a simple way to expand macros: instead of $(MACRO arg1,
arg2) one can write `MACRO arg1, arg2`.
I don't see how that would improve anything, at all.
--
/Jacob C
On 2015-01-01 16:09, Dicebot wrote:
My top list of md shortcuts for "casual" documentation:
1. `code`
2. * lists
headers
3. ===
I prefer the hashtag syntax:
# header
## header
--
/Jacob Carlborg
On 1/1/2015 10:04 AM, Dicebot wrote:
As long as you are actually forced to use _any_ kind of macros in basic
documentation it won't be good enough.
Basic documentation can be written without any macros:
/
This function does blah, blah, blah.
Blah, blah, blah is a
On 2015-01-01 01:44, Rikki Cattermole wrote:
The AST stuff would guaranteed be a DIP (second to last CTFE
implementation type, well as I define it anyway).
http://wiki.dlang.org/DIP50 ;)
--
/Jacob Carlborg
On 2015-01-01 14:28, Andrej Mitrovic via Digitalmars-d wrote:
The wxWidgets developers maintain a hand-written set of doxygen
interface files because doxygen actually crashes when trying to parse
the C++ code directly.
As a result the documentation is frequently out of date. I remember
filing n
On 2015-01-01 01:21, Rikki Cattermole wrote:
Following this, we could extend this one altogether.
AST entry points. Read only (later maybe not) full access to dmd-fe AST.
So we're back at AST macros :). I don't mind but I don't think it's the
right solution in this case.
--
/Jacob Carlborg
On Thursday, 1 January 2015 at 19:57:56 UTC, Walter Bright wrote:
On 1/1/2015 8:39 AM, Manu via Digitalmars-d wrote:
It's just noisy and hard to read, as
I think we've established to be the popular opinion.
Is also hard to read. Yes, I'm being facetious, but take a look
at those examples post
On 1/1/2015 12:02 PM, Andrej Mitrovic via Digitalmars-d wrote:
Well the actual truth is that doxygen is pretty much the C++ standard,
while Markdown is a standard for everything else. :)
My experience with C/C++ is that no documentation is the standard :-)
Manu:
I would do that to start with, but the difference is that if I
work
with phobos in mind, then I'll raise design discussion here,
otherwise
I'll just keep it to myself.
I think having a color module in Phobos is OK. But probably it's
better to write it with Phobos in mind but to keep i
On 1/1/2015 12:04 PM, Adam D. Ruppe wrote:
On Thursday, 1 January 2015 at 19:57:56 UTC, Walter Bright wrote:
Is also hard to read. Yes, I'm being facetious, but take a look at those
examples posted here about how ugly Ddoc is - they're of that category.
The difference is the ddoc code posted h
On 1/1/2015 6:00 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
See, this is my point. $(INTERVAL x .. y) is, to my mind, less clear to read
_in the source_ than [x, y).
My point is there's ALWAYS going to be some sort of escaping mechanism, and it
is ALWAYS going to interfere with the
On Thursday, 11 December 2014 at 12:22:46 UTC, Martin Nowak wrote:
What's up with this new website design ?
Drafts looked good.
Yeah, draft looks good, but this didn't got the priority and
support it deserves.
So, is it dead already ?
On Thursday, 1 January 2015 at 20:00:12 UTC, Ola Fosheim Grøstad
wrote:
Because it is true? :-) Documents are old fashion, what you
want is an interactive frontend to an information database.
One thing I would like to do is add $(TAGS sorting, searching)
etc to functions where applicable which
On Thursday, 1 January 2015 at 18:15:10 UTC, Ary Borenszweig
wrote:
I really don't understand why you say that.
Because it is true? :-) Documents are old fashion, what you want
is an interactive frontend to an information database.
I would suggest D to use a simple language to write the
doc
On Thursday, 1 January 2015 at 18:43:12 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Fri, Jan 02, 2015 at 02:56:16AM +1000, Manu via
Digitalmars-d wrote:
Does anyone know how to fix this? Can we please do so? It's
been a
problem for like 5 years it seems.
It's a bit insane that we can't resolve
On Thursday, 1 January 2015 at 19:57:56 UTC, Walter Bright wrote:
Is also hard to read. Yes, I'm being facetious, but take a look
at those examples posted here about how ugly Ddoc is - they're
of that category.
The difference is the ddoc code posted here is copied verbatim
from a real world
On 1/1/15, Walter Bright via Digitalmars-d wrote:
> On 1/1/2015 8:19 AM, Manu via Digitalmars-d wrote:
>> I was thinking more along the lines of letting doxygen inspire
>> enhancements to ddoc, since as far as I can see, it's pretty much the
>> standard these days, and people already know it.
>
>
On 1/1/2015 8:39 AM, Manu via Digitalmars-d wrote:
It's just noisy and hard to read, as
I think we've established to be the popular opinion.
I'm sure we can also agree that:
#include\
#include\
int main\
(){print\
f("hello\
world\n\
");retur\
n EXIT_S\
UCCESS;}
Is also hard to read. Yes,
On 01/01/15 20:42, Walter Bright via Digitalmars-d wrote:
On 1/1/2015 8:19 AM, Manu via Digitalmars-d wrote:
I was thinking more along the lines of letting doxygen inspire
enhancements to ddoc, since as far as I can see, it's pretty much the
standard these days, and people already know it.
And
Could you give a concrete example of using your Match template?
e.g. to perform a different action for floating point or integral
values.
Hey all, I've found myself leaning on a really versatile pattern
a lot lately, thought I'd share it: this is for those situations
where you might have some
On 1/1/2015 8:19 AM, Manu via Digitalmars-d wrote:
I was thinking more along the lines of letting doxygen inspire
enhancements to ddoc, since as far as I can see, it's pretty much the
standard these days, and people already know it.
And others are saying "Markdown is the standard."
BTW, Boost
On Thu, Jan 01, 2015 at 01:42:45PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
> On 12/31/14 6:05 PM, Dicebot wrote:
> >On Wednesday, 31 December 2014 at 22:58:57 UTC, H. S. Teoh via
> >Digitalmars-d wrote:
> >>people demanded Tuple support.
> >
> >Was it bearophile? :P I can't stop feeli
On Thursday, 1 January 2015 at 18:24:47 UTC, JN wrote:
I should be able to click SysTime and go to that type
definition.
Don't know why it's not working for Phobos, but vibe.d
documentation seems to have clickable types
(http://vibed.org/api/)
vibe.d docs are generated using custom tool by
On 1/1/15 3:32 AM, Walter Bright wrote:
On 1/1/2015 1:47 AM, Andrei Alexandrescu wrote:
Stars and underlines are popular due to markdown. There'd be
limitations, e.g.
pairs occurring across a ddoc parent won't be considered for expansion
etc. Also
the defaults can be written to be idempotent. (B
On 1/1/15 3:00 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
I'm hoping that I'm just missing a Ddoc trick here, but I don't think so
:-(
You're not but that's really rare. uniform01 is a rare case of unpaired
paren in code. -- Andrei
On 29/12/14 05:13, Andrei Alexandrescu via Digitalmars-d wrote:
I did want to say something about this. I've given a close read to the "Lost a
new commercial user this week" thread, through and through. It seems I've
identified a problem that belongs to us. ("Us" is a vacuous term meaning "the
le
On 12/31/14 6:05 PM, Dicebot wrote:
On Wednesday, 31 December 2014 at 22:58:57 UTC, H. S. Teoh via
Digitalmars-d wrote:
people demanded Tuple support.
Was it bearophile? :P I can't stop feeling that it is simply not
recognized enough how bad D tuples are if such request arises. I'd
personally
On Thursday, 1 January 2015 at 07:40:50 UTC, Shachar Shemesh
wrote:
Add to that the fact that the language's name is a single
letter, and you find yourself looking for "D is". Try it. The
results are unhelpful. Searching for "dlang is" is somewhat
better, but not much. TDPL's table of contents
On Fri, Jan 02, 2015 at 02:56:16AM +1000, Manu via Digitalmars-d wrote:
> Does anyone know how to fix this? Can we please do so? It's been a
> problem for like 5 years it seems.
> It's a bit insane that we can't resolve any non-linear functions at
> compile time.
I've been waiting for this since l
On Thursday, 1 January 2015 at 18:15:10 UTC, Ary Borenszweig
wrote:
and I can't believe that after 10+ years of development, D
documentation still doesn't have a basic feature like
inter-linking between types (I even once submitted a PR but it
wasn't accepted because other code was written on t
On 1/1/15 2:35 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
On Thursday, 1 January 2015 at 17:19:09 UTC, Ary Borenszweig wrote:
What's cross-library-indexing? You mean show documentation for many
libraries at once?
Yes, many libraries, source code with builtin links, links to github
with
On Thursday, 1 January 2015 at 16:56:24 UTC, Manu via
Digitalmars-d wrote:
Does anyone know how to fix this? Can we please do so? It's
been a
problem for like 5 years it seems.
It's a bit insane that we can't resolve any non-linear
functions at
compile time.
I was looking for a relevant issu
As long as you are actually forced to use _any_ kind of macros in
basic documentation it won't be good enough.
Raw source is most commonly read form of any documentation
(unless it is Phobos or other stdlib) and it is most important
one. Looking acceptable is not enough, raw documentation code
Manu via Digitalmars-d wrote:
> Does anyone know how to fix this? Can we please do so? It's been a
> problem for like 5 years it seems.
> It's a bit insane that we can't resolve any non-linear functions at
> compile time.
I've been hoping for that too for a long time. Application to memoization
t
On Thursday, 1 January 2015 at 14:37:31 UTC, Adam D. Ruppe wrote:
On Thursday, 1 January 2015 at 14:22:19 UTC, ponce wrote:
I actually like DDoc as it is, and finds it readable.
You know, if $(D_CODE) escaped the code properly and `code` was
a shortcut to it... that'd actually solve my big co
On Thursday, 1 January 2015 at 17:19:09 UTC, Ary Borenszweig
wrote:
What's cross-library-indexing? You mean show documentation for
many libraries at once?
Yes, many libraries, source code with builtin links, links to
github with line numbers, docs for other languages when D
wrappers are provi
Let's try to get state-of-the-art ddoc in here. Iff my backtick
PR goes through, I'll do another one bringing some of these
tricks to the default macro list.
What I want to do in this thread is get the nicest ddoc bits we
can do and analyze where they fail. If they rock, let's just put
those
On 12/31/14 3:51 PM, Rikki Cattermole wrote:
On 1/01/2015 4:23 a.m., Jacob Carlborg wrote:
On 2014-12-30 06:13, Rikki Cattermole wrote:
Hmm I have an idea.
I wonder if I can get ddoc to generate json files.
You would still need to write the documentation in Ddoc, which is what
we're complain
On 1/1/15 1:23 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
On Thursday, 1 January 2015 at 15:01:13 UTC, Ary Borenszweig wrote:
it is. There's no need for macros. There's no need to generate JSON,
XML, YAML, PDF or anything other than HTML, which is quite universal
and accessible now.
Yo
On Thu, Jan 01, 2015 at 01:19:06AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 12/31/14 1:12 PM, Dicebot wrote:
> >I don't feel like any small change in DDOC will make me like/use it.
>
> I'm envisioning quite an interesting possibility in which certain
> constructs are automatically
On 01/01/15 17:16, Manu via Digitalmars-d wrote:
Doxygen supports both @param and \param.
Ah yes, I'd forgotten that. It's been a while :-\
It would be really good if doxygen supported D comprehensively. I
often port C code to D which already has doxygen commentary. I never
port the doxygen
On Tuesday, 30 December 2014 at 21:22:01 UTC, Kiith-Sa wrote:
(accidentally posted this into D.learn first, was intended to
be here)
A few weeks/months ago someone here mentioned that it'd be good
if DUB projects linked to code.dlang.org to help anyone who runs
into such a project quickly disco
Does anyone know how to fix this? Can we please do so? It's been a
problem for like 5 years it seems.
It's a bit insane that we can't resolve any non-linear functions at
compile time.
On 2 January 2015 at 02:06, ponce via Digitalmars-d
wrote:
> On Thursday, 1 January 2015 at 15:46:07 UTC, Manu via Digitalmars-d wrote:
>>
>> I feel like the colour space should be attached to the colour. Why would
>> you make it a separate object?
>>
>
> If the color space is a runtime object (eg
On 1 January 2015 at 21:51, Walter Bright via Digitalmars-d
wrote:
> On 12/31/2014 10:17 PM, Manu via Digitalmars-d wrote:
>>
>> Why is doxygen insufficient? Is there a reason ddoc was invented
>> rather than supporting the practically-industry-standard doxygen
>> format from the start?
>
>
> Ther
On Thursday, 1 January 2015 at 15:09:22 UTC, Dicebot wrote:
My top list of md shortcuts for "casual" documentation:
1. `code`
https://github.com/D-Programming-Language/dmd/pull/4228
That's by far my #1 syntax-wise, and since my implementation uses
the existing code, it will be relevant sema
On Thursday, 1 January 2015 at 15:01:13 UTC, Ary Borenszweig
wrote:
it is. There's no need for macros. There's no need to generate
JSON, XML, YAML, PDF or anything other than HTML, which is
quite universal and accessible now.
You only need to generate XML with high quality semantic markup
for
On Thursday, 1 January 2015 at 12:05:03 UTC, Walter Bright wrote:
There is also nothing stopping anyone from using Doxygen if
they prefer it.
Sure, but there is a big advantage in having a the same tech doc
format for all libraries for the same language/group of languages.
I've spent way too
On 1 January 2015 at 20:16, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 1/1/15 2:02 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
>>
>> On 01/01/15 10:33, Andrei Alexandrescu via Digitalmars-d wrote:
>>>
>>> No particular system was clearly dominant when Walter invented ddoc.
>>> Also
On 1 January 2015 at 20:02, Joseph Rushton Wakeling via Digitalmars-d
wrote:
> On 01/01/15 10:33, Andrei Alexandrescu via Digitalmars-d wrote:
>>
>> No particular system was clearly dominant when Walter invented ddoc. Also
>> I
>> might be frequenting the wrong circles; most people I know and myse
On Thursday, 1 January 2015 at 15:46:07 UTC, Manu via
Digitalmars-d wrote:
On 2 January 2015 at 01:09, ponce via Digitalmars-d
wrote:
On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via
Digitalmars-d wrote:
I've been working on a pretty comprehensive module for
dealing with
colours in vari
On 1 January 2015 at 19:33, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 12/31/14 10:17 PM, Manu via Digitalmars-d wrote:
>>
>> On 1 January 2015 at 05:50, Andrei Alexandrescu via Digitalmars-d
>>
>> wrote:
>>>
>>> Hello,
>>>
>>>
>>> In wake of the recent discussions on improving ddoc syntax
On 2 January 2015 at 01:09, ponce via Digitalmars-d
wrote:
> On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via Digitalmars-d wrote:
>>
>> I've been working on a pretty comprehensive module for dealing with
>> colours in various formats and colour spaces and conversions between
>> all of these.
On Thursday, 1 January 2015 at 15:21:40 UTC, ponce wrote:
On Thursday, 1 January 2015 at 14:41:00 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:
On 01/01/15 15:26, Adam D. Ruppe via Digitalmars-d wrote:
Again those are: *bold* and `code`.
I would be inclined to prefer ``code`` or ```co
On Thursday, 1 January 2015 at 14:41:00 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:
On 01/01/15 15:26, Adam D. Ruppe via Digitalmars-d wrote:
Again those are: *bold* and `code`.
I would be inclined to prefer ``code`` or ```code```, simply
because it's valid D syntax to have,
a
On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via
Digitalmars-d wrote:
I've been working on a pretty comprehensive module for dealing
with
colours in various formats and colour spaces and conversions
between
all of these.
It seems like a hot area for duplicated effort, since anything
that
On Monday, 29 December 2014 at 05:43:13 UTC, Walter Bright wrote:
Often I'll pipe the pretty-printed debug output to a file, as
it can be voluminous, and then actually edit the file to bring
out what I need.
Not possible with a debugger.
I think it is. Here is a small adjustment to consid
My top list of md shortcuts for "casual" documentation:
1. `code`
2. * lists
headers
3. ===
--
4. | tables | that are |
--
| pretty | in source |
--
On 1 January 2015 at 20:28, Jacob Carlborg via Digitalmars-d
wrote:
> On 2015-01-01 07:38, Manu via Digitalmars-d wrote:
>>
>> I've been working on a pretty comprehensive module for dealing with
>> colours in various formats and colour spaces and conversions between
>> all of these.
>> It seems li
On 12/31/14 4:50 PM, Andrei Alexandrescu wrote:
Hello,
In wake of the recent discussions on improving ddoc syntax we're looking
at doing something about it. Please discuss any ideas you might have
here. Thanks!
One simple starter would be to allow one escape character, e.g. the
backtick (`), a
On 2 January 2015 at 00:59, Dicebot via Digitalmars-d
wrote:
> Something that creates an API bridge between different external libraries is
> naturally a good fit for Phobos and exactly type of additions I'd like to
> see there. I think only concern is where exactly to put it :
> std.media.image.c
On 1 January 2015 at 23:11, Andrej Mitrovic via Digitalmars-d
wrote:
> On 1/1/15, Manu via Digitalmars-d wrote:
>> Does it seem like something we should see added to phobos?
>
> You're likely to have more success making it an independent library
> and putting it on code.dlang.org.
>
> Remember th
On Thursday, 1 January 2015 at 14:24:36 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:
On 01/01/15 13:55, Gary Willoughby via Digitalmars-d wrote:
I'm seriously considering writing a new blog article for
reddit, highlighting
the attitudes in this discussion because they are so seriously
Something that creates an API bridge between different external
libraries is naturally a good fit for Phobos and exactly type of
additions I'd like to see there. I think only concern is where
exactly to put it : std.media.image.colour sounds like a most
fitting qualified path to me but that is
On 1 January 2015 at 21:30, via Digitalmars-d
wrote:
> On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via Digitalmars-d wrote:
>>
>> My colours can be used as high-level colour values for precise numeric
>> work, or specify encodings such that they are directly useful to
>> represent pixels in
On 1 January 2015 at 22:43, Phil via Digitalmars-d
wrote:
>>
>> I think it would be a nice addition, but might seem a bit lonely on its
>> own, without an image library. Maybe just put it on code.dlang for now, and
>> then add it together with an image library later?
>
>
> This would be helpful to
On 1 January 2015 at 22:39, Peter Alexander via Digitalmars-d
wrote:
> On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via Digitalmars-d wrote:
>>
>> I've been working on a pretty comprehensive module for dealing with
>> colours in various formats and colour spaces and conversions between
>> all
On Thursday, 1 January 2015 at 14:41:00 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:
I would be inclined to prefer ``code`` or ```code```, simply
because it's valid D syntax to have,
auto someString = `Some great big string`;
Eh, that breaks my habit from stack overflow. How ofte
On 1 January 2015 at 19:47, Walter Bright via Digitalmars-d
wrote:
> On 12/31/2014 8:46 PM, Manu via Digitalmars-d wrote:
>>
>> Okay, well it's not really useful without a forceinline attribute.
>> std.simd functions need to be pseudo-intrinsics, ie, the cost of a
>> function call will definitely
On 01/01/15 15:26, Adam D. Ruppe via Digitalmars-d wrote:
Again those are: *bold* and `code`.
I would be inclined to prefer ``code`` or ```code```, simply because it's valid
D syntax to have,
auto someString = `Some great big string`;
On Thursday, 1 January 2015 at 14:22:19 UTC, ponce wrote:
I actually like DDoc as it is, and finds it readable.
You know, if $(D_CODE) escaped the code properly and `code` was a
shortcut to it... that'd actually solve my big complaints with
the ddoc language itself and make it convenient.
R
On Thursday, 1 January 2015 at 11:33:25 UTC, Walter Bright wrote:
Ddoc assumes ( ) nests. But this would require that these
characters nest, too:
*abc_def * _i
for example, which is stretching things a bit because they do
not naturally nest.
I think someone who writes *long bold text
li
1 - 100 of 152 matches
Mail list logo
