Re: CVS import: othersrc/external/mit/micropython

[Kamil Rytarowski <n54%gmx.com@localhost>]

-----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-----