[Issue 1957] 'new' may return same memory to two threads
http://d.puremagic.com/issues/show_bug.cgi?id=1957 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #1 from Martin Nowak c...@dawg.eu 2013-11-01 00:02:46 PDT --- Is this still relevant? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11408] New: allow GC allocations in finalizers
http://d.puremagic.com/issues/show_bug.cgi?id=11408 Summary: allow GC allocations in finalizers Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: c...@dawg.eu --- Comment #0 from Martin Nowak c...@dawg.eu 2013-11-01 00:12:09 PDT --- This has been disabled due to possible memory corruptions in https://github.com/D-Programming-Language/druntime/pull/16. The problem is that cleanup or error checking often does require memory allocations (e.g. bug 7349). We should investigate whether it's possible to have an extra pool for allocations from finalizers. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11392] dirEntries segfaults (fails in 2.064 beta 4, works in 2.063.2)
http://d.puremagic.com/issues/show_bug.cgi?id=11392 --- Comment #6 from thelastmamm...@gmail.com 2013-11-01 01:37:47 PDT --- (In reply to comment #5) I can confirm this seg faults on OSX, 64 bits only. how come this kind of obvious bug (not due to any obscure usage condition, just on plain function usage) can go through the autotester unnoticed ? is that due to https://github.com/D-Programming-Language/phobos/pull/1657 ? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11409] New: Array element-wise comparison
http://d.puremagic.com/issues/show_bug.cgi?id=11409
Summary: Array element-wise comparison
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: daniel...@bigpond.com
--- Comment #0 from daniel...@bigpond.com 2013-11-01 02:37:19 PDT ---
void main() {
auto a = [0, 2, 0];
auto b = [1, 1, 1];
// add 2 to ALL elements in C
auto c = a.dup;
c[] += 2;
assert(c == [2, 4, 2]);
// add ALL elements in B to D
auto d = a.dup;
d[] += b[];
assert(d == [1, 3, 1]);
// checks ALL elements in A are less than B
assert(!(a b)); // Error ...
}
As is shown above, there is an inconsistency in how array element-wise
comparisons are handled in D.
The logical conclusion (IMHO) after using the array vector operations that
mutated all elements in the lhs, is that the operation would check that the
comparison was true for (again) **ALL** elements of the arrays.
Instead, it appears to only check for the first element for which the predicate
holds true, and then stops.
This is really weird, especially when the following holds:
assert([2, 0, 0] [1, 1, 1]);
assert([0, 2, 0] [1, 1, 1]);
assert([0, 0, 2] [1, 1, 1]);
I couldn't find any relevant documentation on how this was supposed to work, so
these are just best guesses support with data.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11409] Array element-wise comparison
http://d.puremagic.com/issues/show_bug.cgi?id=11409
Iain Buclaw ibuc...@ubuntu.com changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||ibuc...@ubuntu.com
Resolution||INVALID
--- Comment #1 from Iain Buclaw ibuc...@ubuntu.com 2013-11-01 03:32:37 PDT ---
Your assumption is not quite right. This is the loop comparisons goes off:
for (size_t u = 0; u len; u++)
{
int result = s1[u] - s2[u];
if (result)
return result;
}
And in you examples:
---
Code: assert([2, 0, 0] [1, 1, 1]);
---
Generates: assert(compare(s1, s2) 0);
---
Returns: result = 2 - 1; = return 1
---
Code: assert([0, 2, 0] [1, 1, 1]);
---
Generates: assert(compare(s1, s2) 0);
---
Returns: result = 0 - 1; = return -1;
---
Code: assert([0, 0, 2] [1, 1, 1]);
---
Generates: assert(compare(s1, s2) 0);
---
Returns: result = 0 - 1; = return -1;
My advise to you would be to compare a *SORTED* array.
Marking as invalid because this is working as expected.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11409] Array element-wise comparison
http://d.puremagic.com/issues/show_bug.cgi?id=11409
--- Comment #2 from daniel...@bigpond.com 2013-11-01 03:44:39 PDT ---
(In reply to comment #1)
Your assumption is not quite right. This is the loop comparisons goes off:
for (size_t u = 0; u len; u++)
{
int result = s1[u] - s2[u];
if (result)
return result;
}
And in you examples:
---
Code: assert([2, 0, 0] [1, 1, 1]);
---
Generates: assert(compare(s1, s2) 0);
---
Returns: result = 2 - 1; = return 1
---
Code: assert([0, 2, 0] [1, 1, 1]);
---
Generates: assert(compare(s1, s2) 0);
---
Returns: result = 0 - 1; = return -1;
---
Code: assert([0, 0, 2] [1, 1, 1]);
---
Generates: assert(compare(s1, s2) 0);
---
Returns: result = 0 - 1; = return -1;
My advise to you would be to compare a *SORTED* array.
Marking as invalid because this is working as expected.
Why would I want to compare a sorted array?
I want to compare two different arrays?
I see no reason why a built-in comparison would assume the array would be
sorted?
This is working as it is implemented, but I wouldn't say it is working as
expected. Not by a long shot.
Is there any reference for this behaviour?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11409] Array element-wise comparison
http://d.puremagic.com/issues/show_bug.cgi?id=11409
--- Comment #3 from daniel...@bigpond.com 2013-11-01 03:56:03 PDT ---
(In reply to comment #1)
Your assumption is not quite right. This is the loop comparisons goes off:
for (size_t u = 0; u len; u++)
{
int result = s1[u] - s2[u];
if (result)
return result;
}
I understand that is more or less what the loop was going off, and I am saying,
that is inconsistent behaviour.
It also makes no sense as a comparison, because as long as the arrays aren't
equal, it will always only compare the first element!?
What the?
What kind of comparison is that for a set of operations that is on 'arrays',
not sorted data structures.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11392] dirEntries segfaults (fails in 2.064 beta 4, works in 2.063.2)
http://d.puremagic.com/issues/show_bug.cgi?id=11392 --- Comment #7 from monarchdo...@gmail.com 2013-11-01 03:59:42 PDT --- (In reply to comment #6) (In reply to comment #5) I can confirm this seg faults on OSX, 64 bits only. how come this kind of obvious bug (not due to any obscure usage condition, just on plain function usage) can go through the autotester unnoticed ? is that due to https://github.com/D-Programming-Language/phobos/pull/1657 ? Only one way to find out: https://github.com/D-Programming-Language/phobos/pull/1677 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11402] any/all are not documented in std.algorithm header
http://d.puremagic.com/issues/show_bug.cgi?id=11402 monarchdo...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from monarchdo...@gmail.com 2013-11-01 04:07:42 PDT --- This was apparently fixed already, but 5 months ago: https://github.com/D-Programming-Language/phobos/commit/b794fa27edd4cd92f31a39d84ed6027261b85c9b When was the website last updated? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11409] Array element-wise comparison
http://d.puremagic.com/issues/show_bug.cgi?id=11409
--- Comment #4 from Iain Buclaw ibuc...@ubuntu.com 2013-11-01 04:16:51 PDT ---
(In reply to comment #3)
(In reply to comment #1)
Your assumption is not quite right. This is the loop comparisons goes off:
for (size_t u = 0; u len; u++)
{
int result = s1[u] - s2[u];
if (result)
return result;
}
I understand that is more or less what the loop was going off, and I am
saying,
that is inconsistent behaviour.
It also makes no sense as a comparison, because as long as the arrays aren't
equal, it will always only compare the first element!?
What the?
What kind of comparison is that for a set of operations that is on 'arrays',
not sorted data structures.
Take by way of example, how you compare two words. You'd say that betty comes
before hello, thus betty hello is true.
In the same logic, [0,2,0] comes before [1,1,1], thus [0,2,0] [1,1,1].
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11392] dirEntries segfaults (fails in 2.064 beta 4, works in 2.063.2)
http://d.puremagic.com/issues/show_bug.cgi?id=11392 --- Comment #8 from safety0ff.bugz safety0ff.b...@gmail.com 2013-11-01 04:40:09 PDT --- (In reply to comment #7) Only one way to find out: https://github.com/D-Programming-Language/phobos/pull/1677 I just did the same, both test show that it would not have been caught with or without the changes to the test. Anyways, as I stated before, in retrospect, I should have used: auto cwd = getcwd(); chdir(testdir); scope(exit) chdir(cwd); and left the actual tests alone. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11409] Array element-wise comparison
http://d.puremagic.com/issues/show_bug.cgi?id=11409 --- Comment #5 from daniel...@bigpond.com 2013-11-01 06:58:18 PDT --- For others that may find this later. The default comparison is the equivalent to a http://www.cplusplus.com/reference/algorithm/lexicographical_compare/. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11410] New: Support equality operator chaining
http://d.puremagic.com/issues/show_bug.cgi?id=11410
Summary: Support equality operator chaining
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-11-01 07:35:12 PDT ---
This is valid C code:
int main() {
int x = 3;
int y = 4;
int z = 5;
int b = x y z;
return 0;
}
Bug GCC tells us that code doesn't work as expected by a Python programmer:
test.c:5:15: warning: comparisons like 'X=Y=Z' do not have their mathematical
meaning [-Wparentheses]
int b = x y z;
So D disallows that code:
test.d(5): Error: semicolon expected, not ''
test.d(5): Error: found '' instead of statement
- - - - - - - - - - - - - -
GCC accepts this code:
int main() {
int x = 4;
int y = 4;
int z = 4;
int b = x == y == z;
return 0;
}
With a warning:
test.c:5:15: warning: suggest parentheses around comparison in operand of '=='
[-Wparentheses]
int b = x == y == z;
While DMD refuses that code:
test.d(5): Error: semicolon expected, not '=='
test.d(5): Error: found '==' instead of statement
From my experience with D code I know there several situations where the
chained equality is handy:
if (n == foo(n) == bar(n) ...
It avoids code like:
aux = foo(n);
if (n == aux aux == bar(n) ...
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11365] Allow D source file names to have no extension (or an arbitrary extension)
http://d.puremagic.com/issues/show_bug.cgi?id=11365 --- Comment #18 from Leandro Lucarella leandro.lucare...@sociomantic.com 2013-11-01 07:56:44 PDT --- (In reply to comment #16) (In reply to comment #12) For the record, good editors solve the problem easily, like vim or emacs: # vim: syntax=d ts=4 sw=4 sts=4 sr noet # -*- d-mode -*- You call that a solution? Arbitrary tools adding an arbitrary amount of HEADER information they've invented? So then other tools have to be able to interpret these lines too. This doesn't scale. It's not a solution. Just a comment about this, even when is irrelevant to my proposed solution: You only need to add extra information when you depart from the default. Is like D itself. Do you need to write all your code in ASM? No, but when you need it is there. It will be painful and you won't get lots of features, but you can do it. You are a grown up and know what's best for you. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5548] Efficient std.conv.to conversions
http://d.puremagic.com/issues/show_bug.cgi?id=5548
Orvid King blah38...@gmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||blah38...@gmail.com
Resolution|WONTFIX |
--- Comment #3 from Orvid King blah38...@gmail.com 2013-11-01 08:26:19 PDT ---
After a bit of testing, std.format.fomatValue is not a valid alternative to
having std.conv.to provide overloads that accept an output buffer. The reason
for this is simple, the following code is 3x slower than simply using
to!string(int):
auto toStr = benchmark!(() {
import std.format;
import std.range : Appender;
auto ret = Appender!string();
auto fmt = FormatSpec!char(%s);
ret.reserve(4096);
for (auto i = 0; i ObjectCount * 11; i++)
{
ret.formatValue(i, fmt);
ret.clear();
}
})(1);
writefln(Took %s ms (%s) to serialize 100k SimpleObjects with an average
payload of %s bytes (%s)., res[0].msecs, toStr[0].msecs,
cast(real)totalPayload / ObjectCount, totalPayload);
In my tests where ObjectCount was 100k, it takes 400ms for to!string(int) to
create all the strings, and 1100ms for formatValue to do the same.
formattedWrite is even worse, 1500ms. In my current implementation of a dynamic
JSON (de)serializer, more than half of my time is eaten up by converting
integers to strings when performing deserialization. I use a pre-allocated
output range as the destination, so I know I'm not doing any allocations within
my code.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11394] NRVO should work for object field initialization in constructor
http://d.puremagic.com/issues/show_bug.cgi?id=11394 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from Kenji Hara k.hara...@gmail.com 2013-11-01 09:06:04 PDT --- https://github.com/D-Programming-Language/dmd/pull/2592 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11394] NRVO should work for object field initialization in constructor
http://d.puremagic.com/issues/show_bug.cgi?id=11394
--- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-11-01 09:05:53 PDT ---
Sorry the OP code is incorrect, because the make function cannot have strong
purity.
Correct test case is:
debug = NRVO;
debug(NRVO) static void* pa, pb, pc;
static int[3] make(in int x) pure
{
typeof(return) a;
a[0] = x;
a[1] = x + 1;
a[2] = x + 2;
debug(NRVO) pa = cast(void*)a.ptr;
return a;
}
struct Bar
{
immutable int[3] arr;
this(int x)
{
this.arr = make(x);// NRVO should work
debug(NRVO) pb = cast(void*)this.arr.ptr;
}
}
void main()
{
auto b = Bar(5);
debug(NRVO) pc = cast(void*)b.arr.ptr;
debug(NRVO) assert(pa == pb);
debug(NRVO) assert(pb == pc);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11338] std.uri URIerror should be an Exception
http://d.puremagic.com/issues/show_bug.cgi?id=11338 --- Comment #1 from github-bugzi...@puremagic.com 2013-11-01 09:20:07 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/1fd19c2366e3d1f41ddff5adc3d73820faf56ad4 Fix of Issue 11338 - URIerror renamed to URIexception - URIexception class inherits from Exception https://github.com/D-Programming-Language/phobos/commit/fa0627b21854a3d7be461da20632e474d07c4b66 Fix Issue 11338 - Now call the onOutOfMemoryError() function when alloca returns NULL - Fixed the URIexception name to URIException - Added a string constructor for the URIException class - Added more informative messages to some of the errors https://github.com/D-Programming-Language/phobos/commit/74d59dd7db418126f323586bcc9a09ca6b69b69a Fixing Issue 11338 - Additional - Now all thrown URIException have human readable text - throw new OutOfMemoryError(Alloca Failure); // Make code look more consistant https://github.com/D-Programming-Language/phobos/commit/42eec50ffe2f315dfb8caac3b8c110058115b880 Merge pull request #1659 from DannyArends/issue_11338 Fix Issue 11338 - std.uri URIerror should be an Exception -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11411] New: Disallow non pure lazy expressions in pure functions
http://d.puremagic.com/issues/show_bug.cgi?id=11411
Summary: Disallow non pure lazy expressions in pure functions
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2013-11-01
19:38:46 MSK ---
As `lazy` expressions are like a `scope delegate` pure functions should reject
inpure `lazy` expressions just like inpure delegates:
---
void f() { }
void g(lazy void p) pure { p; }
void main()
{ g(f()); } // compiles, should fail
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11412] New: Allow nested pure functions to access outer function variables
http://d.puremagic.com/issues/show_bug.cgi?id=11412
Summary: Allow nested pure functions to access outer function
variables
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2013-11-01
19:57:39 MSK ---
As an outer function is a context for its nested function it should be
accessible for weakly pure functions just like type instance for member
functions:
---
struct S
{
int i;
void f() pure
{
int j;
void g() pure
{
++i; // ok
++j; // currently error, looks inconsistent
}
}
}
---
Also this will allow things like this (usable e.g. for std.conv):
---
struct S
{
void toString(scope void delegate(const(char)[]) pure) pure;
}
string sToStr(S s) pure
{
string res;
s.toString((chars) { res ~= chars; });
return res;
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11390] const(typeof(null)) fails to print correctly
http://d.puremagic.com/issues/show_bug.cgi?id=11390 --- Comment #2 from github-bugzi...@puremagic.com 2013-11-01 10:17:19 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/0c5a439e934b25986823a682ed53a2273494367a Fix bug 11390 https://github.com/D-Programming-Language/phobos/commit/ac9fcce808f1125ad7c6fe3b639c678c09b9e250 Better fix for bug 11390 :p https://github.com/D-Programming-Language/phobos/commit/9741b28af258a6150ba65e9a1dddc5e7513ce1ff Merge pull request #1674 from BioTronic/master Fix bug 11390 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4707] auto ref for foreach loops
http://d.puremagic.com/issues/show_bug.cgi?id=4707 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #4 from Martin Nowak c...@dawg.eu 2013-11-01 12:17:39 PDT --- This is still an interesting proposal. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6652] foreach parameter with number range is always ref
http://d.puremagic.com/issues/show_bug.cgi?id=6652 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||la...@virginia.edu --- Comment #30 from Martin Nowak c...@dawg.eu 2013-11-01 12:16:23 PDT --- *** Issue 2543 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2543] foreach's index behaves differently for every type
http://d.puremagic.com/issues/show_bug.cgi?id=2543 Martin Nowak c...@dawg.eu changed: What|Removed |Added Status|NEW |RESOLVED CC||c...@dawg.eu Resolution||DUPLICATE --- Comment #1 from Martin Nowak c...@dawg.eu 2013-11-01 12:16:23 PDT --- *** This issue has been marked as a duplicate of issue 6652 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11413] New: FreeBSD libphobos2.a not updated in 2.064 betas
http://d.puremagic.com/issues/show_bug.cgi?id=11413 Summary: FreeBSD libphobos2.a not updated in 2.064 betas Product: D Version: D2 Platform: All OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: ga...@mail.ru --- Comment #0 from Ivan Kazmenko ga...@mail.ru 2013-11-01 13:39:15 PDT --- At least in the archives dmd2beta.zip (2.064 first beta) and dmd.2.064.beta.4.zip, the dmd2/freebsd/lib32/libphobos2.a file is the same as in the previous version (2.063.2). This may mean that Phobos will not be updated properly in the 2.064 release for FreeBSD as well. Hence this bugreport. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11414] New: druntime should run debug unittest
http://d.puremagic.com/issues/show_bug.cgi?id=11414 Summary: druntime should run debug unittest Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: c...@dawg.eu --- Comment #0 from Martin Nowak c...@dawg.eu 2013-11-01 15:45:49 PDT --- This requires some bigger refactorings of druntime's makefile. It should be structured more like phobos's makefile and recursively invoke debug and release unittests. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11148] Can't implicitly convert const(BigInt) or immutable(BigInt) to BigInt
http://d.puremagic.com/issues/show_bug.cgi?id=11148 Simen Kjaeraas simen.kja...@gmail.com changed: What|Removed |Added Keywords||pull CC||simen.kja...@gmail.com --- Comment #8 from Simen Kjaeraas simen.kja...@gmail.com 2013-11-01 18:29:34 PDT --- https://github.com/D-Programming-Language/phobos/pull/1679 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11415] New: Assign range to array
http://d.puremagic.com/issues/show_bug.cgi?id=11415 Summary: Assign range to array Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: daniel...@bigpond.com --- Comment #0 from daniel...@bigpond.com 2013-11-01 18:28:20 PDT --- I would have expected the following to work: int[] d = [1,2,3,4,5,6,7]; d[] = d.filter!(x = x 3)[]; Where the rhs could have been assigned to the lhs. Unfortunately this gives the following: Error: cannot implicitly convert expression (f.opSlice()) of type FilterResult!(__lambda2, int[]) to int[] For now, the only idiomatic solution I could find is this roundabout way: auto t = d.filter!(x = x 3).copy(d); d = d[0 .. $ - t.length]; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11415] Assign range to array
http://d.puremagic.com/issues/show_bug.cgi?id=11415 Shammah Chancellor shammah.chancel...@gmail.com changed: What|Removed |Added CC||shammah.chancel...@gmail.co ||m --- Comment #1 from Shammah Chancellor shammah.chancel...@gmail.com 2013-11-01 18:32:58 PDT --- Seconded. If an operator implements opSlice it should behave as expected for a r-value per the Array assignment documentation. This can be converted to a similar foreach() loop that arrays are. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11188] std.math.abs fails for shared, const or immutable BigInt types
http://d.puremagic.com/issues/show_bug.cgi?id=11188 Simen Kjaeraas simen.kja...@gmail.com changed: What|Removed |Added Keywords||pull CC||simen.kja...@gmail.com --- Comment #6 from Simen Kjaeraas simen.kja...@gmail.com 2013-11-01 18:35:01 PDT --- https://github.com/D-Programming-Language/phobos/pull/1679 This pull solves some of the problems in this issue. Shared is more complicated, so will have to wait. It may be that the problems of shared are better fixed elsewhere - pure functions on a type that's implicitly castable to immutable seem like they should be callable with shared parameters, but I might be wrong. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11416] New: Array and slice assignment causes garbage values
http://d.puremagic.com/issues/show_bug.cgi?id=11416
Summary: Array and slice assignment causes garbage values
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: daniel...@bigpond.com
--- Comment #0 from daniel...@bigpond.com 2013-11-01 18:56:54 PDT ---
void main() {
float[3] x = [1,1,1];
float[] y = [4,4,4,4];
float[5] w = x[] + y[]; //ok
writeln(w); // [5, 5, 5, 4, 5.60519e-45]
}
w should be [5, 5, 5, 4, float.init]
Right?
http://dpaste.dzfl.pl/fork/53b6d5b5
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6829] Unsigned rotate standard function in Phobos
http://d.puremagic.com/issues/show_bug.cgi?id=6829 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||l...@luismarques.eu --- Comment #46 from Martin Nowak c...@dawg.eu 2013-11-01 19:06:39 PDT --- *** Issue 1116 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1116] std.intrinsic still missing rotate
http://d.puremagic.com/issues/show_bug.cgi?id=1116 Martin Nowak c...@dawg.eu changed: What|Removed |Added Status|NEW |RESOLVED CC||c...@dawg.eu Resolution||DUPLICATE --- Comment #5 from Martin Nowak c...@dawg.eu 2013-11-01 19:06:39 PDT --- *** This issue has been marked as a duplicate of issue 6829 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11417] New: rotate with immediate not recognized by optimizer
http://d.puremagic.com/issues/show_bug.cgi?id=11417
Summary: rotate with immediate not recognized by optimizer
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: c...@dawg.eu
--- Comment #0 from Martin Nowak c...@dawg.eu 2013-11-01 19:16:22 PDT ---
cat bug.d CODE
uint rol(uint n)(in uint x)
{
return x n | x 32 - n;
}
uint ror(uint n)(in uint x)
{
return x n | x 32 - n;
}
alias rol8 = rol!8;
alias ror8 = ror!8;
CODE
dmd -O -release -inline bug
obj2asm bug.o
shlEAX,8
shrEDI,018h
orEAX,EDI
shrEAX,8
shlEDI,018h
orEAX,EDI
While Issue 6829 which uses an runtime shift works the instruction with an
immediate shift isn't recognized by the compiler.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11226] Problems with typeof(null) and const
http://d.puremagic.com/issues/show_bug.cgi?id=11226 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from Kenji Hara k.hara...@gmail.com 2013-11-01 20:21:19 PDT --- https://github.com/D-Programming-Language/dmd/pull/2703 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11418] New: bit test pattern not inlined core.bitop.bt useless
http://d.puremagic.com/issues/show_bug.cgi?id=11418 Summary: bit test pattern not inlined core.bitop.bt useless Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: c...@dawg.eu --- Comment #0 from Martin Nowak c...@dawg.eu 2013-11-01 21:13:40 PDT --- The core.bitop.bt function is no longer an intrinsic. Instead it's a function whose body the optimizer recognizes as bitop function. That would be OK iff the function was always inlined. The problem is, the function is never inlined due to Issue 10985. This forces me write copy the pattern verbatim into my code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11417] rotate with immediate not recognized by optimizer
http://d.puremagic.com/issues/show_bug.cgi?id=11417 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com Severity|normal |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
