[Issue 3145] std.perf documentation is generated, but there's no link to it from the side index
http://d.puremagic.com/issues/show_bug.cgi?id=3145 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||WONTFIX --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-05-24 23:37:09 PDT --- std.perf is deprecated. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2742] std.stdio assumes console works in utf-8
http://d.puremagic.com/issues/show_bug.cgi?id=2742 --- Comment #10 from Stewart Gordon s...@iname.com 2011-05-25 04:59:10 PDT --- (In reply to comment #9) According to this page http://codesnippets.joyent.com/posts/show/414 you can get and set the codepage via the [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage] key's OEMCP value. Setting the codepage requires a restart though. Not if you do it using chcp on the command line, or (presumably) SetConsoleCP in the Windows API. Also, changing the codepage has other effects, e.g. using ALT+Numpad keys is handled differently (with codepage 1252 you don't have to prepend a zero when using ALT+Numkey apparently). snip I don't have to prepend a zero anyway. It just produces a different character if I do. Traditionally at least, with a 0 it types a character from the ANSI set, and without a 0 it types a character from the OEM set. But as I test it (Win7), it depends on what font the command prompt is set to. - Lucida Console or Consolas - C:\Users\StewartGordonchcp 850 Active code page: 850 C:\Users\StewartGordon£úœ£ '£úœ£' is not recognized as an internal or external command, operable program or batch file. C:\Users\StewartGordonchcp 1252 Active code page: 1252 C:\Users\StewartGordon£úœ£ - Raster Fonts - C:\Users\StewartGordonchcp 850 Active code page: 850 C:\Users\StewartGordon£úo£ '£úo£' is not recognized as an internal or external command, operable program or batch file. C:\Users\StewartGordonchcp 1252 Active code page: 1252 C:\Users\StewartGordonú·£ú -- The sequence of strange characters is Alt+0163, Alt+163, Alt+0156, Alt+156 in each case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2742] std.stdio assumes console works in utf-8
http://d.puremagic.com/issues/show_bug.cgi?id=2742 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #11 from Vladimir Panteleev thecybersha...@gmail.com 2011-05-25 05:02:20 PDT --- Since no one seems to have mentioned this here yet: http://msdn.microsoft.com/en-us/library/ms686036(v=vs.85).aspx -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4295] IID_IUnknown symbol undefined in phobos.lib
http://d.puremagic.com/issues/show_bug.cgi?id=4295 --- Comment #7 from Trass3r mrmoc...@gmx.de 2011-05-25 06:29:08 PDT --- It isn't fixed, std.windows.iunknown is still present. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2335] Message on unicode error
http://d.puremagic.com/issues/show_bug.cgi?id=2335 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-05-25 07:19:39 PDT --- Fixing my closing mistakes. Sorry for the noise. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6056] New: Type lookup problem in string mixins
http://d.puremagic.com/issues/show_bug.cgi?id=6056
Summary: Type lookup problem in string mixins
Product: D
Version: D2
Platform: Other
OS/Version: Mac OS X
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: c...@klickverbot.at
--- Comment #0 from klickverbot c...@klickverbot.at 2011-05-25 09:22:04 PDT
---
Apologies for the vague title, but I'm not quite sure how to appropriately
describe this issue. Consider the following snippet:
---
import std.traits : ParameterTypeTuple;
interface Bar {
int a(int t);
int b(short t);
}
template Foo(string name) {
mixin(
alias ParameterTypeTuple!(Bar. ~ name ~ )[0] Type;\n ~
alias const(Type)* PointerType;
);
mixin(alias const(ParameterTypeTuple!(Bar. ~ name ~ )[0])*
PointerTypeDirect;);
pragma(msg, name, : , Type, , , PointerType, , , PointerTypeDirect);
}
// The second instantiation always prints the same for PointerTypeDirect as
// the first, try swapping them.
alias Foo!(a) FooA;
alias Foo!(b) FooB;
---
DMD from current Git master (ef2b5aa) prints:
---
a: int, const(int)*, int*
b: short, const(short)*, int*
---
Note that PointerTypeDirect is the same type on the second instantiation, while
the version using an intermediary alias works fine. If the two instantiation
lines are swapped, the output is as follows:
---
b: short, const(short)*, short*
a: int, const(int)*, short*
---
The two step version still works fine, whereas the direct version now has
short* in both cases.
You might have noticed that it would be enough to use a string mixin expression
for the ParameterTypeTuple argument instead of mixing in the whole declaration.
If one replaces Foo by this:
---
template Foo(string name) {
alias const(ParameterTypeTuple!(mixin(Bar. ~ name))[0])* PointerTypeDirect;
pragma(msg, name, : , PointerTypeDirect);
}
---
The output is:
---
a: int*
b: short*
---
The const seems to be missing, but otherwise it seems to work – but if the
original line is added in again:
---
template Foo(string name) {
mixin(alias const(ParameterTypeTuple!(Bar. ~ name ~ )[0])* NotRelevant;);
alias const(ParameterTypeTuple!(mixin(Bar. ~ name))[0])* PointerTypeDirect;
pragma(msg, name, : , PointerTypeDirect);
}
---
The output again becomes:
---
a: int*
b: int*
---
If the original code is changed to declare a normal, non-const pointer, it
works as expected as well:
---
template Foo(string name) {
mixin(alias ParameterTypeTuple!(Bar. ~ name ~ )[0]* PointerTypeDirect;);
pragma(msg, name, : , PointerTypeDirect);
}
---
Correctly results in:
---
a: int*
b: short*
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6056] Type lookup problem in string mixins
http://d.puremagic.com/issues/show_bug.cgi?id=6056
kenn...@gmail.com changed:
What|Removed |Added
CC||kenn...@gmail.com
Platform|Other |x86
OS/Version|Mac OS X|All
--- Comment #1 from kenn...@gmail.com 2011-05-25 11:38:45 PDT ---
Reduced test case:
--
template Bug6056() {
mixin(alias const typeof('c') A; alias const typeof(0) B;);
static assert(is(B == int));
}
alias Bug6056!() Bug6056_dummy;
--
x.d(4): Error: static assert (is(char == int)) is false
x.d(7):instantiated from here: Bug6056!()
--
Alternative test case:
--
template Bug6056b() {
mixin(alias const(typeof('c')*) A; alias const(typeof(0)*) B;);
static assert(is(B == const(int*)));
}
alias Bug6056b!() Bug6056b_dummy;
--
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6056] Type lookup problem in string mixins
http://d.puremagic.com/issues/show_bug.cgi?id=6056
--- Comment #2 from kenn...@gmail.com 2011-05-25 11:39:51 PDT ---
Actually that 'template' is not needed.
mixin(alias const(typeof('c')*) A; alias const(typeof(0)*) B;);
static assert(is(B == const(int*)));
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5317] Assertion is not work in a function called by std.concurrency.spawn
http://d.puremagic.com/issues/show_bug.cgi?id=5317 --- Comment #4 from Sean Kelly s...@invisibleduck.org 2011-05-25 16:29:53 PDT --- When the assertion isn't propagated, what's likely happening is that the thread instance is being discarded because the thread is complete. If the app terminates quickly enough then it beats the spawned thread to termination and thread_joinAll() finds the Error waiting to be re-thrown. At the moment, D has fairly lax rules for propagating exceptions that caused a thread to terminate--it's assumed that if you care about the result of a thread you'll call join(), which will always re-throw the exception unless told not to. But if you don't retain a reference to the thread then its result will remain unknown. The exception to this rule is that a spawned thread will receive word that its owner has terminated, and linked threads will notify one another on termination. I could retain these uncaught exceptions and re-throw them to the main thread on app termination, but I don't see much utility in it. If something horrible happens in a thread then the user either wants to shutdown the entire app immediately for fear of memory corruption (which increasingly unlikely with thread-local static data), or he wants specific interested parties to be notified that the thread terminated unexpectedly (which is handled by linking via std.concurrency), or he doesn't care. Perhaps I should add a hook so the user can supply an uncaughtExceptionHandler? I'd avoided doing this in the past because it would interact weirdly with the current behavior of join() re-throwing uncaught exceptions, but it's an option. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
