Re: How to convert hex string to string or ubytes? Thanks.

[FrankLike via Digitalmars-d-learn]

On Monday, 5 February 2018 at 06:12:22 UTC, H. S. Teoh wrote:

On Mon, Feb 05, 2018 at 05:48:00AM +, FrankLike via



auto input = "48656c6c6f20776f726c6421";
auto str = input.chunks(2)
.map!(digits => cast(char) digits.to!ubyte(16))
.array;


But,if the input come from here:

import std.digest.md;
auto hash =md5Of("Some Words");
auto input = hexString(hash);
 auto str = input.chunks(2)
 .map!(digits => cast(char) digits.to!ubyte(16))
 .array;

Then get an error:
core.exception.UnicodeException@src\rt\util\utf.d(292):invalid 
UTF-8 sequence

--
0x0041B8E6
0x00419530
0x0040796F

Thanks.

Re: How to convert hex string to string or ubytes? Thanks.

[FrankLike via Digitalmars-d-learn]

On Monday, 5 February 2018 at 06:12:22 UTC, H. S. Teoh wrote:

On Mon, Feb 05, 2018 at 05:48:00AM +, FrankLike via



assert(str == "Hello world!");


Thanks.very good!

Re: How to convert hex string to string or ubytes? Thanks.

[H. S. Teoh via Digitalmars-d-learn]

On Mon, Feb 05, 2018 at 05:48:00AM +, FrankLike via Digitalmars-d-learn 
wrote:
> Now,I can get the string from hex string in compile time,but how to
> get it in run time?
> 
> How to get it in run time?
[...]

Oh wait, I think I misunderstood your original question. Perhaps this is
closer to what you want:

import std.algorithm;
import std.array;
import std.conv;
import std.range;

auto input = "48656c6c6f20776f726c6421";
auto str = input.chunks(2)
.map!(digits => cast(char) digits.to!ubyte(16))
.array;
assert(str == "Hello world!");


T

-- 
Study gravitation, it's a field with a lot of potential.

Re: How to convert hex string to string or ubytes? Thanks.

[H. S. Teoh via Digitalmars-d-learn]

On Mon, Feb 05, 2018 at 05:48:00AM +, FrankLike via Digitalmars-d-learn 
wrote:
> Now,I can get the string from hex string in compile time,but how to
> get it in run time?
> 
> How to get it in run time?
> 
> Thanks.

import std.conv;
string hex = "900D1DEA";
uint value = hex.to!uint(16);
assert(value == 0x900D1DEA);


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you 
wish you hadn't.

Re: Getting compiler Segfault

[H. S. Teoh via Digitalmars-d-learn]

On Sun, Feb 04, 2018 at 12:52:22PM +, Ur@nuz via Digitalmars-d-learn wrote:
> Getting compiler stack overflow when building my project, but still do
> not know how to localize piece of code that triggers this bug. Maybe
> this bug is already registered in bugzilla or someone could give some
> advice where to dig into?
> 
> Just runed building under gdb and got the following stack trace:
[...]

I'm not 100% familiar with the dmd code, but here's my guess as to the
approximate location of the problem, based on looking at the stack
trace:

- It's probably inside a protection declaration, perhaps something like
  `private { ... }` or `protected { ... }` or something along those
  lines.

- There appears to be an import statement somewhere in there, that
  appears to lead to another module with another import;
  
- Eventually, it ends in what looks like a recursive alias to an
  overload that appears to be in a loop, which is likely the cause of
  the compiler crash.

So my wild guess is that there's probably an alias (or multiple aliases)
somewhere in your code that brings in a symbol into an overload set, and
somehow these aliases are referring to each other in a loop. Quite
likely this alias resides in a module imported by another module, which
in turn is imported from within the protection block.

Don't know if this helps, but hopefully it narrows down the problem
somewhat.


T

-- 
People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG

How to convert hex string to string or ubytes? Thanks.

[FrankLike via Digitalmars-d-learn]

Now,I can get the string from hex string in compile time,but how 
to get it in run time?


How to get it in run time?

Thanks.

Re: Should the "front" range primitive be "const" ?

[Simen Kjærås via Digitalmars-d-learn]

On Friday, 2 February 2018 at 14:29:34 UTC, H. S. Teoh wrote:
Its semantics are not broken; it's just harder to use. Due to 
const transitivity, it's an all-or-nothing deal.  .tailConst 
gives us the middle ground.


If the semantics of const means that users will have to write 
.tailConst all over the place, it's broken. If it means that 
users can't use const(T) because they actually want TailConst!T, 
it's broken.


TailConst seems like the logical solution to the problem, but it 
isn't. It directly impacts user code and it leads to lots of 
boilerplate. In addition to .tailConst, we also need 
.tailImmutable. And to top it off, it just doesn't mix with const 
at all - if you pass it as a const parameter, it's broken. If 
it's part of a struct or class with const methods, it's broken. 
It infects every part of your codebase that touches it, it forces 
you to basically implement your own const system in templates, 
and it makes const even harder to use than it currently is.


Tail-const is the more intuitive way to think of it, so if I'm 
wrong, please show me.



Once we've defined immutable(RefCounted!T) to be undefined 
behavior,
suddenly casting from const(RefCounted!T) to 
RefCounted!(const(T)) is

OK again.

[...]

The problem with this is that we're now relying on convention 
rather than something that can be statically verified by the 
compiler. Once you allow casting away const, there's no longer 
a guarantee that somebody didn't pass in an immutable, whether 
by mistake or otherwise. We know from C/C++ where programming 
by convention leads us. :-P


True. Sadly, there's no way to tell the type system 'this type 
should never be immutable'. Maybe such a thing should be in the 
language. Meanwhile, if RefCounted!T implements .headMutable, it 
can check at runtime that the refcount is in writable memory.



Though the above currently doesn't compile, it seems because 
the compiler doesn't know how to resolve Wrapper!(const(T)) 
given a Wrapper!T despite the alias this.


Yeah, I found the same bug when playing with .headMutable:
https://issues.dlang.org/show_bug.cgi?id=18260

--
  Simen

Re: Interfacing with C++

[Timothee Cour via Digitalmars-d-learn]

Calypso (https://github.com/Syniurge/Calypso/) is the most promising
way to interface with C++, it requires 0 bindings and understands all
of C++ (templates etc); there are some caveats/kinks that are being
ironed out (and any help is welcome).


On Sun, Feb 4, 2018 at 4:37 AM, rjframe via Digitalmars-d-learn
 wrote:
> On Sun, 04 Feb 2018 08:33:20 +, Mike Parker wrote:
>
>> Though, I'm curious why anyone would want to declare a callback in a C++
>> program as cdecl only on Windows and use the default C++
>> convention everywhere else. I suggest you dig into it and make sure
>> that's what's intended. And good luck binding to OpenCV!
>
> My guess would be that it's to prevent name mangling of functions in a
> generated DLL and the need for a DEF file.

Re: Setting up DMD on windows

[Seb via Digitalmars-d-learn]

On Sunday, 4 February 2018 at 17:11:21 UTC, Rubn wrote:

On Sunday, 4 February 2018 at 01:33:05 UTC, Seb wrote:

On Sunday, 4 February 2018 at 01:23:50 UTC, Rubn wrote:

On Saturday, 3 February 2018 at 23:42:28 UTC, welkam wrote:

[...]


I think you have to build with an old version of MSVC, 2010 
maybe? It's been a while since I built it I don't remember 
the exactly which version ended up working.


2013 and 2015 are tested on the CIs.


Wasn't that just added? I don't think that CI was running for 
the version he is trying to compile.


IIRC 2013 is the version auto-tester is using and in use for a 
couple of years.

Only AppVeyor (VS 2015) was added recently.

Re: Setting up DMD on windows

[Rubn via Digitalmars-d-learn]

On Sunday, 4 February 2018 at 01:33:05 UTC, Seb wrote:

On Sunday, 4 February 2018 at 01:23:50 UTC, Rubn wrote:

On Saturday, 3 February 2018 at 23:42:28 UTC, welkam wrote:

[...]


I think you have to build with an old version of MSVC, 2010 
maybe? It's been a while since I built it I don't remember the 
exactly which version ended up working.


2013 and 2015 are tested on the CIs.


Wasn't that just added? I don't think that CI was running for the 
version he is trying to compile.

Re: Getting compiler Segfault

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, February 04, 2018 13:54:17 Stefan Koch via Digitalmars-d-learn 
wrote:
> On Sunday, 4 February 2018 at 12:52:22 UTC, Ur@nuz wrote:
> > Getting compiler stack overflow when building my project, but
> > still do not know how to localize piece of code that triggers
> > this bug. Maybe this bug is already registered in bugzilla or
> > someone could give some advice where to dig into?
> >
> > [...]
>
> You'll have to post the code if you want people to be able to
> reproduce things.
> I believe the the dustmite tool should have an obfuscate mode, if
> you cannot share a clear version of it.

It does, though if you give it a large piece of code, odds are that it'll
make your program so unrecognizable that it won't matter.

- Jonathan M Davis

Re: Getting compiler Segfault

[Stefan Koch via Digitalmars-d-learn]

On Sunday, 4 February 2018 at 12:52:22 UTC, Ur@nuz wrote:
Getting compiler stack overflow when building my project, but 
still do not know how to localize piece of code that triggers 
this bug. Maybe this bug is already registered in bugzilla or 
someone could give some advice where to dig into?


[...]


You'll have to post the code if you want people to be able to 
reproduce things.
I believe the the dustmite tool should have an obfuscate mode, if 
you cannot share a clear version of it.

Getting compiler Segfault

[Ur@nuz via Digitalmars-d-learn]

Getting compiler stack overflow when building my project, but 
still do not know how to localize piece of code that triggers 
this bug. Maybe this bug is already registered in bugzilla or 
someone could give some advice where to dig into?


Just runed building under gdb and got the following stack trace:

#149490 0x0056b79a in 
AliasDeclaration::overloadInsert(Dsymbol*) ()
#149491 0x0056be85 in 
OverDeclaration::overloadInsert(Dsymbol*) ()
#149492 0x0056b79a in 
AliasDeclaration::overloadInsert(Dsymbol*) ()
#149493 0x0056be85 in 
OverDeclaration::overloadInsert(Dsymbol*) ()
#149494 0x0056b79a in 
AliasDeclaration::overloadInsert(Dsymbol*) ()
#149495 0x0056be85 in 
OverDeclaration::overloadInsert(Dsymbol*) ()
#149496 0x0056b79a in 
AliasDeclaration::overloadInsert(Dsymbol*) ()
#149497 0x0056be85 in 
OverDeclaration::overloadInsert(Dsymbol*) ()
#149498 0x0056b79a in 
AliasDeclaration::overloadInsert(Dsymbol*) ()
#149499 0x0056be85 in 
OverDeclaration::overloadInsert(Dsymbol*) ()
#149500 0x0056b79a in 
AliasDeclaration::overloadInsert(Dsymbol*) ()
#149501 0x0056be85 in 
OverDeclaration::overloadInsert(Dsymbol*) ()
#149502 0x0056b79a in 
AliasDeclaration::overloadInsert(Dsymbol*) ()
#149503 0x005ce05a in 
dmd.dsymbolsem.aliasSemantic(dmd.declaration.AliasDeclaration, 
dmd.dscope.Scope*) ()
#149504 0x005b5adc in 
DsymbolSemanticVisitor::visit(AliasDeclaration*) ()
#149505 0x0056bc99 in AliasDeclaration::accept(Visitor*) 
()
#149506 0x005b9df0 in 
DsymbolSemanticVisitor::visit(Import*) ()

#149507 0x00570e7a in Import::accept(Visitor*) ()
#149508 0x005bcd24 in 
DsymbolSemanticVisitor::visit(Module*) ()

#149509 0x00594785 in Module::accept(Visitor*) ()
#149510 0x005b9b5f in 
DsymbolSemanticVisitor::visit(Import*) ()

#149511 0x00570e7a in Import::accept(Visitor*) ()
#149512 0x005bae7f in 
DsymbolSemanticVisitor::attribSemantic(AttribDeclaration*) ()
#149513 0x005baf9d in 
DsymbolSemanticVisitor::visit(AttribDeclaration*) ()
#149514 0x0070510f in 
ParseTimeVisitor::visit(ProtDeclaration*) ()

#149515 0x00528b21 in ProtDeclaration::accept(Visitor*) ()
#149516 0x005bcd24 in 
DsymbolSemanticVisitor::visit(Module*) ()

#149517 0x00594785 in Module::accept(Visitor*) ()
#149518 0x0068f8f9 in dmd.mars.tryMain(ulong, 
const(char)**) ()

#149519 0x0069116b in D main ()

Re: Interfacing with C++

[rjframe via Digitalmars-d-learn]

On Sun, 04 Feb 2018 08:33:20 +, Mike Parker wrote:

> Though, I'm curious why anyone would want to declare a callback in a C++
> program as cdecl only on Windows and use the default C++
> convention everywhere else. I suggest you dig into it and make sure
> that's what's intended. And good luck binding to OpenCV!

My guess would be that it's to prevent name mangling of functions in a 
generated DLL and the need for a DEF file.

Re: rdmd main.d leads to Segmentation fault

[Timoses via Digitalmars-d-learn]

On Thursday, 1 February 2018 at 09:01:34 UTC, Kagamin wrote:

On Wednesday, 31 January 2018 at 16:59:15 UTC, Timoses wrote:

And I would need to do what about it?

Sorry, I'm not familiar with assembly code stuff in detail.


You can try to see if it works on another distro or version.


It does work on debian jessie. Stretch failed..

Re: Interfacing with C++

[Seb via Digitalmars-d-learn]

On Sunday, 4 February 2018 at 10:42:22 UTC, infinityplusb wrote:

On Sunday, 4 February 2018 at 08:33:20 UTC, Mike Parker wrote:

[...]
it is, everyone keeps saying writing bindings in D is super 
easy ...

I feel this is a slight simplification. :(


[...]

Sounds easy enough.


[...]



[...]

Thanks, I feel I'm going to need it ...


For C headers, you can use dstep to automatically generate the 
respective D header file: https://github.com/jacob-carlborg/dstep

Re: Interfacing with C++

[infinityplusb via Digitalmars-d-learn]

On Sunday, 4 February 2018 at 08:33:20 UTC, Mike Parker wrote:

On Sunday, 4 February 2018 at 08:17:31 UTC, Mike Parker wrote:

Assuming this is OpenCV ...
it is, everyone keeps saying writing bindings in D is super easy 
...

I feel this is a slight simplification. :(


version(Windows)
extern(C) alias CvCmpFunc = int function(const(void)*, 
const(void)*, void*);

else
extern(C++) alias CvCmpFunc = int function(const(void)*, 
const(void)*, void*);

Sounds easy enough.

Though, I'm curious why anyone would want to declare a callback 
in a C++ program as cdecl only on Windows and use the default 
C++ convention everywhere else. I suggest you dig into it and 
make sure that's what's intended.



And good luck binding to OpenCV!

Thanks, I feel I'm going to need it ...

Re: Interfacing with C++

[Mike Parker via Digitalmars-d-learn]

On Sunday, 4 February 2018 at 08:17:31 UTC, Mike Parker wrote:



So assuming CV_CDECL is cdecl, this should do it:

extern(C) alias CvCmpFunc = int function(const(void)*, 
const(void)*, void*);


Assuming this is OpenCV, Looking at [1], it's cdecl only on 
Windows. Empty everywhere else. So since OpenCV is a C++ library 
these days, I guess it needs to be declared like this:


version(Windows)
extern(C) alias CvCmpFunc = int function(const(void)*, 
const(void)*, void*);

else
extern(C++) alias CvCmpFunc = int function(const(void)*, 
const(void)*, void*);


Though, I'm curious why anyone would want to declare a callback 
in a C++ program as cdecl only on Windows and use the default C++ 
convention everywhere else. I suggest you dig into it and make 
sure that's what's intended. And good luck binding to OpenCV!



[1] 
https://github.com/opencv/opencv/blob/master/modules/core/include/opencv2/core/types_c.h#L68

Re: Interfacing with C++

[Mike Parker via Digitalmars-d-learn]

On Sunday, 4 February 2018 at 07:54:12 UTC, infinityplusb wrote:

Hi all

I'm looking to try and write an interface to C++, but given I'm 
a casual dabbler in D, it's slightly beyond my current ability 
in terms of both C++ and D!


As a leg up, how would one translate something like this from 
C++ to D?


`typedef int (CV_CDECL* CvCmpFunc)(const void* a, const void* 
b, void* userdata );`


From my basic understanding I assumed something like:

`alias CvCmpFunc = Typedef!(int) ; `

but then I'm stuck as to where the rest of the parameters would 
get passed?
Do I just declare it as a function instead? That wasn't my 
understanding of reading how typedefs worked, however so I'm a 
little confused.


Any help would be appreciated.



First, you have to understand how CV_CDECL is defined. This is 
going to determine the calling convention that functions pointed 
to by CvCmpFunc will have. Assuming it's defined to cdecl, the 
standard C calling convention (which I'm guess it is) then your D 
definition needs to be extern(C). If it's stdcall, then you need 
extern(Windows). If it's empty, then you need extern(C++).


Second, because this is a function pointer you're declaring, you 
need to use D's function pointer declaration syntax.


Third, we don't need to use the Typedef template for this. alias 
alone is fine.


So assuming CV_CDECL is cdecl, this should do it:

extern(C) alias CvCmpFunc = int function(const(void)*, 
const(void)*, void*);

Re: Interfacing with C++

[rikki cattermole via Digitalmars-d-learn]

On 04/02/2018 7:54 AM, infinityplusb wrote:

Hi all

I'm looking to try and write an interface to C++, but given I'm a casual 
dabbler in D, it's slightly beyond my current ability in terms of both 
C++ and D!


As a leg up, how would one translate something like this from C++ to D?

`typedef int (CV_CDECL* CvCmpFunc)(const void* a, const void* b, void* 
userdata );`


 From my basic understanding I assumed something like:

`alias CvCmpFunc = Typedef!(int) ; `

but then I'm stuck as to where the rest of the parameters would get passed?
Do I just declare it as a function instead? That wasn't my understanding 
of reading how typedefs worked, however so I'm a little confused.


Any help would be appreciated.

Regards


alias CvCmpFunc = extern(C /* I think */) int function(const void* a, 
const void* b, void* userdata);