headers
MON KEY | 1 Jan 2011 01:06

Re: DocView now supports OpenDocument & MS Office formats

On Fri, Dec 31, 2010 at 11:43 AM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>>> From the Uno FAQ:
>>  2.22 How do I remotely connect to an OpenOffice.org running on a
>>  different machine?
>
> Irrelevant.  E.g., Elisp also allows you to connect to SaaS thingies.
>

Yes, of course; where Emacs is the client (or its immediate mediator);
and where Emacs is built from the more or less standard GNU C
libs/protocols; and where Emacs C API is quite a bit more transparent;
and where the Emacs environment is generally a far cry from the
massive amounts of indirection required to do an ODF conversion via
python/pyuno/UNO/OpenOffice/Java dependency chain -- indeed, it does!

Following are some "benchmarks" which might come of some interest to
the types of people who worry about dumpsize, the slow creep of Emacs
puresize, the size of online documentation relative to the printed
manual, backward compatibility with MS-DOS, running Emacs portably in
both TTY and GUId environments, etc. :P

http://www.oooninja.com/2008/05/openofficeorg-getting-faster-benchmark.html
http://www.oooninja.com/2008/05/openofficeorg-moores-law-obeys.html
http://www.oooninja.com/2009/03/multiplatform-benchmark-30.html	

Would be interesting to chart some of the above benchmarks against the
decline of "Eight Megs And Constantly Swapping" as a prejorative
acronym...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lennart Borgman | 1 Jan 2011 01:50
Picon
Gravatar

Happy new year!

Happy new year all Emacs users and developers!

I wish you all an integrated CEDET, an even more useful Org Mode and
multi major modes. And of course a lot of other things - like a happy
life!
Permalink | Reply | 0 comments |
headers
Stephen J. Turnbull | 1 Jan 2011 04:55
Picon
Favicon

Re: bug#7517: 24.0.50; repeated crash under Mac OS X

Jan Djärv writes:

 > But not in this case.  The given string is not decoded right with undecided. 
 > detect-coding-string doesn't list iso-8859-8.  I think choosing between 
 > iso-8859-x is difficult.  Still, VM should know the coding used.

It does for standards conforming mail.  But VM can't do anything when
people put literal 8-bit codes in the headers without MIME encoding,
which still happens occasionally in legit mail (and is very frequent
in abusive mail), or in the body without a Content-Type charset
parameter.  It has to leave that up to Emacs, or recode to UNKNOWN
(aka application/octet-stream).

VM used to quite ornery about such stuff, and simply refuse to deal
with it.  It's gotten lax in its old age, I guess.
Permalink | Reply | 0 comments |
headers
Werner LEMBERG | 1 Jan 2011 09:28
Picon

bzr vs. git repository


I've now done a comparison between the network traffic of git and bzr,
using nethogs.

git pull (git://repo.or.cz/emacs.git, git version 1.7.1.78) :

  Update from

      commit 6be816dee8c9720dc39ff235b7b31d4190e06d57
      Author: Stefan Monnier <monnier <at> iro.umontreal.ca>
      Date:   Fri Dec 10 15:00:25 2010 -0500

  to

      commit 2d33d18337320f5c0cd1c0627caa6528f7050b29
      Author: Michael Albinus <michael.albinus <at> gmx.de>
      Date:   Fri Dec 31 20:57:05 2010 +0100

  sent:      194k
  received: 6400k

bzr pull (bzr+ssh, bzr version 2.0.5):

  Update from

      revno: 102636
      committer: Glenn Morris <rgm <at> gnu.org>
      branch nick: trunk
      timestamp: Fri 2010-12-10 18:54:07 -0800
(Continue reading)

Permalink | Reply | 11 comments |
headers
Eli Zaretskii | 1 Jan 2011 10:52
Picon

Re: bzr vs. git repository

> Date: Sat, 01 Jan 2011 09:28:38 +0100 (CET)
> From: Werner LEMBERG <wl <at> gnu.org>
> 
> As you can see, bzr still needs about three times more bandwidth in
> both receiving and sending...

So what?  In my testing, both on GNU/Linux and on MS-Windows,
update/pull times are very similar (with bzr slightly _faster_ on
GNU/Linux).  That includes the initial "bzr branch" vs "git clone" (10
min for bzr vs 15 for git).  Other common operations are mostly
comparable as well.  (A great surprise was "annotate", which, for
xdisp.c, took 1 minute with bzr, but a whopping 4.5 minutes with git.
But I see that as a curiosity.)

I don't think this will convince anyone to switch, but frankly, I no
longer understand what is all that fuss with git's speed.  Coupled
with the fact that the git repository seems to be updated only once in
a while, I see no good reasons to use git at all, at least not for
reasons of speed.
Permalink | Reply | 7 comments |
headers
Werner LEMBERG | 1 Jan 2011 10:54
Picon

Re: bzr vs. git repository


>> As you can see, bzr still needs about three times more bandwidth in
>> both receiving and sending...
> 
> I don't think this will convince anyone to switch, but frankly, I no
> longer understand what is all that fuss with git's speed.

I don't want to convince anyone, I just report the issue.  You are
overreacting.

    Werner
Permalink | Reply | 4 comments |
headers
Eli Zaretskii | 1 Jan 2011 11:12
Picon

Re: bzr vs. git repository

> Date: Sat, 01 Jan 2011 10:54:45 +0100 (CET)
> Cc: emacs-devel <at> gnu.org
> From: Werner LEMBERG <wl <at> gnu.org>
> 
> 
> >> As you can see, bzr still needs about three times more bandwidth in
> >> both receiving and sending...
> > 
> > I don't think this will convince anyone to switch, but frankly, I no
> > longer understand what is all that fuss with git's speed.
> 
> I don't want to convince anyone, I just report the issue.  You are
> overreacting.

It's hard to overreact, with all the git propaganda that goes on
here.  For a project that decided long ago to use bzr, this borders on
being inappropriate.  Posting this on the Bazaar mailing list would be
TRT, IMO.  It's always a Good Thing to get the developers think about
getting their software more efficient.  But posting this here can
never make bzr hog less of the bandwidth, so I don't see why would you
do this except to tease.

More to the point: You've analyzed the net traffic, but not the other
aspects of performance, like file I/O, CPU load, memory consumption,
etc.  At least in principle, there are trade-offs between all of
these.  And depending on the particular system configuration of the
end users, the ones that matter could be other than the net traffic.

In my testing, the differences in the net traffic are not noticeable
in the end result.  And the end result is what really matters for
(Continue reading)

Permalink | Reply | 2 comments |
headers
Frank Schmitt | 1 Jan 2011 11:13
X-Face

Re: bzr vs. git repository

Werner LEMBERG <wl <at> gnu.org> writes:

>>> As you can see, bzr still needs about three times more bandwidth in
>>> both receiving and sending...
>> 
>> I don't think this will convince anyone to switch, but frankly, I no
>> longer understand what is all that fuss with git's speed.
>
> I don't want to convince anyone, I just report the issue.  You are
> overreacting.

Honestly, as a lurker on this list, I really wonder how many hours of
developer time was spend in the last few years on discussions about
various aspects of version control systems. I don't dare to imagine all
the cool stuff which could have been created if this time has been spend
on software development instead.

--

-- 
Have you ever considered how much text can fit in eighty columns?  Given that a
signature typically contains up to four lines of text, this space allows you to
attach a tremendous amount of valuable information to your messages.  Seize the
opportunity and don't waste your signature on bullshit that nobody cares about.
Permalink | Reply | 0 comments |
headers
David Kastrup | 1 Jan 2011 11:14
X-Face
Picon
Picon

Re: bzr vs. git repository

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Sat, 01 Jan 2011 09:28:38 +0100 (CET)
>> From: Werner LEMBERG <wl <at> gnu.org>
>> 
>> As you can see, bzr still needs about three times more bandwidth in
>> both receiving and sending...
>
> So what?  In my testing, both on GNU/Linux and on MS-Windows,
> update/pull times are very similar (with bzr slightly _faster_ on
> GNU/Linux).  That includes the initial "bzr branch" vs "git clone" (10
> min for bzr vs 15 for git).  Other common operations are mostly
> comparable as well.  (A great surprise was "annotate", which, for
> xdisp.c, took 1 minute with bzr, but a whopping 4.5 minutes with git.
> But I see that as a curiosity.)

That is not a curiosity but a consequence of git's design choices.  git
stores file system snapshots and a DAG of commits.  Everything else is
reconstructed on-the-fly when you ask for it.  As a result, renaming
files in git is indistinguishable from deleting the old file and
creating a new file with the old content.

That makes git a handy tool for analyzing, say, a progression of
distribution tarballs.  You just check in all the tarballs into a git
repository, and you get renames, moves, copied content, tracking of
material and so on out _gratis_ because git never stores those kind of
things but instead knows how to make them up.

Now "git annotate" is an example where git constructs a history of
content through file renaming and subfile copying, and does it at the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Werner LEMBERG | 1 Jan 2011 12:04
Picon

Re: bzr vs. git repository


> Posting this on the Bazaar mailing list would be TRT, IMO.  It's
> always a Good Thing to get the developers think about getting their
> software more efficient.  But posting this here can never make bzr
> hog less of the bandwidth, so I don't see why would you do this
> except to tease.

RMS explicitly has asked for that info a few months ago, and only now
I was able to provide it for various reasons.  Since the discussion
then happened on this very list, I found it appropriate to post it
here too.

I suggest to forget the whole issue.

    Werner
Permalink | Reply | 1 comment |

Gmane