"Benjamin Thaut" wrote in message news:mbuok2$pn5$1...@digitalmars.com...
Error: ICE: Unsupported type void()
So close...
Good news is that that's a compiler bug and not a language limitation.
Although allowing you to pass a function type to a template in the first
place might also be a co
On Tuesday, 17 February 2015 at 07:28:03 UTC, weaselcat wrote:
Would RefCounted!T being @nogc help alleviate this issue?
I've heard of RefCounted and I understand the concept but I've
never used it. I'll do some reading a some experiments. Maybe
this will work :)
On Monday, 16 February 2015 at 23:17:03 UTC, Jonathan Marler
wrote:
Is there a proposal for how D will support throwing Exceptions
in @nogc code in the future? I've searched the forums and
found different proposals that involve things like
pre-allocated exceptions, non-gc heap allocated except
On Tuesday, 17 February 2015 at 05:52:23 UTC, philippecp wrote:
I was wondering the same myself. I think there would be a lot
of negative side effects to using alternate memory model other
than GC (non-gc could introduce leaks, on stack has potential
to be overwritten). For that reason, I think
Am 17.02.2015 um 02:21 schrieb Daniel Murphy:
struct X(T) { pragma(msg, X.stringof); }
void main()
{
X!(typeof(*(void function()).init)) x;
}
Error: ICE: Unsupported type void()
So close...
On Monday, 16 February 2015 at 06:21:22 UTC, H. S. Teoh wrote:
On Sun, Feb 15, 2015 at 04:02:30PM -0800, Andrei Alexandrescu
via Digitalmars-d wrote:
[...]
* We have the fastest compiler _and_ language in the world,
yet it's
impossible to unittest one module; unittesting one requires
building
I was wondering the same myself. I think there would be a lot of
negative side effects to using alternate memory model other than
GC (non-gc could introduce leaks, on stack has potential to be
overwritten). For that reason, I think the only choices that make
sense are that either @nogc function
On Monday, 16 February 2015 at 21:41:00 UTC, Walter Bright wrote:
On 2/16/2015 12:19 PM, Jacob Carlborg wrote:
Most likely due to that the support for dynamic libraries is
fairly new only
works on Linux (?).
Part of the test suite creates a DLL using D for Windows.
Martin recently added sha
On Mon, Feb 16, 2015 at 08:20:10PM -0800, H. S. Teoh via Digitalmars-d wrote:
[...]
> Not sure how to fix this, as the anchor name probably shouldn't have
> embedded spaces. :-(
[...]
Actually, this irritated me so much that I decided to hack-fix it:
https://github.com/D-Programming-Langu
On Mon, Feb 16, 2015 at 07:51:16PM -0800, H. S. Teoh via Digitalmars-d wrote:
> Something recently broke in the dlang.org repo; now multi-word headings
> are not properly rendered in HTML. See, for example:
>
> http://dlang.org/phobos-prerelease/std_string#.translate
>
> The heading "SeeAls
Something recently broke in the dlang.org repo; now multi-word headings
are not properly rendered in HTML. See, for example:
http://dlang.org/phobos-prerelease/std_string#.translate
The heading "SeeAlso" appears as a single word, whereas it should be two
words "See Also". This doesn't app
On Monday, 16 February 2015 at 11:57:36 UTC, FG wrote:
On 2015-02-16 at 07:06, Vlad Levenfeld wrote:
*ContigiousRange* has enough length [...]
LOL. The clearly masochistic C++ committee needs to be
applauded for introducing what may become the biggest source of
typos. :)
Adjoining would b
"Benjamin Thaut" wrote in message news:mbtena$2n46$1...@digitalmars.com...
I understand that "void function()" is actually a function pointer and
thus the mangling is "correct". But in what way would you actually able
to mirror the C++ declaration of ezDelegate? Does it even work? This
would
Is there a proposal for how D will support throwing Exceptions in
@nogc code in the future? I've searched the forums and found
different proposals that involve things like pre-allocated
exceptions, non-gc heap allocated exceptions or even stack
allocated exceptions. I don't want to debate the
On Monday, 16 February 2015 at 20:31:22 UTC, Andrei Alexandrescu
wrote:
Martin, as our release czar you may want to publish the planned
ship date. -- Andrei
Isn't it already "published"?
http://dlang.org/changelog.html
On 2/16/2015 12:19 PM, Jacob Carlborg wrote:
Most likely due to that the support for dynamic libraries is fairly new only
works on Linux (?).
Part of the test suite creates a DLL using D for Windows.
On Sunday, 15 February 2015 at 04:24:12 UTC, Craig Dillabaugh
wrote:
On Saturday, 14 February 2015 at 06:56:00 UTC, Russel Winder
wrote:
Craig,
I have signed up on Melange as a potential mentor, user name
russel_winder.
Thank you.
Russel,
I haven't yet heard from Martin on his Melange name
On 2/16/15 1:23 AM, Daniel Murphy wrote:
"bearophile" wrote in message news:jufdlgyynxiwbqubb...@forum.dlang.org...
D associative arrays used to be O(1) amortized and O(n ln n) in worst
case.
No, they were still O(n) worst case, for a single bucket with a
degenerate binary tree.
IIRC, the
On 2/16/15 5:10 AM, Daniel Murphy wrote:
"Marc Schütz" " wrote in message
news:iftpzvhoyxxqhbfsx...@forum.dlang.org...
To be really consistent,
x in arr
would need to be equivalent to:
(x >= 0) && (x < arr.length)
`in` tests for the presence of a _key_ in AAs, and the equivalent
noti
On 2/16/15 11:46 AM, H. S. Teoh via Digitalmars-d wrote:
On Mon, Feb 16, 2015 at 09:36:57AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
On 2/16/15 6:33 AM, H. S. Teoh via Digitalmars-d wrote:
[...]
One thought about "forward" and "SortOutput" - first may e.g. go in
std.functional and
On 2/16/15 12:23 PM, Jacob Carlborg wrote:
On 2015-02-16 17:51, Gary Willoughby wrote:
I agree.
To be brutally honest the biggest release mistakes (which seems to be
getting worse lately) are D releases with outstanding regressions.
That's pretty unacceptable IMHO.
Yes, and that someone thin
On 2015-02-16 17:51, Gary Willoughby wrote:
I agree.
To be brutally honest the biggest release mistakes (which seems to be
getting worse lately) are D releases with outstanding regressions.
That's pretty unacceptable IMHO.
Yes, and that someone thinks we need release on a specific date, even
On 2015-02-16 10:40, Benjamin Thaut wrote:
This is in fact not a breaking change because export is broken anyway.
Due to bug 922 export can't be used in cross platform libraries. I
haven't seen a single library on dub that uses export (most likely for
exactly that reason).
Most likely due to t
On Mon, 16 Feb 2015 09:36:57 -0800, Andrei Alexandrescu wrote:
> * There is no added value to D users in splitting algorithm.d into a
> package.
>
> * Even the value to contributors is debatable and definitely low impact.
>
> * The documentation is in shambles.
>
> All told we're looking at a n
On Mon, Feb 16, 2015 at 09:36:57AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 2/16/15 6:33 AM, H. S. Teoh via Digitalmars-d wrote:
[...]
> One thought about "forward" and "SortOutput" - first may e.g. go in
> std.functional and the latter belongs to "sorting".
https://github.com/D-P
On 2/14/15 12:00 PM, Andrei Alexandrescu wrote:
There's been recurring discussion about failing constraints not
generating nice error messages.
void fun(T)(T x) if (complicated_condition) { ... }
struct Type(T)(T x) if (complicated_condition) { ... }
If complicated_condition is not met, the sym
I have a c++ struct:
template
struct ezDelegate
{
}
void DelegateTest(ezDelegate func) { ... }
And I want to match that on the D side, unfortunately it does not work:
D:
struct ezDelegate(Signature) {}
alias delegate_t = ezDelegate!(void function());
extern(C++) void DelegateTest(delegate f
On 2/16/15 6:33 AM, H. S. Teoh via Digitalmars-d wrote:
On Sun, Feb 15, 2015 at 07:49:15PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
Just figured that the documentation of package-ized std.algorithm
is... not good:
http://dlang.org/phobos-prerelease/std_algorithm_package.html
It has
On Monday, 16 February 2015 at 16:00:29 UTC, ketmar wrote:
we can't. this issue, for example, was known for monthes (or,
maybe,
years?), yet there is no sign that it's something that MUST be
fixed for
release.
what i want to tell is that there is no release plan, no
feature freeze
before rele
On Sun, 15 Feb 2015 18:19:49 -0800, Andrei Alexandrescu wrote:
> Folks, we want to get 2.067 out the door on March 1. That's two short
> weeks from now. We really need all hands on deck to make this a
> successful release.
we can't. this issue, for example, was known for monthes (or, maybe,
year
On Mon, 16 Feb 2015 12:16:50 +, rupert wrote:
> If you think you could do a better job than the C++ committee you should
> submit a proposal.
>
> https://isocpp.org/std/submit-a-proposal
why he *should* to that? he *may* submit it. when someone sees people
doing shit, he is not obliged to i
On Monday, 16 February 2015 at 14:35:51 UTC, H. S. Teoh wrote:
That PR was merged quickly because std.algorithm is one of the
most
frequently touched parts of Phobos, and a major work like
splitting it
into submodules risked continual merge conflicts with incoming
PRs. I
thought it was more p
On Sun, Feb 15, 2015 at 07:49:15PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
> Just figured that the documentation of package-ized std.algorithm
> is... not good:
>
> http://dlang.org/phobos-prerelease/std_algorithm_package.html
>
> It has two seemingly random names in it: "forward" an
On Monday, 16 February 2015 at 03:49:14 UTC, Andrei Alexandrescu
wrote:
It has two seemingly random names in it: "forward" and
"SortOutput". Also the table at the beginning uses some odd
small fonts for the function names.
About the font issue:
https://github.com/D-Programming-Language/dlan
John Colvin:
I'm quite a fan of python's // operator for integer division,
especially when combined with python 3's choice to make /
always mean floating point division (i.e. 3/2 == float(3)/2,
3//2 == 1). It recognises that integer division is a weird
thing and separates it from the much les
On Monday, 16 February 2015 at 13:10:44 UTC, Daniel Murphy wrote:
"Marc Schütz" " wrote in message
news:iftpzvhoyxxqhbfsx...@forum.dlang.org...
To be really consistent,
x in arr
would need to be equivalent to:
(x >= 0) && (x < arr.length)
`in` tests for the presence of a _key_ in AAs,
"Marc Schütz" " wrote in message
news:iftpzvhoyxxqhbfsx...@forum.dlang.org...
To be really consistent,
x in arr
would need to be equivalent to:
(x >= 0) && (x < arr.length)
`in` tests for the presence of a _key_ in AAs, and the equivalent notion
of a key for arrays is an index.
It
On Sunday, 15 February 2015 at 21:23:13 UTC, Andrei Alexandrescu
wrote:
The one possible change would be to allow "in" with
statically-sized arrays, under the assumption that the amount
of data searched is fixed and proportional to the size of the
program.
To be really consistent,
x in ar
On Monday, 16 February 2015 at 11:57:36 UTC, FG wrote:
On 2015-02-16 at 07:06, Vlad Levenfeld wrote:
*ContigiousRange* has enough length [...]
LOL. The clearly masochistic C++ committee needs to be
applauded for introducing what may become the biggest source of
typos. :)
Adjoining would b
"Casper Færgemand" " wrote in message
news:aenkruurfmfanarke...@forum.dlang.org...
Java 7 changed its HashMap implementation to use TreeMap (red black search
tree) instead of LinkedList for its buckets, if the key can be sorted.
That puts the worst case lookup time from O(n) to O(log n) for so
"FG" wrote in message news:mbsk0i$1ukb$1...@digitalmars.com...
>> No, they were still O(n) worst case, for a single bucket with a
>> degenerate binary > tree.
What binary tree? I don't see any.
There isn't one any more, we're talking about the previous implementation.
On 2015-02-16 at 07:06, Vlad Levenfeld wrote:
*ContigiousRange* has enough length [...]
LOL. The clearly masochistic C++ committee needs to be applauded for
introducing what may become the biggest source of typos. :)
Adjoining would be easier on the non-native English speakers than contiguou
No, they were still O(n) worst case, for a single bucket with a degenerate
binary tree.
What binary tree? I don't see any.
I see. I was unable to hit this degenerate case in my testing code, but I guess
that was possible. Thank you.
From what I can see in druntime/rt/aaA.d, the bucket is c
Vlad Levenfeld:
a ContiguousRange would be any RandomAccessRange which has a
member called ptr which supports a dereferencing operator *
that yields an ElementType!R. This notion is useful for
functions which might otherwise perform an element-by-element
transfer to an OutputRange via put, in
Daniel Murphy:
No, they were still O(n) worst case, for a single bucket with a
degenerate binary tree.
I see. I was unable to hit this degenerate case in my testing
code, but I guess that was possible. Thank you.
Bye,
bearophile
On Monday, 16 February 2015 at 09:59:07 UTC, Walter Bright wrote:
--
Here is a list of all things wrong with export:
32 & 64 bit issues:
1) Exporting a global variable leads to a linker error
2) Exporting thread local variables should be an error (at
least it is in c++)
3) The module i
On 2/16/2015 1:40 AM, Benjamin Thaut wrote:
On Monday, 16 February 2015 at 08:08:17 UTC, Walter Bright wrote:
At this point I suggest simply making those private helper functions public
and export them. It gets your project moving without waiting for language
changes (and this is a breaking cha
Recently, std.string.splitterLines() was added to Phobos:
https://github.com/D-Programming-Language/phobos/pull/2987
The previous way to split lines was std.string.splitLines(). splitLines() always
allocated memory. splitterLines() never does.
splitterLines() hews to the emerging trend in P
On Monday, 16 February 2015 at 08:08:17 UTC, Walter Bright wrote:
At this point I suggest simply making those private helper
functions public and export them. It gets your project moving
without waiting for language changes (and this is a breaking
change).
This is in fact not a breaking cha
On Monday, 16 February 2015 at 06:23:06 UTC, Daniel Murphy wrote:
"bearophile" wrote in message
news:jufdlgyynxiwbqubb...@forum.dlang.org...
D associative arrays used to be O(1) amortized and O(n ln n)
in worst case.
No, they were still O(n) worst case, for a single bucket with a
degenerat
On 2/15/15 10:19 PM, H. S. Teoh via Digitalmars-d wrote:
On Sun, Feb 15, 2015 at 04:02:30PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]
* We have the fastest compiler _and_ language in the world, yet it's
impossible to unittest one module; unittesting one requires building a
ton o
On Monday, 16 February 2015 at 08:08:17 UTC, Walter Bright wrote:
On 1/31/2015 11:52 AM, Benjamin Thaut wrote:
@Walter:
Making export a attribute seems to be the preferred choice in
this discussion.
Additionaly this was the result of the last discussion around
export, a year
ago, although for
On 1/31/2015 11:52 AM, Benjamin Thaut wrote:
@Walter:
Making export a attribute seems to be the preferred choice in this discussion.
Additionaly this was the result of the last discussion around export, a year
ago, although for different reasons. The last Discussion resulted in DIP 45
which also
53 matches
Mail list logo
