Refactoring no-vfs

[metux]

Building w/o VFS seems quite a bit broken now.
Refactoring it, eg. moving stuff from src/vfsdummy.h into vfs/vfs.h and get rid of some #ifdef VFS

[andrew_b]

vfs/vfs.h

223	    p = strdup (p); 

254	#endif                          /* MC_VFSDUMMY_H */

Please fix that.

And use g_strdup() instead of strdup() and g_snprintf() instead of snprintf().

[metux]

In which way is g_strdup()/g_snprint() better than strdup()/snprintf(), despite being slower ?

[andrew_b]

Actually, in most cases (99%) that glib functions are used in MC.

[metux]

That doesnt change the fact, that these two functions are nothing but slow wrappers, without any technical benetif it that case.

Just look at the source:
g_snprintf() calls g_vsnprintf() calls vsnprintf()

Calling snprintf() is the direct way. And a clever compiler can
optimize much more (eg. inlining statically predictable cases).

[andrew_b]

Just look at glibc source. You'll see the same way.

[andrew_b]

Replying to metux:

That doesnt change the fact, that these two functions are nothing but slow wrappers,

OK, let's compare:

#include <stdio.h>
#include <sys/types.h>

int
main (int argc, char *argv[])
{
 size_t i, j;
 char buf[32];

 for (i = 0; i < 10000; i++)
     for (j = 0; j < 10000; j++)
         snprintf (buf, sizeof (buf), "%ll", i + j);

 return 0;
}

/* Result:
   $ time ./test-snprintf
   9.50user 0.00system 0:09.51elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
   0inputs+0outputs (0major+114minor)pagefaults 0swaps
*/

#include <sys/types.h>
#include <glib.h>

int
main (int argc, char *argv[])
{
 size_t i, j;
 char buf[32];

 for (i = 0; i < 10000; i++)
     for (j = 0; j < 10000; j++)
         g_snprintf (buf, sizeof (buf), "%ll", i + j);

 return 0;
}

/* Result:
   $ time ./test-gsnprintf
   10.14user 0.00system 0:10.15elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
   0inputs+0outputs (0major+137minor)pagefaults 0swaps
*/

Tested on Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz

Yes, slower by 0.6 s for 100,000,000 iterations. Is it too much for you?

[andrew_b]

Enrico, you stubbornly replace glib functions. I don't thing that you will give any votes for your changes.

[andrew_b]

Replying to andrew_b:

I don't thing that you will give any votes for your changes.

s/give/get
of course. Sorry...

[andrew_b]

Sorry, too many typos. My morning is not very well...

I don't thing that you will give any votes for your changes.

I don't think that you will get any votes for your changes.

[slavazanko]

Well... In branch was huge work. It's great. But I have some proposal:

a34369f96646c35bc01ee09fa75ae44be3478bd1::

configure.ac: Added check for empty value of 'enable_mcserver' variable for more proper summary output.

d31b2e86191ee5ea61dfe4e4b55962a1b6a698f5::

Remove support of mvfs. Need to start anoter task for adding them into project. Just keep in mind this changeset if need revert in future. At present time we don't have mvfs support. See #1829 for more details

e4f78f2a928ff5d9bad8b93e8bdf00ed2a9e0bf2::

Replaced free() via g_free() function for one-style codetyping. Please, use g_* functions if this possible.

5c0af26f3bcbd8da915859307fe3323522ae2e84::

Added author of 'vfs/netutil.c' file (but not author of functions in this file :) )

Also, no need to rebase branch at any time of change 'master' branch. In ideal case this branch should be rebased before merge in 'master' branch. Please, don't often rebase branches.

Review, please.

[metux]

As I'm still reworking w/ lots of rebasing, I've almost overwritten your changes by accident ;-O

So I've moved to the 1818_refactoring_no_vfs_METUX branch. Don't touch it - it will be overwritten ;-P

I'll let you know when I'm done and everything runs through the build matrix.

[slavazanko]

:) okay, awaiting...

[metux]

Okay, finished for now and testbuilds succeed.

For additions better chose a different branch name :)

[metux]

rebased to current master, running through testfarm.

[slavazanko]

Present two branches: 1818_refactoring_no_vfs and 1818_refactoring_no_vfs_METUX
What actual? What reason of creating of second branch?

[metux]

Replying to slavazanko:

Present two branches: 1818_refactoring_no_vfs and 1818_refactoring_no_vfs_METUX
What actual? What reason of creating of second branch?

I'm entirely working in 1818_refactoring_no_vfs_METUX, leaving the other branch (w/ your changes) untouched.

[slavazanko]

branch 1818_refactoring_no_vfs_METUX looks like incorrectly rebased.
For example, branch contain these strange commits:

• 8cfaaf0b390a0ea972b8c613b613ddd56a055031: Ticket #1930: src/strutil8bit.c: fixed missing include of fs.h
• fece76ed0fa483adbbd43fce3f004c02274b8fdb: Ticket #1931: Removed obsolete checks for standard header termios.h
• etc.

Please, reorganize branch with proper set of commits.

[metux]

It's not ready for merge yet, since it's based on #1897.

But please keep an eye on this branch :)

[metux]

Rebased to current master. Please review.

[andrew_b]

Branch 1818_refactoring_no_vfs_METUX contains a lot of unrelated commits:

ignoring errors on chdir() call (to make the compiler happy ;-o)
ignore fscanf() result in edit_delete_macro() (make compiler happy ;-o)
ignoring IO errors in background_attention() (make compiler happy ;-o)
and so on.

Please clean your branch. It must not contain commits of #1897.

[metux]

No, that's just because it's based on the 1897_libc_return_values
branch.

Please review / approve that one first.

[andrew_b]

Replying to metux:

No, that's just because it's based on the 1897_libc_return_values
branch.

These issues are independent. Please rebase 1818 branch to master.

And 1818_refactoring_no_vfs_METUX branch is not bildable:

src/Makefile.am:60: USE_SAMBA_FS does not appear in AM_CONDITIONAL
automake failed to generate Makefile.in

[andrew_b]

Created new branch 1818_refactoring_no_vfs.
Initial changeset:43a288cbf68ae5f8090519f974085b4bd69ccd4a