Re: [ANN] mc^2
On 5/8/15, Egmont Koblinger egm...@gmail.com wrote: Hi, How much work would it be to port your branch to 4.8.14 or git head? I'd really like to use your version for daily work Done. The 4.8.14 port has just been pushed to github. The Getting started (and Installation) chapter now has the appropriate branch name. (This is not yet the stage-by-stage patch I promised here to the maintainers (together with some reviewers guide document, to ease their work), but this will come soon.) ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On Wed, 2015-05-27 at 19:25 +0300, Mooffie wrote: (This is not yet the stage-by-stage patch I promised here to the maintainers (together with some reviewers guide document, to ease their work), but this will come soon.) Sweet! Sorry, I was hoping to commit the stuff you added to the Trac in the last couple of days this evening, but... I ran out of time. -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On 5/11/15, Alexander Kriegisch alexan...@kriegisch.name wrote: And now there comes along Mooffie and donates something to the project. As I expected based on my experience with my own patches, people start discussing details and demanding smaller patches In case you're referring here to people asking me to split my patch into smaller ones, then they're absolutely right in their request. It's something I certainly ought to do. [...] instead of discussing and staying stuck in your analysis paralysis? (I think people here were all positive towards the idea behind mc^2, so I believe your impression, in this case at least, was wrong. There was just one guy (Paul) who showed some frustration. I don't think harm has been done *yet* ;-) ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hey guys. Just my two cents because I am still subscribed to this list even though after several years my pet ticket with ready-to use improvement patches have still not been merged into the main line because the project is practically dead. No offense meant, it is OSS and the developers do it for free in their sparetime. I have a high respect for that, guys. I know there are more or less frequent releases, but IMO they do not bring a lot of added value, at least not for me. And now there comes along Mooffie and donates something to the project. As I expected based on my experience with my own patches, people start discussing details and demanding smaller patches instead of just breathing some new life into MC by friggin' merging the patches into to code base. Sorry for being an Agile Coach and thus a smart-ass by nature, but can you not just apply, inspect, adapt instead of discussing and staying stuck in your analysis paralysis? Thank you so much for bearing with me, and feel free to just ignore my rant if you do not like it. I have no intention of self-defending me or my theses and turning this discussion into a flame war. I just wanted to get this off my chest. Kind regards -- Alexander Kriegisch http://scrum-master.de___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On Mon, 2015-05-11 at 02:28 +0300, Paul Sokolovsky wrote: Come on, how can I stop something new being accepted if I can't get even a reasonable response and dialog from maintainers regarding a 5-year old issue with 2-years old patch at iteration #5, to which maintainers themselves contributed?. You overestimate my powers. Very simply so; let me give you a specific example: last Sunday you took the time that I personally could have put into looking further at mooffie's patch away by starting an nonconstructive conversation. Unfortunately, I felt the need to engage, because I was afraid that mooffie will get an impression that his work is not welcome; however, I'd really like to see it merged, and to get this done, it requires him to re-apply his changes on top of master in smaller digestible chunks, so that it can be properly reviewed. If he gets demotivated, I don't see this happening. So, as the time I could donate to OSS on this day ran out, I simply had to close the laptop lid. One could see it as a primitive denial of service attack... -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hi Alexander, On Mon, 2015-05-11 at 16:33 +0200, Alexander Kriegisch wrote: Sorry for being an Agile Coach and thus a smart-ass by nature, but can you not just apply, inspect, adapt instead of discussing and staying stuck in your analysis paralysis? If you'd actually followed the thread, you would have gathered that inspect, adapt and apply (in this order) is exactly what the maintainers are after in this particular case. It would be great if you would consider using some other venue if you just want to get something random off your chest: I have no problem with constructive rants, but almost every single sentence of your post was misguided. However, very annoyingly, trying to explain something to you will most likely not work anyways, but also take time away from actually getting mooffie's work merged. Thanks! -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Sun, 10 May 2015 21:01:38 +0200 Egmont Koblinger egm...@gmail.com wrote: [] Your arguments make me feel that you're personally offended because your pet peeve bug didn't get fixed so far, and in turn you'd like to stop getting something new accepted, just because you'd do it differently. Come on, how can I stop something new being accepted if I can't get even a reasonable response and dialog from maintainers regarding a 5-year old issue with 2-years old patch at iteration #5, to which maintainers themselves contributed?. You overestimate my powers. Otherwise, I do feel for any contributor who submits patches and get ~zero response, so only glad for Mooffie whose patch spurred so unbelievable for this mailing list's last year (or that years?) discussion. (No conspiracy theories please about me and Mooffie playing good and bad cop trying to trick you into accepting it, lol). Well, do _it_ (not something else) the way you'd like to see it, and I'm sure we'll seriously consider accepting that. I do not care about plugins, though glad to discuss approach to them with people who care (I'll get them in software I run too after all). But I'm taking chance to remind that beside exciting new things there're old basic things which has patches, etc. - and waiting for review and progress. And I'd appreciate you consider (seriously or normally) *that*. Until then, Mooffie's work is what we have, and I see no reason to put any obstacle to this. Just beacuse, oh my god, there's another bug that we could've fixed so far but we haven't... Again, please don't put it upside down. I *don't* use my issue as excuse to not look into other things. The maintainers can also consider not taking other issues (which are fixed all the time) as an excuse for not looking into that one. e. -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On 5/10/15, Paul Sokolovsky pmis...@gmail.com wrote: ... and the conversation is focused around priority of things to do [...] is exciting new is the only thing you're after, then Paul, Nowhere did I market mc^2 as bringing exciting new stuff. If you'd checked out mc^2 site, you'd have found a page listing reasons to have scripting support. You'd have discovered that one of my major motives was to help fix this heartbreaking situation of users whose patches get ignored. I mention there the frustration and embitterment they feel. It was even in my announcement message here on this mailing list. Read it again. Nowhere do I use the words features or new or exciting or shiny. The words I *do* use there are to put an end to this waste of human resources. Read mc^2 frontpage again. The one out of which you plucked one sentence. Does it have exciting or new or features or shiny on it? No, it hasn't. It talks about making MC's code leaner, and fixing bugs. What's ironic, Paul, is that if you'd bothered to check out mc^2 you'd have seen that it concurs with your own agenda. It's just that while you're just preaching (or bickering, should I say), I'm actually doing. Furthermore, If you ever bother to read the documents there, or my few messages here, you'll see that I make it a principle to hand over all policy decisions to the community/maintainers. I market mc^2 only as food for thought, and I mention directions in which the community, not me, may choose to go. I also state (the obvious) that the community is free to deem my work garbage. I submit myself to their will because I know it's the only way to go forward in order to achieve the goal, and the goal is not shiny exciting new features but keeping MC alive and solving the heartaches of the contributors and users. Now, don't bother to compose a reply, Paul. I think you'll agree with me that we probably won't manage a very constructive discussion here. I'll welcome any private email from you if you wish to, though. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hi, On Sun, May 10, 2015 at 10:49 AM, Yury V. Zaytsev y...@shurup.com wrote: Egmont, would you be able to do as much? Formally you are not part of the core team, but then again, if Andrew ends up being alone to look at all this stuff, another pair of eyes would definitively be of help... Thanks for thinking about me, it's very kind of you! I'm happy to take a more thorough look if my time permits, but please don't rely on me; also I'm not the right person to comment on the big picture as I'm not familiar with mc that much. I'm more likely to send nitpicking comments only. cheers, e. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On Sun, 2015-05-10 at 12:41 +0200, Morten Bo Johansen wrote: How about S-Lang? It is already used for the terminal stuff in mc. That's an interesting point; my dislike for S-Lang is by far stronger than for Lua, but it is true that we still support it as an alternative to ncurses. Still, I'd tend to agree with Egmont, but if you are volunteering to redo mooffie's work on top of S-Lang ;-), then maybe we could see as to make the actual hooks as language-agnostic as possible, so that you can have your S-Lang engine and Paul his MicroPython one? -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Sun, 10 May 2015 13:18:52 +0200 Egmont Koblinger egm...@gmail.com wrote: On Sun, May 10, 2015 at 1:05 PM, Yury V. Zaytsev y...@shurup.com wrote: 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. 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? Big +1 for this response. Mooffie's work doesn't address one-off bugs or feature requests, but provides a much better ground for speeding up development and adding cool features. It's way more interesting to me than any other open mc bug. Here we go again - Gnome3 support, hurrah! Adding cool features is **bad** if old basic features cannot be gotten right. cheers, egmont -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On Sun, 10 May 2015 14:25:50 +0300 Paul Sokolovsky wrote: the patch exists http://www.midnight-commander.org/ticket/1652 , and only held by exactly perfectionist attitudes and lack of more general response. I don't have words other than I wrote in ticket comments. -- Andrew ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Sun, 10 May 2015 13:44:25 +0200 Egmont Koblinger egm...@gmail.com wrote: On Sun, May 10, 2015 at 1:25 PM, Paul Sokolovsky pmis...@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:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On Sun, 2015-05-10 at 14:55 +0300, Paul Sokolovsky wrote: 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. So, if I were to take your answers at their face value rather than something you said just to make a mailing list argument, it's basically, no, no and no. OK. 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. Okay, AOT is nice, but the statement on LuaJIT API is unfair. Python as a language does have JIT, if you need that for plugin scripting. Thanks for kindly letting me know about it! I'm one of the minor contributors to PyPy. 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. Your argument is zum Besten der Armen; everybody knows that the situation with the maintenance of mc is suboptimal to say the least. However, it's all in your hands: 1) You can maintain your own patchset on top of mc, like I did for years, and it's not as difficult as it might seem 2) You can keep pesting the current maintainers and hope for the best (like Egmont does, and more often than not, he is successful at that, so maybe if you aren't, then there is something you could have done differently, if success is your ultimate goal in the first place) 3) You can fork mc or rewrite it from scratch 4) You can hire someone to work on mc The possibilities are endless. Instead, you keep complaining on the mailing list that somebody who submitted something you didn't like got the attention you think should have been rather given to you. That's your choice. Good luck! -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Sun, 10 May 2015 13:45:09 +0200 Yury V. Zaytsev y...@shurup.com wrote: On Sun, 2015-05-10 at 14:25 +0300, Paul Sokolovsky wrote: 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. Less features is good. I consider mc a unix tool, it's not replacement for command line (or overbloated vendor IDEs), it should do not too many things, but do it right. So, are you undertaking to rewrite mc in the same way as llvm/clang folks rewrote gcc? I considered that. But mc kinda works, and there're lot of stuff which doesn't exist ore really not good enough (for example, llvm needs to be rewritten in scripting language, yeah), I unlikely will ever get to it. But if this talk will inspire someone else to do it - very nice. (I recently got inspired to start another project I had in queue for ~10 years - that's how it works with people). [] If not, then, I'm afraid that I'm not interested in continuing this line of the conversation. ... and the conversation is focused around priority of things to do, which I argue should be fixing old bugs, then proceed with new things. Because is exciting new is the only thing you're after, then rewriting mc would be the best way to get a lot of that new and exciting. And for mc, I'm sure it's not the first patch to integrate some scripting. I'd be curious to learn about the previous attempts. I don't imply I know them, but I can't believe over 20 years nobody thought about that to a level of hacking something up. I'd have done that long ago, if mcedit inspired me to do that, instead of frustrating ;-). Nice speech, but can we please have simpler issues which waited in queue for years be tackled first? My list of *lacking* (not nice to have, like plugins in scripting language) is simple and short: But wait, I have my own list! It's simple and short: fix the regexp stuff and directory compare. How about my list? And I'm sure that Egmont has his own list. How about his list? What makes your list better than ours? There're half-dozen active people on this list. Couple of issues per person = 12 issues. Let's be fair and consider tickets too: among hundreds multi-year ones, there probably about same half-dozen which still have people moaning behind them. ~20 issues to fix - not too bad. Btw, directory compare would better be handled by scripting - there can be multiple criteria which you may want to use, hacking scripted source on demand would be cool. Regexp is core stuff, needs fixing, yeah. -- Sincerely yours, Yury V. Zaytsev -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On Sun, May 10, 2015 at 1:05 PM, Yury V. Zaytsev y...@shurup.com wrote: 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. 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? Big +1 for this response. Mooffie's work doesn't address one-off bugs or feature requests, but provides a much better ground for speeding up development and adding cool features. It's way more interesting to me than any other open mc bug. cheers, egmont ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On Sun, May 10, 2015 at 1:25 PM, Paul Sokolovsky pmis...@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. Does that mean that you've got commit access? No, I don't have. (Why is it relevant?) Yup, it's so complicated because it's written in C. People write in C when target microcontrollers with 16K code size and 0.5K RAM size. It's hilarious to write application-level software in C. IMHO not any more hilarious as writing application-level software in a script language. Anyway, once can e.g. do a C - C++ transition in small incremental steps, without starting over from scratch. You can't do a C - python transition this way. Less features is good. I consider mc a unix tool, it's not replacement for command line (or overbloated vendor IDEs), it should do not too many things, but do it right. mc already does lots of things. Some are important to you while others never use them. Some are intensively being used by others, yet you wouldn't care about those. If you reimplement not too many things, for most users it'll be a failure that lacks important features, and will stick to the old version. Or frustrated users and quitting developers if development model's not right, as we discussed here (from your premise) end of last year. Exactly. I believe Mooffie's approach is a much nicer step in solving this problem than a complete rewrite would be. 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... 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 ;) cheers, egmont ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On Sun, 2015-05-10 at 14:25 +0300, Paul Sokolovsky wrote: 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. Less features is good. I consider mc a unix tool, it's not replacement for command line (or overbloated vendor IDEs), it should do not too many things, but do it right. So, are you undertaking to rewrite mc in the same way as llvm/clang folks rewrote gcc? If yes, then please go ahead and do share your results with the rest of us when you are done. If you end up doing some brilliant work that can readily supplant mc in its current shape and form, I'll be the first to jump the ship. If not, then, I'm afraid that I'm not interested in continuing this line of the conversation. And for mc, I'm sure it's not the first patch to integrate some scripting. I'd be curious to learn about the previous attempts. Nice speech, but can we please have simpler issues which waited in queue for years be tackled first? My list of *lacking* (not nice to have, like plugins in scripting language) is simple and short: But wait, I have my own list! It's simple and short: fix the regexp stuff and directory compare. How about my list? And I'm sure that Egmont has his own list. How about his list? What makes your list better than ours? -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Sun, 10 May 2015 13:05:42 +0200 Yury V. Zaytsev y...@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:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Sun, 10 May 2015 15:13:17 +0300 Andrew Borodin aboro...@vmail.ru wrote: On Sun, 10 May 2015 14:25:50 +0300 Paul Sokolovsky wrote: the patch exists http://www.midnight-commander.org/ticket/1652 , and only held by exactly perfectionist attitudes and lack of more general response. I don't have words other than I wrote in ticket comments. Yes, but beyond literal words you wrote (which is, sorry, nitpicking and word-play of hide vs remove), your concern is editor binary safety. I replied that with last iteration, I did all due diligence to minimize (in a real-world sense) possibility of mistaken line-endining detection, but if you still consider that not good enough, I proposed making the detection optional, and off by default. And that's where it stuck, though there really would rather be further discussion. Another obvious choice is that you (or someone else) propose the code to do it right. So please let's have further discussion - leaving it hang for next 5 years is hardly helpful. -- Andrew -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Sun, 10 May 2015 14:51:17 +0200 Yury V. Zaytsev y...@shurup.com wrote: [] 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. Your argument is zum Besten der Armen; everybody knows that the situation with the maintenance of mc is suboptimal to say the least. However, it's all in your hands: 1) You can maintain your own patchset on top of mc, like I did for years, and it's not as difficult as it might seem That's kinda what I do, but I find myself behind it all the time (mc is basic background tool for me, I don't dream about maintaining my won fork of grep). And when I spawn a new EC2/vagrant/docker box, I want to use it right away, not clone and build source. I also want to grin at the sight of vim/emacs/idea/whatever and say that solution of my community is better (so far I would lie). 2) You can keep pesting the current maintainers and hope for the best (like Egmont does, and more often than not, he is successful at that, so maybe if you aren't, then there is something you could have done differently, if success is your ultimate goal in the first place) My ultimate goal is mc's success, not my patch's. I'd be happy if someone reimplemented that patch with complete binary safety. That's certainly what I tried first, but found that with current editor codebase it will be quite cumbersome (entails lots of bugs), and will make the codebase even more cumbersome. As you guessed, my next step was not to rewrite editor, but to look for realistic and sustainable way to implement it, and I keep pushing it, because other folks actually contributed to it to make it better, so it would be nice to lead somewhere. [] The possibilities are endless. Instead, you keep complaining on the mailing list that somebody who submitted something you didn't like got the attention you think should have been rather given to you. That's your choice. Good luck! I'm discussing it. And attention not to me, but to issues (I just have one to be really concerned about, all other were already resolved.) -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On Sun, 2015-05-10 at 12:41 +0200, Szabó Gergely wrote: PS: how can I unsubscribe from the list? Guess what? ;-) Follow the link: ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel Enter your e-mail address at the bottom of this page, and click the button. -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On Sun, 2015-05-10 at 03:42 +0300, Mooffie wrote: (I already know some places where I'll get criticism. E.g., in places where I didn't wan't to refactor things in the old code (e.g., in src/filemanager/panel.c). Why didn't I? because I didn't think it was wise to refactor/modify old code before I first get an ok on the big picture.) Just to clarify, the fact that I'm excited about your work, think that it's amazing and don't want to bikeshed over Lua (which personally I don't like by the way, but at the same time I see no better practical choice, so let it be Lua!), doesn't mean that somebody else doesn't have a different opinion :-) Andrew seems to be genuinely interested, which is great, because he can do a proper review. How about Slava and Ilia, what are you guys thinking? Slava, would you be able to make time for a review? Egmont, would you be able to do as much? Formally you are not part of the core team, but then again, if Andrew ends up being alone to look at all this stuff, another pair of eyes would definitively be of help... -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Sun, 10 May 2015 10:49:40 +0200 Yury V. Zaytsev y...@shurup.com wrote: On Sun, 2015-05-10 at 03:42 +0300, Mooffie wrote: (I already know some places where I'll get criticism. E.g., in places where I didn't wan't to refactor things in the old code (e.g., in src/filemanager/panel.c). Why didn't I? because I didn't think it was wise to refactor/modify old code before I first get an ok on the big picture.) Just to clarify, the fact that I'm excited about your work, think that it's amazing and don't want to bikeshed over Lua (which personally I don't like by the way, but at the same time I see no better practical choice, so let it be Lua!), doesn't mean that somebody else doesn't have a different opinion :-) 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. Andrew seems to be genuinely interested, which is great, because he can do a proper review. How about Slava and Ilia, what are you guys thinking? Slava, would you be able to make time for a review? 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, to whose solution number of people contributed over these years, including Slava and Ilia themselves, and which are stuck with no review/response (not counting completely out of way, bureaucratic write-offs): http://www.midnight-commander.org/ticket/1652 https://github.com/MidnightCommander/mc/pull/49 Egmont, would you be able to do as much? Formally you are not part of the core team, but then again, if Andrew ends up being alone to look at all this stuff, another pair of eyes would definitively be of help... -- Sincerely yours, Yury V. Zaytsev -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Well, I'm not an MC developer, I've also unsubscribed from the mailing list long ago, but I still get all the emails. So please allow me to be your kind troll. On 2015-05-10 12:12, 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. Your alternative is obviously a working implementation in Micropython. Not? 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, to whose solution number of people contributed over these years, including Slava and Ilia themselves, and which are stuck with no review/response (not counting completely out of way, bureaucratic write-offs): http://www.midnight-commander.org/ticket/1652 https://github.com/MidnightCommander/mc/pull/49 I wish all my random hacks were this well documented... And if you asked me how to define an unimportant issue, I'd probably say, well, if it's been open for 5+ years, it's most definitely not important. My 2 agorot Gergely PS: how can I unsubscribe from the list? ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On 2015-05-10 Yury V. Zaytsev wrote: Just to clarify, the fact that I'm excited about your work, think that it's amazing and don't want to bikeshed over Lua (which personally I don't like by the way, but at the same time I see no better practical choice, so let it be Lua!), doesn't mean that somebody else doesn't have a different opinion :-) How about S-Lang? It is already used for the terminal stuff in mc. Morten ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On Sun, May 10, 2015 at 12:41 PM, Morten Bo Johansen m...@spamcop.net wrote: How about S-Lang? It is already used for the terminal stuff in mc. I think it would be a terrible choice. A language hardly anyone has even heard about, and whose library handling is hardly used by any project other than mc. It's been even proposed couple of times that mc should drop slang support and stick with the much more widespread ncurses. e. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On Sun, May 10, 2015 at 2:54 PM, Paul Sokolovsky pmis...@gmail.com wrote: ... and the conversation is focused around priority of things to do, which I argue should be fixing old bugs, then proceed with new things. Because is exciting new is the only thing you're after, then rewriting mc would be the best way to get a lot of that new and exciting. No project can ever realistically reach the there are no more bugs, so we can work on exciting new features state. E.g. on my other hobby project, where I've contributed much more work than to mc, I've fixed maybe about 100 bugs, yet the number of open tickets is higher than when I started. Not because I code in such a quality (sure I do make mistakes every now and then), but because new ones are discovered and new features are requested. And as you fix the most important ones, the bar goes lower and suddenly the previously less important ones become the most important now. It's a never ending story. Of course aiming for the other end is also terrible, the one where you don't care about bugs, yet wish to add tons of new features and keep aiming higher and higher. A reasonable balance needs to be found. mc has hardly received any new features recently (definitely nothing along the lines of scripting support), but has received many-many bugfixes. You can't say feature freeze until all bugs are fixed, probably bugs are discovered in a higher rate than fixed and we'd never get anywhere. A project needs to evolve, even when it's not bugfree. And also don't forget that plugin support would actually get us closer to fixing quite a few bugs. Your arguments make me feel that you're personally offended because your pet peeve bug didn't get fixed so far, and in turn you'd like to stop getting something new accepted, just because you'd do it differently. Well, do _it_ (not something else) the way you'd like to see it, and I'm sure we'll seriously consider accepting that. Until then, Mooffie's work is what we have, and I see no reason to put any obstacle to this. Just beacuse, oh my god, there's another bug that we could've fixed so far but we haven't... e. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hi Yury, Slava, what do you think? I know that you've been a proponent of the plugin system, but aren't you impressed with this demonstration? Yeah, I really impressed and I'll be happy to see the feature into our master branch. But, as Andrew said before, would be great to split one big commit to a set of smaller commits for better code review and to make bisect process much easily (of course, I hope that bisecting willn't be used, but who knows) . ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hi, I've briefly had a look at mc^2, and I have to say that I was really blown away by mooffie's work! I would be very happy if this can be integrated into the master branch (mooffie can fix my pet peeve, the gnome-terminal open directory thing in recent distros with just a few lines of code!). I feel that scripting is a vastly superior solution to the extensibility problem in the context of mc as compared to plugins. Of course, plugins have their uses, but they will require so much more effort to build and maintain, whereas scenarios for a scripting engine that exposes mc internals through a very thin layer are quick to write, easy to debug and need no compilation. Slava, what do you think? I know that you've been a proponent of the plugin system, but aren't you impressed with this demonstration? From the maintenance point of view, it would be great if most of the tickets asking for niceties could be implemented in a high level language outside of the core of mc, or maybe even in a longer term more non-essential features that are currently in the core could be offloaded to scripts, freeing up resources for important infrastructural projects like broken regexes. We could ship a default library of scripts with some active out of the box, and others requiring opt-in (symlink). Think of no more arguments about changing the gold default behavior, or adding more configuration options... In addition to that, we could make an official script repository with rather loose inclusion criteria (basically, script is maintained compatible with the latest version of mc, and maintainer demonstrates minimal amounts of sanity), which distro packagers could ship as a separate addon, like they do e.g. with bundles of vim plugins. Anyways, how do we move from there on? I'm afraid that personally I lack competence and time to do a proper code review to help the process :-( -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On Fri, 2015-05-08 at 19:33 +0300, Andrew Borodin wrote: It would be great if you split first huge commit of branch in several small commits. It will make the review easier. I couldn't resist and started looking at the code anyways, but quickly discovered that a large part of the diff is simply changes to the PO-files and such. It would be really of huge help, if the first commit would be split in a bunch of smaller commits with logically related changes, and the PO stuff definitively has to go into its own separate commit. -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On 5/8/15, Andrew Borodin aboro...@vmail.ru wrote: It would be great if you split first huge commit of branch in several small commits. It will make the review easier. I'll take notice of that. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On 5/9/15, Yury V. Zaytsev wrote: Anyways, how do we move from there on? I'll be doing two things: - I'll prepare a document explaining to reviewers the overall structure of the code and the modifications to existing files. - I'll look into porting the code to 4.8.14. The thing I'll appreciate from reviewers at this early stage is not to criticize the small things (e.g., coding style) but to look at the big picture. (I already know some places where I'll get criticism. E.g., in places where I didn't wan't to refactor things in the old code (e.g., in src/filemanager/panel.c). Why didn't I? because I didn't think it was wise to refactor/modify old code before I first get an ok on the big picture.) ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On Thu, May 7, 2015 at 11:53 PM, Paul Sokolovsky pmis...@gmail.com wrote: Hello, On Thu, 7 May 2015 23:27:23 +0200 Egmont Koblinger egm...@gmail.com wrote: Hi, Did you... er... did you just rewrite half of mc... adding plugins and stuff...?? It would be indeed cool to remove all that gnome-ish bloat accumulated by decades, but - what a disappointment - home page says that to accomplish such feat there is no need to modify MC’s main code.. Generally one good approach to deal with the situation would be to rewrite mc completely in a scripting language. Extra points for using language in which array indexing starts with e or pi, or going straight to Brainfuck. No, I'm ironic with the last sentence on Lua choice, but I really think the way out of the maze is rewriting mc from scratch, and then surely in a decent scripting language. I was obviously exaggerating when I said Mooffie rewrote half of mc's code. I haven't look at the changes to the C code yet, but as some comments on the homepage suggest, it's probably only a very small fraction of the C code he touched and mostly pretty lightweight changes. Have you ever seen a complete rewrite of a project (that's bigger than a few weeks of hacking) succeed? I have not. This would require at least 100x (but rather 1000x) the work Mooffie has probably already spent. There are no engineering resources for that. Recently I've spent about a week rewriting the viewer, probably noone else would've done it if I hadn't. There's a ticket to rewrite the vfs component, noone's working on that. Regex handling should be carefully cleaned up, noone's working on that. Tty handling is overly complicated, nobody's working on it. But you'd rewrite the whole project from scratch!? And then the rewrite would be missing tons of features because you were lazy to port them, would contain tons of brand new bugs or bugs that had been fixed long ago. It's pretty much guaranteed to be a big failure -- and easily not just a failure of the rewrite but also cause a(n even bigger) decline of the main project, as many times you recah a point where the old project is already considered obsolete and is unmaintained, in favor of the new one which stands on better technical grounds, yet is totally incomplete and lacks tons of things from the old one. Successful redesigns almost always happen in small steps, maintaining the usability and quality of the project throughout the steps. You might eventually replace nearly every component, and the road might eventually become longer than if you had rewrote from scratch, but it's viable because you get satisfied users and passionate developers all the way through, rather than just hacking on something that's not used by anyone; and it's viable because it's not risky: you can stop working on it anytime and leave positive benefits behind rather just having wasted tons of time. As for whether mc's core should be written in C or lua or whatever... compiled or interpreted, strict or loose types, whatever... My personal preference probably doesn't matter too much, yet I'd like to quietly mention that my last python project (port someone else's app against a new API) got stalled in a mostly working state where the parts I've tested work, yet the parts I haven't (because I don't know how to reach that code) probably still call the API using its old method names, wrong order of parameters, and nobody tells me this. Had it been written in a compiled language, the compiler probably would have helped me do a complete port in the same amount of time. As for the plugin API: If you write the core of mc in whichever scripting language and allow a plugin to hook up against _any_ of its methods/variables then you discard the very basic principle that caused all programming language to move at least slightly towards object-oriented approach. If you allow a plugin to do anything, it becomes a nightmare where you can no longer perform internal refactorings because you don't know how many 3rd party plugins you'd break, or by seeing breakages 3rd party plugin authors would back off from the project. On the other hand, if you define a clear API that plugins code against, then it's not really relevant anymore whether the core and the plugins are written in the same programming language or not. Now, I don't know anything about lua, but allegedly it's really good for this kind of plugin stuff, writing hooks to a C code. But let's put all this question aside. We might be arguing for years what would be the best language for mc core and what would be the best language for the plugins, and it'd take us nowhere. The most important factor in the decision should be what we already have. We can't reimplement 20 years of work in mc core. We might reimplement Mooffie's lua code in python/ruby/whatever but apart from spending weeks on it, would it make it any better? The biggest value is that we already do have a decent mc written in C, and
Re: [ANN] mc^2
Hi, How much work would it be to port your branch to 4.8.14 or git head (they're pretty much the same now)? I'd really like to use your version for daily work (and maybe even start writing plugins) to gather feedback. On the other hand, mc-4.8.14 contains some of my work that I really wouldn't want to live without. And of course I wouldn't want to switch back-n-forth between two versions either. Thanks a lot, egmont On Thu, May 7, 2015 at 10:23 PM, Mooffie moof...@gmail.com wrote: Hi guys! I've just published a branch of MC with Lua support: http://www.typo.co.il/~mooffie/mc-lua/docs/html/ See the screenshots link. Also see the other documents link for background (especially HISTORY). Many, many tickets can be solved with mc^2, but I don't want to spam the ticket queue with my posts, so I've prepared a list of some such tickets (see other documents - TICKETS). (But in a few tickets I *will* comment: in tickets I believe a constructive discussion could ensue, or where I feel people are truly in need of a solution.) == Now, I guess I'll be attacked for one reason or another. Let me save your time by attacking myself for you: == Q: Is this a 'fork' of MC? Are you trying to split the community? A: No, this is not a fork (as per Wikipedia's definition). It's intended to be food for thought for the MC community. My hope is that eventually the principle behind mc^2 will be adopted by MC. == Q: Is seems that you've invested a lot of time in this. Gosh, why waste human resources?! Especially on something that nobody's going to use? A: The time I waste here is negligible in comparison to the time and efforts wasted by tens of people who have tried to contribute code to MC over the years. The principle behind mc^2, if adopted by MC, is going to put an end to this waste of human resources. == Q: But why use Lua?!?! Why not pick the language that starts with 'P'?! Why not make it work with any language?!??! A: Let's not talk about languages/VMs *right now*. Please, as much as it's tempting. Right now, the language is not the issue. The issue is the principle, of having some extension language. The language/VM is obviously something everybody will have something to say about. You will. But not now. If every passerby here will now emit his 2 cents opinion/rant, it will kill the vision/project. It will start a Holy War. It will derail the discussion from the mainroad to the gutters. It's the least constructive thing that could happen. It means death. In the future, when we know the principle will be regarded favorably by MC's maintainers, we could open this issue and discuss things. One thing's for sure: You can't give an opinion about the subject without considering it for at least a week (or a month, I'd say). There are various facets to consider. There are threads of thoughts to be picked and discarded. There are insights to be acquired. You can't just barge in with use Python!!, use Parrot!, use GObject!. As the Chinese saying goes, Opinions are like belly buttons: everybody has one. It should take more, much more, than an opinion to affect the discussion. So, again: let's not talk about languages now. (For the record: I recorded my reasons for choosing Lua in other documents - HISTORY.) ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On Fri, 8 May 2015 15:05:33 +0300 Mooffie wrote: On 5/8/15, Egmont Koblinger wrote: How much work would it be to port your branch to 4.8.14 or git head (they're pretty much the same now)? Probably very little work. I'll do that sometime soon, I hope. It would be great if you split first huge commit of branch in several small commits. It will make the review easier. Thanks! -- A. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On 5/8/15, Egmont Koblinger egm...@gmail.com wrote: [...] a complete rewrite [...] would require at least 100x (but rather 1000x) the work Mooffie has probably already spent. There are no engineering resources for that. [...] Successful redesigns almost always happen in small steps, maintaining the usability and quality of the project throughout the steps. [...] Egmont, Thanks for composing this excellent reply. I actually composed one myself (a much, much shorter one) before going on-line. I combed it to see what I could salvage out of it but I see that you've got all the main points. Now, mc^2 isn't perfect. API in a scripting language poses many challenges (which you mentioned, and Szabó Gergely too). These are certainly issues we'll have to think about. It's certainly possible that people will conclude that mc^2 in its present form is garbage, but at least it provides us with a path we can work on. did you just rewrite half of mc No, it's not a rewrite. (That's the short answer. The sources (under the 'src/lua' tree) seem big at first glance, but that's mainly because they have documentation embedded in them. There are files with just 10% of actual code.) ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
On 5/8/15, Egmont Koblinger wrote: How much work would it be to port your branch to 4.8.14 or git head (they're pretty much the same now)? Probably very little work. I'll do that sometime soon, I hope. ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hi, Did you... er... did you just rewrite half of mc... adding plugins and stuff...?? At this moment all I can say is: WOW! e. On Thu, May 7, 2015 at 10:23 PM, Mooffie moof...@gmail.com wrote: Hi guys! I've just published a branch of MC with Lua support: http://www.typo.co.il/~mooffie/mc-lua/docs/html/ See the screenshots link. Also see the other documents link for background (especially HISTORY). Many, many tickets can be solved with mc^2, but I don't want to spam the ticket queue with my posts, so I've prepared a list of some such tickets (see other documents - TICKETS). (But in a few tickets I *will* comment: in tickets I believe a constructive discussion could ensue, or where I feel people are truly in need of a solution.) == Now, I guess I'll be attacked for one reason or another. Let me save your time by attacking myself for you: == Q: Is this a 'fork' of MC? Are you trying to split the community? A: No, this is not a fork (as per Wikipedia's definition). It's intended to be food for thought for the MC community. My hope is that eventually the principle behind mc^2 will be adopted by MC. == Q: Is seems that you've invested a lot of time in this. Gosh, why waste human resources?! Especially on something that nobody's going to use? A: The time I waste here is negligible in comparison to the time and efforts wasted by tens of people who have tried to contribute code to MC over the years. The principle behind mc^2, if adopted by MC, is going to put an end to this waste of human resources. == Q: But why use Lua?!?! Why not pick the language that starts with 'P'?! Why not make it work with any language?!??! A: Let's not talk about languages/VMs *right now*. Please, as much as it's tempting. Right now, the language is not the issue. The issue is the principle, of having some extension language. The language/VM is obviously something everybody will have something to say about. You will. But not now. If every passerby here will now emit his 2 cents opinion/rant, it will kill the vision/project. It will start a Holy War. It will derail the discussion from the mainroad to the gutters. It's the least constructive thing that could happen. It means death. In the future, when we know the principle will be regarded favorably by MC's maintainers, we could open this issue and discuss things. One thing's for sure: You can't give an opinion about the subject without considering it for at least a week (or a month, I'd say). There are various facets to consider. There are threads of thoughts to be picked and discarded. There are insights to be acquired. You can't just barge in with use Python!!, use Parrot!, use GObject!. As the Chinese saying goes, Opinions are like belly buttons: everybody has one. It should take more, much more, than an opinion to affect the discussion. So, again: let's not talk about languages now. (For the record: I recorded my reasons for choosing Lua in other documents - HISTORY.) ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
[ANN] mc^2
Hi guys! I've just published a branch of MC with Lua support: http://www.typo.co.il/~mooffie/mc-lua/docs/html/ See the screenshots link. Also see the other documents link for background (especially HISTORY). Many, many tickets can be solved with mc^2, but I don't want to spam the ticket queue with my posts, so I've prepared a list of some such tickets (see other documents - TICKETS). (But in a few tickets I *will* comment: in tickets I believe a constructive discussion could ensue, or where I feel people are truly in need of a solution.) == Now, I guess I'll be attacked for one reason or another. Let me save your time by attacking myself for you: == Q: Is this a 'fork' of MC? Are you trying to split the community? A: No, this is not a fork (as per Wikipedia's definition). It's intended to be food for thought for the MC community. My hope is that eventually the principle behind mc^2 will be adopted by MC. == Q: Is seems that you've invested a lot of time in this. Gosh, why waste human resources?! Especially on something that nobody's going to use? A: The time I waste here is negligible in comparison to the time and efforts wasted by tens of people who have tried to contribute code to MC over the years. The principle behind mc^2, if adopted by MC, is going to put an end to this waste of human resources. == Q: But why use Lua?!?! Why not pick the language that starts with 'P'?! Why not make it work with any language?!??! A: Let's not talk about languages/VMs *right now*. Please, as much as it's tempting. Right now, the language is not the issue. The issue is the principle, of having some extension language. The language/VM is obviously something everybody will have something to say about. You will. But not now. If every passerby here will now emit his 2 cents opinion/rant, it will kill the vision/project. It will start a Holy War. It will derail the discussion from the mainroad to the gutters. It's the least constructive thing that could happen. It means death. In the future, when we know the principle will be regarded favorably by MC's maintainers, we could open this issue and discuss things. One thing's for sure: You can't give an opinion about the subject without considering it for at least a week (or a month, I'd say). There are various facets to consider. There are threads of thoughts to be picked and discarded. There are insights to be acquired. You can't just barge in with use Python!!, use Parrot!, use GObject!. As the Chinese saying goes, Opinions are like belly buttons: everybody has one. It should take more, much more, than an opinion to affect the discussion. So, again: let's not talk about languages now. (For the record: I recorded my reasons for choosing Lua in other documents - HISTORY.) ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: [ANN] mc^2
Hello, On Thu, 7 May 2015 23:27:23 +0200 Egmont Koblinger egm...@gmail.com wrote: Hi, Did you... er... did you just rewrite half of mc... adding plugins and stuff...?? It would be indeed cool to remove all that gnome-ish bloat accumulated by decades, but - what a disappointment - home page says that to accomplish such feat there is no need to modify MC’s main code.. Generally one good approach to deal with the situation would be to rewrite mc completely in a scripting language. Extra points for using language in which array indexing starts with e or pi, or going straight to Brainfuck. No, I'm ironic with the last sentence on Lua choice, but I really think the way out of the maze is rewriting mc from scratch, and then surely in a decent scripting language. At this moment all I can say is: WOW! e. On Thu, May 7, 2015 at 10:23 PM, Mooffie moof...@gmail.com wrote: Hi guys! I've just published a branch of MC with Lua support: http://www.typo.co.il/~mooffie/mc-lua/docs/html/ See the screenshots link. Also see the other documents link for background (especially HISTORY). Many, many tickets can be solved with mc^2, but I don't want to spam the ticket queue with my posts, so I've prepared a list of some such tickets (see other documents - TICKETS). (But in a few tickets I *will* comment: in tickets I believe a constructive discussion could ensue, or where I feel people are truly in need of a solution.) == Now, I guess I'll be attacked for one reason or another. Let me save your time by attacking myself for you: == Q: Is this a 'fork' of MC? Are you trying to split the community? A: No, this is not a fork (as per Wikipedia's definition). It's intended to be food for thought for the MC community. My hope is that eventually the principle behind mc^2 will be adopted by MC. == Q: Is seems that you've invested a lot of time in this. Gosh, why waste human resources?! Especially on something that nobody's going to use? A: The time I waste here is negligible in comparison to the time and efforts wasted by tens of people who have tried to contribute code to MC over the years. The principle behind mc^2, if adopted by MC, is going to put an end to this waste of human resources. == Q: But why use Lua?!?! Why not pick the language that starts with 'P'?! Why not make it work with any language?!??! A: Let's not talk about languages/VMs *right now*. Please, as much as it's tempting. Right now, the language is not the issue. The issue is the principle, of having some extension language. The language/VM is obviously something everybody will have something to say about. You will. But not now. If every passerby here will now emit his 2 cents opinion/rant, it will kill the vision/project. It will start a Holy War. It will derail the discussion from the mainroad to the gutters. It's the least constructive thing that could happen. It means death. In the future, when we know the principle will be regarded favorably by MC's maintainers, we could open this issue and discuss things. One thing's for sure: You can't give an opinion about the subject without considering it for at least a week (or a month, I'd say). There are various facets to consider. There are threads of thoughts to be picked and discarded. There are insights to be acquired. You can't just barge in with use Python!!, use Parrot!, use GObject!. As the Chinese saying goes, Opinions are like belly buttons: everybody has one. It should take more, much more, than an opinion to affect the discussion. So, again: let's not talk about languages now. (For the record: I recorded my reasons for choosing Lua in other documents - HISTORY.) ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel -- Best regards, Paul mailto:pmis...@gmail.com ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
