-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 17.01.2016 01:34, Alistair Crooks wrote: > Taken from othersrc/README: > > "The "othersrc" collection consists of programs that are either > "not ready for the main tree" or "never going to be ready for the > main tree" but which are NOT appropriate to pkgsrc because they > have no external maintainer." > > In this case, it's a case of not quite ready for the main tree - > I've been looking for a small, embeddable python for a long time > (cpython doesn't quite hit those checklist items), and micropython > fits the bill. I found that tinypy > (http://www.philhassey.com/blog/wp-content/uploads/2008/02/tinypy.tgz) > > was too difficult to modify, and was fairly long in the tooth these > days. Micropython, OTOH, is a 3.4 clone, which works well for me.
Recent debuggers (GDB and LLDB) are scriptable with Python. LLVM may make use of it in additional tools too. I assume the same applies for bind and KYUA/ATF. There is a large test suite for LLDB written with Python. Recently they were upgrading from 2.7 to 3+. Just in case regarding the 3.5 version, Mercurial community decided to not support 3.0-3.4 due to lack of the % operator on str types [1]. The missing free licensed (in the BSD meaning) piece is swig to generate bindings. It generates problems for commercial users of LLDB (like Apple). [1] https://www.mercurial-scm.org/wiki/SupportedPythonVersions > The problem, as ever, is in libffi - then there is library > function support, and, after that, module support, but I think this > is a step in the right direction. > As of libffi, it's not that bad, Miod before his departure from OpenBSD added older archs to it, like VAX and mvme88k. libffi is also MIT-licensed so it shouldn't taint the base. As I understand it, base libraries are built-in, which is good. My vision of Python in base is a minimalist package with minimalist target/use-case, somewhere between the original Python and base Lua. I I see pkgsrc's original Python as oriented towards modules, libraries, real world applications and Lua oriented towards pure C embedding. I would love to use base gdb/lldb with enabled Python extensions. > I talked briefly to christos about micropython, and he encouraged > me to take it to tech-misc, and I shall try to do that, but I'm > behind on so much mail right now, it's embarassing. > > My goal is to have micropython be next to lua in the toolchain, not > in place of it (although I think there's going to come a time quite > soon where lua is going to have to justify its existence, and not > just the netpgp bindings I wrote, as I also did perl, python and > tcl bindings at the same time). > I wouldn't like to get to a point of justifying existence of Lua. > Definitely not aiming to be a fork - the external sources were > imported on a vendor branch, and local fixes for reachover > infrastructure and NetBSD packaging were added afterwards so that > we can incorporate future updates from upstream. > This sounds good to have another upstream. > I have a pkgsrc entry made for it micropython-1.5.2, will try to > add it RSN. > Thank you. > Best, Alistair > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWm4l1AAoJEEuzCOmwLnZsedoQAKVg8rxEgDSgFLG0Pi+S6elk xLMFvX5sMpmFirt1KtWUTONu2ApR1rmi0R9fa3IBM8mN2DrbMWwrFLRqcxSD5Dv5 EMizbkzWCy3DKhEBbQpWP9VV4JK6Nc8ZeNbu29GMJJwH9LzCYs2tbS5+W5nme/ya /z2ezZSFVL8pNKoFQiBp3fjvIBPcT/fTXqKrIXbTtZgFg+1KtF7+7RE8bnuHoU2q eNiLnn/J47dZWNZxgxgjwJFpx2t7jlhicu3Nx25n+ezs9lm18sSdci5UNMGFiL/k Eu4x0+2WHBGWe1OEyu25+W7YUz5cp2Txy+Ms1FW8bYdFDvTZqQamftY2KFGLQeAG q93siCAQa1F6PUDb/1JXdA0q0LS3Uwbjsiz5FHrR9KZeOYChBbl63ANbc6M9E1fK feFJwy4MMwpx3gu+vz+N9naWJ2au22d5ZhOpr2rp2tCGQI4FlB0xCW6LvizrnPrE IN9kzRUHxAKBiKTxq94dYwymjMXG8LJQ1q0SnozW2g+suhdFWjhim1U/BVP6Las2 bfXePfpv2cGKMifRQPPQS/c7CUTqnsdsLKPU6nLWFEtWl+mqAVEVN+rVqpV1df9c b7mZPIfrVHNQoS3Gsr19WooSOXwpFZ3cKlbhwu7dk7P5EFg8MZmjwhQGdCvJj98x MUOI9LKSG3ZYz+V90YfT =8+o4 -----END PGP SIGNATURE-----
