Re: Further Midnight Commander development
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Enrico Weigelt wrote:
* Slava Zanko slavaza...@gmail.com schrieb:
Hi,
huh, I'm not sure whether mvc fits in here.
mcvfs - VIEW; core (signal handling, User events etc) - CONTROLLER,
slang,mcslang,ncurses - VIEWs.. Why not? :)
you meant: mcvfs = model ?
No. model = any data source. mcvfs - one of sources for mc.
I think, it is very early to discuss. We need to start their work,
rather than drown in the discussions. :)
Well, if we say everything's a file and the model is the vfs
(including things like search results represented as filesystem),
we could make some steps in this direction :)
Yep, everything is a file. Network connects - files too. :)
yeah, even sockets:
cat tcp://somehost:port/
(I'll add this to libmvfs in the next days ...)
Cool. I'm waiting now this patch. :)
For example:
$ cat ~/secret/path/to/my-one-of-many-many-server.mcvfs-ftp
host: xxx.xxx.xx
port: 12345
user:
passwd:
passv: 1
...
By pressing 'Enter' to the *.mcvfs-ftp file (via mc.ext) ftp session
will establish... Is this bad think?
hmm, you suggest something like we know as desktop shortcuts from
May be yes, shorcuts...
certain certain DE's ? Well, perhaps it would be even better to just
directly support well-known DE's shortcut files ?
But if file will open by DE, mc don't handle data from 'shorcut'. If mc
open 'shotcut' itself, then for example, pressing 'Enter' on *.mcvfs-ftp
will display in active panel of mc content of remote ftp-server ('cat
*.mcvfs-ftp' may be display content too ;) )
Treat all 'shorcuts' makes no sense - it's set up through mc.ext if
needed. I am talking about support in the file mc.ext like this, for
example:
shell/.mcvfs-ftp
Open=mcvfs:ftp
shell/.mcvfs-dav
Open=mcvfs:dav
shell/.mcvfs-ssh
Open=mcvfs:ssh
Or simular.
But it is very early to discuss too, IMHO. We can dream now, but a
little... ;)
snip
some bash support fixups
(http://mail.gnome.org/archives/mc-devel/2008-December/msg00062.html)
Patch already applied, but not in official branch - in our mc-4.6.3 :)
Patches from our branch will transfer to an oficial branch.
What happened to 4.6.2 ?
There mc-4.6.3 - is a invalid version (Russian fork). As right, we had
to change name (mc+, for example). Sorry. :(
BTW, after applying all gathehing patches, we can assign version
4.7.0-pre1 ;)
Because a lot of changes compared to the current 4.6.2-pre1...
hmm, what major changes do you have in mind ?
First, may will be add UTF-8 support; may will be apply other patches,
stabilized in various distributions.
Second, there mc-4.6.3... people will be at a loss :(
WBR, Slavaz.
P.S. To all: With the passing Christmas :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFJWNYnb3oGR6aVLpoRAkYbAJ9x9fXYQNjdJqk7ZzgbvPSKKL3cIACfcHEh
mJ4Y9JQvD7ZImKp1Jw3Tg3g=
=OHVX
-END PGP SIGNATURE-
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Further Midnight Commander development
Hellom IMHO we should start with the latest stable release (4.6.1 ?) and apply all the vendor/distro patches floating around step by step (*1). Once that's done, we should make a new official release very soon. I agree with this approach, we should start by reviewing those patches as well, as not every distro patch in packages is suitable for upstream inclusion. I suggest that the patches are posted to the list, in a way similar to other projects so the patches can be peer-reviewed and discussed before they go into the tree. Miguel ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] segfault-on-invalid-mtime fix
Hello, This patch looks good, but there are two uses of strftime as well, it might make sense to wrap the use of strftime in a new routine that always make this check (when localtime returns NULL). mc-4.6.1/src/util.c ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] some bash support fixups
Hello, This patch looks pretty dubious, specially considering that MC is used on system other than latest Linux distro with the latest bash. Do we have more information as to what this patch is trying to fix? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] ebuild syntax file
This patch looks like an extension, it looks harmless and should go into the tree. http://patches.metux.de/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] cons.saver: non-blocking console
Hello, Opening the console in non-blocking mode is a bad idea, as it means that every call that is done later on the console_fd needs to check for EWOULDBLOCK. Most of the time, it would be not return that, it would only return that under unique situations which means that testing this patch would not only be non-trivial, but someone would have to audit all the code paths. Also, this is lacking a ChangeLog explaining why this is needed. But I think that this patch should not be applied, it seems like a workaround that has not been properly implemented. Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] find file fixups
This patch looks OK to go in. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] largefile fixups
This patch looks OK to go in. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: HAVE_MMAP still necessary ?
a) cmd.c: compare_files() - it uses the mmap() call directly (w/o going over mcvfs), and it seems to work on local files only. wouldn't it make sense to let it run via mcvfs ? b) view.c: it tries to mmap() in the file, obviously to let the kernel do all the loading. BUT: do we *really* want mmap() here, or just some get me that file into memory()-call (same in cmd.c) ? mmap is more efficient, because the kernel can throw those pages out at any time (as it knows what the backing store for the file is), so under memory pressure it can alleviate the system load easily. Loading the file ourselves means that we load it into dirty pages, effectively taking memory, and forcing the kernel to write the data to swap under load, or to keep the data in memory even when not needed. I do not like the idea of dropping mmap. In case we just want to have an faster way for loading files into memory (in case it's supported), I suggest some new vfs operation for that, let's call it loadFile() - it returns some FILE_DATA structure, containing size, buffer ptr and a callback vector for free'ing. Everyone who wants the whole file (or large blocks) just uses this call instead of ugly #ifdef's, and it's up to vfs to decide what to do behind the scenes. You are trying to invent a bloated replacement for something that the kernel can do really well. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Further Midnight Commander development
On Mon, Dec 29, 2008 at 12:33:44PM -0500, Miguel de Icaza wrote: Hellom IMHO we should start with the latest stable release (4.6.1 ?) and apply all the vendor/distro patches floating around step by step (*1). Once that's done, we should make a new official release very soon. I agree with this approach, we should start by reviewing those patches as well, as not every distro patch in packages is suitable for upstream inclusion. I suggest that the patches are posted to the list, in a way similar to other projects so the patches can be peer-reviewed and discussed before they go into the tree. Miguel +1 -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: HAVE_MMAP still necessary ?
* Miguel de Icaza mig...@novell.com schrieb: Hi, mmap is more efficient, because the kernel can throw those pages out at any time (as it knows what the backing store for the file is), so under memory pressure it can alleviate the system load easily. Absolutely right, but we have to keep in mind, that it's only supported on some filesystems (not even all local ones). So we need some clean way to handle it. The current implementation is quite unclean, sometimes called mcvfs's mmap, sometimes the libc's one. That should really be cleaned up. In case we just want to have an faster way for loading files into memory (in case it's supported), I suggest some new vfs operation for that, let's call it loadFile() - it returns some FILE_DATA structure, containing size, buffer ptr and a callback vector for free'ing. Everyone who wants the whole file (or large blocks) just uses this call instead of ugly #ifdef's, and it's up to vfs to decide what to do behind the scenes. You are trying to invent a bloated replacement for something that the kernel can do really well. My point being, we probably don't really want to have mmap itself, but an efficient way for getting some file (or large parts of it) into memory - that's a totally different requirement, and using mmap() is just one way to do it (if supported by the underlying fs). For the (mcfs-)clients this is an additional logic, which should be hidden behind the scenes - the individual fs should know best what to do, once we've introduced an appropriate API call. BTW: some fs'es (on certain platforms) might find a more clever way, even if mmap() isn't directly supported (eg. emulating it in userspace ;-P) - we really should leave this to the fs. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] ebuild syntax file
* Miguel de Icaza mig...@novell.com schrieb: This patch looks like an extension, it looks harmless and should go into the tree. ACK. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
RFC: Workflow for stable branch patches
Hi folks, just a little suggestion for the workflow of committing patches to the stable tree: * new patches are sent to the list ([PATCH]-prefix) for discussion * if there are no more objections left, they get committed * after commit, the stable tree maintainer drops a note in the appropriate thread I personally always keep the last message of each patch-thread in my mailbox, until it's committed, for better tracking (IMHO better than always having to look at the tracker ;-P). cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Further Midnight Commander development
* Roland Illig roland.il...@gmx.de schrieb: Hi, I'd like to. If there is some more action in mc development (like in 2005, when it was great fun), I'm definitely willing to invest some time into it. :) Maybe we even get all the different UTF-8 patches incorporated into mc. If that's possible without #ifdef's in each and every file, I'd like to work on it. Great :) Perhaps, if you've already have an trac account, we could assign all utf8-related bugs to you. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
autoconf warnings (AC_AIX, ...)
Hi folks, while regenerating the autoconf files, I get bunch of warnings: (but ./configure is created nevertheless) configure.ac:105: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS ../../lib/autoconf/specific.m4:389: AC_USE_SYSTEM_EXTENSIONS is expanded from... aclocal.m4:2977: gl_LOCK_EARLY_BODY is expanded from... aclocal.m4:2970: gl_LOCK_EARLY is expanded from... aclocal.m4:3201: gl_LOCK is expanded from... aclocal.m4:1639: gt_INTL_SUBDIR_CORE is expanded from... aclocal.m4:1478: AM_INTL_SUBDIR is expanded from... aclocal.m4:451: AM_GNU_GETTEXT is expanded from... configure.ac:105: the top level configure.ac:105: warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS configure.ac:105: warning: AC_COMPILE_IFELSE was called before AC_GNU_SOURCE ../../lib/autoconf/specific.m4:331: AC_GNU_SOURCE is expanded from... configure.ac:105: warning: AC_RUN_IFELSE was called before AC_GNU_SOURCE A little research on the net showed up that it might have something to do w/ target-specific macros like AC_AIX or AC_MINIX, AC_GNU_SOURCE, which are now obsolete, instead it's suggest to use AC_USE_SYSTEM_EXTENSIONS http://www.archivum.info/autoconf-patc...@gnu.org/2008-08/msg00015.html Actually, replacing AC_AIX and AC_MINIX by AC_USE_SYSTEM_EXTENSIONS in configure.ac makes the warning go away. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] segfault-on-invalid-mtime fix
* Miguel de Icaza mig...@novell.com schrieb: Hi, This patch looks good, but there are two uses of strftime as well, it might make sense to wrap the use of strftime in a new routine that always make this check (when localtime returns NULL). I'm working on that. BTW: we've got some situations where precense of strftime() is checked (HAVE_STRFTIME) and fallback to ctime(), and some where it is NOT. Should we always do the #ifdef or completely drop the fallback ? cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[PATCH] some time formatting fixes
Hi folks,
this patch goes a bit deeper into the strftime()+localtime() issue.
a) introduce some new shortcut macros and use them in some places
b) adds additional checks (where the macros dont fit)
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
cellphone: +49 174 7066481 email: i...@metux.de skype: nekrad666
--
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
#
# Adds an safe(r) strftime()/localtime() handling, as replacement
# for the mc-4.6.1-invalid-mtime.diff patch
#
# Source: metux
# Reference:4.6.1
# Submit-By:Enrico Weigelt, metux IT service weig...@metux.de
# Submit-Date: 2008-12-30
# Obsoletes:mc-4.6.1-invalid-mtime.diff
#
diff -ruN mc-4.6.1.orig/edit/edit.c mc-4.6.1/edit/edit.c
--- mc-4.6.1.orig/edit/edit.c 2008-12-30 01:52:56.0 +0100
+++ mc-4.6.1/edit/edit.c2008-12-30 01:53:41.0 +0100
@@ -29,6 +29,7 @@
#include ../src/cmd.h/* view_other_cmd() */
#include ../src/user.h /* user_menu_cmd() */
#include ../src/wtools.h /* query_dialog() */
+#include ../src/timefmt.h/* time formatting */
/*
what editor are we going to emulate? one of EDIT_KEY_EMULATION_NORMAL
@@ -2512,20 +2513,13 @@
break;
case CK_Date:{
- time_t t;
-#ifdef HAVE_STRFTIME
char s[1024];
/* fool gcc to prevent a Y2K warning */
char time_format[] = _c;
time_format[0] = '%';
-#endif
- time (t);
-#ifdef HAVE_STRFTIME
- strftime (s, sizeof (s), time_format, localtime (t));
+
+ FMT_LOCALTIME_CURRENT(s, sizeof(s), time_format);
edit_print_string (edit, s);
-#else
- edit_print_string (edit, ctime (t));
-#endif
edit-force |= REDRAW_PAGE;
break;
}
diff -ruN mc-4.6.1.orig/src/Makefile.am mc-4.6.1/src/Makefile.am
--- mc-4.6.1.orig/src/Makefile.am 2008-12-30 01:52:56.0 +0100
+++ mc-4.6.1/src/Makefile.am2008-12-30 01:53:41.0 +0100
@@ -57,9 +57,9 @@
popt.c poptconfig.c popt.h popthelp.c poptint.h poptparse.c \
profile.c profile.h regex.c rxvt.c screen.c setup.c setup.h \
slint.c subshell.c subshell.h textconf.c textconf.h \
- tree.c tree.h treestore.c treestore.h tty.h user.c user.h \
- util.c util.h utilunix.c view.c view.h vfsdummy.h widget.c \
- widget.h win.c win.h wtools.c wtools.h \
+ tree.c tree.h treestore.c treestore.h timefmt.h tty.h user.c\
+ user.h util.c util.h utilunix.c view.c view.h vfsdummy.h\
+ widget.c widget.h win.c win.h wtools.c wtools.h \
x11conn.h x11conn.c
if CHARSET
diff -ruN mc-4.6.1.orig/src/timefmt.h mc-4.6.1/src/timefmt.h
--- mc-4.6.1.orig/src/timefmt.h 1970-01-01 01:00:00.0 +0100
+++ mc-4.6.1/src/timefmt.h 2008-12-30 01:53:41.0 +0100
@@ -0,0 +1,43 @@
+#ifndef __UTIL_TIMEFMT_H
+#define __UTIL_TIMEFMT_H
+
+#include sys/types.h
+
+#define INVALID_TIME_TEXT (invalid)
+
+#ifdef HAVE_STRFTIME
+
+/* safe localtime formatting - strftime()-using version */
+#define FMT_LOCALTIME(buffer, bufsize, fmt, when) \
+{ \
+ struct tm *whentm; \
+ whentm = localtime(when); \
+ if (whentm == NULL) \
+ { \
+ strncpy(buffer, INVALID_TIME_TEXT, bufsize);\
+ buffer[bufsize-1] = 0; \
+ } \
+ else\
+ { \
+ strftime(buffer, bufsize, fmt, whentm); \
+ } \
+} \
+
+#else
+
+/* fallback when strftime/localtime not available */
+#define FMT_LOCALTIME(buffer,bufsize,fmt,when) \
+{ \
+ ctime_r(when,buffer); \
+} \
+
+#endif
+
+#define FMT_LOCALTIME_CURRENT(buffer, bufsize, fmt)\
+{ \
+ time_t __current_time; \
+ time(__current_time);
[PATCH] Fix autoconf warnings on AC_AIX/AC_MINIX
-- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: i...@metux.de skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- # # This patch replaces the calls to obsolete the macros AC_AIX and AC_MINIX # by AC_USE_SYSTEM_EXTENSIONS - makes certain autoconf warnings go away. # # Reference:mc-4.6.1 # Submit-By:Enrico Weigelt, metux IT service weig...@metux.de # Submit-Date: 2008-12-30 # State:new # diff -ruN mc-4.6.1.orig/configure.ac mc-4.6.1/configure.ac --- mc-4.6.1.orig/configure.ac 2008-12-30 01:52:56.0 +0100 +++ mc-4.6.1/configure.ac 2008-12-30 02:12:39.0 +0100 @@ -13,8 +13,7 @@ AC_CANONICAL_HOST -AC_AIX -AC_MINIX +AC_USE_SYSTEM_EXTENSIONS AC_ISC_POSIX AC_PROG_CC_STDC ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
