[ANN] mc^2

[Paul Sokolovsky]

Hello,

On Sun, 10 May 2015 13:44:25 +0200
Egmont Koblinger <egmont at gmail.com> wrote:

> On Sun, May 10, 2015 at 1:25 PM, Paul Sokolovsky <pmiscml at gmail.com>
> wrote:
> 
> Brief response, and we've heard each other's opinion, and I'm not
> trying to convince anyone or go into endless debates/flames.
> 
> Trivia quiz or what? Ok, unix rewrote multics bloat, lives so far,
> > multics dead for big decades. gcc "rewrote" a lot of older vendor
> > compiler crap. llvm/clang "rewrote" gcc to let vendors do more
> > compiler crap. Etc, etc.
> >
> 
> And compare the engineer staffing of these projects to mc's.  Okay, I
> should rephrase my question: in a project that hardly has resources
> to fix even the most critical bugs (e.g. currently there's a segfault
> in 4.8.14 and no solution yet), what are the changes of successfully
> reimplementing 20 years of work from scratch?  I believe it's 0.  Not
> zero-point-lots-of-zeros-one, but zero.

Egmont, things you're saying are very depressing ;-). Maybe looking
around for some inspiration would help ;-) I for example find
http://litcave.rudi.ir/ very inspiring - the guy is not too shy to write
his linker, assembler, compiler, mail client, mailer, pdf reader, etc.
And he's not afraid of "20 years of work" because stuff he does "just
works", and dozens of years are needed for bloat, not "real thing" 
(also, living somewhere by the warm sea in an orange garden and
sequencing DNA as day jobs probably helps too ;-) ).

(This passage, as some other, not directly related to mc hacking of
course, but rather a generic weekend software engineering gossip).

> > Does that mean that you've got commit access?
> >
> 
> No, I don't have. (Why is it relevant?)

Because you spend time communicating on mailing list. And we know, the
biggest problem mc project has is lack of communication from decision-
and commit- makers.

[]

> Nice speech, but can we please have simpler issues which waited in
> > queue for years be tackled first?
> 
> 
> Not sure what you mean by this.  I know that many bugs weren't
> addressed, but in the mean time many others were.  Mooffie's work
> provides a better ground for quicker development in the future.  He's
> not solving issues one by one, but helps solving any subsequent ones
> more effectively.  Yet you argue that instead we should focus on
> continuing fixing bugs one by one...

Yes, please fix handful of bugs in core/basic things in components.
Leave bugs which can be fixed with Mooffie's work for later. If mc is
20-old project, then it should have some quality, and there shouldn't
be more than that "handful" of core/basic bugs.

And the editor is a core component (you're not writing it in a
scripting language), and bugs are certainly - for example, after you
fixed copy/paste in editor, working with it no longer an ordeal (I
can't believe I used it with paste like it was before - I must be a real
hardcode mc fan). Only few bugs left. Reasons for fixing them are
provided. Patches are provided. Leave aside any VFS and similar stuff -
it's obvious that the only way to get it right is to rewrite in
scripting language.

> Anyway, Mooffie has shown us some code.  You don't quite like it,
> you'd take a totally different approach.  Okay, your turn, convince
> us, show us the code please ;)

My whole motive is that before adding "exciting new" stuff (which is
hardly "new" - as I argued even *rewriting* entire mc in scripting is
pretty obvious choice, and scripting support should have been there
ages ago) - old stuff should rather be fixed, especially if all
data/code for that is provided. So, I showed code -
https://github.com/MidnightCommander/mc/pull/49 . If there completely
formal fears for "editor binary safety", I proposed to have it
configurable and off by default. And if that code is not good, someone
else can show other code. And if there's no such code, then maybe time
to think that mc is used by real people for real tasks, and just take
the existing code to let people do them. (Which is the same what I wish
to Mooffie with his code - however incompletely perfect it may be).

> 
> 
> cheers,
> egmont



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