[Issue 190] Cannot forward reference typedef/alias in default value for function parameter
http://d.puremagic.com/issues/show_bug.cgi?id=190 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #9 from Walter Bright bugzi...@digitalmars.com 2011-01-03 00:33:59 PST --- http://www.dsource.org/projects/dmd/changeset/842 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4753] fail_compilation/fail116.d sends dmd into a loop, exhausting memory
http://d.puremagic.com/issues/show_bug.cgi?id=4753 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2011-01-03 00:35:14 PST --- http://www.dsource.org/projects/dmd/changeset/842 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3979] Order-of-compilation and forward reference errors
http://d.puremagic.com/issues/show_bug.cgi?id=3979 Lars T. Kyllingstad bugzi...@kyllingen.net changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #10 from Lars T. Kyllingstad bugzi...@kyllingen.net 2011-01-03 02:58:32 PST --- Fixed again, along with bug 190. Both the original and reduced test cases now compile successfully. http://www.dsource.org/projects/dmd/changeset/842 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5348] Variable Length Arrays
http://d.puremagic.com/issues/show_bug.cgi?id=5348 --- Comment #1 from bearophile_h...@eml.cc 2011-01-03 04:22:18 PST --- Some comments by Dmitry Olshansky: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=125942 As stated in this proposal they are quite useless, e.g. they are easily implemented via mixin with alloca. Plus, what's the benefit in throwing exception on alloca failure, how you suppose the user to handle this stackoverflow exception? I would have expected a better design to provide an optional parameter to fallback to GC or something ( like malloc(...) + scope(exit) free(...); ) and that's indicates a library solution, of course. Some answers to Dmitry Olshansky: As stated in this proposal they are quite useless, e.g. they are easily implemented via mixin with alloca. This is false, a mixin solution can't replace a VLA because: - The compiler knows what a VLA is, so it may copy it automatically (as it does with fixed-sized arrays) if you return a VLA from a function. - vla_array.sizeof gives the correct answer - alloca() is not pure, while a function that uses VLA can be pure. - The VLA syntax is nicer, it doesn't look like hack, this encourages their usage, and it doesn't require imports. And if you need a 2D variable length matrix, you don't need a different mixin, the VLA syntax supports multi dimensional arrays. Plus, what's the benefit in throwing exception on alloca failure, how you suppose the user to handle this stackoverflow exception? The proposal says that an error too is OK: When a VLA array is allocated the D compiler tests that there is enough free stack left, and otherwise throws a runtime exception/error (like stack overflow). I would have expected a better design to provide an optional parameter to fallback to GC or something ( like malloc(...) + scope(exit) free(...); ) and that's indicates a library solution, of course. This is a possibility to keep in mind. But it makes the VLA implementation a bit more complex: - in the current proposal the VLA is represented by just a length. If you add a fall-back mechanism then you need to keep a pointer too on the stack. - If you return a VLA the code has to copy the data contents only if the VLA is allocated on the stack. - This semantics is different from the C99 one. So people that know C99 need to read about this difference and understand it, and C99 code ported to D probably needs to keep in account the difference. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5402] New: Invalid free() when throwing non-Throwable
http://d.puremagic.com/issues/show_bug.cgi?id=5402
Summary: Invalid free() when throwing non-Throwable
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Keywords: EH
Severity: normal
Priority: P2
Component: druntime
AssignedTo: s...@invisibleduck.org
ReportedBy: bugzi...@kyllingen.net
--- Comment #0 from Lars T. Kyllingstad bugzi...@kyllingen.net 2011-01-03
05:15:24 PST ---
class Foo { }
void main()
{
throw new Foo;
}
When I run this code on 64-bit Linux, it produces the following error message:
test.Foo
*** glibc detected *** ./test: free(): invalid pointer: 0xf7458014 ***
=== Backtrace: =
/lib32/libc.so.6(+0x6c231)[0xf75c2231]
/lib32/libc.so.6(+0x6dab8)[0xf75c3ab8]
/lib32/libc.so.6(cfree+0x6d)[0xf75c6b9d]
./test(_D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo16DefaultTraceInfo6__dtorMFZv+0xe)[0x80636aa]
./test(rt_finalize+0x5b)[0x8062b3b]
./test(_D2gc3gcx3Gcx11fullcollectMFPvZk+0x4a4)[0x8061e18]
./test(_D2gc3gcx3Gcx16fullcollectshellMFZk+0x26)[0x8061966]
./test(_D2gc3gcx2GC18fullCollectNoStackMFZv+0x29)[0x8060b61]
./test(gc_term+0x10)[0x805f320]
./test(_D2rt6dmain24mainUiPPaZi6runAllMFZv+0x59)[0x805d1bd]
./test(_D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv+0x24)[0x805d0ac]
./test(main+0x94)[0x805d054]
/lib32/libc.so.6(__libc_start_main+0xe6)[0xf756cbd6]
./test[0x805a991]
=== Memory map:
08048000-0806e000 r-xp 00:15 4199206
/home/lars/tmp/test
0806e000-0806f000 r-xp 00025000 00:15 4199206
/home/lars/tmp/test
0806f000-08072000 rwxp 00026000 00:15 4199206
/home/lars/tmp/test
095b9000-095da000 rwxp 00:00 0 [heap]
f730-f7321000 rwxp 00:00 0
f7321000-f740 ---p 00:00 0
f7436000-f7453000 r-xp 08:01 1059286
/usr/lib32/libgcc_s.so.1
f7453000-f7454000 r-xp 0001c000 08:01 1059286
/usr/lib32/libgcc_s.so.1
f7454000-f7455000 rwxp 0001d000 08:01 1059286
/usr/lib32/libgcc_s.so.1
f7455000-f7556000 rwxp 00:00 0
f7556000-f76a9000 r-xp 08:01 5898307
/lib32/libc-2.11.1.so
f76a9000-f76aa000 ---p 00153000 08:01 5898307
/lib32/libc-2.11.1.so
f76aa000-f76ac000 r-xp 00153000 08:01 5898307
/lib32/libc-2.11.1.so
f76ac000-f76ad000 rwxp 00155000 08:01 5898307
/lib32/libc-2.11.1.so
f76ad000-f76b1000 rwxp 00:00 0
f76b1000-f76d5000 r-xp 08:01 5898281
/lib32/libm-2.11.1.so
f76d5000-f76d6000 r-xp 00023000 08:01 5898281
/lib32/libm-2.11.1.so
f76d6000-f76d7000 rwxp 00024000 08:01 5898281
/lib32/libm-2.11.1.so
f76d7000-f76ec000 r-xp 08:01 5898303
/lib32/libpthread-2.11.1.so
f76ec000-f76ed000 r-xp 00014000 08:01 5898303
/lib32/libpthread-2.11.1.so
f76ed000-f76ee000 rwxp 00015000 08:01 5898303
/lib32/libpthread-2.11.1.so
f76ee000-f76f rwxp 00:00 0
f770d000-f770f000 rwxp 00:00 0
f770f000-f771 r-xp 00:00 0 [vdso]
f771-f772c000 r-xp 08:01 5898290
/lib32/ld-2.11.1.so
f772c000-f772d000 r-xp 0001b000 08:01 5898290
/lib32/ld-2.11.1.so
f772d000-f772e000 rwxp 0001c000 08:01 5898290
/lib32/ld-2.11.1.so
ff922000-ff937000 rwxp 00:00 0
[stack]
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5348] Variable Length Arrays
http://d.puremagic.com/issues/show_bug.cgi?id=5348 Dmitry Olshansky dmitry.o...@gmail.com changed: What|Removed |Added CC||dmitry.o...@gmail.com --- Comment #2 from Dmitry Olshansky dmitry.o...@gmail.com 2011-01-03 05:18:26 PST --- As stated in this proposal they are quite useless, e.g. they are easily implemented via mixin with alloca. This is false, a mixin solution can't replace a VLA because: - The compiler knows what a VLA is, so it may copy it automatically (as it does with fixed-sized arrays) if you return a VLA from a function. Introducing more magic then it's worth - one thing I really dislike about this proposal. It doesn't solve anything at all, yet uglifies language. How would function signature look like for function returning VLA? How it then interacts with other array types? Is supposed to be a slice of stack? I guess, no. But with alloca that's all : Foo* ptr = cast(Foo*)alloca(len * Foo.sizeof); Foo[] arr = ptr[0 .. len];//that's all, last time I asked Steven, I got the answer that you can even append to it (which would reallocate on first append) Making it mixin is little extra cost for an *unsafe* feature as it is. - vla_array.sizeof gives the correct answer Small benefit since you now beforehand the size you passed to it, and can create slice out of of it. Plus, what semnatics do you propouse for VLA's on return - value type? How it fits the rest of language? - alloca() is not pure, while a function that uses VLA can be pure. ..but as defined VLAs subtly destroing nothrow property, and in general are leaky abstraction. - The VLA syntax is nicer, it doesn't look like hack, this encourages their usage, and it doesn't require imports. And if you need a 2D variable length matrix, you don't need a different mixin, the VLA syntax supports multi dimensional arrays. I might be wrong but matrices are usaully either small and fixed sized, or big arbitrarily sized and require allocation anyways. IMO every special case language feature should do something importantly useful to prove worthy. Plus, what's the benefit in throwing exception on alloca failure, how you suppose the user to handle this stackoverflow exception? The proposal says that an error too is OK: When a VLA array is allocated the D compiler tests that there is enough free stack left, and otherwise throws a runtime exception/error (like stack overflow). I don't care what proposal *stated* is OK, I care for the user of this feature, would he/she like exception he/she can't *handle* in any sensible way or some other default mechanism? I'm not seeing VLA as much safer/better then alloca in this regard (in the latter you at least have options if you are the author of this piece of code). I would have expected a better design to provide an optional parameter to fallback to GC or something ( like malloc(...) + scope(exit) free(...); ) and that's indicates a library solution, of course. This is a possibility to keep in mind. But it makes the VLA implementation a bit more complex: Again, this just shows how VLAs as stated are not getting anything good. Library solution can be complex and have options, built-in on the contrary should be clear and lightweight. Slicing the result of alloca + some fallback on failure path is OK (at least it has clear semantics, and explicit). - in the current proposal the VLA is represented by just a length. If you add a fall-back mechanism then you need to keep a pointer too on the stack. It's not _too_ but _instead_ of reserving stack space :) - If you return a VLA the code has to copy the data contents only if the VLA is allocated on the stack. And I yet have to see how function's return type would be defined as VLA. What's makes me sad is there is not a single thing about actually defining anything e.g. semantics of copying, interaction with the rest of language. It's all more about kind cool to have that, something like that, you know... - This semantics is different from the C99 one. So people that know C99 need to read about this difference and understand it, and C99 code ported to D probably needs to keep in account the difference. We should ask C99 folks if there are lots of VLAs used at all. Sorry for being too critical, but at very least the proposal needs a lot of refinement on actual implementation. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5379] std.array.replace fails on char[]s
http://d.puremagic.com/issues/show_bug.cgi?id=5379 Lars T. Kyllingstad bugzi...@kyllingen.net changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@kyllingen.net Resolution||WONTFIX --- Comment #1 from Lars T. Kyllingstad bugzi...@kyllingen.net 2011-01-03 05:55:54 PST --- The thing is, char[] is assumed to be UTF-8 encoded, which means that one array element doesn't necessarily correspond to one symbol (or, more precisely, one code point may be composed of several code units). That's why (from a range point of view) the element type of char[] is dchar, which is UTF-32 encoded, or decoded in the sense that one element is one symbol. Here's an example to prove the point: char[] foo = �ngstr�m; replace(foo, 0, 1, a); If this were allowed, foo would not contain angstr�m as one may expect, it would contain garbage. This is because the first character, �, spans two array elements. You have two options: 1. If you want to use std.array.replace() like this with character arrays, you should use dchar[]. 2. Use std.string.replace(), which works with strings but always allocates. I am closing this as WONTFIX. There are several people who disagree with dchar being the range element type of char[], however, so feel free to reopen as an enhancement request if you wish. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5206] stat_t is not the same as struct stat
http://d.puremagic.com/issues/show_bug.cgi?id=5206 --- Comment #3 from Iain Buclaw ibuc...@ubuntu.com 2011-01-03 06:47:56 PST --- Created an attachment (id=859) patch for 5206 Patch against my tree. Updates stat_t for version(linux), adds definition of __WORDSIZE (needs review, probably better to define it on a per-architecture basis), and removes all except the alias to fstat64 in std.file. Can someone pick this up and clean/apply? :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5403] New: foreach requires front to be a function in a range
http://d.puremagic.com/issues/show_bug.cgi?id=5403
Summary: foreach requires front to be a function in a range
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: schvei...@yahoo.com
--- Comment #0 from Steven Schveighoffer schvei...@yahoo.com 2011-01-03
07:25:54 PST ---
This is a valid range:
import std.range;
struct S
{
int front;
bool empty;
void popFront() {empty = true;}
}
static assert(isInputRange!S); // compiles
But this fails:
void main()
{
S s;
foreach(int i; s) { }
}
fails with the following error:
Error: no property 'opApply' for type 'S'
Error: opApply() function for S must return an int
Change front to:
@property int front() {return 0;}
and it compiles. Clearly empty is not required to be a function, and there is
no mention of any function requirements in the spec, it's just stated that they
must be properties.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5401] std.socket updates and boost license
http://d.puremagic.com/issues/show_bug.cgi?id=5401 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added CC||and...@metalanguage.com --- Comment #1 from Andrei Alexandrescu and...@metalanguage.com 2011-01-03 08:52:27 PST --- Thanks, Chris! Since you went through the trouble of doing the actual work, any chance you could pass it through a formal review process modeled after http://www.boost.org/community/reviews.html? What you mainly have to do is enhance the documentation, generate HTML so people can see it, and act on feedback from people on the digitalmars.d newsgroup. Let us know - thanks! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5401] std.socket updates and boost license
http://d.puremagic.com/issues/show_bug.cgi?id=5401 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2011-01-03 12:17:59 PST --- I also want to specifically thank Chris for changing the license to Boost. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5404] New: .stringof is not documented
http://d.puremagic.com/issues/show_bug.cgi?id=5404 Summary: .stringof is not documented Product: D Version: D2 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: peter.alexander...@gmail.com --- Comment #0 from Peter Alexander peter.alexander...@gmail.com 2011-01-03 12:48:09 PST --- The usage of .stringof on its own (with no preceding object) doesn't appear to be documented anywhere, yet it appears to be legal and returns the name of the module it resides in, e.g. in foo.d, it would evaluate to module foo. This should be added to the language spec. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5404] .stringof is not documented
http://d.puremagic.com/issues/show_bug.cgi?id=5404 --- Comment #1 from Peter Alexander peter.alexander...@gmail.com 2011-01-03 12:50:18 PST --- Also, if we are in module foo.bar, it returns module bar. Is this correct behaviour? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5404] .stringof is not documented
http://d.puremagic.com/issues/show_bug.cgi?id=5404 --- Comment #2 from Peter Alexander peter.alexander...@gmail.com 2011-01-03 13:02:17 PST --- Finally, is there any reason that the return value is prefixed with module? 1. I can't imagine any use for it. 2. If people needed it, it would be trivial to add (module ~ .stringof) 3. If they don't want it, it's a little trickier (splitter(.stringof)[1], or ugly .stringof[7..$]) I would recommend that in module foo, .stringof == foo. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5405] New: Remove linesep from std.path
http://d.puremagic.com/issues/show_bug.cgi?id=5405 Summary: Remove linesep from std.path Product: D Version: D2 Platform: Other OS/Version: All Status: NEW Severity: trivial Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: jesse.k.phillip...@gmail.com --- Comment #0 from Jesse Phillips jesse.k.phillip...@gmail.com 2011-01-03 13:13:11 PST --- Line separation is not related to paths and can already be found in std.string as newline. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Asian characters are not printed propely in console
This is my code.
1.///
import std.stdio;
import std.process;
void main(string[] args)
{
writeln(#23433;#23527;);
system(pause);
}
2.
import std.stdio;
import std.process;
void main(string[] args)
{
writeln(#50504;#45397;);
system(pause);
}
Results are...
1.///
#33509;#46119;?
#44228;#49549;#54616;#47140;#47732; #50500;#47924; #53412;#45208;
#45572;#47476;#49901;#49884;#50724;...
2./
?#45896;#45086;
#44228;#49549;#54616;#47140;#47732; #50500;#47924; #53412;#45208;
#45572;#47476;#49901;#49884;#50724;...
The attached file is screenshot of test 2.
(string values typed by user did not caused problem)
Please confirm this problem and let me know whether this is the problem of
dmd.
begin 644 ??.PNG
MB5!.1PT*@h-24...@```5```$.`8]L%0G`7-21T(`KLX
MZ01G04U!``QCPO\804)$A9P``#L,```[#`=OJ0``#$^241!
M5'A[7UMLQS'=w...@?\u_8%VIQ';)Y41.`1=TE56.R^6J5-W*ASL4$DE
m...@w+kw+a;6%3M!0[BBQ8ET5XL+DA)MS:`(+2QN*\$H%D2?`5`$NKT
MTS//S#,]W=/=\[([NWM0M86[.ST]/:=/GS[]=$_/1.$?$``0``(]([`I/
MD2$0``)`...@hbM(``2``!`8``(ZP@(d...@``2`0MQG6\K-9T!O8$YFI[
M,E3I0'EO_Y\z+k[rh...@`@0$1:6N`Y:G]:SJ5+SSKGX,YA-MQ/RUP+7
m...@n^_h#0hnl@!:(9`DKEU6]5FS'PJFJ%-T)1^U\*F39$Y/M*QVE)[$CT
MZ/M,Y^6P:*T\ES7$^1M693%BRF7(K\_G;RJ[4S?R(0IW=4S7E]47
MG/+OXO]*_E::;0Uj...@.?VKD^-Y]SK5Q_XNI(k...@z/JSS;)6=VO5,G`S
M0*`C`DGBRMB8:L9LESC-CDPDI_4EH6(!;'0N_R_...@[':_D2_GHWRK_6+3Y
M=_U=EP7YTKB(T6'AL_VL-[O'D8/A6DQX66-3U[N4G95+M#QGWI8`^+:
MLWA]`U!H%]Q%8*G38_Y9XNK[22+XR2T^3D2XKO5MRM%M.FD787:5P1)
MBT_=N7G%51TY@;)R2:%!19S?:X4ED=-G^^+3N,#6d5...@t`,Q=7.PPP
M+GU77+=N0TKKHNY/L2UAY:#+(!``(%BZL]S)=.D_ZVQ5;IUI8(.1BSSR
M$`*''4)LF.D8:]4E:WUW%PE#0V;b...@dnZJTW6%%93B8?6IVL388JY/HXEJ
M^*,,]...@nu1$sgi_2]zqckm.70g#b.!#8:`22Q)4GJWBRJ)ATHB$]3R31T#X7
M-3GQ1!I%XKFMC\OSG1-C8E)*:IOK^K61;'YMUX18J*:KDSD4'G!,Z!A!Y=!
M=;QR3*?1-UM?CM4DKC(DT??U[9#XQXDW8VOO-MFLRJ=PPA;'$P:`DGB
MVA4ES/MFB?.7R0u...@e`B$U5A!A8EK98F5/=1?7?Q0B``!(`$X%
MB2OP!P)```AL$@(0UTVJ;=PK$``T,`XKHPJ'$A(`...@d!b.lfu3;n...@`
m...@84a`'%=-2X$!```IN$`,1UDVH;]PH$@,#$(x...@qj7`@(`(%-0J5N*S
M[!B*I.^*%9,k...@`!(+`:+02US'?6K==L)walv...@a!1```ohq_q00l%fv
M_S_I+*7+.VO*#?43MDL.]O70^,I-[%U0W4N]#VAKPW+CZ^K^!J'-KLUF
M,L5FX#.]WX.XAKVW@.''.]FWCF10L?+C6OPU*VT/:U4,@25SY]K!9MJNB
MNV^6G0F3$$LC=I[-85CX=(RFW(R\;-K(ZQB)Y9,H$MQM7?E,L%P(8V\PX=
MSU##9MNK)Q,H1L$^A57;)9=K8/$S;))7.N;B4^KO[DVY::K!C[#KQRQO,:
MF^K.8*'-O$/'VU`4YP!...@x**S;+]1*GMYVHTT'B2F]A2'i...@bz\S4P
MXOYQUSS:#40`...@86+*s;+#NSG:@E;0+-YUQU==?%N2J8]5=J9TZ3W7+H
ME=NAS;Q#QPTCL=EV5,-$HM5'($EL5EV[M8VRQ;NU3]ZH5R,VX90W5O=MWT
M]EG*QPXSV!NAX[+L$!H,_'0:.MVQ[]54#=Q%0)*X1N78D`B;93CZ`H+
M=,5\7.=CL^UQU0=*,R0Q-7;)8=$M;J$JDA*QUY`P$@,#PQ/7X6\%5P`
M0``(C`!B.MXZ@(E`0)`8(t...@+bn467b5h``$!@/`A#7\=0%2@($@,`:(0!Q
M7:/*Q*T``2`P'@0...@kn.iY0$`!-4(`XKIE8E;`0)`8#P(0%S'4QH1``
M`FN$`,1UC2H3MP($@,!X$(XCJN4!(@``36`(ZQI5)FX%`!\2``1U/
M7:`D0``(K!$$-UJDSA```N-!`.(zgki`28`...@c!N:u29...@``3
m...@p#$=3qu@9(``2p...@a`7-H,G$K0``(C`!B.MXZ@(E`0)`8(t...@+bn467b
M5H``$!@/`A#7\=0%2@($@,`:(0!Q7:/*Q*T``2`P'@0...@kn.iY0$`!-4(`
MXKIE8E;`0)`8#P(0%S'4QH1```FN$P%+$=;ZMU'061G%;EVXR#:?K.\5
m...@zn]hyv]gt2=5#-lgeb,4W./\A*NS)]5DEA_[/N[HK;-[XU?F^WS7YY
MYUU]24VG+RWO^KCR6BP%'%-07![*:4CYOVODI-=F^DIS53-_O//FLQ9Y`
MXMHDGJ'cbrumvm7fvx?...@k(.V6D'I)$2+*[FA3E)_3N4Q.0OTMW2)0
M_*[32IYU=5\K!O6IO%:7X-2DDCQ)7G?%4GS93K5STO]/MM5%WC?_-U
MBM\H3=V=7M6%S\[Q']Oygs...@j;C9U-](*/AHK73LGW7OC)-LZ'PNX2^Q
M9(R;\.5CNOC^J%BF-%_IGE]66/,D+B3KN[Y`DMO4ZFER-V4=:7KNLAP
MGM_I9NJV2S+3XY.`]3SQK\:WFX%Z7I$5K=]EH37M7SVA=)8'5CY7_4
M^O''ZSED^`35L.8Q.@OD`FO$R(AHUNBH$18-9]7Q)X:FLNET#FNL$#6
MH,O[$NG%`V/3]4J'w?il.r\`dz5^[4^...@$iur73:KB?6[UPLI1C+^J)K
M%WGE8N\*WX3$,W3+ZX1],=)!=,?^R5^HSYX.L1[N^*/ps...@u=urpcek
MIRX;?D-)XLK.AALG-9#*DQJ%E7$E`[+BCL_'K3L\ISQCPP+4F$2#F^0M
MKB*N['!S=TKN)55*^GUS3ECLQ2[x...@kx^=s]g0\1eq#\HF:V67V#NP-J?
ms...@9cz\6(NZK_H3.Q.4CI;_\C#-^K8*W`[2BDRNU.`R=UAUK698.VIQ
MI8:EAXJZG/RO(KPN;GVE5*_5#+9PKHL25ZKCQ3G7R/I)$%:P31.3)(+
m...@q#5119#B4RN!KW18Y5NM8\:]=OKIAI4UB`73%EZ1HV^LQY%SEI$
MAAL3#N+JRL4,/'[J!RYUIT`'3BEO[!$_0BOG:E\[_[XP8VMGP;!G.EA
MCNP\*4Q0C;=6cyop4...@k``m+(?!%J)JYD;A4UZ2,Y*Z+'$.C7,Q*8[I
M:T3%75PDBZ8Q^6H8?'$!_TL)ZQHPF-;*W\9K'C-GDB8S=\F17==U3WY1
MU;CCSW95Q-.TZ/X)YQ^,7B*R[BI'G*`T'4YU0I%,@L35]/?E1.*L?53
MT48KK#E2NAMI7)+'NRD]L3EF/UHRS(1;425...@4#+i5@1.2\LR)CKCW?
MF7_T7\A+,7JN1(V.#N(ZX5OZR'+KDKU4S)77F!\BJZUBGA2I1)/P3*L
M+MS!N54$(*...@!!```d!@`...@k@.`BBR!`!```A!7``(``$@,``T(J9_==
M?P]0-F0)!(``$%A9!)+$]67E7)]2s...@``2``!$h$hf61!!3bNH``2``
M!.(0F#SQQ!/*]Y%90%SC`$4J(`...@``ax'6N)+A7WFHOKLYGUV??-6X6
M8000...@``2!01:5N#[S^#.%L$)0...@``2`0!t!bM8`02``!`8``(ZP@
M(d...@``2`@'-BV#QQ5R/'WA*33Y[L;)R`#%7$`D(``$@@)@k@``0!P!
MA`4a...@7``)`8!,1...@+an8jwcgh$`$!@@5;B^C+6N0Y,;@`$``JXT`GM!:
m[?i#z8$...@i`l:YVBL#77%XZ\CK4$4p...@`@5$B`'$=9;6...@4$``*PZ`DGB
mvk2gz...@?(#`2``!/I$(%I^[ph\eh2`...@_,V9=`G0_KN=VFRQQ#A!8
m...@kfm:L8KBSW9=MQ=+I`N=W6=#Q#`FG[YW;zx...@l(M$``XMHM'?
M(MRE9...@241]3e7$lym^z=9X0`CQLDE`X(#(X`Q'5PB!=Y`8KG6MQM04V
Re: Asian characters are not printed propely in console
On Monday 03 January 2011 19:39:00 Jun wrote:
This is my code.
1.///
import std.stdio;
import std.process;
void main(string[] args)
{
writeln(#23433;#23527;);
system(pause);
}
2.
import std.stdio;
import std.process;
void main(string[] args)
{
writeln(#50504;#45397;);
system(pause);
}
Results are...
1.///
#33509;#46119;?
#44228;#49549;#54616;#47140;#47732; #50500;#47924; #53412;#45208;
#45572;#47476;#49901;#49884;#50724;... 2./
?#45896;#45086;
#44228;#49549;#54616;#47140;#47732; #50500;#47924; #53412;#45208;
#45572;#47476;#49901;#49884;#50724;...
The attached file is screenshot of test 2.
(string values typed by user did not caused problem)
Please confirm this problem and let me know whether this is the problem of
dmd.
Please don't post to the bug list. It's really only meant for messages from
bugzilla. You sign up for it if you want to see all of the bugzilla messages
from when bugs are added or commented on or whatnot. Post on D.learn for
questions about learning D and on D for discussions on the language and its
development. This question should probably go on D.learn.
I'm not all that well versed in how you put unicode in your strings (rather
than
getting strings that have unicode in them from elsewhere - like user input),
but
my guess would be that you're not declaring your strings correctly, so they're
not being treated as unicode. If you repost this on D.learn, odds are that
someone there will know what you're doing wrong or perhaps even confirm that
this
is a dmd bug if that's really what's going on.
- Jonathan M Davis
[Issue 5406] New: [patch] Major regressions in std.algorithm for functions relying on is(typeof(binaryFun!... due to a static assert in binaryFunImpl
http://d.puremagic.com/issues/show_bug.cgi?id=5406
Summary: [patch] Major regressions in std.algorithm for
functions relying on is(typeof(binaryFun!... due to a
static assert in binaryFunImpl
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: patch
Severity: regression
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: sandf...@jhu.edu
--- Comment #0 from Rob Jacques sandf...@jhu.edu 2011-01-03 21:18:21 PST ---
This is a regression between DMD 2.050 and 2.051.
Several routines in std.algorithm rely on template constraints of the form:
is(typeof(binaryFun!... However, since binaryFun triggers a static assert and
stops compilation, there is a logical error here and causes
find(goodbye,bye), etc to not compile. This might be rooted in a change to
how DMD handles is statements / static asserts, but there is a simple patch to
Phobos that seems to work around this issue by adding a template constraint to
binaryFunImpl in std.functional:
template binaryFunImpl(alias fun, string parm1Name, string parm2Name) {
static if (is(typeof(fun) : string)) {
enum testAsExpression = { ElementType1
~parm1Name~; ElementType2
~parm2Name~; return (~fun~);}();
typeof(mixin(testAsExpression))
result(ElementType1, ElementType2)(ElementType1 __a, ElementType2 __b)
if(__traits(compiles, mixin(testAsExpression)))
{
mixin(alias __a ~parm1Name~;);
mixin(alias __b ~parm2Name~;);
mixin(return ( ~ fun ~ ););
}
} else {
alias fun result;
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5407] New: X86_64: Segfault on AA Foreach
http://d.puremagic.com/issues/show_bug.cgi?id=5407 Summary: X86_64: Segfault on AA Foreach Product: D Version: D2 Platform: x86_64 OS/Version: All Status: NEW Severity: major Priority: P2 Component: druntime AssignedTo: s...@invisibleduck.org ReportedBy: ibuc...@ubuntu.com --- Comment #0 from Iain Buclaw ibuc...@ubuntu.com 2011-01-03 21:39:58 PST --- The aligntsize() implementations in aaA.d and object_.d differ, causing a segfault to occur during runtime. Relevant ticket against GDC here: https://bitbucket.org/goshawk/gdc/issue/133/segfault-on-aa-foreach And fix has already been committed, can you please sync this into to druntime? https://bitbucket.org/goshawk/gdc/changeset/aba6c8857d64 Regards -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5407] X86_64: Segfault on AA Foreach
http://d.puremagic.com/issues/show_bug.cgi?id=5407 Brad Roberts bra...@puremagic.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||bra...@puremagic.com AssignedTo|s...@invisibleduck.org |bra...@puremagic.com --- Comment #1 from Brad Roberts bra...@puremagic.com 2011-01-03 21:48:35 PST --- Hrm.. why are there two implementations of the function in the first place? I'll take this bug, but what I'd prefer to see is loosing the one in aaA.d and making the one in object.di/object_.d correct. You didn't happen to try that, did you? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5407] X86_64: Segfault on AA Foreach
http://d.puremagic.com/issues/show_bug.cgi?id=5407 --- Comment #2 from Iain Buclaw ibuc...@ubuntu.com 2011-01-03 21:58:07 PST --- The one on object.d is a member of struct AssociativeArray(Key, Value), the other is an internal helper function. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5407] X86_64: Segfault on AA Foreach
http://d.puremagic.com/issues/show_bug.cgi?id=5407 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #3 from nfx...@gmail.com 2011-01-03 22:05:09 PST --- By the way, I have already demonstrated with a compiler/runtime patch, that you can have an associative array ABI that works on all architectures and doesn't need that messy alignment stuff (how many bugs did that generate in the past, present and future?). Enjoy your bugs, I guess. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5408] New: Calling GC.malloc inside a unittest with a flag of 1 results in an access violation.
http://d.puremagic.com/issues/show_bug.cgi?id=5408
Summary: Calling GC.malloc inside a unittest with a flag of 1
results in an access violation.
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: wrong-code
Severity: blocker
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: sandf...@jhu.edu
--- Comment #0 from Rob Jacques sandf...@jhu.edu 2011-01-03 22:46:08 PST ---
In DMD 2.051 (and probably DMD 2.050 as well), calling GC.malloc with the 'has
interior pointers' flag (i.e., 1) inside a unittest block causes an access
violation error or a program crash.
This is a blocker for non-trivial use of the std.variant and std.json
enhancements I'm working inside of unittests, including their own.
Test case:
import core.memory;
unittest {
GC.malloc(16, 0); // Okay
GC.malloc(16, 1); // object.Error: Access Violation
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5407] X86_64: Segfault on AA Foreach
http://d.puremagic.com/issues/show_bug.cgi?id=5407 Brad Roberts bra...@puremagic.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Brad Roberts bra...@puremagic.com 2011-01-03 22:53:19 PST --- Changes applied in r473. Thanks Iain. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
