gnumeric issueshttps://gitlab.gnome.org/GNOME/gnumeric/-/issues2024-02-29T10:03:33Zhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/591deco-Math project, step 00_a: exact bin and dec 'ranges' (in gnumeric). - enh...2024-02-29T10:03:33Zb. s.deco-Math project, step 00_a: exact bin and dec 'ranges' (in gnumeric). - enhancement request -on 2021-07-04 i asked in gnumeric-list if somebody can help to implement such, the response was ~ not overwhelming ~ but provided some good tips from @John Denker and @Morten,
target is to have functions 'bin_range' and 'dec_range' (...on 2021-07-04 i asked in gnumeric-list if somebody can help to implement such, the response was ~ not overwhelming ~ but provided some good tips from @John Denker and @Morten,
target is to have functions 'bin_range' and 'dec_range' (or similar) which switch exactly with the binary and decimal range borders at 0,25; 0,5 ;1; 2; 4 ... and 0,01; 0,1; 1; 10; 100 ... and avoid the small imprecisions of 'LOG' calculations just below range borders. (to reach good precision in general it has to start in the elementary functionalities.)
in the meantime i tried coding it myself and think it works (gnumeric is somewhat 'programmer friendlier' than LO Calc?), but i had my system already pested / improved with some other precision patches, in this respect, surprises may well still hinder the solution,
i'll try to push it into the master, and kindly ask for:
a: a thorough survey,
b: hints for improvements / style / usances,
c: hints if and where i have to care for long doubles and similar,
d: help to get it 'up and running' as it's helpful for other improvements i'm working on ...
best regards,
b.https://gitlab.gnome.org/GNOME/gnumeric/-/issues/689math: LOG10 weak with gnumeric-LONG?, log10( 10000000 ) -> 7.0000000000000000...2024-02-28T19:34:48Zb. s.math: LOG10 weak with gnumeric-LONG?, log10( 10000000 ) -> 7.000000000000000000**4**, why?Have seen above producing a test fail with gnumeric-LONG, tried to dig down:
sheet: `=log10( 10000000 )` -> '7', but if you widen the cell (format still general ):
-> 7.000000000000000000**4** for all variants with log( x, 10 ), l...Have seen above producing a test fail with gnumeric-LONG, tried to dig down:
sheet: `=log10( 10000000 )` -> '7', but if you widen the cell (format still general ):
-> 7.000000000000000000**4** for all variants with log( x, 10 ), log10( 10^7 ) ...
[edit] masked out a longer detour I got into because my compiler works differently for
`"log10l( 10000000 )"` versus
`long double aL = 10000000;`
`"log10l( aL )"`
<details><summary>error based on 'cheating' compiler - Click to expand</summary>
Request for help, same on other systems? Or single fail here?
same machine, C-code `printf( "log10l( 10000000 ) : %.25LE\n", log10l( 10000000 ) );`
-> log10l( 10000000 ) : 7.000000000000000000**0**000000E+00
also with all variants like '10000000L', '10000000.0L', pow( 10.0L, 7.0L ) ...
add. info:
compiled --with-long-double,
gnumeric-config.h: #define HAVE_LOG10L 1
gnumeric-features.h: #define HAVE_LOG10L 1
in general sheet handles long double precision,
calling chain IMHO:
gnumeric/plugins/fn-math/functions.c/gnumeric_log10:
-> gnm_log10,
gnumeric/src/numbers.h in '#ifdef GNM_WITH_LONG_DOUBLE' section:
#define gnm_log10 log10l
and that should be above C-code 'log10l', but I get different results in sheet,
snippets:
goffice not involved?
other logs / powers affected too, some, not all,
no such simple fails with gnumeric-double,
functions.c has math.h included, numbers.h hasn't,
I get 7.000000000000000000**4** as result of log(10000000)/log(10),
but not for ln(10000000)/ln(10),
my system IS! pested with patches here, trials there, WIP all around,
but above fail is old, persistent, since long time in all long installations and versions,
also where I tried to produce / keep clean vanilla installations,
bt with =log10(10000000) in single cell:
```
^C
Thread 1 "gnumeric" received signal SIGINT, Interrupt.
0x00007ffff6c7f32f in __GI___poll (fds=0x55555571ae30, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
(gdb) bt
#0 0x00007ffff6c7f32f in __GI___poll (fds=0x55555571ae30, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x00007ffff6dd893e in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff6dd8c7f in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff726e265 in gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#4 0x0000555555557d50 in main (argc=<optimized out>, argv=<optimized out>) at main-application.c:343
```
bt breaking fill =log10(10000000) to the whole sheet:
```
^C
Thread 1 "gnumeric" received signal SIGINT, Interrupt.
_int_malloc (av=av@entry=0x7ffff6d75c60 <main_arena>, bytes=bytes@entry=2080) at ./malloc/malloc.c:4377
4377 ./malloc/malloc.c: No such file or directory.
(gdb) bt
#0 _int_malloc (av=av@entry=0x7ffff6d75c60 <main_arena>, bytes=bytes@entry=2080) at ./malloc/malloc.c:4377
#1 0x00007ffff6c17f7f in _int_memalign (av=av@entry=0x7ffff6d75c60 <main_arena>, alignment=alignment@entry=1024, bytes=bytes@entry=1008) at ./malloc/malloc.c:4963
#2 0x00007ffff6c1864a in _mid_memalign (alignment=alignment@entry=1024, bytes=bytes@entry=1008, address=<optimized out>) at ./malloc/malloc.c:3565
#3 0x00007ffff6c19c5f in __posix_memalign (size=1008, alignment=1024, memptr=0x7fffffffc960) at ./malloc/malloc.c:5685
#4 __posix_memalign (memptr=0x7fffffffc960, alignment=1024, size=1008) at ./malloc/malloc.c:5669
#5 0x00007ffff6df67e4 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007ffff6df7416 in g_slice_alloc () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#7 0x00007ffff7bcd8a7 in cell_new () at sheet.c:4632
#8 sheet_cell_create (sheet=sheet@entry=0x5555555a6230, col=98, row=58599) at sheet.c:4713
#9 0x00007ffff7bcda21 in sheet_cell_fetch (sheet=sheet@entry=0x5555555a6230, col=<optimized out>, row=<optimized out>) at sheet.c:2225
#10 0x00007ffff7af4718 in paste_cell (dat=0x7fffffffcb50, src=0x5555557dfc48, target_row=<optimized out>, target_col=<optimized out>) at clipboard.c:273
#11 cb_paste_cell (src=0x5555557dfc48, ignore=<optimized out>, dat=0x7fffffffcb50) at clipboard.c:379
#12 0x00007ffff6dc67a0 in g_hash_table_foreach () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007ffff7af5175 in clipboard_paste_region (cr=0x5555557d5a90, pt=pt@entry=0x55555626f100, cc=0x55555592e040) at clipboard.c:625
#14 0x00007ffff7aff15d in cmd_paste_copy_impl (cmd=0x55555626f0b0, wbc=0x55555592e040, is_undo=0) at commands.c:3002
#15 0x00007ffff7b03ce6 in gnm_command_push_undo (wbc=wbc@entry=0x55555592e040, obj=0x55555626f0b0) at commands.c:729
#16 0x00007ffff7b058a2 in cmd_paste_copy (wbc=wbc@entry=0x55555592e040, pt=pt@entry=0x7fffffffcd30, cr=<optimized out>) at commands.c:3239
#17 0x00007ffff7af6cc6 in cmd_paste (wbc=0x55555592e040, pt=0x7fffffffcd30) at cmd-edit.c:349
#18 0x00007ffff7af6e0d in cmd_paste_to_selection (wbc=0x55555592e040, dest_sv=0x5555558f40d0, paste_flags=163869) at cmd-edit.c:378
#19 0x00007ffff6ed2500 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 0x00007ffff6ee5b46 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#21 0x00007ffff6eec6c5 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#22 0x00007ffff6eec88f in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#23 0x00007ffff70d5800 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#24 0x00007ffff70d5d89 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#25 0x00007ffff6ed2500 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#26 0x00007ffff6ee5b46 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#27 0x00007ffff6eebefd in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#28 0x00007ffff6eec88f in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#29 0x00007ffff712e338 in gtk_accel_group_activate () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#30 0x00007ffff712fbe5 in gtk_accel_groups_activate () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#31 0x00007ffff73dc8ee in gtk_window_activate_key () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#32 0x00007ffff73dcbb1 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#33 0x00007ffff740d144 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#34 0x00007ffff6ed26f9 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#35 0x00007ffff6eebb2e in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#36 0x00007ffff6eec88f in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#37 0x00007ffff73b7554 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#38 0x00007ffff726d6ff in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#39 0x00007ffff726f066 in gtk_main_do_event () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#40 0x00007ffff6f575a5 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#41 0x00007ffff6f8b5b2 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#42 0x00007ffff6dd8739 in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#43 0x00007ffff6dd89c8 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#44 0x00007ffff6dd8c7f in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#45 0x00007ffff726e265 in gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#46 0x0000555555557d50 in main (argc=<optimized out>, argv=<optimized out>) at main-application.c:343
(gdb)
```
single stepping, looks missing glib sources?
gnumeric-double:
```
Thread 1 "gnumeric" hit Breakpoint 1, gnumeric_log10 (ei=0x7fffffffcbf0, argv=<optimized out>) at functions.c:1532
1532 return value_new_float (gnm_log10 (t));
(gdb) s
__log10 (x=10000000) at ./math/w_log10_compat.c:30
30 ./math/w_log10_compat.c: No such file or directory.
(gdb) s
44 in ./math/w_log10_compat.c
(gdb) s
__ieee754_log10 (x=10000000) at ../sysdeps/ieee754/dbl-64/e_log10.c:64
64 ../sysdeps/ieee754/dbl-64/e_log10.c: No such file or directory.
(gdb) s
67 in ../sysdeps/ieee754/dbl-64/e_log10.c
... 4 times more ...
(gdb) s
87 in ../sysdeps/ieee754/dbl-64/e_log10.c
(gdb) s
__ieee754_log_fma (x=1.1920928955078125) at ../sysdeps/ieee754/dbl-64/e_log.c:56
56 ../sysdeps/ieee754/dbl-64/e_log.c: No such file or directory.
(gdb) s
asuint64 (f=1.1920928955078125) at ../sysdeps/ieee754/dbl-64/math_config.h:63
63 ../sysdeps/ieee754/dbl-64/math_config.h: No such file or directory.
(gdb) s
__ieee754_log_fma (x=1.1920928955078125) at ../sysdeps/ieee754/dbl-64/e_log.c:57
57 ../sysdeps/ieee754/dbl-64/e_log.c: No such file or directory.
(gdb) s
top16 (x=1.1920928955078125) at ../sysdeps/ieee754/dbl-64/math_config.h:68
68 ../sysdeps/ieee754/dbl-64/math_config.h: No such file or directory.
(gdb) s
57 ../sysdeps/ieee754/dbl-64/e_log.c: No such file or directory.
```
single stepping, looks missing glib sources?
gnumeric-long:
```
Thread 1 "gnumeric" hit Breakpoint 1, gnumeric_log10 (ei=0x7fffffffcc00, argv=<optimized out>) at functions.c:1532
1532 return value_new_float (gnm_log10 (t));
(gdb) s
__log10l (x=10000000) at ./math/w_log10l_compat.c:30
30 ./math/w_log10l_compat.c: No such file or directory.
(gdb) s
44 in ./math/w_log10l_compat.c
(gdb) s
__ieee754_log10l () at ../sysdeps/x86_64/fpu/e_log10l.S:31
31 ../sysdeps/x86_64/fpu/e_log10l.S: No such file or directory.
(gdb) s
32 in ../sysdeps/x86_64/fpu/e_log10l.S
... 13 times more ...
(gdb) s
56 in ../sysdeps/x86_64/fpu/e_log10l.S
(gdb) s
__ieee754_log10l () at ../sysdeps/x86_64/fpu/e_log10l.S:57
57 in ../sysdeps/x86_64/fpu/e_log10l.S
(gdb) s
value_new_float (f=7.00000000000000000043) at value.c:119
119 if (gnm_finite (f)) {
(gdb)
```
</details>
[/edit]https://gitlab.gnome.org/GNOME/gnumeric/-/issues/752Copy and paste from Firefox copies too much2024-02-04T00:01:19ZDarrell TangmanCopy and paste from Firefox copies too muchI just installed 1.12.56 to get access to the fix to issue #733, and it mostly fixes the problem I was having. However, when I copy a string such as "$12345.67" from Firefox and paste into a formatted field in gnumeric, the formatting of...I just installed 1.12.56 to get access to the fix to issue #733, and it mostly fixes the problem I was having. However, when I copy a string such as "$12345.67" from Firefox and paste into a formatted field in gnumeric, the formatting of the field changes. It would be nice if there were a way to copy and paste from Firefox that pastes only the string, as it is less work to simply type the new value into the field than it is to paste the new value and then restore the desired format.https://gitlab.gnome.org/GNOME/gnumeric/-/issues/712UI: marking active / focussed cell by 'bordering' partly lost when autofilte...2024-01-12T09:16:30Zb. s.UI: marking active / focussed cell by 'bordering' partly lost when autofilter active,It's weird behavior, sometimes partly in the filtered area,
sometimes partly below, mostly right to the displayed data,
sometimes visible when scrolling up with the cursor key,
and hidden when scrolling down, mostly the color marki...It's weird behavior, sometimes partly in the filtered area,
sometimes partly below, mostly right to the displayed data,
sometimes visible when scrolling up with the cursor key,
and hidden when scrolling down, mostly the color marking of
the column header is kept, while the marking of the row
number disappears or stays with wrong rows ...
In parallel the cell content isn't shown in the cell when
editing such cells ( F2 ), only in the formula bar.
might be dependent of somewhat bigger size of the filtered area!
related to #694 ??https://gitlab.gnome.org/GNOME/gnumeric/-/issues/747Wayland crashes due to events piling up2024-01-09T23:00:41ZJan SchmidtWayland crashes due to events piling upI have had a lot of crashes with gnumeric 1.12.56 exiting with a `Lost connection to Wayland compositor.` message. It doesn't happen if I run with `GDK_BACKEND=x11`.
I usually use large sheets for graphing captured data (multiple sheets...I have had a lot of crashes with gnumeric 1.12.56 exiting with a `Lost connection to Wayland compositor.` message. It doesn't happen if I run with `GDK_BACKEND=x11`.
I usually use large sheets for graphing captured data (multiple sheets of > 64k rows and graphs of the data), and recalculating / updates can often take a long time. I suspect the Wayland compositor is kicking gnumeric off for being unresponsive in some wayhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/691performance: conditional formats problematic2023-11-22T20:26:49Zb. s.performance: conditional formats problematicgnumeric is fantastically fast, I experienced two exceptions:
1. comments,
2. conditional formats,
applying too many of either produces slowsdowns until final freeze,
Test: copy cells B4:C5 on the sheet 'comments' or 'condi...gnumeric is fantastically fast, I experienced two exceptions:
1. comments,
2. conditional formats,
applying too many of either produces slowsdowns until final freeze,
Test: copy cells B4:C5 on the sheet 'comments' or 'conditional_formats' of [performance_problems.gnumeric](/uploads/9e20d720e1610ee6c832ddc86f596662/performance_problems.gnumeric) to B4:C65536
-> stall. ( inserting 5.000 copies needs time but finishes )
<details><summary>add. details - Click to expand</summary>
IMHO it's not a matter of the random cells, the same copy on sheet 'neutral' shows no problem.
Assumption: the data structure for comments and conditional formats or the access to them is not optimized, quadratic explosion?
Importance? The test is an arbitrary stress test, but similar things can happen in normal use. Knowing the reasons I can avoid such structures in my work, but it unexpectedly hits innocent careless users now and then, and can cause data loss. AFAIK gnumeric has no automatic backup before critical actions, and no option to terminate hanging actions 'softly' - without total termination.
If the issue can't be eliminated I would recommend to issue a warning before inserting many cells with comments or conditional formats. </details>https://gitlab.gnome.org/GNOME/gnumeric/-/issues/229Slowness with very large area of conditional formatting2023-11-20T17:31:19ZBugzillaSlowness with very large area of conditional formatting## Submitted by jut..@..il.com
**[Link to original bug (#705927)](https://bugzilla.gnome.org/show_bug.cgi?id=705927)**
## Description
Hang on opening an xlsx file.
Git versions of glib, goffice, gnumeric, libgsf and libxml2.
Test ...## Submitted by jut..@..il.com
**[Link to original bug (#705927)](https://bugzilla.gnome.org/show_bug.cgi?id=705927)**
## Description
Hang on opening an xlsx file.
Git versions of glib, goffice, gnumeric, libgsf and libxml2.
Test case: https://www.fbibiospecs.org/Documents/EBTS_v9_4_Draft_Appendix_20120914.xlsx
The file opens in few seconds in LibreOffice.
After waiting 10+ minutes on gnumeric, gdb says the following:
Program received signal SIGINT, Interrupt.
0x00007ffff39e5ed4 in g_slist_last (list=0x104d88c0) at gslist.c:845
845 while (list->next)
(gdb) step
846 list = list->next;
(gdb)
845 while (list->next)
(gdb)
846 list = list->next;
(gdb)
845 while (list->next)
(gdb)
846 list = list->next;
--
Juha Kylmänen
Research Assistant, OUSPG
Version: git masterhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/743performance: Edit paste significantly slower than competition, growing with f...2023-11-20T16:50:30Zb. s.performance: Edit paste significantly slower than competition, growing with fill of sheet,Copy 4M cells to a new book: ~5.5 minutes,
compared to LO Calc: ~6 seconds.
Think it's not dependent on the formulae, but to provide
reproducer: data structure used for test:
source:
B4: =B3 + 1
C4: =B4^2
D4: =sqrt( C4 )...Copy 4M cells to a new book: ~5.5 minutes,
compared to LO Calc: ~6 seconds.
Think it's not dependent on the formulae, but to provide
reproducer: data structure used for test:
source:
B4: =B3 + 1
C4: =B4^2
D4: =sqrt( C4 )
E4: =D4 = B4
copy B4:E4 ( ctrl-C )
paste to B5:B65536 ( ctrl-V )
copy B:E
paste to B1 in new book
paste to G1, L1, Q1 ...
First paste : ~9.5 seconds,
second paste: ~18 seconds,
each subsequent paste: ~9 seconds more than previous,
8'th paste: ~72 seconds,
data copied up here: **4M cells**, time used **~5.5 minutes**.
Could think there is some checking for formula reuse or similar,
but LO Calc uses 'shared formulas' as well.
Wouldn't complain if difference to LO Calc is 1:2 or similar,
but 1:55 and increasing with more data is inefficient.
LO Calc: first copy of 4 **1M columns** to a new book,
~6 seconds, four further copies of 4 1M columns each ~6 seconds,
not increasing, next copy is somewhat slower, ~10 seconds,
and the next one crashes ;-)
( do we have any docu available about data structure and algo
for elementary functionalities? )https://gitlab.gnome.org/GNOME/gnumeric/-/issues/739multi-table html import fails without <caption>2023-11-04T21:05:26ZJohnDenkermulti-table html import fails without <caption>***Desired and Expected Behavior***
This concerns importing an HTML file containing multiple tables.
By way of background: The following valid HTML works as desired and expected:
[tables.html](/uploads/476ec784198dea367fb90bbb6b94a1a4/...***Desired and Expected Behavior***
This concerns importing an HTML file containing multiple tables.
By way of background: The following valid HTML works as desired and expected:
[tables.html](/uploads/476ec784198dea367fb90bbb6b94a1a4/tables.html)
As you can see in these screenshots, the two tables appear as separate sheets:
![tables-xxx](/uploads/78e0ad65d699b25b405cb3e9445e2163/tables-xxx.png)
![tables-abc](/uploads/ccb28c97c0cfca7a850b5ce40926b38b/tables-abc.png)
***Undesired and Unexpected Behavior***
This applies to a version compiled from freshly-pulled git sources.
Now suppose we remove the <caption> tags. That results in the following, which is still 100% valid HTML:
[tablex.html](/uploads/2f7b6cfb6b40744bb551d52bd02b4b90/tablex.html)
Alas gnumeric interprets this incorrectly, as shown in this screenshot. The second table tramples on the first. Data is lost.
![tablex](/uploads/6a48aca2f3bf19a9924f18256b95427a/tablex.png)
***Single-Sheet Behavior***
Older versions behave differently. gnumeric version '1.12.51' puts both tables on the same page, one after another. This is sometimes desirable, and sometimes merely OK. No data is lost. I am not complaining about this.
![tablex-old](/uploads/f7a36f6bf52ad68cc1831b029705e102/tablex-old.png)
***Remarks***
The HTML standard does not require a table to have a <caption> tag.
Gnumeric should not assume a caption will be present.
The decision-making should be driven primarily by the table tag, with an assist from the caption tag if any. Note that the caption tag, if present, must come immediately after the table tag, which simplifies things.
- Take the name of the sheet from the caption, if any.
- Otherwise, take the name from the table tag's ID attribute if any.
- Otherwise, generate the table name in sequence (Sheet1, Sheet2, ...).
If two or more tables are encountered with the same name, they should be imported to the same sheet, one after another, with no trampling, as seen in the single-sheet example above.https://gitlab.gnome.org/GNOME/gnumeric/-/issues/716apostophe aka single-quote disappears i.e. explicit literal string becomes im...2023-11-04T20:40:10ZJohnDenkerapostophe aka single-quote disappears i.e. explicit literal string becomes implicit, which it shouldn'tPlease refer to the attached example:
[bad-unquote.gnumeric](/uploads/9f330eba4ce6ae22611fb0e08be6d211/bad-unquote.gnumeric)
In cell B2 use an apostrophe to enter the explicit literal string:
```
'2023/jan/1
```
This is recognized as be...Please refer to the attached example:
[bad-unquote.gnumeric](/uploads/9f330eba4ce6ae22611fb0e08be6d211/bad-unquote.gnumeric)
In cell B2 use an apostrophe to enter the explicit literal string:
```
'2023/jan/1
```
This is recognized as being a string and a valid date.
Copy B2 to B4 and lengthen the month name to january.
This is no longer a valid date. It is still a string. The apostrophe has disappeared, which is odd and alarming.
Copy B4 to B6 and change the day number. The apostrophe is still gone.
Copy B6 to B8 and shorten the month name back to jan.
This goes back to being a valid date, but it is no longer a string. This is unexpected and undesirable. This causes problems if you want to edit the expression, because the representation has changed. The new representation is probably locale-dependent. It causes additional problems if there is explicit type-checking using the `TYPE()` function, and when the string is concatenated using the `&` operator.
A similar scenario plays out in cells B14, B16, and B18. Explicit string becomes implicit string becomes non-string.
**Desired behavior**
The apostrophe should be sticky. When something is an explicit literal string, it should remain an explicit literal string unless and until the user edits out the apostrophe. It should remain an explicit literal string even if it would be recognized as implicitly necessarily a string.
To say the same thing the other way,
```
'2023/january/1xx
'2023/jan/1
'foobar
```
should be different from
```
2023/january/1xx
2023/jan/1
foobar
```
and should remain different. The distinction is important because it affects editing, type-checking, and concatenation.
**Workaround:**
In my application there are partial workarounds, but they are ugly, involving additional cells and constructing a string by concatenation.
**Circumstances**
This is observed with both (a) freshly-pulled git sources and (b) a years old distro version:
```
gnumeric version '1.12.51'
datadir := '/usr/share/gnumeric/1.12.51'
libdir := '/usr/lib/gnumeric/1.12.51'
```https://gitlab.gnome.org/GNOME/gnumeric/-/issues/734plotSurface fails for non-monotonic x or y data2023-10-30T02:11:10ZJohnDenkerplotSurface fails for non-monotonic x or y data**Background and Expected Behavior**
The gnumeric manual section 10.3.15 documents plotSurface as follows:
```
The first subtype uses an n by 1 or 1 by n range for the x-values, a second 1 by m or m by 1
range for the y-values and an m...**Background and Expected Behavior**
The gnumeric manual section 10.3.15 documents plotSurface as follows:
```
The first subtype uses an n by 1 or 1 by n range for the x-values, a second 1 by m or m by 1
range for the y-values and an m by n range for the z values. The plotted points are constructed
from these three ranges in such a way that the z value in the ith column and jth row is combined
with the ith x value and the jth y value. This subtype then uses an m by n grid for the surface.
```
That is 100% fine as-is. Two satisfactory examples are shown in the attached .gnumeric file:
![plotXYZsurface-bugs.gnumeric](/uploads/2fe803813d59fa60ca9fcc896db66ba5/plotXYZsurface-bugs.gnumeric)
and the associated screenshot:
![hump](/uploads/96f7fb113516f9ad37294ee0658df338/hump.png)
On the 'hump' worksheet, in the special case of monotonic increasing x, the example exhibits the desired, expected, conventional, documented behavior, namely the top half of a hoop.
Similarly, in the special case of monotonic decreasing x, the example exhibits the desired, expected, conventional, documented behavior, namely the bottom half of a hoop.
Turning now to the 'hoop' worksheet, the plot shows a complete hoop. This is plotted by carrying out the documented behavior cited above, in the most simple, straightforward, direct way possible.
![hoop](/uploads/17c1d6224202e94ef01d70889112d406/hoop.png)
The x-data is known as a function of column number (i) ... and trivially as a function of (i,j).
The y-data is known as a function of row number (j) ... and trivially as a function of (i,j).
The z-data is known as a function of (i) and (j) ... tabulated explicitly.
Therefore we have [x,y,z] points in a 3D space, known as a function of (i,j).
The 3D [x,y,z] points are rotated and projected onto [u,v] space, i.e. the plane of the screen. The third coordinate in screen-space is available for hidden-surface elimination, but that's not at issue here.
The question of whether x is monotonic as a function of (i) does not arise.
The question of whether y is monotonic as a function of (j) does not arise.
The question of whether z is single-valued or known or even knowable as a function of x and/or y does not arise.
It suffices to know [x,y,z] as a function of column and row (i,j).
**Observed Bad Behavior**
Returning now to the 'hump' worksheet:
Let's try to plot the complete hoop using plotSurface. So we set the x-step in cell B30 to 20.
Alas plotSurface fails. AFAICT it fails whenever x is non-monotonic. Apparently it replaces the user's x-data with the column number (i). This happens without warning, without explanation. Of course (i) is monotonic, but it's the wrong data. Similar words apply to non-monotonic y-data.
This behavior is undocumented, undesired, unconventional, surprising, and exceedingly confusing.
It must be emphasized that a direct, straightforward implementation of the documented behavior would not exhibit this bug.
The hidden-surface elimination issue is the same whether or not x and/or y is monotonic, so it has no bearing on this discussion.
I do not know of any workarounds that I would consider practical for handling the case of non-monotonic x and/or y.
**Circumstances**
This is observed with a version compiled from freshly-pulled git sources:
```
gnumeric version '1.12.56'
datadir := '/usr/src/gnome/install/share/gnumeric/1.12.56'
libdir := '/usr/src/gnome/gnumeric'
69a456bedda13c41c79a98a1128edd9e74d2bb62 (origin/master, origin/HEAD)
Date: Sun Sep 24 13:07:14 2023 -0400
```
It is also observed with an older distro version:
```
gnumeric version '1.12.51'
datadir := '/usr/share/gnumeric/1.12.51'
libdir := '/usr/lib/gnumeric/1.12.51'
```
I suspect it has been unchanged for years.https://gitlab.gnome.org/GNOME/gnumeric/-/issues/735plotXYsurface undocumented2023-10-30T01:48:45ZJohnDenkerplotXYsurface undocumentedThis is an issue with the documentation.
According to the gnumeric manual section 10.3.15, the Surface type of plot has two subtypes, namely plotSurface and plotXYZsurface.
The code, however, implements a third subtype, namely plotXYsu...This is an issue with the documentation.
According to the gnumeric manual section 10.3.15, the Surface type of plot has two subtypes, namely plotSurface and plotXYZsurface.
The code, however, implements a third subtype, namely plotXYsurface, which is completely undocumented AFAICT. It has been this way for years. If this is an actual feature that actual users are expected to use, it would be nice to see a few words about what its inputs and outputs should be.https://gitlab.gnome.org/GNOME/gnumeric/-/issues/702UI: cell formatting: oddity when copying row height and / or column width,2023-09-27T07:41:10Zb. s.UI: cell formatting: oddity when copying row height and / or column width,cell with edited row height and column width.
I.) copy to other location on same sheet ( ctrl-C - ctrl-V ): row height and col width **not** copied.
expected: copy height and width same way as other formattings.
II.) copy to oth...cell with edited row height and column width.
I.) copy to other location on same sheet ( ctrl-C - ctrl-V ): row height and col width **not** copied.
expected: copy height and width same way as other formattings.
II.) copy to other sheet in same workbook: row height and col width **not** copied.
expected: copy height and width same way as other formattings.
III.) copy to other workbook: row hight and col width **not** copied.
expected: copy height and width same way as other formattings.
IV.) copy to other instance / other ver. of gnumeric, or 'copy - close and reopen program - paste':
a.) same position: row height and col width **copied, not undoable**.
expected: undoable as other copied formattings.
b.) other position e.g. origin was B2, paste to D4: row height and col. width copied **to 'source position'** - B2,
**off from 'content position'** - D4, **not undoable**.
expected: same position as content and undoable as for other formattings.
See picture ( case IV.b. ) and sample file: [formatting_inconsistent_for_copies_2.gnumeric](/uploads/95345fb385188e7b96ee1b490077d5c4/formatting_inconsistent_for_copies_2.gnumeric)
![copy_formattings_problem_2023-03-30_16-01-15](/uploads/c7fde664d9731c651d7d85294b4d3fb4/copy_formattings_problem_2023-03-30_16-01-15.png)
ver.: actual 1.12.56 dev.https://gitlab.gnome.org/GNOME/gnumeric/-/issues/729Gnumeric always looks as unfocused even if it is2023-09-19T08:14:22ZEmmanuel PacaudGnumeric always looks as unfocused even if it isHi,
Running gnumeric under Fedora 38 / GNOME / Wayland, the main window always looks as if it is unfocused, with grayed text on titlebar, menubar and toolbars.
![image](/uploads/7accb51f99fb0d5d5b35863c0e7bddcd/image.png)
The applicat...Hi,
Running gnumeric under Fedora 38 / GNOME / Wayland, the main window always looks as if it is unfocused, with grayed text on titlebar, menubar and toolbars.
![image](/uploads/7accb51f99fb0d5d5b35863c0e7bddcd/image.png)
The application is still perfectly usable, though the item highlighting on mouse hovering does not work. This is with gnumeric master and gtk 3.24.38.https://gitlab.gnome.org/GNOME/gnumeric/-/issues/728chart: cursor has offset from pull handle after leaving window frame at right...2023-09-16T12:53:39Zb. s.chart: cursor has offset from pull handle after leaving window frame at right or bottom border,We had some graph / chart / insert object related issues lately?,
think this one wasn't yet mentioned but may be related:
When inserting or resizing a chart there are handles? to pick
with the mouse pointer and pull to wanted lo...We had some graph / chart / insert object related issues lately?,
think this one wasn't yet mentioned but may be related:
When inserting or resizing a chart there are handles? to pick
with the mouse pointer and pull to wanted location.
When I 'leave the sheet' with the clicked pointer it comes back
'out of sync' to the pulling mark. That happens at right and
bottom border, when re-entering the sheet the cursor has some
offset towards the handle it's pulling, may be related to the
distance the sheet went scrolled while cursor outside.
Best shown on two pictures, the cursor which is not catched in the
screenshots but is in the center of the magenta circles is 'in sync'
with the right bottom pulling circle ( green dot ) in
![graph_pull_in_sync](/uploads/bd3497ecbdb5cb5a4c44e4a4dcb5b64b/graph_pull_in_sync.png),
but off from it in the next picture, the cursor pointing to I6:I7
still pulls! the green dot handle at I17. Also happens with cursor
'out' and opposite offset.
![graph_pull_out_of_sync](/uploads/50cf065e63f211bdf76d3ed683c3e722/graph_pull_out_of_sync.png)
If relevant: I'm using a 4k screen without special settings.
Gnumeric is actual 1.12.56 and appr. goffice on Kali / debian linux,
rechecked with fresh pulled goffice and gnumeric from today.
Also rechecked with another install on ubuntu ( 22-04 LTS ).
Add. but likely unrelated I got some warnings in the
terminal gnumeric was started from, happened when I'd hold the
cursor above top of window to scroll the sheet back.
```
(gnumeric:380211): Gtk-WARNING **: 10:43:17.317: drawing failure for widget 'GnmPane': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.317: drawing failure for widget 'GtkGrid': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.317: drawing failure for widget 'GtkNotebook': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.317: drawing failure for widget 'GtkBox': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.317: drawing failure for widget 'GtkBox': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.317: drawing failure for widget 'GtkBox': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.317: drawing failure for widget 'GtkBox': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.317: drawing failure for widget 'GtkWindow': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.340: drawing failure for widget 'GnmPane': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.340: drawing failure for widget 'GtkGrid': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.340: drawing failure for widget 'GtkNotebook': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.340: drawing failure for widget 'GtkBox': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.340: drawing failure for widget 'GtkBox': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.340: drawing failure for widget 'GtkBox': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.340: drawing failure for widget 'GtkBox': NULL pointer
(gnumeric:380211): Gtk-WARNING **: 10:43:17.340: drawing failure for widget 'GtkWindow': NULL pointer
```
poss. related: #679,
and the following observation which is likely https://gitlab.gnome.org/GNOME/goffice/-/issues/54 .
but I'd rather see scaling of cursor moves than offset there.
When editing the graph properties in the dialog cursor move and handle move isn't in sync,
making it difficult to find a working point to click once you'd let go.
here cursor and clickpoint match:
![graph_graphical_editing_1](/uploads/6ff88438835e75ca1564c143ae775ad4/graph_graphical_editing_1.png)
and here after some small pull they are off:
![graph_graphical_editing_2](/uploads/e42ada280110cb670c1a3b4d87ce75e2/graph_graphical_editing_2.png)https://gitlab.gnome.org/GNOME/gnumeric/-/issues/706Number format resets when unrelated changes made to range in Format Cells dialog2023-09-09T16:03:17ZKevin DaughtridgeNumber format resets when unrelated changes made to range in Format Cells dialogInput numbers in two or more contiguous cells. Change the number format from the default on one or more, but not all, of those cells. Select all the cells. Open the Format Changes dialog. Make one or more changes in tabs other than the N...Input numbers in two or more contiguous cells. Change the number format from the default on one or more, but not all, of those cells. Select all the cells. Open the Format Changes dialog. Make one or more changes in tabs other than the Number tab. Click OK or Apply. The changes will be applied, but the number format on all the cells in the range will be reset to the default.
No other settings from the dialog are similarly reset. If the number format is consistent across the range, it is not reset. The equivalent toolbar buttons for these settings do not reset the number format, but of course they do not cover the full range of possible settings (especially for borders).https://gitlab.gnome.org/GNOME/gnumeric/-/issues/724formula works in libreoffice calc, but not in gnumeric.2023-09-04T20:24:54ZG Gformula works in libreoffice calc, but not in gnumeric.=INDEX({1,2,3,4,5},MATCH(0,COUNTIF({1,2,3},{1,2,3,4,5}),0))=INDEX({1,2,3,4,5},MATCH(0,COUNTIF({1,2,3},{1,2,3,4,5}),0))https://gitlab.gnome.org/GNOME/gnumeric/-/issues/723Forcing gnumeric to load a virtual environment python3 instance2023-09-04T20:02:50ZGian Luca RocchiForcing gnumeric to load a virtual environment python3 instanceI'm on a Debian 12 distro, using gnumeric-1.12.55 and trying to use a python module which is not packaged in Debian system, namely CoolProp. At the end, the workaround of creating a pseudo-segregated environment with the scheme as sugges...I'm on a Debian 12 distro, using gnumeric-1.12.55 and trying to use a python module which is not packaged in Debian system, namely CoolProp. At the end, the workaround of creating a pseudo-segregated environment with the scheme as suggested in /usr/share/doc/python3.11/README.venv:
> e.g. instead of running: $ pip install --user foo
>
> run:
>
> $ mkdir -p \~/.venvs
>
> $ python3 -m venv \~/.venvs/foo
>
> $ \~/.venvs/foo/bin/python -m pip install foo
did the job of installing the wanted python module. The problem now is: how to tell gnumeric to spawn the virtual environment (venv) python instance while loading a gnumeric python plugin which relies on the above python module. I tried to navigate the relevant gnumeric plugin loader source code without being able to get off the sticky mud. I just noticed that once the Python_functions plugin is used, by calling one of the functions contained in, the combo selector in the Python console is giving a chance to choose the interpreter. I'm confused about the possibility I may have to solve this issue. I need some experienced programmer to suggest some path to go forward.
Thank youhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/605Restore mathematical logic for rounding down and up,2023-07-28T05:29:05Zb. s.Restore mathematical logic for rounding down and up,
Currently gnumeric calculates results that contradict mathematical logic.
When rounding down, a value should not become larger, and when rounding up, it should not become smaller than the initial value.
In my opinion, the fu...
Currently gnumeric calculates results that contradict mathematical logic.
When rounding down, a value should not become larger, and when rounding up, it should not become smaller than the initial value.
In my opinion, the fuzziness caused by 'sub_epsilon' and 'add_epsilon' - with which actually the rounding! to clearly shortened strings should be adapted to user expectations? - also affects rounding down and rounding up.
While one can discuss whether the application for 'rounding' makes sense - I think a correction of the initial value considered deviated would be more correct - the effect on rounding down and up is clearly wrong.
Besides the contradiction to school mathematics, it unfortunately also blocks my work for more precise floating point calculations by making rounding 'at the limit' impossible.
According to the attached sheet it is not 'only a few' values that are affected, but in the range of representable precision partly more than half ( sheets 'rounddown_fails' - calculating, 'rounddown_with_snap-to' - copied results, 'roundup_fails' - calculating, 'roundup_with_snap-to' - copied results ).
[finding_rounddown_up_fails.ods](/uploads/ab56acf55d1460966fe41c3ad68636f4/finding_rounddown_up_fails.ods)
The rate of affected values reduces with the 'precision distance' between initial value and rounded target, but also with 'shorter' targets deviations occur, e.g. [ edit 2022-07-18 reg. digits stolen by translator prog. ] <s>'=rounddown( 0.2499999999999972, 2 )</s> <ins>'=rounddown( 0.24999999999999**99**72, 2 )</ins> [ /edit ] what should normally produce 0.24, actual result 0.25.
As long as there is no better solution for the rounding problem I suggest to mitigate the effects on rounddown and roundup with the following patches, they implement a 'John Denker correction', if a result is recognizably wrong -> correct it.
I think it is possible to code this more elegant, 'nicer' and faster, I just wanted to show the necessity and a possible solution, to make this 'suitable' I leave to people who can do this better than me ...
In the attached workbook also sheets 'rounddown_with_jdc' and 'roundup_with_jdc', both 'copied values' from a patched version.
( The sheets 'rounddown_fails_calc' and 'roundup_fails_calc' mark the points where LO Calc produces similar wrong results, they are not visible for the user reg. 'display prettyfying' and don't make it into the file with save as LO Calc writes up to 20 decimals digits in the file, but - same as display - only 15 of them are significant the rest is padded with zeroes. But wrong values are calculated, visible with 'rawsubtract', and go into downstream calculations ... )
proposed patches - deco-math_patch_P0005b_restore_math_logic_for_rounddown_roundup:
trunc:
-----------------------------------------------------
```
static GnmValue *
gnumeric_trunc (GnmFuncEvalInfo *ei, GnmValue const * const *argv)
{
gnm_float number = value_get_as_float (argv[0]);
gnm_float digits = argv[1] ? value_get_as_float (argv[1]) : 0;
if (digits >= 0) {
if (digits <= GNM_MAX_EXP) {
gnm_float p10 = gnm_pow10 ((int)digits);
// edit b. - TO STAY - 2021-10-08: John Denker correction,
// in some cases, rounding to extrema, e.g. rounddown( nextafter( 0.25, -1 ); 16 ) for doubles or rounddown( nextafter( 0.5, -1 ); 19 )
// for 'long' instead of rounddown roundup occurs,
// partly reg. 'sub-/add_epsilon' fuzzyness, partly just FP-rounding-fail, John Denker proposed a corrective procedure,
// ori was: number = gnm_fake_trunc (number * p10) / p10;
gnm_float number_1 = gnm_fake_trunc( number * p10 ) / p10;
number = ( number > 0 ) ? number_1 - ( number_1 > number ) * gnm_pow10( -digits )
: number_1 + ( number_1 < number ) * gnm_pow10( -digits );
}
} else {
if (digits >= GNM_MIN_EXP) {
/* Keep p10 integer. */
gnm_float p10 = gnm_pow10 ((int)-digits);
// edit b. - TO STAY - 2021-10-08: John Denker correction,
// in some cases, rounding to extrema, e.g. rounddown( nextafter( 0.25, -1 ); 16 ) for doubles or rounddown( nextafter( 0.5, -1 ); 19 )
// for 'long' instead of rounddown roundup occurs,
// partly reg. 'sub-/add_epsilon' fuzzyness, partly just FP-rounding-fail, John Denker proposed a corrective procedure,
// ori was: number = gnm_fake_trunc (number / p10) * p10;
gnm_float number_1 = gnm_fake_trunc( number / p10 ) * p10;
number = ( number > 0 ) ? number_1 - ( number_1 > number ) * gnm_pow10( -digits )
: number_1 + ( number_1 < number ) * gnm_pow10( -digits );
} else
number = 0;
}
return value_new_float (number);
}
```
-----------------------------------------------------
and for roundup:
-----------------------------------------------------
```
static GnmValue *
gnumeric_roundup (GnmFuncEvalInfo *ei, GnmValue const * const *argv)
{
gnm_float number = value_get_as_float (argv[0]);
gnm_float digits = argv[1] ? value_get_as_float (argv[1]) : 0;
if (digits >= 0) {
if (digits <= GNM_MAX_EXP) {
gnm_float p10 = gnm_pow10 ((int)digits);
// edit b. - TO STAY - 2021-10-08: John Denker correction,
// in some cases, rounding to extrema, e.g. roundup( nextafter( 0.25, 1 ); 16 ) for doubles or roundup( nextafter( 0.5, 1 ); 19 )
// for 'long' instead of roundup rounddown occurs,
// partly reg. 'sub-/add_epsilon' fuzzyness, partly just FP-rounding-fail, John Denker proposed a corrective procedure,
// ori was: number = gnm_fake_roundup (number * p10) / p10;
gnm_float number_1 = gnm_fake_roundup( number * p10 ) / p10;
number = ( number > 0 ) ? number_1 + ( number_1 < number ) * gnm_pow10( -digits )
: number_1 - ( number_1 > number ) * gnm_pow10( -digits );
}
} else {
if (digits >= GNM_MIN_EXP) {
/* Keep p10 integer. */
gnm_float p10 = gnm_pow10 ((int)-digits);
// edit b. - TO STAY - 2021-10-08: John Denker correction,
// in some cases, rounding to extrema, e.g. roundup( nextafter( 0.25, 1 ); 16 ) for doubles or roundup( nextafter( 0.5, 1 ); 19 )
// for 'long' instead of roundup rounddown occurs,
// partly reg. 'sub-/add_epsilon' fuzzyness, partly just FP-rounding-fail, John Denker proposed a corrective procedure,
// ori was: number = gnm_fake_roundup (number / p10) * p10;
gnm_float number_1 = gnm_fake_roundup (number / p10) * p10;
number = ( number > 0 ) ? number_1 + ( number_1 < number ) * gnm_pow10( -digits )
: number_1 - ( number_1 > number ) * gnm_pow10( -digits );
} else
number = 0;
}
return value_new_float (number);
}
```
-----------------------------------------------------
Best Regards,
b.https://gitlab.gnome.org/GNOME/gnumeric/-/issues/123Gnumeric should have a "format painter" button.2023-07-27T10:11:14ZBugzillaGnumeric should have a "format painter" button.## Submitted by Alister
**[Link to original bug (#597278)](https://bugzilla.gnome.org/show_bug.cgi?id=597278)**
## Description
The summary says it all :)
Or is this against the gnome rules?
Version: 1.8.x## Submitted by Alister
**[Link to original bug (#597278)](https://bugzilla.gnome.org/show_bug.cgi?id=597278)**
## Description
The summary says it all :)
Or is this against the gnome rules?
Version: 1.8.x