{"thread":{"id":"59578","subject":"Video conference libification eng discussion, this Thursday 16:30 UTC","startedAt":"2023-04-11T18:40:47Z","lastAt":"2023-04-13T17:00:30Z","messageCount":2,"participants":["Emily Shaffer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"475165","messageId":"CAJoAoZnBPH6j93eRRuVKZkDix9h7S287eTMfF9dK0CvC+meMxQ@mail.gmail.com","threadId":"59578","inReplyTo":null,"subject":"Video conference libification eng discussion, this Thursday 16:30 UTC","fromName":"Emily Shaffer","fromEmail":"nasamuffin@google.com","sentAt":"2023-04-11T18:40:23Z","receivedAt":"2023-04-11T18:40:47Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"Hello folks,\n\nGoogle is hosting a standing engineering discussion about libifying\nGit, for contributors interested in participating in or hearing about\nthe progress of this effort. Expect this discussion to be free-form\nand casual - no powerpoints here!\n\nWe're hoping to hold this meeting every Thursday at 9:30am Pacific\n(16:30 UTC) via Google Meet.\n\nTo get an invite to the video conference and the notes document,\nplease reply to this email. Please also add points to the agenda\n(template follows) if you want to raise awareness of them.\n\nWe'll choose a topic to discuss at the beginning of the meeting, and\nI'll reply afterwards with the notes.\n\n - (asynchronous) What's cooking in libification?\n - Patches we sent regarding libification\n - Patches for review related to the libification effort\n - (asynchronous) What happened in the past 1-2 weeks that interested\nparties or intermittent contributors need to know?\n - (asynchronous) Where are you stuck? What eng discussions do we want\nto have? (We'll choose a topic from this list a day ahead of the\nmeeting.)\n - Session topic: \n"},{"id":"475311","messageId":"CAJoAoZ=A7hPbFHw_7btD0+dFzpQOXSpVa7ss2O0zbG2S_d3rKQ@mail.gmail.com","threadId":"59578","inReplyTo":"CAJoAoZnBPH6j93eRRuVKZkDix9h7S287eTMfF9dK0CvC+meMxQ@mail.gmail.com","subject":"Re: Video conference libification eng discussion, this Thursday 16:30 UTC","fromName":"Emily Shaffer","fromEmail":"nasamuffin@google.com","sentAt":"2023-04-13T17:00:07Z","receivedAt":"2023-04-13T17:00:30Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"The notes from today's session follow.\n\n\n - (asynchronous) What's cooking in libification?\n - Patches we sent regarding libification\n- Coccinelle conventions\nhttps://lore.kernel.org/git/pull.1495.git.git.1681329955.gitgitgadget@gmail.com\n - Patches for review related to the libification effort\n- cache.h cleanups\nhttps://lore.kernel.org/git/pull.1509.v2.git.1680571348.gitgitgadget@gmail.com\n - (asynchronous) What happened in the past 1-2 weeks that interested\nparties or intermittent contributors need to know?\n - (asynchronous) Where are you stuck? What eng discussions do we want\nto have? (We'll choose a topic from this list at the beginning of the\nmeeting.)\n - Session topic: <TBD>\n\n\n* Elijah: I have the next set of cache.h cleanups waiting around,\nbut I'm waiting for the first set to make it in, and wondering whether\nI should rebase onto Calvin\n * Calvin: you should send yours without waiting, I don't think\nthere will be a conflict\n * Elijah: ok, will try to avoid strbuf and git-compat-util changes\n* Glen: Hey take a look at\nhttps://lore.kernel.org/git/pull.1495.git.git.1681329955.gitgitgadget@gmail.com\n * Elijah: I also wasn't sure how to review these, the how-to\nsounds useful but I don't know any better either?\n * Glen: If this series doesn't seem to make your life easier,\nthen it hasn't achieved its purpose\n * Should this come with MyFirstSemanticPatch..?\n * General approval 🙂\n * Maybe it can come later\n* Calvin: We've been working on the idea of a \"git-std-lib\" internally\n * Libification of \"just strbuf\" and \"just hashmap\" vs.\nlibification of \"all the shared low-level stuff that depends on each\nother\"\n * Removing the dependency on wrapper.h/usage.h is really tricky\n * So instead, a standard library which is includable from git\nlibrary callers and also used throughout Git's own codebase\n * Stuff like strbuf, string\\_list, abspath, strmap, strvec,\nwrapper, usage, utf8, etc etc etc all in a single library\n * To get the proof of concept, made some cleanups to\ngit-compat-util, removed dependencies on repository.h, trace2.h, etc\nwere refactored or replaced with a stub in the unit test makefile\n * Have something promising internally\n * Does this seem like a good idea..? Hoping to send RFC after\nOOO next week sometime\n * Elijah: Expecting lots of people to ask what's the purpose of\nthe standard library, does it imply backwards compatibility, etc etc\n * No backwards compatibility, if consumers want to accept\nthat churn then they can use it with no promises\n * Emily: In fact, it's likely to start out pretty rough,\nwith still prints and dies and so on, so we will intend to change it a\nlot afterwards\n * Calvin: You might ask, why not do that first? Mostly, to\nunblock others as quickly as possible 🙂 If we can make it possible to\nbuild something on top of it and prove it's usable, then that gives us\nmore momentum to keep polishing it\n * Randall: Do we want to mark these apis as experimental?\n * Emily: Yes, this and all the apis we're working on for\nthe foreseeable future\n * Elijah: static? Dynamic?\n * Calvin: static for now. I don't have a lot of\nexperience with Makefile\n * Where are these makefile changes going?\n * Emily: Early stages, we want to make a guarantee about\nthe ability to compile and unit test, that's likely to go into\nt/Makefile\n * Glen: Maybe later it makes sense to move things into\nlib/ and stand up a lib/Makefile, but we can cross that bridge when we\ncome to it\n * Randall: atexit() is used in Git, be careful with deps\non atexit() in a dynamic library please! It's not very platform\nconsistent\n * Emily: Randall, can you take one of these sessions and\ntell us all the stories about atexit() 🙂\n * Elijah: hash.h depending on repository.h, stringmap\ndepending on hash.h, this is gross. But FYI I did work on something to\nremove repository.h from hash.h\n * Calvin: we ran into that problem, yeah. Very cool to\nhear you have some fix, can we see it 🙂\n * Elijah: mempool?\n * Calvin: not worried about mempool\n* Elijah: Was doing some performance testing moving functions into a\nnew file and determining if it was helpful or not (to see if I can\nreplace rust stuff)\n * Turns out there's a small performance degradation moving\nsomething into a new file like this?\n * We might be able to use this to increase performance in some places too\n * Calvin: do we know why?\n * Elijah: maybe code locality..? It's a function that's being\npassed to qsort, so it was being run in a very tight loop, it seems\nlike that difference in cache locality made a difference\n * Jonathan: I've seen this kind of thing as an argument to be\npro-C++ because templates mean you can choose this functionality at\ncompile time and avoid this penalty.\n * Elijah: I spent a lot of time on microoptimizations for the\nmerge code, it was difficult to parallelize it as it is (in C/++). Why\nnot 🦀? Was an interesting experiment to look into performance\nregressions. Putting the sort into rust actually gave some speedup.\nBeing able to optimize that sort was really helpful.\n * Randall: Other compilers, like Intel C99, the optimizer can do\nsome things with comparators in the same object as the qsort\ninvocation to avoid that penalty.\n * Randall: Happy to talk about C multithreading too, look over code, etc\n* Randall: Have been pressed into service as CVE analysis manager.\nThinking about the libification project and tests as a very good thing\nfor tracking down CVEs in the base code (if they lurk there). Being\nable to test libraries on their own is really helpful from there,\nthanks!\n\nOn Tue, Apr 11, 2023 at 11:40 AM Emily Shaffer wrote:\n>\n> Hello folks,\n>\n> Google is hosting a standing engineering discussion about libifying\n> Git, for contributors interested in participating in or hearing about\n> the progress of this effort. Expect this discussion to be free-form\n> and casual - no powerpoints here!\n>\n> We're hoping to hold this meeting every Thursday at 9:30am Pacific\n> (16:30 UTC) via Google Meet.\n>\n> To get an invite to the video conference and the notes document,\n> please reply to this email. Please also add points to the agenda\n> (template follows) if you want to raise awareness of them.\n>\n> We'll choose a topic to discuss at the beginning of the meeting, and\n> I'll reply afterwards with the notes.\n>\n> - (asynchronous) What's cooking in libification?\n> - Patches we sent regarding libification\n> - Patches for review related to the libification effort\n> - (asynchronous) What happened in the past 1-2 weeks that interested\n> parties or intermittent contributors need to know?\n> - (asynchronous) Where are you stuck? What eng discussions do we want\n> to have? (We'll choose a topic from this list a day ahead of the\n> meeting.)\n> - Session topic: \n"}]}