The formats "%A" and "%LA" have some degree of freedom. Specifically,
while the standard specifies one digit before the ".", it does not
constrain the digit other than being non-zero for normal numbers. The
exponent is in bits, so that leaves four possible renderings of each
value.
For example,
For Gnumeric specifically, that means use the "gnumeric" tag on the
discourse server: https://discourse.gnome.org/tag/gnumeric
I would personally have preferred to keep the mailing list, but since
I am not the one doing the work that doesn't count for a hole lot.
(And dealing with internet-exposed
It's very likely a matter of sheet order. The version you're running
is so old I have no good feel for the bugs we've fixed in the
meantime.
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
That is indeed an ancient version.
Try running from the command line -- there might be error messages
with hints of what is going on.
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
The crlibm values are carefully curated as the worst possible cases
for double rounding.
I don't know of anyone who has searched for the worst cases for long
double. It may not be computationally feasible with current
understanding and technology.
If you just want sample values, you can use
Those reference values are specifically for "double" with round-to-nearest.
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
> I'm not sure if this was intentional?
Sort-of.
Excel's number system, and thus Gnumeric's (and LO's, etc), know
nothing about complex numbers. They are bolted on sideways as
strings, lots of duct tape involved. There is no support for
rounding-for-purposes of display.
So it's not going to
The answer remains: avoid the cvs format. It is ill defined and you
will always have issues.
Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
Fixed. The format is locale dependent which, in my book, isn't a
great idea. We will now load that file differently in different
locales which, evidently, is the Excel way.
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
Thanks.
In this case you do not have a csv problem, but an xlsx problem.
We read the file as per the file format specification and get a cell
with m/d/y format. Unfortunately it looks like Excel doesn't follow
its own file format! See, for example
The devil's in the details here, so please provide a sample file.
And, as always, avoid csv if at all you can.
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
See "man -s3 printf". The GNM_FORMAT_ part simply adds the "L"
modifier when long doubles are in play in addition to the g/G/e/G/f/F.
"E" vs "e": most places it doesn't matter, but for user visible places
it is a matter of tradition and Excel compatibility.
Why 2+ digits for exponents? Don't
Goal seek can do it, but only for continuous functions. If you can
rearrange yourself to have a continuous output then this is an
efficient solution.
The solvers aren't meant for this type of work
data->fill->tabulate can help you find the breakpoint.
M.
You need to pay close attention to compiler warnings that indicate the
wrong types are being used. Since --with-long-double
isn't used often, no-one has done that for a while.
I have fixed most. I left some that relate to debug printouts. Those
printouts won't work, but they shouldn't get
Basically you need every location that value_new_float is called.
There will be some in ms-formula-read that are important.
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
xls stores only binary numbers. You will not be able to store long doubles.
xlsx leaves pointer->output.decimal_digits as -1 and gets shortest
representation. Comment out 1483 in xml-sax-write.c and you ought to
get the same. Note: this will break a lot of tests that will suddenly
see
Thanks for the thought, but financial donations are not needed.
Gnumeric developers tend to be a bit older than your average free
software types and thus a bit better settled.
Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
All tests use GnumericTest.pm which removes environment vars LANG,
LOCALE, LC_*. Then it sets LC_ALL=C. So trying to override them when
running the test suite will get you nowhere.
The SHA1 for the applix test was generated on my system. The test
exists to make sure we don't accidentally make
For .ods there is no way to store what number system is in use. You
could certainly store the shorter "0.1", but that would simply be
wrong in a different way.
The number you have in hand is
0.155511151231257827021181583404541015625 aka
3602879701896397 / 2^55. There simply is
GOAccumulator usage goes something like this:
void *state = go_accumulator_start ();
GOAccumulator *acc = go_accumulator_new ();
go_accumulator_add (acc, d1);
go_accumulator_add (acc, d2);
go_accumulator_add (acc, d3);
go_accumulator_add (acc, d4);
double res = go_accumulator_value (acc);
> still how to build automated tests for calculations / features to avoid time
> consuming and error prone manual tests after each change,
In a git checkout, go to the "test" directory and run "make
check-TESTS". You can run single tests too if you wish.
However, you are messing with
The "= no" problem has been fixed.
This is what you get when you run "yes = no" (with spaces, try it!)
instead of "test yes = no".
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
configure --with-long-double
(or autogen.sh --with-long-double if you are running from the git tree
which, since you were looking for the test suite
the other day you should be)
goffice will need to have been compiled with --with-long-double also.
Note: this code path isn't tested terribly
If you really wanted to do something like that, you would call
function_def_call_with_values or function_call_with_exprs.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
The best approach at this point is to clone one of the existing
plugins. The first question is to ask "what kind of plugin?"
Adding functions to Gnumeric? -- take, for example, fn-math
Adding a solver method? -- take glpk (external program) or nlsolve (internal).
Anything else? samples are
> i'd like to learn how rounding for display is done, some of it might be
> useful for improvements i'm thinking about.
string-to-value is, basically, the C library's strtod. ("Basically"
because there are complications like decimal comma, thousands
separators, and probably other such things.)
> 1) Gnumeric uses fuzzy rounding and fuzzy comparisons.
Comparisons are not fuzzy, but sharp ieee comparisons.
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
Gnumeric's rounding here is indeed done with
round_to_int(x * 10^d) / 10^d
except that round_to_int deliberately misrounds 0.5-1ulp to 1. That's
not important here.
This means that, in general, you should not expect last-bit accuracy
for this operation. Both the multiplication and the
Gnumeric, when run from the compile tree, is independent of any
installed version of Gnumeric.
That does most of what you need unless you need your own version of
Goffice or other libraries at the same time. In that case it can be
done with "--prefix=/somewhere" in the configuration phase. It's
1. We use an extension of Kahan summation, see
https://gitlab.gnome.org/GNOME/goffice/-/blob/master/goffice/math/go-accumulator.c
This is done for sum(...), not for a+b
2. We don't even attempt to be smart here. It's pointless as the
partial sums often sit in their own cells and must be
You should not worry. ssconvert does the conversion correctly
regardless of this error message.
I haven't seen that particular problem for a while, but it relates to
storing configuration information. Probably about the plugins in use,
if memory serves.
M.
I just pushed changes that allow theming of the grid colour:
GnmItemGrid.grid,
GnmPreviewGrid.grid {
color: #c7c7c7;
}
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
> I am unable to change the grid color
The grid colour can come either from the spreadsheet (if you define
borders) or from a default
which happens to live in src/style-color.c, function style_color_grid.
That means that currently you
need a recompile to change it.
I'll try to hook it up
> i asked for it here ~9 years ago but there's stubborn people on this earth...
You did indeed, but you were so obnoxious about it then (and now, it
would seem) that it promptly got put in the "will take patches" pile.
There is some kind of life lesson hidden here, I suspect.
Now, if you have
I have code that can detect whether a theme is dark. (It's a
heuristic -- looks at the
foreground colour; if that is light, the theme is probably dark. For
the sake of argument,
assume it works.)
I could use that to load a "gnumeric-dark.css" file instead, but that
leaves the question
of what
It should be something like the stuff below, but it looks like the
gtk+ people have broken
this underneath us. That happens entirely too often.
M.
GnmItemGrid pane-divider {
color: #ff;
/* This isn't working well yet: */
border-style: solid;
border-width: 1px;
}
You either compile your new one into gnumeric, or you add your stuff
to ~/.config/gtk-3.0/gtk.css bearing in mind that this file is shared among
all gtk3 programs.
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
You can probably comment that code out for now, just to get going. It
affects only command
line handling. You can return if you get through the rest.
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
see tools/win32/patches/glib-goption-disable-localization.patch
The glib people sat on our bug report for a decade, then did something
incompatible. This is needed for non-ascii filenames on the command
line. Options: hack glib or hack gnumeric.
M
It turns off "long double" support in the api. The error you showed suggests
that the C library doesn't have the necessary support. Also, from memory,
the win32 library isn't sufficiently accurate to make compiling with long double
meaningful.
The linker warnings suggest that it wants .so
--without-long-double
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
> I don't even care what names you give them, so long as the names are not
> the same.
Sorry, not an option: I don't name them.
Users name them foo.csv and probably think of them as "cee ess vee"
files where you,
as I understand it, think of them as "comma separated value" files.
> THESE ARE
Mostly for entertainment purposes, here's a tour of Northern Europe as
told by random
csv files. (I am ignoring xls files named *.csv -- there are quite a
few of those too.
Also ignored are completely vanilla "," separated files which are also
used in these
countries.)
TL;DR: ";" separation is
Fair enough. Use .gnumeric, .xlsx, or .ods. Any of these attach semantics
to the data they carry. They are equally good for this purpose and can be
converted from one to the other.
If you were working with Excel, the recommendation would be .xlsx only
and if you were working with LO it would
I did provide advice on what I believe the semi-safe subset of csv is, see
items 1-5 near the end of my message.
There are so many ***conflicting*** csv implementations in the world, that
it is hard to get any closer. RFC-4180 (which arrived decades later than csv
files) is not particularly
TL;DR: Avoid csv files if you can.
This note described what Gnumeric does with csv files and why csv files are
a bad idea to begin with.
Note: this is about unattended import of csv files. With the configurable
text importer, Gnumeric can be convinced to import just about any reasonable
You are going to have to contact whoever made the binaries you
installed. This sounds
like an installation problem.
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
Please file a bug at https://gitlab.gnome.org/GNOME/gnumeric/-/issues with
a sample file.
There are basically two possibilities: either the file contains a 0 for C1
(in which case things work as designed)
or it contains something else (and we have a problem).
The intent is that only volatile
I don't think there is an easy spreadsheet solution to this, but if
you have the data in sorted text files,
the command line "comm -23 filea fileb" will do the job.
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
That would be the hosting provider, not Gnumeric's web page as such.
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
Where did you get your Gnumeric and goffice from?
Do you have more than one of either installed?
What version is your goffice?
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
We have the semantics of, say, 0+blank, from Excel. While we could
certainly make
our own definition of what 0+blank should be, going that way is not
going to improve
interoperability. If you're going to break interoperability,
COPYVALUE is the cleaner
and more explicit way.
A quick google
Actually, it's not a good idea. Excel seems to return 0 in this case
making our result a bug.
You are better off creating a new function, say COPYVALUE, in fn-info
to do the copying.
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
It's possible with CELL("contents",A42)
(I'm not saying that's a good idea, only that it is possible.)
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
Goal-seek changes the cells. I don't see that happening in a sheet function.
However, something like this could probably be done in Python using
the introspection machinery. A good starting point for exploring that
is the code in test/t3001-introspection-simple.py which shows
basically how to
The GsfOutfile interface is write-once for files and directories.
Therefore you must hold on to the GstOutfile from the C was created
and use that.
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
It looks like you get two sets of plugins being registered.
Either you have multiple copies of goffice or gnumeric installed, or
else something is weird with your plugin setup.
Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
Could you please try adding a line
g_printerr ("id=%s\n", id ? id : "-");
just before the failing assertion?
That should tell us the id that is duplicated.
Thanks,
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
I have added auto-by-extension in goffice. I'm not sure about the
rest, but the bug tracker is the place, not here.
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
No, it is in src/wbc-gtk-actions.c, not in a config file.
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
First patch committed.
Suggested alternative for second patch attached. The attribute was
renamed to "deflate-level" to match GsfOutputZip. The attribute is no
longer construct-only, although it has to be set before actual writing
starts. There is no "full" method. As an added benefit, the
Please open a bug report for this -- it's better for documentation and
keeping track of things.
gsf_output_memory_steal_bytes is pretty straightforward.
gsf_output_gzip_new_full is a bit less so. Not because the
functionality is not good -- it is very reasonable -- but because
there are other
This breaks "make distcheck" for me.
[...]
test -d "gnumeric-1.12.46" || mkdir "gnumeric-1.12.46"
cp: cannot stat
'.//home/welinder/gnome/gnumeric/samples/regress.gnumeric': No such
file or directory
+# AFAICT this is just another name for the same thing:
+$top_builddir = $topsrc;
Not during
To build Gnumeric from github you will need Goffice from github.
You could probably hack around it ("#define go_format_has_year(fmt)
0") if you don't mind potential problems with text import.
Search and replace never sees empty cells so it won't do what you need.
Python scripting -- see
1. Select area.
2. Format->Auto Format...
3. Pick the style you want
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
libgsf isn't too hard to compile and it doesn't require very recent
versions of anything.
Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
I am fairly certain we don't have a hard dependency of python 2.
That is to say, you can configure and compile Gnumeric without python
2 being present. You will likely lose the python plugin as a result,
but that's life.
I believe the introspection based python interface is happy with python 3.
Please file a bug at https://gitlab.gnome.org/GNOME/libgsf/issues
Attaching a complete sample program and the corrupted stream you get
would be helpful.
Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
Unless you have a specific need for GsfTimestamp, I would recommend
that you use glib's GDateTime type instead.
Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
GsfTimestamp isn't our best interface, :-/
That said, you really should be able to use gsf_timestamp_set_time for
any time that is actually in the 1970-2038 range. You'll have to do
the calculation using 64 bit arithmetic, but the final value should be
in range.
M.
Done.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
There's no particular reason why it couldn't be added, although we
would have to pick a branch, W_0 presumably.
Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
Fixed, but filing a bug directly on
https://gitlab.gnome.org/GNOME/gnumeric/issues is better. Gitlab has
better memory and it makes for better release notes to be able to
point to what was fixed.
M.
___
gnumeric-list mailing list
Unrelated. My fault. Fixed.
M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
Fixed.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
In the Format->Sheet submenu there are options for hiding row/column
headers as well as the grid.
The toolbars can be hidden using the View->Toolbars submenu, but these
settings are not considered part of the workbook.
For the rest, you're out of luck.
M.
On Sat, Aug 18, 2018 at 2:22 PM Артём
Select area
Format->Auto Format
You probably want one of the list templates.
On Tue, Jun 12, 2018 at 12:54 AM bill wrote:
>
> Hi all,
>
> Another "newbie" question, if i might...
>
> I've noticed that in larger spreadsheets the author often shades every other
> row a light gray making it
You are probably in full-screen mode. Press F11.
M.
On Wed, May 30, 2018 at 5:23 AM Pawel Tokarz
wrote:
> Maybe that's silly but annoying... In some of my sheets the bottom
tabbed sheet indicator has disappeared.
> When I create a new spreadsheet I see the tabs in it but not in the
already
It appears that under LinuxMint with Cinnamon, you need to ask the desktop
to
remember recently used files. That happens under Preferences->Privacy.
Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
; > me (perhaps I need to update other libraries?)
> >
> > This worked on goffice-0.10.32 with the patches I'd used on gnumeric.
> > So we'll need to sort out what changed.
> >
> >
> > On 04/13/2018 11:17 AM, Morten Welinder wrote:
> >> Major progres
Major progress on my end. I found two major sources of crashes (1: many of
our
boxed types were bad; 2: some pygobject versions fail on transfer-full
arguments).
You can follow the battle at
https://git.gnome.org/browse/gnumeric/tree/README-introspection
although that file may move. This
introspection
> - Applications are C, python is not
> - Objects needs to be converted between the two, normally transparent but
> sometimes results in unexpected behavior.
>
>
> Memory Management
> - not all objects get exported in a directly usable way
> - in .gir file, o
I tried to write a script to do some basic operations, but I immediately
hit problems in introspection
and/or pygobject. Specifically, something gets terminally confused over
sheet_cell_set_value
leading to a double-free. Even if they fix that right now, it's going to
be years before stable
ike McClain <mike.junk...@att.net> wrote:
> On Wed, Apr 11, 2018 at 12:00:07PM +, gnumeric-list-requ...@gnome.org
> wrote:
> > From: Morten Welinder <mort...@gnome.org>
> > To: Gnumeric Mailing List <gnumeric-list@gnome.org>
> > Subject: Re:
All support for Windows (any version) has ceased.
Morten
On Fri, Apr 6, 2018 at 6:48 PM Gilmar Placeres Simão
wrote:
> Gentlemen:
>
> Please let me know which is the official Gnumeric website that has the
> updated * Gnumeric for Windows 10* download link.
>
> Thank you
> I understand there is a work group tackling the translation task.
There isn't. There was, perhaps, a bit of shadow work aimed at something
not entirely unlike
that in the late 1990s. Between bitrot and a moving target, there is
really no point in looking
for something that old, except
It's quite possible that this has bitrotted over the years.
Please file a bug for this at bugzilla.gnome.org, including what version of
Gnumeric you are using.
Morten
On Wed, Apr 4, 2018 at 1:17 AM Mike McClain wrote:
> I'd like to move my portfolio tracker to gnumeric.
ble solution. A lock file could be deleted. I am not
> talking about more exotic hard links when lock files will be saved in
> different directories.
>
>
>> ---
>> On Thu, 22 Mar 2018 20:28:29 -0400, Morten W
> Is there a reason that the patch attached to that bug wasn't applied?
Yes.
And now a reasonable follow-up question would be what that reason was,
but I don't
remember the details. It was discussed in mail or on IRC.
However, a quick look says that it can't work right under NFS -- and
There currently isn't although there was some discussion about it a
long while ago,
see https://bugzilla.gnome.org/show_bug.cgi?id=334024
I guess at least we ought to check if the file system time stamp has
changed since we loaded
the file. That would catch the vast majority of the problems.
M.
It would be interesting to figure out what did go wrong here. It is
likely to be either
a libc bug or a compiler bug. Both are a bit scary, but we have seen it before.
libc is my guess.
What libc is in play? What value do you get if you use the %.55Lg format?
Morten
On Thu, Mar 1, 2018
You need format %Lf here.
welinder@dicentra:~> gcc -O -Wall ttt.c
welinder@dicentra:~> ./a.out
outputs: 0.077979
Morten
On Wed, Feb 28, 2018 at 10:15 AM, Jason Martin wrote:
> On OpenIndiana trying to update:
>
> goffice-0.10.35 to goffice-0.10.38
>
> test-math.c is
You might be able to shrink the desktop's font size which will help a bit,
but basically it's not a use case we put effort into.
M.
On Tue, Feb 6, 2018 at 8:38 AM, Lisi Nicola wrote:
> Dear Sirs,
>
> I am testing the gnumeric spreadsheet on an old my PC where I installed
Sounds good!
Are there any patches from that work which ought to go into the git repository?
Morten
On Wed, Jan 10, 2018 at 5:12 PM, M-Rick via gnumeric-list
wrote:
> This is the latest build of Gnumeric Mac 1.12.38.
> The MacOS native help is a bit slow to launch,
> does there exists a public available list of Gnumeric extensions to ODF?
In a certain sense, yes. We have a patch that changes the regular schema
into the extended schema:
https://git.gnome.org/browse/gnumeric/tree/test/ods-ext-schema.patch
We actually test against the schema, so I am fairly
hat appears when you open a new book
> ("Book1.gnumeric"). In fact my present default shows signs of having
> had some previous input by me. The problem is I can't remember how I
> achieved this.
>
>
> On Fri, 16 Nov 2017 Morten Welinder <mort...@gnome.org> w
Build system problems are difficult to handle because there is really
no way to make sure a change won't break
someone else's build. (And note that this holds independent of the
particular build system in use.)
At the autogen level, in practice, what I do is to make sure things
work for me,
There is no rpm. We distribute only source code. You are on your own
for compilation.
Morten
On Tue, Sep 19, 2017 at 8:33 AM, SILVESTRE Bruno wrote:
> Hello,
>
>
>
> I would need to install gnumeric for AIX 7.1.
>
> Where can I find the rpm package (+ dependencies) for
ssconvert is basically Gnumeric's load and save bundled together.
There is currently no editing functionality. (And, also, no concrete
plans as to how to add that.)
Morten
On Sun, Aug 27, 2017 at 5:56 AM, Peter Brooks
wrote:
> I've been using ssconvert a lot
You can probably change that to run "gzip -dcf" instead.
Morten
On Sat, Aug 26, 2017 at 3:24 AM, Jason Martin wrote:
>
> I have built gnumeric and it is running fine on OpenIndiana but I want the
> tests to work correcty.
>
> I am having problems with:
>
>
1 - 100 of 407 matches
Mail list logo