Re: [ANN] mc^2


On Sun, 10 May 2015 13:05:42 +0200
"Yury V. Zaytsev" <yury 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: . 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

5) ...

Sorry, but I don't think that MicroPython is a viable choice,

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]