nPython.exe is just a C# tool to simulate the behavior of pure python interpreter. It uses Python.Runtime.dll, which is also C# and contains all logic to make the "bridge" between:
- Native calls to Python and program logic: they all are simply redirected to pure python interpreter already installed in your system. - Instantiations of C# objects (from C# itself or contained in an dll referenced by your script): they are kept in "C# realm" and only translated to a way python can understand. I didn't compile python here, I only compiled nPython. Do you need to compile python too? Can't you just install python on your system via apt? Em ter, 24 de jan de 2017 às 16:49, Daniel Krause <mad...@web.de> escreveu: > Hello William, > > I tried your nPython.exe, yes, it works on my raspberry. > > Could you explain, what you did to create this python-version? Did you > compile it on Windows? > And how would you add modules like numpy etc? > I am sorry if these questions sound silly, but I have no experience with > compiling python from scratch. > > Thanks a lot for your support so far > Daniel > > > 2017-01-22 22:03 GMT+01:00 Daniel Krause <mad...@web.de>: > > Hi, > > I tried to compile python 3.6 from source. > ./configure > make > worked without problems. > > But > make test > failed. > The logfile is attached. > > I am afraid this problem is beyond the scope of this mailing list, but > perhaps someone has an idea anyway. > > Thanks > Daniel > > 2017-01-22 19:38 GMT+01:00 William Ivanski <william.ivan...@gmail.com>: > > Hey, Daniel, > > Maybe it's a bug on the version of Python for .NET you compiled. Maybe if > you try the .EXE and .DLL I compiled and sent you? > > Em dom, 22 de jan de 2017 às 15:10, Daniel Krause <mad...@web.de> > escreveu: > > Hello, > > I installed the current mono-version 4.6.2.16-0xamarin1 and upgraded my > system with `sudo -H apt-get upgrade mono-complete`. > The examples for mono worked (I tested the console example and the winform > example), the clr import from python still gives me errors: > > import clr > *** Error in `python3.5': free(): invalid pointer: 0x76011050 *** > Stacktrace: > > at <unknown> <0xffffffff> > at (wrapper managed-to-native) Python.Runtime.Runtime.Py_Initialize () > <0x00033> > at Python.Runtime.Runtime.Initialize () <0x00027> > at Python.Runtime.PythonEngine.Initialize () <0x0007f> > at Python.Runtime.PythonEngine.InitExt () <0x0002f> > at (wrapper runtime-invoke) <Module>.runtime_invoke_intptr > (object,intptr,intptr,intptr) <0x0006f> > > Native stacktrace: > > > Debug info from gdb: > > [New LWP 21070] > [Thread debugging using libthread_db enabled] > Using host libthread_db library > "/lib/arm-linux-gnueabihf/libthread_db.so.1". > __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46 > 46 ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or > directory. > Id Target Id Frame > * 1 Thread 0x76f1c300 (LWP 21069) "python3.5" __libc_do_syscall () at > ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46 > 2 Thread 0x761b1470 (LWP 21070) "Finalizer" __libc_do_syscall () at > ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46 > > Thread 2 (Thread 0x761b1470 (LWP 21070)): > #0 __libc_do_syscall () at > ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46 > #1 0x76eb2834 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, > expected=1, futex_word=0x76843c78) at > ../sysdeps/unix/sysv/linux/futex-internal.h:205 > #2 do_futex_wait (sem=sem@entry=0x76843c78, abstime=0x0) at > sem_waitcommon.c:115 > #3 0x76eb2916 in __new_sem_wait_slow (sem=0x76843c78, abstime=0x0) at > sem_waitcommon.c:282 > #4 0x76734cc4 in ?? () from /usr/lib/libmonoboehm-2.0.so.1 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > Thread 1 (Thread 0x76f1c300 (LWP 21069)): > #0 __libc_do_syscall () at > ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46 > #1 0x76eb432a in __waitpid (pid=21071, stat_loc=0x7eb086e4, options=0) at > ../sysdeps/unix/sysv/linux/waitpid.c:29 > #2 0x76695d08 in ?? () from /usr/lib/libmonoboehm-2.0.so.1 > > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > ================================================================= > Got a SIGABRT while executing native code. This usually indicates > a fatal error in the mono runtime or one of the native libraries > used by your application. > ================================================================= > > Aborted (core dumped) > > 2017-01-18 13:37 GMT+01:00 William Ivanski <william.ivan...@gmail.com>: > > Hey, Daniel, > > Sorry I didn't ask from which repo you installed mono on your system. I'm > assuming you installed from Ubuntu repo, which provides mono 4.2 even on > Ubuntu 16.10. > > If you want to try mono 4.6, you may be able to install it on your system > from official mono repo: > http://www.mono-project.com/docs/getting-started/install/linux/ > > Please let me know if it works for you. > > Em qua, 18 de jan de 2017 às 10:31, Daniel Krause <mad...@web.de> > escreveu: > > Hi William, > > it is good to hear, that Ubuntu 16.10 is working. > Unfortunately there is no Ubuntu 16.10 for Raspberry available (or let's > say, I did not find it, and I would be happy with the LTS-version...). > > Pythonnet is compiled from github as on your machine. I am using the same > mono-version as the pythonnet project uses for its testing, but on my > machine something is not working. > > You are also using a newer version of mono. > > Maybe there is a way to upgrade the version of mono on my system to > version 4.6.2 to give that a test? > > Thanks > Daniel > > > 2017-01-18 11:56 GMT+01:00 William Ivanski <william.ivan...@gmail.com>: > > Hi, Andres, Daniel and others, > > It works, I'm using Kubuntu 16.10 and mono 4.6.2. To run: > > mono nPython.exe test.py > > I compiled Python for .NET myself from GitHub repo. You can always toss > away the EXE and the DLL, and compile them yourself. > > Em qua, 18 de jan de 2017 às 03:16, Andres <kno...@gmail.com> escreveu: > > Daniel, and others, I advice not to consume random binaries from random > people on the internet. > > On Wednesday, January 18, 2017 06:09 AM, William Ivanski wrote: > > Please see solution > > here: > https://drive.google.com/file/d/0B6qR86JfcfthdDNwS2g4V2RFRmc/view?usp=sharing > > > > It works, I'm using Kubuntu 16.10 and mono 4.6.2. I compiled Python for > > .NET myself from GitHub repo. > > To run: > > > > mono nPython.exe test.py > > > > Em ter, 17 de jan de 2017 às 18:57, Daniel Krause <mad...@web.de > > <mailto:mad...@web.de>> escreveu: > > > > Hello, > > > > I am trying to to use mono from python via pythonnet. > > > > My system: > > > > *Ubuntu* > > > > * Release 16.04.1 LTS (Xenial Xerus) 32-bit > > * Kernel Linux 4.1.19-v7+ armv7l > > * MATE 1.12.1 > > > > *Hardware* > > > > * Memory: 925,8 MiB > > * Processor: ARMv7 Processor rev 4 (v7l) × 4 > > > > *Mono: *mono-complete (4.2.4.4-0wheezy1) > > > > **More information on the system and installed dependencies for > > pythonnet can be found in this thread: > > https://github.com/pythonnet/pythonnet/issues/327 > > > > The following small test script fails at the first step (importing > > the clr): > > #!/usr/bin/env python3 > > > > print('import clr') > > import clr > > print('clr imported') > > > > if __name__ == '__main__': > > print('main') > > exit(0) > > > > It gives the following traceback: > > import clr > > *** Error in `python3.5': free(): invalid pointer: 0x75b92050 *** > > Stacktrace: > > > > at <unknown> <0xffffffff> > > at (wrapper managed-to-native) > > Python.Runtime.Runtime.Py_Initialize () <0xffffffff> > > at Python.Runtime.Runtime.Initialize () <0x0002f> > > at Python.Runtime.PythonEngine.Initialize () <0x00093> > > at Python.Runtime.PythonEngine.InitExt () <0x0002f> > > at (wrapper runtime-invoke) <Module>.runtime_invoke_intptr > > (object,intptr,intptr,intptr) <0xffffffff> > > > > Native stacktrace: > > > > > > Debug info from gdb: > > > > [New LWP 1901] > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library > > "/lib/arm-linux-gnueabihf/libthread_db.so.1". > > 0x76f23454 in __libc_do_syscall () from > > /lib/arm-linux-gnueabihf/libpthread.so.0 > > Id Target Id Frame > > * 1 Thread 0x76f8a300 (LWP 1900) "python3.5" 0x76f23454 in > > __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0 > > 2 Thread 0x76250470 (LWP 1901) "Finalizer" 0x76f23454 in > > __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0 > > > > Thread 2 (Thread 0x76250470 (LWP 1901)): > > #0 0x76f23454 in __libc_do_syscall () from > > /lib/arm-linux-gnueabihf/libpthread.so.0 > > #1 0x76f20834 in do_futex_wait.constprop () from > > /lib/arm-linux-gnueabihf/libpthread.so.0 > > #2 0x76f20916 in __new_sem_wait_slow.constprop.0 () from > > /lib/arm-linux-gnueabihf/libpthread.so.0 > > #3 0x767dae84 in mono_sem_wait () from > /usr/lib/libmonoboehm-2.0.so.1 > > #4 0x767a89a0 in ?? () from /usr/lib/libmonoboehm-2.0.so.1 > > Backtrace stopped: previous frame identical to this frame (corrupt > > stack?) > > > > Thread 1 (Thread 0x76f8a300 (LWP 1900)): > > #0 0x76f23454 in __libc_do_syscall () from > > /lib/arm-linux-gnueabihf/libpthread.so.0 > > #1 0x76f2232a in waitpid () from > > /lib/arm-linux-gnueabihf/libpthread.so.0 > > #2 0x767122bc in ?? () from /usr/lib/libmonoboehm-2.0.so.1 > > Backtrace stopped: previous frame identical to this frame (corrupt > > stack?) > > > > ================================================================= > > Got a SIGABRT while executing native code. This usually indicates > > a fatal error in the mono runtime or one of the native libraries > > used by your application. > > ================================================================= > > > > Aborted (core dumped) > > > > My debugging skills are very poor, anyway, I tried to use valgrind > > to get perhaps a better idea. The output: > > ==2813== Memcheck, a memory error detector > > ==2813== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et > al. > > ==2813== Using Valgrind-3.11.0 and LibVEX; rerun with -h for > > copyright info > > ==2813== Command: python3.5 pythonnet_test.py > > ==2813== > > disInstr(arm): unhandled instruction: 0xF1010200 > > cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0) > > ==2813== valgrind: Unrecognised instruction at address 0x48596f4. > > ==2813== at 0x48596F4: ??? (in > > /usr/lib/arm-linux-gnueabihf/libarmmem.so) > > ==2813== Your program just tried to execute an instruction that > Valgrind > > ==2813== did not recognise. There are two possible reasons for this. > > ==2813== 1. Your program has a bug and erroneously jumped to a > non-code > > ==2813== location. If you are running Memcheck and you just saw a > > ==2813== warning about a bad jump, it's probably your program's > > fault. > > ==2813== 2. The instruction is legitimate but Valgrind doesn't > > handle it, > > ==2813== i.e. it's Valgrind's fault. If you think this is the > > case or > > ==2813== you are not sure, please let us know and we'll try to > > fix it. > > ==2813== Either way, Valgrind will now raise a SIGILL signal which > will > > ==2813== probably kill your program. > > ==2813== > > ==2813== Process terminating with default action of signal 4 (SIGILL) > > ==2813== Illegal opcode at address 0x48596F4 > > ==2813== at 0x48596F4: ??? (in > > /usr/lib/arm-linux-gnueabihf/libarmmem.so) > > ==2813== > > ==2813== HEAP SUMMARY: > > ==2813== in use at exit: 1,088 bytes in 10 blocks > > ==2813== total heap usage: 62 allocs, 52 frees, 5,692 bytes > allocated > > ==2813== > > ==2813== LEAK SUMMARY: > > ==2813== definitely lost: 0 bytes in 0 blocks > > ==2813== indirectly lost: 0 bytes in 0 blocks > > ==2813== possibly lost: 0 bytes in 0 blocks > > ==2813== still reachable: 1,088 bytes in 10 blocks > > ==2813== suppressed: 0 bytes in 0 blocks > > ==2813== Rerun with --leak-check=full to see details of leaked memory > > ==2813== > > ==2813== For counts of detected and suppressed errors, rerun with: -v > > ==2813== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from > 0) > > Illegal instruction (core dumped) > > > > Both the traceback from python and the output of valgrind are beyond > > my comprehension. > > > > Has anyone have an idea, what is wrong, and how to fix it? > > > > Thanks > > Daniel > > _______________________________________________ > > Mono-list maillist - Mono-list@lists.dot.net > > <mailto:Mono-list@lists.dot.net> > > http://lists.dot.net/mailman/listinfo/mono-list > > > > -- > > > > William Ivanski - Microsoft MVP > > > > > > > > _______________________________________________ > > Mono-list maillist - Mono-list@lists.dot.net > > http://lists.dot.net/mailman/listinfo/mono-list > > > > -- William Ivanski - Microsoft MVP
_______________________________________________ Mono-list maillist - Mono-list@lists.dot.net http://lists.dot.net/mailman/listinfo/mono-list