Re: human friendly hexrep???

2022-10-30 Thread Morten Welinder
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, if your value is 2, you can end up with 0x8p-2, 0x4p-1,
0x2p+0, or 0x1p+1.

hexrep is a debugging tool so the exact form of the output isn't
terribly important.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Announcement: this mailing list will be retired by the end of Oct 2022

2022-10-20 Thread Morten Welinder via gnumeric-list
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 code based on the increasingly
unmaintained python2 does sound a bit scary these days.)

Thanks to the Redhat team for keeping the mailing list running over the years!

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: New worksheet in a long-existing (and working) file changes expression to string after saving and closing (and then reopening)

2022-09-16 Thread Morten Welinder
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


Re: New worksheet in a long-existing (and working) file changes expression to string after saving and closing (and then reopening)

2022-09-13 Thread Morten Welinder
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


Re: Re: Re: Re: no tests for trigonometric functions? need help / hints how to adapt tests for gnumeric 'long' version,

2022-06-17 Thread Morten Welinder
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 Mathematica which has an
independent implementation of sin/cos/etc, at least when you avoid
double (what Mathematica calls "machine-precision numbers").  You
will, however, have to deal with the complication of presenting the
correct (base 2) value as input.  Using an unrounded decimal
representation should work, but may well require 64 decimal digits or
more.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Re: Re: no tests for trigonometric functions? need help / hints how to adapt tests for gnumeric 'long' version,

2022-06-17 Thread Morten Welinder
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


Re: Formatting complex numbers?

2022-06-09 Thread Morten Welinder
> 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 be elegant.

What you can do, as a sort-of workaround, is to extract the real and
imaginary parts.  Say, A1 contains a complex formula.  Then enter
=REAL(A1) into B1 and =IMAGINARY(A1) into C1.  Those numbers you can
format in all the usual ways.

We could introduce a function to round complex numbers but any use of
it would actually change values and thus results.  Not a great idea
either.

Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: ssconvert: more Excel-to-csv issues

2022-05-23 Thread Morten Welinder
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


Re: ssconvert assumes that Excel/xlsx dates are in US locale?

2022-05-22 Thread Morten Welinder
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
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: ssconvert assumes that Excel/xlsx dates are in US locale?

2022-05-15 Thread Morten Welinder
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
https://social.msdn.microsoft.com/Forums/office/en-US/e27aaf16-b900-4654-8210-83c5774a179c/xlsx-numfmtid-predefined-id-14-doesnt-match?forum=oxmlsdk

It is not clear what they actually do and the answer may be locale
dependent.  I'll have to do some research.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: ssconvert assumes that Excel/xlsx dates are in US locale?

2022-05-14 Thread Morten Welinder
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


Re: four questions about formatting of numbers ...

2022-05-13 Thread Morten Welinder
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 know -- probably history and
tradition.  If you don't like the extra "0", it's an easy and clean
post-process step to remove it.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: keyboard macro? or other tool to quickly find target values?

2022-02-08 Thread Morten Welinder
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.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: where to set default row hight ??? file opens with too small settings for row and column - follow up

2022-02-03 Thread Morten Welinder
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 executed.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: code pointer for reading from xls files

2022-01-29 Thread Morten Welinder
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


Re: enhancement request: 'shortest roundtripping' representation of values for file export - with patch proposal

2021-12-19 Thread Morten Welinder
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 unexpected changes!

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Gnumeric donations

2021-12-01 Thread Morten Welinder
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
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: follow up: problems with gnumerics tests, did e.g. the applix import ever succeed? - needs 'locale advice'?

2021-09-29 Thread Morten Welinder
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 changes we didn't
intend to.  As no-one cares about applix I doubt the actual output was
ever inspected in fine detail.  If you see unwanted locale dependency
then we might be missing a gnm_push_C_locale somewhere in there.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: compatibility problem between 'double' and 'long double' versions | was: follow up: Aw: Re: 'testing' in gnumeric

2021-09-23 Thread Morten Welinder
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 no way of knowing whether
that was meant to be 0.1 or slightly more.  It looks like we have
chosen to store just enough digits to ensure round-trip for double.

For the .gnumeric format, you can use the stored FloatRadix and
FloatDigits (see xml_write_number_system) to decide what to do.

Again: the problem you are trying to solve does not have a solution.
You are trying to look at 3602879701896397 / 2^55 and make the
decision "that's not the right number; it should have been 1/10
exactly".  But since you don't know where that value came from you
cannot know whether you are reducing or enlarging the error of
representation.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Re: where can / must one activate 'LONG DOUBLES'? - works to some extend, feedback and additional questions

2021-09-19 Thread Morten Welinder
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);
go_accumulator_free (acc);
go_accumulator_end (state);

The only thing magic here is "state" which relates to cpu state
(precision mode, rounding mode) and isn't particularly relevant for
modern cpus.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Re: where can / must one activate 'LONG DOUBLES'? - works to some extend, feedback and additional questions

2021-09-19 Thread Morten Welinder
> 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 calculations so you will see failures
that computations are not giving the expected results.  How you will
deal with that I don't know.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Re: where can / must one activate 'LONG DOUBLES'? - works to some extend, feedback and additional questions

2021-09-19 Thread Morten Welinder
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


Re: where can / must one activate 'LONG DOUBLES'?

2021-09-18 Thread Morten Welinder
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 often.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: simple? c-coding / gnumeric coding style question ...

2021-09-07 Thread Morten Welinder
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


Re: Writing a new plugin

2021-08-02 Thread Morten Welinder
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 getting a bit thin.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Re: Re: Re: Re: deco-Math project, step 00_a: exact bin and dec 'ranges' (in gnumeric).

2021-07-23 Thread Morten Welinder
> 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.)

value-to-string is in goffice/math/go-dtoa.c and is based on musl's
printf code.  It's changed to handle things like decimal comma.

As far as I know, both ways have full accuracy in the round-to-nearest
sense under two conditions: (1) a sane C library -- glibc is fine, and
(2) ieee-854 semantics of double and long double -- x86 is fine.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: fuzzy rounding, roundoff, roundup(), et cetera.

2021-07-10 Thread Morten Welinder
> 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


Re: Re: Re: Re: deco-Math project, step 00_a: exact bin and dec 'ranges' (in gnumeric).

2021-07-07 Thread Morten Welinder
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 division can
introduce rounding errors.  I am willing to entertain patches that fix
that if (a) someone is sufficiently interested to do the work, and (b)
can do it in a sane way that doesn't involve making strings out of
numbers.  This is not a beginner's task.

But note that the function implemented would be x ->
round_to_base2(round_to_base10(x,d),53).  In other words, you are
inherently double rounding.  Allow me to point out that while
well-defined, it is not a very sane thing to do, except in the cases
where the outer round is known to be a no-op.

There are two types of rounding in Gnumeric: the rounding functions
such as ROUND.  These change the values.  Then there is the rounding
implied by attaching a format to a cell.  That does not change the
value, only its display: even if you format A1 to show two decimals,
then another cell containing =A1*42 will still see the full precision
of A1.

Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: multiple / parallel installations of gnumeric on one system?

2021-07-01 Thread Morten Welinder
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 a
little more involved and you may have to set various environment
variables.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: newbie questions, sum over range, rounding of special problematic values

2021-05-06 Thread Morten Welinder
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 displayed.

3. This is based on misunderstandings.  Our calculations are based on
base 2.  To understand things, read
http://www.gnumeric.org/numerical-issues.html

Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: (ssconvert:31889): dconf-WARNING

2021-03-08 Thread Morten Welinder
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.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: gnumeric dark theme

2021-02-20 Thread Morten Welinder
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


Re: gnumeric dark theme

2021-02-18 Thread Morten Welinder
> 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 somewhere where it can be controlled by css.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: gnumeric dark theme

2021-02-17 Thread Morten Welinder
> 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 something to actually contribute about the matter I
am all ears.  Code, css, etc.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: gnumeric dark theme

2021-02-16 Thread Morten Welinder
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 to put into such a file.  I would probably add a
gnumeric-common.css file too,
just so we don't have to repeat everything.

Do you have a suggestion about what should go into there?

Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: gnumeric dark theme

2021-02-16 Thread Morten Welinder
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;
}
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: gnumeric dark theme

2021-02-15 Thread Morten Welinder
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
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: problem compiling Gnumeric on MSYS2

2021-01-20 Thread Morten Welinder
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
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: problem compiling Gnumeric on MSYS2

2021-01-20 Thread Morten Welinder
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
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Problem compiling goffice under MSYS2

2021-01-20 Thread Morten Welinder
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 files.  I don't know where you
would get those, but wait and see if it actually matters.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Problem compiling goffice under MSYS2

2021-01-19 Thread Morten Welinder
--without-long-double
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: More than you ever wanted to know about csv files (Re: to csv or not to csv)

2020-10-18 Thread Morten Welinder
> 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 NOT ALL THE SAME.

Nope, but they are all "csv" files.   I understand that you would
prefer those files to have
been named something else by suitably educated users, but that is not
the world we are
living in.

It's a messy world, to say the least, but "csv" files show up on
Gnumeric's doorstep with
just a filename, "foo.csv", and absolutely no indication of what
subspecies they are.

Any suggestion that these people should not be able to import their
data with the same
ease as you with your vanilla csv files will be rejected.  And
declaring that "foo.csv"
loaded from the command line has to be separated by commas would do
that.  I will
not do it.

And that's it about csv files from me.  Once we reach the all caps
stage I tune out.

Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: More than you ever wanted to know about csv files (Re: to csv or not to csv)

2020-10-13 Thread Morten Welinder
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 quite common.  Decimal comma is common.

If you wonder why ";" is so common: it's what Excel does in locales
that use decimal
comma.   Gnumeric cannot ignore this fact.

M.




Let's start in Germany. Here's a list of German doctors.  Note, that
the separator is ";":
http://www.stadtmagazinverlag.de/orte/senftenberg09/Aerzte.csv

Here's a csv file using [tab] as separators:
https://gitlab.lrz.de/ru49qap/paradiso/blob/master/kiva_locations.csv

Here's "|" as separator.  That's a new one! Note also the "123.45 €" amounts.
https://www.smarthome.de/feed/exagon-smarthome.csv

Here's a ';' separated file with "123,56" numbers.
https://wahlergebnis.duisburg.de/Buergerentscheid/05112000/html5/Buergerentscheid_NRW6.csv

Moving on to Finland, here we see ";" separated data in some non-UTF8
encoding.  It looks
like a bunch of names and addresses.  Or maybe it's the local
butcher's price list -- I can't tell.
https://www.graafinenteollisuus.fi/files/149/7_saraketta_09.csv

Denmark.  The Education and Research Ministry uses  ";" separated data
with "123,45" numbers:
https://ufm.dk/uddannelse/statistik-og-analyser/uddannelseszoom/ufm_samlet_02sep2020.csv

Sweden, [tab] separated:
https://panglaodb.se/csvs/f658ebfb.csv

Norway: ";" separated with what appears to be an html header:
https://www.feva.no/wp-content/uploads/2013/08/resultater1.csv
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: More than you ever wanted to know about csv files (Re: to csv or not to csv)

2020-10-13 Thread Morten Welinder
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 be .xlsx or .ods.

With respect to the configurable text importer, that is for use when a specific
text file isn't handled by the automatics.  Basically any text-in-columns type
file should stand a fair chance of being something we can handle.  On the
down side, it's not automatic.


Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: More than you ever wanted to know about csv files (Re: to csv or not to csv)

2020-10-11 Thread Morten Welinder
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 helpful -- it partially describes an ideal
not implemented
by anyone.

> To my way of thinking, CSV applies to the middle layer.

Please read "very important note" again.  We cannot have uninterpreted data in a
spreadsheet, so the semantic layer is not optional.

People get extremely emotional about csv files for some reason.   It's
basically "csv files
obviously mean what I think they mean and everyone else is an idiot."
>From a spreadsheet
implementor point of view, the loud and ***conflicting*** demands of
csv users is not worth
the effort.  I have taken a good amount of abuse on that account.

With respect to documentation: maybe.  There are parts of the whole
thing for which I may
change things without notice.  It is by nature a bit of an AI system
that tries to make up for
the lack of semantics in csv files.  A full description would be very
complicated and in
practice worse than useless: it would actively prevent fixing things.

Oh, and I lied: Gnumeric doesn't look at the whole column for clues.
The first line might
contain a header, so it's mostly ignored.

You can file the bugs.  If you want to see what is going on for each,
set GNM_DEBUG=stf.
That gives you a hint or two.

Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


More than you ever wanted to know about csv files (Re: to csv or not to csv)

2020-10-11 Thread Morten Welinder
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
text-in-columns file.

There are three phases to csv file import:

1. Character set resolution.
2. The syntactic level -- chopping the file into lines and lines into fields.
3. The semantic level -- making sense of fields.


Phase 1: Character Set Resolution

Most people aren't aware, nor do they need to be aware, of this level.
It governs
how the bytes in the file are turned into characters.  Most text you find on a
Linux system will be UTF-8 encoded -- including a very large fraction that is
just ASCII -- but Windows originated files will occasionally have
UTF-16 encoding,
either little or big endian, with or without a BOM marker.  The
Windows files will
use 2 bytes per character while UTF-8 files use a variable length, mostly 1 byte
per character for western text.

The reason you don't have to think about this is that detection is
mostly automatic
and that the automatic system rarely fails.  The only reason to
intervene would be
if you got ahold of some 1990s non-ASCII file with, typically, Eastern-European
text in it.

The Gnumeric solution here is to map everything to UTF-8, but for the
purposes here
you might as well think "ASCII".


Phase 2: The syntactic level

This level handles chopping a file into lines and the resulting lines
into fields.
This is the (only) level that RFC-4180 has an opinion on.

Let's start with lines.  RFC-4180 specifies that lines are terminated with \r\n.
In particular, if a file uses unix style \n only, then as far as RFC-4180 is
concerned the whole file is only a very long line.  Since \n files
occur often in
the real world, following RFC-4180 strictly is clearly not a viable option.

The Gnumeric solution is to accept \r\n, \n, and even the old Mac \r as line
terminators.  Moreover, the last line may omit the terminator.  The line part of
the syntactic level rarely causes problems.

The fields part of the syntactic level is where the wild west starts.  Here
are some samples to think of, with comments that aren't part of the files.

   1,2,3 # Easy
   4,5,6

   100.22,222.34,-123# Still easy
   444,,123.45

   "111,22",222,"22,33"  # Not too bad, typical in Europe
   "1,22",,"222,11"

   111,22;222;22,33  # Same as above other than terminators
   1,22;;222,11  # (And, yes, still called csv even though the separator
 # isn't comma!)

   "Quote ""this""",text # Double quote in quoted text for embedded quote

   "Quote \"this\"",text # Escaped quote in quoted text (not handled
by Gnumeric)

   "Multi# Embedded line breaks in text
   line
   field,text

   Foo,Bar"Baz,Bof   # Quote inside unquoted field

I don't recall if we have seen files with single quotes.  I certainly
wouldn't rule
it out offhand.

It should be fairly clear that if you get the quoting style and/or the field
separator wrong, then you are stuck with a pile of garbage.

The Gnumeric solution here is to assume the RFC-4180 quoting style,
and then look at
the text in the file, notably on a line starting with a quote if there
is any, and
make a guess and the field separator.  In practice it seems to work.

Let's assume we got it right, and move on.  Note, that we are now
leaving anything
that RFC-4180 can help us with.


Phase 3: The semantic level

This is the phase that takes a, roughly, rectangular array of text
bits and tries
to make sense of it.

VERY IMPORTANT NOTE: Gnumeric (and other spreadsheets) interpret data when they
are entered.  If we determine that something is a number, then it will be
stored as a number and it does not matter whether it was entered as "100",
"1e2", "00100" or "100.000".  We do not carry the string it came from around
(and depending on context such a string may not even exist in the first place).
This mean that we know the meaning of the data and that it does not change if,
say, the spreadsheet is later loaded somewhere in Europe where "100.000" could
be a hundred thousand.  On don't get me started on dates!

If this is not the behaviour you want, then you must arrange for that particular
piece of data to be interpreted as a string, not a number or anything
else.  This
is one of the major pitfalls of csv files and the place falls squarely
on the csv
format because it has no way of saying "that's a string!"

The use of quotes in csv files is *not* an indication that a piece of data is a
string.  Several reasons: (1) in decimal-comma locales most numbers have to be
quoted; (2) most csv producers quote everything; (3) I know of no csv producing
programs that actually try to use quotes for that purpose and I know of no csv
consuming programs that try to interpret files that way.

The Gnumeric solution here is to 

Re: Help with gnumeric on Mac OS X

2020-09-13 Thread Morten Welinder
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


Re: xlsx recalculate on open

2020-08-22 Thread Morten Welinder
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 cells (i.e., those containing =TODAY() or
some such) are computed on load.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Comparing 2 Columns

2020-08-16 Thread Morten Welinder
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
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Gnumeric website blocks Tor

2020-08-15 Thread Morten Welinder
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


Re: Whenever I try to save a file in *.gnumeric format, my gnumeric crashes

2020-07-04 Thread Morten Welinder
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


Re: copying empty cells, or not

2020-06-04 Thread Morten Welinder
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 suggests that Excel has no copy-value formula.  I
certainly know of
no such formula.  It's no secret that the semantics of Excel formulas
are, shall we
say, not always well thought through.  But it is what we have to play with.

Most vector operations ignore strings, booleans, and blanks.  You're
better of building
a solution around that as it should come with the ability to share
formulas with others.

Actually, be wary of booleans if you need to interoperate with
LibreOffice.  Last I checked
they did not have a concept of boolean values, only of numbers
formatted as booleans.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: copying empty cells, or not

2020-06-03 Thread Morten Welinder
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
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: copying empty cells, or not

2020-06-03 Thread Morten Welinder
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


Re: GoalSeek as a Function (not only a tool) in Gnumeric

2020-06-03 Thread Morten Welinder
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 drive Gnumeric's engine from a python script.

Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: libgsf - Child by name returns only GsfInput

2020-05-31 Thread Morten Welinder
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
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: go_rsm_register_file: assertion 'g_hash_table_lookup (rsm, id) == NULL' failed assertions

2020-03-20 Thread Morten Welinder
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
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: go_rsm_register_file: assertion 'g_hash_table_lookup (rsm, id) == NULL' failed assertions

2020-03-19 Thread Morten Welinder
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
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: "Save as Image" enhancements

2020-03-09 Thread Morten Welinder
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


Re: Ctrl+.

2019-12-06 Thread Morten Welinder
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


Re: libgsf tweaks

2019-10-16 Thread Morten Welinder
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 object
class becomes for standard and new objects can be created directly
with g_object_new if desired.

Comments?

Morten


ppp
Description: Binary data
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: libgsf tweaks

2019-10-15 Thread Morten Welinder
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 fields in the gzip header that it might make sense to
add and I can't see us having _really_full and _really_really_full
versions.  I need to think about that part.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: [patch] improve versatility and reliability of

2019-08-21 Thread Morten Welinder
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 distcheck.  Anything written by the compilation will go
into the build directory while src can remain readonly.  I don't think
that's related to the distcheck failure, though.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Adding Simple Feature to Gnumeric

2019-08-21 Thread Morten Welinder
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 test/t3001-introspection-simple.py -- certainly can.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: how to shade alternate rows?

2019-06-20 Thread Morten Welinder
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


Re: Getting the latest libgsf-1-dev lib for Ubuntu 16.04

2019-05-14 Thread Morten Welinder
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


Re: gnumeric & python2

2019-01-09 Thread Morten Welinder
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.

Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: File corruption if stream contains vector properties

2018-12-10 Thread Morten Welinder
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
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: How to use GsfTimestamp for windows timestamp (relative to 1.1.1601)

2018-11-19 Thread Morten Welinder
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


Re: How to use GsfTimestamp for windows timestamp (relative to 1.1.1601)

2018-11-19 Thread Morten Welinder
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.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Lambert function

2018-11-16 Thread Morten Welinder
Done.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Lambert function

2018-11-12 Thread Morten Welinder
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


Re: Crash !

2018-10-13 Thread Morten Welinder
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
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: segfault

2018-10-02 Thread Morten Welinder
Unrelated.  My fault.  Fixed.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: segfault

2018-10-02 Thread Morten Welinder
Fixed.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Снимок.PNG

2018-08-20 Thread Morten Welinder
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 Артём К. via gnumeric-list
 wrote:
>
> dear, how can I hide the highlighted rows and hide the grid?
>
> thx, dear : )
>
>
>
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: how to shade the background in every other row?

2018-06-12 Thread Morten Welinder
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 easier for the eye to discriminate between rows. I 
> can do this manually but it's very time consuming, and is broken anytime i 
> add or delete a row. Can someone please tell me the formula to do this and 
> how to apply it? Many thanks!
>
> peace
> bill dobbins
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: The tabbed sheet indicator disappeared in some sheets

2018-05-30 Thread Morten Welinder
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 created spreadsheeds.

> I tried to open the spreadsheet in LibreOffice (in which the tab is shown
and all the sheets are visible) and save it in xls format, but upon opening
in the Gnumeric the problem presists.

> I can still manage the sheets through the Sheet manager (from the Format
menu on top) so I am certain that the sheets are there, all of them are
editable (open lockers) and visible (eye icon).

> Is there any way to make the panel visible? Neither googling nor playing
with the settings helped me.

> WIth Regards,

> Pawel
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Recently used files list empty with Cinnamon

2018-04-30 Thread Morten Welinder
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
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: how to convert VB scripts to Gnumeric python

2018-04-14 Thread Morten Welinder
> So it's expected a Gnm.Cell and not the col, row provided in the program.

That's a sign you're picking up an old introspection file.  "make install"
might help.

M.

On Fri, Apr 13, 2018 at 9:18 PM <dm-gn...@mercuryresearch.com> wrote:

> Also using your test program, as is I get an error when it hits the

> sheet.cell_set_value

> operation, saying it got 3 variables instead of the 2 expected. When I
> change it to two, I get:

> TypeError: argument cell: Expected Gnm.Cell

> So it's expected a Gnm.Cell and not the col, row provided in the program.


> I suspect I'm probably testing a bit ahead of your patches on github.


> On 04/13/2018 06:00 PM, dm-gn...@mercuryresearch.com wrote:
> > OK, I've updated from github (I installed goffice and gnumeric) and
> > I'm getting a crash on my application's file IO:
> >
> > ** (pubrep:23096): WARNING **: Couldn't connect to accessibility bus:
> > Failed to connect to socket /tmp/dbus-E0H2kRCBCm: Connection refused
> > shell to uri
> > workbook view from uri
> >
> > ** (pubrep:23096): CRITICAL **: go_doc_init_read: assertion
> > 'doc->priv->imagebuf == NULL' failed
> > Segmentation fault
> >
> > This appears to be happening on the line
> >
> > s_wbv=Gnm.WorkbookView.new_from_uri(s_uri, None, io, None)
> >
> > Which is the actual workbook file open read. Though this may just be
> > 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 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 file also contains the "blessed"
> >> API.
> >> This is still evolving.
> >>
> >> My main test script is at
> >> Â Â Â
> >>
https://git.gnome.org/browse/gnumeric/tree/test/t3001-introspection-simple.py
> >> It does pretty much everything one can do to a workbook other than
> >> file i/o.
> >> (That's somewhere on my list.)
> >>
> >> Note: I have marked lots of functions as "skip" because they are
> >> low-level functions
> >> not intended for scripting.  Most of GnmCell's methods are like
> >> that.  They don't do
> >> what you would expect of them and there are proper alternatives,
> >> typically in Sheet.Â
> >>
> >> Morten
> >>
> >
> > ___
> > gnumeric-list mailing list
> > gnumeric-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gnumeric-list
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: how to convert VB scripts to Gnumeric python

2018-04-13 Thread Morten Welinder
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 file also contains the "blessed" API.
This is still evolving.

My main test script is at

https://git.gnome.org/browse/gnumeric/tree/test/t3001-introspection-simple.py
It does pretty much everything one can do to a workbook other than file i/o.
(That's somewhere on my list.)

Note: I have marked lots of functions as "skip" because they are low-level
functions
not intended for scripting.  Most of GnmCell's methods are like that.  They
don't do
what you would expect of them and there are proper alternatives, typically
in Sheet.

Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: how to convert VB scripts to Gnumeric python

2018-04-12 Thread Morten Welinder
Some progress.  I have something like this working now:

import gi
gi.require_version('Gnm', '1.12')
from gi.repository import Gnm
Gnm.init()

wb = Gnm.Workbook.new_with_sheets(1)
sheet = wb.sheet_by_index(0)
sheet.cell_set_value(0,0,Gnm.Value.new_int(10))
sheet.cell_set_value(0,1,Gnm.Value.new_float(1.0/3.0))
sheet.cell_set_text(0,2,"=A1+A2")
wb.recalc()

for i in range(3):
print sheet.cell_get_value(0,i).peek_string()

It's not a great API.  In fact, in it shows clear signs of being a bit
foreign to Python.

A gotcha: all versions of introspection until about 2 months ago
misunderstood "char const *" as "char *" causing problems with functions
like value_peek_string.  Such functions will need to have their return
value marked "transfer none".  ("const char *" worked fine, on the other
hand.)

M.








On Wed, Apr 11, 2018 at 8:01 PM <dm-gn...@mercuryresearch.com> wrote:

> Copying would be a helpful thing. I ran into similar problems. There is a
> workaround.
>
> My copy/paste operation core (sorry, this is c/p from my application so no
> setup code shown):
>
> cell = sheet.cell_fetch(col, row)
> if cell is not None:
> d_cell = d_sheet.cell_fetch(dest_col, dest_row)
> # For whatever reason, copying/duping value
> doesn't work, so we use other methods
> if (debug > 0): print dest_col, dest_row
> v = cell.get_rendered_text()
> d_cell.set_text(v)
> # This works but generates tons of
> gnm_style_unref errors
> style = cell.get_style()
> d_sheet.style_set_pos(dest_col, dest_row,
> style)
>
> d_sheet, d_cell is the destination to copy to.
>
> You essentially have to work with parts of a cell.
> I can probably help with the introspection annotations, as you've already
> seen from the
> patches I sent privately. I think if certain core functions are done first
> it will enable development
> that would uncover other problems.
>
> I have a personal development note document I will share here, since
> apparently rough drafts are OK to some of you and hint at problems:
>
> Gnome Introspection notes
>  - not part of the application
>  - used scanner driven code
>  - comments are code
>  - function names influence introspection interface
>  - names with "new" mostly result in constructor interfaces that return
> full-ownership objects that are easily usable.
>  - Comments may not export usable interface and this will not show up as a
> bug in the application. e.g. allow-none/nullable optional values. (* I
> previously described this about inserting "allow-none" in the defintions)
>
>  https://wiki.gnome.org/Projects/GObjectIntrospection#Annotation_System
>  https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations
>
> Python GI API Reference
> https://lazka.github.io/pgi-docs/
>
>
> Python and 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, object definitions tagged return-value
> transfer-ownership="full" are directly usable python objects
>  - other objects may need reference or memory management and can trigger
> segfaults
>
>
>
>
> On 04/11/2018 04:42 PM, Morten Welinder wrote:
>
> 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 distributions
> will see the fix.
>
> In this particular case I might be able to paper over the problem by
> interposing a function that copies
> its argument instead of taking ownership.  That'll slow down python a
> bit, but if you're using python
> you're probably not that much in a hurry.
>
> The key to getting parts of Gnumeric available via python is to have
> accurate introspection annotations
> for the relevant APIs.  If anyone feels like helping with that, it would
> be appreciated.
>
> Morten
>
>
>
>
>
> ___
> gnumeric-list mailing 
> listgnumeric-list@gnome.orghttps://mail.gnome.org/mailman/listinfo/gnumeric-list
>
>
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
>
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: how to convert VB scripts to Gnumeric python

2018-04-11 Thread Morten Welinder
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 distributions
will see the fix.

In this particular case I might be able to paper over the problem by
interposing a function that copies
its argument instead of taking ownership.  That'll slow down python a bit,
but if you're using python
you're probably not that much in a hurry.

The key to getting parts of Gnumeric available via python is to have
accurate introspection annotations
for the relevant APIs.  If anyone feels like helping with that, it would be
appreciated.

Morten
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: how to convert VB scripts to Gnumeric python

2018-04-11 Thread Morten Welinder
> Where does 'gi.repository' come from?

That is created when Gnumeric is configured with --enable-introspection
(which requires that
both libgsf and goffice also are configure that way).

Debian might have put the resulting files into another package.

M.




On Wed, Apr 11, 2018 at 1:54 PM Mike 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: how to convert VB scripts to Gnumeric python
> >
> > Here's a sample that just does a numerical computation:
> >
> > $ python
> > Python 2.7.12 (default, Dec  4 2017, 14:50:18)
> > [GCC 5.4.0 20160609] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> from gi.repository import Gnm;
> > __main__:1: PyGIWarning: Gnm was imported without specifying a version
> > first. Use gi.require_version('Gnm', '1.12') before import to ensure that
> > the right version gets loaded.
> > >>> Gnm.qnorm(0.2,0,1,0,0)
> > 0.8416212335729144
> >
> > Morten
>
> mike@/deb73:~> python
> Python 2.7.3 (default, Nov 24 2017, 16:26:37)
> [GCC 4.7.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from gi.repository import Gnm;
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: No module named gi.repository
>
> Not found from the gnumeric Python CL either.
> Where does 'gi.repository' come from?
> Is that from the larger Gnome desktop package?
> If it matters I'm running Debian Wheezy on a P3 w/ 256M ram.
>
> Thanks for your help,
> Mike
>
> --
> An open mind is apt to let anything inor out!
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
>
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Gnumeric for Windows 10?

2018-04-06 Thread Morten Welinder
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
>
>
> Att.
> *Gilmar Placeres *Simão
> *GPS Assessoria ME*
> https://www.linkedin.com/in/profsimao/
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
>
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: my-func.py

2018-04-06 Thread Morten Welinder
> 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 possibly for giggles.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: my-func.py

2018-04-06 Thread Morten Welinder
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. Going through the
> manual I've followed the instructions but have something wrong. Though
> py_add is recognized I get 'Function implementation not available.'
> when putting '=py_add(2,3)' in a cell.
> The correct sample mentioned doesn't seem to be available.
> Here's my my-func.py:
> # my-func.py
> #
>
> from Gnumeric import GnumericError, GnumericErrorVALUE
> import Gnumeric
> import string
>
> example_functions = {
> # Add two numbers together
> def func_add(num1, num2):
> '@FUNCTION=PY_ADD\n'\
> '@SYNTAX=py_add(num1, num2)\n'\
> '@DESCRIPTION=Adds two numbers together.\n'\
> 'Look, the description can go onto other lines.\n\n'\
> '@EXAMPLES=To add two constants, just type them in: py_add(2,3)\n'\
> 'To add two cells, use the cell addresses: py_add(A1,A2)\n\n'\
> '@SEEALSO='
>
> return num1 + num2
>
> # Translate the func_add python function to a gnumeric function and
> register
> example_functions = {
> 'py_add': ('ff','num1,num2',func_add)
> }
>
> }
>
> Thanks for the help,
> Mike
> --
> We'll be friends till we're old and senile... Then we'll be new
> friends!!
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
>
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: How to prevent Gnumeric from overwriting the same file by different gnumeric instances

2018-03-25 Thread Morten Welinder
The next version of Gnumeric will verify that the time stamp has the expected
value before overwriting.

Morten


On Sat, Mar 24, 2018 at 7:09 PM, Yury Dubinsky <yury.dubin...@gmail.com> wrote:
> I believe  timestamp checking must be anyway. Just lock files cannot
> be a very reliable 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 Welinder <mort...@gnome.org>
>> wrote :
>>>  [...]
>>>
>>> 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
>>> networked
>>> file systems are the primary reason why one would want locking.
>>> Specifically,
>>> O_EXCL isn't going to be necessarily exclusive.
>>>
>>> M.
>>> ___
>>> gnumeric-list mailing list
>>> gnumeric-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/gnumeric-list
>> ___
>> gnumeric-list mailing list
>> gnumeric-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gnumeric-list
>>
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: How to prevent Gnumeric from overwriting the same file by different gnumeric instances

2018-03-22 Thread Morten Welinder
> 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 networked
file systems are the primary reason why one would want locking.  Specifically,
O_EXCL isn't going to be necessarily exclusive.

M.
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: How to prevent Gnumeric from overwriting the same file by different gnumeric instances

2018-03-22 Thread Morten Welinder
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.


On Thu, Mar 22, 2018 at 5:13 PM, Yury Dubinsky  wrote:
> Hello,
> When we click on a spreadsheet file, Gnumeric every time opens the file  in
> a new program instance without any checking if this file was already open.
> Thus, it is extremely easy to accidentally overwrite the file content.
> The most of advanced text editors warn users in case when open files are
> changed on the disk. Office suites, such as LibreOffice, MS Office lock open
> files.
> Is there anything similar in Gnumeric?
> Thanks,
>  Yury
>
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
>
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: goffice-0.10.38 build problems

2018-03-02 Thread Morten Welinder
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 at 2:04 PM, Jason Martin  wrote:
> Thanks, that works but I still did not get the 32 bit version of goffice to
> pass math tests.
>
> I ended up just shipping 64 bit version, if it gets approved.
>
> Rebuilt and tested gnumeric 64 bit and all seems fine.
>
> I may have missed some extra build/enviroment option for 32 bit in
> oi-userland Makefile.
>
> Gnumeric has an excellent reputation and I want it to stay that way.
>
> It is a great piece of open source work.
>
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
>
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: goffice-0.10.38 build problems

2018-03-01 Thread Morten Welinder
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 failing for me
>
> test-math.log
>
> sinpi(0) = 0  [0]
> cospi(0) = 1  [1]
> tanpi(0) = 0  [0]
> cotpi(0) = nan  [nan]
> atanpi(0) = 0  [0]
> sinpil(0) = 0  [0]
> cospil(0) = 1  [1]
> tanpil(0) = 0  [0]
> cotpil(0) = nan  [nan]
> atanpil(0) = 0  [0]
> sinpi(-0) = -0  [-0]
> cospi(-0) = 1  [1]
> tanpi(-0) = -0  [-0]
> cotpi(-0) = -nan  [-nan]
> atanpi(-0) = -0  [-0]
> sinpil(-0) = -0  [-0]
> cospil(-0) = 1  [1]
> tanpil(-0) = -0  [-0]
> cotpil(-0) = -nan  [-nan]
> atanpil(-0) = -0  [-0]
> sinpi(0.125) = 0.382683  [0.382683]
> cospi(0.125) = 0.92388  [0.92388]
> tanpi(0.125) = 0.414214  [0.414214]
> cotpi(0.125) = 2.41421  [2.41421]
> atanpi(0.125) = 0.0395834  [0.0395834]
> sinpil(0.125) = 0.382683  [0.382683]
> cospil(0.125) = 0.92388  [0.92388]
> tanpil(0.125) = 0.414214  [0.414214]
> cotpil(0.125) = 2.41421  [2.41421]
> atanpil(0.125) = 0.0395834  [0.0395834]
> sinpi(-0.125) = -0.382683  [-0.382683]
> cospi(-0.125) = 0.92388  [0.92388]
> tanpi(-0.125) = -0.414214  [-0.414214]
> cotpi(-0.125) = -2.41421  [-2.41421]
> atanpi(-0.125) = -0.0395834  [-0.0395834]
> sinpil(-0.125) = -0.382683  [-0.382683]
> cospil(-0.125) = 0.92388  [0.92388]
> tanpil(-0.125) = -0.414214  [-0.414214]
> cotpil(-0.125) = -2.41421  [-2.41421]
> atanpil(-0.125) = -0.0395834  [-0.0395834]
> sinpi(0.25) = 0.707107  [0.707107]
> cospi(0.25) = 0.707107  [0.707107]
> tanpi(0.25) = 1  [1]
> cotpi(0.25) = 1  [1]
> atanpi(0.25) = 0.0779791  [0.0779791]
> sinpil(0.25) = 0.707107  [0.707107]
> cospil(0.25) = 0.707107  [0.707107]
> tanpil(0.25) = 1  [1]
> cotpil(0.25) = 1  [1]
> **
> ERROR:/export/home/agrellum/oi-userland/components/library/goffice/goffice-0.10.38/tests/test-math.c:106:trig_tests:
> assertion failed: (r == fa)
> FAIL test-math (exit status: 134)
>
> I think the next call would be atanpil at 0.25
>
> and it is excepting both sides to be 0.077979
>
> Going through the source and man pages:
>
> A sample shows:
>
>
> #include 
> #include 
>
> int main (int argc, char **argv)
> {
> long double x;
> x=0.25;
> printf("outputs: %f \n", atanl (x) / M_PI);
> // Output: ``outputs: -0.00``
>
> return 0;
> }
>
>
> gcc -std=gnu99 -lm sample.c
> ./a.out
>
> outputs: -0.00
>
>
>
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
>
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Request of information

2018-02-08 Thread Morten Welinder
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 the
> Linux ubuntu OS.
>
> The maximum screen resolution I can setup is 1024x600 pixels, I know it is
> very low.
>
> I am having a problem with the pop-upped windows that are displayed outside
> my screen.
>
> Please could someone told me if and how I can avoid this issue ?
>
>
>
> Thanks
>
> nicola
>
>
>
>
> Eni SpA
> Sede Legale
> Piazzale Enrico Mattei, 1
> 00144 Roma - Italia
>
> Capitale sociale
> euro 4.005.358.876,00 i.v.
> Codice Fiscale e Registro Imprese di Roma n. 00484960588
> Partita IVA n. 00905811006
> R.E.A. Roma n. 756453
>
> Sedi secondarie:
> Via Emilia, 1 e Piazza Ezio Vanoni, 1
> 20097 San Donato Milanese (Milano) – Italia
>
> eni.com
>
> 
> Message for the recipient only, if received in error, please notify the
> sender and read http://www.eni.com/disclaimer/
>
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
>
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Gnumeric on Mac OS X

2018-01-10 Thread Morten Welinder
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, but it does work.
> This release doesn’t include databases support yet.
> Still missing native menus and shortcuts to make it a great MacOS
> application, but you’ll like it anyway for what it can already do.
>
> Enjoy!
>
> https://www.dropbox.com/s/nbisw6ifpxiyjnk/Gnumeric-1.12.38.7z
> 
>
>
>
> --
> Sent from: http://gnome-apps.13852.n7.nabble.com/GnuMeric-f3818.html
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: Extensions to ODF

2018-01-06 Thread Morten Welinder
> 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 certain it is complete.

Morten




On Fri, Jan 5, 2018 at 11:06 AM, Regina Henschel
 wrote:
> Hi all,
>
> does there exists a public available list of Gnumeric extensions to ODF?
>
> Kind regards
> Regina Henschel
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: gnumeric-list Digest, Vol 161, Issue 2

2017-11-18 Thread Morten Welinder
> set the number format for all cells in the book

The default for that is always "General".  When you open a blank
workbook, we do not load a file.


M.

On Sat, Nov 18, 2017 at 8:25 AM, Chris Dunn <ch...@iccqs.com> wrote:
> Morten,
>
> Thanks and noted.
>
> The one thing that I'd like to do that you don't mention is being able
> to set the number format for all cells in the book. Maybe other things
> too.
>
> Is this possible?
>
> I had a vague memory (rapidly age failing) that it was possible somehow
> to modify the default template that 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> wrote :
>
>> You can set a couple of things such as default font and sheet size in
>> Edit->Preferences.
>>
>> Morten
>>
>>
>> On Wed, Nov 15, 2017 at 7:30 AM, Chris Dunn <ch...@iccqs.com> wrote:
>> > I've searched all that I can, but can't find the answer.
>> >
>> > How do I change the properties of the default Gnumeric template?
>> >
>> > That is to say, how can I change the format of cells, font size etc
>> > of any new workbook that I open?
>> >
>> > Thanks in advance.
>> >
>
> --
>
> Chris Dunn
>
>
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: failed to compile goffice from git on debian 9

2017-10-29 Thread Morten Welinder
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, Andreas, and Jean.  The method is that
they tell me when I break something and we hash it out.  It doesn't scale.

At the tarball level there is a slow feedback from distributions.  The
major ones are pretty good at letting me know of problems,
generally arising from them using newer dependents than I do.

Now, specifically m4/glib-gettext.m4.  You probably had a copy from a
previous version of your distribution, i.e., from before a
system upgrade.  That happens, but I can't really tell the difference
between an edited file and an old file, so blowing the file
away unconditionally seems unwise.

Morten





On Sun, Oct 29, 2017 at 11:59 AM, Frédéric Parrenin
 wrote:
> Answering to myself.
> The solution is to delete the file m4/glib-gettext.m4.
> Note that gnumeric is also affected.
> Maybe it is worth a fix in the build system?
>
> Best,
>
> Frédéric
>
>
> Le 24/10/2017 à 16:21, Frédéric Parrenin a écrit :
>>
>> Dear all,
>>
>> Today I tried to compile the git version of goffice.
>> I get the following error message when running ./autogen.sh:
>>
>> root@lgge179:/usr/local/goffice# ./autogen.sh
>> m4/glib-gettext.m4:39: error: m4_copy: won't overwrite defined macro:
>> glib_DEFUN
>> m4/glib-gettext.m4:39: the top level
>> autom4te: /usr/bin/m4 failed with exit status: 1
>> aclocal: error: echo failed with exit status: 1
>>
>> Any help would be appreciated!
>>
>> Thanks,
>>
>> Frédéric
>>
>
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: gnumeric for AIX 7.1

2017-09-20 Thread Morten Welinder
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 AIX ?
>
>
>
> Thanks in advance,
>
>
>
> Regards
>
> Bruno
>
>
>
>
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
>
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: ssconvert - column spacing

2017-08-27 Thread Morten Welinder
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 recently, and it really is excellent!
>
> The main problem that I've been having has been column widths. Various
> spreadsheet programs say they make the columns as wide as the widest
> entry (which would be fine), but they clearly don't.
>
> Is there a way to get ssconvert to set the column width? Either to the
> maximum size or to any size.
>
> I've been using MacoS Numbers and LibreOffice Calc.
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


Re: GnumericTest.pm porting question

2017-08-26 Thread Morten Welinder
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:
>
> GnumericTest::test_importer(GnumericTest.pm:400):
> 400: my $htxt = zcat -f '$tmp' | $normalize_gnumeric | sha1sum;
> DB<1> s
> Invalid Option
> Usage: zcat [file ...]
>
>
> On OpenIndiana or Solaris the zcat command will be one of the two:
>
> my $htxt = `compress -f '$tmp' | $normalize_gnumeric | sha1sum`;
> -or---
> my $htxt = `uncompress -f '$tmp' | $normalize_gnumeric | sha1sum`;
>
> BUT how did the original author get the checksum for example the test
> t5905-guppi.pl
>
> _importer ("$samples/b6-guppi.gnumeric",
> "4f9552b87482dfa330ed251dffef467939478244", $mode);
>
> None of my changes have worked so far.
>
>
> Thanks
>
>
>
> ___
> gnumeric-list mailing list
> gnumeric-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
>
___
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list


  1   2   3   4   5   >