[ANN] mc^2

Paul Sokolovsky pmiscml at gmail.com
Sun May 10 11:55:03 UTC 2015


Hello,

On Sun, 10 May 2015 13:05:42 +0200
"Yury V. Zaytsev" <yury at shurup.com> wrote:

> On Sun, 2015-05-10 at 13:12 +0300, Paul Sokolovsky wrote:
> 
> > As a shameless plug, I can offer a better alternative:
> > https://github.com/micropython/micropython . It would offer about
> > the same footprint as Lua, while offering more pleasant data model,
> > and well-known standard library. As a full disclosure, it's rather
> > younger than Lua (but pretty well developed at 4K commits) and it
> > would be first (known, as it's BSD, anyone can do it secretly)
> > standalone project to embed it.
> 
> I really like Python and, of course, I know about MicroPython. Now,
> let's do a simple reality check:
> 
> 1) How many distributions have it packaged so far?

You ask as if it was a systemd and you're looking start witchhunt
against distro which still didn't include it ;-). 

> 2) Does it already provide a stable embedding API?

Nope, that's why I think it would be interesting to have use of it like
that, to establish it ;-).

> 3) How complete is the standard library? (I know...)

Good news: there's a standard library, I mean something which really
can be called that! Unlike Lua.

> 4) Does it have a JIT? (okay, this one is unfair)

It has AOT, which is cooler, as you get timing guarantees. Also, *Lua*
doesn't have JIT. It's a separate project, whose API is compatible or
not. Python as a language does have JIT, if you need that for plugin
scripting.

> 5) ...
> 
> Sorry, but I don't think that MicroPython is a viable choice,
> unfortunately.
> 
> However, in the end, I don't think that it's a big deal: there is Lupa
> and Lunatic Python, so once the support for Lua gets in, you can use
> Python just as well. At the same time, if you absolutely want to use
> Python directly, in theory, you can later re-use the same
> infrastructure for MicroPython.
> 
> > Fairly speaking, Mooffie is very lucky that his random hack got so
> > much attention. There're simpler and more important issues which
> > are open for 5+ years
> 
> The problem is that the definition of "important" is in the eyes of
> the beholder. I'm sorry, but I personally couldn't care less about
> #1652, simply because I don't. I recognize that it might be a deal
> breaker for you, but not for me.

That's why it's important that *maintainers* take formal criteria of
"completeness" and "lack of random gaps in functionality". And
higher-level criteria, like mc being an open-source project, which
naturally should be expected to be used for, and appreciate needs of
open-source software. And OSS is very diversified, including
line-endings. I'm, as an open-source developer, deal with at least a
dozen new projects each month, and regularly hit cases when mc instead
of helping, complicates me contributing to such software (by not
allowing to edit files comfortably).

So, yes, you personally may not care about it, but this issue - of
diversity of real-world files - objectively exists.

> However, do I personally care a lot about the list of tickets that
> mooffie has shown a solution for with his patch. Is it surprising that
> I'm excited about it?

Let me translate: you're excited to add yet another toy-like, bloat
feature, which will of course be buggy - instead of fixing what's
already in queue (and I know not everyone cares about #1652, it's just
an example of ~1 thing which makes me frustrated about mc, instead of
making me happy, I'm sure it's similar for many other people - there're
merely several long-standing issues to fix, new features can wait).

> I hope that your patch eventually will get reviewed and merged, as
> long as it doesn't affect the binary safety by default, but this
> can't be me, sorry about that.

I do hope so too, especially that again, it's not exactly my patch, few
people contributed to it, they just lost the already, apparently.

> 
> By the way, I wonder if hooks can be added to the editor so that it
> would be viable to implement the line endings autodetection via the
> scripting engine...

Please, no! Get it right first, so it worked for 99% cases without any
"scripts", then work on creeping featuritis to let people do
mind-boggling things.

> 
> -- 
> Sincerely yours,
> Yury V. Zaytsev
> 
> 



-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com



More information about the mc-devel mailing list