Re: lambdas and function literals in classes
On 07/09/13 12:50, John Colvin wrote:
JS asked about this in the main group, but here is more appropriate and I'm
quite interested myself.
Function/delegate *literals* in aggregates are not accepted by the compiler.
It's just a compiler issue; iirc the frontend recently got a bit smarter about
figuring out what is/isn't a delegate, so maybe at some point the restriction
will be gone. Right now, everybody runs into this, and has to work around by
inventing dummy names for the literals. Ie
struct S {
enum a = { return 42; }();
}
does not work.You have to use
struct S {
static ugh() { return 42; };
enum a = ugh();
}
which of course litters the namespace and obfuscates what's happening.
The
enum a = { return 42; }();
line will work outside of the struct/class/whatever.
For this to work the compiler would have figure out that the function
literal really is just a function literal, ie does not access any field
of the struct and does not need any context pointer. Which is possible,
but does not currently happen. It's also not possible to /explicitly/
specify - there's no way to mark *just* the literal as static.
struct S {
static enum a = { return 42; }();
}
Works - but that's not enough:
struct S {
static mixin({ return int a;; }()); // oops, 'a' is static.
}
IIRC this issue is already reported somewhere in bugzilla.
artur
Re: lambdas and function literals in classes
On Tuesday, 9 July 2013 at 12:32:55 UTC, Artur Skawina wrote: On 07/09/13 12:50, John Colvin wrote: JS asked about this in the main group, but here is more appropriate and I'm quite interested myself. Function/delegate *literals* in aggregates are not accepted by the compiler. Probably calling those function/delegate literals at aggregate _scope_ is a more precise thing to do. Because current error message sounds rather ambiguous.
Re: lambdas and function literals in classes
On 07/09/2013 02:32 PM, Artur Skawina wrote: IIRC this issue is already reported somewhere in bugzilla. http://d.puremagic.com/issues/show_bug.cgi?id=7653
Re: C standard libraries
On Tuesday, 2 July 2013 at 12:52:49 UTC, bearophile wrote: Adam D. Ruppe: The older std.c is kept around just for compatibility with the old names before the move, at least as far as I know. Maybe they haven't fully deprecated it though because there's other reasons I don't know about, since it has been many years now since the move. In D/Phobos/Dmd there is a ton of stuff that's supposed to be obsolete, that should not be used, that is deprecated, etc. I presume Walter thinks that the problems caused from keeping it and from unwanted usages of it, is smaller than the breaking troubles caused by removing it. I am person that likes to keeps things ordered and clean, so I prefer to remove old stuff after a suitable deprecation period, instead of keeping it around almost forever (like floating point special comparison operators). Bye, bearophile I agree. Also the website needs updating to deter people from using std.c: http://dlang.org/phobos/#stdio
Re: GitHub behind proxy servers among other questions
On Tuesday, 9 July 2013 at 08:55:29 UTC, monarch_dodra wrote: On Monday, 8 July 2013 at 19:20:46 UTC, John Colvin wrote: I don't see how it is problematic? The firewall doesn't allow a particular type of connection, so you cache the result somewhere else and then access it via something that is allowed. It's the same as downloading the zip file from github, only you're doing the zipping yourself, then using scp to do the download instead of http. Is it common to have ssh connections banned in the IT policy but *not* blocked by the firewall? I'm just saying that maybe the firwall is blocking that protocol on purpose? Github can very easily be seen as File Sharing and/or Online Storage. The sole act of downloading/uploading anything on there is possible violations of policy. You could download viruses, or be stealing your company's code to publish it online. Even if you *can* download the zip via http, it doesn't mean you are actually allowed to. If your company's firewall doesn't block a porn site, does that means its OK to surf it? Now, most companies wouldn't really care that much about it, if you connect every now and then, no one will care. Worst case scenario, you'll get a reminder not to download/upload crap on internet. But, if you start doing all this via ssh, or other alternative routes, then you are *activelly* bypassing protections, and in particular, doing something you *know* you shouldn't be doing. That's a more serious offense. Now, do what you want. I'm just saying before going it and deploying such tools to download the files on git, please make sure you aren't violating your company's policies. I do not encourage anyone to bypass network security protections and I do encourage letting your conscious be your guide on this topic. The issue is that it is just more complicating than I think it should be to download libraries and such. Authors of helper libraries and other D related code should take their queue from dlang.org and actually have binaries that users can download and just use without the need to compile before they can use the wares. It is not a firewall issue or anything like that. It was just GIT not supporting modern proxy authorization schemes. Problem resolved but it could have been avoided all together for those of us that are not to the point of contributing to these projects and are just trying to get their feet wet without drowning first. On another note I was able to successfully compile the DWT lib and I was able to compile the snippet example programs to test DWT. I did notice for those that are interested DWT exe's are over 2MB which is really what I was wanted to find out. I will redirect DWT questions to the appropriate forum. The workaround for GIT via proxy is just not as pretty as I would have liked it. However as I posted previously I found a suitable workaround for the issue. No other discussion is needed for this issue.
Re: Simple test suite for std.random
On 07/05/2013 04:16 PM, Joseph Rushton Wakeling wrote: To this we can add: http://d.puremagic.com/issues/show_bug.cgi?id=10550 At least 2 of the Xorshift generators (32 and 160) depart strongly from uniformity in their output. Because the others appear OK, my guess would be that the fault lies either in the initialization of the seeds_ variable inside XorshiftEngine, or (more likely) in the parts of popFront related to the 32- and 160-bit engines. A fix for this landed earlier today, although we probably need to follow up with some appropriate experts to have the solution rigorously reviewed. Thanks to Masahiro Nakagawa and monarch_dodra who made sure the fix made it to Phobos in double quick time :-)
std.algorithm.filter cannot call gc_malloc at compile time
enum tokenRange = matchStr.split(,) .map!(a = a.findSplit(`=`) .array .map!strip) .filter!!a.empty; This won't compile. The error message is: .../core/memory.d(337): Error: gc_malloc cannot be interpreted at compile time, because it has no available source code Is there some way I can work around this?
Re: std.algorithm.filter cannot call gc_malloc at compile time
On Tuesday, 9 July 2013 at 16:44:29 UTC, John Colvin wrote: Fixed in git master. array was not ctfe-able until a few months back. What compiler version/release are you using? I'm using DPaste, but setting the compiler to use the latest from GIT fixed it. Thanks!
Re: std.algorithm.filter cannot call gc_malloc at compile time
On Tuesday, 9 July 2013 at 16:48:20 UTC, John Colvin wrote: which dpaste is that? http://dpaste.dzfl.pl/ gives me the error even using dmd 2.X Git Actually, yes, it still does not work. I forgot that I had changed enum to auto to get it working. My bad.
Re: std.algorithm.filter cannot call gc_malloc at compile time
On Tuesday, 9 July 2013 at 16:47:02 UTC, Meta wrote: On Tuesday, 9 July 2013 at 16:44:29 UTC, John Colvin wrote: Fixed in git master. array was not ctfe-able until a few months back. What compiler version/release are you using? I'm using DPaste, but setting the compiler to use the latest from GIT fixed it. Thanks! which dpaste is that? http://dpaste.dzfl.pl/ gives me the error even using dmd 2.X Git
Re: Assert failures in threads
On Jul 1, 2013, at 4:04 AM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: I've noticed that when an assert fails inside a thread, no error message is printed and the program/thread just hangs. Is there any way to ensure that an assertion failure inside a thread does output a message? For the purposes of my current needs, it's fine if it also brings down the whole program, just so long as I'm alerted to what generated the error. If you join the thread, any unhanded exception will be rethrown in the joining thread by default. Or you can have a catch(Throwable) in the top level of your thread function. I thought about adding an overridable unhandled exception filter (I think Java has something like this) but that seemed like it would interact strangely with the join behavior.
Re: std.algorithm.filter cannot call gc_malloc at compile time
On Tuesday, 9 July 2013 at 16:48:20 UTC, John Colvin wrote: On Tuesday, 9 July 2013 at 16:47:02 UTC, Meta wrote: On Tuesday, 9 July 2013 at 16:44:29 UTC, John Colvin wrote: Fixed in git master. array was not ctfe-able until a few months back. What compiler version/release are you using? I'm using DPaste, but setting the compiler to use the latest from GIT fixed it. Thanks! which dpaste is that? http://dpaste.dzfl.pl/ gives me the error even using dmd 2.X Git It's working for me on my local head. FYI, the problem was fixed about a month ago: https://github.com/D-Programming-Language/phobos/pull/1305 It doesn't work in my 2.063.2 though. dmd 2.X Git is probably not refreshed very often...?
Re: std.algorithm.filter cannot call gc_malloc at compile time
On Tuesday, 9 July 2013 at 19:06:36 UTC, monarch_dodra wrote: On Tuesday, 9 July 2013 at 16:48:20 UTC, John Colvin wrote: On Tuesday, 9 July 2013 at 16:47:02 UTC, Meta wrote: On Tuesday, 9 July 2013 at 16:44:29 UTC, John Colvin wrote: Fixed in git master. array was not ctfe-able until a few months back. What compiler version/release are you using? I'm using DPaste, but setting the compiler to use the latest from GIT fixed it. Thanks! which dpaste is that? http://dpaste.dzfl.pl/ gives me the error even using dmd 2.X Git It's working for me on my local head. FYI, the problem was fixed about a month ago: https://github.com/D-Programming-Language/phobos/pull/1305 It doesn't work in my 2.063.2 though. dmd 2.X Git is probably not refreshed very often...? Apparently not. It's a pity, it's not like building dmd etc. is something that takes a long time or needs any manual intervention.
Re: Beginner problem: casting in opCmp override
On Mon, Jul 08, 2013 at 05:09:14PM -0700, Jonathan M Davis wrote:
On Monday, July 08, 2013 16:58:03 H. S. Teoh wrote:
On Mon, Jul 08, 2013 at 04:48:05PM -0700, Jonathan M Davis wrote:
On Monday, July 08, 2013 16:38:16 H. S. Teoh wrote:
[...]
Basically, when you write x==y, the compiler looks for opEquals
and opCmp. If opEquals is found, then it's rewritten as
x.opEquals(y); otherwise, if opCmp is found, it's rewritten as
x.opCmp(y)==0. If neither are found, then the compiler generates
a default implementation of opEquals, which basically does a
bitwise comparison of x and y.
Actually, what it's supposed to do isn't necessarily a bitwise
comparison. It's supposed to do a recursive comparison of all of
the members, where it calls == on each of the members. If a
bitwise comparison will do that, then it may end up as a bitwise
comparison for efficiency reasons, but it's not necessarily a
bitwise comparison. It used to be that it was doing a bitwise
comparison when it wasn't supposed to, but that was fixed fairly
recently (though I don't recall if that fix has been released
yet).
Basically, there's no reason to overload opEquals unless you have
a member which you don't want to compare with == (e.g. pointers).
[...]
Unfortunately, this isn't true for opCmp. If you don't define opCmp,
the typeinfo of the struct will have a compare function that
basically does bitwise comparison. Proof:
struct S {
int[] data;
}
void main() {
auto s = S([1,2,3]);
auto t = S([1,2,3]);
auto u = S([1,2,4]);
assert(s == t);
assert(s != u);
assert(typeid(s).compare(s, t) == 0); // FAILS
assert(typeid(s).compare(s, u) != 0);
}
Should this be filed as a DMD bug?
Yes. opCmp's behavior should definitely match opEquals' behavior.
[...]
http://d.puremagic.com/issues/show_bug.cgi?id=10588
T
--
MSDOS = MicroSoft's Denial Of Service
Re: Assert failures in threads
On Tuesday, July 09, 2013 10:39:59 Sean Kelly wrote: If you join the thread, any unhanded exception will be rethrown in the joining thread by default. What about threads which were spawned by std.concurrency? IIRC, those are never explicitly joined. Is catching Throwable in the spawned thread required in order to get stuff like AssertErrors printed? - Jonathan M Davis
Re: Assert failures in threads
On Jul 9, 2013, at 3:33 PM, Jonathan M Davis jmdavisp...@gmx.com wrote: On Tuesday, July 09, 2013 10:39:59 Sean Kelly wrote: If you join the thread, any unhanded exception will be rethrown in the joining thread by default. What about threads which were spawned by std.concurrency? IIRC, those are never explicitly joined. Is catching Throwable in the spawned thread required in order to get stuff like AssertErrors printed? Unfortunately yes. I suppose std.concurency could do something fancy to propagate uncaught exceptions the thread's owner as a message (similar to the LinkTerminated message) but it doesn't do so now.
[Issue 9097] Value range propagation to disable some array bound tests
http://d.puremagic.com/issues/show_bug.cgi?id=9097 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9097] Value range propagation to disable some array bound tests
http://d.puremagic.com/issues/show_bug.cgi?id=9097 --- Comment #2 from github-bugzi...@puremagic.com 2013-07-08 22:57:46 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/186acf411866c1950b215f58fd57c08e903f588c Fix Issue 9097 - Value range propagation to disable some array bound tests Do not emit bounds check code if the index is statically known to be within bounds https://github.com/D-Programming-Language/dmd/commit/fe9bb4aaad8b9aa132bd86d7a1168be12fec5981 Merge pull request #1493 from yebblies/issue9097 Fix Issue 9097 - Value range propagation to disable some array bound tests -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10573] Weird linking problem with associative array cast [DMD 2.63]
http://d.puremagic.com/issues/show_bug.cgi?id=10573
--- Comment #3 from Daniel Kozak kozz...@gmail.com 2013-07-08 23:20:16 PDT ---
(In reply to comment #2)
Btw, I'd be very careful using casts on hashes like that, there's no runtime
checking when you cast hashes, even if the key or value is a base class which
is casted to a derived class. For example:
-
class A { }
class B : A { void call() { } }
void main()
{
A[int] a;
a[1] = new A();
B[int] b = cast(B[int])a; // unsafe, no exceptions thrown
b[1].call(); // crash
}
-
Yes, I realize I can avoid this kind of cast in my case, so now the code is
more safe and compilable.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10580] spawnShell/pipeShell changes some environment variables (incl. PATH)
http://d.puremagic.com/issues/show_bug.cgi?id=10580 --- Comment #2 from thelastmamm...@gmail.com 2013-07-08 23:43:37 PDT --- furthermore the output of command env is returned in a different order -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10580] spawnShell/pipeShell changes some environment variables (incl. PATH)
http://d.puremagic.com/issues/show_bug.cgi?id=10580 --- Comment #1 from thelastmamm...@gmail.com 2013-07-08 23:41:59 PDT --- it also changes these (at least on OSX): MANPATH SHLVL ( this one is normal though) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10380] Wrong code using associative array as key type in associative array
http://d.puremagic.com/issues/show_bug.cgi?id=10380 --- Comment #4 from Denis Shelomovskij verylonglogin@gmail.com 2013-07-09 10:49:34 MSD --- (In reply to comment #3) Do you have any failing unittest for this bug? I can't seem to reproduce the problem in git HEAD. It's hard to create unittests as the problem will appear iff we will have to unequal AA-s with equal hashes. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10481] out of memory error
http://d.puremagic.com/issues/show_bug.cgi?id=10481 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10481] out of memory error
http://d.puremagic.com/issues/show_bug.cgi?id=10481 --- Comment #3 from github-bugzi...@puremagic.com 2013-07-09 00:40:49 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/1365ebdc3c9176229513d2a5a30bf20c2dc50e37 fix Issue 10481 - out of memory error https://github.com/D-Programming-Language/dmd/commit/5378ea8f2c19abe7643418bf15401e617d6a1bcd Merge pull request #2323 from 9rnsr/fix10481 [REG2.063] Issue 10481 - out of memory error -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10579] regression 062=063: Cannot interpret TypeInfo at compile time
http://d.puremagic.com/issues/show_bug.cgi?id=10579 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||CTFE, ice, pull --- Comment #1 from Don clugd...@yahoo.com.au 2013-07-09 00:45:14 PDT --- https://github.com/D-Programming-Language/dmd/pull/2325 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10550] Xorshift32 and Xorshift160 do not generate uniformly-distributed random numbers
http://d.puremagic.com/issues/show_bug.cgi?id=10550 --- Comment #15 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net 2013-07-09 01:04:56 PDT --- Masahiro -- thanks so much for your fast attention to this. :-) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10579] regression 062=063: Cannot interpret TypeInfo at compile time
http://d.puremagic.com/issues/show_bug.cgi?id=10579 --- Comment #2 from github-bugzi...@puremagic.com 2013-07-09 01:10:06 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/7f50fb0014544d5174f767d5a57c78cd747bded9 Fix bug 10579 CTFE ICE with TypeInfo Applies to any attempt to call a virtual function on a static variable. https://github.com/D-Programming-Language/dmd/commit/25db2c93a5fc94899cc9632e64aa3348f7ee2442 Bug 10579 CTFE ICE second case ICE when resolving a virtual function call in CTFE. Same ICE as bug 10579. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10579] regression 062=063: Cannot interpret TypeInfo at compile time
http://d.puremagic.com/issues/show_bug.cgi?id=10579 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9982] ICE on CTFE for pointer dereference
http://d.puremagic.com/issues/show_bug.cgi?id=9982
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Version|D2 |D1 D2
Severity|normal |critical
--- Comment #2 from Don clugd...@yahoo.com.au 2013-07-09 02:00:27 PDT ---
This is a critical bug. Assignment via a pointer to a struct member does not
work!
struct Bug9982 {
int a;
}
int test9982()
{
Bug9982 x;
int *q = x.a;
*q = 99;
assert(x.a == 99);
return 1;
}
static assert(test9982());
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10567] Typeinfo.compare has unreasonable signature requirements on opCmp
http://d.puremagic.com/issues/show_bug.cgi?id=10567 --- Comment #5 from github-bugzi...@puremagic.com 2013-07-09 02:47:53 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/607c25a22d8d72f2d7fb5f81c861c7e54534101e Supplemental fix for issue 10567 Add helper function in druntime, same as opEquals case. https://github.com/D-Programming-Language/druntime/commit/d46b4eb096c2246c59a161a1d4e5494b38d784d0 Merge pull request #543 from 9rnsr/fix10567 Supplemental fix for issue 10567 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9097] Value range propagation to disable some array bound tests
http://d.puremagic.com/issues/show_bug.cgi?id=9097 --- Comment #3 from bearophile_h...@eml.cc 2013-07-09 03:15:11 PDT --- In past dmd generated this with dmd -O -inline -release -noboundscheck: __Dmain: sub ESP, 0330h mov ECX, 0C8h push EDI mov EAX, 0338h[ESP] add EAX, 01770h mov 4[ESP], EAX xor EAX, EAX lea EDI, 014h[ESP] rep stosd mov EAX, 4[ESP] mov ECX, 064h xor EDX, EDX div ECX xor EAX, EAX mov dword ptr 014h[EDX*4][ESP], 1 pop EDI add ESP, 0330h ret Now it generates this in both the optimized build and the less optimized build dmd -O -inline (beside removing the array bound tests, it also avoids the div): __Dmain: sub ESP, 0324h mov ECX, 0C8h push EDI mov EAX, 032Ch[ESP] add EAX, 01770h mov 0324h[ESP], EAX xor EAX, EAX lea EDI, 4[ESP] rep stosd mov ECX, 0324h[ESP] mov EAX, ECX mov EDX, 051EB851Fh mul EDX shr EDX, 5 imul EAX, EDX, 064h sub ECX, EAX xor EAX, EAX mov dword ptr 4[ECX*4][ESP], 1 pop EDI add ESP, 0324h ret -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10574] auto ref fails to match when IFTI succeeds (strip to level const)
http://d.puremagic.com/issues/show_bug.cgi?id=10574
--- Comment #4 from monarchdo...@gmail.com 2013-07-09 03:56:35 PDT ---
(In reply to comment #3)
(In reply to comment #2)
Just an educated guess. The problem seems to be that the value is a L-value
so
the signature becomes (ref T[]) which cannot match immutable(int[]).
That's exactly the current compiler's behavior. auto ref always behave as
ref parameter against lvalue argument `i`, then T[] cannot deduce type T
from
immutable(int[]).
More generally, it seems auto ref will never operate a cast on an lvalue *even
if* the parameter is not templatized. This is strange because auto ref *will*
do it for RValues. Here is another (reduced) example that shows it.
//
void foo()(auto ref long a);
void main()
{
int get();
int a;
foo(get()); //Fine, rvalue int is cast to long
foo(a); //Nope!
}
//
main.d(7): Error: template main.foo does not match any function template
declaration. Candidates are:
main.d(1):main.foo()(auto ref long a)
main.d(7): Error: template main.foo()(auto ref long a) cannot deduce template
function from argument types !()(int)
//
I also spotted this (which, IMO, is even more problematic):
//
struct S
{
@property long get();
alias get this;
}
void foo()(auto ref long a);
void main()
{
S s;
foo(S()); //Fine.
foo(s); //Nope!
}
//
This time, it gives the cryptic error:
main.d(14): Error: s.get() is not an lvalue
= But that's strange: foo takes by auto ref... what do I care about lvalue?
Because s is an Lvalue, it would appear the auto ref is primed to take by
ref. It then fails when an actual Rvalue is given.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10577] 2.063 Mixin Regression (works with 2.062)
http://d.puremagic.com/issues/show_bug.cgi?id=10577 --- Comment #3 from github-bugzi...@puremagic.com 2013-07-09 05:58:39 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/51991f94be53375fe66339d46eea343cd8a107a6 fix Issue 10577 - 2.063 Mixin Regression (works with 2.062) https://github.com/D-Programming-Language/dmd/commit/af61ebff5404dd408b1b40ef94e17fb585c1a7b6 Merge pull request #2322 from 9rnsr/fix10577 [REG2.063] Issue 10577 - 2.063 Mixin Regression (works with 2.062) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10380] Wrong code using associative array as key type in associative array
http://d.puremagic.com/issues/show_bug.cgi?id=10380 --- Comment #5 from hst...@quickfur.ath.cx 2013-07-09 06:44:21 PDT --- I have a fix for this, but I need to somehow make a unittest to verify that it actually fixes the problem. Maybe we can somehow craft a unittest using typeid(aa).compare? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10380] Wrong code using associative array as key type in associative array
http://d.puremagic.com/issues/show_bug.cgi?id=10380 --- Comment #7 from hst...@quickfur.ath.cx 2013-07-09 07:58:00 PDT --- I figured out a way to test for broken .compare: make an AA key type that overrides both opEquals and opCmp, and deliberately have wrong implementation for opCmp. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10380] Wrong code using associative array as key type in associative array
http://d.puremagic.com/issues/show_bug.cgi?id=10380 --- Comment #6 from hst...@quickfur.ath.cx 2013-07-09 07:56:57 PDT --- https://github.com/D-Programming-Language/druntime/pull/544 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10581] New: Undefined identifier std.uni.isWhite when passing string lambda to std.algorithm.filter
http://d.puremagic.com/issues/show_bug.cgi?id=10581
Summary: Undefined identifier std.uni.isWhite when passing
string lambda to std.algorithm.filter
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: minor
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: monkeywork...@hotmail.com
--- Comment #0 from monkeywork...@hotmail.com 2013-07-09 08:42:35 PDT ---
import std.algorithm;
import std.uni;
void main()
{
//Compiles
auto x = [ ].filter!(a = a.canFind!(not!isWhite));
///.../std/functional.d(56): Error: undefined identifier isWhite
auto y = [ ].filter!a.canFind!(not!isWhite);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7013] Mutable interface for BigInts
http://d.puremagic.com/issues/show_bug.cgi?id=7013
hst...@quickfur.ath.cx changed:
What|Removed |Added
CC||hst...@quickfur.ath.cx
--- Comment #1 from hst...@quickfur.ath.cx 2013-07-09 08:59:04 PDT ---
In latest git HEAD, the following works:
import std.bigint;
void main() {
BigInt x = 123;
BigInt y = 321;
x += y;
assert(x == 444);
}
Not sure what's happening under the hood, though. Is it making internal
allocations?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7012] Pure vector operations
http://d.puremagic.com/issues/show_bug.cgi?id=7012 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx 2013-07-09 08:55:08 PDT --- On latest git HEAD, dmd gives: test.d(4): Error: Array operation a[] + b[] not implemented So at least the message is more helpful. But it's still not working yet. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7010] Purity of map and filter
http://d.puremagic.com/issues/show_bug.cgi?id=7010 hst...@quickfur.ath.cx changed: What|Removed |Added Status|NEW |RESOLVED CC||hst...@quickfur.ath.cx Resolution||WORKSFORME --- Comment #2 from hst...@quickfur.ath.cx 2013-07-09 09:01:21 PDT --- This appears to have been fixed in git HEAD. -- 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 --- Comment #1 from hst...@quickfur.ath.cx 2013-07-09 09:05:22 PDT --- The implementation should probably go into std.bitmanip or core.bitop. What's the pattern that DMD recognizes for rotate instructions? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10582] New: Programmed and Compiler generated symbols clash.
http://d.puremagic.com/issues/show_bug.cgi?id=10582
Summary: Programmed and Compiler generated symbols clash.
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ibuc...@ubuntu.com
--- Comment #0 from Iain Buclaw ibuc...@ubuntu.com 2013-07-09 09:46:05 PDT ---
This is more of a pathological case, but produces an unexpected error
nonetheless. Ditto for any other type of compiler generated temporary symbol.
struct Bug
{
~this() { }
int opApply(in int delegate(int i) dg) { return 0; }
}
void main()
{
int __sl5;
int __sl6;
foreach (i; Bug()) {} // Error: declaration __sl6 is already defined
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7013] Mutable interface for BigInts
http://d.puremagic.com/issues/show_bug.cgi?id=7013
--- Comment #2 from bearophile_h...@eml.cc 2013-07-09 09:57:35 PDT ---
(In reply to comment #1)
In latest git HEAD, the following works:
import std.bigint;
void main() {
BigInt x = 123;
BigInt y = 321;
x += y;
assert(x == 444);
}
Not sure what's happening under the hood, though. Is it making internal
allocations?
That code works, but it's not about what this enhancement request is about.
When you perform x+=y; the data inside x probably doesn't change.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7012] Pure vector operations
http://d.puremagic.com/issues/show_bug.cgi?id=7012
bearophile_h...@eml.cc changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||WORKSFORME
--- Comment #2 from bearophile_h...@eml.cc 2013-07-09 10:02:30 PDT ---
This compiles:
void main() pure nothrow {
int[3] a = [1, 2, 2];
int[3] b = [10, 20, 20];
int[3] c = void;
c[] = a[] + b[];
}
The error message caused by this line of code is not related to purity:
immutable int[3] c = a[] + b[];
So this is closed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7013] Mutable interface for BigInts
http://d.puremagic.com/issues/show_bug.cgi?id=7013 --- Comment #4 from hst...@quickfur.ath.cx 2013-07-09 10:07:34 PDT --- You're right, I looked at the code for BigInt, every time you do +=, it allocates a new underlying buffer. That's pretty inefficient if you're using these operations in an inner loop. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7013] Mutable interface for BigInts
http://d.puremagic.com/issues/show_bug.cgi?id=7013 --- Comment #3 from bearophile_h...@eml.cc 2013-07-09 09:58:59 PDT --- (In reply to comment #2) When you perform x+=y; the data inside x probably doesn't change. I meant the original x. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10581] Undefined identifier std.uni.isWhite when passing string lambda to std.algorithm.filter
http://d.puremagic.com/issues/show_bug.cgi?id=10581 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||jmdavisp...@gmx.com Resolution||INVALID --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2013-07-09 10:10:22 PDT --- Sorry, but that's not a bug. It's one of the major reasons that the newer lambda syntax was introduced. The string lambda syntax only works with stuff that's imported by std.functional, and there's no reason for std.functional to import std.uni other than making string lambdas work with std.uni, and we obviously can't make that work with everything, because we can't have std.functional importing everything. Also, while I don't particularly like it (as string lambdas are really nice for short stuff), Andrei and Walter seem to be in favor of phasing out string lambdas anyway. But you're really not saving much by using a string lambda here anyway, so in this particular case, I don't think that that's much of a loss. -- 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
--- Comment #2 from bearophile_h...@eml.cc 2013-07-09 10:13:38 PDT ---
(In reply to comment #1)
What's the pattern that DMD recognizes for rotate instructions?
Walter offers this example of recognizable rotation:
void test236() {
uint a;
int shift;
a = 7;
shift = 1;
int r;
r = (a shift) | (a (int.sizeof * 8 - shift));
assert(r == 0x8000_0003);
r = (a shift) | (a (int.sizeof * 8 - shift));
assert(a == 7);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7013] Mutable interface for BigInts
http://d.puremagic.com/issues/show_bug.cgi?id=7013 --- Comment #5 from bearophile_h...@eml.cc 2013-07-09 10:24:39 PDT --- (In reply to comment #4) You're right, I looked at the code for BigInt, every time you do +=, it allocates a new underlying buffer. That's pretty inefficient if you're using these operations in an inner loop. On the other hand I think a mutable integer is not what most people expect, and it can cause some undesired side effects (and bugs). That's why I suggested to introduce a specific syntax that allows you to manage bigints as mutable buffers where max performance is needed, and keep their behavour clean on default. Generally I think it's better to perform tricky optimizations only on explicit request. Some possible alternative syntaxes: x.mutable += y; x.mulAcc(y); x.mutate!+(y); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10583] New: DMD 2.063 dumps core with mixins involving __traits(getProtection, ..
http://d.puremagic.com/issues/show_bug.cgi?id=10583
Summary: DMD 2.063 dumps core with mixins involving
__traits(getProtection, ..
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: pun...@coverify.org
--- Comment #0 from Puneet Goel pun...@coverify.org 2013-07-09 10:21:03 PDT
---
Here is the test code. On compiling I get:
dmd: traits.c:288: virtual Expression* TraitsExp::semantic(Scope*): Assertion
`protName' failed.
Aborted (core dumped)
Also note that if I uncomment line 37 and comment out line 36, dmd compiles the
code smoothly.
/ Test Code starts here
enum sync; // 1
// 2
public template get_sync(size_t I, A...) { // 3
static if(I == A.length) // 4
enum bool get_sync = false;// 5
else static if(is(A[I] == sync)) // 6
enum bool get_sync = true;// 7
else // 8
enum bool get_sync = get_sync!(I+1, A); // 9
} // 10
// 11
template add_sync(T, size_t ITER=0) { // 12
static if(ITER == (__traits(derivedMembers, T).length)) {// 13
enum string add_sync = ; // 14
} else { // 15
enum string mem = __traits(derivedMembers, T)[ITER]; // 16
enum string add_sync = // 17
mixin(add_sync!(get_sync!(0, __traits(getAttributes, // 18
~ mem ~ )), __traits(getProtection,// 19
~ mem ~ ), \ ~ mem ~ \)); ~ add_sync!(T, ITER+1); // 20
}// 21
} // 22
// 23
template add_sync(bool A, string P, string M) {// 24
static if(A) { // 25
enum string add_sync = auto ~ M[1..$] ~// 26
() {synchronized(this) return ~ M ~ ;}; // 27
} else { // 28
enum string add_sync = ; // 29
}// 30
} // 31
// 32
class derived {// 33
mixin(add_sync!(derived)); // 34
@sync private bool _bar; // 35
void frop() {} // 36
// private void frop() {}// 37
} // 38
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8441] mixin containing template functions causes compiler errors
http://d.puremagic.com/issues/show_bug.cgi?id=8441 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #11 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-07-09 10:51:10 PDT --- (In reply to comment #10) (In reply to comment #8) I don't test std.signal2 module, but the two test cases work with my patch. https://github.com/D-Programming-Language/dmd/pull/1660 std.signal2 works too! Thank you! @jfanati...@gmx.at: I've tried your std.signals by compiling with 'dmd -c -o- -unittest signals.d' (the unittest switch is important here), specifically I've tried two commits for signals2: 04c951e34623e9365a3874c89f43eb997a7b376c (dav1d told me you said this might work) 4f7aaba0135bdfebfe54cbd645ca3652b0b0eb7a (git-head) I've tried them both with the current state of Pull 1660, but compilation fails due to those mixin conflicts. Can you verify this? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10550] Xorshift32 and Xorshift160 do not generate uniformly-distributed random numbers
http://d.puremagic.com/issues/show_bug.cgi?id=10550 Joseph Rushton Wakeling joseph.wakel...@webdrake.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #16 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net 2013-07-09 11:16:30 PDT --- I think we can now close the bug, but I will try and follow up with some people expert in RNG design to see if we can confirm the fixes really are correct. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10585] New: Structs in unittest / functions shouldn't have frame pointer unless necessary
http://d.puremagic.com/issues/show_bug.cgi?id=10585
Summary: Structs in unittest / functions shouldn't have frame
pointer unless necessary
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: hst...@quickfur.ath.cx
--- Comment #0 from hst...@quickfur.ath.cx 2013-07-09 11:21:21 PDT ---
CODE:
--snip--
import std.stdio;
void listMembers(T)() {
writefln(Size of %s is %d, T.stringof, T.sizeof);
foreach (field; __traits(allMembers, T)) {
writefln(\t%s, field);
}
}
void main() {
int y=1;
struct S1 {
int x;
}
static struct S2 {
int x;
bool opEquals() { return true; }
}
struct S3 {
int x;
bool opEquals() { return true; }
}
struct S4 {
int x;
bool opEquals() { return y==1; }
}
listMembers!S1();
listMembers!S2();
listMembers!S3();
listMembers!S4();
}
--snip--
OUTPUT:
--snip--
Size of S1 is 4
x
Size of S2 is 4
x
opEquals
Size of S3 is 16
x
opEquals
this
Size of S4 is 16
x
opEquals
this
--snip--
S3 is identical to S2 (except for the 'static' qualifier); DMD should not
insert the frame pointer since it's not needed.
According to TDPL, the frame pointer is only inserted where needed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10584] New: Unhelpful error default constructing nested class
http://d.puremagic.com/issues/show_bug.cgi?id=10584
Summary: Unhelpful error default constructing nested class
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: peter.alexander...@gmail.com
--- Comment #0 from Peter Alexander peter.alexander...@gmail.com 2013-07-09
11:21:07 PDT ---
class A
{
class B {}
B b = new B();
}
Error: 'this' is only defined in non-static member functions, not A.
This error isn't particularly helpful, since I don't explicitly request this.
The error should state that constructing B requires a this reference, which
isn't available for default construction.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10586] New: DMD unable to interpret cascaded template calls at compile time
http://d.puremagic.com/issues/show_bug.cgi?id=10586
Summary: DMD unable to interpret cascaded template calls at
compile time
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: pun...@coverify.org
--- Comment #0 from Puneet Goel pun...@coverify.org 2013-07-09 11:31:58 PDT
---
I am using latest github dmd -- 712c3e256b1198523bb8a5c49e5e08d3f8409855
Here is the minimized code for the regression.
$ dmd -c bvec.d
foo.d(12): Error: Cannot interpret FooSize!N at compile time
foo.d(13):while evaluating SIZE.init
foo.d(13):while looking for match for FooParams!(1LU)
foo.d(9): Error: template instance foo.foo!1 error instantiating
I think the regression got introduced while fixing 10579.
// Regression Code starts here
private template FooParams(size_t SIZE) {
private alias ubyte StoreT;
}
template FooSize(size_t N=1) {
enum size_t FooSize = N;
}
enum foo!1 BIT_0 = foo!1.init;
struct foo(size_t N) {
enum size_t SIZE = FooSize!N;
private alias FooParams!(SIZE).StoreT store_t;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10587] New: __traits(getAttributes) doesn't work on incomplete templated types
http://d.puremagic.com/issues/show_bug.cgi?id=10587
Summary: __traits(getAttributes) doesn't work on incomplete
templated types
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: qas...@gmail.com
--- Comment #0 from QAston qas...@gmail.com 2013-07-09 11:38:30 PDT ---
Minimized case:
enum Attribute;
@Attribute
class MyTemplate(T) {
}
@Attribute
class MyType {
}
pragma(msg, __traits(getAttributes, MyTemplate)); // prints: tuple()
pragma(msg, __traits(getAttributes, MyTemplate!uint)); // prints:
tuple((Attribute))
pragma(msg, __traits(getAttributes, MyType)); // prints: tuple((Attribute))
I think it either result should be the same for non-instantiated type as for
instantiated or pragma(msg, __traits(getAttributes, MyTemplate)) should yeld a
compile time error.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9455] File.isBinaryMode and more
http://d.puremagic.com/issues/show_bug.cgi?id=9455 Kevin L kevin.lamo...@gmail.com changed: What|Removed |Added CC||kevin.lamo...@gmail.com --- Comment #1 from Kevin L kevin.lamo...@gmail.com 2013-07-09 11:38:23 PDT --- (In reply to comment #0) - Add isBinaryMode/isWriteable/isReadable properties to File, and implement them as light wrappers around platform-specific functions that get that information. I vote that there be five new functions: * isReadable(inout(C)[] path) (or perhaps canRead()): for files, a std.stdio.open(..., r) will succeed; for directories, std.file.dirEntries() will succeed. * isWriteable(inout(C)[] path) (or perhaps canWrite()): for files, a std.stdio.open(..., w) will succeed; for directories, creating a new file in the directory will succeed (excluding things like no space on device). Open question if this function should detect write-only media and return false if so. * isExecutable(inout(C)[] path) (or perhaps canExecute()): for files, exec()/fork()/popen()/etc. (and wrappers) will succeed; always false for directories. * isTraversable(inout(C)[] path): always false for files; for directories, a chdir() will succeed OR a file in the directory can be stat()d. (This is the traditional POSIX view of execute bit on a directory.) * std.stdio.File.isBinary(): returns true if the file was opened with rb or wb. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10577] 2.063 Mixin Regression (works with 2.062)
http://d.puremagic.com/issues/show_bug.cgi?id=10577 hst...@quickfur.ath.cx changed: What|Removed |Added Status|NEW |RESOLVED CC||hst...@quickfur.ath.cx Resolution||WORKSFORME --- Comment #4 from hst...@quickfur.ath.cx 2013-07-09 11:44:36 PDT --- Seems to have been fixed by the pull. I can compile the code without errors. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8441] mixin containing template functions causes compiler errors
http://d.puremagic.com/issues/show_bug.cgi?id=8441 --- Comment #12 from jfanati...@gmx.at 2013-07-09 11:57:15 PDT --- I've tried them both with the current state of Pull 1660, but compilation fails due to those mixin conflicts. Can you verify this? HEAD definitely won't work at all. The older commit used to work for me, but pull 1660 changed quite significantly since then. Seeing that there is real use of my implementation I'm shifting it up in my priority list, prepare to see some commits in the next days. I will comment on pull 1660 if I find any issues. Best regards, Robert -- 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 --- Comment #3 from hst...@quickfur.ath.cx 2013-07-09 12:06:57 PDT --- Hmph. That doesn't work. Compiling without -O just makes DMD translate it literally into shl/shr followed by or. Compiling with -O computes the values via CTFE, so I changed the code by making a and shift parameters, but DMD still uses shl/shr followed by or, instead of replacing it with rol/ror, as claimed. So basically, the pattern either isn't there, or isn't working properly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10551] [CTFE] Wrong-code on passing dereferenced array pointer by ref 2
http://d.puremagic.com/issues/show_bug.cgi?id=10551 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2013-07-09 12:16:34 PDT --- https://github.com/D-Programming-Language/dmd/pull/2324 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10552] Cannot apply access specifiers to individual anonymous enum members
http://d.puremagic.com/issues/show_bug.cgi?id=10552 --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2013-07-09 12:20:51 PDT --- Language changes are enhancements, not bug fixes. -- 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 --- Comment #4 from hst...@quickfur.ath.cx 2013-07-09 12:20:16 PDT --- In fact, not even gdc -O3 recognizes this pattern. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10552] Cannot apply access specifiers to individual anonymous enum members
http://d.puremagic.com/issues/show_bug.cgi?id=10552 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: ---
[Issue 10491] Type inference for function arguments with default value
http://d.puremagic.com/issues/show_bug.cgi?id=10491 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #8 from Walter Bright bugzi...@digitalmars.com 2013-07-09 13:17:59 PDT --- While I agree that this would be a nice enhancement, I'm with Kenji in worrying about ever more complex forward reference problems. I don't think it is worth the effort to overcome those problems at the moment, since as Kenji also pointed out, default arguments are not used often. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10588] New: Typeinfo.compare uses bitwise comparison for structs
http://d.puremagic.com/issues/show_bug.cgi?id=10588
Summary: Typeinfo.compare uses bitwise comparison for structs
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: hst...@quickfur.ath.cx
--- Comment #0 from hst...@quickfur.ath.cx 2013-07-09 13:48:31 PDT ---
CODE:
--snip--
struct S {
int[] data;
}
void main() {
auto s = S([1,2,3]);
auto t = S([1,2,3]);
auto u = S([1,2,4]);
assert(s == t);
assert(s != u);
assert(typeid(s).compare(s, t) == 0); // FAILS
assert(typeid(s).compare(s, u) != 0);
}
--snip--
Since S doesn't define opEquals or opCmp, the typeinfo's .compare is just the
default provided by DMD. However, it uses bitwise comparison, whereas == uses
field-wise comparison.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10589] New: GC.malloc(sz, GC.BlkAttr.APPENDABLE) fails after a certain size
http://d.puremagic.com/issues/show_bug.cgi?id=10589
Summary: GC.malloc(sz, GC.BlkAttr.APPENDABLE) fails after a
certain size
Product: D
Version: unspecified
Platform: All
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: monarchdo...@gmail.com
--- Comment #0 from monarchdo...@gmail.com 2013-07-09 13:56:40 PDT ---
As the title explains, after a certain size (2048 for my 32 bit install on an
64 linux), the appendable data cannot be exploited anymore:
//
import std.stdio;
import core.memory;
void main()
{
for ( size_t i = 4 ; i 1_000_000 ; i *= 1.4 )
{
ubyte[] s;
s.reserve(i);
writefln(%6s: s.capacity is %6s, i, s.capacity);
assert(s.capacity = i);
auto p = s.ptr;
auto s2 = p[0 .. 0];
writefln(%6s: s2.capacity is %6s, i, s2.capacity);
assert(s2.capacity = i);
}
for ( size_t i = 4 ; i 1_000_000 ; i *= 1.4 )
{
ubyte* p = cast(ubyte*)GC.malloc(i, GC.BlkAttr.APPENDABLE);
ubyte[] s = p[0 .. 0];
writefln(%6s: s.capacity is %6s, i, s.capacity);
assert(s.capacity + 4 = i); //This ends up failing.
}
}
//
439521: s.capacity is 442351
439521: s2.capacity is 442351
615329: s.capacity is 618479
615329: s2.capacity is 618479
861460: s.capacity is 864239
861460: s2.capacity is 864239
4: p.capacity is 15
5: p.capacity is 15
6: p.capacity is 15
8: p.capacity is 15
...
1443: p.capacity is 2046
2020: p.capacity is 2046
2827: p.capacity is 0
core.exception.AssertError@main(24): Assertion failure
//
I find this strange, because the first test shows that the allocation size
should not be a barrier.
Is the APPENDABLE data miss-placed or something? I can't really make sense of
why there would be a different behaviour between s2 or p ... ?
This is problematic, as malloc(APPENDABLE) is the only way to allocate a
true d slice manually. Without this, functions such as array or appender,
will return arrays that will relocate after the very first append :(
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8441] mixin containing template functions causes compiler errors
http://d.puremagic.com/issues/show_bug.cgi?id=8441 --- Comment #13 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-07-09 15:29:03 PDT --- (In reply to comment #12) I've tried them both with the current state of Pull 1660, but compilation fails due to those mixin conflicts. Can you verify this? HEAD definitely won't work at all. The older commit used to work for me, but pull 1660 changed quite significantly since then. Seeing that there is real use of my implementation I'm shifting it up in my priority list, prepare to see some commits in the next days. I will comment on pull 1660 if I find any issues. Best regards, Robert Btw why are you using mixin templates instead of a struct? I know the current std.signals uses it, but it's broken because people keep running into Issue 5028. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8441] mixin containing template functions causes compiler errors
http://d.puremagic.com/issues/show_bug.cgi?id=8441 --- Comment #14 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-07-09 15:29:34 PDT --- (In reply to comment #13) Issue 5028. Link: http://d.puremagic.com/issues/show_bug.cgi?id=5028 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10590] New: multiple definitions incorrectly allowed
http://d.puremagic.com/issues/show_bug.cgi?id=10590
Summary: multiple definitions incorrectly allowed
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: critical
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: thelastmamm...@gmail.com
--- Comment #0 from thelastmamm...@gmail.com 2013-07-09 20:01:06 PDT ---
main.d:
int fun() {return 1;}
int fun() {return 2;}
void main(){}
dmd -run main.d
this compiles, but shouldn't
(compile error only occurs when referring to fun)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10591] New: Error: only one main allowed doesn't show location of conflicting main symbols
http://d.puremagic.com/issues/show_bug.cgi?id=10591
Summary: Error: only one main allowed doesn't show location of
conflicting main symbols
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: thelastmamm...@gmail.com
--- Comment #0 from thelastmamm...@gmail.com 2013-07-09 20:19:02 PDT ---
---a.d
void main(){}
---
---b.d
void main(){}
---
---main.d
import a,b;
---
rdmd main.d
(or dmd main.d a.d b.d)
=b.d(1): Error: only one main allowed
the error message should show:
b.d(1): Error: only one main allowed (previously defined in a.d(1))
In more complex cases (with auto generated code or mixins etc), it can be hard
to trace down location of such main symbols, so compiler should show that.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10591] Error: only one main allowed doesn't show location of conflicting main symbols
http://d.puremagic.com/issues/show_bug.cgi?id=10591 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-07-09 20:24:22 PDT --- I guess I should have been more persistent about error messages: https://github.com/D-Programming-Language/dmd/pull/1753#discussion_r3403264 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4841] -inline wrecks certain nested structs causing error *** is a nested function and cannot be accessed from ***
http://d.puremagic.com/issues/show_bug.cgi?id=4841 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #18 from Kenji Hara k.hara...@gmail.com 2013-07-09 20:27:33 PDT --- https://github.com/D-Programming-Language/dmd/pull/2329 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10590] multiple definitions incorrectly allowed
http://d.puremagic.com/issues/show_bug.cgi?id=10590 Maxim Fomin ma...@maxim-fomin.ru changed: What|Removed |Added CC||ma...@maxim-fomin.ru --- Comment #1 from Maxim Fomin ma...@maxim-fomin.ru 2013-07-09 21:49:40 PDT --- I am sure this is a dup of some issue but cannot find it right now. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8441] mixin containing template functions causes compiler errors
http://d.puremagic.com/issues/show_bug.cgi?id=8441 --- Comment #15 from jfanati...@gmx.at 2013-07-09 22:43:28 PDT --- Btw why are you using mixin templates instead of a struct? I know the current std.signals uses it, but it's broken because people keep running into Issue 5028. Instead is not quite correct, the mixin is just a wrapper around the FullSignal struct. Reasoning: So only containing object can emit signals. (emit is made private) It is just a convenience wrapper which implements a good default behaviour in just one line of code. (Make emit private) Otherwise you would have to instantiate a FullSignal as private and manually provide methods for accessing the RestrictedSignal for making connections. Not too much work, but a little annoying. You can of course use the struct directly if you want. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
