Am Mo., 3. Juni 2024 um 06:00 Uhr schrieb Richard Kimberly Heck <
rikih...@gmail.com>:
> On 6/2/24 23:07, Richard Kimberly Heck wrote:
> > commit 3e796c680a11593bd09433be22bec45dcfe0d7a7
> > Author: Richard Kimberly Heck
> > Date: Sun Jun 2 14:12:23 2024 -0400
> >
> > Fix table crash report
On 6/2/24 23:07, Richard Kimberly Heck wrote:
commit 3e796c680a11593bd09433be22bec45dcfe0d7a7
Author: Richard Kimberly Heck
Date: Sun Jun 2 14:12:23 2024 -0400
Fix table crash reported on Windows.
I did not mean to commit this yet. But I am pretty sure it is right, so
won't revert.
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 anythin
A simple thank you all
Mark
The more you know, the more you realise how little you know
One earth, one family, one future…
> On 1 Jun 2024, at 05:24, Murat Yildizoglu wrote:
>
> Congratulations and our gratitude for the magnificent team of developers!
> Best regards to all.
> Murat
>
> --
>
On 6/2/24 17:49, Andrew Parsloe wrote:
On 3/06/2024 4:32 am, Richard Kimberly Heck wrote:
We've had a report of the following sort of crash, or maybe assertion.
Create a table. Mark more than half the rows or columns. Delete those
(using the toolbar button, but I doubt that matters). Boom.
I
On 6/2/24 15:46, Yu Jin wrote:
Am So., 2. Juni 2024 um 20:14 Uhr schrieb Richard Kimberly Heck:
On 6/2/24 14:12, Yu Jin wrote:
Thanks.
The attached should fix it, I think.
Confirmed, your patch makes first column undeletable though:
Try this one. Silly mistake.
Riki
From db832
On Sun, Jun 02, 2024 at 12:20:39PM +0200, Pavel Sanda wrote:
Could you make it available with few comments about build/install?
Sure.
This could go either to our wiki (with deps and packages into wiki-uploads.git)
or it could go into https://www.lyx.org/misc/archaeology/
(www-user.git:/misc/a
On 3/06/2024 4:32 am, Richard Kimberly Heck wrote:
We've had a report of the following sort of crash, or maybe assertion.
Create a table. Mark more than half the rows or columns. Delete those
(using the toolbar button, but I doubt that matters). Boom.
I cannot reproduce on Linux, but Eugene w
Am So., 2. Juni 2024 um 20:14 Uhr schrieb Richard Kimberly Heck:
> On 6/2/24 14:12, Yu Jin wrote:
>
> Thanks.
>
> The attached should fix it, I think.
>
Confirmed, your patch makes first column undeletable though:
[image: image.png] ->
[image: image.png]
And if I just put the cursor into "a" and
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/
On 6/2/24 14:12, Yu Jin wrote:
Am So., 2. Juni 2024 um 19:59 Uhr schrieb Richard Kimberly Heck:
On 6/2/24 13:18, Udicoudco wrote:
> On Sun, Jun 2, 2024 at 7:53 PM Richard Kimberly Heck wrote:
>> On 6/2/24 12:35, Udicoudco wrote:
>>> On Sun, Jun 2, 2024 at 7:32 PM Richard Kimberly
Am So., 2. Juni 2024 um 19:59 Uhr schrieb Richard Kimberly Heck:
> On 6/2/24 13:18, Udicoudco wrote:
> > On Sun, Jun 2, 2024 at 7:53 PM Richard Kimberly Heck wrote:
> >> On 6/2/24 12:35, Udicoudco wrote:
> >>> On Sun, Jun 2, 2024 at 7:32 PM Richard Kimberly Heck wrote:
> We've had a report of
Le 02/06/2024 à 19:37, Richard Kimberly Heck a écrit :
Right. I think -dbg any loads absolutely every layout file it can find.
If the layout formats are not up to date, that is going to take even
longer than it otherwise would.
I don't think caching previous loads is possible. Some of them may
On 6/2/24 13:18, Udicoudco wrote:
On Sun, Jun 2, 2024 at 7:53 PM Richard Kimberly Heck wrote:
On 6/2/24 12:35, Udicoudco wrote:
On Sun, Jun 2, 2024 at 7:32 PM Richard Kimberly Heck wrote:
We've had a report of the following sort of crash, or maybe assertion.
Create a table. Mark more than h
On 6/2/24 13:23, José Matos wrote:
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 s
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
On Sun, Jun 2, 2024 at 7:53 PM Richard Kimberly Heck wrote:
>
> On 6/2/24 12:35, Udicoudco wrote:
> > On Sun, Jun 2, 2024 at 7:32 PM Richard Kimberly Heck
> > wrote:
> >> We've had a report of the following sort of crash, or maybe assertion.
> >>
> >> Create a table. Mark more than half the rows
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.
On 6/2/24 12:45, José Matos wrote:
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.c
I can reproduce on MacOS
Version 2.4.0~RC4
(March 24, 2024)
Qt Version (run-time): 5.15.13 on platform cocoa
Qt Version (compile-time): 5.15.13
OS Version (run-time): macOS 11.6
Python detected: 3.10.1 (/usr/local/bin/python3)
John
( 1) 1 lyx 0x00010d3e6cd
On 6/2/24 12:35, Udicoudco wrote:
On Sun, Jun 2, 2024 at 7:32 PM Richard Kimberly Heck wrote:
We've had a report of the following sort of crash, or maybe assertion.
Create a table. Mark more than half the rows or columns. Delete those
(using the toolbar button, but I doubt that matters). Boom.
Apparently, the German version of the "additional software" page on our
website still recommends MiKTeX for Windows. It looks like the Spanish
version also does so. In any event, the point is that it's out of sync
with the English version. I would guess there are other issues like
this. What to
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 wh
On Sun, Jun 2, 2024 at 7:32 PM Richard Kimberly Heck wrote:
>
> We've had a report of the following sort of crash, or maybe assertion.
>
> Create a table. Mark more than half the rows or columns. Delete those
> (using the toolbar button, but I doubt that matters). Boom.
>
> I cannot reproduce on L
We've had a report of the following sort of crash, or maybe assertion.
Create a table. Mark more than half the rows or columns. Delete those
(using the toolbar button, but I doubt that matters). Boom.
I cannot reproduce on Linux, but Eugene was able to reproduce on
Windows. Anyone else?
Rik
Am Sonntag, dem 02.06.2024 um 17:05 +0200 schrieb Jürgen Spitzmüller:
> Am Sonntag, dem 02.06.2024 um 16:28 +0200 schrieb Pavel Sanda:
> > ./lyx -dbg any
> > ends up in infinite layout2layout conversion loop (strangely it
> > does
> > not when running without -dbg).
> > Did we forget to update layo
Am Sonntag, dem 02.06.2024 um 16:28 +0200 schrieb Pavel Sanda:
> ./lyx -dbg any
> ends up in infinite layout2layout conversion loop (strangely it does
> not when running without -dbg).
> Did we forget to update layout format number with some recent
> feature?
I stepped the format number at 2a7ec05
Hi,
./lyx -dbg any
ends up in infinite layout2layout conversion loop (strangely it does not when
running without -dbg).
Did we forget to update layout format number with some recent feature?
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am Sonntag, dem 02.06.2024 um 14:44 +0200 schrieb Kornel Benko:
> If 2.4.x will become 2.4.1, what happens with 2.4.1~devel?
2.4.2, I suppose. But only in case we need an emergency release.
--
Jürgen
signature.asc
Description: This is a digitally signed message part
--
lyx-devel mailing list
Le 02/06/2024 à 15:18, Jean-Marc Lasgouttes a écrit :
Le 02/06/2024 à 14:44, Kornel Benko a écrit :
This is very confusing.
If 2.4.x will become 2.4.1, what happens with 2.4.1~devel?
It will go to 2.4.2.
The 2.4.1-devel branch is "next stable release which is not an emergency
release".
JM
Le 02/06/2024 à 14:44, Kornel Benko a écrit :
This is very confusing.
If 2.4.x will become 2.4.1, what happens with 2.4.1~devel?
It will go to 2.4.2.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am Thu, 30 May 2024 12:17:15 -0400
schrieb Richard Kimberly Heck :
> On 5/30/24 02:46, Jürgen Spitzmüller wrote:
> > Am Mittwoch, dem 29.05.2024 um 14:50 + schrieb Richard Kimberly
> > Heck:
> >> commit e80fdf38e4dc095316547371d22284676e2e6c7d
> >> Author: Richard Kimberly Heck
> >> Date:
On Sun, Jun 02, 2024 at 12:50:48AM +0200, Enrico Forestieri wrote:
> Of course, you also need Qt3 and corresponding development files. However,
> if you are interested, I can provide everything is necessary:
> $ ls -l /usr/local/src/pkgs/qt3/
> totale 9344
> -rw-r--r-- 1 ef 137708 6 ago 2015 lib
On Mon, May 20, 2024 at 11:55:39AM -0400, Richard Kimberly Heck wrote:
> On 5/20/24 09:48, Pavel Sanda wrote:
> > On Mon, May 20, 2024 at 03:24:30AM +0200, Thibaut Cuvelier wrote:
> > > > InsetInfo shortcuts export to xhtml is borken compared to 2.3.
> > > >
> > > > In 2.3 we exported: Ctrl+N
> >
34 matches
Mail list logo
