Re: Excel Spreadsheet to PDF (was: Re: PDF on debian)
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)
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?
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?
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?
> 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?
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?
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?
> 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?
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?
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?
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?]
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?]
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&q=%2Brecutils+%2Bscript+%2Bexample and https://www.google.com/search?gbv=1&q=%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?]
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?]
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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 inte
Re: FOSS equivalents of *OLD* database and spreadsheet tools?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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
Re: FOSS equivalents of *OLD* database and spreadsheet tools?
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?
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?
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?
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?
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?
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?
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?
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?
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.
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.
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.
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.
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.
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.
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 Director Transient Software Limited <https://transient.nz/> New Zealand
Re: Simple spreadsheet program.
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.
On Tue, 13 Mar 2018 10:22:23 -0500 David Wright wrote: > On Tue 13 Mar 2018 at 08:59:00 (+), Joe wrote: > > On Tue, 13 Mar 2018 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 > > > > > > 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.
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 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.
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 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.
On Tue 13 Mar 2018 at 08:59:00 (+), Joe wrote: > On Tue, 13 Mar 2018 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 > > > > 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.
> 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.
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 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.
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.
On 13.03.18 09:59, Joe wrote: > On Tue, 13 Mar 2018 20:42:08 +1100 > Erik Christiansen 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.
On Tue, 13 Mar 2018 20:42:08 +1100 Erik Christiansen 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.
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.
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.
On Tue, 13 Mar 2018 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 > > 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.
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.
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.
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.
scim probably ought to answer. On Tue, 13 Mar 2018, terryc wrote: Date: Mon, 12 Mar 2018 23:13:33 From: terryc 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.
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.
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
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 escribió: > >> On 2015-02-23, Petter Adsen 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 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
On Mon, Feb 23, 2015 at 09:11:30AM -0800, Carl Johnson wrote: > John Hasler 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
John Hasler 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. ¹ http://www.syntax-k.de/projekte/teapot -- Carl Johnsonca...@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