Re: Excel Spreadsheet to PDF (was: Re: PDF on debian)

[Jeffrey Walton]

On Thu, Mar 9, 2023 at 10:42 PM Charles Curley
 wrote:
>
> On Fri, 10 Mar 2023 08:50:08 +0800
> Corey Hickman  wrote:
>
> > If I want to convert some excel files to PDF, what's the suggested
> > way? I know I can program with java to implement that, but if there
> > are existing command-line solutions I would like to try them.
> [...]
>
> Given the nature of this list, I conjecture you want a solution that
> works on Linux.
>
> I would use LibreOffice to export to PDF. I believe one can script the
> process.

++

I use the following for ODT files:

odt_files=(...)
for odt_file in "${odt_files[@]}"
do
echo "Processing ${odt_file}"
lowriter --convert-to pdf "${odt_file}"
done

Jeff

Excel Spreadsheet to PDF (was: Re: PDF on debian)

[Charles Curley]

On Fri, 10 Mar 2023 08:50:08 +0800
Corey Hickman  wrote:

> If I want to convert some excel files to PDF, what's the suggested
> way? I know I can program with java to implement that, but if there
> are existing command-line solutions I would like to try them.

This really should have been a new email thread.

Given the nature of this list, I conjecture you want a solution that
works on Linux.

I would use LibreOffice to export to PDF. I believe one can script the
process.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: OT: Freestanding spreadsheet program?

[Russell]

Weaver  wrote:
> On 24-04-2021 08:25, Stefan Monnier wrote:
>>> Back in the good (bad?) old days of TRS-80, all we had was VisiCalc. Simple.
>>> Today, is there a useful spreadsheet program that does not rely on all the
>>> baggage associated with either an "office suite," or
>>> a "desktop environment?"
>> 
>> I can mention `gnumeric` and if you're into Emacs I can also also
>> suggest SES.
> 
> Plus 1 for gnumeric.
> Excellent.
> Doesn't drop data on large data sets as much vaunted proprietary
> programmes do.
> Cheers!
> 
> Harry.

I think he also wanted something that doesn't require a desktop
environment.

-- 
rust
0x68caecc97f6a90122e51c0692c88d9cb6b58a3dc

Re: OT: Freestanding spreadsheet program?

[Weaver]

On 25-04-2021 13:07, rustbuck...@pm.me wrote:
> Weaver  wrote:
>> On 24-04-2021 08:25, Stefan Monnier wrote:
>>>> Back in the good (bad?) old days of TRS-80, all we had was VisiCalc. 
>>>> Simple.
>>>> Today, is there a useful spreadsheet program that does not rely on all the
>>>> baggage associated with either an "office suite," or
>>>> a "desktop environment?"
>>>
>>> I can mention `gnumeric` and if you're into Emacs I can also also
>>> suggest SES.
>>
>> Plus 1 for gnumeric.
>> Excellent.
>> Doesn't drop data on large data sets as much vaunted proprietary
>> programmes do.
>> Cheers!
>>
>> Harry.
> 
> I think he also wanted something that doesn't require a desktop
> environment.

Not the way I read it.
The inference I picked up was he wanted one that didn't require
installing any particular DE. 
One that wasn't dependent on any particular desktop environment, or
required the installation of an entire office suite.
Regardless, the OP has made a decision on the matter now, and is happy.
Cheers!

Harry
-- 
`Great spirits have often encountered 
violent opposition from weak minds'.
-- Albert Einstein

Re: OT: Freestanding spreadsheet program?

[Stefan Monnier]

> I think he also wanted something that doesn't require a desktop environment.

AFAIK Gnumeric works fine in "naked X11".


Stefan

Re: OT: Freestanding spreadsheet program?

[Bob Bernstein]

Thank you all. For reasons completely beyond my grasp I selected 
'teapot' for further investigation despite there being as far as 
I can tell no deb for it.


Oh well.

9-)

--
RSB

Re: OT: Freestanding spreadsheet program?

[Weaver]

On 24-04-2021 08:25, Stefan Monnier wrote:
>> Back in the good (bad?) old days of TRS-80, all we had was VisiCalc. Simple.
>> Today, is there a useful spreadsheet program that does not rely on all the
>> baggage associated with either an "office suite," or
>> a "desktop environment?"
> 
> I can mention `gnumeric` and if you're into Emacs I can also also
> suggest SES.

Plus 1 for gnumeric.
Excellent.
Doesn't drop data on large data sets as much vaunted proprietary
programmes do.
Cheers!

Harry.

Re: OT: Freestanding spreadsheet program?

[Stefan Monnier]

> Back in the good (bad?) old days of TRS-80, all we had was VisiCalc. Simple.
> Today, is there a useful spreadsheet program that does not rely on all the
> baggage associated with either an "office suite," or
> a "desktop environment?"

I can mention `gnumeric` and if you're into Emacs I can also also
suggest SES.


Stefan

Re: OT: Freestanding spreadsheet program?

[Jude DaShiell]

sure, teapot.


On Fri, 23 Apr 2021, Dan Ritter wrote:

> Bob Bernstein wrote:
> > Back in the good (bad?) old days of TRS-80, all we had was VisiCalc. Simple.
> >
> > Today, is there a useful spreadsheet program that does not rely on all the
> > baggage associated with either an "office suite," or a "desktop
> > environment?"
> >
>
> Sure.
>
> treesheets
>
> pyspread
>
> sc
>
> -dsr-
>
>

Re: OT: Freestanding spreadsheet program?

[Dan Ritter]

Bob Bernstein wrote: 
> Back in the good (bad?) old days of TRS-80, all we had was VisiCalc. Simple.
> 
> Today, is there a useful spreadsheet program that does not rely on all the
> baggage associated with either an "office suite," or a "desktop
> environment?"
> 

Sure.

treesheets

pyspread

sc

-dsr-

OT: Freestanding spreadsheet program?

[Bob Bernstein]

Back in the good (bad?) old days of TRS-80, all we had was 
VisiCalc. Simple.


Today, is there a useful spreadsheet program that does not rely 
on all the baggage associated with either an "office suite," or a 
"desktop environment?"


Thx,


--
"...that there is no getting away from the central position of the individual I believe 
anyone can see for himself merely by observing that the individual does not regard the 
following to be a senseless question: "Under what conditions would you draw the 
conclusion that everyone in the world except yourself had gone crazy?"

Bridgman _The Nature of Physical Theory_ (1936)

Re: Example(s) of recutils project flow? - was [FOSS equivalents of *OLD* database and spreadsheet tools?]

[Andrei POPESCU]

On Vi, 07 aug 20, 07:33:05, Richard Owlett wrote:
> 
> I had done similar search with DuckDuckGo receiving similarly useless hits.

[...]
 
> That's why I'm looking for a human's answer.

It helps to specify in advance what you tried already and didn't work.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Example(s) of recutils project flow? - was [FOSS equivalents of *OLD* database and spreadsheet tools?]

[Richard Owlett]

On 08/07/2020 06:46 AM, David wrote:

On Fri, 7 Aug 2020 at 21:31, Richard Owlett  wrote:

On 07/27/2020 10:13 AM, Eric S Fraga wrote:

You may wish to have a look at recutils:



https://www.gnu.org/software/recutils/



I've done a first read of the well written manual which has many
examples of individual commands. Are there any examples of project
workflow using shell scripts or Tcl?


https://www.google.com/search?q=recutils+script+example



I had done similar search with DuckDuckGo receiving similarly useless hits.
I tried more restrictive forms of your search i.e.
https://www.google.com/search?gbv=1=%2Brecutils+%2Bscript+%2Bexample
and
https://www.google.com/search?gbv=1=%2B%22recutils%22+%2B%22tcl%22+%2B%22example%22

The second is especially irrelevant - it *ACTIVELY* ignores request that 
"recutils" *MUST* be present.


That's why I'm looking for a human's answer.
Thank you.

Re: Example(s) of recutils project flow? - was [FOSS equivalents of *OLD* database and spreadsheet tools?]

[David]

On Fri, 7 Aug 2020 at 21:31, Richard Owlett  wrote:
> On 07/27/2020 10:13 AM, Eric S Fraga wrote:
> > You may wish to have a look at recutils:

> > https://www.gnu.org/software/recutils/

> I've done a first read of the well written manual which has many
> examples of individual commands. Are there any examples of project
> workflow using shell scripts or Tcl?

https://www.google.com/search?q=recutils+script+example

Example(s) of recutils project flow? - was [FOSS equivalents of *OLD* database and spreadsheet tools?]

[Richard Owlett]

On 07/27/2020 10:13 AM, Eric S Fraga wrote:

You may wish to have a look at recutils:

https://www.gnu.org/software/recutils/

but it may not have some of the functionality you wish (although you
could build on it with shell scripts & awk, say).



I've done a first read of the well written manual which has many 
examples of individual commands. Are there any examples of project 
workflow using shell scripts or Tcl?


TIA

Re: [Interim Solution] Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Tom Dial]

On 7/29/20 06:03, Richard Owlett wrote:
> On 07/29/2020 06:13 AM, Joe wrote:
>> [snip]
>>
>> I'd recommend using the right tool for the job.
>>
> 
> Which is why I'll investigate.
> Your approach is literally orders of magnitude more than I want.

With respect, Joe is right, in my opinion based on some about 20 as a
DBA and later head of the database branch in a DOD agency.

I quite understand what you are proposing, and over the years the branch
spent a good deal of time and taxpayer resources sorting such
applications developed by accountants to help them in their work. Over
time they grew big and complex beyond their original simple design,
scaled and performed poorly, became infected with data (and formula)
errors that the developers could not fix. All too often the developers
had retired or otherwise moved on and their successors, who had little
understanding of the application beyond its use, were completely at a
loss. It was a mess, and around the time I retired, we did an agency
wide search and found around 500 of them, quite a few critical to
accounting operations yet largely undocumented and often seriously at
variance with accepted accounting rules and standards. The projected
cost of cleaning up was mind-boggling.

Many of those concerns, of course, do not apply to a relatively small
dietary application like you are considering (but consider Joe's size
metrics). A number of them do.

1. Lack of documentation. It takes a lot of discipline to document any
application even to the point where the developer, after a few weeks,
can easily identify its organization and fix or extend it. That is more
difficult with a set of spreadsheets than with a proper relational
database where the defining statements go a considerable way to
documenting themselves.

2. Errors. A decently designed relational database will present fewer
opportunities to insert data errors and make them easier to find and fix
when they do creep in.

3. Work involved. It is entirely possible to design a relational system
based only on CSV or other flat files; Unix, and I suppose Linux even
provides commands for most or all of the fundamental processes, and
desktop machines no more than a decade or so old can perform reasonably
well for small and moderate size databases and straightforward queries,
although performance will fall fairly rapidly with size and complexity,
and designing queries is harder and more labor intensive and error prone
than using a tool - SQL - designed for the job.

I have not looked at recutils, and my opinion is not necessarily worth
much as far as they are concerned. That said, I think it is unlikely
that the learning curve would be lower or less steep than with a proper
DBMS. My preference in a Linux environment is Postgres, but MariaDB and
SQLite are quite up to the task. Any of them can be installed with a
single command, and at least one probably already is installed. Their
configuration for basic use is not difficult, and there are ample web
based and probably public library based sources of "howto" information.

You are the best judge of your situation, but the notion that setting up
and using a proper database is "literally orders of magnitude more than"
a utility based alternative almost certainly is rubbish; it is, at
worst, only slightly more, and the benefits are substantially more.

Regards,
Tom Dial

Re: [Interim Solution] Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Joe]

On Thu, 30 Jul 2020 10:51:06 -0400
Miles Fidelman  wrote:

> On 7/30/20 5:21 AM, Eric S Fraga wrote:
> 
> > On Wednesday, 29 Jul 2020 at 04:40, Richard Owlett wrote:  
> >> On 07/27/2020 10:13 AM, Eric S Fraga wrote:  
> >>> You may wish to have a look at recutils:  
> >> A database is over-kill for some personal preferences.
> >>
> >> I had mentioned spreadsheets in original post as I had visualized
> >> a  
> > I am confused. You also mentioned databases and specifically SQL for
> > querying databases.
> >  
> Yes, indeed - it sure seems like SQL will be necessary for either
> querying, or importing from, databases of nutritional content.
> Building the app around and SQL engine - say SQL Lite - would seem to
> make a lot of sense.
> 
> Anything else, and some kind of converter will be needed.
>

There's at least one US database in spreadsheet form, I found it a
couple of years ago. The problem for me was that the numbers aren't the
same for the UK, even with basic foodstuffs, and the proprietary foods
are formulated for local market preferences. I'm mostly using a UK
database with about 3000 entries.

I wasn't keen on the idea of tapping an Internet database directly.
Firstly, the Net is a lot more ephemeral than we like to think, and
things do just disappear, but also these databases are of variable
quality, often containing alphabetic characters where numbers are
expected. I preferred to make my own databases, cleaning up information
where necessary and dropping most of the nutrients. I also often need
to create entries, both from the sides of packets for packaged foods
and ingredients lists for home-cooked dishes.

-- 
Joe

Re: [Interim Solution] Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Richard Owlett]

On 07/30/2020 09:51 AM, Miles Fidelman wrote:

In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: [Interim Solution] Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Miles Fidelman]

On 7/30/20 5:21 AM, Eric S Fraga wrote:


On Wednesday, 29 Jul 2020 at 04:40, Richard Owlett wrote:

On 07/27/2020 10:13 AM, Eric S Fraga wrote:

You may wish to have a look at recutils:

A database is over-kill for some personal preferences.

I had mentioned spreadsheets in original post as I had visualized a

I am confused. You also mentioned databases and specifically SQL for
querying databases.


Yes, indeed - it sure seems like SQL will be necessary for either querying,
or importing from, databases of nutritional content.  Building the app around
and SQL engine - say SQL Lite - would seem to make a lot of sense.

Anything else, and some kind of converter will be needed.

Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

Re: [Interim Solution] Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Eric S Fraga]

On Thursday, 30 Jul 2020 at 06:15, Richard Owlett wrote:
> Does that sound at all like I saw anything in favor of SQL ?  !

No but you said:

> IIRC, dBase was simpler.

so I suggested a simple FOSS database system.  Like I said, no
worries.  I obviously misunderstood what you were looking for.

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.7 on Debian bullseye/sid

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Richard Owlett]

On 07/30/2020 08:03 AM, Linux-Fan wrote:

Richard Owlett writes:


On 07/27/2020 10:13 AM, Eric S Fraga wrote:

You may wish to have a look at recutils:

https://www.gnu.org/software/recutils/

but it may not have some of the functionality you wish (although you
could build on it with shell scripts & awk, say).



I've just begun going through the manual
  [https://www.gnu.org/software/recutils/manual/]
It appears to be a good match for what I want to do.

I prefer reading manuals offline. Is it available as a single HTML 
document?


I have not found it as a single HTML document, but it should be possible to
generate it given that the online variant is also generated -- the HTML 
source
tells it was generated by `makeinfo` which you can find it in package 
texinfo.


On a Debian system with deb-src lines and texinfo installed, I could do:

 $ aptitude source recutils
 $ mkdir sub
 $ tar -C sub -xf recutils_1.7.orig.tar.gz
 $ cd sub
 $ makeinfo --html ./recutils-1.7/doc/recutils.texi

Afterwards, the generated HTML files (not a single document, but the same
view you find online) were available in directory `sub/recutils`.

If it is just about offline reading and less about the HTML: Seems the
complete documentation is shipped as part of Debian package recutils
(access it via `info recutils`).



As I'm already familiar with it, I'll use WebHTTrack to get a local copy 
of the manual. Being able to jump to references [my reason to prefer 
HTML] is more important than ease of stepping linearly thru a document 
[i.e. using space key in 'info'].


Thanks.

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Linux-Fan]

Richard Owlett writes:


On 07/27/2020 10:13 AM, Eric S Fraga wrote:

You may wish to have a look at recutils:

https://www.gnu.org/software/recutils/

but it may not have some of the functionality you wish (although you
could build on it with shell scripts & awk, say).



I've just begun going through the manual
  [https://www.gnu.org/software/recutils/manual/]
It appears to be a good match for what I want to do.

I prefer reading manuals offline. Is it available as a single HTML document?


I have not found it as a single HTML document, but it should be possible to
generate it given that the online variant is also generated -- the HTML source
tells it was generated by `makeinfo` which you can find it in package texinfo.

On a Debian system with deb-src lines and texinfo installed, I could do:

$ aptitude source recutils
$ mkdir sub
$ tar -C sub -xf recutils_1.7.orig.tar.gz
$ cd sub
$ makeinfo --html ./recutils-1.7/doc/recutils.texi

Afterwards, the generated HTML files (not a single document, but the same
view you find online) were available in directory `sub/recutils`.

If it is just about offline reading and less about the HTML: Seems the
complete documentation is shipped as part of Debian package recutils
(access it via `info recutils`).

HTH
Linux-Fan


pgp3JqWeYFaDO.pgp
Description: PGP signature

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Richard Owlett]

On 07/27/2020 10:13 AM, Eric S Fraga wrote:

You may wish to have a look at recutils:

https://www.gnu.org/software/recutils/

but it may not have some of the functionality you wish (although you
could build on it with shell scripts & awk, say).



I've just begun going through the manual
  [https://www.gnu.org/software/recutils/manual/]
It appears to be a good match for what I want to do.

I prefer reading manuals offline. Is it available as a single HTML document?

TIA

Re: [Interim Solution] Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Richard Owlett]

On 07/30/2020 04:21 AM, Eric S Fraga wrote:

On Wednesday, 29 Jul 2020 at 04:40, Richard Owlett wrote:

On 07/27/2020 10:13 AM, Eric S Fraga wrote:

You may wish to have a look at recutils:


A database is over-kill for some personal preferences.

I had mentioned spreadsheets in original post as I had visualized a


I am confused. You also mentioned databases and specifically SQL for
querying databases.

No worries.



Quoting yours truly:

SQL {and variants} seen to dominate all else.
IIRC, dBase was simpler. 


Does that sound at all like I saw anything in favor of SQL ?  !

Re: [Interim Solution] Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[tomas]

On Wed, Jul 29, 2020 at 01:09:15PM -0700, David Christensen wrote:
> On 2020-07-29 05:03, Richard Owlett wrote:
> 
> >[A suggested] approach is literally orders of magnitude more than I want.
> 
> 
> Consider these idealized cost functions for solution technologies A,
> B, and C:
> 
> fA(t) = t*t + 1
> 
> fB(t) = (t/3)*(t/3) + 10
> 
> fC(t) = (t/10/*(t/10) + 100
[...]

I really fear that's the way economists operate. This would explain
a lot of things ;-P

Cheers
-- t


signature.asc
Description: Digital signature

Re: [Interim Solution] Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Eric S Fraga]

On Wednesday, 29 Jul 2020 at 04:40, Richard Owlett wrote:
> On 07/27/2020 10:13 AM, Eric S Fraga wrote:
>> You may wish to have a look at recutils:
>
> A database is over-kill for some personal preferences.
>
> I had mentioned spreadsheets in original post as I had visualized a

I am confused. You also mentioned databases and specifically SQL for
querying databases.

No worries.
-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.7 on Debian bullseye/sid

Re: [Interim Solution] Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[David Christensen]

On 2020-07-29 05:03, Richard Owlett wrote:


[A suggested] approach is literally orders of magnitude more than I want.



Consider these idealized cost functions for solution technologies A, B, 
and C:


fA(t) = t*t + 1

fB(t) = (t/3)*(t/3) + 10

fC(t) = (t/10/*(t/10) + 100


Observe:

- fA has the lowest initial cost, but the highest cost over time.

- fB has an order of magnitude higher initial cost, but an order of 
magnitude lower cost over time.


- fC has the highest initial cost and the lowest cost over time.

- fA and fB intersect at time tAB.

- fB and fC intersect at time tBC.


The obvious strategy is to estimate t and pick the technology with the 
lowest cost:


-  For t < tAB, pick technology A.

-  For tAB < t < tBC, pick technology B.

-  For tBC < t, pick technology C.


The debate is over which cost function applies to which technology, and 
estimates of t.



I would put Excel and scripting language solutions into A.  I would put 
Access into B (unfortunately, there does not appear to be a FOSS B),  I 
would put .NET, Java, CORBA, LAMP, etc., into C.  Using Perl, I estimate 
your app should be t < tAB.



David

Re: [Interim Solution] Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Richard Owlett]

On 07/29/2020 06:13 AM, Joe wrote:

[snip]

I'd recommend using the right tool for the job.



Which is why I'll investigate.
Your approach is literally orders of magnitude more than I want.

Re: [Interim Solution] Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Joe]

On Wed, 29 Jul 2020 04:40:24 -0500
Richard Owlett  wrote:

> On 07/27/2020 10:13 AM, Eric S Fraga wrote:
> > You may wish to have a look at recutils:
> > 
> > https://www.gnu.org/software/recutils/
> > 
> > but it may not have some of the functionality you wish (although you
> > could build on it with shell scripts & awk, say).
> >   
> 
> A database is over-kill for some personal preferences.

Which isn't what you're talking about.
> 
> I had mentioned spreadsheets in original post as I had visualized a 
> multiple page spreadsheet. One page for the nutrient components of a 
> food. One page that would be used to input date, food, and amount.

Presumably you don't want to also enter the nutrients for each food in
each meal, you want your system to look up values for that food from a
list somewhere.

>  A 
> page that would have date and total of nutrient for that date. But I 
> couldn't figure out the details.
> 
> IIUC can import data from a CSV file.
> I could have one file for nutrient content of foods and one file with 
> date, food, quantity, and unique record id.

And this is the kind of thing that spreadsheets can do on a small
scale, but they don't scale up well. As I said, I'm on over 300 foods
and adding one or two a week. I'm also looking at about a dozen
nutrients, and have over 17,000 journal entries over about 2 1/2 years.

This is exactly the kind of thing that databases are very good at.
> 
> Process would be edit to the appropriate CSV file to add information.
> There would be a "report generator" which would read CSV files,
> convert them to recfile, then create a "Total Consumed" recfile to be
> displayed. [ A data join IIUC]. That recfile may initially be display
> only.

So is this.

I'd recommend using the right tool for the job.

-- 
Joe

Re: [Interim Solution] Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[mick crane]

On 2020-07-29 10:40, Richard Owlett wrote:


A database is over-kill for some personal preferences.


apropos of nothing I found this great, clear introduction to Perl/Tk for 
inputting how many cups of coffee and bacon sandwiches you had.

https://www.ibm.com/developerworks/aix/library/au-perltkmodule/index.html
mick
--
Key ID4BFEBB31

[Interim Solution] Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Richard Owlett]

On 07/27/2020 10:13 AM, Eric S Fraga wrote:

You may wish to have a look at recutils:

https://www.gnu.org/software/recutils/

but it may not have some of the functionality you wish (although you
could build on it with shell scripts & awk, say).



A database is over-kill for some personal preferences.

I had mentioned spreadsheets in original post as I had visualized a 
multiple page spreadsheet. One page for the nutrient components of a 
food. One page that would be used to input date, food, and amount. A 
page that would have date and total of nutrient for that date. But I 
couldn't figure out the details.


IIUC can import data from a CSV file.
I could have one file for nutrient content of foods and one file with 
date, food, quantity, and unique record id.


Process would be edit to the appropriate CSV file to add information.
There would be a "report generator" which would read CSV files, convert 
them to recfile, then create a "Total Consumed" recfile to be displayed. 
[ A data join IIUC]. That recfile may initially be display only.

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Miles Fidelman]

On 7/27/20 9:59 PM, rhkra...@gmail.com wrote:


Somebody wrote:



But... isn't the tool the least of your problems?  The big one being,
where are you going to get your nutritional database. (Seems to me that
most of what Weight Watchers and Noom do is collect data on millions of
products.)

 From my records in my free format database (which would not be suitable for
your program (at least not in its present condition), some notes on available
databases.

 From "USDA databases" Thu Sep 08 06:57:41 2016
Date: 09/08/16 06:57 am
Subject: USDA databases




What a great list of databases!  Thanks for posting this.  Who knew?

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[mick crane]

On 2020-07-27 22:46, Michael Stone wrote:

On Mon, Jul 27, 2020 at 10:34:39PM +0100, Joe wrote:

The OP is in a learning experience, it's what retirement is for.


Huh. I thought it was for doing what you want instead of what other
people tell you that you "have to" do.


That's funny considering government response to Covid-19.

mick
--
Key ID4BFEBB31

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Nicholas Geovanis]

Yes, the Harbour project.
https://harbour.github.io/

On Mon, Jul 27, 2020, 9:57 PM Nicholas Geovanis 
wrote:

> There used to be an open-sourced version of Clipper, wasn't there? That
> was the dBase 3 compiler from a 3rd party. Did that go extinct?
>
> On Mon, Jul 27, 2020, 8:59 PM  wrote:
>
>> Somebody wrote:
>> > But... isn't the tool the least of your problems?  The big one being,
>> > where are you going to get your nutritional database. (Seems to me that
>> > most of what Weight Watchers and Noom do is collect data on millions of
>> > products.)
>>
>> From my records in my free format database (which would not be suitable
>> for
>> your program (at least not in its present condition), some notes on
>> available
>> databases.
>>
>> From "USDA databases" Thu Sep 08 06:57:41 2016
>> Date: 09/08/16 06:57 am
>> Subject: USDA databases
>>
>> There is documentation available to explain how the databases are
>> organized,
>> what they contain, etc.  Several different formats are available (ASCII
>> text,
>> Access, etc.) Statistical information (e.g., standard deviation) is
>> available
>> for some data.
>>
>>* [[http://www.ars.usda.gov/Services/docs.htm?docid=8964][USDA
>> National
>> Nutrient Database for Standard Reference: Release 28]]
>>
>>*
>> [[
>> http://www.ars.usda.gov/sp2UserFiles/Place/80400525/Data/SR/SR28/sr28_doc.pdf
>> ]
>> [Composition of Foods: Raw, Processed, Prepared; USDA National Nutrient
>> Database for Standard Reference, Release 28 (2015); Documentation and
>> User
>> Guide]]
>>
>>* [[
>> https://ndb.nal.usda.gov/ndb/docs/SR_BrandedFoods_May2016.pdf][USDA
>> Branded Food Products Database; Documentation; May 2016]]--an
>> experimental
>> public / private partnership, dissolved in 2015 (iirc) after developing
>> data
>> for 354 products, incorporated as an adjunct (iiuc) to the USDA database
>> SR28
>>
>>* [[https://www.ars.usda.gov/Services/docs.htm?docid=24912][SR27 -
>> Download
>> Files]]
>>
>> And, from some documentation on CRON-O-Meter (which is a program like
>> you're
>> describing, available in an online version and a Linux version:
>>
>> 
>> The foods in our database come from several sources.
>>
>>* NCCDB (Nutrition Coordinating Center Food & Nutrient Database) from
>> the
>> University of Minnesota, contains over 16000 food entries with
>> comprehensive
>> data on 70 nutrients.
>>
>>* USDA (SR28) (United States Department of Agriculture National
>> Nutrient
>> Database for Standard Reference (SR28)) contains over 8000 food entries
>> with
>> data on over 70 nutrients.
>>
>>* ESHA (ESHA Research, Inc.) contains over 35000 brand name products
>> and
>> restaurant menu items. These items don't typically have as full of a
>> nutrient
>> profile as the USDA and NCCDB items, but contain all the published
>> information
>> from the product nutrition labels--I don't know how many nutrients--may
>> vary.
>>
>>*  Nutritionix: barcode scanning database, contains data for over
>> 400,000 food product nutrition labels--I don't know how many
>> nutrients--may
>> vary. Nutritionix API
>>
>>* CNF 2010 (Canadian Nutrient File)
>> This data has a lot of overlap with the USDA data (many entries are
>> derived it), but adds a lot of additional foods, as well as reflecting
>> differences found in Canadian foods. It has french and english names for
>> all
>> items, as well as standard measures in metric units--I don't know how
>> many
>> nutrients--may vary.
>>
>>* IFCDB (Irish Food Composition Database) contains nearly 1000 irish
>> food
>> and supplement products--I don't know how many nutrients--may vary.
>>
>>* CRDB (CRON-O-Meter Community Database) foods submitted by
>> CRON-O-Meter
>> users (they show green in the food search dialog)--I don't know how many
>> nutrients--may vary.
>>
>>* Custom
>> These are your custom foods. These are private and can only be viewed
>> and
>> used by you, or any friends you have linked to for
>> food-sharing--nutrients
>> included may vary based on where I got the data (I mean, like from which
>> of
>> the databases listed below.
>> 
>>
>> One of my points is that data / databases are available.
>>
>> I'm also willing to share with you my file on my experiences with this
>> type of
>> program.  NUT is available for LInux, but it was really freaky -- for
>> example,
>> you had to specify how many meals per day you intended to eat (for this
>> example, assume 6, 3 meals, 3 between meal snacks, and then when you
>> entered
>> the first meal it multiplied all the nutritional values by 6.  I forget
>> what it
>> did as you entered the other meals.
>>
>> CRON-O-Meter was much better, but not really good enough to suit me.
>>
>> I experimented with possibly as many as 10 such programs that I could run
>> without touching Windows.  One of them (I forget which) tracked something
>> like
>> 60 different nutrients, things like micrograms and such of minerals,
>> vitamins,
>> ...
>>
>> If you're really 

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Nicholas Geovanis]

There used to be an open-sourced version of Clipper, wasn't there? That was
the dBase 3 compiler from a 3rd party. Did that go extinct?

On Mon, Jul 27, 2020, 8:59 PM  wrote:

> Somebody wrote:
> > But... isn't the tool the least of your problems?  The big one being,
> > where are you going to get your nutritional database. (Seems to me that
> > most of what Weight Watchers and Noom do is collect data on millions of
> > products.)
>
> From my records in my free format database (which would not be suitable
> for
> your program (at least not in its present condition), some notes on
> available
> databases.
>
> From "USDA databases" Thu Sep 08 06:57:41 2016
> Date: 09/08/16 06:57 am
> Subject: USDA databases
>
> There is documentation available to explain how the databases are
> organized,
> what they contain, etc.  Several different formats are available (ASCII
> text,
> Access, etc.) Statistical information (e.g., standard deviation) is
> available
> for some data.
>
>* [[http://www.ars.usda.gov/Services/docs.htm?docid=8964][USDA
> National
> Nutrient Database for Standard Reference: Release 28]]
>
>*
> [[
> http://www.ars.usda.gov/sp2UserFiles/Place/80400525/Data/SR/SR28/sr28_doc.pdf
> ]
> [Composition of Foods: Raw, Processed, Prepared; USDA National Nutrient
> Database for Standard Reference, Release 28 (2015); Documentation and User
> Guide]]
>
>* [[https://ndb.nal.usda.gov/ndb/docs/SR_BrandedFoods_May2016.pdf][USDA
> Branded Food Products Database; Documentation; May 2016]]--an experimental
> public / private partnership, dissolved in 2015 (iirc) after developing
> data
> for 354 products, incorporated as an adjunct (iiuc) to the USDA database
> SR28
>
>* [[https://www.ars.usda.gov/Services/docs.htm?docid=24912][SR27 -
> Download
> Files]]
>
> And, from some documentation on CRON-O-Meter (which is a program like
> you're
> describing, available in an online version and a Linux version:
>
> 
> The foods in our database come from several sources.
>
>* NCCDB (Nutrition Coordinating Center Food & Nutrient Database) from
> the
> University of Minnesota, contains over 16000 food entries with
> comprehensive
> data on 70 nutrients.
>
>* USDA (SR28) (United States Department of Agriculture National
> Nutrient
> Database for Standard Reference (SR28)) contains over 8000 food entries
> with
> data on over 70 nutrients.
>
>* ESHA (ESHA Research, Inc.) contains over 35000 brand name products
> and
> restaurant menu items. These items don't typically have as full of a
> nutrient
> profile as the USDA and NCCDB items, but contain all the published
> information
> from the product nutrition labels--I don't know how many nutrients--may
> vary.
>
>*  Nutritionix: barcode scanning database, contains data for over
> 400,000 food product nutrition labels--I don't know how many
> nutrients--may
> vary. Nutritionix API
>
>* CNF 2010 (Canadian Nutrient File)
> This data has a lot of overlap with the USDA data (many entries are
> derived it), but adds a lot of additional foods, as well as reflecting
> differences found in Canadian foods. It has french and english names for
> all
> items, as well as standard measures in metric units--I don't know how many
> nutrients--may vary.
>
>* IFCDB (Irish Food Composition Database) contains nearly 1000 irish
> food
> and supplement products--I don't know how many nutrients--may vary.
>
>* CRDB (CRON-O-Meter Community Database) foods submitted by
> CRON-O-Meter
> users (they show green in the food search dialog)--I don't know how many
> nutrients--may vary.
>
>* Custom
> These are your custom foods. These are private and can only be viewed
> and
> used by you, or any friends you have linked to for food-sharing--nutrients
> included may vary based on where I got the data (I mean, like from which
> of
> the databases listed below.
> 
>
> One of my points is that data / databases are available.
>
> I'm also willing to share with you my file on my experiences with this
> type of
> program.  NUT is available for LInux, but it was really freaky -- for
> example,
> you had to specify how many meals per day you intended to eat (for this
> example, assume 6, 3 meals, 3 between meal snacks, and then when you
> entered
> the first meal it multiplied all the nutritional values by 6.  I forget
> what it
> did as you entered the other meals.
>
> CRON-O-Meter was much better, but not really good enough to suit me.
>
> I experimented with possibly as many as 10 such programs that I could run
> without touching Windows.  One of them (I forget which) tracked something
> like
> 60 different nutrients, things like micrograms and such of minerals,
> vitamins,
> ...
>
> If you're really interested, I can make my file with my notes in it
> available
> to you.
>
> You can treat it as a plain text file, or read it as emails in any email
> client
> that can handle mbox files, or, with a special file I can provide, read it
> in
> kate with the   features 

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[rhkramer]

Somebody wrote:
> But... isn't the tool the least of your problems?  The big one being,
> where are you going to get your nutritional database. (Seems to me that
> most of what Weight Watchers and Noom do is collect data on millions of
> products.)

From my records in my free format database (which would not be suitable for 
your program (at least not in its present condition), some notes on available 
databases.

From "USDA databases" Thu Sep 08 06:57:41 2016 
Date: 09/08/16 06:57 am 
Subject: USDA databases

There is documentation available to explain how the databases are organized, 
what they contain, etc.  Several different formats are available (ASCII text, 
Access, etc.) Statistical information (e.g., standard deviation) is available 
for some data.

   * [[http://www.ars.usda.gov/Services/docs.htm?docid=8964][USDA National 
Nutrient Database for Standard Reference: Release 28]]

   * 
[[http://www.ars.usda.gov/sp2UserFiles/Place/80400525/Data/SR/SR28/sr28_doc.pdf]
[Composition of Foods: Raw, Processed, Prepared; USDA National Nutrient 
Database for Standard Reference, Release 28 (2015); Documentation and User 
Guide]]

   * [[https://ndb.nal.usda.gov/ndb/docs/SR_BrandedFoods_May2016.pdf][USDA 
Branded Food Products Database; Documentation; May 2016]]--an experimental 
public / private partnership, dissolved in 2015 (iirc) after developing data 
for 354 products, incorporated as an adjunct (iiuc) to the USDA database SR28

   * [[https://www.ars.usda.gov/Services/docs.htm?docid=24912][SR27 - Download 
Files]]

And, from some documentation on CRON-O-Meter (which is a program like you're 
describing, available in an online version and a Linux version:


The foods in our database come from several sources.

   * NCCDB (Nutrition Coordinating Center Food & Nutrient Database) from the 
University of Minnesota, contains over 16000 food entries with comprehensive 
data on 70 nutrients.

   * USDA (SR28) (United States Department of Agriculture National Nutrient 
Database for Standard Reference (SR28)) contains over 8000 food entries with 
data on over 70 nutrients.

   * ESHA (ESHA Research, Inc.) contains over 35000 brand name products and 
restaurant menu items. These items don't typically have as full of a nutrient 
profile as the USDA and NCCDB items, but contain all the published information 
from the product nutrition labels--I don't know how many nutrients--may vary.

   *  Nutritionix: barcode scanning database, contains data for over 
400,000 food product nutrition labels--I don't know how many nutrients--may 
vary. Nutritionix API

   * CNF 2010 (Canadian Nutrient File)
This data has a lot of overlap with the USDA data (many entries are 
derived it), but adds a lot of additional foods, as well as reflecting 
differences found in Canadian foods. It has french and english names for all 
items, as well as standard measures in metric units--I don't know how many 
nutrients--may vary.

   * IFCDB (Irish Food Composition Database) contains nearly 1000 irish food 
and supplement products--I don't know how many nutrients--may vary.

   * CRDB (CRON-O-Meter Community Database) foods submitted by CRON-O-Meter 
users (they show green in the food search dialog)--I don't know how many 
nutrients--may vary. 

   * Custom
These are your custom foods. These are private and can only be viewed and 
used by you, or any friends you have linked to for food-sharing--nutrients 
included may vary based on where I got the data (I mean, like from which of 
the databases listed below.


One of my points is that data / databases are available.

I'm also willing to share with you my file on my experiences with this type of 
program.  NUT is available for LInux, but it was really freaky -- for example, 
you had to specify how many meals per day you intended to eat (for this 
example, assume 6, 3 meals, 3 between meal snacks, and then when you entered 
the first meal it multiplied all the nutritional values by 6.  I forget what it 
did as you entered the other meals.

CRON-O-Meter was much better, but not really good enough to suit me.

I experimented with possibly as many as 10 such programs that I could run 
without touching Windows.  One of them (I forget which) tracked something like 
60 different nutrients, things like micrograms and such of minerals, vitamins, 
...

If you're really interested, I can make my file with my notes in it available 
to you.

You can treat it as a plain text file, or read it as emails in any email client 
that can handle mbox files, or, with a special file I can provide, read it in 
kate with the   features I intended it to have (syntax highlighting and 
folding).

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[David Wright]

On Mon 27 Jul 2020 at 15:46:08 (-0400), Michael Stone wrote:
> On Mon, Jul 27, 2020 at 11:39:11AM -0400, Greg Wooledge wrote:
> > On Mon, Jul 27, 2020 at 11:16:45AM -0400, Michael Stone wrote:
> > > On Mon, Jul 27, 2020 at 08:09:36AM -0400, Greg Wooledge wrote:
> > > > For a project of this size and scope, a Tcl application with an sqlite3
> > > > database in a local file seems well suited.
> > > 
> > > Only on the internet can someone ask a simple question and get tcl as the
> > > answer. :-/
> > 
> > OK, here's a quick program to show how it might be done.
> 
> The question wasn't "what's your favorite programming language", was it?
> 
> Even then, I'd be hard-pressed to recommend tcl as the thing to learn
> in 2020, but that's beside the point.
> 
> > Do you consider this "difficult"?  If so, you are probably approaching
> > this problem as a non-programmer, in which case I don't know what to
> > tell you.  Programming languages exist for a reason, and Tcl is one of
> > the easiest ones for this particular job.
> 
> Did you read the original question or use dbase back in the day?

I, for one, read the question a previous time that it was posed:
https://lists.debian.org/debian-user/2017/02/msg01024.html
That reference is somewhere mid-thread, and this time I'll quote
it to save your looking it up:

   "A little research indicates that Tcl/Tk plays well with sqlite.
A couple of years ago I started learning it for a now abandoned
project. I'll follow up on that combo. [I looked at some code
fragments on http://wiki.tcl.tk . They were reminiscent of what
I did in dBaseII so may be a productive path.]" — Richard Owlett

Cheers,
David.

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Joe]

On Mon, 27 Jul 2020 17:46:35 -0400
Michael Stone  wrote:

> On Mon, Jul 27, 2020 at 10:34:39PM +0100, Joe wrote:
> >The OP is in a learning experience, it's what retirement is for.  
> 
> Huh. I thought it was for doing what you want instead of what other 
> people tell you that you "have to" do. 
> 

He does.

-- 
Joe

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Joe]

On Mon, 27 Jul 2020 22:22:12 +0200
 wrote:

> On Mon, Jul 27, 2020 at 04:04:16PM -0400, Michael Stone wrote:
> > On Mon, Jul 27, 2020 at 09:52:28PM +0200, to...@tuxteam.de wrote:  
> > >And, in Greg's defense, he provided some code, something no
> > >one of us did -- I'd say this round goes to him ;-)  
> > 
> > How? The OP request was for something simpler than SQL [...]  
> 
> Whatever. I was a bit tongue-in-cheek anyway, illustrated by
> emoticon.
> 
> Far more "interesting" proposals have crossed this thread,
> including a full LAMP stack (witt PHP to learn, a web server
> to administer and a browser to eat all available RAM -- uh
> as a client). You jumped at Tcl, which somehow suggests you
> have some peeve with it. /My/ peeve is "don't do that", so
> I jumped at it, hopefully in a sufficiently humorous way to
> not hurt anyone.
> 
> The OP is old enough to pick and choose.
> 
> Or something. But don't take me too seriously.
> 
>

In a forum like this it *is* appropriate to suggest alternatives that
don't fully answer the question as asked, as it is archived and
available publicly. Not all questions posed, along with their
constraints, have a practical answer, and questions often have
constraints which become irrelevant if an alternative view is taken.

And if not exposed to the Net, a web server doesn't need much
administration. If you want a Net presence, hire it, let someone else
worry about getting hacked.

-- 
Joe

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Michael Stone]

On Mon, Jul 27, 2020 at 10:34:39PM +0100, Joe wrote:

The OP is in a learning experience, it's what retirement is for.


Huh. I thought it was for doing what you want instead of what other 
people tell you that you "have to" do. 

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Joe]

On Mon, 27 Jul 2020 16:04:16 -0400
Michael Stone  wrote:

> On Mon, Jul 27, 2020 at 09:52:28PM +0200, to...@tuxteam.de wrote:
> >And, in Greg's defense, he provided some code, something no
> >one of us did -- I'd say this round goes to him ;-)  
> 
> How? The OP request was for something simpler than SQL (presumably 
> because he didn't want to learn SQL?), so the response "learn SQL 
> anyway, and in addition learn my favorite language as a way to pass 
> the SQL commands to the backend" simply misses the point.
> 

The OP is in a learning experience, it's what retirement is for.

Very basic SQL, no more than a few queries, is an appropriate thing to
learn, along with the (minimal) care and feeding of MySQL/MariaDb. I've
never really gone beyond select, insert, delete and update queries,
resorting to Google to temporarily learn to add users, change
privileges etc. As a hobbyist, I've never needed to go near stored
procedures, transactions etc.

I was once SQLphobic, avoiding the use of applications which required a
MySQL database, looking around for 'simpler' ways to do things, which
invariably required more work. Eventually I was forced into it, and I
currently have more than 20 domestic, business and experimental
databases running in MariaDb. I added another a week ago, and when I
work up the enthusiasm, I'll make a user interface for it. I have at
least one database whose only user interface is PhpMyAdmin...

-- 
Joe

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[tomas]

On Mon, Jul 27, 2020 at 04:04:16PM -0400, Michael Stone wrote:
> On Mon, Jul 27, 2020 at 09:52:28PM +0200, to...@tuxteam.de wrote:
> >And, in Greg's defense, he provided some code, something no
> >one of us did -- I'd say this round goes to him ;-)
> 
> How? The OP request was for something simpler than SQL [...]

Whatever. I was a bit tongue-in-cheek anyway, illustrated by
emoticon.

Far more "interesting" proposals have crossed this thread,
including a full LAMP stack (witt PHP to learn, a web server
to administer and a browser to eat all available RAM -- uh
as a client). You jumped at Tcl, which somehow suggests you
have some peeve with it. /My/ peeve is "don't do that", so
I jumped at it, hopefully in a sufficiently humorous way to
not hurt anyone.

The OP is old enough to pick and choose.

Or something. But don't take me too seriously.

Cheers
-- t


signature.asc
Description: Digital signature

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Greg Wooledge]

On Mon, Jul 27, 2020 at 04:04:16PM -0400, Michael Stone wrote:
> On Mon, Jul 27, 2020 at 09:52:28PM +0200, to...@tuxteam.de wrote:
> > And, in Greg's defense, he provided some code, something no
> > one of us did -- I'd say this round goes to him ;-)
> 
> How? The OP request was for something simpler than SQL (presumably because
> he didn't want to learn SQL?), so the response "learn SQL anyway, and in
> addition learn my favorite language as a way to pass the SQL commands to the
> backend" simply misses the point.

It's a language the OP has already stated they're learning (in a past
thread -- we understand if you do not have this context).  In addition,
learning SQL is the right long term solution.

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Michael Stone]

On Mon, Jul 27, 2020 at 09:52:28PM +0200, to...@tuxteam.de wrote:

And, in Greg's defense, he provided some code, something no
one of us did -- I'd say this round goes to him ;-)


How? The OP request was for something simpler than SQL (presumably 
because he didn't want to learn SQL?), so the response "learn SQL 
anyway, and in addition learn my favorite language as a way to pass 
the SQL commands to the backend" simply misses the point.

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[tomas]

On Mon, Jul 27, 2020 at 03:46:08PM -0400, Michael Stone wrote:
> On Mon, Jul 27, 2020 at 11:39:11AM -0400, Greg Wooledge wrote:

[...]

> >OK, here's a quick program to show how it might be done.
> 
> The question wasn't "what's your favorite programming language", was it?

To be fair, the question wasn't what your favourite programming
language is *not* ;-P

And, in Greg's defense, he provided some code, something no
one of us did -- I'd say this round goes to him ;-)

Cheers
-- t


signature.asc
Description: Digital signature

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Michael Stone]

On Mon, Jul 27, 2020 at 11:39:11AM -0400, Greg Wooledge wrote:

On Mon, Jul 27, 2020 at 11:16:45AM -0400, Michael Stone wrote:

On Mon, Jul 27, 2020 at 08:09:36AM -0400, Greg Wooledge wrote:
> For a project of this size and scope, a Tcl application with an sqlite3
> database in a local file seems well suited.

Only on the internet can someone ask a simple question and get tcl as the
answer. :-/


OK, here's a quick program to show how it might be done.


The question wasn't "what's your favorite programming language", was it?

Even then, I'd be hard-pressed to recommend tcl as the thing to learn in 
2020, but that's beside the point.



Do you consider this "difficult"?  If so, you are probably approaching
this problem as a non-programmer, in which case I don't know what to
tell you.  Programming languages exist for a reason, and Tcl is one of
the easiest ones for this particular job.


Did you read the original question or use dbase back in the day? 

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Miles Fidelman]

On 7/27/20 11:16 AM, Michael Stone wrote:


On Mon, Jul 27, 2020 at 08:09:36AM -0400, Greg Wooledge wrote:

For a project of this size and scope, a Tcl application with an sqlite3
database in a local file seems well suited.


Only on the internet can someone ask a simple question and get tcl as 
the answer. :-/


Well...

1. Where else would you ask the question, if not "the internet?"

2. tcl is still pretty cool - some great things are written in it, like 
fossil-scm (the DCVS used for sqlite, built on sqlite, in tcl, by the 
author of sqlite)


Seems like a great idea.




--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[tomas]

On Mon, Jul 27, 2020 at 11:16:45AM -0400, Michael Stone wrote:
> On Mon, Jul 27, 2020 at 08:09:36AM -0400, Greg Wooledge wrote:
> >For a project of this size and scope, a Tcl application with an sqlite3
> >database in a local file seems well suited.
> 
> Only on the internet can someone ask a simple question and get tcl
> as the answer. :-/

For quick one-off GUI scripts it's still hard to beat, though.

Cheers
-- t


signature.asc
Description: Digital signature

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[David Wright]

On Mon 27 Jul 2020 at 11:16:45 (-0400), Michael Stone wrote:
> On Mon, Jul 27, 2020 at 08:09:36AM -0400, Greg Wooledge wrote:
> > For a project of this size and scope, a Tcl application with an sqlite3
> > database in a local file seems well suited.
> 
> Only on the internet can someone ask a simple question and get tcl as
> the answer. :-/

It should suit the OP. For example,

https://lists.debian.org/debian-user/2018/07/msg00756.html

Cheers,
David.

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Greg Wooledge]

On Mon, Jul 27, 2020 at 11:16:45AM -0400, Michael Stone wrote:
> On Mon, Jul 27, 2020 at 08:09:36AM -0400, Greg Wooledge wrote:
> > For a project of this size and scope, a Tcl application with an sqlite3
> > database in a local file seems well suited.
> 
> Only on the internet can someone ask a simple question and get tcl as the
> answer. :-/

OK, here's a quick program to show how it might be done.  The interface
is quite primitive, but it's a proof of concept.

You need to install the libsqlite3-tcl package, if you're using Debian's
version of Tcl.  If you compile Tcl from upstream source, this package
is included by default.

Here's the program:

=
#!/usr/bin/tclsh8.6
package require sqlite3
set dbfile ./food.db

proc usage {} {
global argv0
puts stderr "usage: $argv0 {add|print|dump} arguments"
exit 1
}

if {[file exists $dbfile]} {
sqlite3 db $dbfile
} else {
sqlite3 db $dbfile
db eval {create table food (name text, calories real)}
}

lassign $argv cmd food cals
switch -- $cmd {
add {
if {[llength $argv] != 3} {usage}
db eval {insert into food(name, calories) values (:food, :cals)}
}
print {
if {[llength $argv] != 2} {usage}
db eval {select calories from food where name = :food} v {}
if {! [info exists v(calories)]} {
puts stderr "Food '$food' not found"
exit 1
}
puts $v(calories)
}
dump {
db eval {select name, calories from food order by name} v {
puts [format "%-30.30s %f" $v(name) $v(calories)]
}
}
default {usage}
}
=

And running it:

unicorn:~$ ./foo
usage: ./foo {add|print|dump} arguments
unicorn:~$ ./foo add pretzels 50
unicorn:~$ ./foo add corn 30
unicorn:~$ ./foo print corn
30.0
unicorn:~$ ./foo print 'potato chips'
Food 'potato chips' not found
unicorn:~$ ./foo dump
corn   30.00
pretzels   50.00
unicorn:~$ ls -l food.db
-rw-r--r-- 1 greg greg 8192 Jul 27 11:31 food.db
unicorn:~$ ./foo add corn 35
unicorn:~$ ./foo dump
corn   30.00
corn   35.00
pretzels   50.00

Oops.  Looks like we should consider making the name a unique index.
Well, you can add that to your version.

Do you consider this "difficult"?  If so, you are probably approaching
this problem as a non-programmer, in which case I don't know what to
tell you.  Programming languages exist for a reason, and Tcl is one of
the easiest ones for this particular job.

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Michael Stone]

On Mon, Jul 27, 2020 at 08:09:36AM -0400, Greg Wooledge wrote:

For a project of this size and scope, a Tcl application with an sqlite3
database in a local file seems well suited.


Only on the internet can someone ask a simple question and get tcl as 
the answer. :-/

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Eric S Fraga]

You may wish to have a look at recutils:

https://www.gnu.org/software/recutils/

but it may not have some of the functionality you wish (although you
could build on it with shell scripts & awk, say).
-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.7 on Debian bullseye/sid

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Ajith R]

Hi,

If you decide against a command line system and  decide to go SQL / Klexi way, 
I want to suggest to you a relatively lesser known integrated database system - 
http://www.suneido.com. It has been around for nearly 20 years. It is pretty 
easy to design and stable. It is FOSS. The only problem is that it is available 
only for the Windows platform.
If you still want to go the command line way, have a look at 
https://www.gnu.org/software/recutils/. From the description at the site, 
" GNU Recutils is a set of tools and libraries to access human-editable, plain 
text databases called recfiles. The data is stored as a sequence of records, 
each record containing an arbitrary number of named fields. The picture below 
shows a sample database containing information about GNU packages, along with 
the main features provided by recutils.",it looks like it is the program you 
have been looking for. (Disclaimer: I know nothing about the program.)

All the best,
ajith





On Saturday, 25 July, 2020, 11:08:42 pm IST, Richard Owlett 
 wrote: 





Back in 70's/80's I wrote programs as part of routine job duties.
  {8080/8085 assembler, dBase and Paradox}
Neither I, nor my employers, classed me as a "programmer".
I was "Senior Engineering Tech" or "Junior Engineer".
IOW, I was not in abject *AWE* of computers. *ROFL*

Right now I'm working on a personal project.
INPUT:    How much of what did I eat?
OUTPUT:    How much [cal/protein/fiber] did I eat?

SQL {and variants} seen to dominate all else.
IIRC, dBase was simpler.

What current FOSS system might I be comfortable with?

TIA

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Greg Wooledge]

On Sat, Jul 25, 2020 at 02:45:58PM -0400, Paul M Foster wrote:
> Since you probably would like an application with a nice interface
> (curses, GUI, web), I'd suggest PHP. The platform for your interface is
> in the server and the browser; you just have to write some HTML, which
> is pretty easy. Otherwise, you're looking at fiddly code with GTK or QT
> (or ncurses).

PHP is a terrible language, and I wouldn't recommend it as a starting
point for anything but failure.  Also, I wouldn't assume that the OP
wants a web interface.  If anything, he probably wants a command line
tool that only runs on localhost.  (And then he'll tack on new insane
restrictions later.  "Of course I wanted it to run on a 20x2 LCD!
And it has to fit on a 5.25" floppy!  You should have known that!!")

Crazy undocumented criteria aside, Tcl, Perl and Python would all suit
this project extremely well, I think.  The OP should choose whichever
of those 3 he likes best, and learn how to talk to a database with it.
If a pure command line interface is desired, then there's not much else he
needs to know.  If a GUI interface is desired, all 3 of those languages
have Tk bindings.

For a project of this size and scope, a Tcl application with an sqlite3
database in a local file seems well suited.

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[David Christensen]

On 2020-07-26 03:06, mick crane wrote:


On Sat, 25 Jul 2020 14:55:35 -0700 David Christensen wrote:



It's been a while, but Linux-Apache-MySQL-Perl worked for me back in
the day:


I'm not very good at this and wondered how to do it and thought could 
have things in a hash of hashes. As you tend to stick with a limited 
variety of recipes wouldn't be that extensive for personal use. After 
sorting out input.


my %food=(
"ham sandwich"=>{
cal=> .4,
protein=>.2,
fiber=>.3,
},
"cauliflower cheese"=>{
cal=> .8,
protein=>.3,
fiber=>.1,
},
);
my $calories= $food{$ARGV[0]}{cal}*$ARGV[1];

and add it to a weekly and daily totals file.



Perl data structures and algorithms can work when needs are few, simple, 
and fixed.  The UI is command-line options and arguments to the Perl 
script.  Data is stored in CSV or TSV files, and accessed with a 
library.  Reports are generated with a PDF library.  The key is that 
everything must fit into memory at once.



As complexity, change, and/or size increase, a database management 
system and SQL become necessary.



David

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Michael Stone]

On Sun, Jul 26, 2020 at 06:58:06PM +0100, Joe wrote:

On Sun, 26 Jul 2020 10:24:25 -0400
Michael Stone  wrote:


On Sat, Jul 25, 2020 at 12:38:10PM -0500, Richard Owlett wrote:
>Back in 70's/80's I wrote programs as part of routine job duties.
>  {8080/8085 assembler, dBase and Paradox}
>Neither I, nor my employers, classed me as a "programmer".
>I was "Senior Engineering Tech" or "Junior Engineer".
>IOW, I was not in abject *AWE* of computers. *ROFL*
>
>Right now I'm working on a personal project.
>INPUT:  How much of what did I eat?
>OUTPUT: How much [cal/protein/fiber] did I eat?
>
>SQL {and variants} seen to dominate all else.
>IIRC, dBase was simpler.
>
>What current FOSS system might I be comfortable with?

Take a look at kexi



Yes, that might be the way for the OP. I looked at it some years ago,
I've just installed it and looked again, and it *still* cannot connect
to an existing SQL database. It can use an SQL server, but only to make
its own databases. It can import data. But it can't share an existing
database with other types of client.


As I understood the OPs requirements, that's irrelevant. They're 
probably best off with sqlite hiding in the backend of a forms-based DB 
frontend.

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Joe]

On Sun, 26 Jul 2020 10:24:25 -0400
Michael Stone  wrote:

> On Sat, Jul 25, 2020 at 12:38:10PM -0500, Richard Owlett wrote:
> >Back in 70's/80's I wrote programs as part of routine job duties.
> >  {8080/8085 assembler, dBase and Paradox}
> >Neither I, nor my employers, classed me as a "programmer".
> >I was "Senior Engineering Tech" or "Junior Engineer".
> >IOW, I was not in abject *AWE* of computers. *ROFL*
> >
> >Right now I'm working on a personal project.
> >INPUT:   How much of what did I eat?
> >OUTPUT:  How much [cal/protein/fiber] did I eat?
> >
> >SQL {and variants} seen to dominate all else.
> >IIRC, dBase was simpler.
> >
> >What current FOSS system might I be comfortable with?  
> 
> Take a look at kexi
> 

Yes, that might be the way for the OP. I looked at it some years ago,
I've just installed it and looked again, and it *still* cannot connect
to an existing SQL database. It can use an SQL server, but only to make
its own databases. It can import data. But it can't share an existing
database with other types of client.

It bills itself as an equal to Access, and for all I know it might be
such when working with its own private databases. But Access could
operate as a front end to various external databases when it was
Access2 under Windows 3.1, when I first encountered it.

-- 
Joe

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[tomas]

On Sun, Jul 26, 2020 at 10:24:25AM -0400, Michael Stone wrote:
> On Sat, Jul 25, 2020 at 12:38:10PM -0500, Richard Owlett wrote:
> >Back in 70's/80's I wrote programs as part of routine job duties.
> > {8080/8085 assembler, dBase and Paradox}
> >Neither I, nor my employers, classed me as a "programmer".
> >I was "Senior Engineering Tech" or "Junior Engineer".
> >IOW, I was not in abject *AWE* of computers. *ROFL*
> >
> >Right now I'm working on a personal project.
> >INPUT:   How much of what did I eat?
> >OUTPUT:  How much [cal/protein/fiber] did I eat?
> >
> >SQL {and variants} seen to dominate all else.
> >IIRC, dBase was simpler.
> >
> >What current FOSS system might I be comfortable with?
> 
> Take a look at kexi

Yes, I mentioned that already, although I can't vouch for it because
it's not the class of application I delve in.

I'm sure there are a few apps covering that.

Cheers
-- t


signature.asc
Description: Digital signature

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Michael Stone]

On Sat, Jul 25, 2020 at 12:38:10PM -0500, Richard Owlett wrote:

Back in 70's/80's I wrote programs as part of routine job duties.
 {8080/8085 assembler, dBase and Paradox}
Neither I, nor my employers, classed me as a "programmer".
I was "Senior Engineering Tech" or "Junior Engineer".
IOW, I was not in abject *AWE* of computers. *ROFL*

Right now I'm working on a personal project.
INPUT:  How much of what did I eat?
OUTPUT: How much [cal/protein/fiber] did I eat?

SQL {and variants} seen to dominate all else.
IIRC, dBase was simpler.

What current FOSS system might I be comfortable with?


Take a look at kexi

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Joe]

On Sun, 26 Jul 2020 11:06:51 +0100
mick crane  wrote:

> On 2020-07-26 08:54, Joe wrote:
> > On Sat, 25 Jul 2020 14:55:35 -0700
> > David Christensen  wrote:
> >   
> >> 
> >> 
> >> It's been a while, but Linux-Apache-MySQL-Perl worked for me back
> >> in the day:
> >> 
> >> https://en.wikipedia.org/wiki/Lamp_stack  
> > 
> > I have a couple of early web applications written in Perl, but then
> > I found PHP. There's still no SQL user interface RAD tool like
> > Access, which uses SQL internally and externally, and has a lot of
> > database design knowledge built into it.  
> 
> I'm not very good at this and wondered how to do it and thought could 
> have things in a hash of hashes. As you tend to stick with a limited 
> variety of recipes wouldn't be that extensive for personal use. After 
> sorting out input.

I have something over 300 foods in my database, and I'm storing a dozen
parameters for each. I also don't want to calculate these parameters
for each entry in the journal, just enter the name and weight, that's
what joining two tables is for.
> 
> my %food=(
> "ham sandwich"=>{
> cal=> .4,
> protein=>.2,
> fiber=>.3,  
> },
> "cauliflower cheese"=>{
> cal=> .8,
> protein=>.3,
> fiber=>.1,  
> },
> );
> my $calories= $food{$ARGV[0]}{cal}*$ARGV[1];
> 
> and add it to a weekly and daily totals file.
> 

Yes, though I had the impression the OP was looking for a suitable
database to do the job, rather than writing from scratch. I have run
web and SQL servers at home for twenty years, doing it the way I did
was the obvious route.

-- 
Joe

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[mick crane]

On 2020-07-26 08:54, Joe wrote:

On Sat, 25 Jul 2020 14:55:35 -0700
David Christensen  wrote:




It's been a while, but Linux-Apache-MySQL-Perl worked for me back in
the day:

https://en.wikipedia.org/wiki/Lamp_stack


I have a couple of early web applications written in Perl, but then I
found PHP. There's still no SQL user interface RAD tool like Access,
which uses SQL internally and externally, and has a lot of database
design knowledge built into it.


I'm not very good at this and wondered how to do it and thought could 
have things in a hash of hashes. As you tend to stick with a limited 
variety of recipes wouldn't be that extensive for personal use. After 
sorting out input.


my %food=(
"ham sandwich"=>{
cal=> .4,
protein=>.2,
fiber=>.3,
},
"cauliflower cheese"=>{
cal=> .8,
protein=>.3,
fiber=>.1,
},
);
my $calories= $food{$ARGV[0]}{cal}*$ARGV[1];

and add it to a weekly and daily totals file.

mick
--
Key ID4BFEBB31

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Joe]

On Sat, 25 Jul 2020 14:55:35 -0700
David Christensen  wrote:

> 
> 
> It's been a while, but Linux-Apache-MySQL-Perl worked for me back in
> the day:
> 
> https://en.wikipedia.org/wiki/Lamp_stack

I have a couple of early web applications written in Perl, but then I
found PHP. There's still no SQL user interface RAD tool like Access,
which uses SQL internally and externally, and has a lot of database
design knowledge built into it.

-- 
Joe

Re: Fwd: Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Rh Kramer]

I suspect the threading on this will be broken -- I forwarded it to another 
computer where I have my notes on my adventures with "nutrition" programs.

On Saturday, July 25, 2020 6:40:47 PM you wrote:
> --  Forwarded Message  --
> 
> Subject: Re: FOSS equivalents of *OLD* database and spreadsheet tools?
> Date: Saturday, July 25, 2020, 03:27:06 PM
> From: Miles Fidelman 
> To: debian-user@lists.debian.org

> But... isn't the tool the least of your problems?  The big one being,
> where are you going to get your nutritional database. (Seems to me that
> most of what Weight Watchers and Noom do is collect data on millions of
> products.)

>From my records in my free format database (which would not be suitable for 
your program (at least not in its present condition), some notes on available 
databases.

>From "USDA databases" Thu Sep 08 06:57:41 2016 
Date: 09/08/16 06:57 am 
Subject: USDA databases

There is documentation available to explain how the databases are organized, 
what they contain, etc.  Several different formats are available (ASCII text, 
Access, etc.) Statistical information (e.g., standard deviation) is available 
for some data.

   * [[http://www.ars.usda.gov/Services/docs.htm?docid=8964][USDA National 
Nutrient Database for Standard Reference: Release 28]]

   * 
[[http://www.ars.usda.gov/sp2UserFiles/Place/80400525/Data/SR/SR28/sr28_doc.pdf]
[Composition of Foods: Raw, Processed, Prepared; USDA National Nutrient 
Database for Standard Reference, Release 28 (2015); Documentation and User 
Guide]]

   * [[https://ndb.nal.usda.gov/ndb/docs/SR_BrandedFoods_May2016.pdf][USDA 
Branded Food Products Database; Documentation; May 2016]]--an experimental 
public / private partnership, dissolved in 2015 (iirc) after developing data 
for 354 products, incorporated as an adjunct (iiuc) to the USDA database SR28

   * [[https://www.ars.usda.gov/Services/docs.htm?docid=24912][SR27 - Download 
Files]]

And, from some documentation on CRON-O-Meter (which is a program like you're 
describing, available in an online version and a Linux version:


The foods in our database come from several sources.

   * NCCDB (Nutrition Coordinating Center Food & Nutrient Database) from the 
University of Minnesota, contains over 16000 food entries with comprehensive 
data on 70 nutrients.

   * USDA (SR28) (United States Department of Agriculture National Nutrient 
Database for Standard Reference (SR28)) contains over 8000 food entries with 
data on over 70 nutrients.

   * ESHA (ESHA Research, Inc.) contains over 35000 brand name products and 
restaurant menu items. These items don't typically have as full of a nutrient 
profile as the USDA and NCCDB items, but contain all the published information 
from the product nutrition labels--I don't know how many nutrients--may vary.

   *  Nutritionix: barcode scanning database, contains data for over 
400,000 food product nutrition labels--I don't know how many nutrients--may 
vary. Nutritionix API

   * CNF 2010 (Canadian Nutrient File)
This data has a lot of overlap with the USDA data (many entries are 
derived it), but adds a lot of additional foods, as well as reflecting 
differences found in Canadian foods. It has french and english names for all 
items, as well as standard measures in metric units--I don't know how many 
nutrients--may vary.

   * IFCDB (Irish Food Composition Database) contains nearly 1000 irish food 
and supplement products--I don't know how many nutrients--may vary.

   * CRDB (CRON-O-Meter Community Database) foods submitted by CRON-O-Meter 
users (they show green in the food search dialog)--I don't know how many 
nutrients--may vary. 

   * Custom
These are your custom foods. These are private and can only be viewed and 
used by you, or any friends you have linked to for food-sharing--nutrients 
included may vary based on where I got the data (I mean, like from which of 
the databases listed below.


One of my points is that data / databases are available.

I'm also willing to share with you my file on my experiences with this type of 
program.  NUT is available for LInux, but it was really freaky -- for example, 
you had to specify how many meals per day you intended to eat (for this 
example, assume 6, 3 meals, 3 between meal snacks, and then when you entered 
the first meal it multiplied all the nutritional values by 6.  I forget what it 
did as you entered the other meals.

CRON-O-Meter was much better, but not really good enough to suit me.

I experimented with possibly as many as 10 such programs that I could run 
without touching Windows.  One of them (I forget which) tracked something like 
60 different nutrients, things like micrograms and such of minerals, vitamins, 
...

If you're really interested, I can make my file with my notes in it available 
to you.

You can treat it as a plain text file, or read it as emails in any email clien

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[David Christensen]

On 2020-07-25 13:22, Joe wrote:

Shame about that. If you didn't need FOSS I'd recommend Microsoft
Access, by far the best piece of software they ever produced (not that
it's a high bar). It combines a simple database server, OK for one user,
with a visual RAD system to make the user interface. Beyond doubt, it's
the quickest way to do what you want, and you can probably do most of
what you need with no code at all, just editing properties of objects.
But you have to walk the Dark Path, and pay money.


+1


Using VBA to pull data from Access and feed it into other Office 
applications is very compelling-- Excel graphs, Word form letters, etc..




There will never be a FOSS Access, because the FOSS database people
sneer at it. A damn cheek, given the appalling state of LibreOffice
Base. I've tried to use that, but it's impossibly buggy. OK for editing
tables, now that it is finally able to talk to remote database servers
reliably and without ODBC, but disastrous for making user interfaces.
The last time I used the Report Writer (literally the last time ever) it
simply wasn't working at all


Ouch.  was wondering about that when I posted the link to LibreOffice 
Base (which I have not tried for a very long time)...



It's been a while, but Linux-Apache-MySQL-Perl worked for me back in the 
day:


https://en.wikipedia.org/wiki/Lamp_stack


David

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[rhkramer]

On Saturday, July 25, 2020 01:38:10 PM Richard Owlett wrote:
> Back in 70's/80's I wrote programs as part of routine job duties.
>{8080/8085 assembler, dBase and Paradox}
> Neither I, nor my employers, classed me as a "programmer".
> I was "Senior Engineering Tech" or "Junior Engineer".
> IOW, I was not in abject *AWE* of computers. *ROFL*
> 
> Right now I'm working on a personal project.
> INPUT:How much of what did I eat?
> OUTPUT:   How much [cal/protein/fiber] did I eat?

There is a FOSS (I believe -- I'm pretty sure the source is available) program 
that does that -- can't recall the name -- will check my notes this evening.

It is a little less slick than some of the commercial programs, but it does 
import a database with the nutritional values of quite a few foods (it's from 
a federal agency, like the FDA or something).  It would be nice if more people 
worked on it and brought it up to date.  (For one thing, it uses an older 
version of that database -- it should be set up so that it can easily link to 
any new database that comes along._
 
> SQL {and variants} seen to dominate all else.
> IIRC, dBase was simpler.
> 
> What current FOSS system might I be comfortable with?

Well Libre / Open Office has a database that might be somewhat similar to 
Microsoft Access (and thus Paradox and dBase).

I have been working towards my own free format database (ala askSam) for a 
number of years (I don't want to say how many), but it does work for me.  

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[David Christensen]

On 2020-07-25 10:38, Richard Owlett wrote:

Back in 70's/80's I wrote programs as part of routine job duties.
   {8080/8085 assembler, dBase and Paradox}
Neither I, nor my employers, classed me as a "programmer".
I was "Senior Engineering Tech" or "Junior Engineer".
IOW, I was not in abject *AWE* of computers. *ROFL*

Right now I'm working on a personal project.
INPUT:    How much of what did I eat?
OUTPUT:    How much [cal/protein/fiber] did I eat?

SQL {and variants} seen to dominate all else.
IIRC, dBase was simpler.

What current FOSS system might I be comfortable with?


https://en.wikipedia.org/wiki/LibreOffice_Base


David

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Joe]

On Sat, 25 Jul 2020 12:38:10 -0500
Richard Owlett  wrote:

> Back in 70's/80's I wrote programs as part of routine job duties.
>{8080/8085 assembler, dBase and Paradox}
> Neither I, nor my employers, classed me as a "programmer".
> I was "Senior Engineering Tech" or "Junior Engineer".
> IOW, I was not in abject *AWE* of computers. *ROFL*
> 
> Right now I'm working on a personal project.
> INPUT:How much of what did I eat?
> OUTPUT:   How much [cal/protein/fiber] did I eat?
> 
> SQL {and variants} seen to dominate all else.
> IIRC, dBase was simpler.

I think you will want SQL for this job. You will need a query with a
join of two tables. Spreadsheets really can't do that on a large scale.
I have no doubt that there are other ways (e.g. the hard way, by
programming the join code from scratch) but SQL makes that part fairly
easy. Flat-file databases are OK for trivial card-file applications,
but as soon as you want joins, you need to go relational and that
pretty much means SQL. I must admit, that after many years of dabbling,
I can still barely speak basic SQL, but that's all most simple jobs
need.
> 
> What current FOSS system might I be comfortable with?

Shame about that. If you didn't need FOSS I'd recommend Microsoft
Access, by far the best piece of software they ever produced (not that
it's a high bar). It combines a simple database server, OK for one user,
with a visual RAD system to make the user interface. Beyond doubt, it's
the quickest way to do what you want, and you can probably do most of
what you need with no code at all, just editing properties of objects.
But you have to walk the Dark Path, and pay money.

There will never be a FOSS Access, because the FOSS database people
sneer at it. A damn cheek, given the appalling state of LibreOffice
Base. I've tried to use that, but it's impossibly buggy. OK for editing
tables, now that it is finally able to talk to remote database servers
reliably and without ODBC, but disastrous for making user interfaces.
The last time I used the Report Writer (literally the last time ever) it
simply wasn't working at all, and I needed to produce an invoice
urgently. I ended up writing a PDF generator in PHP, single-purpose
certainly, just for my invoices, but it's guaranteed to work. No
software rot until PHP8...

The hard part of any database job is the user interface, an SQL database
server like MariaDb Just Works, as does SQLite. I've tried a variety of
methodologies, including CakePHP and Laravel (also a PHP framework). I
was hoping that a framework would reduce the amount of work, which they
do in some ways, but they introduce a huge amount of extra baggage. OK
if you're building something with dozens of forms and tables, or if
you're doing this every day professionally, but it doesn't help much
with simple hobby jobs. PhpMyEdit is good for really simple jobs, but it
doesn't scale well. 

I have a server, so I naturally build web applications, which are
automatically cross-platform. But I think even with a single modestly
powered computer, it's as easy to do it that way as to build interfaces
with graphics toolkits. HTML is adequate for most jobs, though *still*
missing a couple of obvious user interface features. I consider the use
of JavaScript to be an admission of defeat, but sometimes there's no
way around it. But my little netbook runs Apache2 with PHP7 and
MariaDb quite happily, for when I need to do some work away from home,
and it's trivial to copy SQL databases between servers. My first server
had 256MB of RAM, and Apache2/PHP5 and MySQL worked OK on that.

Here's how I did what you want to do: I have two main tables, the
journal and the food data. I have a third table of food categories,
which is only used as an input aid, as I currently have over 300 types
of food, which would not work well in a single drop-down list. I have a
fourth table of users, in case the application ever gets used by more
than one person.

I have three main web pages: the primary one is to make journal entries,
and show cumulative figures for single days or date ranges. it can also
edit existing entries. The next most important is for adding new foods,
which again allows editing of existing foods. There are various
databases on the Net giving nutritional values for thousands of food
types, and of course there's the side of the packet for packaged foods.
These two pages I made by hand, with a mix of PHP and HTML. The third
is a week-based statistics page, which I made with Laravel, but which
again had some hand-written PHP and HTML.

It has a few rough edges, as the programs you write for yourself never
get properly finished. I've done the 20%, I'm not willing to do the
other 80% to polish it. But it works.

Another pathway to user interfaces is either Visual Basic or Delphi, in
the FOSS form of Gambas and Lazarus. Good for making forms, but the
integration of databases is nowhere near as complete as with Access.
But it may suit you.

-- 
Joe

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[David Wright]

On Sat 25 Jul 2020 at 14:45:58 (-0400), Paul M Foster wrote:
> On Sat, Jul 25, 2020 at 12:38:10PM -0500, Richard Owlett wrote:
> 
> > Back in 70's/80's I wrote programs as part of routine job duties.
> >   {8080/8085 assembler, dBase and Paradox}
> > Neither I, nor my employers, classed me as a "programmer".
> > I was "Senior Engineering Tech" or "Junior Engineer".
> > IOW, I was not in abject *AWE* of computers. *ROFL*
> > 
> > Right now I'm working on a personal project.
> > INPUT:  How much of what did I eat?
> > OUTPUT: How much [cal/protein/fiber] did I eat?
> > 
> > SQL {and variants} seen to dominate all else.
> > IIRC, dBase was simpler.
> > 
> > What current FOSS system might I be comfortable with?
> > 
> I used dBase (FoxPro) and Paradox decades ago. My advice: learn SQL and
> select the DBMS of your choice. SQLite3, PostgreSQL, MySQL. For
> portability and low traffic, I'd select SQLite3.

I think I indirectly made that suggestion in this thread
https://lists.debian.org/debian-user/2018/07/msg00057.html
which referred back to the OP's own thread
https://lists.debian.org/debian-user/2018/06/msg00757.html

> Gone are the days of xBase and the like. SQL is the lingua franca for
> all modern database systems. And SQLite3 has bindings for most modern
> languages.
> 
> Since you probably would like an application with a nice interface

One can never be sure: the OP seems pretty fearless when it comes to CLIs.

> (curses, GUI, web), I'd suggest PHP. The platform for your interface is
> in the server and the browser; you just have to write some HTML, which
> is pretty easy. Otherwise, you're looking at fiddly code with GTK or QT
> (or ncurses).

Cheers,
David.

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Miles Fidelman]

On Sat, Jul 25, 2020 at 12:38:10PM -0500, Richard Owlett wrote:

Back in 70's/80's I wrote programs as part of routine job duties.
   {8080/8085 assembler, dBase and Paradox}
Neither I, nor my employers, classed me as a "programmer".
I was "Senior Engineering Tech" or "Junior Engineer".
IOW, I was not in abject *AWE* of computers. *ROFL*

Right now I'm working on a personal project.
INPUT:  How much of what did I eat?
OUTPUT: How much [cal/protein/fiber] did I eat?

SQL {and variants} seen to dominate all else.
IIRC, dBase was simpler.

What current FOSS system might I be comfortable with?


You might try googling "open source alternatives to dbase" - there seems 
to be quite a list.  Or you could go with a NoSQL database like CouchDB.


But... isn't the tool the least of your problems?  The big one being, 
where are you going to get your nutritional database. (Seems to me that 
most of what Weight Watchers and Noom do is collect data on millions of 
products.)


Good Eating,

Miles Fidelman

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[tomas]

On Sat, Jul 25, 2020 at 12:38:10PM -0500, Richard Owlett wrote:
> Back in 70's/80's I wrote programs as part of routine job duties.
>   {8080/8085 assembler, dBase and Paradox}
> Neither I, nor my employers, classed me as a "programmer".
> I was "Senior Engineering Tech" or "Junior Engineer".
> IOW, I was not in abject *AWE* of computers. *ROFL*
> 
> Right now I'm working on a personal project.
> INPUT:How much of what did I eat?
> OUTPUT:   How much [cal/protein/fiber] did I eat?
> 
> SQL {and variants} seen to dominate all else.
> IIRC, dBase was simpler.
> 
> What current FOSS system might I be comfortable with?

There are a couple of packages which might fit your
loose description (Disclaimer: I never tried any of
those). Perhaps kexi. Browse through the output of

  aptitude search '~sdatabase'

... there might be some nuggets in there.

Good luck
-- t


signature.asc
Description: Digital signature

Re: FOSS equivalents of *OLD* database and spreadsheet tools?

[Paul M Foster]

On Sat, Jul 25, 2020 at 12:38:10PM -0500, Richard Owlett wrote:

> Back in 70's/80's I wrote programs as part of routine job duties.
>   {8080/8085 assembler, dBase and Paradox}
> Neither I, nor my employers, classed me as a "programmer".
> I was "Senior Engineering Tech" or "Junior Engineer".
> IOW, I was not in abject *AWE* of computers. *ROFL*
> 
> Right now I'm working on a personal project.
> INPUT:How much of what did I eat?
> OUTPUT:   How much [cal/protein/fiber] did I eat?
> 
> SQL {and variants} seen to dominate all else.
> IIRC, dBase was simpler.
> 
> What current FOSS system might I be comfortable with?
> 

I used dBase (FoxPro) and Paradox decades ago. My advice: learn SQL and
select the DBMS of your choice. SQLite3, PostgreSQL, MySQL. For
portability and low traffic, I'd select SQLite3.

Gone are the days of xBase and the like. SQL is the lingua franca for
all modern database systems. And SQLite3 has bindings for most modern
languages.

Since you probably would like an application with a nice interface
(curses, GUI, web), I'd suggest PHP. The platform for your interface is
in the server and the browser; you just have to write some HTML, which
is pretty easy. Otherwise, you're looking at fiddly code with GTK or QT
(or ncurses).

Paul

-- 
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com

FOSS equivalents of *OLD* database and spreadsheet tools?

[Richard Owlett]

Back in 70's/80's I wrote programs as part of routine job duties.
  {8080/8085 assembler, dBase and Paradox}
Neither I, nor my employers, classed me as a "programmer".
I was "Senior Engineering Tech" or "Junior Engineer".
IOW, I was not in abject *AWE* of computers. *ROFL*

Right now I'm working on a personal project.
INPUT:  How much of what did I eat?
OUTPUT: How much [cal/protein/fiber] did I eat?

SQL {and variants} seen to dominate all else.
IIRC, dBase was simpler.

What current FOSS system might I be comfortable with?

TIA

Re: Simple spreadsheet program.

[David Wright]

On Wed 14 Mar 2018 at 18:46:46 (+1100), Erik Christiansen wrote:
> On 13.03.18 10:48, David Wright wrote:
> > On Tue 13 Mar 2018 at 21:31:00 (+1100), Erik Christiansen wrote:
> > > Too true. After a couple of hours of failing to get any GUI drawing
> > > package, not least LibreOffice, to do anything useful, I used Vim to
> > > textually produce the 8 drawings for my house; plan, elevations &
> > > sections, and site plan. It took about 800 lines of Postscript, and I
> > > didn't have to crack the inscrutable secrets of an obstructive GUI
> > > interface.
> > 
> > OTOH the results of your work were highly scrutable?
> 
> Adjectives describe nouns, in the quoted text that is "interface secrets".
> The quoted text did not refer to output/results.
> The quote of my function to draw a door in a floorplan shows my text
> input, not output/results.

That's just playing with words. As far as we on this list are
concerned, your contribution to the thread was a process: editing
PostScript source text with vim. The work that you put into this
process/interface/call it what you will, was a lengthy session
of learning the PostScript language. That has to be costed in,
just as learning about snap-to-grid has to be.

> The result of conversion of the postscript to pdf is a suite of drawings
> when displayed with e.g. xpdf. (Scrutable even to local government
> officials, at considerable cost saving compared to using an architect.)

The marks on the paper were not under discussion, neither as a
technical drawing nor as an architectural design, but only the
operations to produce them.

> But there is perhaps an unstated point - that the postscript language
> (the interface) is not equally scrutable for all.

That's why I quoted it, so people could judge for themselves. It's
the one part of your process that can be clearly put in a posting.
This source code has to be mastered.

> I found it infinitely
> easier to learn a fully discoverable textual language than how to crank
> a mouse engine in mysterious ways.

One would expect that of someone who sees using a mouse as fighting it.

But here we have no way of knowing how the OP views using a mouse
(which for most spreadsheet operations plays a minor role):
whether it makes things easier or speedier, or is best avoided.
For most people, there's a balance; they use both mouse and keyboard
as they feel is appropriate for each action.

All that said, the thrust of my post was: everyone should have some
sort of acquaintance with spreadsheets by the time they leave school.
Vim key bindings—perhaps not. PostScript—probably not.

Cheers,
David.

Re: Simple spreadsheet program.

[David Wright]

On Tue 13 Mar 2018 at 22:00:00 (-0700), Charlie Gibbs wrote:
> On 13/03/18 02:49 PM, Ben Caradoc-Davies wrote:
> 
> >I also long avoided the complexity of LibreOffice Calc, but a modest
> >investment of time has left me satisfied with the results. Things I like:
> >
> >- Flexible CSV import/export. I like to manipulate CSV files with grep,
> >perl, and geany, and then import into Calc. Nothing is quicker than
> >Ctrl-D in a text editor for deleting unwanted rows. I also use a regex
> >to convert all dates to (for example) ISO 8601 here as fixing date
> >values in Calc can be painful (but formatting is easy with Ctrl-1). Then
> >CSV import to slurp it into Calc, delete unwanted columns, and copy and
> >paste into the target sheet.
> 
> The nice thing for me is that when you import a CSV file,
> LibreOffice Calc sizes each column according to the width of the
> data.  Unlike Excel, you don't have to manually invoke the
> hilariously-titled "auto-format" feature to set the column widths to
> something reasonable.

I was unaware that in Excel you couldn't use the usual method which
I gave (for heights rather than widths, but it's the same) in
https://lists.debian.org/debian-user/2018/01/msg00264.html
and is used by both gnumeric and calc.

> Speaking of ISO 8601, I'm currently in the process of converting all
> our systems to use it in place of other date formats such as
> /mm/dd. Excel is quite adamant about converting anything that
> looks remotely like a date into mm/dd/ format, but ISO 8601 is
> apparently beyond what its feeble mind can handle, and Excel leaves
> it alone.

But used as an entry format for dates and times, doesn't that mean
you're entering strings, which then can't be used in calculations?

For me, the problem with ISO 8601 as a display format is losing the
month names, so I use formats like -mmm-dd hh:mm for displaying
columns containing timestamps. With CSV export, gnumeric turns such
dates into /mm/dd which can be reimported elsewhere.

Cheers,
David.

Re: Simple spreadsheet program.

[Erik Christiansen]

On 13.03.18 10:48, David Wright wrote:
> On Tue 13 Mar 2018 at 21:31:00 (+1100), Erik Christiansen wrote:
> > Too true. After a couple of hours of failing to get any GUI drawing
> > package, not least LibreOffice, to do anything useful, I used Vim to
> > textually produce the 8 drawings for my house; plan, elevations &
> > sections, and site plan. It took about 800 lines of Postscript, and I
> > didn't have to crack the inscrutable secrets of an obstructive GUI
> > interface.
> 
> OTOH the results of your work were highly scrutable?

Adjectives describe nouns, in the quoted text that is "interface secrets".
The quoted text did not refer to output/results.
The quote of my function to draw a door in a floorplan shows my text
input, not output/results.
The result of conversion of the postscript to pdf is a suite of drawings
when displayed with e.g. xpdf. (Scrutable even to local government
officials, at considerable cost saving compared to using an architect.)

But there is perhaps an unstated point - that the postscript language
(the interface) is not equally scrutable for all. I found it infinitely
easier to learn a fully discoverable textual language than how to crank
a mouse engine in mysterious ways. Eric Raymond perhaps said it best.
(See sig)

Cheers,
Erik

-- 
The meta-problem here is that the configuration wizard does all the approved   
rituals (GUI with standardized clicky buttons, help popping up in a browser,
etc. etc.) but doesn't have the central attribute these are supposed to achieve:
discoverability. That is, the quality that every point in the interface has
prompts and actions attached to it from which you can learn what to do next.
   - Eric Raymond, in "The Luxury of Ignorance."

Re: Simple spreadsheet program.

[Charlie Gibbs]

On 13/03/18 02:49 PM, Ben Caradoc-Davies wrote:


I also long avoided the complexity of LibreOffice Calc, but a modest
investment of time has left me satisfied with the results. Things I like:

- Flexible CSV import/export. I like to manipulate CSV files with grep,
perl, and geany, and then import into Calc. Nothing is quicker than
Ctrl-D in a text editor for deleting unwanted rows. I also use a regex
to convert all dates to (for example) ISO 8601 here as fixing date
values in Calc can be painful (but formatting is easy with Ctrl-1). Then
CSV import to slurp it into Calc, delete unwanted columns, and copy and
paste into the target sheet.


The nice thing for me is that when you import a CSV file, LibreOffice 
Calc sizes each column according to the width of the data.  Unlike 
Excel, you don't have to manually invoke the hilariously-titled 
"auto-format" feature to set the column widths to something reasonable.


Speaking of ISO 8601, I'm currently in the process of converting all our 
systems to use it in place of other date formats such as /mm/dd. 
Excel is quite adamant about converting anything that looks remotely 
like a date into mm/dd/ format, but ISO 8601 is apparently beyond 
what its feeble mind can handle, and Excel leaves it alone.


A lot of my programming effort goes toward "Excel-proofing" my data.

--
cgi...@surfnaked.ca (Charlie Gibbs)

Re: Simple spreadsheet program.

[deloptes]

Ben Caradoc-Davies wrote:

> I also long avoided the complexity of LibreOffice Calc, but a modest
> investment of time has left me satisfied with the results.

+1

I use Apache OO, and there is very good documentation such that in 1-2
minutes I could find answer to any of my question and complete the task.

Re: Simple spreadsheet program.

[Ben Caradoc-Davies]

On 13/03/18 16:13, terryc wrote:

What is a simple spreadsheet program that can be installed under
Stretch. I need to do some work quickly
hint, if your answer is LibreOffice or similar read the question again.
I'm frustrated that the last few time I wanted to do a simple
spreadsheet layout, it was easier and faster to craft a LaTex document
then try and unfathom LibreOffice methods.


Is your goal calculation or the preparation of tables for documents?

I also long avoided the complexity of LibreOffice Calc, but a modest 
investment of time has left me satisfied with the results. Things I like:


- Flexible CSV import/export. I like to manipulate CSV files with grep, 
perl, and geany, and then import into Calc. Nothing is quicker than 
Ctrl-D in a text editor for deleting unwanted rows. I also use a regex 
to convert all dates to (for example) ISO 8601 here as fixing date 
values in Calc can be painful (but formatting is easy with Ctrl-1). Then 
CSV import to slurp it into Calc, delete unwanted columns, and copy and 
paste into the target sheet.


- Copy a rectangular subset in Calc then Paste Special / HTML in Writer 
is an easy way to get calculated tables into a PDF document.


- Interoperability with Windows users via DOCX gives them something they 
can alter.


LibreOffice can be daunting at first but I found that a little 
persistence went a long way. Even from my perspective as a TeX/LaTeX 
user and programmer with much experience in data ingestion and 
reporting, LibreOffice lets me get small things done more quickly. I 
recommend it.


You can use a sledgehammer to crack a nut, producing delicious nut 
butter, if you do not mind the crunchy bits of shell.  :-)


Kind regards,

--
Ben Caradoc-Davies <b...@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand

Re: Simple spreadsheet program.

[Curt]

On 2018-03-13, Joe  wrote:
>> 
>> Yes, on a new stretch (print/SSH/standard utilities) with the
>> following installed already:
>> 
>> etckeeper cryptsetup dosfstools keyutils gdisk zip apt-show-versions
>> aptitude boot-info-script bootlogd dkms exim4 firmware-linux flac
>> fluid-soundfont-gm fluid-soundfont-gs fluidsynth* gpm lame lynx-cur mc
>> mlocate normalize-audio mutt ntp p7zip-full paps pdftk
>> printer-driver-cups-pdf putty putty-doc python-doc python3.5-doc
>> python-reportlab realpath scrot setcd smartmontools sox strace
>> texlive-luatex* timidity tnef unifont uudeview wicd-curses xournal
>> xpdf xzgv xzoom youtube-dl* apt-listbugs emacs emacs24-common-non-dfsg
>> hwdata hwinfo info inxi jpeginfo firmware-ipw2x00
>> ndiswrapper-utils-1.9 linux-source alsa-utils arandr aumix-gtk
>> audacious-plugins audacity evince font-manager fvwm get-flash-videos*
>> 
>> (where * marks the relatively hungry ones), gnumeric will add:
>> 
>> hunspell-en-us enchant libaa1 libdv4 libshout3
>> gstreamer1.0-plugins-good lp-solve yelp libyelp0 pxlib1 fonts-dejavu
>> libhyphen0 libsuitesparseconfig4 libgsf-1-114 gnumeric-doc
>> libgoffice-0.10-10 gnumeric-common gnome-user-guide libaspell15
>> yelp-xsl libtag1v5 libgsf-1-common libcolamd2 libenchant1c2a
>> fonts-dejavu-extra gstreamer1.0-x libwebkit2gtk-4.0-37 aspell
>> libgoffice-0.10-10-common libhunspell-1.4-0 libtag1v5-vanilla gnumeric
>> libjavascriptcoregtk-4.0-18 libxslt1.1 aspell-en
>> 
>
> I think you may be collecting 'recommendeds' there. I've had gnumeric
> installed for many years, and don't have, for example, enchant.
>

I'm disenchanted too.

curty@einstein:~$ apt depends gnumeric
gnumeric
  PreDepends: debconf
  Depends: gnumeric-common (= 1.12.32-1)
 |Depends: debconf (>= 0.5)
  Depends: 
cdebconf
debconf
  Depends: libatk1.0-0 (>= 1.12.4)
  Depends: libc6 (>= 2.23)
  Depends: libcairo2 (>= 1.10.0)
  Depends: libgdk-pixbuf2.0-0 (>= 2.25.2)
  Depends: libglib2.0-0 (>= 2.37.3)
  Depends: libgoffice-0.10-10 (>= 0.10.28)
  Depends: libgsf-1-114 (>= 1.14.24)
  Depends: libgtk-3-0 (>= 3.19.12)
  Depends: libpango-1.0-0 (>= 1.22.0)
  Depends: libpangocairo-1.0-0 (>= 1.14.0)
  Depends: libxml2 (>= 2.7.4)
  Depends: pxlib1 (>= 0.5.0)
  Depends: zlib1g (>= 1:1.1.4)
  Depends: gsfonts
  Depends: procps
procps:i386
  Breaks: gnumeric-common (<< 1.12.2)
  Breaks: gnumeric-doc (<< 1.12.32)
  Recommends: gnumeric-doc (>= 1.12.32)
 |Recommends: evince
  Recommends: evince-gtk
  Recommends: lp-solve
  Suggests: gnumeric-plugins-extra
 |Suggests: fonts-liberation
  Suggests: ttf-mscorefonts-installer
  Replaces: gnumeric-common (<< 1.12.2)

-- 
Bah, the latest news, the latest news is not the last.
Samuel Beckett

Re: Simple spreadsheet program.

[Joe]

On Tue, 13 Mar 2018 10:22:23 -0500
David Wright <deb...@lionunicorn.co.uk> wrote:

> On Tue 13 Mar 2018 at 08:59:00 (+), Joe wrote:
> > On Tue, 13 Mar 2018 14:13:33 +1100
> > terryc <ter...@woa.com.au> wrote:
> >   
> > > What is a simple spreadsheet program that can be installed under
> > > Stretch. I need to do some work quickly
> > > 
> > > hint, if your answer is LibreOffice or similar read the question
> > > again. I'm frustrated that the last few time I wanted to do a
> > > simple spreadsheet layout, it was easier and faster to craft a
> > > LaTex document then try and unfathom LibreOffice methods.
> > >   
> > 
> > 'The' alternative spreadsheet is gnumeric, but it's some years
> > since I used it last. I recall it as being a bit less Excel-like
> > than LibreOffice (OpenOffice then) but that might be different now.
> > If you don't have any other Gnome stuff, gnumeric is likely to pull
> > in quite a lot of dependencies.  
> 
> Yes, on a new stretch (print/SSH/standard utilities) with the
> following installed already:
> 
> etckeeper cryptsetup dosfstools keyutils gdisk zip apt-show-versions
> aptitude boot-info-script bootlogd dkms exim4 firmware-linux flac
> fluid-soundfont-gm fluid-soundfont-gs fluidsynth* gpm lame lynx-cur mc
> mlocate normalize-audio mutt ntp p7zip-full paps pdftk
> printer-driver-cups-pdf putty putty-doc python-doc python3.5-doc
> python-reportlab realpath scrot setcd smartmontools sox strace
> texlive-luatex* timidity tnef unifont uudeview wicd-curses xournal
> xpdf xzgv xzoom youtube-dl* apt-listbugs emacs emacs24-common-non-dfsg
> hwdata hwinfo info inxi jpeginfo firmware-ipw2x00
> ndiswrapper-utils-1.9 linux-source alsa-utils arandr aumix-gtk
> audacious-plugins audacity evince font-manager fvwm get-flash-videos*
> 
> (where * marks the relatively hungry ones), gnumeric will add:
> 
> hunspell-en-us enchant libaa1 libdv4 libshout3
> gstreamer1.0-plugins-good lp-solve yelp libyelp0 pxlib1 fonts-dejavu
> libhyphen0 libsuitesparseconfig4 libgsf-1-114 gnumeric-doc
> libgoffice-0.10-10 gnumeric-common gnome-user-guide libaspell15
> yelp-xsl libtag1v5 libgsf-1-common libcolamd2 libenchant1c2a
> fonts-dejavu-extra gstreamer1.0-x libwebkit2gtk-4.0-37 aspell
> libgoffice-0.10-10-common libhunspell-1.4-0 libtag1v5-vanilla gnumeric
> libjavascriptcoregtk-4.0-18 libxslt1.1 aspell-en
> 

I think you may be collecting 'recommendeds' there. I've had gnumeric
installed for many years, and don't have, for example, enchant.

-- 
Joe

Re: Simple spreadsheet program.

[David Wright]

On Tue 13 Mar 2018 at 21:31:00 (+1100), Erik Christiansen wrote:
> On 13.03.18 09:59, Joe wrote:
> > On Tue, 13 Mar 2018 20:42:08 +1100
> > Erik Christiansen <dva...@internode.on.net> wrote:
> > > An sc description: "Its keybindings are familiar to users of 'vi', and
> > > it has most features that a pure spreadsheet would, but lacks things
> > > like graphing and saving in foreign formats. It's very stable and
> > > quite easy to use once you've put a little effort into learning it."
> > > makes it look as simple as it gets.
> > > 
> > > Erik
> > > (Who just uses a line of awk when needing to sum a column or two in a
> > > table.)
> > > 
> > 
> > It's the 'little effort' that stood out for me. Someone familiar with
> > the operation of a piece of software always grossly underestimates how
> > much they know about it, and how much someone else coming to it cold
> > needs to know.
> 
> Too true. After a couple of hours of failing to get any GUI drawing
> package, not least LibreOffice, to do anything useful, I used Vim to
> textually produce the 8 drawings for my house; plan, elevations &
> sections, and site plan. It took about 800 lines of Postscript, and I
> didn't have to crack the inscrutable secrets of an obstructive GUI
> interface.

OTOH the results of your work were highly scrutable?

/door% S: length (door width)
{ dup
/wall_length exch wall_length add 60 add def % Keep global variable outside 
dict scope.
  1 dict begin  % 60 = 2*30 jambs.
  /length exch def  % Take length off the stack.
  30 100 box
  currentpoint translate 
  0 length lineto length length length 0 length arct 30 100 box gstroke
  gsave 200 300 moveto length buf cvs show   % Size 
text.
  grestore
  end  % End of local var scope.  
} def

> But I persevered with the Eagle GUI schematic capture & PCB layout app,
> putting in the weeks to tame it.
> 
> It probably comes down to whether you think you'll ever use it again.

In the case of spreadsheets, I think anyone leaving school should be
able to use one to do simple finance/budgeting calculations, just as
using a calculator was necessary for pupils in the past. That didn't
mean the latter had to be familiar with an RPN interface (like the
original HP models), but just the basic infix interface that most
calculators had.

In the case of the OP, "I need to do some work quickly" indicates that
the interface is more important than the underlying complexity that the
computer deals with. That said, I have no idea what the OP was
trying to do. If LaTeX was a good fit last time, it sounds as if they
wanted to print a table of non-calculated information in a neat and
tidy format, for which I might gravitate to a text file with tabs.

Cheers,
David.

Re: Simple spreadsheet program.

[Jude DaShiell]

Oleo is now no longer supported and support for that spreadsheet ended 
in 2001.  However there is good news.  A program called neoleo can be 
found and built and neoleo is the successor to oleo and is under active 
support.  The neoleo program can work in text or graphics now.  I doubt 
debian has neoleo 6.0 available though which is why I didn't mention it 
in my response.  I run archlinux here and if I can ever get stretch to 
properly boot after an install I may put that on one of my hard drives 
and use it too.


On Tue, 13 Mar 2018, Toma? ?olc wrote:


Date: Tue, 13 Mar 2018 05:49:28
From: Toma? ?olc <tomaz.s...@tablix.org>
To: debian-user@lists.debian.org
Subject: Re: Simple spreadsheet program.
Resent-Date: Tue, 13 Mar 2018 09:49:51 + (UTC)
Resent-From: debian-user@lists.debian.org

Years ago I used to work with GNU Oleo in a text terminal.

https://www.gnu.org/software/oleo/oleo.html

I see it's been removed from Debian in 2009 though.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526212

Best regards
Toma?




--

Re: Simple spreadsheet program.

[David Wright]

On Tue 13 Mar 2018 at 08:59:00 (+), Joe wrote:
> On Tue, 13 Mar 2018 14:13:33 +1100
> terryc <ter...@woa.com.au> wrote:
> 
> > What is a simple spreadsheet program that can be installed under
> > Stretch. I need to do some work quickly
> > 
> > hint, if your answer is LibreOffice or similar read the question
> > again. I'm frustrated that the last few time I wanted to do a simple
> > spreadsheet layout, it was easier and faster to craft a LaTex document
> > then try and unfathom LibreOffice methods.
> > 
> 
> 'The' alternative spreadsheet is gnumeric, but it's some years since I
> used it last. I recall it as being a bit less Excel-like than
> LibreOffice (OpenOffice then) but that might be different now. If you
> don't have any other Gnome stuff, gnumeric is likely to pull in quite a
> lot of dependencies.

Yes, on a new stretch (print/SSH/standard utilities) with the
following installed already:

etckeeper cryptsetup dosfstools keyutils gdisk zip apt-show-versions
aptitude boot-info-script bootlogd dkms exim4 firmware-linux flac
fluid-soundfont-gm fluid-soundfont-gs fluidsynth* gpm lame lynx-cur mc
mlocate normalize-audio mutt ntp p7zip-full paps pdftk
printer-driver-cups-pdf putty putty-doc python-doc python3.5-doc
python-reportlab realpath scrot setcd smartmontools sox strace
texlive-luatex* timidity tnef unifont uudeview wicd-curses xournal
xpdf xzgv xzoom youtube-dl* apt-listbugs emacs emacs24-common-non-dfsg
hwdata hwinfo info inxi jpeginfo firmware-ipw2x00
ndiswrapper-utils-1.9 linux-source alsa-utils arandr aumix-gtk
audacious-plugins audacity evince font-manager fvwm get-flash-videos*

(where * marks the relatively hungry ones), gnumeric will add:

hunspell-en-us enchant libaa1 libdv4 libshout3
gstreamer1.0-plugins-good lp-solve yelp libyelp0 pxlib1 fonts-dejavu
libhyphen0 libsuitesparseconfig4 libgsf-1-114 gnumeric-doc
libgoffice-0.10-10 gnumeric-common gnome-user-guide libaspell15
yelp-xsl libtag1v5 libgsf-1-common libcolamd2 libenchant1c2a
fonts-dejavu-extra gstreamer1.0-x libwebkit2gtk-4.0-37 aspell
libgoffice-0.10-10-common libhunspell-1.4-0 libtag1v5-vanilla gnumeric
libjavascriptcoregtk-4.0-18 libxslt1.1 aspell-en

> I'm not aware of a 'simple' spreadsheet, as it is the kind of
> application that begs for feature-creep. Synaptic turns up sc, which I
> know nothing about, but the description doesn't look compatible with
> 'simple', unless the user interface is similar to something you already
> know.

Cheers,
David.

Re: Simple spreadsheet program.

[Stefan Monnier]

> An alternative is org mode in Emacs if you have Emacs already
> installed.  Simple spreadsheet capabilities in tables.

There's also SES, also part of Emacs (i.e. C-x C-f .ses RET should
get you started).  And Emacs being what it is, there's also the Dismal
package, which you can install from GNU ELPA.


Stefan

Re: Simple spreadsheet program.

[John Hasler]

terryc wrote:
> What is a simple spreadsheet program that can be installed under
> Stretch. I need to do some work quickly

Package: sc
Source: sc (7.16-4)
Version: 7.16-4+b2
Installed-Size: 440
Maintainer: Adam Majer <ad...@zombino.com>
Architecture: amd64
Depends: libc6 (>= 2.14), libncurses5 (>= 6), libtinfo5 (>= 6)
Description-en: Text-based spreadsheet with VI-like keybindings
 "Spreadsheet Calculator" is a much modified version of the public-
 domain spread sheet sc, which was posted to Usenet several years ago
 by Mark Weiser as vc, originally by James Gosling. It is based on
 rectangular table much like a financial spreadsheet.
 .
 Its keybindings are familiar to users of 'vi', and it has most
 features that a pure spreadsheet would, but lacks things like
 graphing and saving in foreign formats.  It's very stable and quite
 easy to use once you've put a little effort into learning it.
Description-md5: 0925a794779dba23662eeb41fb663c7e
Tag: office::spreadsheet, role::program, scope::application,
 uitoolkit::ncurses, use::editing, works-with::spreadsheet
Section: math
Priority: optional
Filename: pool/main/s/sc/sc_7.16-4+b2_amd64.deb
Size: 211774
MD5sum: 94c7293bbb4ed7858f861d0e1bc3dfe5
SHA256: 1a676b93a1e376f18f8efc30e574c1b65b84be12157289d4105850810f2804e5

-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Simple spreadsheet program.

[Eric S Fraga]

On Tuesday, 13 Mar 2018 at 14:13, terryc wrote:
> What is a simple spreadsheet program that can be installed under
> Stretch. I need to do some work quickly

I already mentioned sc.

An alternative is org mode in Emacs if you have Emacs already
installed.  Simple spreadsheet capabilities in tables.

Maybe define what you mean by simple.

-- 
Eric S Fraga via Emacs 27.0.50 & org 9.1.6 on Debian buster/sid


signature.asc
Description: PGP signature

Re: Simple spreadsheet program.

[Erik Christiansen]

On 13.03.18 09:59, Joe wrote:
> On Tue, 13 Mar 2018 20:42:08 +1100
> Erik Christiansen <dva...@internode.on.net> wrote:
> > An sc description: "Its keybindings are familiar to users of 'vi', and
> > it has most features that a pure spreadsheet would, but lacks things
> > like graphing and saving in foreign formats. It's very stable and
> > quite easy to use once you've put a little effort into learning it."
> > makes it look as simple as it gets.
> > 
> > Erik
> > (Who just uses a line of awk when needing to sum a column or two in a
> > table.)
> > 
> 
> It's the 'little effort' that stood out for me. Someone familiar with
> the operation of a piece of software always grossly underestimates how
> much they know about it, and how much someone else coming to it cold
> needs to know.

Too true. After a couple of hours of failing to get any GUI drawing
package, not least LibreOffice, to do anything useful, I used Vim to
textually produce the 8 drawings for my house; plan, elevations &
sections, and site plan. It took about 800 lines of Postscript, and I
didn't have to crack the inscrutable secrets of an obstructive GUI
interface.

But I persevered with the Eagle GUI schematic capture & PCB layout app,
putting in the weeks to tame it.

It probably comes down to whether you think you'll ever use it again.

Erik

Re: Simple spreadsheet program.

[Joe]

On Tue, 13 Mar 2018 20:42:08 +1100
Erik Christiansen <dva...@internode.on.net> wrote:

> On 13.03.18 08:59, Joe wrote:
> > I'm not aware of a 'simple' spreadsheet, as it is the kind of
> > application that begs for feature-creep. Synaptic turns up sc,
> > which I know nothing about, but the description doesn't look
> > compatible with 'simple', unless the user interface is similar to
> > something you already know.  
> 
> An sc description: "Its keybindings are familiar to users of 'vi', and
> it has most features that a pure spreadsheet would, but lacks things
> like graphing and saving in foreign formats. It's very stable and
> quite easy to use once you've put a little effort into learning it."
> makes it look as simple as it gets.
> 
> Erik
> (Who just uses a line of awk when needing to sum a column or two in a
> table.)
> 

It's the 'little effort' that stood out for me. Someone familiar with
the operation of a piece of software always grossly underestimates how
much they know about it, and how much someone else coming to it cold
needs to know.

-- 
Joe

Re: Simple spreadsheet program.

[Tomaž Šolc]

Years ago I used to work with GNU Oleo in a text terminal.

https://www.gnu.org/software/oleo/oleo.html

I see it's been removed from Debian in 2009 though.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526212

Best regards
Tomaž

Re: Simple spreadsheet program.

[Erik Christiansen]

On 13.03.18 08:59, Joe wrote:
> I'm not aware of a 'simple' spreadsheet, as it is the kind of
> application that begs for feature-creep. Synaptic turns up sc, which I
> know nothing about, but the description doesn't look compatible with
> 'simple', unless the user interface is similar to something you already
> know.

An sc description: "Its keybindings are familiar to users of 'vi', and
it has most features that a pure spreadsheet would, but lacks things
like graphing and saving in foreign formats. It's very stable and quite
easy to use once you've put a little effort into learning it." makes it
look as simple as it gets.

Erik
(Who just uses a line of awk when needing to sum a column or two in a table.)

Re: Simple spreadsheet program.

[Joe]

On Tue, 13 Mar 2018 14:13:33 +1100
terryc <ter...@woa.com.au> wrote:

> What is a simple spreadsheet program that can be installed under
> Stretch. I need to do some work quickly
> 
> hint, if your answer is LibreOffice or similar read the question
> again. I'm frustrated that the last few time I wanted to do a simple
> spreadsheet layout, it was easier and faster to craft a LaTex document
> then try and unfathom LibreOffice methods.
> 

'The' alternative spreadsheet is gnumeric, but it's some years since I
used it last. I recall it as being a bit less Excel-like than
LibreOffice (OpenOffice then) but that might be different now. If you
don't have any other Gnome stuff, gnumeric is likely to pull in quite a
lot of dependencies.

I'm not aware of a 'simple' spreadsheet, as it is the kind of
application that begs for feature-creep. Synaptic turns up sc, which I
know nothing about, but the description doesn't look compatible with
'simple', unless the user interface is similar to something you already
know.

-- 
Joe

Re: Simple spreadsheet program.

[Eric S Fraga]

On Tuesday, 13 Mar 2018 at 14:13, terryc wrote:
> What is a simple spreadsheet program that can be installed under
> Stretch. I need to do some work quickly

sc works well and is indeed simple.  not graphical.

-- 
Eric S Fraga via Emacs 27.0.50 & org 9.1.6 on Debian buster/sid


signature.asc
Description: PGP signature

Re: Simple spreadsheet program.

[deloptes]

terryc wrote:

> hint, if your answer is LibreOffice or similar read the question again.
> I'm frustrated that the last few time I wanted to do a simple
> spreadsheet layout, it was easier and faster to craft a LaTex document
> then try and unfathom LibreOffice methods.

Windows + MS Office :D

Re: Simple spreadsheet program.

[Joel Roth]

On Tue, Mar 13, 2018 at 02:13:33PM +1100, terryc wrote:
> What is a simple spreadsheet program that can be installed under
> Stretch. I need to do some work quickly

Here's Instacalc, a free-to-use DOS program that I 
once used heavily.

http://www.bttr-software.de/freesoft/dbase.htm#instacalc
 
Note that you'll need to run this under some type of 
DOS emulator. 

> hint, if your answer is LibreOffice or similar read the question again.
> I'm frustrated that the last few time I wanted to do a simple
> spreadsheet layout, it was easier and faster to craft a LaTex document
> then try and unfathom LibreOffice methods.

I'm a dinosaur, too, but the bar to using LibreOffice calc
seems pretty low, basically one 5 minute youtube tutorial.

cheers
 

-- 
Joel Roth
  

Re: Simple spreadsheet program.

[Jude DaShiell]

scim probably ought to answer.
On Tue, 13 Mar 2018, terryc wrote:


Date: Mon, 12 Mar 2018 23:13:33
From: terryc <ter...@woa.com.au>
To: debian-user@lists.debian.org
Subject: Simple spreadsheet program.
Resent-Date: Tue, 13 Mar 2018 03:14:03 + (UTC)
Resent-From: debian-user@lists.debian.org

What is a simple spreadsheet program that can be installed under
Stretch. I need to do some work quickly

hint, if your answer is LibreOffice or similar read the question again.
I'm frustrated that the last few time I wanted to do a simple
spreadsheet layout, it was easier and faster to craft a LaTex document
then try and unfathom LibreOffice methods.




--

Re: Simple spreadsheet program.

[David Wright]

On Tue 13 Mar 2018 at 14:13:33 (+1100), terryc wrote:
> What is a simple spreadsheet program that can be installed under
> Stretch. I need to do some work quickly

I use gnumeric myself. As its description says, if you know
Excel, then you'll know how to use it.

(I use a Window Manager, not a Desk Environment.)

Cheers,
David.

Simple spreadsheet program.

[terryc]

What is a simple spreadsheet program that can be installed under
Stretch. I need to do some work quickly

hint, if your answer is LibreOffice or similar read the question again.
I'm frustrated that the last few time I wanted to do a simple
spreadsheet layout, it was easier and faster to craft a LaTex document
then try and unfathom LibreOffice methods.

Re: SCIM - terminal spreadsheet - sc fork

[Darac Marjal]

On Mon, Feb 23, 2015 at 09:11:30AM -0800, Carl Johnson wrote:
 John Hasler jhas...@newsguy.com writes:
 
  Chris Bannister writes:
  That sounds like a recipe for confusion. Some people, no doubt still
  use the old version.
 
  My wife does.  I would not be adverse to upgrading to a supported
  replacement, though, as long as it is backward-compatible.  Keeping the
  old name would be a plus.
 
 I just noticed that there is a text spreadsheet called teapot that
 supposedly can import sc files.  I don't see where Debian has packages,
 but it has .deb packages available for download at its web page¹.  The
 original poster may want to also look at it for ideas.

teapot was ITP'd back in 2010
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594507), but it looks
like it got neglected.

 
 ¹ http://www.syntax-k.de/projekte/teapot
 -- 
 Carl Johnson  ca...@peak.org
 
 
 --
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/87r3tgzh6l.fsf@elk.localnet
 


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150224091719.ga23...@darac.org.uk

Re: SCIM - terminal spreadsheet - sc fork

[Andrés Martinelli]

Hello again and thanks for the suggestions. I cannot use the same name because 
scim is not sc with some new features, nor is an improvement over it, its just  
another application.
It should be entirely compatible with sc, but in the inside, is a completely 
different app.

 El 23/02/2015, a las 11:32, Liam O'Toole liam.p.oto...@gmail.com escribió:
 
 On 2015-02-23, Petter Adsen pet...@synth.no wrote:
 --Sig_/rpAzsNcN+cDo.tN.Ondk0c6
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 
 On Mon, 23 Feb 2015 13:52:29 + (UTC)
 Liam O'Toole liam.p.oto...@gmail.com wrote:
 Anyway, regardless of the terminology, simply to appropriate the name
 sc might be perceived as bad manners. I would encourage the OP to
 attempt to contact the former developers(s) first if he or she wishes
 to use that name.
 
 Or, if that fails, what about sc2?
 
 Petter
 
 Indeed. Or perhaps sc-ng.
 
 -- 
 
 Liam
 
 
 
 -- 
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/slrnmemefq.729.liam.p.otoole@dipsy.tubbynet
 


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/4751312e-2e5b-4d04-b8a8-7ccde5ab7...@gmail.com

Re: SCIM - terminal spreadsheet - sc fork

[Chris Bannister]

On Mon, Feb 23, 2015 at 09:01:22AM +0100, Christian Groessler wrote:
 Why not just keep the original name, sc?
 
 I don't think it's actively developed elsewhere, so the new improved version
 could be distinguished by the version number.

That sounds like a recipe for confusion. Some people, no doubt still use
the old version.

Is there any software that has done this? AFAIK, all forks have changed
the name.

-- 
If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing. --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150223120036.GA6465@tal