HMAC and toHexString
... string key = "blahblahblah"; auto mac = hmac!SHA256(key.representation); string s = ...,t=...u=...,v=...; foreach(w;AliasSeq!(s,t,u,v)) mac.put(w.representation); ubyte[32] s = mac.finish; string sig = toHexString!(LetterCase.lower)(s); writeln(sig); // From what I understand Should print something like 41771e2d0d6c1cf7f442aa8547783ea5b126bfc15a4b354e94d0eaea2ab0fa1a // Actually prints something like x"31 36 39 33 39 32 38 31 62 38 31 62 36 36 62 63 63 34 63 36 36 61 62 32 34 37 64 32 64 34 61 00 78 2A 55 5B FF 7F 00 00 78 2A 55 5B FF 7F 00 00 E0 2A 55 5B FF 7F 00 00 08 2C 55 5B FF 7F 00 00"c Note the nuls and things like FF What am I doing wrong here?
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Tuesday, 17 July 2018 at 16:39:48 UTC, bachmeier wrote: On Tuesday, 17 July 2018 at 15:55:03 UTC, bachmeier wrote: On Tuesday, 17 July 2018 at 06:57:37 UTC, drug wrote: [...] I'm going to create an issue on Github. This is the output I get: [...] I solved that problem but now I have others. dpp is a good thing on paper but maybe not yet in practice. Echoing what Andrei and Walter say all the time, it's not going to get fixed without bug reports...
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Tuesday, 17 July 2018 at 15:55:03 UTC, bachmeier wrote: On Tuesday, 17 July 2018 at 06:57:37 UTC, drug wrote: [...] I'm going to create an issue on Github. This is the output I get: [...] I solved that problem but now I have others. dpp is a good thing on paper but maybe not yet in practice.
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Tuesday, 17 July 2018 at 06:57:37 UTC, drug wrote: I just build it using dub then do something like that(from memory): `d++ some_c_header.h --include-path path/to/other/c/header/files --keep-d-files` and it generates d file for the corresponding c header. Although dpp is intended to be used directly I use it for generating intermediate files. First of all because when I tried to import nuklear.h dpp generated nuklear.d with simple error - due to bug it included diagnostic message of libclang into d file and it was simpler and faster to edit intermediate file manually than wait for bug fixing. I'm going to create an issue on Github. This is the output I get: $ dub build dpp Building package dpp in /home/office/.dub/packages/dpp-0.0.1/dpp/ WARNING: A deprecated branch based version specification is used for the dependency libclang. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead. Performing "debug" build using /usr/bin/dmd for x86_64. libclang ~master: target for configuration "library" is up to date. dpp 0.0.1: building configuration "executable"... .dub/packages/dpp-0.0.1/dpp/source/dpp/runtime/app.d(106,16): Warning: C preprocessor directive #define is not supported .dub/packages/dpp-0.0.1/dpp/source/dpp/cursor/typedef_.d(89,9): Error: @nogc function dpp.cursor.typedef_.isSomeFunction cannot call non-@nogc function clang.Type.pointee .dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(176,8): Error: incompatible types for (type.pointee()) is (null): Type and typeof(null) .dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(177,12): Error: incompatible types for (type.pointee()) !is (null): Type and typeof(null) .dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(184,40): Error: can only * a pointer, not a Type .dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(192,21): Error: can only * a pointer, not a Type .dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(202,22): Error: cannot implicitly convert expression (*ptr).pointee() of type Type to const(Type)* .dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(246,31): Error: can only * a pointer, not a Type /usr/bin/dmd failed with exit code 1.
Re: names not demangled in nm --demangle=dlang
On Tuesday, 17 July 2018 at 15:39:39 UTC, Zheng (Vic) Luo wrote: Hi, I built a simple program with dmd a.d and tried to observe symbols with nm --demangle=dlang ./a. However, I can observe that only part of the symbols (e.g., std.stdio.File.size()) are demangled, while others remain in their original name (e.g., _D3std5stdio4File8opAssignMFNfSQBdQBcQzZv). Is this a bug of nm? It probably doesn't support the new back-referencing yet. https://dlang.org/changelog/2.077.0.html#mangleBackref https://dlang.org/blog/2017/12/20/ds-newfangled-name-mangling/ Moreover, what is the suggested way to demangle symbol names in dlang? ddemangle (it should be part of your distribution or release archive)
names not demangled in nm --demangle=dlang
Hi, I built a simple program with dmd a.d and tried to observe symbols with nm --demangle=dlang ./a. However, I can observe that only part of the symbols (e.g., std.stdio.File.size()) are demangled, while others remain in their original name (e.g., _D3std5stdio4File8opAssignMFNfSQBdQBcQzZv). Is this a bug of nm? Moreover, what is the suggested way to demangle symbol names in dlang? Thanks
Re: Check whether a range is empty
On Tuesday, 17 July 2018 at 13:59:45 UTC, Gary Willoughby wrote:
I thought every range at the lowest level has an `empty`
property. So, in this case, it would be:
if (PFResutl.toRange.empty)
{
writeln("Empty");
}
Yeah, but it seems, that PFResutl is a range of ranges, and the
OP has the case, where both of the contained ranges are empty.
However, this does not correspond to empty of the governing range.
So
[[], []].empty is false
whereas
[[], []].joiner.empty is true.
Re: CJK problem when using console outputs
On Monday, 16 July 2018 at 18:16:45 UTC, ag0aep6g wrote:
On 07/16/2018 11:30 AM, zhani wrote:
[...]
Try this:
import std.stdio: writeln;
import std.exception: enforce;
import core.sys.windows.windows: CP_UTF8, SetConsoleOutputCP;
void main()
{
SetConsoleOutputCP(CP_UTF8).enforce;
writeln("Allo");
writeln("こんにちは");
writeln("你好");
writeln("안녕하세요");
}
thank you for reply. :-)
i removed a code that my cheated and solved it.
i still, don't know why dmd didn't support CJK by default when
write a console.
Dlang must be a world-wise for everyone.
anyway, thank you so much.
Re: Check whether a range is empty
On Friday, 13 July 2018 at 18:37:35 UTC, vino.B wrote:
Hi All,
How do i check whether a range is empty. eg.
(!PFResutl.toRange).empty. I tired the below, but it is no
printing Empty if the range is empty it just prints blank line.
if (!(!PFResutl.toRange).empty) { writeln("Empty"); }
From,
Vino.B
I thought every range at the lowest level has an `empty`
property. So, in this case, it would be:
if (PFResutl.toRange.empty)
{
writeln("Empty");
}
Re: Check whether a range is empty
On 7/15/18 8:56 AM, vino.B wrote: On Sunday, 15 July 2018 at 12:18:27 UTC, Steven Schveighoffer wrote: On 7/15/18 7:45 AM, vino.B wrote: [...] I still don't know why you are using chain here as it equates to the identity function in this instance: https://github.com/dlang/phobos/blob/3d41721141f31059ca6e77dec2da390fad737955/std/range/package.d#L900 Hi Steve, Initially i thought the using "chain" it will merge several ranges for arrays into single range of array, but it doesn't merge into single range of array so i have removed the same from my code. Ahh, I think you want joiner: https://dlang.org/phobos/std_algorithm_iteration.html#joiner -Steve
Re: Is it feasible to slowly rewrite a C++ codebase in D?
16.07.2018 17:32, bachmeier пишет: On Friday, 13 July 2018 at 19:53:45 UTC, Laeeth Isharc wrote: On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote: What are your ideas? If you would like to expose C function and type declarations to D, you could take a look at DPP, which allows you to just #include a C header. If you encounter a bug, please file an issue and in time we will fix it. Does not yet work for C++ except in some cases. https://github.com/atilaneves/dpp I would like to give this a try, but I don't see any instructions for installation on the Github page. I tried dub build dpp, but I got a bunch of error messages. I just build it using dub then do something like that(from memory): `d++ some_c_header.h --include-path path/to/other/c/header/files --keep-d-files` and it generates d file for the corresponding c header. Although dpp is intended to be used directly I use it for generating intermediate files. First of all because when I tried to import nuklear.h dpp generated nuklear.d with simple error - due to bug it included diagnostic message of libclang into d file and it was simpler and faster to edit intermediate file manually than wait for bug fixing.
Re: Implicit conversion of struct with methods to immutable in pure function fails
On Monday, 16 July 2018 at 13:13:53 UTC, Timoses wrote: On Monday, 16 July 2018 at 12:00:57 UTC, Simen Kjærås wrote: On Monday, 16 July 2018 at 11:43:03 UTC, Timoses wrote: Why does this fail? It doesn't. Not using DMD 2.081.1 under Windows, at least. I tried adding a bitfield since you mentioned it, but it compiles nicely for me. Which version of DMD are you using, and are you having the issues with the exact code you posted here? -- Simen https://run.dlang.io/is/Pgs527 I'm on 2.080.1. But above is on latest 2.081.1 I believe. Note that the bottom code snippet in the original post does work, while the first one does not. That makes sense. The problem is F has a context pointer to the main() block, since it's a non-static struct with methods inside a block. It doesn't actually use the context pointer for anything, so it possibly shouldn't have one, but it does, so we have to work around it. The fix is to mark F as static, or move it outside the main() block. -- Simen
