Re: Using python in D
On Fri, 2019-06-07 at 14:02 +, rnd via Digitalmars-d-learn wrote:
This being D meets Python, I thought I'd take a look at this one.
> I tried following in dub.selections.json file:
>
> {
> "fileVersion": 1,
> "versions": {
> "pyd": "0.10.5"
> },
> "subConfigurations": {
> "pyd": "python35"
> }
> }
I do not use JSON for human constructed files, and whilst I think SDL
is inferior to TOML for these sorts of files, I am using the Dub
specification:
name "pyd_test"
description "A PyD project from rnd on the email list."
dependency "pyd" version="*"
subConfiguration "pyd" "python37"
which seems to do the job.
> I also tried python3.5 and python3 in place of python35, but
> everytime python27 is being used (where pandas is not installed).
> The error is:
I only have Python 3.7, I deleted Python 2.7 long ago, and always use
the latest Python on Debian (which may get a bit old during the stupid
process called Debian release freeze.
> $ dub run
> Performing "debug" build using /usr/bin/dmd for x86_64.
> pyd 0.10.5: target for configuration "python27" is up to date.
> <<< NOTE VERSON HERE;
> rntestpy ~master: building configuration "application"...
> Linking...
> To force a rebuild of up-to-date targets, run again with --force.
> Running ./rntestpy
> pyd.exception.PythonException@/home/cardio/.dub/packages/pyd-
> 0.10.5/pyd/infrastructure/pyd/pydobject.d(59):
> exceptions.ImportError: No module named pandas
>
> /home/cardio/.dub/packages/pyd-
> 0.10.5/pyd/infrastructure/pyd/exception.d:46 void
> pyd.exception.handle_exception(immutable(char)[], ulong)
> [0x56438721e9e8]
> /home/cardio/.dub/packages/pyd-
> 0.10.5/pyd/infrastructure/pyd/pydobject.d:59 pyd.pydobject.PydObject
> pyd.pydobject.PydObject.__ctor(deimos.python.object.PyObject*)
> [0x56438721f2e8]
> /home/cardio/.dub/packages/pyd-
> 0.10.5/pyd/infrastructure/pyd/embedded.d:54 pyd.pydobject.PydObject
> pyd.embedded.py_import(immutable(char)[]) [0x56438721e501]
> source/main.d:6 _Dmain [0x56438721ded0]
> Program exited with code 1
>
> I also tried command "dub run --force" but still the error
> persists.
I am getting what appears to be the exact same problem:
|> dub
Performing "debug" build using /usr/bin/ldc2 for x86_64.
pyd 0.10.5: target for configuration "python37" is up to date.
pyd_test ~master: building configuration "application"...
To force a rebuild of up-to-date targets, run again with --force.
Running ./pyd_test
pyd.exception.PythonException@source/main.d(10):
NameError: name 'pandas' is not defined
exception.d:46 [0x564147a72be6]
embedded.d:283 [0x564147a72a23]
main.d:10 [0x564147a6fce1]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll() [0x7f8116bff12f]
??:? _d_run_main [0x7f8116bfef45]
__entrypoint.d:8 [0x564147a70314]
??:? __libc_start_main [0x7f81167d909a]
??:? [0x564147a6fb99]
Program exited with code 1
But I am quietly confident that pandas is installed into the standard
place:
|> aptitude search python3-pandas
i python3-pandas
- data structures for "relational" or "labeled" data -
Python 3
i A python3-pandas-lib
- low-level implementations and bindings for pandas - Python
3
So, a priori, this would seem to be a fault within PyD for not looking
up the right place for Python packages.
Having looked at the dub.json ( :-( ) file for PyD it seems that it is
looking in /usr/lib/python3.7m whereas on Debian the directory should
be /usr/lib/python3.7. I have no idea how to control this from a user
dub.sdl.
Of course the installed Python packages are in /usr/lib/python3/dist-
packages, at least on Debian, so the above shouldn't apply!
> I also tried to give command "source pyd_set_env_vars.sh
> /usr/bin/python3" but still it is not working.
>
> Another command which I tried produced following output but still
> the problem persisted:
>
> $ python3 pyd_get_env_set_text.py
> export PYD_D_VERSION_1=Python_2_4_Or_Later
> export PYD_D_VERSION_2=Python_2_5_Or_Later
> export PYD_D_VERSION_3=Python_2_6_Or_Later
> export PYD_D_VERSION_4=Python_2_7_Or_Later
> export PYD_D_VERSION_5=Python_3_0_Or_Later
> export PYD_D_VERSION_6=Python_3_1_Or_Later
> export PYD_D_VERSION_7=Python_3_2_Or_Later
> export PYD_D_VERSION_8=Python_3_3_Or_Later
> export PYD_D_VERSION_9=Python_3_4_Or_Later
> export PYD_D_VERSION_10=Python_3_5_Or_Later
> export PYD_D_VERSION_11=__PYD__DUMMY__
> export PYD_D_VERSION_12=__PYD__DUMMY__
> export PYD_D_VERSION_13=__PYD__DUMMY__
> export PYD_LIBPYTHON_DIR=/usr/lib
> export PYD_LIBPYTHON=python3.5m
This last one may well be the problem. Try manually adjusting it to
python3.
Re: Using python in D
On Saturday, 8 June 2019 at 09:11:48 UTC, Russel Winder wrote: ... ... The problem seems to be that PyD is not looking in the right place for importing packages, but this is pure speculation. Perhaps this merits a bug report against the PyD source repository? Thanks for your time, effort and a detailed analysis of this problem. I did not delete Python2.7 since I thought there could be some part of Debian/installed package that may depend on it. But I will try to do it now. I am not well versed with the procedure of submitting bug report and will appreciate if you/some other expert on this forum does it. best wishes, rnd.
Re: Using python in D
On Sat, 2019-06-08 at 16:53 +, rnd via Digitalmars-d-learn wrote: > […] > I did not delete Python2.7 since I thought there could be some > part of Debian/installed package that may depend on it. But I > will try to do it now. I overstated the case a bit. I do not use Python 2.7 but there are a few packages that are LaTeX, Samba, etc. related that still require Python 2. This is clearly an insane position but the Debian packages and/or the upstream applications have not been properly managed. There are one or two situations where Python 2 should still be used, but for 99.99% of situations Python 3 is the only choice. > I am not well versed with the procedure of submitting bug report > and will appreciate if you/some other expert on this forum does > it. PyD is hosted on GitHub so it is a question of putting in an issue there: https://github.com/ariovistus/pyd/issues The best bet is to write up what you have presented on email here, and then let the PyD developers guide you into providing the data they need to decide what the actual problem is and how it might be fixed. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: if (X !is null && X.Y !is null) access crash
On 6/8/19 2:28 AM, Amex wrote: On Friday, 7 June 2019 at 16:09:47 UTC, Adam D. Ruppe wrote: It happens when I close down my app. is this inside a destructor? No, it's in an external thread(it is in a callback). All I can think of is that something is happening in between the two checks since there is no way it could happen otherwise. Possible the GC cleaned up the object already. When this happens, you get this kind of behavior (the GC intentionally sets the vtable to null to prevent invalid access). Try GC.addRef on the X reference, and see if it helps. -Steve
Re: FieldNameTuple!T and std.traits.Fields!T not empty for interfaces
On 6/6/19 5:36 PM, Jonathan M Davis wrote: 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. In fact, it feels like the opposite. Returning a tuple of an empty string almost guarantees you will get an error (__traits(getMember, T, "") likely is an error). I just am not sure why someone did that. A perfectly reasonable alternative would be simply to return an empty tuple. -Steve
check if _argument[0] is a descendant of a specific class.
Hi, I'm googling since an hour but this is too much for me:
class A{}
class B:A{}
void foo(...){
if(_arguments[0]==typeid(A)){
//obviously not works for B
}
if(_arguments[0] is_a_descendant_of A){
//how to make it work for both A and B?
}
}
--
Also I tried to write a funct to compare classes by TypeInfo, but
the TypeInfo.next field is not works in the way as I thought. It
gives null, so the following code doesn't work.
auto isClass(C)(TypeInfo i){
if(i==typeid(C)) return true;
auto n = i.next;
return n is null ? false : n.isClass!C;
}
I just wanna check if a compile_time _argument[0] is a descendant
of a class or not.
I also tried (is : ) but without luck.
Thank you.
Re: check if _argument[0] is a descendant of a specific class.
On Saturday, 8 June 2019 at 21:16:14 UTC, realhet wrote:
void foo(...){
Do you have to use the variadic thing?
It is easy to do with template variadic or with just regular
arrays of interfaces/base classes.
I just wanna check if a compile_time _argument[0] is a
descendant of a class or not.
_arguments is a compile time construct, it is a run time thing.
I kinda suspect what you really want to write is
foo(T...)(T args) { }
and then you can do `static if(is(arg[0] : A))` to catch both A
and B.
Your approach for the typeinfo thing at runtime was close though,
just it isn't `next` (that's used for like immutable(A), where
next is A), but `base`.
http://dpldocs.info/experimental-docs/object.TypeInfo_Class.html
but with the compile time list foo(T...)(T args), there's no need
to do typeid/typeinfo at all.
Re: check if _argument[0] is a descendant of a specific class.
On Saturday, 8 June 2019 at 21:24:53 UTC, Adam D. Ruppe wrote: _arguments is a compile time construct, it is a run time thing. err i meant is *NOT* a compile time construct
Re: check if _argument[0] is a descendant of a specific class.
On Saturday, 8 June 2019 at 21:25:41 UTC, Adam D. Ruppe wrote:
On Saturday, 8 June 2019 at 21:24:53 UTC, Adam D. Ruppe wrote:
_arguments is a compile time construct, it is a run time thing.
err i meant is *NOT* a compile time construct
Thank You for the fast help!
At first I was happy to find the variadic example and didn't even
realized, that was the runtime version.
Now it works correctly with the base class check, and also it is
now static and fast:
static foreach(a; args){
static if(is(typeof(a)==string)){
//...
}else
static if(is(typeof(a) : Cell)){
if(a !is null){
//...
}
}else
static if(is(typeof(a)==TextStyle)){
//...
}else{
static assert(0, "Unsupported type: "~typeof(a).stringof);
}
}
Re: Using python in D
On Saturday, 8 June 2019 at 19:35:00 UTC, Russel Winder wrote: PyD is hosted on GitHub so it is a question of putting in an issue there: https://github.com/ariovistus/pyd/issues The best bet is to write up what you have presented on email here, and then let the PyD developers guide you into providing the data they need to decide what the actual problem is and how it might be fixed. Thanks for guidance. I also wanted to know: Once executable is successfully created, will it work on systems where Python and pandas are not installed?
Can D optimize?
Can dmd or ldc optimize the following cases:
foo(int x)
{
if (x > 10 && x < 100) bar1; else bar2;
}
...
for(int i = 23; i < 55; i++)
foo(i); // equivalent to calling bar1(i)
clearly i is within the range of the if in foo and so the checks
are unnecessary.
I realize that this is generally a complex and possibly
unsolvable problem... but in the example above, which comes up
enough, it is not.
Many times when one iterates over an array the boundaries cause
special cases... for maximum performance one has to break up the
boundary cases which just increases code complexity and
verbosity. If the compiler can figure it out automatically then
it is unnecessary.
When working with algorithms
Of course, if the limits are not known at compile time this
method cannot be used...
So, I'm wondering if there is a simple way to achieve the same
thing that is easy on the eyes.
Suppose we have a resampling function. The boundaries require
different functionality.
So there are effectively 3 functions and the loop over the data
would be split up in to three parts. Normally we have to do it by
hand and maintain everything.
I imagine ranges might be able to help solve this in an optimal
way but I'm not sure what might be the best approach. It should
be equivalent to hand written code if not better.
Re: if (X !is null && X.Y !is null) access crash
On Saturday, 8 June 2019 at 20:44:13 UTC, Steven Schveighoffer wrote: On 6/8/19 2:28 AM, Amex wrote: On Friday, 7 June 2019 at 16:09:47 UTC, Adam D. Ruppe wrote: It happens when I close down my app. is this inside a destructor? No, it's in an external thread(it is in a callback). All I can think of is that something is happening in between the two checks since there is no way it could happen otherwise. Possible the GC cleaned up the object already. When this happens, you get this kind of behavior (the GC intentionally sets the vtable to null to prevent invalid access). Try GC.addRef on the X reference, and see if it helps. -Steve This is during shutdown so I imagine simply turning off the GC should work fine? That way it prevents all cases rather than having to add a bunch of specific cases each time they crop up.
