Re: [LyX/master] Update layouts
On Mon, 2024-06-03 at 16:15 +0200, Jürgen Spitzmüller wrote: > Hm, I intentionally held that back unless we fix the problem > discussed at https://marc.info/?l=lyx-devel=171733833610242=2 IMHO I think that for the moment the right approach is really to update the layouts. :-) The optimization that was suggested there it is relevant mainly for us. This will bite users only if they have a large set of layout files (like we do). As far as I remember we have observed this in the past but the update of all the layouts fixed this issue. So I think that for the moment a pragmatic solution is to always update the layouts when updating the layout format. By reviewing the changes we can ensure that the update code does what it should. We should also add a note somewhere to improve the update mechanism to avoid that the same conversion is done over and over again. This clearly falls under the definition of insanity: “Insanity is doing the same thing over and over and expecting different results.” that is (mis?)attributed to Einstein. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Merge
On Sun, 2024-06-02 at 22:53 -0400, Richard Kimberly Heck wrote: > I've merged 2.4.x into 2.4.1-devel. I should have been doing this > periodically but didn't. There were quite a few conflicts, > unsurprisingly. I believe I have resolved them all properly, and I've > spot-checked several commits. But you might want to have a look and > make sure I didn't mess anything up. > > Going forward, this should not be as much of an issue, since commits > to 2.4.x will be few. And hopefully, we won't need an emergency > release, and I can merge 2.4.1-devel into 2.4.x before long. > > Riki An interesting idea that comes from KDE is that bugfix releases use a Fibonacci series (assuming F_0=1). The first bug fix release (.1) is done one week after the stable release (.0). The second release is done 2 weeks after .1. The third release is done 3 weeks after .2. The fourth release is done 5 weeks after .3. ... My point here is to establish some kind of deadline. Something like "unless some emergency bug comes 2.4.1 is (more or less) scheduled for the end of the month". Thank you for coordinating this effort. Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: layout update in master?
On Sun, 2024-06-02 at 13:37 -0400, Richard Kimberly Heck wrote: > I don't think caching previous loads is possible. Some of them may > over-write previous declarations. Or even include conditional > operations. > > Riki I mean in the same session: $ grep layouts/stdcounters.inc ~/tmp/inbox/lyx/dbg.out | wc -l 435 It does not make any sense that this layout file is converted 435 times in the same session. Once it is enough, and all the other times that it is called it could be using the cached values. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: layout update in master?
On Sun, 2024-06-02 at 12:56 -0400, Richard Kimberly Heck wrote: > I do not see it here. There's a lot of debug output, as you would > expect, but it eventually stops. The resulting file is 1.7 MB and layout2layout is called 2176 before we finally had window. It seems that there is no caching of the previous conversions and so for each class all included files are converted over and over again. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: layout update in master?
On Sun, 2024-06-02 at 12:56 -0400, Richard Kimberly Heck wrote: > I do not see it here. There's a lot of debug output, as you would > expect, but it eventually stops. $ src/lyx -dbg tclass > /dev/null 2>&1 I had to wait for more than a minute. I will redirect the output to see what is going on. > This is ancient code. Very odd that we'd see a problem only now. > > Riki Probably this was the last straw? :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: layout update in master?
On Sun, 2024-06-02 at 17:49 +0200, Jürgen Spitzmüller wrote:
> The following is causing this:
>
> if (lyxerr.debugging(Debug::TCLASS)) {
> // only system layout files are loaded here so no
> // buffer path is needed.
> tmpl->load();
> }
>
> LayoutFile.cpp::147ff.
>
> No idea why it loops.
I see the same infinite loop.
Could it be a race condition?
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Cannot select a report class with Wayland
On Sat, 2024-06-01 at 17:49 +0200, Jean-Pierre Chrétien wrote: > Dear devs, > > I just used the fresh official 2.4.0 release to type in a report and > I was > unable to select the desired class from the list, which displays only > down to > Japanese reports (same with 2.3.8). > > Works fine with Xorg... > I doubt that devlopers can do anything about it :-(( What does Help->About LyX->Version says? You can copy the content there. I had a similar issue before but it has been working for so long that I forgot about it. :-) Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Removal of Python 2 (Request for Comments)
On Fri, 2024-05-31 at 12:54 -0400, Richard Kimberly Heck wrote:
> I'm especially thinking of older files (say, lyx_1_5.py) that will
> not get much testing. It'd be bad to break one of those.
I know that I am revisiting this but I want to give further context to
why I am doing this.
I am testing with tools that were developed for Python 3 and this is
revealing bugs in code/even in older code.
Point in case, I am using mypy (in order to use type annotations that
can be used for type hinting).
Running this I identified two cases that are real bugs:
lyx_2_0.py:2304: error: Function "check_passthru" could always be true
in boolean context [truthy-function]
lyx_2_0.py:2369: error: Function "check_passthru" could always be true
in boolean context [truthy-function]
The code reads as
if not check_passthru:
return
but check_passthru is a function and thus the result is always true.
The code should have been
if not check_passthru(document):
return
I am using this to annotate both variables and functions.
So, for example, all the converter files will have something like this
(this is the easiest example for 0.6 files):
from LyX import Converter_format
# Converter_format is defined in the LyX module as
# list[tuple[int, list[Callable[[type[LyX_base]], None
supported_versions: list[str] = ["0.6"] + [f"0.6.{i}" for i in
range(5)]
convert: Converter_format = [(200, [])]
revert: Converter_format = []
In this case the Converter_format makes it explicit what is the
structure of that variable. These annotations are not used at runtime
but can be used to do static analysis of the code.
It was not possible to used this before as we wanted to also support
Python 2 where this syntax is not possible at all.
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: How can I run LyX 2.4.0 on Ubuntu 30.04 ?
On Fri, 2024-05-31 at 22:38 +0200, Pavel Sanda wrote: > If it's not on mirrors anymore it get's moved to archive.debian.org > and stays there forever. So you need to change URL for apt. > https://snapshot.debian.org/ is another option. > > Pavel FWIW the same applies for Fedora after the releases the repos are moved to the archive and accessible from there... Then it will be necessary to edit the repos location for the package manager to work. I reinforce the warning from Pavel: beware about the origin of the image that you run. This can be a security threat because the image provenance is important. Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/ next] Prepare the removal of Python 2 support
On Thu, 2024-05-30 at 12:33 -0400, Richard Kimberly Heck wrote: > This does look powerful. But it's unclear to me whether it's worth > requiring. I don't have a strong view. > > Riki FWIW worth the choice of 3.10 is not arbitrary on my part. A new Python parser was introduced in Python 3.9: A new parser for CPython https://lwn.net/Articles/816922/ The implementation of this parser allowed for constructions that would be otherwise not possible: An overview of structural pattern matching for Python https://lwn.net/Articles/893193/ Or even removing the sub-parser used for formatted strings: Formalizing f-strings https://lwn.net/Articles/919426/ The bottom issue is that I can not use 3.10 code like match in a file that will be parsed by a previous version. The only option that I see is to place that code in another file/module and import it conditionally in the first file. Not handy but there are worse things in life. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Removal of Python 2 (Request for Comments)
On Fri, 2024-05-31 at 12:54 -0400, Richard Kimberly Heck wrote: > One question I had, though, was whether the formatted string changes > in the lyx2lyx code are necessary. Or whether they're safe enough > that I shouldn't worry. Those changes have been done automatically through pyupgrade: https://github.com/asottile/pyupgrade I have used the --py38-plus option. > I'm especially thinking of older files (say, lyx_1_5.py) that will > not get much testing. It'd be bad to break one of those. I agree that this could be a problem so I ran all the changes comparing the conversions from previous user guides. At the same time I reviewed every change to ensure that the changes do what they do. > Riki -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.4.0 To Be Released Friday!
On Fri, 2024-05-31 at 12:01 -0400, Richard Kimberly Heck wrote: > It's such a milestone that I thought about suggesting we call it 3.0. > > Riki Naturally I am all for it. :-D Jokes aside I agree with you. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: How can I run LyX 2.4.0 on Ubuntu 30.04 ?
On Fri, 2024-05-31 at 12:05 -0400, Scott Kostyshak wrote: > I'm guessing the answer has to do with containers? > > Scott I have also thought about this a lot (because of the file format and to have the original lyx to generate it) and my conclusion is similar to yours. Apologies for not adding further to this conversation but that is what I have. :-) Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/ next] Prepare the removal of Python 2 support
On Fri, 2024-05-31 at 11:47 +0200, Pavel Sanda wrote:
> On Fri, May 31, 2024 at 01:51:31AM +0100, José Matos wrote:
>
>
> By *old* LTS I meant something like 16.04/18.04.
>
> > In October of 2026 Python 3.10 will no longer be supported even in
> > terms of security releases:
>
> Sure, but LTS distros tend to have independent stream of important
> security patches even when upstream stopped the support.
>
It is important to distinguish in this conversation two aspects of LTS:
* servers;
* desktop computers.
Or else with the last round of supports we will feel bounded to support
+15 year distributions. :-(
By now the experience tells me that, for example, RHEL 8 is becoming
more and more difficult to build updated graphical applications. And
most of the work is moving to RHEL 9.
Another important distinction to make here is in these arguments are if
the issues are related to the users or to the developers?
Because sometimes in the conversations they are mixed and they clearly
correspond to different concerns.
For developers the releases correspond to what exists now, while for
users the concern are the distributions that will be available when the
first stable version is released.
> > On the other hand if you want to build for older systems it is
> > possible to use new tools to build and run.
>
> I am hesitant to push users for tinkering with python installs just
> to run lyx.
One interesting tidbit that I found when searching for this. On Fedora:
[jamatos@griffin ~]$ rpm -q --queryformat '%{SIZE} \t%{NAME} \n'
$(rpm -qa | grep python3.10) | sort -n
33319 python3.10
1692348 python3.10-tkinter
32617346python3.10-libs
[jamatos@griffin ~]$ rpm -q --queryformat '%{SIZE} \t%{NAME} \n'
$(rpm -qa | grep lyx) | sort -n
284894 lyx-fonts
14937413lyx
63453371lyx-common
So that means that Python 3.10 corresponds to 33 MiB while LyX
corresponds to 75 MiB. Honestly I had no idea, I had suspicions but I
did not know. :-)
> Anyway, my breakdown would be:
>
> LyX 2.4 requires GCC 4.9, Python 2.7/3.5, Qt 5.4 (>=5.6 suggested)
>
> This is what I see wrt ubuntu:
> focal/20.04 (sec support till 2030): GCC 9.3, Qt 5.12, Python 3.8.2
> Older do not ship python 3 / Qt 5, end of story.
>
> Redhat world:
> RHEL 7 is dead, Searching RHEL 8 (sec support till 2029) packages
> seems behind redhats login wall but when I look on pkgs.org (sorry if
> I mess up, not expert in redhats ecosystem) I see GCC 8.5, Qt 5.15, I
> don't see python3 packages, but when login on nearby rocky 8.9
> machine I see:
> $ python3 --version
> Python 3.6.8
>
>
> The lower intersection gives GCC 8.5, Qt 5.12, Python 3.6, if, as you
> say, is easy to update python3 in rhel, maybe 3.8 then.
I can work with 3.8 with the walrus operator, that is also quite
helpful for our code:
https://docs.python.org/3/whatsnew/3.8.html#assignment-expressions
One advantage of 3.9 for our code is the support of Type Hinting
Generics in Standard Collections:
https://docs.python.org/3/whatsnew/3.9.html#type-hinting-generics-in-standard-collections
This will help us to better document our code and to advantage of
static analysis to find problems.
> All in all, if we have incentive, we could bump some deps for master
> right away, kill python 2.7, but python 3.10 seems premature for
> lyx 2.5 in my opinion.
> As said it will break even on machine I am still using for active
> development and that system did not even switch to LTS (yet :).
> Not a good sign...
As I have told you above I am a lot more sensitive to this argument
than to say that the reasons not change are related to our users when
we have not a reasonable estimate for release.
> Pavel
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.4.0 To Be Released Friday!
On Fri, 2024-05-31 at 00:41 +0200, Pavel Sanda wrote: > I updated some dev stats for 2.4 series ( > https://wiki.lyx.org/Devel/Statistics ) > and when looking on the obviously most important indicator, oh boy, > we are getting old and grumpy :) Our all-time star Jose dropped below > 0.5 emoticons per email and other are not doing much better. Following Goodhart's law [1] I will append a random emoji to my email signature to improve this key performance indicator. :-D [1] https://en.wikipedia.org/wiki/Goodhart%27s_law -- José Abílio ;-) -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/ next] Prepare the removal of Python 2 support
On Thu, 2024-05-30 at 19:10 +0200, Jean-Marc Lasgouttes wrote: > I'd suggest AM_PATH_PYTHON now that we do not have 2 versions > anymore. > https://www.gnu.org/software/automake/manual/html_node/Python.html Does that means that the code can be simplified like this? # Find a suitable python interpreter AM_PATH_PYTHON([3.10.0]) And then we can remove config/lyxpython.m4, right? Thank you for looking into this black magic voodoo stuff. :-D -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.4.0 To Be Released Friday!
On Thu, 2024-05-30 at 17:48 -0400, Richard Kimberly Heck wrote: > I've uploaded everything to the FTP server and will now wait the > usual > 24 hours or so for the mirrors to sync. Official release will be done > some time tomorrow, but those who are impatient can find the tarballs > and binaries on the main server: http://ftp.lyx.org/pub/lyx/ > > Riki Packages for Fedora 39 and 40 are already on its way to updates- testing, and in a week (or less) they will be available for everyone in updates. Hooray. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/ next] Prepare the removal of Python 2 support
On Fri, 2024-05-31 at 00:02 +0200, Pavel Sanda wrote: > The research which should be done is to pair aprox. versions > of Qt, gcc & python in some still alive oold LTS ubuntu/redhat + 2.5 > years. > It does not make sense to invest time for supporting old gcc when > the rest won't work anyway. > > I did not do this research yet, but the quick check on my terminal > showed 3.9.2 and I'm not even running old LTS, so my first guess is > that you are trying to bump too much... > > Pavel The current Ubuntu LTS é 24.04, the previous one is Ubuntu 22.04 LTS jammy. In the oldest version the Python version that comes with the system is 3.10.4. https://distrowatch.com/dwres.php?firstlist=debian=ubuntu=5=compare-packages=2 So the previous LTS works even now. In October of 2026 Python 3.10 will no longer be supported even in terms of security releases: https://devguide.python.org/versions/ On the other hand if you want to build for older systems it is possible to use new tools to build and run. I did that to build lyx 2.3 for RHEL-7 that come with gcc-4. In that case it is also possible, and quite easy to install another python version that does not replace the system. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
[LyX/ next] Prepare the removal of Python 2 support
In order to pay the technical debt that is the Python 2 support I
intend to start removing its support.
The first step is to change the build support to ignore Python 2.
Since that is code that, usually, I run away from I would like to get
your feedback before committing it. Because if this breaks the package
does not build and that is a huge problem. :-)
@Jean-Marc is the code OK for the autotools?
@Kornel is the code right for cmake?
There is another change that deserves to be discussed, in the process I
have bumped the minimum python version to be 3.10.
Assuming that the next development cycle takes 2.5 years this will be a
version that will be 5 years old by then and so it should be widely
available.
In this particular case the reason to jump directly to 3.10 is the
structural pattern matching:
https://docs.python.org/3/whatsnew/3.10.html#pep-634-structural-pattern-matching
FWIW notice that this is a lot more powerful than the usual C/C++
switch.
I think that some of our code, like lyx2lyx, can take direct advantage
of this feature.
Best regards,
--
José Abílio
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 26bca21728..43a524c655 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -924,26 +924,17 @@ unset(PYTHON_VERSION_MAJOR)
unset(PYTHON_VERSION_MINOR)
unset(PYTHON_VERSION_STRING)
if (CMAKE_VERSION VERSION_LESS "3.13")
- find_package(PythonInterp 3.5 QUIET)
+ find_package(PythonInterp 3.10 QUIET)
if(NOT PYTHONINTERP_FOUND)
-find_package(PythonInterp 2.0 REQUIRED)
-if(NOT PYTHON_VERSION_STRING VERSION_LESS 2.8)
- message(FATAL_ERROR "Python interpreter found, but is not suitable")
-endif()
+ message(FATAL_ERROR "Python interpreter not found or not suitable")
endif()
set(LYX_PYTHON_EXECUTABLE ${PYTHON_EXECUTABLE} CACHE FILEPATH "Python to be used by LyX")
else()
- find_package(Python3 3.5 QUIET)
+ find_package(Python3 3.10 QUIET)
if(NOT Python3_Interpreter_FOUND)
-unset(PYTHON_EXECUTABLE CACHE)
-find_package(Python2 2.0 REQUIRED)
-if(NOT Python2_VERSION VERSION_LESS 2.8)
- message(FATAL_ERROR "Python interpreter found, but is not suitable")
-endif()
-set(LYX_PYTHON_EXECUTABLE ${Python2_EXECUTABLE} CACHE FILEPATH "Python to be used by LyX")
- else()
-set(LYX_PYTHON_EXECUTABLE ${Python3_EXECUTABLE} CACHE FILEPATH "Python to be used by LyX")
+ message(FATAL_ERROR "Python interpreter not found or not suitable")
endif()
+ set(LYX_PYTHON_EXECUTABLE ${Python3_EXECUTABLE} CACHE FILEPATH "Python to be used by LyX")
endif()
if(LYX_NLS)
diff --git a/config/lyxpython.m4 b/config/lyxpython.m4
index 21d0d8a963..274e7742d6 100644
--- a/config/lyxpython.m4
+++ b/config/lyxpython.m4
@@ -10,19 +10,18 @@
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
-dnl Usage: LYX_PATH_PYTHON23(PY2-MIN-VERSION, PYTHON3-MIN-VERSION)
-dnl Find a suitable Python interpreter, that is either python2 >= $1
-dnl or python3 >= $2. Stop with an error message if it has not been found.
-AC_DEFUN([LYX_PATH_PYTHON23],
+dnl Usage: LYX_PATH_PYTHON(PYTHON-MIN-VERSION)
+dnl Find a suitable Python interpreter, that is >= $1
+dnl Stop with an error message if it has not been found.
+AC_DEFUN([LYX_PATH_PYTHON],
[
- m4_define(py2_ver, [patsubst($1,[\.],[,])])
- m4_define(py3_ver, [patsubst($2,[\.],[,])])
+ m4_define(py_ver, [patsubst($1,[\.],[,])])
- m4_define_default([_AM_PYTHON_INTERPRETER_LIST], [python3 python2 python])
+ m4_define_default([_AM_PYTHON_INTERPRETER_LIST], [python3 python])
if test -n "$PYTHON"; then
# If the user set $PYTHON, use it and don't search something else.
- AC_MSG_CHECKING([whether $PYTHON version is >= $1 or $2])
+ AC_MSG_CHECKING([whether $PYTHON version is >= $1])
LYX_PYTHON_CHECK_VERSION([$PYTHON],
[AC_MSG_RESULT([yes])],
[AC_MSG_RESULT([no])
@@ -31,7 +30,7 @@ AC_DEFUN([LYX_PATH_PYTHON23],
else
# Otherwise, try each interpreter until we find one that satisfies
# LYX_PYTHON_CHECK_VERSION.
- AC_CACHE_CHECK([for a Python interpreter with version >= $1 or $2],
+ AC_CACHE_CHECK([for a Python interpreter with version >= $1],
[am_cv_pathless_PYTHON],[
for am_cv_pathless_PYTHON in _AM_PYTHON_INTERPRETER_LIST none; do
test "$am_cv_pathless_PYTHON" = none && break
@@ -53,10 +52,10 @@ AC_DEFUN([LYX_PATH_PYTHON23],
# LYX_PYTHON_CHECK_VERSION(PROG, [ACTION-IF-TRUE], [ACTION-IF-FALSE])
# ---
-# Run ACTION-IF-TRUE if the Python interpreter PROG has version >= py2_ver or py3_ver.
+# Run ACTION-IF-TRUE if the Python interpreter PROG has version py_ver.
# Run ACTION-IF-FALSE otherwise.
AC_DEFUN([LYX_PYTHON_CHECK_VERSION],
[prog="import sys
version = sys.version_info@<:@:3@:>@
-sys.exit(not ((py2_ver) <= version < (3,0,0) or version >= (py3_ver)))"
+sys.exit(version < (py_ver))"
Re: 2.4.0 Tarballs
On Sat, 2024-05-25 at 22:45 -0400, Richard Kimberly Heck wrote: > Here: > > http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/ > > Let's have a day or two of testing. Assuming all goes well, we can > build > tarballs early next week, and release at the end of the week. > > Riki For Fedora: https://copr.fedorainfracloud.org/coprs/jamatos/lyx-next/ This has been built for F38, F39, F40 and rawhide. This package replaces the distribution package (2.3.8). As soon as 2.4.0 is released this package will become the distribution's package. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: metainfo wrong target dir?
On Thu, 2024-05-23 at 10:20 +0200, Pavel Sanda wrote: > Others please chime in, but I'd say just document it and release > 2.4.0. > If we get some clue it can be always added in 2.4.1 which won't take > for long I guess. > > Pavel I agree. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.3.8 layout2layout.py
On Thu, 2024-05-23 at 04:00 +0800, Eberhard W Lisse wrote: > ?? > > el There is a latent bug in the code that Norbert pinpointed. This bug was already fixed in the 2.4 code but not on the 2.3 version. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.3.8 layout2layout.py
On Tue, 2024-05-21 at 18:04 +0100, José Matos wrote: > This is fixed in 2.4. > Since there will not be any new 2.3.x release I think that we can > leave it that way. OK, Rikki fixed this. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.3.8 layout2layout.py
On Tue, 2024-05-21 at 17:10 +0200, Norbert Koksch wrote: > Dear LyX developers, > > in lines 396 ... 365 of layout2layout.py, \s has to replaced by \\s. > > Best regards > Norbert Thank you for the report. This is fixed in 2.4. Since there will not be any new 2.3.x release I think that we can leave it that way. Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Version 2.4.0~RC4 Instant preview stops working when inserting floats or comments
On Sat, 2024-05-18 at 12:45 +0200, Jürgen Spitzmüller wrote: > Don't know about suffix, but cprotect should probably by a > requirement for LyX now generally. I am sorry for asking this again. I am not sure if we had discussed this before. As a packager, for Fedora, I would like to be able to exactly define what are the latex dependencies for LyX. I am aware that some of our dependencies are optional, e.g. the different layouts that we support. But, for example, to correctly compile the User Guide what is the list of latex dependencies? Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.3.8 Released
On Sat, 2024-05-18 at 09:15 +0200, JP wrote: > > Samedi here. > same here But it is also Saturday (samedi in French) so it was not really an error. :-D -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Final 2.3.8 Tarballs
On Thu, 2024-05-09 at 12:18 +0200, Jean-Marc Lasgouttes wrote: > This is not a new bug in 2.3.8, right? > > In some sense the lyx2lyx bug is a new bug (since we backported 2.4 > format support), though. Shall we do something about it? > > JMarc The problem is the backwards conversion (converting from 2.4 to 2.3 file format) and not the forward conversion, right? The backwards conversion has always been a *good to have* an not a *should have*. If this can be easily fixed then of course it should be fixed. I am sorry if I am understanding this wrong, I have no time to get all the details right. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0~RC4 gnuplot onscreen previewing not working
On Thu, 2024-04-11 at 21:38 +0200, Tobias Hilbricht wrote: > Dear readers, > > I can compile the LyX gnuplot scripting example document, but the > gnuplot does not show up onscreen for previewing with needauth > converter enabled. By contrast, PDF-images do get converted for > onscreen preview. I attached a screenshot. > > Thanks for having a look at it! > Tobias This is now fixed and it will in 2.4.0 when it is released. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0~RC4 gnuplot onscreen previewing not working
On Mon, 2024-04-15 at 10:01 +0100, José Matos wrote: > The change is in at: > https://www.lyx.org/trac/changeset/cdcaf0e7b6cc45bc74175667c390c3148c4730e9/lyxgit > > @Riki this is a candidate for 2.4.0. Is it OK? ping :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Workarea not updated after deleting figure inset, on current master
On Wed, 2024-04-17 at 23:29 +0200, Jean-Marc Lasgouttes wrote: > Is it still here with latest master? If it is, could you give a > better > recipe? I cannot reproduce. > > JMarc With your last change this issue was fixed: commit 1a11abe4394272f521cd63993e426c136e0e9b6c Author: Jean-Marc Lasgouttes Date: Tue Apr 16 23:55:24 2024 +0200 Always repaint the gray area below main inset Now that SingleParUpdate does not always lead to a full screen update when the height of the paragraph changes (see new behavior of updateMatrics(bool)), it is necessary to make sure that the grey area below the main page is always repainted. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX v2.4.0 RC4 -> Unicode in Program Listing (again...)
On Wed, 2024-04-17 at 13:17 +, Bernt Lie wrote: > Question 1: > * Dangerous, because LyX is more likely to *crash*, or > * Dangerous, because it opens up my computer to hacking?? The script that you call can run any code using the gnuplot "system" call. That is the same as having access to a shell... If the gnuplot files that you use are your own, or from one that you trust, then there is no risk... or actually the same risk that you had if you run the script outside of LyX. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Workarea not updated after deleting figure inset, on current master
[So let us see if I can taunt Jean-Marc as well as Scott does :-D ] Insert a figure inset as the single element of a paragraph. Load a figure, even if there is an error converting it, delete the figure. The bottom part of the inset figure will stay there. It is not repainted. If you delete the empty space, thus removing the paragraph, then everything is right again. Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX v2.4.0 RC4 -> Unicode in Program Listing (again...)
On Tue, 2024-04-16 at 17:22 +, Bernt Lie wrote: > QUESTION 1: What is wrong? I *did* envoke the “-shell-escape” flag, > didn’t I? The shell-escape option is a per-document option. In LyX, in the document that you want to use this option: Document -> Settings -> Output select the options that says "Allow running external programs" The options that you passed to the converters do not work, basically they are no-ops (do nothing). I hope that this helps, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0~RC4 gnuplot onscreen previewing not working
On Sun, 2024-04-14 at 00:37 +0100, José Matos wrote: > Actually in the spirit of the other code the change is 2-lines. > > I will test this tomorrow and commit it. :-) The change is in at: https://www.lyx.org/trac/changeset/cdcaf0e7b6cc45bc74175667c390c3148c4730e9/lyxgit @Riki this is a candidate for 2.4.0. Is it OK? -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0~RC4 gnuplot onscreen previewing not working
On Fri, 2024-04-12 at 11:09 +0100, José Matos wrote:
> The real fix is one line of code. :-)
> I will do it later today.
Actually in the spirit of the other code the change is 2-lines.
I will test this tomorrow and commit it. :-)
--
José Abílio
diff --git a/src/graphics/GraphicsConverter.cpp b/src/graphics/GraphicsConverter.cpp
index 669f08d2ff..34d37a4066 100644
--- a/src/graphics/GraphicsConverter.cpp
+++ b/src/graphics/GraphicsConverter.cpp
@@ -362,6 +362,7 @@ static void build_script(string const & doc_fname,
string const token_base = "$$b";
string const token_to= "$$o";
string const token_todir = "$$d";
+ string const token_python = "$${python}";
EdgePath::const_iterator it = edgepath.begin();
EdgePath::const_iterator end = edgepath.end();
@@ -405,6 +406,7 @@ static void build_script(string const & doc_fname,
command = subst(command, token_base, "' + '\"' + infile_base + '\"' + '");
command = subst(command, token_to,"' + '\"' + outfile + '\"' + '");
command = subst(command, token_todir, "' + '\"' + outdir + '\"' + '");
+ command = subst(command, token_python, os::python());
build_conversion_command(command, script);
}
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug in language conversion ?
On Fri, 2024-04-12 at 13:57 +0200, Jürgen Spitzmüller wrote: > I wouldn't rate it a bug, but I also would prefer if insets > (generally, not only in the case here) would inherit language changes > from selections. In principle I agree with you. Is there a counter example where this is undesirable? -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0~RC4 gnuplot onscreen previewing not working
On Thu, 2024-04-11 at 21:38 +0200, Tobias Hilbricht wrote:
> graphics/GraphicsConverter.cpp (288): build_script ...
> graphics/GraphicsConverter.cpp (414): ready!
> graphics/GraphicsConverter.cpp (150): Conversion script:
> --
> # -*- coding: utf-8 -*-
> import os, shutil, sys
>
> def unlinkNoThrow(file):
> ''' remove a file, do not throw if an error occurs '''
> try:
> os.unlink(file)
> except:
> pass
>
> infile = "/home/tobias/Dokumente/Privat/DocCentral/LaTeX/LyX/gnuplot-
> example.gp"
> outfile = "/tmp/lyx_tmpdir.qIGrrVZsvWmq/gconvertYrusMn.gp"
> shutil.copy(infile, outfile)
> os.chdir("/tmp/lyx_tmpdir.qIGrrVZsvWmq/")
> infile = "/tmp/lyx_tmpdir.qIGrrVZsvWmq/gconvertYrusMn.gp"
> infile_base = "/tmp/lyx_tmpdir.qIGrrVZsvWmq/gconvertYrusMn"
> outfile = "/tmp/lyx_tmpdir.qIGrrVZsvWmq/gconvertYrusMn.pdf"
> outdir = os.path.dirname(outfile)
>
> if os.system(r'$${python} "/usr/local/share/lyx-
The problem is here $${python} is not converted when we create the
script.
For the moment a way to get around this is in
Tools->Preferences->File Handling->Converters
Gnuplot -> PDF (graphics)
Converter: $${python} $$s/scripts/gnuplot2pdf.py $$i $$o
move that to
Converter: python3 $$s/scripts/gnuplot2pdf.py $$i $$o
> 2.4.0~RC4/scripts/gnuplot2pdf.py" ' + '"' + infile + '"' + ' ' + '"'
> +
> outfile + '"' + '') != 0:
> unlinkNoThrow(outfile)
> sys.exit(1)
>
> if not os.path.isfile(outfile):
> if os.path.isfile(outfile + '.0'):
> os.rename(outfile + '.0', outfile)
> import glob
> for file in glob.glob(outfile + '.?'):
> unlinkNoThrow(file)
> else:
> sys.exit(1)
>
> if infile != outfile:
> unlinkNoThrow(infile)
The real fix is one line of code. :-)
I will do it later today.
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0 RC4 - bug? Abstract headline is missing
On Fri, 2024-04-12 at 09:41 +, Bernt Lie via lyx-users wrote: > When I use KOMA script and Article style, and insert an Abstract, the > headline "Abstract" is not inserted. This is different from previous > versions, I think?? > > Is this a bug? I tested in 2.3.x and it does not show there as well. So at least the change is not specific to lyx 2.4. If you change to the standard class then the label is there both for 2.3 and 2.4. So the question is if the label should be there for consistency. I am inclined to say yes but I have no strong feelings about this. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Cursor painting gets stuck if space before end of inset
On Fri, 2024-04-12 at 10:05 +0200, Kornel Benko wrote: > Am Fri, 12 Apr 2024 00:07:06 -0400 > schrieb Scott Kostyshak : > > > To reproduce: > > > > 1. Open the attached file. > > 2. Put the cursor just after "testing" and before the space. > > 3. Press . > > > > Result: it looks like the cursor is frozen for a second. > > I do not see this. > > > Similarly, if after (3) you do another quick you can see > > two cursors painted for a split second. > > This I could see. > > > Can anyone reproduce? > > > > Scott > > Kornel I have the same symptoms as Kornel. I do not see the first but I see the second artifact. Version 2.5.0~devel (not released yet) Built from git commit hash cad4da73 Qt Version (run-time): 6.6.2 on platform wayland Qt Version (compile-time): 6.6.2 OS Version (run-time): Fedora Linux 40 (KDE Plasma) Python detected: 3.12.3 (/usr/bin/python3) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0, Listing, and computer language?
On Wed, 2024-04-10 at 15:11 +, Bernt Lie wrote: > > > How can I add another computer language to the Program Listing > Settings? > > * Is there a file where I can add reserved words, etc.? > * …and then have it show up in the Program Listing Settings language > choice? > > -B Either listings or minted have those definitions for most languages. But they are specific to each package and language. I do not think that it is possible to add another language from the options. But I can be wrong, naturally. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: File format increases on master make it hard to test
On Sun, 2024-04-07 at 23:03 -0400, Scott Kostyshak wrote: > Thanks, that is a good idea, but I would not want to use that setting > for most of my documents. I find that doing repeated lyx2lyx does not > create a smooth workflow. > > Scott I pushed against the guarantee before. :-) The rationale was the main priority was to ensure the best upgrade (forward). On the other hand after hundreds of file updates we have now a better understanding of what it involves and so I think that with some small effort we can improve, make it for a smoother experience, the round trip experience. BTW, I know that this is orthogonal to your issue. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: File format increases on master make it hard to test
On Sun, 2024-04-07 at 11:31 -0400, Scott Kostyshak wrote: > Fair enough. That was what I was afraid of (and expected). > > Scott A possible mid-term solution, to your use case, is to set the output format of the latest stable version. This would mean that any document is always imported to the latest development release and when saved it is done in the stable file format. On the other hand what this would mean to stress the conversion/reversion round trip. This could be implemented as some kind of option to set, by default, the save file format version or even better, because in this case this is what it intended, the target version. In the preferences file this could go as: \save_file_format 2.4 If this option is not set then everything works as usual. If it is set then, when the file is saved, the file is reverted to that file format. I hope that this idea helps, :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Layout file format change proposal
On Thu, 2024-03-28 at 13:00 +0100, Thibaut Cuvelier wrote: > All of these formats are rather well supported and far from shiny new > things (I think all of them have at least a decade of existence). > > Regarding validation: XML Schema has many offsprings, such as JSON > Schema (https://json-schema.org/), with implementations that work on > YAML and TOML (https://json-schema-everywhere.github.io/toml). In any > case, these schemas are extremely lacking compared to 21st-century > XML validation (RelaxNG with Schematron). > We currently have no validation, but it would be great to have it as > part of the test suite. > > How well do these formats work with (long) strings? What's great with > the current format is that you don't need to escape anything when LyX > expects a string. This aspect of the design removes a huge source of > typos. I agree with Thibaut's analysis. In addition I would say that with all its faults the upgrade mechanism between the different file formats is well defined and streamlined, note for example the number of LyX file formats that we have (more than 100). And this is also the part that lead us to the elephant in the room, the LyX file format where most of these discussions took place. IMHO it only makes sense to choose a file format if the purpose is to change all the different file formats to that model: * bind (key bindings); * citeengine * kmap (keyboard mappings); * layouts; * ui; * xtemplate; and * .lyx (the LyX file format - the elephant). Or else we risk the xkcd joke where in order to establish a unique standard we introduce another one. Do not underestimate the work required for the later. The advantages of having a standard format are many but the obstacles are also many. In any case it would be nice to compile the information here in a wiki page, in the development components, so that the next time this comes we have a central reference. That was also the rationale to the PEPs (Python Enhance Proposals), even if the proposal would be rejected there was a place where the reasons were stated. Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Errors compiling lyx2.4 with gcc 5.4.0
On Mon, 2024-04-01 at 20:44 +0200, Kornel Benko wrote: > Attached the the errors for src/frontends/qt/GuiRef.cpp and > src/frontends/qt/GuiWorkArea.cpp. > > This is on a debian computer used by my wife, so I am somewhat > reluctant to upgrade there. > If I create a package on a different computer, the resulting > executable does not run > there because it expects many newer libraries. > > Kornel I suspect that the problem is the Qt version. What Qt version is available there? -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on current master
On Sat, 2024-03-30 at 10:16 +0100, Jürgen Spitzmüller wrote: > Yes, fixed, thanks. I confirm, it works now for me. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on current master
On Fri, 2024-03-29 at 22:38 -0400, Scott Kostyshak wrote: > To reproduce: > > 1. Start a new document. > 2. Start a math inset and put "x + y". > 3. Select x. > 4. Press ctrl + f to open find. > 5. Press . > > The result for me is a SIGSEGV. > > Can anyone else reproduce? > > Scott Yes, this is the backtrace is attached. -- José Abílio lyx: SIGSEGV signal caught! Sorry, you have found a bug in LyX, hope you have not lost any data. Please read the bug-reporting instructions in 'Help->Introduction' and send us a bug report, if necessary. Thanks! Bye. Error: LyX crashed! SIGSEGV signal caught! Sorry, you have found a bug in LyX, hope you have not lost any data. Please read the bug-reporting instructions in 'Help->Introduction' and send us a bug report, if necessary. Thanks! Bye. ( 1) src/lyx: lyx::frontend::Alert::doError(std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, bool) ( 2) src/lyx: std::_Function_handler, std::allocator > const>, std::reference_wrapper, std::allocator > const>, std::reference_wrapper))(std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, bool)> >::_M_invoke(std::_Any_data const&) ( 3) src/lyx: lyx::frontend::InGuiThread::synchronousFunctionCall() ( 4) src/lyx: lyx::frontend::IntoGuiThreadMover::callInGuiThread() ( 5) src/lyx: lyx::frontend::Alert::error(std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, bool) ( 6) src/lyx: src/lyx() [0x77de5a] ( 7) /lib64/libc.so.6: /lib64/libc.so.6(+0x40710) [0x7f7d06453710] ( 8) src/lyx: lyx::CursorSlice::setPitPos(long, long) ( 9) src/lyx: lyx::InsetText::edit(lyx::Cursor&, bool, lyx::Inset::EntryDirection) ( 10) src/lyx: lyx::BufferView::setCursorSelectionTo(lyx::DocIterator const&) ( 11) src/lyx: lyx::findOne(lyx::BufferView*, std::__cxx11::basic_string, std::allocator > const&, bool, bool, bool, bool, bool, bool, bool, bool) ( 12) src/lyx: lyx::lyxfind(lyx::BufferView*, lyx::FuncRequest const&) ( 13) src/lyx: lyx::BufferView::dispatch(lyx::FuncRequest const&, lyx::DispatchResult&) ( 14) src/lyx: lyx::frontend::GuiView::dispatchToBufferView(lyx::FuncRequest const&, lyx::DispatchResult&) ( 15) src/lyx: lyx::frontend::GuiView::dispatch(lyx::FuncRequest const&, lyx::DispatchResult&) ( 16) src/lyx: lyx::frontend::GuiApplication::dispatch(lyx::FuncRequest const&, lyx::DispatchResult&) ( 17) src/lyx: lyx::frontend::GuiApplication::dispatch(lyx::FuncRequest const&) ( 18) src/lyx: lyx::dispatch(lyx::FuncRequest const&) ( 19) src/lyx: lyx::frontend::GuiSearchWidget::find(std::__cxx11::basic_string, std::allocator > const&, bool, bool, bool, bool, bool, bool) ( 20) src/lyx: lyx::frontend::GuiSearchWidget::doFind(bool, bool) ( 21) src/lyx: lyx::frontend::GuiSearchWidget::keyPressEvent(QKeyEvent*) ( 22) /lib64/libQt6Widgets.so.6: QWidget::event(QEvent*) ( 23) /lib64/libQt6Widgets.so.6: QApplicationPrivate::notify_helper(QObject*, QEvent*) ( 24) /lib64/libQt6Widgets.so.6: QApplication::notify(QObject*, QEvent*) ( 25) src/lyx: lyx::frontend::GuiApplication::notify(QObject*, QEvent*) ( 26) /lib64/libQt6Core.so.6: QCoreApplication::notifyInternal2(QObject*, QEvent*) ( 27) /lib64/libQt6Widgets.so.6: /lib64/libQt6Widgets.so.6(+0x1fb270) [0x7f7d07dfb270] ( 28) /lib64/libQt6Widgets.so.6: QApplicationPrivate::notify_helper(QObject*, QEvent*) ( 29) src/lyx: lyx::frontend::GuiApplication::notify(QObject*, QEvent*) ( 30) /lib64/libQt6Core.so.6: QCoreApplication::notifyInternal2(QObject*, QEvent*) ( 31) /lib64/libQt6Gui.so.6: QGuiApplicationPrivate::processKeyEvent(QWindowSystemInterfacePrivate::KeyEvent*) ( 32) /lib64/libQt6Gui.so.6: QWindowSystemInterface::sendWindowSystemEvents(QFlags) ( 33) /lib64/libQt6Gui.so.6: /lib64/libQt6Gui.so.6(+0x740824) [0x7f7d07940824] ( 34) /lib64/libglib-2.0.so.0: /lib64/libglib-2.0.so.0(+0x5c68c) [0x7f7d0690f68c] ( 35) /lib64/libglib-2.0.so.0: /lib64/libglib-2.0.so.0(+0xbd788) [0x7f7d06970788] ( 36) /lib64/libglib-2.0.so.0: /lib64/libglib-2.0.so.0(g_main_context_iteration+0x33) [0x7f7d06910b03] ( 37) /lib64/libQt6Core.so.6: QEventDispatcherGlib::processEvents(QFlags) ( 38) /lib64/libQt6Core.so.6: QEventLoop::exec(QFlags) ( 39) /lib64/libQt6Core.so.6: QCoreApplication::exec() ( 40) src/lyx: lyx::frontend::GuiApplication::exec() ( 41) src/lyx: lyx::LyX::exec(int&, char**) ( 42) src/lyx: src/lyx(main+0x45) [0x62248b] ( 43) /lib64/libc.so.6: /lib64/libc.so.6(+0x2a088) [0x7f7d0643d088] ( 44) /lib64/libc.so.6: /lib64/libc.so.6(__libc_start_main+0x8b) [0x7f7d0643d14b] ( 45) src/lyx: src/lyx(_start+0x25) [0x622385] [1]+ Aborted (core dumped) src/lyx -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Layout file format change proposal
On Wed, 2024-03-27 at 11:02 -0400, Scott Kostyshak wrote: > Cool idea, Lorenzo! There have been some discussions in the past on > using standard formats, even for the .lyx file itself. I can see the > advantages of that but I don't know what the cost of converting to > them > is. > > Scott Typical answer to this: https://xkcd.com/927/ :-) It makes sense for us to use a standard format. Some of the questions then are: * which one is chosen (what is the most appropriate for our needs)? * what the are advantages and drawbacks from this change? * what is the transition plan? * what is the effort required for this transition? Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4 RC4
On Sun, 2024-03-24 at 18:36 -0400, Richard Kimberly Heck wrote: > One last RC, just to be on the safe side. > > http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/ > > Please prepare binaries. Built for Fedora/Red Hat: https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/ -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: RC4? [was: Scheduled maintenance of LyX servers (Mar 21, 2024)]
On Sun, 2024-03-24 at 13:12 -0400, Richard Kimberly Heck wrote: > I was about to ask where everyone thinks we stand with that. There > have been some pretty significant bugs, but it seems like everything > has settled now? > > Riki Assuming that you have the time it would be nice to issue another RC. This will create a new baseline to which people can report. So in that regard Pavel's suggestion seems worthwhile. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Copy files to tmp
On Tue, 2024-03-19 at 09:24 +0100, jspi...@gmail.com wrote: > Thanks, this does not seem to be related to external material, > AFAICS. > However, what would help me is a new placeholder, $$OrigAbsName, that > outputs the absolute path to the original filename (see attached). I > know that documenting this for 2.4 is too late, but would you be OK > if I submitted this as a hidden feature and document later? > > Jürgen I am suspicious, in any case it follows my opinion. :-) I think that this is quite reasonable because the feature is self- contained and it does not interfere with other features. So IMHO +1. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: windows preview bug fix
On Tue, 2024-03-12 at 10:37 +0100, Jürgen Spitzmüller wrote: > If nobody beats me to it, I will do it. Thank you Jürgen, I am busy with other issues. Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: windows preview bug fix
On Fri, 2024-02-16 at 15:23 +0200, Idan Pazi wrote: > Encountered the following bug (windows 10, python 3.12) - preview of > math fails: > > graphics\PreviewLoader.cpp (2ef): > > PreviewLoader::finishedInProgress(1): processing failed for py -3 - > > tt $$s/scripts/lyxpreview2bitmap.py --png > > "C:/Users/idank/AppData/Local/Temp/lyx_tmpdir.mzhGYGTpQcAc/lyx_tmpb > > uf0/lyxpreviewuaCFJC.tex" --dpi 137 --fg 00 --bg ff -- > > bibtex="bibtex" > > > Running the command manually gives the problem: > > File "C:\Program Files\LyX > > 2.4\Resources\scripts\lyxpreview_tools.py", line 168, in > > run_command_win32 > > data = data + buffer > > ~^~~~ > > TypeError: can only concatenate str (not "bytes") to str > > > Apparently, the returned value from win32file.ReadFile should be > converted to a string. > Fix patch attached. > Thank you, Idan After our exchange last week I feel inclined to apply this. I am still note sure that this is the right step but clearly it improves the code regarding the previous one. Does any one opposes to this action? Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Mark utf8x as "deprecated" ?
On Tue, 2024-02-27 at 20:11 -0500, Scott Kostyshak wrote: > That is indeed good to know. I don't think we should remove the > support, > just signal to the user that it's not recommended anymore. > > Scott Honestly, I suspect, it probably means that since it works the authors do not care. :-) So probably the first step is to signal that to developers/writers and to see if that it is still needed or a remnant from the past... I am becoming nostalgic with time. :-D Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Failure to compile
I get this at current git:
/home/jamatos/lyx/lyx/src/insets/InsetBibtex.cpp: In member function
‘virtual void lyx::InsetBibtex::docbook(lyx::XMLStream&, const
lyx::OutputParams&) const’:
/home/jamatos/lyx/lyx/src/insets/InsetBibtex.cpp:1223:70: error: ‘class
std::set >’ has no member named
‘contains’
1223 | if
(alreadyOutputDocBookTags.contains(docbookTag)) {
|
^~~~
@Thibaut isn't the contains method C++20?
FWIW I am using gcc 14 (pre-release).
Best regards,
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Mark utf8x as "deprecated" ?
On Mon, 2024-02-26 at 11:20 -0500, Scott Kostyshak wrote: > I do not propose this for now since it is a string change, but should > we > mark utf8x support as deprecated in the dropdown box? Just to give a > hint that it is probably not what users want? If so, should I do this > on > the master branch after 2.4.0 is out so that it will go into effect > for > 2.5.0? Note that I am just suggesting to add the string > "(deprecated)", > and not to remove the support. > > I don't know anything about the technical details, but a utf8x test > started failing after a TL update, and I do not think it is expected > for > it to be fixed. See here: > > > https://github.com/latex3/hyperref/issues/248#issuecomment-1961868947 > > Scott The following Hebrew documents still use it in 2.4: lib/doc/he/Intro.lyx lib/doc/he/Tutorial.lyx lib/examples/he/Example_%28LyXified%29.lyx lib/examples/he/Example_%28raw%29.lyx lib/examples/he/Welcome.lyx FWIW this has not changed since 2.1. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: windows preview bug fix
On Sat, 2024-02-24 at 21:51 +0100, Enrico Forestieri wrote: > Wanting to be very safe, we could use te chardet library for > performing the correct conversion, but if the above is the standard > with python 3 on windows I don't think it is necessary. In [1]: help(str) ... str(object='') -> str str(bytes_or_buffer[, encoding[, errors]]) -> str ... encoding defaults to sys.getdefaultencoding(). errors defaults to 'strict'. ... In [2]: import sys sys.getdefaultencoding() Out[2]: 'utf-8' So probably this should work more time than what I was expecting. :-) This is unexpected and welcome. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: windows preview bug fix
On Sat, 2024-02-17 at 10:41 +0100, Enrico Forestieri wrote: > On Fri, Feb 16, 2024 at 03:28:25PM +0000, José Matos wrote: > > > > On Fri, 2024-02-16 at 15:23 +0200, Idan Pazi wrote: > > > > > > Apparently, the returned value from win32file.ReadFile should be > > > converted to a string. > > > > > Fix patch attached. > > > Thank you, Idan > > > > What is the encoding of the bytes? Is it UTF8? > > If so the patch look right. > > > > @Enrico, what do you think? > > I don't have a native Windows python 3 installation and the python > distributed with LyX on Windows doesn't include PyWin extension > modules. > Thus I cannot test that code. However, I don't think that > win32file.ReadFile() returns utf8. Most probably it returns some 8- > bit > encoding corresponding to the current code page. But, even using > win32file.ReadFileW() (assuming it exists) that would return utf16. > > -- > Enrico @Idan, I agree with Enrico. So I am also puzzled why this works. What is the output that you get from the following code? import sys print(sys.flags.utf8_mode) The UTF-8 mode that was introduced in Python 3.7 and will be the default in Python 3.15. In https://docs.python.org/3/using/windows.html#win-utf8-mode it reads: """ Note Even when UTF-8 mode is disabled, Python uses UTF-8 by default on Windows for: * Console I/O including standard I/O (see PEP 528 for details). * The filesystem encoding (see PEP 529 for details). """ So I am not sure if the code works because of the last remark... -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.4 ready for wayland??
On Sat, 2024-02-17 at 11:35 +0100, Cor Blom wrote: > Hi all, > I wonder how you see the transition to wayland. There are two bugs > that > I think need to be resolved: > > https://www.lyx.org/trac/ticket/12614 > > https://www.lyx.org/trac/ticket/13039 > > Personally I don't think these are showstopper that need to be > resolved > before release, but then some note about lyx not completely ready for > wayland would be a good idea. Maybe with a workaround to force lyx to > run in xwayland, which works fine. > > Kind regards, > > Cor Just as a data point: I commented on both tickets. Either I have no issues or I have no idea of what it should happen (Stockholm syndrome?! :-D ). This is what I am using: Qt Version (run-time): 6.6.1 on platform wayland Qt Version (compile-time): 6.6.1 OS Version (run-time): Fedora Linux 40 (KDE Plasma Prerelease) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: windows preview bug fix
On Fri, 2024-02-16 at 15:23 +0200, Idan Pazi wrote: > > Apparently, the returned value from win32file.ReadFile should be > converted to a string. > Fix patch attached. > Thank you, Idan What is the encoding of the bytes? Is it UTF8? If so the patch look right. @Enrico, what do you think? -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX document gives LaTeX errors of file not found on master
On Tue, 2024-02-13 at 21:45 -0500, Scott Kostyshak wrote: > I just happened to come across the following: > > https://github.com/georgid/PhDThesis/ > > To reproduce on master, clone the above, and open what I think is the > main LyX document: > > PhDThesis_Georgi_Knowledge_based_Lyrics_Tracking.lyx > > On 2.3.x, the document compiles to PDF without error. Note that I > don't > have Helvetica so I replaced that with "default" in two instances. > > When I compile on current master, I get the following as the first > error: > > ! LaTeX Error: File `../pypYIN/report/ISMIR_2017/note_bar_DBN.eps' > not found. > > I don't have time to dig into this, and I understand if no one else > has > time to take a look. > > Scott I confirm what you get. OTHO 2.4 is correct because that path is outside of the repo, I do not have that file. So the surprising part is why does 2.3 works? Actually it does not work. Using 2.3 we get an empty frame in the space where that graphics should be, with the file path displayed instead: ../pypYIN/report/ISMIR_2017/note_bar_DBN.eps 2.4 is more strict and errors out. So this is a different behaviour but not an error/bug of LyX 2.4. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: RC3 Tarballs
On Fri, 2024-02-09 at 20:07 -0500, Richard Kimberly Heck wrote: > Here: > > http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/ > > Please prepare binaries. > > Riki Done for Fedora/RHEL at https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/ It build and works fine. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Regression on master: cannot insert math in a table cell
On Thu, 2024-02-08 at 09:16 +0100, Jürgen Spitzmüller wrote: > Riki, this might warrant a soonish RC3. It's not only math that was > disabled, but also special characters, spacing and others. FWIW I have backported this fix to RC2 (Jürgen's patch applies cleanly) for Fedora/RHEL packages in copr. Unsurprisingly I can confirm that this fixes the problem. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Regression on master: cannot insert math in a table cell
On Wed, 2024-02-07 at 12:49 -0500, Scott Kostyshak wrote: > I cannot get into math mode in a table cell, on current master. Just > in > case it helps, I attach an example (but you can also insert a table > in a > new document yourself instead). > > I can bisect tomorrow if that would help. > > Scott I can confirm, in addition if we use the menu we can see that the whole math insertion section is grayed out. So it seems that this is inadvertently on purpose. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: RC2 Tarballs
On Sun, 2024-02-04 at 22:10 -0500, Richard Kimberly Heck wrote: > are here: > > http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/ > > Please prepare binaries. Done for Fedora/RHEL (distro/archs): Centos-stream+epel-next 8 aarch64 ppc64le x86_64 Centos-stream+epel-next 9 aarch64 ppc64le s390x x86_64 Centos-stream 8 aarch64 ppc64le x86_64 Centos-stream 9 aarch64 ppc64le s390x x86_64 Epel 8 aarch64 x86_64 Epel 9 aarch64 x86_64 Fedora 38 aarch64 ppc64le x86_64 Fedora 39 aarch64 ppc64le x86_64 Fedora rawhide aarch64 ppc64le x86_64 https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/ -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LYX 2.4 RC1 — Unable to export a Lyx archive (zip)
On Wed, 2024-01-31 at 13:27 +0100, Enrico Forestieri wrote: > It is a mess and while adjusting a thing some other thing was > breaking. > I don't plan to look further into it if simply shipping a patched > getopt.py on windows solves the problem ;) As far a I can see I think that problem is from our solution required to support both Python 2 and 3. In this context the Python 3 code seems to be saner, after all that was one of the major reasons to break the backward compatibility between Python 2 and 3. :-) If the easiest, and faster, solution for 2.4 is to ship this interim file I have no issue with that. :-) Regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LYX 2.4 RC1 — Unable to export a Lyx archive (zip)
On Tue, 2024-01-30 at 19:26 +0100, Enrico Forestieri wrote: > For making it work with Python 3 on Windows I had to patch both our > lyxpak.py script and getopt.py from Python. > > Attached you will find the patch to be applied to lyxpak.py, the > patch I > had to apply to getopt.py and the patched version (lyxwin_getopt.py) > that should be distributed with LyX. > > In this way lyxpak.py works for me with both Python 2 and 3, in both > Windows and Linux. The culprit, from your analysis, seems to be that on windows some variables are bytes instead of strings (unicode text on Python 3). Would not it be easier to convert the bytes to unicode, in the cases where we need (read windows), and then it is not necessary to change getopt and friends? I am finishing other tasks and so I had not a proper look into this issue and so I am admit to be wrong. Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.4.0~RC1 hangs on macOS
On Mon, 2024-01-29 at 08:01 +0100, Stephan Witt wrote: > > Yes, the version check in configure.py is executed twice. > The first attempt is the simple call, the 2nd is a python call. > The latter should be made on windows only as it is mentioned in the > comment (~ line 1336). > I’ve made the change and put it in. > > Stephan Thank you Stephan. @Jerry Stephan already fixed this and the bus should be fixed for RC2. Regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LYX 2.4 RC1 — Unable to export a Lyx archive (zip)
On Sat, 2024-01-27 at 20:49 +0100, didiergab...@free.fr wrote:
> 20:37:37.977: Exportation en cours...
> 20:37:37.993: (buffer-export lyxzip)
> 20:37:38.150: python -tt "C:/Users/Didier/AppData/Local/Programs/LyX
> 2.4/Resources/scripts/lyxpak.py" "K:/CPGE/PTSI/DS/DS-2023-
> 2024/DS3/"/"MWE-PDF preview.lyx"
> 20:37:38.375: Traceback (most recent call last):
> 20:37:38.376: File "C:\Users\Didier\AppData\Local\Programs\LyX
> 2.4\Resources\scripts\lyxpak.py", line 396, in
> 20:37:38.377: if not argv[0].startswith("-"):
> 20:37:38.378:^^^
> 20:37:38.378: TypeError: startswith first arg must be bytes or a
> tuple of bytes, not str
> support\Systemcall.cpp (306): Systemcall: 'python -tt
> "C:/Users/Didier/AppData/Local/Programs/LyX
> 2.4/Resources/scripts/lyxpak.py" "K:/CPGE/PTSI/DS/DS-2023-
> 2024/DS3/"/"MWE-PDF preview.lyx"' finished with exit code 1
> Error: Conversion du fichier impossible
The problem here is that argv members are of type bytes instead of
being str (string).
This comes from the fact that the lyxpak.py script has special code to
deal with Python 2 on Windows.
@Enrico could it be that most of the specific windows code is not need
any more with Python 3?
Regards,
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LYX 2.4 RC1 — Unable to export a Lyx archive (zip)
On Sat, 2024-01-27 at 18:12 +0100, didiergab...@free.fr wrote: > Unable to export a Lyx archive (zip)... > Attached here is a screen copy of the error message, as well as the > test file. > On windows 10 pro What do you get from View -> Messages Pane (Affichage -> Panneau des messages)? On Linux I get: 17:28:53.360: Exporting ... 17:28:53.365: (buffer-export lyxgz) 17:28:53.467: python3 -tt "/home/jamatos/lyx/lyx.anon/lib/scripts/lyxpak.py" "/home/jamatos/tmp/inbox/lyx/"/"MWE-PDF preview.lyx" 17:28:53.568: LyX archive "/home/jamatos/tmp/inbox/lyx/MWE-PDF preview.tar.gz" created successfully. 17:28:53.568: lyx2lyx warning: No conversion needed: Target format 620 same as current format! 17:28:53.573: Successful export to format: LyX Archive (tar.gz) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.4.0~RC1 hangs on macOS
On Thu, 2024-01-25 at 04:03 -0700, list_em...@icloud.com wrote: > $ lilypond --version > -bash: lilypond: command not found > > Jerry Thank you. That means that we are misinterpreting its output. I will try to understand why... -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.4.0~RC1 hangs on macOS
On Thu, 2024-01-25 at 03:26 -0700, list_em...@icloud.com wrote: > I did > > ln -s /opt/local/bin/python3 /usr/local/bin/python3 > > and had the same results _except_ for the _first_ time I tried to run > with this link, the OS asked permission to access files in my > Documents folder—this is normal these days when running a program for > the first time, apparently a part of Apple’s security measures. > Subsequent runs did _not_ ask this question, and at that point > behavior was the same as before, including the lilypond nonsense > output when running from a terminal. > > Jerry I am not sure if that is related but let us try to get this first: What do you get from the command line? $ lilypond --version -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: RC1: Unable to read files with accents in names on Windows
On Thu, 2024-01-25 at 10:29 +0100, Enrico Forestieri wrote: > On Thu, Jan 25, 2024 at 09:31:00AM +0100, Enrico Forestieri wrote: > > > > Converting the file to utf-8 encoding everything works fine. > > Fixed at 48a065e8 > > -- > Enrico Thank you. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: RC1: Unable to read files with accents in names on Windows
On Thu, 2024-01-25 at 09:31 +0100, Enrico Forestieri wrote: > After investigating this I now know why. Capturing the generated > script in a file reveals that it is actually encoded in a 8 bit > encoding on Windows, despite the fact that the first line of the > script says it is encoded in utf-8. Basically it comes to the difference between bytes and string. In Python 2 they are the same. In Python 3 the line that states that the content is utf8 is a no-op since all code files need to be in that encoding. https://docs.python.org/3/howto/unicode.html#the-string-type -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.4.0~RC1 hangs on macOS
On Wed, 2024-01-24 at 00:48 -0700, list_em...@icloud.com wrote: > Thanks, el. > > Getting rid of macports for homebrew is not an option for me. > > In my profile file, I have this: > > alias python=/opt/local/bin/python3 > > which is macports. Does LyX see this? This alias points to Python > 3.9.18. There is a utility to switch to other versions. > > I already have the command line tools installed, with Python 3.9.6 at > /usr/bin/phython3. > > I just now tried switching to this line in my profile file: > > alias python=/usr/bin/python3 > > with the same result. > > Remember that LyX 2.3.7 works fine. > > Jerry LyX tells what is the version used in Help->About LyX. Of course that the issue is that if it hangs before you can not see that. Honestly I would be quite surprised if problems comes to be python since reconfigure runs. The issue is why do you get the loop. One idea here is to output the Python version to the reconfigure output. That is quite easy, since we already inside Python. The only thing that looks a bit strange is: """ +checking for "lilypond"... yes + found LilyPond, but could not extract version number. checking for a LilyPond book (LaTeX) -> LaTeX converter... +checking for "lilypond-book"... yes File "/Applications/LyX.app/Contents/MacOS//lilypond-book", line 12 unset DISPLAY ^ SyntaxError: invalid syntax """ This is a shell script that only goes in Mac distribution and the reconfigure code seems to try to run it as Python? -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Poor PDF preview quality - LyX 2.4.0, Release Candidate 1
On Mon, 2024-01-22 at 22:24 +0100, didiergab...@free.fr wrote: > Thank you for your reply. > > I also noticed on this occasion that the export to a Lyx archive does > not work… > I have the following error message (see screenshot) What do you get when you do "Help->About LyX", in French it should be "Aide->À propos de LyX"... -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Ditch alphadin from the distribution
On Mon, 2024-01-22 at 12:38 +0100, Pavel Sanda wrote: > I think you just forgot to run ./autogen.sh first... > > Pavel You are right. I always forget when I need to do that. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Ditch alphadin from the distribution
On Sat, 2024-01-20 at 14:20 +0100, Juergen Spitzmueller wrote: > commit c7f6846bbe007af3d6010339eb48147f6236cdf4 > Author: Juergen Spitzmueller > Date: Sat Jan 20 15:47:56 2024 +0100 > > Ditch alphadin from the distribution > > lib/doc/Makefile.am | 1 - > lib/doc/UserGuide.lyx | 8 +- > lib/doc/ar/UserGuide.lyx | 8 +- > lib/doc/biblio/alphadin.bst | 1665 - > -- > lib/doc/de/UserGuide.lyx | 8 +- > lib/doc/es/UserGuide.lyx | 9 +- > lib/doc/fr/UserGuide.lyx | 13 +- > lib/doc/ja/UserGuide.lyx | 18 +- > lib/doc/ru/UserGuide.lyx | 19 +- > 9 files changed, 55 insertions(+), 1694 deletions(-) Just to report that now the autotools build fail to compile: make[3]: Entering directory '/home/jamatos/tmp/build/lyx/lib/doc' make[3]: *** No rule to make target 'biblio/alphadin.bst', needed by 'all-am'. Stop. Removing that reference from the corresponding Makefile.in solves the issue, but I do not understand where the comes from Makefile.am. For me the autotools always looked like black magic. :-) Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: RC1!!
On Thu, 2024-01-18 at 23:30 +0100, Pavel Sanda wrote: > I am completely fine if you want to ditch that. > > Pavel I agree. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 1.0
On Tue, 2023-01-10 at 11:36 +0100, Jean-Marc Lasgouttes wrote: > Hi there, > > This LyX 1.0 file from Patrick is not readable with current versions. > Experiments show that lyx2lyx first complains about a malformed file > when converting to LyX 1.4. > > I do not know how to go further, though. > > Ideas? > > JMarc For some reason it seems that I left this unanswered. :-( The original files seems to be really truncated. If you look into a file from that time all of them end with... \the_end That is what the conversion step in 1.4 is complaining about. This files does not have that and so I assume that the problem comes from the time when the file was saved. I can recover what is there but that needs to be done by hand. PS: I noticed this thread when comparing the time spent by lyx2lyx based on the Python version used. In this case the result was converting the 2.3 User Guide to the 2.4 file format. Basically the last versions of python (3.11 and 3.12) run ~ 8 times faster than with python 2.7. -- José Abílio lyx2lyx_times.pdf Description: Adobe PDF document -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: RC1!!
On Thu, 2024-01-11 at 11:14 -0500, Richard Kimberly Heck wrote: > Here: > > http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/ > > Please build binaries. > > Riki Built for Centos-stream+epel-next 8; Centos-stream+epel-next 9; Centos- stream 8; Centos-stream 9; Epel 8; Epel 9; Fedora 38; Fedora 39; Fedora 40 (rawhide). For each of these it was built on aarch64; ppc64le and x86_64. https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Fix lyxpak to be Python 3 compatible
On Wed, 2023-12-06 at 14:21 -0500, Scott Kostyshak wrote: > Thanks for the quick fix! > > It's in master at 9143878e. > > Next time, it might be easier if you make the patch with > > git format-patch HEAD^ > > This way you can add a commit message. > > Scott Thank you for the hint. I will use it. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0 Schedule
On Fri, 2023-12-22 at 13:40 +0100, Daniel wrote: > RC2? I seem to have missed RC1. Where can I get it? It seems not to > be on the ftp server. > > Daniel That is of course RC1, since the current development version is named Version 2.4.0~RC1.devel (not released yet) I suspect that Riki simply took that as ++Version. OTOH if the next release is RC2 I will not complain, as long as the next one is RC3 and not RC2.1 . :-D :-p Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0 Schedule
On Wed, 2023-12-20 at 20:47 -0500, Richard Kimberly Heck wrote: > I've sent a note to the translators making one final call for > translations, asking for them to be delivered by the New Year. > Shortly > after that, I will package RC2, and hopefully we can aim at an actual > release by the end of January. > > Riki Woohoo! Christmas is coming earlier here. :-D PS: In the process I found that a woo woo is an alcoholic cocktail: https://en.wikipedia.org/wiki/Woo_woo Not necessarily my choice but appropriate in this case. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Fix lyxpak to be Python 3 compatible
Based on the error reported on the lyx-users here follows a fix for
issue reported.
I took the change and I changed some minor annoyances:
* test comparison with None;
* fixed a region where the indentation was different from all the
others (2 spaces instead of 4);
* replaced xrange with range.
Could someone, please, commit this?
Regards,
--
José Abílio
diff --git a/lib/scripts/lyxpak.py b/lib/scripts/lyxpak.py
index affef65644..6cdea5c53f 100755
--- a/lib/scripts/lyxpak.py
+++ b/lib/scripts/lyxpak.py
@@ -233,7 +233,7 @@ def find_lyx2lyx(progloc, path):
if "PATHEXT" in os.environ:
extlist = extlist + os.environ["PATHEXT"].split(os.pathsep)
lyx_exe, full_path = find_exe(["lyxc", "lyx"], extlist, path)
-if lyx_exe == None:
+if lyx_exe is None:
error('Cannot find the LyX executable in the path.')
try:
cmd_stdout = subprocess.check_output([lyx_exe, '-version'], stderr=subprocess.STDOUT)
@@ -265,9 +265,9 @@ def main(args):
ourprog = args[0]
try:
- (options, argv) = getopt(args[1:], "htzl:o:")
+(options, argv) = getopt(args[1:], "htzl:o:")
except:
- error(usage(ourprog))
+error(usage(ourprog))
# we expect the filename to be left
if len(argv) != 1:
@@ -278,19 +278,19 @@ def main(args):
lyx2lyx = None
for (opt, param) in options:
- if opt == "-h":
-print(usage(ourprog))
-sys.exit(0)
- elif opt == "-t":
-makezip = False
- elif opt == "-z":
-makezip = True
- elif opt == "-l":
-lyx2lyx = param
- elif opt == "-o":
-outdir = param
-if not os.path.isdir(unicode(outdir, 'utf-8')):
- error('Error: "%s" is not a directory.' % outdir)
+if opt == "-h":
+print(usage(ourprog))
+sys.exit(0)
+elif opt == "-t":
+makezip = False
+elif opt == "-z":
+makezip = True
+elif opt == "-l":
+lyx2lyx = param
+elif opt == "-o":
+outdir = param
+if not os.path.isdir(unicode(outdir, 'utf-8')):
+error('Error: "%s" is not a directory.' % outdir)
lyxfile = argv[0]
if not running_on_windows:
@@ -320,7 +320,7 @@ def main(args):
path = os.environ["PATH"].split(os.pathsep)
-if lyx2lyx == None:
+if lyx2lyx is None:
lyx2lyx = find_lyx2lyx(ourprog, path)
# Initialize the list with the specified LyX file and recursively
@@ -390,7 +390,7 @@ if __name__ == "__main__":
argc = c_int(0)
argv_unicode = CommandLineToArgvW(GetCommandLineW(), byref(argc))
# unicode_argv[0] is the Python interpreter, so skip that.
-argv = [argv_unicode[i].encode('utf-8') for i in xrange(1, argc.value)]
+argv = [argv_unicode[i].encode('utf-8') for i in range(1, argc.value)]
# Also skip option arguments to the Python interpreter.
while len(argv) > 0:
if not argv[0].startswith("-"):
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ctests failing on current master
On Sun, 2023-12-03 at 10:55 +0100, Kornel Benko wrote: > Thanks. I wonder if some unified diff would be worth the struggle for > the error message. > > Kornel It gives more context and that is always a good thing for tests. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ctests failing on current master
On Sun, 2023-12-03 at 10:07 +0100, Kornel Benko wrote: > The only difference in the "roundtrip" for style 'Enumerate' is > > < Requires "" 1"" > > Requires " 1" The first line seems problematic. Does that corresponds to 3 arguments? Does this only show in the tests or is this construct used in our layouts? -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: PDF conversion error
On Sat, 2023-12-02 at 11:25 -0500, T Rex wrote: > sorry, I see that it was treated Yes, we need to move this to the first place in our FAQ. :-D Question: What should I do since I have the XYZ problem? Answer: It is probably fixed in 2.4.0 version, please check there. In this particular case the code ran in Python 2 although it was not doing what we expected it to do. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: It is that time of year again :-)
On Thu, 2023-11-23 at 12:34 +0100, Jean-Marc Lasgouttes wrote: > You are not allowed to answer “yes” to a question with an “or” in it. > > And the “As far as I can see” is not enough to cover up your tracks. > ;) > > JMarc Are you implying that I need to read your messages carefully? ;-) As a scientist that was a challenge: 1) make distclean 2) ccache -c 3) .../configure --with-version-suffix=-devel --enable-qt6 4) make -j15 and so running with gcc-13.2.1 there are no warnings. Are you happy now? :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: It is that time of year again :-)
On Wed, 2023-11-22 at 22:03 +0100, Jean-Marc Lasgouttes wrote: > Does it mean that the annoying warning with QByteArray that we get > with > gcc 13 is fixed in Qt 6.6 or that it is fixed in gcc 14? > > JMarc As far as I can see, yes. With that said I could say that those issues are hidden to haunt us later, but then that would be Halloween (so I would be in the wrong holiday :-) ). FWIW I was (pleasantly) quite surprised with the result. Of course we still have Christmas. :-) """ “Why do programmers always mix up Halloween and Christmas?” “Because Oct 31 = Dec 25.” """ In the interest of full disclosure I should say that I can not run the resulting executable: $ src/lyx src/lyx: /lib64/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by src/lyx) The one that I have installed in the system only provides until 1.3.14. Oh, scratch that, I can override the library load path. I did not do this for a long time so I forgot the right recipe: $ LD_LIBRARY_PATH=/opt/gcc-latest/lib64/ src/lyx works as it should. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
It is that time of year again :-)
Hi, no, no I am not talking about the Thanksgiving. I wish a good holiday to those who celebrate and a good day to everyone. :-) Regarding the issue that brings me here, the output of config.log is: Configuration Host type: x86_64-pc-linux-gnu Special build flags: build=development warnings assertions stdlib-assertions callback-printing use-hunspell use-enchant Bundled libraries:nod C++ Compiler:/opt/gcc-latest/bin/g++ (14.0.0) C++ Compiler flags: -Wall -Wextra -fPIC -g -O -std=c++17 -Wno- deprecated-copy C++ Compiler user flags: Linker flags: -rdynamic Linker user flags: Qt Frontend: Qt version: 6.6.0 Packaging: posix LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx-devel Notice the latest gcc. This time around there is no new warning cropping up (actually with these settings there is no warning at all). Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Deprecated functions with lyx-2.3.7dev
On Fri, 2023-11-10 at 12:18 +0100, Pavel Sanda wrote: > If it's only about warnings, I wouldn't touch 2.3. I agree. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Re: New warning (or at least I only noticed it now)
On Thu, 2023-11-09 at 20:34 +0100, Pavel Sanda wrote: > Looks reasonable. Pavel I agree. After so many dark spells I fear for Jean-Marc's sanity. :-D -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Europe CV not compiling
On Tue, 2023-10-10 at 23:58 +0200, Dan wrote: > Hello, > > I stumbled upon a problem compiling with pdflatex the "Europe CV" > example. I get the following error, in both languages available: > Spanish and English. > Can someone try and reproduce the problem so that I know whether it > is specific to me or the document itself? Thanks. > > PROBLEM > --- > 1. File > Open Examples... > Europe CV. > 2. Generate the preview of the document. > 3. Check whether the following error arises. I get this error repeated several times: ! LaTeX hooks Error: Sorting rule for 'begindocument' hook applied too late. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Evolution of the time used by lyx2lyx based on the Python version used
On Tue, 2023-10-10 at 15:24 -0400, Scott Kostyshak wrote: > From what I understand, this means we haven't spent enough time > optimizing the code for 2.7. ;) This should be a development goal as soon as 2.4 is released. :-D -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Evolution of the time used by lyx2lyx based on the Python version used
Just for fun I ran the conversion of the 2.3 User Guide to the 2.4
format. In order to do that I used the several versions of Python that
I have available since lyx2lyx only uses the standard library:
[jamatos@griffin ~]$ for v in 2 3.{6..12};
do echo -n $v; time python$v /usr/share/lyx-devel/lyx2lyx/lyx2lyx -o
/dev/null /usr/share/lyx/doc/UserGuide.lyx; done
2
real0m1.487s
user0m1.449s
sys 0m0.037s
3.6
real0m0.294s
user0m0.273s
sys 0m0.020s
3.7
real0m0.262s
user0m0.236s
sys 0m0.025s
3.8
real0m0.209s
user0m0.193s
sys 0m0.016s
3.9
real0m0.220s
user0m0.202s
sys 0m0.019s
3.10
real0m0.239s
user0m0.221s
sys 0m0.019s
3.11
real0m0.204s
user0m0.179s
sys 0m0.024s
3.12
real0m0.179s
user0m0.165s
sys 0m0.015s
So as you can see Python 3.12 is 8.78 times faster than Python 2.7.
Of course this is just for conversion, also running this several times
the results change but the general picture is the same.
PS: Yes, I am using bash. :-)
Regards,
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Added some options to configure.py allowing for faster partial-reconfigures.
On Mon, 2023-10-09 at 07:36 +, Isaac Oscar Gariano wrote: > > It would be nice to be able to select these options from the GUI > > when > > you click the reconfigure button, so if someone familiar with the > > GUI > > code can do that, it would be very helpfull! > > > > > > — Isaac Oscar Gariano As a first reaction your changes provide better control for configure and they are worth having. In order to take a cautious stance we should leave them out of 2.4.0 and consider them to 2.4.1 or 2.4.2. OTHO IMHO (I am missing other acronyms to add) this does not need to be accessible through the GUI. Most of the time you want the default procedure, it is slow but it does what you want. The use of these options inside LyX should depend on the actual context. That would mean that in your particular case the option to only rebuild the modules part should be in the modules related interface. In this case this will take time and it should be done in a incremental way (and so it will take some time). So I support the inclusion of this change that initially it is only accessible through the command line. That was the principle that I have used in lyx2lyx that has more options than those that LyX provides directly. And some of those were only used from LyX several years (and releases) after being in lyx2lyx. Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: metainfo and cmake
On Fri, 2023-10-06 at 11:09 +0200, Kornel Benko wrote: > Should we rename this file on install to be able to install multiple > lyx-versions? > Like "org.lyx.LyX.metainfo.xml" -> "LyX2.4.metainfo.xml" > if using versioned suffixes? > > Kornel Using my blue hat here (Fedora). :-) Although I am not using cmake (yet!) I prefer to have the simple version. When I need to take care of another version I prefer to do it myself. Looking into the system directory (/usr/share/metainfo/) I do not see any versioned file. My two ¢. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
2.4.0 with qt6
My setup: Version 2.4.0~RC1.devel (not released yet) Built from git commit hash 73e588bd Qt Version (run-time): 6.5.2 on platform wayland Qt Version (compile-time): 6.5.2 OS Version (run-time): Fedora Linux 39 (KDE Plasma Prerelease) Python detected: 3.12.0 (/usr/bin/python3) Today was the first time that I tried LyX with Qt 6 and I was amazed by the look and feel of it. Thanks to all you for the good work with this integration. In particular I will, most probably, switch from qt5 to qt6, for the Fedora builds, when 2.4 is released. Is there any particular issue that I should be aware? Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Introduce default box frame color (#12921)
On Sat, 2023-09-30 at 13:08 +0200, Jürgen Spitzmüller wrote: > Not my doing, but I fixed it. I know, thank you. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Introduce default box frame color (#12921)
On Sat, 2023-09-30 at 08:38 +0200, Juergen Spitzmueller wrote:
>
> Introduce default box frame color (#12921)
>
> This better aligns with dark mode
Hi Jürgen,
what I am about to report is unrelated to this file format change. I
have just noticed it because of it.
When opening a file I got a warning:
.../lib/lyx2lyx/lyx_2_4.py:4714:
SyntaxWarning: invalid escape sequence '\h'
cmd = "\href{" + target + "}{" + name + "}"
the problem is the \h.
The two possible solutions are:
to change "\href{" to either r"\href{" or "\\href{".
I prefer the former because the code becomes easier to read but any
option will fix the warning.
FWIW the code works because there is no \h escape sequence but, in any
case, it is better to fix this.
Best regards,
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
