Re: leftover branches ?
On Mon, 13 Sep 2010 00:09:08 +0200 Enrico Weigelt wrote: there seem to be some old leftover branches: 1823_prev_line_def Ticket is not closed yet. 1897_libc_return_values Removed. should they get removed ? And now my questions to you: 1775_mvfs_9P 1775_mvfs_9P_2 1775_mvfs_9P_3 DEV_mvfs_fish DEV_mvfs_local METUX.mvfs WTF? Why you created a lot of branches about your mvfs stuff??? MC dev team doesn't have any plans to use this unknown library. Please remove that branches yourself and please don't push any mvfs-related code to the mc repo. Else your write access to the mc repo will be disabled. If you develop the mc fork, please don't that in official mc server. That's nonsense. Thanks. -- Andrew ___ mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: leftover branches ?
* Andrew Borodin aboro...@vmail.ru schrieb: And now my questions to you: 1775_mvfs_9P 1775_mvfs_9P_2 1775_mvfs_9P_3 DEV_mvfs_fish DEV_mvfs_local METUX.mvfs Work in progress. I'll assign it to proper ticket when it passed test cycles. WTF? Why you created a lot of branches about your mvfs stuff??? Just continued the work I started about 1.5 years ago. MC dev team doesn't have any plans to use this unknown library. Did you do any one vote on that or do you now rule alone here ? Please remove that branches yourself and please don't push any mvfs-related code to the mc repo. Else your write access to the mc repo will be disabled. Are you sure you're officially authorized to impose those threats ? Did you check back with the guy who sponsors the infrastructure ? And do you think this is an appropriate reward for one of the people who practically revived mc from death ? If you develop the mc fork, please don't that in official mc server. In case you still didn't notice: the mvfs stuff was meant for upstream on day one. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: leftover branches ?
On Mon, 13 Sep 2010 08:47:30 +0200 Enrico Weigelt wrote: 1775_mvfs_9P 1775_mvfs_9P_2 1775_mvfs_9P_3 DEV_mvfs_fish DEV_mvfs_local METUX.mvfs Work in progress. I'll assign it to proper ticket when it passed test cycles. Do you really need these tons of branches for one task? MC dev team doesn't have any plans to use this unknown library. Did you do any one vote on that or do you now rule alone here ? We discussed about that in Jabber room and in this list. Please remove that branches yourself and please don't push any mvfs-related code to the mc repo. Else your write access to the mc repo will be disabled. Are you sure you're officially authorized to impose those threats ? I'm one of current MC developers. Did you check back with the guy who sponsors the infrastructure ? Are you one of that sponsors? And do you think this is an appropriate reward for one of the people who practically revived mc from death ? And who are that people? If you develop the mc fork, please don't that in official mc server. In case you still didn't notice: the mvfs stuff was meant for upstream on day one. Really? -- Andrew ___ mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Lazy behavior in Extfs
Hi Guys, First of all I want to congratulate you for the excellent piece of software you develop. I use it all the time. I'm in the process of creating a custom extfs for a special file type, and I was researching in the existing scripts to get some examples. I was able to start doing some listings. But then I figured out that for all scripts mc calls them just once and they provide the full content for the entire file, and it seems mc parses the list using the / so it knows all the structure and it never invokes the script again. It is acceptable for small to medium size files or files without a big depth, but it is not for big files containing a very deep structure. So I was wandering if it is possible for mc to fetch content from extfs script in a lazy way. The first time I return the list at the root level, then when mc wants to enter in some of the entries it hits the script again with the file path plus the relative internal path. This way only the needed part of the file is loaded. Is it possible some way? otherwise I should desist of using MC for this purpose :-( which should be a shame Thank you so much in advance. Gaston. ___ mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Lazy behavior in Extfs
Hi! On Mon, 2010-09-13 at 13:06 -0300, Gastón Tonietti wrote: So I was wandering if it is possible for mc to fetch content from extfs script in a lazy way. The first time I return the list at the root level, then when mc wants to enter in some of the entries it hits the script again with the file path plus the relative internal path. This way only the needed part of the file is loaded. I am not sure whether it's indeed possible with extfs, but for sure it is possible if you implement your protocol as a VFS module. -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Lazy behavior in Extfs
Nice. It should be very useful to handle it this way. Is there any issue for tracking this improvement or we should open a new one? On Mon, Sep 13, 2010 at 7:06 PM, Enrico Weigelt weig...@metux.de wrote: * Gastón Tonietti gaston.tonie...@gmail.com schrieb: I'm in the process of creating a custom extfs for a special file type, and I was researching in the existing scripts to get some examples. I was able to start doing some listings. But then I figured out that for all scripts mc calls them just once and they provide the full content for the entire file, and it seems mc parses the list using the / so it knows all the structure and it never invokes the script again. That's IMHO a generic design problem in extfs, as it handles only whole archives. This also tends to cause trouble if the archive changes w/o extfs noticing it (I often have this case w/ patchfiles). A clean solution, IMHO would be putting these things into little fileservers, which directly provide the filesystem operations and internally do whatever's optimal for the actual archive type. (doing this as separate fileservers, eg. via 9P, instead of extending mc-vfs, allows them to be independent from mc itself and usable w/o it.) Actually I need to do some heavy initialization stuff when opening the archive, and suppose the laziness issues for Extfs is solved, the initialization stuff will be done many times, each time MC hits the script with different internal path. The desired behavior should be to work with a single instance of the *service* for the given archive and keep it during all the MC session. This way all initialization work is done just once, the ideal scenario for LAZY processing. Also the *service* could listen for external changes made to the archive and ask MC for a refresh some way. Gaston. So I was wandering if it is possible for mc to fetch content from extfs script in a lazy way. The first time I return the list at the root level, then when mc wants to enter in some of the entries it hits the script again with the file path plus the relative internal path. This way only the needed part of the file is loaded. This would change semantics of the extfs interface, actually making these scripts little fileservers, in this case non-persistent ones (a bit like an kind of nfs or dav via command line ;-)). cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel ___ mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
