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. >