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
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 text file, or read it as emails in any email clien
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
