#lumosql Minutes

Meeting started by danshearer at 2022-03-18 12:01:18+0000 (full logs).

Attendees

  1. BKJ621 (aka Björn) - 12 lines (3%)
  2. Bayes - 16 lines (4%)
  3. Labhraich (aka Claudio) - 52 lines (14%)
  4. danshearer (aka Dan Shearer) - 196 lines (52%)
  5. gabby_bch (aka Gabby) - 11 lines (3%)
  6. lumosql-meetbot - 4 lines (1%)
  7. rubdos[m] (aka Ruben) - 88 lines (23%)

Meeting Summary

  1. Actions from last meeting (danshearer, 12:04:11)
    1. INFO: Claudio cleaned up combined database, and made some fixes that became obvious during that (danshearer, 12:04:39)
    2. INFO: Dan has written some talk abstracts but hasn't had them approved by the team yet. (danshearer, 12:05:33)
    3. INFO: First week of April is Brussels holidays, but some VUB staff are around on Monday 4th April (danshearer, 12:06:13)
    4. ACTION: danshearer1 circulate talk abstracts/pull abstract from any volunteers, then publish asap (danshearer, 12:07:11)
    5. ACCEPTED: Talks in Brussels will be on Wednesday 6th April (danshearer, 12:10:14)
    6. INFO: I submitted some large cluster runs, and we noticed some limits as a result, but also there is some useful data runs too. (danshearer, 12:11:14)
    7. INFO: Gabby and Dan finalised the recipe to make R Shiny output high contrast (danshearer, 12:20:33)
    8. INFO: Ruben committed a BibLaTeX file to the lumodoc repo, which will be incrementally updated from now on. (rubdos[m], 12:21:14)
    9. INFO: Dan has researched how to automatically switch contrast depending on the user selection. (danshearer, 12:24:20)
    10. ACTION: Dan to write up the R contrast research, and get comment/fixes from author of the ggplot high contrast module. (danshearer, 12:25:13)
    11. INFO: Dan has booked travel to Brussels (danshearer, 12:27:06)
    12. INFO: all has booked (BKJ621, 12:27:32)
    13. INFO: Gabby, Claudio and Björn also booked (danshearer, 12:28:21)
    14. INFO: Björn will initiate payout of ms-part a for tickets (BKJ621, 12:29:00)
  2. LumoSQL infrastructure (danshearer, 12:29:53)
    1. INFO: r.lumosql.org is a VM with every conceivable development option and R environment etc. It has been our essential playground. We now have some R code in the main LumoSQL Fossil tree and that is where it needs to be maintained with everything else. So at somepoint r.lumosql.org will become more of a production machine, with https enabled. But it won't be the master for any data. (danshearer, 12:32:15)
    2. INFO: Ruben has enabled a second worker on the VUB cluster, so two LumoSQL jobs can run at once. Very handy if one of those jobs is busy writing extremely large amounts of data with DATASIZE=1,1000 or something (danshearer, 12:33:32)
    3. INFO: Ruben has improved the script in the repo kbench/work-loop.sh, and that is what is run on the VUB cluster when we submit jobs using 'curl' according to the documentation. Ruben has been administrating the cluster from our point of view, including liasing with the actual administrators. Thanks Ruben. (danshearer, 12:35:52)
    4. INFO: this meetbot is under active development, and already I hope today's meeting notes will be better as a result. Let me know if you think of things that would make it easier or better. (danshearer, 12:37:11)
    5. INFO: we do not have a LumoSQL buildfarm, but we need one. I have looked at two public buildfarms and applied for a team account at one of them. The purpose of a buildfarm is to compile our code on lots of different kinds of computer and operating system and report where it breaks. It would be good if we could recruit a volunteer who likes this sort of thing and I am sure we will at some point. But for now my goal is to get a buildfarm (danshearer, 12:39:32)
    6. ACTION: Dan to test at least one buildfarm and discuss setting it up with the team (danshearer, 12:40:00)
    7. INFO: Buildfarms are important, because LumoSQL is intended for embedded deployment, and that means mobile hardware, which means huge diversity but also huge investment in making buildfarms available. (danshearer, 12:43:37)
  3. Benchmarking (danshearer, 12:53:09)
    1. INFO: Benchmarking tools and database now feels ready to be used by other people. The database design and tool approach has been reviewed by several people in #R and they think it is good. (danshearer, 12:54:53)
    2. INFO: Bayes committed some preliminary notes here: https://lumosql.org/src/lumosql/doc/tip/analysis/contrasts/README.md (danshearer, 12:57:07)
    3. ACTION: Dan to extract comments from irclog to doc directory regarding the meaning of fields in the benchmarking database (danshearer, 13:01:56)
    4. ACTION: Dan to ask Bayes if (a) he thinks attending meetings might be useful and (b) if so, what time in Iowa is good for him (danshearer, 13:02:40)
    5. ACTION: Ruben to find out how to record the talks. (rubdos[m], 13:03:39)
    6. ACTION: Dan to ask Bayes if he would like to be a giant head on the screen in Brussels. (danshearer, 13:09:20)
    7. ACTION: Dan to invite other people to present. (danshearer, 13:14:14)
    8. INFO: Dan has tested an ircv3 bouncer called soju, https://soju.im . This will keep a log of channels for anyone with an account, so BKJ621 and anyone else can always check in and see what is going on. (danshearer, 13:16:06)
  4. Where LumoSQL is up to (danshearer, 13:19:30)
  5. LumoSQL Encryption (danshearer, 13:20:04)
    1. INFO: Ruben et al are working actively at a proof-of-concept ABE library that will plug into lumoSQL. (rubdos[m], 13:34:13)
    2. INFO: First version will not be collusion resistant and will probably have other issues (performance), but it should be secure and interesting. (rubdos[m], 13:34:31)
    3. INFO: Indexing is going to be the most difficult part, and the most interesting, and will be postponed to one of the last phases. (rubdos[m], 13:35:36)
    4. INFO: In context of a Lumion, that means the Lumion will probably have to carry metadata for populating the index at the receiving side. (rubdos[m], 13:36:08)
  6. Documentation (danshearer, 13:41:01)
    1. ACTION: Dan to review Gabby's doc changes and proposed tree consolidation (danshearer, 13:41:57)
  7. All other things we forgot above (danshearer, 13:58:25)
    1. LINK: https://lumosql.org/src/lumosql/dir?ci=tip&name=analysis/contrasts/R (danshearer, 13:59:08)
    2. ACTION: Bayes to improve the READMEs under analyses/ to describe the structure (danshearer, 14:04:12)
    3. INFO: it seems plausible that the SQLite key-value pair store is at least reasonably competitive. (danshearer, 14:06:45)
    4. ACTION: Dan to discuss with matthewcroughan attending Brussels (danshearer, 14:17:19)
    5. ACTION: As soon as it is confirmed that the SQLite k-v store is at minimum reasonably competitive, approach Richard Hipp about his existing approval in principle to make an API for the SQLite k-v store (which will then instantly become the world's most deployed k-v store if it is part of SQLite) (danshearer, 14:19:09)
    6. ACTION: Ruben to find an auditorium for Wednesday (rubdos[m], 14:27:24)
    7. ACTION: Dan and Ruben to discuss advertising in Brussels and what to write on the advertising in terms of buildings (danshearer, 14:29:41)
Meeting ended at 2022-03-18 14:40:12+0000 (full logs).

Action Items

  1. danshearer1 circulate talk abstracts/pull abstract from any volunteers, then publish asap (link)
  2. Dan to write up the R contrast research, and get comment/fixes from author of the ggplot high contrast module. (link)
  3. Dan to test at least one buildfarm and discuss setting it up with the team (link)
  4. Dan to extract comments from irclog to doc directory regarding the meaning of fields in the benchmarking database (link)
  5. Dan to ask Bayes if (a) he thinks attending meetings might be useful and (b) if so, what time in Iowa is good for him (link)
  6. Ruben to find out how to record the talks. (link)
  7. Dan to ask Bayes if he would like to be a giant head on the screen in Brussels. (link)
  8. Dan to invite other people to present. (link)
  9. Dan to review Gabby's doc changes and proposed tree consolidation (link)
  10. Bayes to improve the READMEs under analyses/ to describe the structure (link)
  11. Dan to discuss with matthewcroughan attending Brussels (link)
  12. As soon as it is confirmed that the SQLite k-v store is at minimum reasonably competitive, approach Richard Hipp about his existing approval in principle to make an API for the SQLite k-v store (which will then instantly become the world's most deployed k-v store if it is part of SQLite) (link)
  13. Ruben to find an auditorium for Wednesday (link)
  14. Dan and Ruben to discuss advertising in Brussels and what to write on the advertising in terms of buildings (link)

Action Items by Attendee

Generated by HCoop Meetbot v0.5.0 (05 Mar 2022)