08:07:00 <dan-shearer[m]> #startmeeting 
08:07:00 <lumosql-meetbot> dan-shearer[m]: Meeting started at 2022-08-19T08:07+0000
08:07:01 <lumosql-meetbot> dan-shearer[m]: Current chairs: dan-shearer[m]
08:07:02 <lumosql-meetbot> dan-shearer[m]: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
08:07:03 <lumosql-meetbot> dan-shearer[m]: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
08:07:04 <lumosql-meetbot> dan-shearer[m]: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
08:07:19 <dan-shearer[m]> #meetingname Weekly Catchup
08:07:19 <lumosql-meetbot> dan-shearer[m]: Meeting name set to: Weekly Catchup
08:07:42 <rubdos[m]> #here Ruben
08:07:50 <dan-shearer[m]> #here Dan
08:07:58 <Labhraich> #here Claudio
08:08:08 <bjk621[m]> #here Bjön
08:08:09 <bjk621[m]> *Björn
08:08:33 <dan-shearer[m]> #topic Administration
08:09:02 <dan-shearer[m]> is aware that a normal meeting has some standard headings that are used every time. Look, we will get there ok? :-)
08:10:23 <bjk621[m]> I am ashamed. I am still behind but I have done other things Dan knows about
08:10:26 <dan-shearer[m]> #info Gabby is away having well-deserved fun for more than a month.
08:10:41 <dan-shearer[m]> #info Ruben is back and will tell us exciting things
08:11:09 <rubdos[m]> I can tell you exciting things about the US!
08:11:12 <dan-shearer[m]> #info Dan has a proposal to make about team members
08:12:11 <dan-shearer[m]> Ruben De Smet: I had in mind cryptography, but yes, my knowledge of current US historical events is that yes, "exciting" seems a good word.
08:13:01 <dan-shearer[m]> #info Björn is not more behind on certain administrative matters than Dan is on those same matters. Shared responsibility.
08:13:18 <dan-shearer[m]> Labhraich: good morning!
08:13:50 <Labhraich> I'll stick to "morning".  Will omit the adjectives until I'm absolutely sure
08:16:00 <dan-shearer[m]> okidoke well I think there is some pretty positive stuff to cover. Not exactly "look the LumoSQL release is ready" but some of the things we need have moved on.
08:17:10 <dan-shearer[m]> Ruben, sticking if you don't mind to LumoSQL for the duration of this meeting, could you take the next heading since you have been thinking about your work a lot.
08:18:49 <dan-shearer[m]> #topic PE-SQL and Related Matters
08:18:49 <rubdos[m]> That's a bold assumption
08:18:50 <dan-shearer[m]> *a bit
08:19:20 <dan-shearer[m]> That's exactly the correct kind of vacation. You need more practice at that by the sounds of it.
08:19:21 <rubdos[m]> This was my first vacation in four years that I did not touch my computer every day.
08:19:23 <rubdos[m]> #info I've come back from vacation and will start working on the SQL-PE module as of Monday full time.
08:19:30 <rubdos[m]> dan-shearer[m]: Absolutely.
08:20:33 <rubdos[m]> #info Current state of the module: there's some API surface for authentication, and I'd like to start tiding it and tying it into LumoSQL itself.
08:20:38 <rubdos[m]> I think that's EOT
08:21:13 <bjk621[m]> Was it broken? (I have been out sailing w/ a computer for years. Do not work every day though)
08:21:41 <dan-shearer[m]> Ruben De Smet: the general idea is that we can't try out Lumions unless we have a way of handling them.
08:22:02 <rubdos[m]> bjk621[m]: It was mostly me that was broken.
08:22:15 <rubdos[m]> dan-shearer[m]: As said before: first LumoSQL+ABE, *then* Lumions.
08:22:24 <rubdos[m]> Lumions are an externalisation of LumoSQL-encrypted rows.
08:23:00 <dan-shearer[m]> bjk621: "was the computer broken because you didn't use it on holiday" goes into the Geek Addiction Comments Hall of Fame
08:23:14 <dan-shearer[m]> Ruben De Smet: yes as said before. And reminded now in these notes.
08:23:16 <dan-shearer[m]> Thankyou
08:23:48 <dan-shearer[m]> I know that Labhraich and bjk621 both have tasks they are well aware of. No need to repeat that here.
08:24:11 <dan-shearer[m]> #topic Team Collaboration
08:24:55 <Labhraich> Surely, you touch the compuer every day if it *is* broken and you are repairing it...
08:25:20 <Labhraich> Or even the "computer".  Please ignore any missing letters as the keyboard seems to be full of cat fur
08:25:34 <rubdos[m]> I've gone so far as to neglect my Whisperfish room on Matrix and the Whisperfish forum topic, which meant I had to spend a day or two catching up...
08:25:51 <rubdos[m]> Labhraich: Sounds like you will spend a lot of time repairing it.
08:26:23 <dan-shearer[m]> Labhraich: huh. Can't blind me with your semantics. I would describe you as one of the most balanced geeks about "holiday == byebye computers" I know. I have learned from you.
08:26:44 <dan-shearer[m]> well, speaking of Whisperfish
08:28:04 <dan-shearer[m]> #topic We now have an additional project that wants to be an early adopter of LumoSQL APIs and participate in development of Lumions etc. That is https://molly.im , an independent fork of the Signal client. The other project is Whisperfish.
08:28:21 <dan-shearer[m]> NO!
08:28:25 <rubdos[m]> Isn't that an info?
08:28:27 <dan-shearer[m]> That was supposed to be #info
08:28:53 <dan-shearer[m]> Luckily all I have to do is edit the JSON log after this meeting and regenerate the HTML now. So that's fixable
08:28:53 <rubdos[m]> isn't there an #undo?
08:29:17 <dan-shearer[m]> No there is not #undo but that would be a cool feature.
08:29:23 <dan-shearer[m]> stops getting distracted
08:29:24 <Labhraich> dan-shearer[m]: As meeting chair you can #undo and remove the #topic, if you do that before the next command
08:29:34 <dan-shearer[m]> #undo 
08:29:34 <lumosql-meetbot> dan-shearer[m]: Removed event: 5cffa3fa1093417da60d83881ee531e9@2022-08-19T08:28+0000
08:29:53 <dan-shearer[m]> wow! So much for me having any knowledge of this meetbot. Apologies to Ruben.
08:29:55 <dan-shearer[m]> Thanks Labhraich
08:30:23 <dan-shearer[m]> #info We now have an additional project that wants to be an early adopter of LumoSQL APIs and participate in development of Lumions etc. That is https://molly.im , an independent fork of the Signal client. (The other project is Whisperfish.)
08:30:26 <rubdos[m]> They use this thing for SailfishOS meetings too :)
08:31:10 <dan-shearer[m]> Oh really? I had no idea. Well they have benefited from the bugfixes that LumoSQL has got put into it. That's how libre software is supposed to work, great :-)
08:32:00 <Labhraich> As a reminder...   https://hcoop-meetbot.readthedocs.io/en/latest/  (that's where I went to check that yes, #undo exists)
08:32:42 <dan-shearer[m]> #info Oscar Mira from Molly is very interested to participate in relevant parts of LumoSQL. He has helpful background and I will invite him to the next meeting.
08:34:59 <dan-shearer[m]> #info Dan is actively seeking more team members with skills in C, SQLite, applied cryptography and reverse engineering. "Reverse engineering" in the sense of looking at SQLite code and drawing a diagram.
08:35:26 <Labhraich> It may be quicker to take a brain scan of Mr Hipp....
08:35:42 <dan-shearer[m]> We don't have enough storage for that.
08:36:47 <dan-shearer[m]> (The first time I saw a neuroscience calculation about how much it would take to store a human brain state it was 1 PiB. And then more is discovered and it went to 10 PiB. I think it just keeps going up :-)
08:37:26 <Labhraich> looks up prices for 10PiB NVME.  "Sorry, this item is on order and will be available in around 30 years"
08:39:02 <Labhraich> OK, no brain scan of Mr Hipp then, as useful as that would be
08:39:23 <dan-shearer[m]> Labhraich: if you had a genie with a magic wish, is there any subsystem you would like better documented to help in what you are doing? Or to help in passing what you are doing on to someone else?
08:42:09 <Labhraich> I'd like to know what vdbe changes are to be expected in Sqlite 3.40 :-)
08:45:00 <dan-shearer[m]> That's not infeasible.
08:45:38 <dan-shearer[m]> #action Dan to encapsulate current LumoSQL vdbe changes, to give context for asking sqlite.org about what is coming.
08:45:50 <dan-shearer[m]> *summarise, not encapsulate
08:46:28 <dan-shearer[m]> That fits under the current heading, because "vdbe changes that are not a hard fork" is interesting territory for SQLite.
08:47:28 <dan-shearer[m]> And we need to start attracting the attention of sqlite. We aren't many commits away for it to be obvious what is going on here.
08:47:42 <dan-shearer[m]> ok, so that's my comments on interacting with other projects/attracting other people.
08:48:08 <dan-shearer[m]> Labhraich: am I correct that you don't feel a need for your own #topic today?
08:48:27 <dan-shearer[m]> bjk621: I know the above is definitely true for you.
08:48:31 <Labhraich> Not unless you want it to be an empty one
08:48:46 <dan-shearer[m]> NULL Labhraich , NULL
08:49:00 <dan-shearer[m]> Then I think that is everything.
08:49:18 <Labhraich> However I note that I could at least start running tests with the latest sqlite commit, so I'm not taken by surprise next time a vdbe change breaks something.  Could even run that automatically...
08:49:51 <Labhraich> Empty as in "".  Not NULL as (char *)0x0
08:50:39 <dan-shearer[m]> Labhraich: that is exactly why I am looking for someone to be a kind of buildmaster. What people call "continuous integration" would mostly cover what I have in mind. Björn used to run teams that kept compiling nXm matricies of platforms and trees.
08:51:17 <bjk621[m]> w/ a build-master
08:51:40 <Labhraich> Somebody who keeps building things to see if we (or sqlite) have broken anything ?
08:52:00 <dan-shearer[m]> Yes. And additionally in our case, to keep running benchmarks too.
08:52:23 <dan-shearer[m]> #topic Status
08:53:30 <dan-shearer[m]> #info Claudio and Dan together decided that LMDB v1.0 is not going to happen within any reasonable or predictable time and it has therefore been dropped from the plan. LMDB v1.0 has page-level encryption.
08:54:20 <Uilebheist> lmdb 0.9.29 has been "latest" for 17 months now, with no reason to believe there's going to be anything any year now
08:54:29 <dan-shearer[m]> #info Benchmarking on LMDB preliminary results indicate that cost/benefits relate to hardware not inherent software improvements
08:54:51 <dan-shearer[m]> But that's why we need to reboot the statistical work
08:55:29 <Labhraich> I note that we don't have any data on how things would work, say, on a phone
08:55:50 <Labhraich> The Raspberry PI benchmarks are only a hint, as the hardware is still different enough
08:56:54 <dan-shearer[m]> Yes, but our highly strong suspicion is that we are not looking at "memory-mapped design is generally superior to the SQLite btree approach", but rather, "different kinds of storage and hardware architecture probably suit different approaches".
08:57:14 <dan-shearer[m]> And that is what Luis kept telling us about choosing the correct questions because he can't do that for us.
08:57:41 <Labhraich> This is what I've always seen from benchmarks. There is no clear overall winner, but there is a winner given a particular combination of CPU and storage (and the winner is not always the same)
08:58:16 <Labhraich> So it would be rather important that we know what happens in a place where most of sqlite copies actually run, like a phone
08:58:18 <dan-shearer[m]> spent time revisiting the benchmarking last week before coming out with the above statement.
08:59:45 <dan-shearer[m]> #info Dan has provisionally proposed that, given LumoSQL APIs are starting to become clear, it is time to evaluate the offer from sqlite.org about exposing the Btree as a K-V store library API
09:00:14 <dan-shearer[m]> which would require someone specific to work on it, because its self-contained, and potentially highly significant
09:01:28 <dan-shearer[m]> It was an interesting (and of course provisional) offer by Richard Hipp that they would be happy to accept patches doing this. Given that they are also offering API stability guarantees to 2050.
09:01:39 <dan-shearer[m]> ok I think that has summarised everything I know about
09:02:05 <Labhraich> Well, a stable API for btree would also means a stable(r) backend API for us...
09:03:01 <dan-shearer[m]> Oh hum - Labhraich if you want a hand with API documentation or review, that's important and I must allocate time for that. It would be great for someone else to be able to look at these APIs never having heard of LumoSQL before and make sense of them. I'm a good crash test dummy
09:03:23 <dan-shearer[m]> I think that is pretty much end of meeting
09:03:44 <Labhraich> There's no real backend API at the moment.  All we do is imitate btree.c and swap it in when sqlite is not looking
09:04:03 <dan-shearer[m]> twenty seconds to #endmeeting if no interruptions :-)
09:04:39 <dan-shearer[m]> Thankyou all.
09:04:41 <dan-shearer[m]> #endmeeting