| 18 Jul 2025 |
msgilligan | You don't have to be calling native code to use this feature, you can just use it for memory optimization if you want/need. | 00:22:04 |
msgilligan | Thanks, I added a comment to my home.nix reminding me to migrate from programs.neovim to programs.nixvim! | 01:06:35 |
Infinidoge 🏳️⚧️ | Enjoy o7 | 01:07:06 |
Infinidoge 🏳️⚧️ | It's helped me a lot, as otherwise I would spent far too much time tinkering with Neovim to figure out the LSPs | 01:07:25 |
msgilligan | My exact worry. I don't have much invested in my current configuration so it will be easy to switch. | 01:08:18 |
samasaur | i find that the native way to do it is not that hard | 01:08:50 |
samasaur | like it's really wonky but it's mostly just boilerplate that you copy once | 01:09:03 |
samasaur | though i haven't actually tried nixvim | 01:09:11 |
Infinidoge 🏳️⚧️ | * It's helped me a lot, as otherwise I would spend far too much time tinkering with Neovim to figure out the LSPs | 01:09:17 |
samasaur | and also i learned last week that the way you set up LSPs has changed in 0.11 out from under me and I still haven't gotten around to swapping over | 01:09:31 |
samasaur | hmm maybe i should try nixvim | 01:09:45 |
Infinidoge 🏳️⚧️ | My Nixvim-based config for reference: https://github.com/Infinidoge/universe/blob/master/users/modules/global/neovim.nix | 01:10:06 |
| 19 Jul 2025 |
| vog joined the room. | 20:04:37 |
vog | I'd like to run keycloak with PostgreSQL connected via unix sockets. For that purpose, I'd like to add junixsocket to Nix, as I assume this is useful for other Java packages as well: https://github.com/kohlschutter/junixsocket | 20:07:13 |
vog | However, I'm a bit confused on how Java packages are meant to be added to Nixpkgs: | 20:08:51 |
vog |
- Looking at libraries like jogl, but also keycloak plugins, it seems to including binary releases is preferred over building Java libraries from source?
| 20:08:53 |
vog | *
- Looking at libraries like jogl, but also keycloak plugins, it seems to me that including binary releases is preferred over building Java libraries from source?
| 20:09:19 |
msgilligan | Why not just use JEP 380: https://openjdk.org/jeps/380 (it's in JDK 16 and later) | 20:09:22 |
msgilligan | * Why not just use JEP 380? https://openjdk.org/jeps/380 (it's in JDK 16 and later) | 20:09:54 |
emily | building Java libraries from source is hard (because binary .jars are what people push to Maven or whatever) | 20:09:54 |
vog | Is that supported by postgresql_jdbc, and if so, which JDBC URL should I form? | 20:10:07 |
emily | it's not really that useful when a "source build" has all its dependencies precompiled | 20:10:12 |
emily | from-scratch source builds for entire Java dep trees would be cool and there is stuff in Gradle that could make that work, but it's not where the ecosystem is by default | 20:10:30 |
vog | Ok, no problem for me, actually this simplifies my packaging work. ;-) | 20:11:21 |
msgilligan | I would like to see bootstrappable Java libraries/jars someday, but emily is right, it's not currently practical. | 20:11:58 |
msgilligan | I don't know, but I took a quick look at the Keycloak website and it is recommending (requiring?) JDK 21, so you shouldn't have to use a 3rd-party (possibly native) library for the raw socket access. I don't know whether the JDBCs drivers are using JEP 380 yet. | 20:14:11 |
msgilligan | * I don't know, but I took a quick look at the Keycloak website and it is recommending (requiring?) JDK 21, so you shouldn't have to use a 3rd-party (possibly native) library for the raw socket access. I don't know whether the JDBC drivers are using JEP 380 yet. | 20:15:14 |
vog | Well, the PostgreSQL JDBC driver explicitly recommends using junixsocket: https://jdbc.postgresql.org/documentation/use/#unix-sockets | 20:15:41 |
vog | (and doesn't mention JEP 380 at all) | 20:15:56 |
vog | This article explains everything quite in detail: https://www.morling.dev/blog/talking-to-postgres-through-java-16-unix-domain-socket-channels/ | 20:22:16 |