[ESS-bugs] ESS 13.09-1 with old R versions fails pretty badly

[Martin Maechler]

>>>>> Vitalie Spinu <spinuvit at gmail.com>
>>>>>     on Thu, 31 Oct 2013 16:17:51 -0700 writes:

    >>>> Martin Maechler on Wed, 30 Oct 2013 09:57:59 +0100
    >>>> wrote:
    > [...]


    >>> This will not work for those who don't build.

    MM> That's no problem. All of us (ESS core) can build.
    MM> People working from svn or git *must* build ...

    > A couple of short notes:

    >  1) I don't build because I tend to restart emacs after
    > every feature I add/change. Sometimes it takes dozens of
    > restarts an hour. So waiting for our 30 seconds make is
    > not an option for me. Sorry.

Why don't you just  "evaluate-buffer" for a small change?
I also have a cron job that does  'svn up' and 'make' for me on
a regular basis...
You can 
    	M-x shell  ... make
inside the current emacs, and continue working and the restart
emacs after the very few seconds make has taken.
If you 'make' regularly, then making again is very fast of course.

    >  2) Some people (especially on Windows) might need to
    > test/use ESS from source. Requiring all the make/latex
    > stuff on Windows is an overkill. We will scary people away
    > even more than we do now. We don't want that.

quite rarely; only the very sophisticated ones will not install
ESS from a zip file that they download from somewhere.

    >  We really need and easy install. We are in acute need of
    > new users/testers and new lisp developers.

Almost all free software works with a 
       '[ configure; ] make; ...' 
like scheme.

AND as I said previously, you can still work ok without 'make', 
our code will download the R code if it is outdated locally;
that's not a big deal.
I agree that we could consider moving the LaTeX part away from
the simple 'make' (= 'make all') to only 'make doc' (and similar).

Rich:  What has been the problem on the Mac without 'make'?


    >  3) Recall that even Dirk doesn't use make for his build.

Out of lazyness.
He uses gazillions of other software pieces where he'll be
running make all the time; so he would quickly switch, when
there's a good reason, and I think we have very good reasons.

    >>> It will also not work with MELPA. I will fix that by
    >>> parsing the ESSR/DESCRIPTION directly.

Well, that was a good improvement anyway; thank you Vitalie!

    MM> Do we really care for MELPA for *UN*released versions of
    MM> ESS ??

    > I think rolling releases are better for small
    > projects. That means more testers, quicker bug fixes and,
    > most importantly, fixes get to end users really quickly
    > (MELPA is updated every hour).

To only about 1% or less of end users.
I cannot believe that many  non-emacs-hackers would accept
automatically pushed updates;  Not even I would, and I'm pretty
versed with emacs.

    > My personal belief is that, eventually, MELPA should
    > become the *only* official source of ESS. No debian
    > package, no Vincent's bundle. This is how modern emacs
    > works, and it is the fastest and easiest route for the
    > users. We should adapt IMO. Resistance is futile :-)

I quite strongly disagree, but we can wait and see.

Do you maintain an OS for a group of users, Vitalie? 
Which OS?


    MM> start from. The others (even if they are more than 0.05%
    MM> must build, yes, that's true for all free software I've
    MM> known.

    > Well, emacs packages need not be build in order to work

some do or did in the past, e.g. mail/news/internet/... plugins
all typically need some configuration step which must be run 
before the package is setup.

    > and people are used to this simple scheme. Let's try not
    > to introduce additional sticks in the wheels, we already
    > have enough of them.

Emacs hackers are used to this.
99.5% of the rest are used to either downloading software, or
having  updates of existing software which happen relatively
rarely and they typically approve more or less consciously
before they happen.