Re: Why any! with map! is not working here
On Thursday, June 6, 2019 10:21:39 PM MDT rnd via Digitalmars-d-learn wrote: > On Thursday, 6 June 2019 at 21:32:11 UTC, Jonathan M Davis wrote: > > If any is not given a predicate, it defaults to just checking > > whether the element itself is true (requiring that the element > > be bool), which is why Marco's suggestion works, but it's a > > rather odd way to write the code and will be less efficient > > unless the optimizer manages to optimize away the extra work > > involved with having map. > > > > However, in general, with D, you're not going to find that > > there is only one way to do things. There are going to tend to > > be many different approaches to solve the same problem. D code > > is often simple because of the powerful language constructs and > > standard library, but it makes no attempt to make it so that > > there's only one way to do things - especially when you start > > combining stuff to do whatever it is you're trying to do. > > > > - Jonathan M Davis > > Maybe one of these methods can be made 'official' or 'idiomatic': If you're looking for the language or library to tell you exactly how you should be doing things, then you've come to the wrong language. There are approaches that are more idiomatic than others (e.g. range-based solutions are usually favored), but D is purposefully designed to be multi-paradigm, and there are going to be very different approaches to a problem where each approach is equally viable or where one approach is better in some situations, whereas another is better in others. And once we're dealing with combining functions to get a job done, it would actually be very difficult to try to claim that a particular combination of them is the correct way. Which functions make sense is going to depend on the task, and it's naturally going to be possible to combine functions in different ways to get the same result. > > any!pred(ss); > > ss.any!pred(); > > ss.any!pred; > > This will reduce learning burden on beginners. We're not going to make requirements over that sort of thing any more than we're going to require that all D code use a particular bracing style. D provides the tools needed to get stuff done, but for the most part, it doesn't try to tell you how to use them. There are some best practices for how to go about things in D, but that's not usually about stuff like coding style, and it really covers a fairly small number of the decisions that a D programmer has to make. The closest that you're going to get on coding style is the official style guide ( https://dlang.org/dstyle.html ), and aside from some Phobos-specific requirements at the bottom, it's mostly just about how you name public symbols so that there's some consistency when using other people's libraries. For best practices, you're going to get things like "use ranges" and "make your imports local." You're not going to be told how to format your code or which set of functions you should be using to solve a particular problem. - Jonathan M Davis
Re: Using python in D
On Friday, 7 June 2019 at 04:39:14 UTC, rikki cattermole wrote: On 07/06/2019 3:54 PM, rnd wrote: How should I 'initialize python' ? The example is probably a good place to begin. https://github.com/ariovistus/pyd/blob/master/examples/simple_embedded/hello.d Thanks for the link. After putting in missing statements, it started running but reported: exceptions.ImportError: No module named pandas I believe pyd is working on Python2 while I have pandas installed in Python3. How can I specify Python version 3 in pyd?
Re: Using python in D
On 07/06/2019 3:54 PM, rnd wrote: Edit: I tried above D program and got following error: core.exception.AssertError@/home/abcde/.dub/packages/pyd-0.10.5/pyd/infrastructure/pyd/embedded.d(53): python not initialized ??:? _d_assert_msg [0x5562d3f3c466] /home/abcde/.dub/packages/pyd-0.10.5/pyd/infrastructure/pyd/embedded.d:53 pyd.pydobject.PydObject pyd.embedded.py_import(immutable(char)[]) [0x5562d3f0b2f1] source/main.d:6 _Dmain [0x5562d3f0adeb] How should I 'initialize python' ? The example is probably a good place to begin. https://github.com/ariovistus/pyd/blob/master/examples/simple_embedded/hello.d
Re: Why any! with map! is not working here
On Thursday, 6 June 2019 at 21:32:11 UTC, Jonathan M Davis wrote: If any is not given a predicate, it defaults to just checking whether the element itself is true (requiring that the element be bool), which is why Marco's suggestion works, but it's a rather odd way to write the code and will be less efficient unless the optimizer manages to optimize away the extra work involved with having map. However, in general, with D, you're not going to find that there is only one way to do things. There are going to tend to be many different approaches to solve the same problem. D code is often simple because of the powerful language constructs and standard library, but it makes no attempt to make it so that there's only one way to do things - especially when you start combining stuff to do whatever it is you're trying to do. - Jonathan M Davis Maybe one of these methods can be made 'official' or 'idiomatic': any!pred(ss); ss.any!pred(); ss.any!pred; This will reduce learning burden on beginners.
Re: Using python in D
Edit: I tried above D program and got following error: core.exception.AssertError@/home/abcde/.dub/packages/pyd-0.10.5/pyd/infrastructure/pyd/embedded.d(53): python not initialized ??:? _d_assert_msg [0x5562d3f3c466] /home/abcde/.dub/packages/pyd-0.10.5/pyd/infrastructure/pyd/embedded.d:53 pyd.pydobject.PydObject pyd.embedded.py_import(immutable(char)[]) [0x5562d3f0b2f1] source/main.d:6 _Dmain [0x5562d3f0adeb] How should I 'initialize python' ?
Using python in D
I have a simple python script file which contains following 3
statements:
import pandas
df = pandas.read_csv('testfile.csv')
print(df[0:3])
Can I incorporate above in a D program?
I see there is pyd package for using python in D:
https://code.dlang.org/packages/pyd
Will following program work:
import std.stdio;
import pyd.embedded;
void main(){
py_import("pandas");
py_stmts("df = pandas.read_csv('testfile.csv')");
py_stmts("print(df[0:3])");
}
Thanks for your insight.
Re: FieldNameTuple!T and std.traits.Fields!T not empty for interfaces
On Thursday, June 6, 2019 2:52:42 PM MDT Steven Schveighoffer via Digitalmars-d-learn wrote: > On 6/6/19 4:49 PM, Steven Schveighoffer wrote: > > Oh wait! It's not empty, it has an empty string as a single member! > > That's definitely a bug. > > OK, not a bug, but not what I would have expected. From docs: > > "If T isn't a struct, class, or union, an expression tuple with an empty > string is returned." > > I wonder why that behavior is there, certainly it's intentional. I guess that whoever wrote it did that rather than making it an error so that they wouldn't have to first check whether they were passing a type that even made sense. It still seems like an odd decision though. Normally, you'd just require that an appropriate type be passed. - Jonathan M Davis
Re: Why any! with map! is not working here
On Thursday, June 6, 2019 5:50:36 AM MDT rnd via Digitalmars-d-learn wrote: > On Thursday, 6 June 2019 at 09:49:28 UTC, Jonathan M Davis wrote: > > So, to start, the any portion should be something more like > > > > any!pred(ss); > > > > or > > > > ss.any!pred(); > > > > or > > > > ss.any!pred; > > > > where pred is whatever the predicate is. > > Apparently, following also works: > > > any(ss.map!(a => a > 127)) // as written by Marco de Wild > or > any(map!(a => a > 127)(ss)) > > > Thanks for detailed explanations. > Philosophically, I personally think, there should be only one way > to do such things since that will add to simplicity, as in C. > Apparently, smallness and simplicity of C contributed greatly to > its success. > Only drawbacks of C, like its unsafe parts, should be removed and > clearly advantages newer concepts should be added in a clearly > defined manner. > Just thinking loudly! If any is not given a predicate, it defaults to just checking whether the element itself is true (requiring that the element be bool), which is why Marco's suggestion works, but it's a rather odd way to write the code and will be less efficient unless the optimizer manages to optimize away the extra work involved with having map. However, in general, with D, you're not going to find that there is only one way to do things. There are going to tend to be many different approaches to solve the same problem. D code is often simple because of the powerful language constructs and standard library, but it makes no attempt to make it so that there's only one way to do things - especially when you start combining stuff to do whatever it is you're trying to do. - Jonathan M Davis
Re: Why this fails when using unittest?
On 6/6/19 1:49 PM, Adam D. Ruppe wrote:
On Thursday, 6 June 2019 at 17:40:17 UTC, Machine Code wrote:
outside an unittest, this compiles fine:
struct A
try making it `static struct` instead
cannot implicitly convert expression "hehe" of type string to A
Why does inside a unittest it doesn't work? the constructor
this(string) {} seems to get disabled.
My suspicion is it is trying to access the context of the unittest as a
hidden paramater to that constructor there... and in an enum, it can't,
just stupid compiler didn't think to mention the hidden arg here.
my guess.
Yes, correct guess. A unittest block is actually a function, so it's
considered an inner struct with a hidden context pointer.
-Steve
Re: FieldNameTuple!T and std.traits.Fields!T not empty for interfaces
On 6/6/19 4:49 PM, Steven Schveighoffer wrote: Oh wait! It's not empty, it has an empty string as a single member! That's definitely a bug. OK, not a bug, but not what I would have expected. From docs: "If T isn't a struct, class, or union, an expression tuple with an empty string is returned." I wonder why that behavior is there, certainly it's intentional. -Steve
Re: FieldNameTuple!T and std.traits.Fields!T not empty for interfaces
On 6/6/19 4:43 PM, Steven Schveighoffer wrote:
On 6/6/19 4:22 PM, Amex wrote:
FieldNameTuple!T
std.traits.Fields!T
are non-empty when T is an interface!
An interface cannot contain fields and yet these return non-zero and
screws up my code. While I can filter for interfaces it makes me
wonder what else may slip through?
Is it a bug or what is going on?
Can you provide code to demonstrate? I get no fields when I do this:
interface I
{
}
import std.traits;
pragma(msg, FieldNameTuple!I);
Oh wait! It's not empty, it has an empty string as a single member!
That's definitely a bug.
-Steve
Re: FieldNameTuple!T and std.traits.Fields!T not empty for interfaces
On 6/6/19 4:22 PM, Amex wrote:
FieldNameTuple!T
std.traits.Fields!T
are non-empty when T is an interface!
An interface cannot contain fields and yet these return non-zero and
screws up my code. While I can filter for interfaces it makes me wonder
what else may slip through?
Is it a bug or what is going on?
Can you provide code to demonstrate? I get no fields when I do this:
interface I
{
}
import std.traits;
pragma(msg, FieldNameTuple!I);
-Steve
Re: FieldNameTuple!T and std.traits.Fields!T not empty for interfaces
On Thursday, 6 June 2019 at 20:22:26 UTC, Amex wrote: Is it a bug or what is going on? my suspicion is it is actually the pointer to the vtable getting caught up in it but idk, i didn't really look, just guessing.
Re: typeid, typeinfo, classinfo not returning most derived
On Thursday, 6 June 2019 at 20:22:00 UTC, Amex wrote: I i = new D(); It is a bizarre quirk, I think because interfaces do not necessarily point to objects with RTTI (though this can be statically determined, so I am not sure that is valid), but when you do typeid on an interface, it gives the typeinfo for that interface, not the object itself. First cast to Object, then get the typeid and you'll see what you want to see. maybe we should just change this behavior.
FieldNameTuple!T and std.traits.Fields!T not empty for interfaces
FieldNameTuple!T std.traits.Fields!T are non-empty when T is an interface! An interface cannot contain fields and yet these return non-zero and screws up my code. While I can filter for interfaces it makes me wonder what else may slip through? Is it a bug or what is going on?
typeid, typeinfo, classinfo not returning most derived
- x 0x004b71e0 {Interface for main.I} {m_init={length=0
ptr=0x}, name="main.I", vtbl={length=0 ptr=0x},
...} object.TypeInfo_Class {TypeInfo_Class}
[TypeInfo_Class]D0006: Error: Type resolve failed
m_init {length=0 ptr=0x} byte[]
+ name"main.I" string
vtbl{length=0 ptr=0x} void*[]
interfaces {length=0 ptr=0x}
object.Interface[]
base0x object.TypeInfo_Class
destructor 0x void*
classInvariant 0x void function(object.Object)*
m_flags 36 uint
deallocator 0x void*
m_offTi {length=0 ptr=0x} object.OffsetTypeInfo[]
defaultConstructor 0x void
function(object.Object)*
m_RTInfo0x const(void)*
- i 0x004b71e0 {Interface for main.I} {m_init={length=0
ptr=0x}, name="main.I", vtbl={length=0 ptr=0x},
...} object.TypeInfo_Class {TypeInfo_Class}
[TypeInfo_Class]D0006: Error: Type resolve failed
m_init {length=0 ptr=0x} byte[]
+ name"main.I" string
vtbl{length=0 ptr=0x} void*[]
interfaces {length=0 ptr=0x}
object.Interface[]
base0x object.TypeInfo_Class
destructor 0x void*
classInvariant 0x void function(object.Object)*
m_flags 36 uint
deallocator 0x void*
m_offTi {length=0 ptr=0x} object.OffsetTypeInfo[]
defaultConstructor 0x void
function(object.Object)*
m_RTInfo0x const(void)*
- c 0x004b71e0 {Interface for main.I} {m_init={length=0
ptr=0x}, name="main.I", vtbl={length=0 ptr=0x},
...} object.TypeInfo_Class {TypeInfo_Class}
[TypeInfo_Class]D0006: Error: Type resolve failed
m_init {length=0 ptr=0x} byte[]
+ name"main.I" string
vtbl{length=0 ptr=0x} void*[]
interfaces {length=0 ptr=0x}
object.Interface[]
base0x object.TypeInfo_Class
destructor 0x void*
classInvariant 0x void function(object.Object)*
m_flags 36 uint
deallocator 0x void*
m_offTi {length=0 ptr=0x} object.OffsetTypeInfo[]
defaultConstructor 0x void
function(object.Object)*
m_RTInfo0x const(void)*
Simply for the code
auto info(T)(T o)
{
auto x = typeid(o);
auto i = x.typeinfo;
auto c = o.classinfo;
return;
}
info exists in it's own module called from the main module.
interface I
{
void foo();
}
abstract class A : I
{
}
class C : A
{
void foo()
{
writeln("x");
}
}
class D : C { }
and
I i = new D();
info(i);
(more or less)
Re: Why this fails when using unittest?
On Thursday, 6 June 2019 at 17:40:17 UTC, Machine Code wrote:
outside an unittest, this compiles fine:
struct A
{
enum A foo = "hehe";
this(string a) { m_a = a; }
alias m_a this;
string m_a;
}
but if you wrap this a unittest {} and compile with
dmd -unittest -run foo.d
this give the following error:
cannot implicitly convert expression "hehe" of type string to A
Why does inside a unittest it doesn't work? the constructor
this(string) {} seems to get disabled.
I this notice albeit a simple cast workaround that:
enum A foo = cast(A)"hehe";
or better:
enum foo = A("hehe");
but isn't that a bug? what am I missing?
Re: Why this fails when using unittest?
On Thursday, 6 June 2019 at 17:40:17 UTC, Machine Code wrote:
outside an unittest, this compiles fine:
struct A
try making it `static struct` instead
cannot implicitly convert expression "hehe" of type string to A
Why does inside a unittest it doesn't work? the constructor
this(string) {} seems to get disabled.
My suspicion is it is trying to access the context of the
unittest as a hidden paramater to that constructor there... and
in an enum, it can't, just stupid compiler didn't think to
mention the hidden arg here.
my guess.
Why this fails when using unittest?
outside an unittest, this compiles fine:
struct A
{
enum A foo = "hehe";
this(string a) { m_a = a; }
alias m_a this;
string m_a;
}
but if you wrap this a unittest {} and compile with
dmd -unittest -run foo.d
this give the following error:
cannot implicitly convert expression "hehe" of type string to A
Why does inside a unittest it doesn't work? the constructor
this(string) {} seems to get disabled.
Re: Why any! with map! is not working here
On Thursday, 6 June 2019 at 09:49:28 UTC, Jonathan M Davis wrote: So, to start, the any portion should be something more like any!pred(ss); or ss.any!pred(); or ss.any!pred; where pred is whatever the predicate is. Apparently, following also works: any(ss.map!(a => a > 127)) // as written by Marco de Wild or any(map!(a => a > 127)(ss)) Thanks for detailed explanations. Philosophically, I personally think, there should be only one way to do such things since that will add to simplicity, as in C. Apparently, smallness and simplicity of C contributed greatly to its success. Only drawbacks of C, like its unsafe parts, should be removed and clearly advantages newer concepts should be added in a clearly defined manner. Just thinking loudly!
Re: Reading .pem files for secured
On Thursday, 6 June 2019 at 11:08:18 UTC, Dukc wrote: We were both wrong :-). It turned out that the correct way to initialize a SecureD RSA private key is to feed contents of .pem in without ANY processing. Ah, they made it even easier :)
Re: Reading .pem files for secured
On Friday, 31 May 2019 at 12:17:14 UTC, Sebastiaan Koppe wrote: On Friday, 31 May 2019 at 10:35:46 UTC, Dukc wrote: But then came a problem that I need to feed the key from .pem to initialize RSA class. Just base64 decode the PEM data (without the ) and feed it to RSA.this(ubyte[] publicKey). Ought to be that simple. We were both wrong :-). It turned out that the correct way to initialize a SecureD RSA private key is to feed contents of .pem in without ANY processing.
Re: Get module file path from ModuleInfo
On Thursday, 6 June 2019 at 10:16:17 UTC, Jacob Carlborg wrote:
On Thursday, 6 June 2019 at 04:20:52 UTC, Andre Pany wrote:
Hi,
I want to enhance a unittest framework to also report the
results in SonarQube Generic Execution format. This format
lists the file paths.
The unittest framework loops through the modules and collects
the module name and the unittests:
foreach (moduleInfo; ModuleInfo)
{
if (moduleInfo)
{
auto unitTest = moduleInfo.unitTest;
if (unitTest)
{
testClass.name = moduleInfo.name;
testClass.test = (o, test) { unitTest(); };
testClasses ~= testClass;
}
}
}
Is there any way to get the module file path (the value
__FILE__ would contain in the modules)?
Kind regards
André
No, I think you have to use `__traits(getUnitTests)`.
—
/Jacob Carlborg
Also __traits(getUnitTests) does not return the module file name.
The approach above is working fine in the d-unit library
(https://code.dlang.org/packages/d-unit)
What do you think does make more sense to make it possible:
- Enhance ModuleInfo
(https://dlang.org/library/object/module_info.html) with a new
attribute "string file"
- add a new trait __traits(file, "module name")
Kind regards
André
Re: Get module file path from ModuleInfo
On Thursday, 6 June 2019 at 04:20:52 UTC, Andre Pany wrote:
Hi,
I want to enhance a unittest framework to also report the
results in SonarQube Generic Execution format. This format
lists the file paths.
The unittest framework loops through the modules and collects
the module name and the unittests:
foreach (moduleInfo; ModuleInfo)
{
if (moduleInfo)
{
auto unitTest = moduleInfo.unitTest;
if (unitTest)
{
testClass.name = moduleInfo.name;
testClass.test = (o, test) { unitTest(); };
testClasses ~= testClass;
}
}
}
Is there any way to get the module file path (the value
__FILE__ would contain in the modules)?
Kind regards
André
No, I think you have to use `__traits(getUnitTests)`.
—
/Jacob Carlborg
Re: Why any! with map! is not working here
On Thursday, June 6, 2019 3:01:11 AM MDT rnd via Digitalmars-d-learn wrote:
> I am trying to check if any character in the string is > 127 by
> following function:
>
> import std.algorithm.searching;
> import std.algorithm.iteration;
> bool isBinary(char[] ss){
>return (any!(map!(a => a > 127)(ss)));
> }
>
> However, I am getting this error:
>
> Error: variable ss cannot be read at compile time
>
> I also tried:
>
> bool isBinary(char[] ss){
> return (any!(ss.map!(a => a > 127)));
> }
>
>
> But I get error:
>
> Error: template identifier map is not a member of variable
> mysrcfile.isBinary.ss
>
>
> How can this be corrected?
Well, it might be easier to see the problem if you removed the outer layer
of parens, since they do nothing and just clutter up the code further.
bool isBinary(char[] ss){
return any!(map!(a => a > 127)(ss));
}
Now, let's add the parens for the function call for clarity.
bool isBinary(char[] ss){
return any!(map!(a => a > 127)(ss))();
}
So, as should now be obvious, the first problem here is that you're not
passing any function arguments to any - neither through UFCS or through the
normal function call syntax. any takes a predicate as a template argument
and a range as a runtime argument. Presumably, you want to be passing ss to
any. However, you're passing it to map, which is part of the predicate for
any, and the way that you're doing it results in the compiler trying to
evaluate ss at compile-time, which isn't going to work, because it's a
runtime variable - hence the compiler error that you're seeing.
So, to start, the any portion should be something more like
any!pred(ss);
or
ss.any!pred();
or
ss.any!pred;
where pred is whatever the predicate is. That would then iterate through ss
and return whether the predicate returned true for any element. So, you'd
want something like
bool isBinary(char[] ss){
return any!pred(ss);
}
That then leaves the question of what the predicate should be (since, you're
obviously not going to just put the value pred there). The predicate needs
to be something that's callable - be it a function, a delegate, a lambda,
etc. Most typically, it's a lambda.
map!(a => a > 127)(ss);
is not a lambda. It's simply a function call to map. The a => a > 127 is a
lambda for map, but the overall expression is not a lambda. It calls map on
ss and converts it to a range of bool where each element is true if the
corresponding element of ss was greater than 127. It could be turned into a
lambda by doing something like
b => map!(a => a > 127)(ss)
but the return value isn't bool (which is what's necessary for a predicate),
and it really doesn't make sense to be using ss in the predicate anyway.
You're already iterating over ss with any. What you want is a predicate
that's going to be true for an element of ss that matches the condition
you're testing for. What you said about that is
> I am trying to check if any character in the string is > 127
So, let's build something that does that. The simplest would be
a => a > 127
This would then give you
bool isBinary(char[] ss){
return any!(a => a > 127)(ss);
}
map is neither necessary nor useful here. map is for converting the elements
from one type to another, which you don't need to do here.
Now, that solution _does_ unfortunately autodecode, so it's actually
decoding sequences of char to dchar and then testing them - which will work
in this case but is unnecessary work. To avoid that, either
std.string.representation or std.utf.byCodeUnit would work. e.g.
bool isBinary(char[] ss){
return any!(a => a > 127)(ss.representation());
}
or
bool isBinary(char[] ss){
return any!(a => a > 127)(ss.byCodeUnit());
}
representation would convert string[] to immutable(ubyte)[], and byCodeUnit
converts string[] to a range of code units instead of a range of code points
(so a range of char instead of a range of dchar).
Of course, you could also do something like
bool isBinary(char[] ss){
return any!isASCII(ss.byCodeUnit());
}
using std.ascii.isASCII, which makes what you're testing for more explicit.
And if you prefer UFCS, then
bool isBinary(char[] ss){
return ss.byCodeUnit().any!isASCII();
}
or
bool isBinary(char[] ss){
return ss.byCodeUnit.any!isASCII;
}
- Jonathan M Davis
Why any! with map! is not working here
I am trying to check if any character in the string is > 127 by
following function:
import std.algorithm.searching;
import std.algorithm.iteration;
bool isBinary(char[] ss){
return (any!(map!(a => a > 127)(ss)));
}
However, I am getting this error:
Error: variable ss cannot be read at compile time
I also tried:
bool isBinary(char[] ss){
return (any!(ss.map!(a => a > 127)));
}
But I get error:
Error: template identifier map is not a member of variable
mysrcfile.isBinary.ss
How can this be corrected?
Re: Not able to use this C++ library in D
You should declare methods too, see example https://dlang.org/spec/cpp_interface.html#using_cpp_classes_from_d
