joining multicast groups with std.socket
I am trying to listen to a multicast group using the std.socket library. I have looked at the documentation but I do not see a way to join a multicast group. The code I have so far is pasted below. I am looking for the IP_ADD_MEMBERSHIP socket option (along the lines of http://www.cs.unc.edu/~jeffay/dirt/FAQ/comp249-001-F99/mcast-socket.html) and can't find within the library. Let's assume I am trying to listen to 225.0.0.37/12345 Can someone help me with a snippet on some d code that will do this? I appreciate the help! Peter auto socket = new UdpSocket(); auto address = new InternetAddress(12345); socket.bind(address); auto multicastAddress = new InternetAddress("225.0.0.37"); /// The below naturally does not work and I can't seem to find // How do I join the multicast address above? byte[256] buffer; int read = socket.receiveFrom(buffer); printf("Received bytes %i", read); return 0;
Re: terminology: "l-value" & "r-value"
Steven Schveighoffer wrote: > please replace done. :-) -manfred
Re: terminology: "l-value" & "r-value"
On Tue, 4 Jan 2011 17:56:53 + (UTC) "Manfred_Nowak" wrote: > > They describe which side of the equation they are on > > arg, no! please replace "equation" by "assignExpression". lol, great! this is one of the reasons why in my dream language, assignment would be denoted by any other sign *but* "=". Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: terminology: "l-value" & "r-value"
On Tue, 04 Jan 2011 12:56:53 -0500, Manfred_Nowak wrote: Steven Schveighoffer wrote: They describe which side of the equation they are on arg, no! please replace "equation" by "assignExpression". please replace arg with argh! ;) But whatever floats your boat. -Steve
Re: Why does the example on page 8 of TDPL work without importing std.algorithm for splitter?
On 4/01/2011 9:26 p.m., Lars T. Kyllingstad wrote: On Mon, 03 Jan 2011 17:18:34 -0600, Ellery Newcomer wrote: If you're importing some other phobos module, I would guess an instance of this bug: http://d.puremagic.com/issues/show_bug.cgi?id=314 On 01/03/2011 10:56 AM, Bryce Watkins wrote: However when I use splitter in my code it works without having imported std.algorithm. That's right. std.string does a public selective import of startsWith() and endsWith() from std.algorithm, and bug 314 causes the whole module to be imported publically. 314 is a huge, gaping hole in the module system. AFAIK, it's a high- priority bug, but also one that is very difficult to fix for some reason. -Lars Thanks now I understand, this also means that the example on page 8 only works because of bug 314, and should this bug ever be fixed then the example code will break. Therefore it really should include an import of std.algorithm explicitly for both clarity and long term reliability. Bryce.
Re: terminology: "l-value" & "r-value"
Steven Schveighoffer wrote: > They describe which side of the equation they are on arg, no! please replace "equation" by "assignExpression". -manfred
Re: terminology: "l-value" & "r-value"
On Tue, 04 Jan 2011 08:55:07 -0500, spir wrote: Hello, I'm bluffed by the 2 terms "l-value" & "r-value" used in C-line language common terminologies. I think I guess what they mean, but I don't understand the need for such absconse idioms. Why not: l-value <-> variable r-value <-> value (or expression) ? I guess (*p) is considered an l-value. Indeed, it's a special way of denoting a variable, matching the special case of a pointer. If correct, this requires slightly extending the notion of variable (and/or of identifier). On the r-value side, I cannot find anything that makes it a distinct concept from the one of value, or of expression. Explanations welcome, thank you, Denis lvalue stands for left value, rvalue stands for right value. They describe which side of the equation they are on: lvalue = rvalue; Why these terms instead of something more natural? Well, I have no idea :) If I were to guess, it would be that no natural term could exactly describe the meaning, and also that using natural terms are subjective. There's no mistaking what lvalue and rvalue mean becausey they are defined by the language itself. I'm sure Walter probably knows the origin, l and r values are really compiler terms, and he's been writing compilers for a long time. -Steve
Re: terminology: "l-value" & "r-value"
On 01/04/2011 02:55 PM, spir wrote: Hello, I'm bluffed by the 2 terms "l-value"& "r-value" used in C-line language common terminologies. I think I guess what they mean, but I don't understand the need for such absconse idioms. Why not: l-value<-> variable r-value<-> value (or expression) ? I guess (*p) is considered an l-value. Indeed, it's a special way of denoting a variable, matching the special case of a pointer. If correct, this requires slightly extending the notion of variable (and/or of identifier). On the r-value side, I cannot find anything that makes it a distinct concept from the one of value, or of expression. Explanations welcome, thank you, Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com rvalue is easier than value-not-bound-to-a-memory-address. lvalue is easier than value-with-memory-address. Both lvalues and rvalues are values, both can be expressions, and lvalues doesn't have to be variables. Perhaps a better terminology could have been chosen, but changing them doesn't provide real benefits, as far as I can tell.
terminology: "l-value" & "r-value"
Hello, I'm bluffed by the 2 terms "l-value" & "r-value" used in C-line language common terminologies. I think I guess what they mean, but I don't understand the need for such absconse idioms. Why not: l-value <-> variable r-value <-> value (or expression) ? I guess (*p) is considered an l-value. Indeed, it's a special way of denoting a variable, matching the special case of a pointer. If correct, this requires slightly extending the notion of variable (and/or of identifier). On the r-value side, I cannot find anything that makes it a distinct concept from the one of value, or of expression. Explanations welcome, thank you, Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: Asian characters are not printed propely in console
On Tue, 04 Jan 2011 11:47:32 +0200, Jun wrote: Should I use different type and prefix or suffix similary to C++? Place the following code anywhere at the top level in your program: version(Windows) { import std.c.windows.windows : SetConsoleCP, SetConsoleOutputCP; static this() { SetConsoleCP(65001); SetConsoleOutputCP(65001); } } This code should really be in the standard library, I think. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Asian characters are not printed propely in console
I'm sorry for posting in the wrong place. I attached screenshot of my code and the result. As you can see, Korean letters get changed after compilation. This problem doesn't happen with user input(from readln() method). Should I use different type and prefix or suffix similary to C++? begin 644 캡처.PNG MB5!.1PT*&@h-24...@```5<```$."`8]L%0G`7-21T(`KLX< MZ01G04U!``"QCPO\804)<$A9[7UMLQS'>=w...@?\u&_8%VIQ';)Y41.`1=TE56.R^6J5-W*AS"L4$DE m...@w+kw+a;6%3M!0[BBQ&8E"T"5XL+DA)M&S:`(&+2QN*\$H"%"D2?`5`$NKT MTS//S#,]W=/=\[([NWM0M86[.ST]/:=/GS[]=$_/1.$?$``"0``(]([`I/<< MD2$0``)`...@hb"M(``2``!`8``&(ZP"@(d...@``2`0"MQG6\K-9T!O&8$YFI[ M,E&3I0'EO_Y\>z+k[rh...@`@0$1:"6N`Y:G<]:SJ5+SSKGX,YA-MQ/RUP+7 m...@n^_h#0hnl@U6]5FS'PJFJ%-T)1^U\*F39$Y/M<*QVE)[$CT MZ/M,Y&&^6P:*T\ES&7$^1M>693%BRF7(K\_G;R?VK&D"^-Y]SK5Q_XNI(k...@z/JSS>;)6=VO5,G`S M0*`C`DGBRMN4G9<5+M#QGWI8`^+: MLXKO5MRM%M.FD787<:5>P<1) MBT_=N7G%51>TY@;)R2:%!19S?:>X4ED=-G^^+3N,#6d5...@t`,""Q=7.PPP M+G&U77+=N0TKKHNY/L2UAY:#+(!``(&%BZL]S)=.D_ZVQ5<;IUI8(.1U5A>!A8EK98F5/=1?7?Q0S_I+*7+.VO*#?43MDL.]O70&^<,I-[%U0W4N&]#VAKPW+CZ^K^!J'-KLUF M,L5FX#.]WX.XAKVW@&.''.]FWCF10L?+C6OP&&U*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,H<1L$^A57;)9=K8/$S;))7.N;B4^KO[DVY::K!C>[#KQRQO,: MF^K.8*'-O$/'VU`4YP"!...@x>**S;+]1*GMYVHTSS:#40"`...@86+*s;+#NSG:@E<;0+-YUQU==?%N2J8]5=J9TZ3W7+H ME=NAS;Q#QPTCL=EV5,-$HM5'($EH,G$K0``(C`/\A*NS)]5D*:4CYOVODI-=F^DIS53-_O//FLQ9Y` MXMHDGJ'cbrumvm7fvx?...@k(.V6D'I)"$2+*[FA"3E)_3&N4Q.0OTMW2>)0 M_*[32IY>U>=5\K!O6IO%:7X-2Dygs...@j;C9U-](*/AHK7>3LGW7OC)-LZ'PNX2^Q M9(R;\.5CNOC>^J%BF-%"_IGE]66/,D+B&3KN[Y`DMO4ZF&ER<-V4=:7KNLAP MGM<_I9NJV2S+3XY".`]3SQK\:>WFX%Z7I$5K=]EH<37M7S>V"A=)8'5CY7_4 M^&O''`35L.8Q."@OD`FO$R(AHUNBH$18"-9]7Q)X:FLNET#FNL$#6 MH,O&[$NG%`V/3]4HF<:V67V#NP-J? ms...@9cz\6(NZK_H3.Q.4CI;_\C#-^K8<*W`[2^LQY%SE<0BOG:E\[_[XP<8VMGP;!G.EA MCNP\*4Q0C;=6cyop4...@k``m+(?!%J)JYD<<;A4UZ2,Y*Z<+'$.C7,Q*8[I M:T3%7>5PDBZ8Q^6H8?'$!_TL)ZQHPF-;*W\9&K"'C-GDB8S=\F17&==U3WY1 MU;C[BI&'G*`T'4YU0I%",@L35]/?E1.*L?53 MT48KK#"E"2NAMI7)+'NRD]L3EF/UHRS(1;425...@4#+i5@1.2\LR<)CKCW? MF7_"T7\A+,7JN1(V.#N(ZX"5OZR'"+K(J9_== M?P]0-F0)!(``$%A9!)+$]>67E7)]2&s...@``2``!$h$hf61!!3b"NH``2`` M!.(0F#SQQ!/*]Y%90%SC`$4J(`...@``ax'6N)+A><7WFHOKLY"GUV,;@`$``"JXT`GM!: m[?i#z8$...@i`l:YVBL#7&7%XZ\CK4$4"p...@`@5$B`'$=9;6...@4$``"*PZ`DGB mvk2gz...@?(#`2``!/I$(%I<^[ph\eh2`...@_,V9=`G<0_K>N=VFRQQ#A!8 m...@kfm:L8K>BSW9=MQ=+I`N<=W6="#Q#`FG[YW;zx...@l(M$``XMH"M'&? M(MRE<9...@241]3e7$lym^z"=9X0`CQLDE`X(#(X`Q'5PB!=Y`8X!S762EXEHKBL!&BNMI#]MBVE9<4>&0&","&RDN#95Q&rz[1tq...@b6qg<9V?TH;S2O62-[ZF3GWF,YF@ MYD+VW1=%$G*IL>(JEWY(!;?#`B9VF\=BY?^NN&RH?+JH\^W#SB+&8HMT0&!5 m...@9<9U-,T)!#M3\EC=T3D/"5KK(4BP;G:46D6GN.ME]TO\5K;+3>"9^ M7.+*U][>WB[<[40/UWVAS]G4(4*Y>!E!)7']S"^K2\*XFD`J":#,-#4LP'DT mk0kp...@^72y@^[UBC;:a_5m6*y]55...@d$<@161EQI]GOJ<&7S[6EUZ*S% M1`JNMDHUI]3D+)NE%)\:4c^z...@ake"g...@=<15X\W"9QRJ M$;6YVK;%38MI:$C>2EP]SM;E/IO$M=(_^,I*[LXIKCV1KBGFZKJ$<;\B-*`[ MF2ZQ$ZXV:'$U27DGEHGI5B!L`!-Y%',%:L* M(BL(R<:*P&J)JQF:L_AI!UO\3?#2]WR"2_Q?BJ_[>&U8SS%;DT=]PJF86"NN MP6F:\Y>3::9,XCJN,$8O[LXEC*E,-,[5[CAEDO>#'N)98VZ M-#;+CH()B38#`8BK5<]];)8=19TVFV%'9;s...@l>x...@x])C0V#EQ+7R;+_> MN&7*6PX66P*6&Z\4S_.+;0G#YU?W)XC:+)NO31O)\)x$q=...@vqds?#-anq MT"8Jvm...@jou9[ge.0w_1j/\K*&[Z8M\#J_.66CO9CL/9...@l M>VSM&^59(@(K):[V;E/f3...@3nv&Y1.-'B^KHC6FV7G`EMNRI*)*EVSOL=) MR\VPC?")S:_M[0#GK)PYHRB]_(D$5GZW]QZP-WHA`9;XDMA>%6RE]!6!Q6;9 M2VS+N/3($...@i<:WO?.7:M4K\5A-;>^>JP/FRLD*;9=-Q%AIRK;FB.L6U[6;8 MMEA2^:1...@nmywe2*n36\q\+u+r_7j[@#)>]GQ:V0-"<4!`C8"*R:N5O%)Q!K> M1!",GSK.]Y_C>.N!+;Z#BZMCD^M"7+6*VEL#VDXUY%QM=I"S+?#5^7O>&9;: MK""n...@a_2hbl%+b:K_#RNR)ZMA7U`BD,T3@>-^6=7[E&BF;9:38YR'G,PR>3A>;AB3IHF'V"P[O97BC)5$8*7$-1KAB/=H M1>5&8I,VP*TND M$MZ!-:9;QV;98ZH-E&5...@!-9*7`?&"MD#`2``!*(1...@+a&0X6$0``(`(%X!""N m...@a)1```D`@&H%H<76]WT[^IJ>6]47Q`0;@`...@`#a`'DL3UY9?_A7)]2&1! M*!`*'``'P(&2`Q!7N&UTC.``.#``!R"N`X"*WAL.#AP`!Y+%]?B!I_1:TO^A MCHL0`<("(!+$!!P`!ZH<2!97BKF2P!XX7L9?(:YH6&A8X``XT(.X/O/X5R"N M""<@3@<@`,-'&CE7"&N<"EP*>``.-#,@4)*#H<^_>/?711Q_A`PS``7``'@0f+z0?_]] M]=Y[[ZE7?.[>O8L/,``'P`%PH`4')B2H)*)OO_VV>NNMM]2;;[ZIWGCC MC>)sy\x=a0\p``?`...@c0,3$M3;MV^KFS=OJFO7KJD?_>A'ZH<__*&Z4M___O>+S_>^ M][W*=WD,?Y]K.0^O;.GK?UDN*K_$0>(S M!/ZKDB?A0&652S?E\LV^ZG:(?%(XVB6MW7XF)*J4(=U4"EE=A.3ULEP!3!QZ M5D/^C6N[J\[;_-;$+9N',=^;>.TZ9K<-L\XU150YK:^W=_7T+"5...@w'@1<#4?V MW"X7T55<0^NH9:/R-4PIKFU%EI8:LBB[!%;RW"6PXZG%84MB=\)29%WBRIU4 MBKARY]9&4.4YRQ97[I29.Y,VPLJ]>LQPRG:OPU(!N:X-">#/UQ&*DI/$!B&*K+6/<9([Q-P_VVPIEJ0)DWK9VK M/6R2\2F?P"+V.KQ0MKF"ry6x...@iq(;+B".A(0UQL6Z&E5,;#8FWB?3A.*N MA(EK/J$-YJMXCASEV'%Z6V!3XNRR?F-BH5W2M!'8I8JK[.%=PBI[>Q;85237 MNI;9%5>30[\VHFH3TD7JID82G&o...@$([/B:8VA6.':)C(^,J>(: MT\!B'6VLN')^LH':QJ%IPG9\M=IOB7SB*L,#30XVID[[2M.WN,;R7Z9K%->7 M_^&\VIGO)GW.G#VG_N$?SYME+'(8!??:+]&'R"VT>B!F2\J4GCXT1(MI:#%N M*#6-7(xeev3yef5mtbj8im...@?;-C04XD;H>`H/8].F""QAT2BN?_5__J_Z M^_-[^G/)\]E3+U_(/M_YFW/J.W^]:S[_\QO?4C_^\8^+^)3=VR/V.H0T=L_3 MM_;5%W]UA0MBBKA4#;!CLQ?_=T5^='$)A)->: M>3M4$*K7$"]BCJ=R,90^15R#88'Y[HOJ/NWQ>C_^0
Re: Why does the example on page 8 of TDPL work without importing std.algorithm for splitter?
On Mon, 03 Jan 2011 17:18:34 -0600, Ellery Newcomer wrote: > If you're importing some other phobos module, I would guess an instance > of this bug: http://d.puremagic.com/issues/show_bug.cgi?id=314 > > On 01/03/2011 10:56 AM, Bryce Watkins wrote: >> However when I use splitter in my code it works without having imported >> std.algorithm. That's right. std.string does a public selective import of startsWith() and endsWith() from std.algorithm, and bug 314 causes the whole module to be imported publically. 314 is a huge, gaping hole in the module system. AFAIK, it's a high- priority bug, but also one that is very difficult to fix for some reason. -Lars