#ctrl-c | Logs for 2020-10-02
Back
[00:36:21] -!- anton has quit [Client exited]
[00:36:26] -!- anton [anton!anton@amcclure.org] has joined #ctrl-c
[09:26:36] -!- perrierjouet [perrierjouet!~perrierjou@modemcable012.251-130-66.mc.videotron.ca] has joined #ctrl-c
[11:58:00] -!- anton has quit [Client exited]
[11:58:09] -!- anton [anton!anton@am32.org] has joined #ctrl-c
[14:05:14] -!- felix [felix!~nttp@212.87.203.208] has joined #ctrl-c
[15:54:49] <felix> I wanted to ask what development libraries we have installed, then remembered I can just look in /usr/include
[15:55:40] <aravk> felix: on what system?
[15:55:49] <felix> Ctrl-C.
[15:55:50] <aravk> because /usr/include would probably be a bit of a mess
[15:55:54] <aravk> sorry, meant distro
[15:56:02] <aravk> wait
[15:56:07] <aravk> I feel stupid
[15:56:08] <felix> It is a bit of a mess!
[15:56:31] <felix> Already knew about ncurses. Turns out there's also sqlite3, and then some seemingly random picks.
[15:56:52] <aravk> dpkg -l
[15:57:03] <aravk> `dpkg -l | grep dev` should get you what you want
[15:57:29] <aravk> though I don't know dpkg well enough so you should probably check whether that's correct
[15:58:19] <felix> It seems to start up less all by itself.
[15:58:34] <aravk> really?
[15:58:41] <aravk> nope, not on my end
[15:58:55] <felix> On my PC it does.
[15:59:21] <aravk> huh
[15:59:22] <aravk> cool
[16:03:31] <felix> Unless it does something by itself that just happens to use the same keys.
[16:03:38] <felix> In fact that seems more likely.
[16:12:34] <felix> And in any event it wouldn't show me all the stuff that was built from source.
[16:12:54] <felix> Which seems to be the case for a lot of things on Ctrl-C.
[16:14:01] <aravk> ah, didn't know that
[16:14:05] <felix> Err... Or not? Those would logically place header files in /usr/local/include
[16:14:15] <aravk> perhaps
[16:14:17] <aravk> not always
[16:14:19] <felix> Well, it is an old OS. ;)
[16:14:35] <aravk> hm, yeah
[16:14:35] <felix> While Crystal for instance is the latest version.
[16:20:14] <timemachine> o/
[16:21:01] <felix> Hello!
[16:21:47] <timemachine> how is it going this afternoon?
[16:21:48] <felix> I'm just curious, because lately I started doing things that aren't just scripts using standard libraries.
[16:22:12] <felix> Oh, been making progress with a few things. You?
[16:23:00] <timemachine> Living the dream! My new hardware KVM was delivered yesterday. It's nice to get the extra keyboards off my desk.
[16:23:11] <felix> Sounds good!
[16:24:24] <timemachine> something's busted with MacOS though, running a mouse through a USB 2.0 hub doesn't work appearently and has been a known issue since 2014 ... just fix it already.
[16:24:56] <timemachine> so I still have two mice on my desk and I need to swap those but we are much less crowded.
[16:26:17] <timemachine> I may boot a test machine with the latest FreeBSD and see if it also has the mouce problem and take a crack at fixing it ... not that Apple accepts upstream pull requests but at least I could build my own binary and release it on github.
[16:28:22] <felix> I hope it works out!
[16:33:21] <timemachine> tnx
[16:35:02] <timemachine> reading some scrollback: I love working with SQLite3. It is one of the best file formats for saved application state.
[16:35:35] <aravk> raw binary ftw
[16:35:47] <timemachine> lol
[16:35:50] <felix> I also used it for a couple of things.
[16:36:23] <felix> Moved to INI files in one case since then.
[16:37:05] <aravk> my only issue with sqlite is the amount of work it takes
[16:37:12] <aravk> you need a full library
[16:37:28] <aravk> plus you need to learn SQL statements (which aren't that hard, granted, but still)
[16:37:49] <felix> Yeah, it's only light and easy compared to other SQL servers.
[16:37:54] <aravk> much easier to pull of a simple flocking text or binary based system
[16:38:00] <aravk> s/of/off/
[16:38:12] * timemachine shrugs* I guess it depends on the size of application.
[16:38:21] <aravk> yeah, and the amount of data you're manipulating
[16:38:37] <aravk> dealing with thousands (or more) entries? sure, use sqlite
[16:40:33] <timemachine> I had to implement a multi-session undo history for a query editor on an old project and it was helpful to persist the command history to one table and the undo buffers to another table. really flexable
[16:41:00] <aravk> if working with a binary format, that would just be two files instead of one
[16:45:49] <timemachine> SQLite is also very well tested so you are able to reduce the project's test exposure vs other libraries. (I worked in medical device manufacturing)
[16:46:56] <felix> SQLite itself, yes. Code using it is another story.
[16:47:25] <timemachine> heh too true.
[16:51:09] <felix> And I dunno... my other app loads 50K records from a CSV into an SQLite file so they can be browsed online.
[16:51:48] <felix> But it's slow and kind of messy to convert the data, and as it turns out, SQLite databases have 100% overhead.
[16:52:40] <felix> It occurs to me that I could have just as easily read the CSV line by line, filtering to keep only what I need and working with that on every request.
[18:26:48] -!- felix has quit [Client exited]
[23:55:50] -!- anton has quit [Connection closed]
[23:55:56] -!- anton [anton!anton@am32.org] has joined #ctrl-c