Am 12.07.2011 06:38, schrieb ChrisW:
Obviously Digital Mars does development in D, but I was wondering if
any other companies have yet taken the plunge -- even if just in their
R&D department -- to try using D as their development language?
I am working for a company that develops photographic
"Jonathan M Davis" wrote in message
news:mailman.1554.1310450510.14074.digitalmar...@puremagic.com...
> Nope. It works for static arrays but not for const or immutable arrays.
> Try
> it. It'll fail. I don't know _why_ it doesn't work, but it doesn't. If it
> did,
> this would be a much smaller
On Tuesday 12 July 2011 15:46:41 Daniel Murphy wrote:
> "Jonathan M Davis" wrote in message
> news:mailman.1552.1310429761.14074.digitalmar...@puremagic.com...
>
> > This enhancement request would make the situation with immutable and
> > const arrays so that they're much more in line with mutabl
"Jonathan M Davis" wrote in message
news:mailman.1552.1310429761.14074.digitalmar...@puremagic.com...
> This enhancement request would make the situation with immutable and const
> arrays so that they're much more in line with mutable container types and
> static arrays:
>
> http://d.puremagic.co
Obviously Digital Mars does development in D, but I was wondering if
any other companies have yet taken the plunge -- even if just in their
R&D department -- to try using D as their development language?
On 07/10/2011 04:13 PM, Max Klyga wrote:
Several weeks ago Andrei mentioned at #d irc channel that he wanted to
implement next_permutation STL function in Phobos.
I thought that would be a nice excercize to implement it myself.
I ported implementation mentioned in this article:
http://marknelson
On 2011-07-11 14:45, Timon Gehr wrote:
> Jonathan M Davis wrote:
> > The solution is to fix template instantiation so that it's smarter when
> > dealing with static arrays and const or immutable arrays:
> > http://d.puremagic.com/issues/show_bug.cgi?id=6148
>
> Unless I am missing something essent
eris Wrote:
> My library uses a straight-forward reactor approach to handle incoming events
> (IO,
> timer etc). The library is structured as one-thread-per-core and as many
> co-routines (fibers) per thread as memory will allow. The threads communicate
> with each other via lock-free single-w
On Tue, 12 Jul 2011 00:58:04 +0300, Timon Gehr wrote:
so wrote:
There is a simple workaround for this type of ranges that are like
iterators, which we know the beginning and the end.
We can improve isForwardRange!R by adding a line hasForwardRange!R. If
it
does have, we return an adaptor wh
On Tue, 12 Jul 2011 00:58:04 +0300, Timon Gehr wrote:
Wouldn't that be quite invasive? I imagine every function that would
want to work
on ranges would then have to provide two versions, one that does the
work and one
that calls the other version after having applied the adaptor(s)?
Cheers
eris Wrote:
> My library uses a straight-forward reactor approach to handle incoming events
> (IO,
> timer etc). The library is structured as one-thread-per-core and as many
> co-routines (fibers) per thread as memory will allow. The threads communicate
> with each other via lock-free single-w
so wrote:
> There is a simple workaround for this type of ranges that are like
> iterators, which we know the beginning and the end.
> We can improve isForwardRange!R by adding a line hasForwardRange!R. If it
> does have, we return an adaptor which gives us a mutable range.
> Good thing is because
Jonathan M Davis wrote:
> The solution is to fix template instantiation so that it's smarter when
> dealing with static arrays and const or immutable arrays:
> http://d.puremagic.com/issues/show_bug.cgi?id=6148
>
Unless I am missing something essential, supporting this would turn the
complexity
o
On Tue, 12 Jul 2011 00:01:55 +0300, Jonathan M Davis
wrote:
The solution is to fix template instantiation so that it's smarter when
dealing with static arrays and const or immutable arrays:
http://d.puremagic.com/issues/show_bug.cgi?id=6148
It's a language issue, not a design issue. Making r
On Tue, 12 Jul 2011 00:37:04 +0300, so wrote:
Good thing is because the original range is mutable we don't need to
worry about anything else.
Typo, "original range is immutable"
On 7/11/2011 12:34 PM, Andrei Alexandrescu wrote:
On 7/11/11 1:03 PM, Johannes Pfau wrote:
Hi,
is it ok to adapt the d-p-l.org library reference style for own
projects?
I'd like to use it for the cairoD documentation.
Fine by me. Walter?
Yes.
On 2011-07-11 13:30, Timon Gehr wrote:
> Jonathan M Davis wrote:
> > On 2011-07-11 09:06, Timon Gehr wrote:
> > > Jonathan M Davis wrote:
> > > > On Sunday 10 July 2011 21:09:27 Mehrdad wrote:
> > > >> I noticed that the code below doesn't work, and I was wondering if
> > > >> it's
> > > >>
> > >
Jonathan M Davis wrote:
> On 2011-07-11 09:06, Timon Gehr wrote:
> > Jonathan M Davis wrote:
> > > On Sunday 10 July 2011 21:09:27 Mehrdad wrote:
> > >> I noticed that the code below doesn't work, and I was wondering if it's
> > >>
> > >> by design (hopefully not):
> > >> immutable SEP = ", ";
> >
On 7/11/11 1:03 PM, Johannes Pfau wrote:
Hi,
is it ok to adapt the d-p-l.org library reference style for own
projects?
I'd like to use it for the cairoD documentation.
Fine by me. Walter?
Andrei
Johannes Pfau Wrote:
> Hi,
>
> is it ok to adapt the d-p-l.org library reference style for own
> projects?
>
> I'd like to use it for the cairoD documentation.
> --
> Johannes Pfau
>
It should be encouraged.
On 2011-07-11 09:06, Timon Gehr wrote:
> Jonathan M Davis wrote:
> > On Sunday 10 July 2011 21:09:27 Mehrdad wrote:
> >> I noticed that the code below doesn't work, and I was wondering if it's
> >>
> >> by design (hopefully not):
> >> immutable SEP = ", ";
> >> ["a", "b"].join(SEP);
> >>
> >> The
bearophile Wrote:
> This comes from a small sub-thread in D.learn (but I have asked for it the
> first time in bug 3837 time ago):
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=28030
>
> I suggest to turn floating point literals like the following i
Hi,
is it ok to adapt the d-p-l.org library reference style for own
projects?
I'd like to use it for the cairoD documentation.
--
Johannes Pfau
You can use the example program from std/demangle.d for that purpose.
My library uses a straight-forward reactor approach to handle incoming events
(IO,
timer etc). The library is structured as one-thread-per-core and as many
co-routines (fibers) per thread as memory will allow. The threads communicate
with each other via lock-free single-writer, single-reader FI
Jonathan M Davis wrote:
> On Sunday 10 July 2011 21:09:27 Mehrdad wrote:
>> I noticed that the code below doesn't work, and I was wondering if it's
>> by design (hopefully not):
>>
>> immutable SEP = ", ";
>> ["a", "b"].join(SEP);
>>
>> The fact that SEP is immutable(char[]) instead of im
.5
3.
And require to write them like this:
0.5
3.0
+1
(Daniel Murphy suggests to allow 1.f and 1.L (and maybe .2f and .2L too)
but I think this is a special case).
-1
On Sun, 10 Jul 2011 13:51:10 -0400, Daniel Murphy
wrote:
"bearophile" wrote in message
news:ivcg7j$ooj$1...@digitalmars.com...
Jacob Carlborg reminds that 1.f conflicts with the UFCS, I think the
suggestion by Daniel Murphy of the special case is not worth it.
If the only reason for remo
28 matches
Mail list logo
