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
