Re: serious bug (fedora issue?)
Le 30/12/2018 à 22:05, Dr Eberhard Lisse a écrit : Should I raise a bug on the tracker for this? Yes please. I guess we should skip everything ERT. JMarc
Re: serious bug (fedora issue?)
I tried "buffer-anonymize"
and found that
\begin{enumerate}[resume, label={\arabic*}.]
becomes
\begin{enumerate}[resume, a={\aa*}.]
Should I raise a bug on the tracker for this?
el
On 2018-12-29 18:19 , Jean-Marc Lasgouttes wrote:
[...]
> Is it enough to obfuscate it with "buffer-anonymize"?
[...]
Re: I can not insert citations
On 12/30/18 7:10 AM, Jürgen Spitzmüller wrote: > Am Sonntag, den 30.12.2018, 11:35 +0100 schrieb Jürgen Spitzmüller: >> Bisect points towards the commit below. >> >> Note, however, that the bug is not in master. So either we forgot to >> backport something, or there is a difference elsewhere. > Attached the patch with the crucial difference to master. This patch > fixes the problem for me in stable. > > The reason is that what follows below the inserted condition assumes > BibTeX. With Bibliography, the cache is set valid and remains so. > > This should be clarified in the source. For now, I understand that the > attached patch is enough. I have built and verified the fix and built a new installer. I'm having trouble uploading it, though, seemingly due to some problem with the ftp server. I'll post another message when that's resolved. Riki
Re: #10626: thin application icons icns and ico
On 27.12.18 17:20, LyX Ticket Tracker wrote: > #10626: thin application icons icns and ico > -+ > Reporter: Mike | Owner: lasgouttes > Type: enhancement | Status: fixedinmaster > Priority: normal | Milestone: 2.3.3 > Component: build| Version: unspecified > Severity: normal | Resolution: > Keywords: | > -+ > Changes (by spitz): > > * cc: spitz, rikiheck (added) > * status: new => fixedinmaster > > > Comment: > > I applied the icons here to master at [186597b5468/lyxgit]. > > Is it worth backporting this to stable? > > As to the proposals at https://github.com/MNMikeN/Lydia, I don't like very > much these bright colors. But then, as long as this only applies to Win > and Mac, and don't really care much. > Well, thanks for commenting on the proposal at all. The colors are meant to resemble the old ones but still really clearly differentiated from other icons when the Dock gets full and icons tiny. The reason was that bigger icons, more popping colors should allow for better usability. For my eyes, my proposal might look a bit uncool in color choice compared to current design trends (grey on grey is hey), but I really do find the new one faster in my Dock (and I usually replace the shipping icons with mine for that reason). But the proposal is really just that: a proposal, that cleans up the old vectors and enables retina-like high resolutions to be rendered from it. Should someone want to make changes, I guess starting from my cleaned up version should be easier than from what's floating around on wiki. Also, the old template and resulting icons are really full of 'errors' as is the currently shipping icon. Look eg at the cut off shadow, the wasted space in term of screen/icon real-estate? The proposal is by no means perfect and if someone gets it done better or even if we want a complete redesign, that'd be great. Just the current ones are really not that good either. Just a little subtle improvement could go a long way.
Re: New Warnings on Master
On 12/30/18 2:35 AM, Jürgen Spitzmüller wrote: > Am Samstag, den 29.12.2018, 13:13 -0500 schrieb Richard Kimberly Heck: >> frontends/qt4/GuiToolbar.cpp (449): Unknown dynamic menu type: paste >> frontends/qt4/GuiToolbar.cpp (449): Unknown dynamic menu type: >> textstyle-apply > Are you sure your tree is properly updated? The line numbers given > here, anyway, don't match current master (where this warning is at line > 518). Also, I don't know why you get them. Both "paste" and "textstyle- > apply" are in DynamicMenuButton::isMenuType() Should have tried building in a fresh directory. It's fine. Riki
Re: I can not insert citations
On 12/30/18 7:10 AM, Jürgen Spitzmüller wrote:
> Am Sonntag, den 30.12.2018, 11:35 +0100 schrieb Jürgen Spitzmüller:
>> Bisect points towards the commit below.
>>
>> Note, however, that the bug is not in master. So either we forgot to
>> backport something, or there is a difference elsewhere.
> Attached the patch with the crucial difference to master. This patch
> fixes the problem for me in stable.
>
> The reason is that what follows below the inserted condition assumes
> BibTeX. With Bibliography, the cache is set valid and remains so.
>
> This should be clarified in the source. For now, I understand that the
> attached patch is enough.
So if I understand right, the x.diff patch should fix this issue? I can
issue a new Windows installer without too much difficulty.
> While comparing, I also noticed that the following call is missing in
> stable:
>
> diff --git a/src/Buffer.cpp b/src/Buffer.cpp
> index 6be7d0eab3..0df33ad268 100644
> --- a/src/Buffer.cpp
> +++ b/src/Buffer.cpp
> @@ -2386,6 +2386,7 @@ void Buffer::invalidateBibinfoCache() const
> {
> d->bibinfo_cache_valid_ = false;
> d->cite_labels_valid_ = false;
> + removeBiblioTempFiles();
> // also invalidate the cache for the parent buffer
> Buffer const * const pbuf = d->parent();
> if (pbuf)
>
> I propose to add this to stable as well (but not to the 2.3.2 fix of
> the Windows installer).
Yes, that's fine.
Riki
Re: How to crash lyx: option #4269
On Sun, Dec 30, 2018 at 01:24:40PM +0100, Jürgen Spitzmüller wrote: > Am Sonntag, den 30.12.2018, 12:21 + schrieb José Abílio Matos: > > I can rephrase: should we just fix this line, that can become > > obviously wrong, > > or should we try to cure the cause and not just the symptom? > > > > In this case the problem is that the "from name" and the "to name" > > are equal. > > Should we rule out those cases, or try to accommodate them in our > > framework? > > I'd say the latter. For some reason it doesn't crash for me, but I see where the problem lies. In computing the length of the extension, the code does not account for the prefix "unzipped_" which is added when the zipped filename does not have one of the extensions "gz", "z", "Z", or "svgz". Please, can you try the attached patch and report whether it fixes the crash for you? -- Enrico diff --git a/src/insets/InsetGraphics.cpp b/src/insets/InsetGraphics.cpp index c1d9822b93..70b7780910 100644 --- a/src/insets/InsetGraphics.cpp +++ b/src/insets/InsetGraphics.cpp @@ -587,7 +587,10 @@ copyToDirIfNeeded(DocFileName const & file, string const & dir) // have different content but would get the same mangled // name in this case. string const base = removeExtension(file.unzippedFileName()); - string::size_type const ext_len = file_in.length() - base.length(); + string::size_type const prefix_len = + prefixIs(onlyFileName(base), "unzipped_") ? 9 : 0; + string::size_type const ext_len = + file_in.length() + prefix_len - base.length(); mangled[mangled.length() - ext_len] = '.'; } FileName const file_out(makeAbsPath(mangled, dir));
Re: [LyX/master] Move all python shebangs from /usr/bin/env to python3.
On Sunday, 30 December 2018 00.28.16 WET Pavel Sanda wrote: > The famous rng weakening was more or less single man's failure, here we deal > with conceptual thing. 2.7 is simply still default on many important > platforms and I don't believe it disappears promptly; it's generally > difficult to kill sucessfull kids (hello adobe flash :) This was the first time that I had to think for a little while about "adobe flash", because I had just forgot it. And I am happy for that. :-) > I see more likely that there will be some consorcium of subjects who will > continue to release bugfixes on top of 2.7 in similar way in which older > 'unsupported' kernels still receive fixes in various distros. I suspect you right. > Actually someone should pay van Rossum to come back, continue maintenance of > 2.7, declare 2.7 to be the only Python (TM), and leave the whole mess of > 3.x releases for stuntmen. > > Pavel That train has already left the station, at least three years ago. :-) -- José Abílio
Re: How to crash lyx: option #4269
Am Sonntag, den 30.12.2018, 12:21 + schrieb José Abílio Matos: > I can rephrase: should we just fix this line, that can become > obviously wrong, > or should we try to cure the cause and not just the symptom? > > In this case the problem is that the "from name" and the "to name" > are equal. > Should we rule out those cases, or try to accommodate them in our > framework? I'd say the latter. Jürgen signature.asc Description: This is a digitally signed message part
Re: How to crash lyx: option #4269
On Sunday, 30 December 2018 07.38.50 WET Jürgen Spitzmüller wrote: > Is this a rhetorical question? > > Jürgen Yes, :-) I can rephrase: should we just fix this line, that can become obviously wrong, or should we try to cure the cause and not just the symptom? In this case the problem is that the "from name" and the "to name" are equal. Should we rule out those cases, or try to accommodate them in our framework? -- José Abílio
Re: I can not insert citations
Am Sonntag, den 30.12.2018, 11:35 +0100 schrieb Jürgen Spitzmüller:
> Bisect points towards the commit below.
>
> Note, however, that the bug is not in master. So either we forgot to
> backport something, or there is a difference elsewhere.
Attached the patch with the crucial difference to master. This patch
fixes the problem for me in stable.
The reason is that what follows below the inserted condition assumes
BibTeX. With Bibliography, the cache is set valid and remains so.
This should be clarified in the source. For now, I understand that the
attached patch is enough.
While comparing, I also noticed that the following call is missing in
stable:
diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 6be7d0eab3..0df33ad268 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -2386,6 +2386,7 @@ void Buffer::invalidateBibinfoCache() const
{
d->bibinfo_cache_valid_ = false;
d->cite_labels_valid_ = false;
+ removeBiblioTempFiles();
// also invalidate the cache for the parent buffer
Buffer const * const pbuf = d->parent();
if (pbuf)
I propose to add this to stable as well (but not to the 2.3.2 fix of
the Windows installer).
Jürgen
diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 6be7d0eab3..a19b2b1be9 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -2472,6 +2472,11 @@ void Buffer::checkIfBibInfoCacheIsValid() const
return;
}
+ // if we already know the cache is invalid, no need to check
+ // the timestamps
+ if (!d->bibinfo_cache_valid_)
+ return;
+
// we'll assume it's ok and change this if it's not
d->bibinfo_cache_valid_ = true;
d->cite_labels_valid_ = true;
signature.asc
Description: This is a digitally signed message part
Re: I can not insert citations
Am Sonntag, den 30.12.2018, 09:55 +0100 schrieb Jürgen Spitzmüller: > Am Samstag, den 29.12.2018, 21:09 -0300 schrieb Sergio Celani: > > Dear Lyx users > > > > I have the following problem with the latest version of Lyx in > > Windows 10. > > I open a document with several references. When you click on the > > icon > > to insert a cite in the document, the window opens but no cite > > appears. Although several references are included in the document. > > This does not happen with version 2.3.1 > > Attached two screenshots. In the first one corresponds to Lyx 2.3.2 > > (with the problem) The second one is in Lyx 2.3.1. > > The problem occurs with all the documents that I have tried > > I am afraid this is a bug. Citing from the bibliography environment > seems to be broken in 2.3.2 (I am currently investigating). I am > surprised nobody noticed this before. > > The only advice I gan give you now is to downgrade to LyX 2.3.1. Bisect points towards the commit below. Note, however, that the bug is not in master. So either we forgot to backport something, or there is a difference elsewhere. Jürgen e9614a36ebe71ca9b7aa62a7c74e63f9753b6c0a is the first bad commit commit e9614a36ebe71ca9b7aa62a7c74e63f9753b6c0a Author: Richard Kimberly Heck Date: Wed Dec 12 01:18:16 2018 -0500 Fix slowness problem reported on the mailing list on Windows. https://marc.info/?l=lyx-devel=154458979925296=2 This is related to the fix for #9158 and the caching of bibfile information. On Windows, it is incredibly slow to run kpsewhich, which we do to check where files actually are, so as to get info about them (e.g., timestamps). So we have started to cache that as a map. The map is supposed to be invalidated when various things happen, but an oversight was causing it to be invalidated on every cut operation. This is because cutting uses a temporary Buffer, and the operations on it were affecting the *global* cache of biblio file info. (It makes sense to have a global cache, since these files are not document-specific.) Basically, we have to update the list of bibfiles in that temporary Buffer---but that is one of the things that invalidated the cache. The solution is only to invalidate the cache if the list of bibfiles has actually changed (a sensible idea anyway). The only time that will happen in the temporary Buffer is when the copied information contains a BibTeX inset. That should be fairly rare. > signature.asc Description: This is a digitally signed message part
