Functional regressions - more info
================================
Regarding the functional regressions and the test-results found so far,
the most obvious test-case I could find for failed XML-parsing was eww.
So I tried to load www.google.com using eww, and as I suspected, it
failed. It even specifically failed with saying the following:
> Contacting host: www.google.com:80
> libxml2 library not found
Phil: This should be fairly easy for you to verify locally before publishing a new test-build, right?
--
Jostein Kjønigsen
🥓
jostein@kjonigsen.net / jostein@secure.kjonigsen.net / jostein@gmail.com
https://jostein.kjonigsen.net
On Tue, Nov 15, 2016, at 11:49 AM, Jostein Kjønigsen wrote:
> Hey everyone.
>
> Sorry about the slow response. I've been ill, and haven't had time to
> test this in a production environment until now.
>
> I've got good news and I got bad news. I'll try to be as short and
> concise as possible.
>
>
> Test setup
> =========
>
> In my testing, I've taken the provided Emacs 25-build, downloaded the
> corresponding GNU libraries prebuilt by ezwinports, and combined this
> output in a common Emacs folder from where I've run my tests.
>
> My tool for automating this process is available online[1].
>
>
> Performance results
> ==================
>
> My quickest attempt to do semi-scientific testing is checking with
> Windows Performance Recorder, how long a sustained 100% CPU usage
> period is during startup on my current Emacs-configuration[2].
>
> The results are below:
>
> * Emacs 25.1 (Phil's build): 7 seconds
> * Emacs 25.1 (GNU's release-build): 12 seconds
> * Emacs 24.5 (GNU's release-build): 7 seconds
>
> Phil's build thus has the same performance characteristics as Emacs
> 24.5 for Windows.
>
> And I'd love to say that this was the end of the story... but... I
> like to do real world testing too :)
>
>
> Functional Regressions
> ====================
>
> I've found functional regressions in Phil's build, especially in what
> seems to be handling of incoming XML data from inferior processes.
> This error is not found in the official GNU build currently published
> for Emacs 25.1, nor in Emacs 24.5.
>
> My use-case is fairly simple:
>
> * Ensure eslint is installed globally in your environment (Install
> NodeJS, and then do "npm install -g eslint")
> * Open a JS-file which should trigger eslint warnings.
> * Enable flycheck-mode (which in turn will invoke eslint).
>
> In this case, opening a file with eslint warnings yields no in-buffer
> flycheck errors, but instead a error-message in the minibuffer saying
> something to the extent of this:
>
>> Suspicious state from syntax checker javascript-eslint: Flycheck
>> checker javascript-eslint returned non-zero exit code 1, but its
>> output contained no errors: > 8"?>> line="13" column="7" severity="error" message="'tsify' is
>> assigned a value but never used. (no-unused-vars)" source="eslint.rules.no-unused-
>> vars" />> message="Strings must use doublequote. (quotes)"
>> source="eslint.rules.quotes" />> severity="error" message="Strings must use doublequote. (quotes)"
>> source="eslint.rules.quotes" />
>
> Is Emacs not able to load libxml? Are DLLs linked correctly? Is there
> any way I can help and do diagnostics on my end?
>
> This seems like a symptom of a pretty critical issue which will needs
> to be resolved before any new release-build can be published. Let me
> know how I can help.
>
>
> References:
>
> [1] https://github.com/josteink/machine-build/blob/master/tools/emacs-win32-bootstrap.cmd
> [2] https://github.com/josteink/machine-build/blob/master/dotfiles/emacs/dot-emacs.el
>
> --
> Jostein Kjønigsen
> 🥓
> jostein@kjonigsen.net / jostein@secure.kjonigsen.net /
> jostein@gmail.com
> https://jostein.kjonigsen.net
>
>
> On Mon, Nov 14, 2016, at 07:12 PM, Eli Zaretskii wrote:
>>> From: phillip.lord@russet.org.uk (Phillip Lord)
>>> Cc: emacs-devel@gnu.org, jostein@kjonigsen.net,
>>> npostavs@users.sourceforge.net
>>> Date: Mon, 14 Nov 2016 16:55:27 +0000
>>>
>>> Eli Zaretskii writes:
>>>
>>>> It's okay. In general, if you don't strip the binaries, it
>>>> would be
>>>> better to also include -g3 in CFLAGS (so that there's debug info
>>>> there, and reports about crashes can be accompanied by meaningful
>>>> information), but for a release it is less important than for a
>>>> pretest, so I see no need for yet another build.
>>>
>>> Confused? You mean to have four builds in total?
>>
>> No, of course not. Just 2: one for x86, the other x86_64.
>>
>>> Or you want me to configure with:
>>>
>>> CFLAGS="-O2 -static -g3"
>>
>> That's the best if you don't strip the binaries, yes.
>>
>> Thanks, and sorry for the confusion I caused.
>