Peetz0r has quit [Read error: Connection reset by peer]
Peetz0r has joined #nixos-chat
<ldlework>
lol cataclysm: dda is in nixpkgs
<ldlework>
nice
<gchristensen>
<!-- this is just hack because dl and ul aren't completely isomorphic -->
<gchristensen>
samueldr: ^
<samueldr>
this doesn't sound... right?
<samueldr>
or do you mean between each other?
<gchristensen>
dunno, here is the what that comment is on: <xsl:variable name="toc.dd.type"><xsl:choose><xsl:when test="$toc.list.type = 'dl'">dd</xsl:when><xsl:otherwise/></xsl:choose></xsl:variable>
<samueldr>
ah, so you're not the author of the comment
<gchristensen>
no :)
<samueldr>
yeah, not sure what they're going for, but I think I see it
<gchristensen>
but the xml community is closer to the fp community than I think the fp community'd like to know
<samueldr>
you'd need <ul><something></something><li></li></ul> to be equivalent
<samueldr>
if it's what I have in mind
<pie_>
whats dda
<pie_>
somehow i am not surprised <gchristensen> but the xml community is closer to the fp community than I think the fp community'd like to know
<gchristensen>
dda?
<samueldr>
[21:03:43] <ldlework> lol cataclysm: dda is in nixpkgs
<gchristensen>
ah
<pie_>
the confusion spreads
<ldlework>
cataclysm: dark days ahead is an open-world survival-sim roguelike
<ldlework>
pie_ I actually made a adventure-puzzle remake of Robots for Pyweek competetion years ago, https://i.imgur.com/8KGyISj.png
<ldlework>
you're a wizard in a robot prison and you have to find your staff, fight the warden and escape
<ldlework>
all the robot guards work like they do in robots where the only way to kill them is have them run into each other
<pie_>
haha cute
<pie_>
oh damn that actually looks pretty good
drakonis_ has joined #nixos-chat
Drakonis has quit [Ping timeout: 264 seconds]
Drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 258 seconds]
<ldlework>
just played some Quake VR
<ldlework>
phew!
<pie_>
is normal movement too slow for you now
<pie_>
do you find yourself trying to jump chasms between buildings
<ldlework>
it did take me a few attempts to perform a diagonal jump
<pie_>
is normal human field of view too small now
<drakonis1>
i remember someone making a fantasy cataclysm
jackdk has quit [Quit: Connection closed for inactivity]
pie_ has quit [Ping timeout: 252 seconds]
drakonis1 has quit [Quit: WeeChat 2.4]
jackdk has joined #nixos-chat
cjpbirkbeck has joined #nixos-chat
Drakonis has quit [Remote host closed the connection]
Myhlamaeus1 has quit [Ping timeout: 248 seconds]
cjpbirkbeck has quit [Quit: Quitting now.]
<ajs124>
nix[1947]: segfault at 28fb00002948 ip 00007f38d8ab3fa7 sp 00007ffea6bc76e0 error 4 in libnixexpr.so[7f38d8a92000+a7000
<ajs124>
my nix repl just segfaulted on me. oh well.
Myhlamaeus1 has joined #nixos-chat
<joepie91[w]>
ajs124: make sure to file a bug :)
<joepie91[w]>
is there some way to get a list of all the store paths for all of the top-level packages in nixpkgs? I want to build a full index of all files in lib/ for all (top-level) packages in nixpkgs, without needing to literally build every package
<joepie91[w]>
(afaik hydra.nixos.org provides this information via narinfo files, but only when you know the store path)
<clever>
joepie91[w]: nix-index already does that
<joepie91[w]>
clever: far as I can tell, nix-index only indexes what you have installed
<joepie91[w]>
or at least that seems to be what it's doing
<joepie91[w]>
unless I misunderstand
<clever>
joepie91[w]: nix-index will query your current nixpkgs, and then query the binary cache for every file in those storepaths
<joepie91[w]>
for the entire nixpkgs?
<clever>
yes
<joepie91[w]>
ah, I misunderstood then.
<clever>
it will even find things in the closure of packages
<joepie91[w]>
clever: okay, so, new question: how do I access the generated index from an external tool :)
<clever>
so the 32bit wine in the 64bit nixpkgs, depends on 32bit builds of some tools, and nix-index will find the 32bit versions via wine
<clever>
run nix-locate to search the index
<joepie91[w]>
I want to avoid wrapping CLI tools if at all possible
<__monty__>
So, it's not a silver bullet or anything, but I do like it.
<jD91mZM2>
Yeah, that's mostly what I'm focusing at: Do you think nixpkgs does (or will at some point) accept packages written in dhall, assuming that's actually possible (haven't read up on if dhall can create package derivations yet)
<__monty__>
Dhall-nix let's you embed dhall in nix expressions.
<__monty__>
I'm not sure what the maintainer's pov is on maintaining a chimero tbh.
<__monty__>
I'd take typed nix over dhall but dhall's my surrogate typed nix.
<jD91mZM2>
__monty__: Forgive me - what's a chimero?
<jD91mZM2>
__monty__: Still haven't heard of it haha, but I'll look it up
<joepie91[w]>
tries to automagically determine all the needed packages for a given static binary
<joepie91[w]>
with a bit of heuristics
<joepie91[w]>
cc pie_, probably of interest
<eyJhb>
joepie91[w]: the license guru
<eyJhb>
What the hell does one do, if the LICENSE template hasn't been filled? ` Copyright (C) {year} {fullname}` :p
<__monty__>
Doesn't really matter. That's not a requirement to get copyright.
<joepie91[w]>
eyJhb: explicit copyright statements like that are (in most jurisdictions) strictly informational, they have no special legal weight; so it doesn't affect the validity of the license, it just means you need to look elsewhere to figure out the copyright holder
<__monty__>
So you go by day-you-found-it to determine when it goes out of copyright.
<jD91mZM2>
joepie91[w]++ this looks awesome
<{^_^}>
joepie91[w]'s karma got increased to 2
<eyJhb>
Seems somewhat weird to copyright configuration files for packer though..
<joepie91[w]>
eyJhb: "copyrighting" isn't an active thing you do
<joepie91[w]>
a thing either has copyright or it does not
<eyJhb>
Licesing **
<joepie91[w]>
(in all the jurisdictions that you probably care about)
<eyJhb>
Or however you spell it :p
<joepie91[w]>
that's not so strange :) licensing it explicitly doesn't take a lot of effort and it avoids the need to back-and-forth over "does this technically qualify as a copyrighted work or not"
<joepie91[w]>
I'd consider it good practice on the part of a maintainer to do it
<joepie91[w]>
just because it means the user of the thing needs to worry less about the exact copyright status (assuming their usage falls within the license)
<joepie91[w]>
jD91mZM2: on the feature-creep list: trace dynamic library loads and auto-detect missing runtime-loaded libraries
<joepie91[w]>
bunch of games have a habit of this
<joepie91[w]>
and I already have a pile of heuristics in a different project to filter out the noise for that
<joepie91[w]>
current implementation just does `ldd` and calls it a day
<jD91mZM2>
joepie91[w]: I was just thinking "automatically patch any specified ELF binary RPATH and interpreter", but I guess you can do both heh
<__monty__>
joepie91[w]: Doesn't the author have copyright rather than the work?
<joepie91[w]>
__monty__: yes, but the work is the subject of the copyright
<joepie91[w]>
and it is ultimately the type of work that determines whether something qualifies for copyright or not
<joepie91[w]>
it needs to have involved creative input etc. etc.
<joepie91[w]>
how that relates to copyright expiry varies by jurisdiction
<joepie91[w]>
some go by author death, some go by age of the work, etc.
<clever>
joepie91[w]: in general, you dont need the .lib when generating a lib path for rpath
<joepie91[w]>
clever: ?
<clever>
joepie91[w]: lib.makeLibraryPath will .lib for you automatically
<joepie91[w]>
clever: unsure what this is in relation to
<clever>
so when you need libcups.so.2, just use cups, not cups.lib
<joepie91[w]>
oh, the output of the tool
<clever>
the image you linked ~10mins ago
<joepie91[w]>
it's just dumping out whatever nix-locate says lol
<joepie91[w]>
minus the `.out`
<clever>
you could strip the .lib out, since its designed to look for libraryes
<joepie91[w]>
I suppose
<clever>
maybe also generate a lib.makeLibraryPath line for the user, so they dont have to copy/paste every single attr in the list
<joepie91[w]>
I've had that break a few times though
<joepie91[w]>
clever: yeah, planning on JSON output, Nix output, and a --run flag to just insta-run the binary in an FHS with the specified libs or so
<clever>
dont even need an FHS to run it
<joepie91[w]>
some binaries do need an FHS :) so it's an easy default
<clever>
use ld.so as an interpreter (just like you run bash on a shell script) with LD_LIBRARY_PATH
<joepie91[w]>
I want something that Just Works
<clever>
joepie91[w]: there is also my patchelf util
<clever>
you could generate a variant of it as well
<clever>
if you nix-build this, you get a result symlink pointing to a bash script
<clever>
you then run ./result ./game.elf
<clever>
and it will patch it up
<clever>
the main benefit of this, is impure patching of something outside of nix, and the result symlink "depends" on the libraries, so nix cant GC them and break game.elf (which nix isnt aware of)
<__monty__>
joepie91[w]: And you have to follow the rules in your jurisdiction or the copyright holder's?
<joepie91[w]>
__monty__: neither; you have to follow the rules in the jurisdiction where you publish a thing
<joepie91[w]>
that gets murky pretty quickly when the internet is involved :)
<joepie91[w]>
clever: I don't want to actually mutate anything, and that still wouldn't handle things that need an FHS
<joepie91[w]>
my object here is a low-effort, best-effort, just-works tool; not an optimally frugal or reliable one
<joepie91[w]>
objective*
<qyliss>
re dhall: it can generate derivations, but then you need to use IFD, so not allowed in nixpkgs AAUI
<qyliss>
It does look awesome though.
<Taneb>
qyliss: at least until someone implements a dhall interpreter in pure nix ;)
<qyliss>
I think niksnut would have something to say about that lol
<ar>
is there a comparision between dhall and jsonnet?
<ar>
because the goal between them seem to overlap somewhat
<__monty__>
ar: Mainly OOP v. functional I guess.
<__monty__>
But dhall's a total language. So if something typechecks it's guaranteed not to infinite loop.
<joepie91[w]>
whee, made my tool way faster by batching all queries into a single `nix-locate` call via regex
<joepie91[w]>
now it no longer takes 20 seconds to find deps :p
<__monty__>
Are you sure you didn't make it 20x more fragile? : )
<joepie91[w]>
reasonably sure
<eyJhb>
Well... Didn't know it mattered for sed if you use `sed -Ei` or `sed -iE`.. SHouldn't they work the same?
<eyJhb>
Ah. I see, it will use E as suffix then..
<eyJhb>
Might be a lot safer doing `sed -E -i`
<__monty__>
Yeah, kinda non-standard flag handling. LoD rears its ugly head again.
<__monty__>
joepie91[w]: Law of Demeter, Principle of Least Surprise.
<joepie91[w]>
oh
<joepie91[w]>
wasn't familiar with the "Law of Demeter" name
<__monty__>
I like the irony : )
<joepie91[w]>
lol
<eyJhb>
joepie91[w]: do it in go and see how fast that is
<joepie91[w]>
eyJhb: equally fast
<joepie91[w]>
because almost all of the time is spent waiting for nix-locate
<joepie91[w]>
which is in Rust
<joepie91[w]>
so :P
<eyJhb>
Damn
<eyJhb>
Do it in Go anyways! avD
<joepie91[w]>
(the idea that JS is "slow" is, generally speaking, wrong)
<eyJhb>
:D *
<joepie91[w]>
yeah, nope :)
<eyJhb>
Wondering now, is JS faster than Python?
<joepie91[w]>
eyJhb: taken literally, that is an unanswerable question
<joepie91[w]>
since the language can, at most, define the performance ceiling
<joepie91[w]>
and the real-world performance is determined by the runtime, not the language
<joepie91[w]>
but if you're talking about V8 versus reference implementation for Python: yes, JS is much much faster
<joepie91[w]>
it'
<joepie91[w]>
oops
<joepie91[w]>
it's not so clear when you start looking at other Python implementations *
<eyJhb>
Basically remember back to running a clean default apt install python, took around 2 minutes to do some sorting with a awfull algorithm. Did the same awful algo in Go, took around 1s
<__monty__>
JS VMs have seen some crazy optimization work.
<joepie91[w]>
^
<joepie91[w]>
eyJhb: JS performance will likely be closer to Go than to Python
<joepie91[w]>
(have not tested; this is a general guess based on performance profiles I've observed)
<joepie91[w]>
assuming a sensible implementation of the awful algorithm :)
<joepie91[w]>
if you do dumb things that break the optimizer, it will of course be much slower
<__monty__>
eyJhb: There's pathological problems that pypy would be much faster at than go btw. Comparing performance on random problems doesn't really reveal much.
<joepie91[w]>
probably the most common performance fuckup in JS is passing a lot of differently-shaped types into the same function
<joepie91[w]>
well, okay, that is not true
<joepie91[w]>
that's probably the second most common fuckup
<joepie91[w]>
the most common one being lots of allocations in a hot path
<joepie91[w]>
anyway, if you pass a lot of differently-shaped stuff into a function, the optimizer is gonna go ¯_(ツ)_/¯ and just stop bothering
<__monty__>
¯\_(ツ)_/¯
<__monty__>
ftfy ; )
<joepie91[w]>
markdown parser ate the backslash, I think
<__monty__>
Didn't know markdown had escapes.
<__monty__>
Maybe it's just the client? I know irssi munches it.
<joepie91[w]>
__monty__: markdown definitely has escapes
<joepie91[w]>
or well, most variants of it do :)
<joepie91[w]>
for stuff like explicit asterisks
<joepie91[w]>
also in some variants for explicit newlines
<__monty__>
It's in the original spec. Guess I just haven't needed them yet.
Arahael has quit [Ping timeout: 245 seconds]
Arahael has joined #nixos-chat
lopsided98 has quit [Remote host closed the connection]
<kraem>
is it a good idea answering your own questions in the irc channel if someone else googles the same issue and finds the irc log or is it considered spam?
<gchristensen>
yes please
<__monty__>
It's mostly nice as a ping to people that you no longer need help. And to enable them to show you a better/alternative solution.
<joepie91[w]>
well, after a slight hack, my --run feature seems to work!
<joepie91[w]>
anybody have suggestions for binaries to test with this tool? :P
<joepie91[w]>
(requirement for now: all necessary libraries must be included in the `ldd` output, not dynamically loaded at runtime)
<gchristensen>
oxygen
<gchristensen>
ehh that is a trap actually :P
<__monty__>
joepie91[w]: Yes, I have this ransonmware binary over here I'd love for you to test ; )
<joepie91[w]>
but I haven't implemented interactive detection yet
<joepie91[w]>
that involves a bit more complexity to do neatly
<kraem>
gchristensen, __monty__ cool, said and done.
<joepie91[w]>
headless X server and everything
<joepie91[w]>
hence why all libraries currently need to be declared in the `ldd` output :)
<joepie91[w]>
because that interactive logic is still missing and I don't feel like adding it today
<gchristensen>
ahhh nice
<joepie91[w]>
gchristensen: anyway, my plan for interactive stuff is to basically launch the binary in a headless X context, and see whether it survives for 5 seconds or so without crashing
<joepie91[w]>
if it crashes, it would extract the missing library from LD_DEBUG
<joepie91[w]>
rinse repeat until it survives for 5 seconds
<joepie91[w]>
at which point it'd conclude "this is all that you need"
<joepie91[w]>
(and it'd kill the binary itself)
<joepie91[w]>
it's a bit rudimentary, but I expect it to work for most cases
<gchristensen>
LD_PRELOAD to detect openat attempts for .so's and dynamically bring them in to scope (lol)
<joepie91[w]>
gchristensen: there is, in fact, a limit to my insanity :D
<MichaelRaskin>
So, just a FUSE filesystem?
jackdk has quit [Quit: Connection closed for inactivity]
<joepie91[w]>
lol
<eyJhb>
Is it possible to do something like outputdir/{file1,file2}.sh in a makefile prerequisites?
<eyJhb>
Nvm :)
<joepie91[w]>
what's up with the steam package in nixpkgs being marked as broken?
<gchristensen>
using java-ey IDE programs reminds me why people like massive monitors
<MichaelRaskin>
joepie91: I think steam is not marked broken, just with a broken license?
<ar>
gchristensen: i like my 27" screens even without having to use IDEs
<joepie91[w]>
MichaelRaskin: error: Package ‘steam’ in /nix/store/44an78w2n810g0011r5pfpf6j5ll4nsj-nixos-19.03.173052.aef662d2eb5/nixos/pkgs/games/steam/steam.nix:33 is marked as broken, refusing to evaluate.
<gchristensen>
ar: me too, but I set the resolutoin such that I don't get much more real estate
<ar>
well, i use them at their native 3840x2160
<gchristensen>
ouch
<gchristensen>
your eyes :P
<MichaelRaskin>
joepie91: Ah, release branch
<joepie91[w]>
well, yes :P
Drakonis has joined #nixos-chat
andi- has quit [Quit: WeeChat 2.5]
andi- has joined #nixos-chat
<__monty__>
qyliss: Why does dhall necessitate IFD btw?
<MichaelRaskin>
Because a converter more or less exists already, but adding it to Nix upstream code seems unlikely?
<__monty__>
Oh, I thought dhallToNix simply turned some dhall into a nix expression but it uses import.
<__monty__>
So dhallToNix being in nixpkgs doesn't mean you can use it in nixpkgs expressions?
<qyliss>
Correct
<manveru>
is dhall-to-nix still broken?
<manveru>
looks like it
<__monty__>
And a dhall to nix compiler/interpreter written in nix would probably not be accepted into nixpkgs?
<manveru>
well... writing that in nix would be impressive already :D
<gchristensen>
probably not, __monty__
<manveru>
the only thing i could think of is to have a nix plugin for it, but then you'd have to write it in C++ or rust i think?
<__monty__>
Dammit, how am I supposed to take over the world if everyone's gonna dhall-block me? : )
<manveru>
lol
<manveru>
just fix dhall-nix derivation first, please :D
<manveru>
it's been broken for months again
<__monty__>
I'm not sure I'll end up using it though. Nix derivation I want to work on is intended to go in nixpkgs.
<manveru>
why did you want to use dhall?
<__monty__>
Because I like the type system safety net.
<__monty__>
Don't worry. There *are* no syntactic conventions. You get carte blanche!
<gchristensen>
hrnm?
<__monty__>
gchristensen: Didn't the screenshot show a blank section?
<gchristensen>
ah
<gchristensen>
it is because I deleted all the content
<__monty__>
Woops.
<gchristensen>
on purpose
<__monty__>
Oh, blank slate?
<gchristensen>
nah, I'm trying to debug some XSLT and deleting everything which is unrelated to the bug makes it a lot easier to step through the execution
<samueldr>
maybe it shouldn't split that deep, gchristensen :)
<gchristensen>
yeah, maybe not
<samueldr>
tough question: can this be tweaked by chapter?
<gchristensen>
but also there are a *lot* of attrset functions, so maybe it should?
<samueldr>
though it's nice to scroll around those instead of page through
<gchristensen>
samueldr: dunno. not actually interested in spending too much time on what gets its own page just yet, as there is a lot of work to be done before that really matters :P for example, a lot of pages don't get a ToC at all: http://gsc.io/search-docs/ch08s01s02s03.html while others do: http://gsc.io/search-docs/ch06.html
<samueldr>
oh sure, that's a thing to look at after the thing works :)
<gchristensen>
it seems that the chunker and the tocer have, annoyingly, very slightly different behavior
<gchristensen>
okay! every page has a ToC now!
<MichaelRaskin>
Is it me, or is there more core Nix* development discussed here than in #nixos-dev ?
<gchristensen>
I'll move :P
<MichaelRaskin>
I am not sure that would be enough to change the sign of the inequality!
<MichaelRaskin>
So we could just as well reflect on what is going on…
<gchristensen>
sure
<MichaelRaskin>
I mean, there has to be _some_ reason, right?
<samueldr>
I think it's more freeing to "just show things" here
<MichaelRaskin>
I am torn between soliciting ideas about a clear intent for #nixos-dev channel and saying «so #nixos-dev effectively is silent, very well, less fragmentation»
<samueldr>
nixos-dev for committed, involved discussion about the development, nixos-chat as the general discussion without commitment, at least to me
<samueldr>
and nixos for the usual nixos discussion and support
__monty__ has quit [Ping timeout: 248 seconds]
pie__ has joined #nixos-chat
<eyJhb>
The ToC is like.. 1/5 of the page
<gchristensen>
yep!
<gchristensen>
in some cases it is about 99%
<eyJhb>
I am dreading when I need to start doing some proper documentation...
<eyJhb>
But first things first, at big rewrite :|
__monty__ has joined #nixos-chat
pie__ has quit [Ping timeout: 252 seconds]
Miyu-chan has quit [Ping timeout: 272 seconds]
__monty__ has quit [Ping timeout: 245 seconds]
__monty__ has joined #nixos-chat
jackdk has joined #nixos-chat
__monty__ has quit [Quit: leaving]
noonien has quit [Quit: Connection closed for inactivity]
<elvishjerricco>
Is there anything like vnstat that tells you how much bandwidth each process uses? iOS tells you how much of your network usage is from each app for the past week or month and it's really nice.
pie__ has joined #nixos-chat
pie__ has quit [Ping timeout: 250 seconds]
<elvishjerricco>
Nethogs would do the trick if it had a daemon mode, saved data to a db, and let you select a time window to monitor.
<ashkitten>
thinking about how much i'd love for applications to each have their own path to store mutable data, and not just put it anywhere they'd like relative to my home directory
<ashkitten>
imagine if nixos only had 4 top-level directories: /nix, /config, /data, and /home
<gchristensen>
my root FS has only /boot /nix /home and /private at boot, which is pretty close
<elvishjerricco>
ashkitten: One day I'm gonna figure out how to mount everything I can as readonly :P
<ashkitten>
each program would get a path inside /data to store whatever
<samueldr>
add -o ro to mount :^)
<samueldr>
(oh, you wanted it to be useful too?)
<ashkitten>
it'd be great
<samueldr>
one of the issues here is "define program"
<elvishjerricco>
This is, regrettably, one area where iOS is a lot better than most OSes
<ashkitten>
hell, for "legacy" apps we could run it in a chroot and bind-mount the data dir where it expects to store stuff
<samueldr>
a store path with a bin folder with multiple binaries, are they all the same program?
<samueldr>
multiple store paths from a program and its plugins, are they the same program?
<samueldr>
:)
<samueldr>
if program A calls program B, with bind chroot shenanigans, would B store its data in A?
<ashkitten>
you're right, but if we had defined that 30 years ago we wouldn't have this issue
<gchristensen>
ashkitten: please make this happen
<gchristensen>
perhaps also coordinate with qyliss on spectrum-os.org
<elvishjerricco>
As much as I dislike container stuff like Docker, the central premise that each unit of software should have its own sandbox is really good.
<ashkitten>
it's ofc not perfect and seems to be more of a proof of concept but it looks neat
<gchristensen>
ashkitten: you can't distract me right now with something so tantalizing!
<ashkitten>
what are you doing? :)
<gchristensen>
making the docs searchable
<ashkitten>
ooh
<elvishjerricco>
ashkitten: I think that page is suggesting that plash works by modifying libc, and wee bit of linux namespacing. Why wouldn't it just use namespaces for everything? Libc is easily circumvented