On Wednesday, December 13, 2017 06:14:04 bauss via Digitalmars-d wrote:
> Documentation can be done like this for multiline:
>
> /**
> * ...
> * ...
> * etc.
> */
>
> Instead of:
>
> /// ...
> /// ...
> /// etc.
You can also do
/**
...
...
etc.
*/
or
/++
...
...
etc.
+/
Personally,
On 12/12/2017 07:15 PM, IM wrote:
I started learning D recently.
Welcome! There is also the Learn newsgroup[1]. ;)
Ali
[1] Available through a forum interface here:
http://forum.dlang.org/group/learn
On Wednesday, 13 December 2017 at 03:15:11 UTC, IM wrote:
Thanks!
First thing.
Generally in D module names are kept lower-case.
To give an example your:
AbstractTaskRunner.d
module tasks.AbstractTaskRunner;
Would usually be:
abstracttaskrunner.d
module tasks.abstracttaskrunner;
Of course it
I started learning D recently. As part of the learning process, I
started working on some D projects to experiment and learn. My
first project is a tasking system library that I plan to use in
another D project I'm working on.
The goal is to be able to post and run any task asynchronously on
Here's a page that describes the issue:
http://ssp.impulsetrain.com/gamma-premult.html
On Wednesday, 13 December 2017 at 01:44:33 UTC, Dmitry wrote:
On Tuesday, 12 December 2017 at 23:28:23 UTC, Ivan Trombley
wrote:
Here's the code that produces the correct results (exactly the
same as GIMP):
Share images you used, please.
Background image:
http://a4.pbase.com/o10/09/605909/1/1
On Tuesday, December 12, 2017 16:12:50 Adam D. Ruppe via Digitalmars-d
wrote:
> On Tuesday, 12 December 2017 at 11:33:45 UTC, Jonathan M Davis
>
> wrote:
> > Personally, I would _very_ much like to see the magic
> > formatting in ddoc kept to a minimum.
>
> You know what drives me nuts? This* is w
On Tuesday, 12 December 2017 at 23:28:23 UTC, Ivan Trombley wrote:
Here's the code that produces the correct results (exactly the
same as GIMP):
Share images you used, please.
On Tuesday, 12 December 2017 at 23:25:19 UTC, Neia Neutuladh
wrote:
Have you noticed performance problems or implementation side
irregularities?
Well, I was referring to things like in front() having to use
code such as `if(!inited) ...; return value`, which was discussed
here in the forum in
GIMP 2.9, that is.
On Tuesday, 12 December 2017 at 07:12:07 UTC, Dmitry wrote:
On Tuesday, 12 December 2017 at 06:27:30 UTC, Ivan Trombley
wrote:
This isn't a scaling problem (which is totally solved by
Scaling is not a prerequisite for this problem.
pre-multiplying the alpha with the colors BTW). This is a gam
On Tuesday, 12 December 2017 at 18:58:11 UTC, Luís Marques wrote:
Ok, so the consensus was to make ranges easy to use. Was there
any progress on mechanisms to avoid the possible performance
penalties, and to make the implementation side more regular?
Have you noticed performance problems or im
Looks like your only options are to stone her or marry her.
On 12/12/17 7:49 AM, ketmar wrote:
see documentation:
http://dpldocs.info/experimental-docs/std.conv.toChars.html
"...Can be uint or ulong. If radix is 10, can also be int or long."
45 is int, not uint. so no radices except `10` will work.
So, the answer is:
toChars!2(45u);
BTW, I find thi
On Tuesday, 12 December 2017 at 20:31:36 UTC, unazed wrote:
[...]
Best to tell all ur friends.
I don't know if Dlang.org is the right place for this thread, but
I honestly have no where else to turn because this situation
directly involves my family, and friends.
Let me start from the beginning, I am 18 and my sister is 21. I
just finished high school and my sister is home from college. I
On Tuesday, 12 December 2017 at 18:40:51 UTC, Seb wrote:
Spec: "r.front can be legally evaluated if and only if
evaluating r.empty has, or would have, equaled false."
Spec: "r.front evaluated multiple times, without calling
r.popFront, or otherwise mutating the range object or the
underlying
On Tuesday, 12 December 2017 at 18:32:11 UTC, Luís Marques wrote:
What's the current state of the range specification?
-> https://dlang.org/phobos/std_range_primitives.html#isInputRange
For instance, do we have to call empty before calling front?
Spec: "r.front can be legally evaluated if a
What's the current state of the range specification? For
instance, do we have to call empty before calling front? Can
front provide different answers each time (e.g. map)? Were these
kinds of issues resolved or not? Is Phobos respecting some
consensual protocol or are there still gotchas?
On Tuesday, 12 December 2017 at 02:30:39 UTC, Walter Bright wrote:
On 12/11/2017 2:30 PM, Jakob Bornecrantz wrote:
It is not written in D, but the language is close enough in
concepts that it can be mechanically ported into D, and is
licensed under BOOST. Feel free to do what ever to it[1].
T
On 12/12/17 17:20, Stefan Koch wrote:
On Tuesday, 12 December 2017 at 14:49:04 UTC, Shachar Shemesh wrote:
module foo;
import std.traits;
[...]
A template is not a symbol as is.
And eponymous templates alias them-selfs to the symbol they define on
instancing
And yet, "bar", which is a tem
On Tuesday, 12 December 2017 at 16:12:50 UTC, Adam D. Ruppe wrote:
Ugh. Or why is _this_ italic?
I know! /This should be italic./ _This should be underlined._ How
anyone could manage to mess those up is way beyond me. Some
digging indicates it's a decision based on the fact that both are
use
On Tuesday, 12 December 2017 at 11:33:45 UTC, Jonathan M Davis
wrote:
Personally, I would _very_ much like to see the magic
formatting in ddoc kept to a minimum.
You know what drives me nuts? This* is weird.
* it is rendered as a list item! And I know, you can do \*. But
ugh.
Ugh. Or why is
On Tuesday, 12 December 2017 at 15:59:42 UTC, John Gabriele wrote:
On Monday, 11 December 2017 at 00:54:00 UTC, Walter Bright
wrote:
I have a more pragmatic definition of a standard:
1. Products that implement it say they adhere to it and defer
to it as the authority on correct behavior.
2.
On Monday, 11 December 2017 at 00:54:00 UTC, Walter Bright wrote:
I have a more pragmatic definition of a standard:
1. Products that implement it say they adhere to it and defer
to it as the authority on correct behavior.
2. There's more than one such product.
3. There's more products adher
On Tuesday, 12 December 2017 at 15:19:48 UTC, ketmar wrote:
p.s.: but no, i am wrong.
foo(-42);
this is perfectly valid for `foo (uint n)`, as D converts
negative ints to uints without any warnings.
so no, overloads won't fit.
hmm yes, it seems it is not possible.
On Tuesday, 12 December 2017 at 14:49:04 UTC, Shachar Shemesh
wrote:
module foo;
import std.traits;
[...]
A template is not a symbol as is.
And eponymous templates alias them-selfs to the symbol they
define on instancing
John Colvin wrote:
On Tuesday, 12 December 2017 at 12:49:32 UTC, ketmar wrote:
see documentation:
http://dpldocs.info/experimental-docs/std.conv.toChars.html
"...Can be uint or ulong. If radix is 10, can also be int or long."
45 is int, not uint. so no radices except `10` will work.
I thin
p.s.: but no, i am wrong.
foo(-42);
this is perfectly valid for `foo (uint n)`, as D converts negative ints to
uints without any warnings.
so no, overloads won't fit.
On Tuesday, 12 December 2017 at 12:49:32 UTC, ketmar wrote:
see documentation:
http://dpldocs.info/experimental-docs/std.conv.toChars.html
"...Can be uint or ulong. If radix is 10, can also be int or
long."
45 is int, not uint. so no radices except `10` will work.
I think it would be possi
module foo;
import std.traits;
void bar(T)() {
}
pragma(msg, "id: ", fullyQualifiedName!(bar));
pragma(msg, "parent: ", fullyQualifiedName!(__traits(parent, bar)));
pragma(msg, "id: ", fullyQualifiedName!(bar!int));
pragma(msg, "parent: ", fullyQualifiedName!(__trai
On Sunday, 10 December 2017 at 06:20:43 UTC, Walter Bright wrote:
Besides, commonmark has a lot of stuff we don't need, like
multiple ways of doing the same thing.
We would have to come with style guidelines to avoid a mix of say:
*italic* and _italic_
# Heading 1 and
Heading 1
==
B
On Tuesday, 12 December 2017 at 13:50:42 UTC, Bastiaan Veelo
wrote:
On Tuesday, 12 December 2017 at 11:48:24 UTC, Chris wrote:
On Tuesday, 12 December 2017 at 11:33:45 UTC, Jonathan M Davis
wrote:
And then you have to worry about something like int* screwing
with things, because the compiler
On Tuesday, 12 December 2017 at 13:50:42 UTC, Bastiaan Veelo
wrote:
On Tuesday, 12 December 2017 at 11:48:24 UTC, Chris wrote:
On Tuesday, 12 December 2017 at 11:33:45 UTC, Jonathan M Davis
wrote:
And then you have to worry about something like int* screwing
with things, because the compiler
On Tuesday, 12 December 2017 at 11:48:24 UTC, Chris wrote:
On Tuesday, 12 December 2017 at 11:33:45 UTC, Jonathan M Davis
wrote:
And then you have to worry about something like int* screwing
with things, because the compiler decides that you wanted
italics. Honestly, I don't think that someth
see documentation: http://dpldocs.info/experimental-docs/std.conv.toChars.html
"...Can be uint or ulong. If radix is 10, can also be int or long."
45 is int, not uint. so no radices except `10` will work.
Greetings
This small code snippet works:
//
import std.conv;
import std.stdio;
void main() {
writeln(toChars!10(45));
}
But if I change toChars!10 with toChars!2, I get:
/tmp/test.d(6): Error: template std.conv.toChars cannot deduce
function from argument types !(2)(int), candidates are:
On Tuesday, 12 December 2017 at 11:48:24 UTC, Chris wrote:
Try this one (paste it into http://spec.commonmark.org/dingus/):
# CommonMark
```
int* ptr;
```
`int*` is a pointer to an integer.
int* is a pointer to an integer.
The output is
CommonMark
int* ptr;
int* is a pointer to a
On Tuesday, 12 December 2017 at 11:33:45 UTC, Jonathan M Davis
wrote:
And then you have to worry about something like int* screwing
with things, because the compiler decides that you wanted
italics. Honestly, I don't think that something like $(I foo)
is very onerous - it's not all that diffe
On Tuesday, December 12, 2017 10:22:24 meppl via Digitalmars-d wrote:
> On Tuesday, 12 December 2017 at 06:55:45 UTC, Jonathan M Davis
>
> wrote:
> > On Tuesday, December 05, 2017 20:11:33 Walter Bright via
> >
> > Digitalmars-d wrote:
> >> https://help.github.com/articles/basic-writing-and-formatt
Compare:
Output:
https://github.com/vibe-d/vibe.d/blob/master/README.md
Input:
https://raw.githubusercontent.com/vibe-d/vibe.d/master/README.md
Most programmers who use GitHub will be familiar with this and
can write docs, tutorials etc. with very little effort. The set
of Markdown used for t
On Monday, 11 December 2017 at 00:54:00 UTC, Walter Bright wrote:
I have a more pragmatic definition of a standard:
1. Products that implement it say they adhere to it and defer
to it as the authority on correct behavior.
2. There's more than one such product.
You have to start somewhere.
On Tuesday, 12 December 2017 at 06:55:45 UTC, Jonathan M Davis
wrote:
On Tuesday, December 05, 2017 20:11:33 Walter Bright via
Digitalmars-d wrote:
https://help.github.com/articles/basic-writing-and-formatting-syntax/
Anyone interested in picking up the flag?
(I know this has come up before, a
On Tuesday, December 12, 2017 09:25:57 Seb via Digitalmars-d wrote:
> On Tuesday, 12 December 2017 at 08:19:39 UTC, Piotr Mitana wrote:
> > Hello,
> >
> > I'd like to make a little suggestion for phobos: enrich
> > findSplit* method family with the "needleless" predicate option.
> >
> > [...]
>
> .
On Tuesday, 12 December 2017 at 08:19:39 UTC, Piotr Mitana wrote:
Hello,
I'd like to make a little suggestion for phobos: enrich
findSplit* method family with the "needleless" predicate option.
[...]
... or you simply use `until`:
auto r = ["23", "42", "14.3", "-323", "}"];
r.until!(x =>
On Tuesday, 12 December 2017 at 09:17:21 UTC, bauss wrote:
On Tuesday, 12 December 2017 at 08:19:39 UTC, Piotr Mitana
wrote:
Hello,
I'd like to make a little suggestion for phobos: enrich
findSplit* method family with the "needleless" predicate
option.
[...]
Either do it yourself and crea
On Tuesday, 12 December 2017 at 08:19:39 UTC, Piotr Mitana wrote:
Hello,
I'd like to make a little suggestion for phobos: enrich
findSplit* method family with the "needleless" predicate option.
[...]
Either do it yourself and create a pull-request or go here
instead of posting in the forum
Hello,
I'd like to make a little suggestion for phobos: enrich
findSplit* method family with the "needleless" predicate option.
Motivation:
Let's have a range of string tokens that - after cutting of the
initial brace - looks like this:
auto range = ["23", "42", "14.3", "-323", "}"]
N
On 12/11/2017 07:18 PM, Joakim wrote:
> On Friday, 8 December 2017 at 09:33:03 UTC, Ali Çehreli wrote:
>> I failed to find a way for Druntime to be resilient when such threads
>> disappear. For example, the registered cleanup handler in thread.d is
>> called only for cancelled threads, not the on
49 matches
Mail list logo
