aszlig has quit [Quit: Kerneling down for reboot NOW.]
aszlig has joined #nixos-dev
__Sander__ has joined #nixos-dev
aszlig has quit [Quit: brb]
pie__ has quit [Ping timeout: 265 seconds]
aszlig has joined #nixos-dev
__Sander__ has quit [Ping timeout: 245 seconds]
orivej has quit [Ping timeout: 265 seconds]
psyanticy has joined #nixos-dev
xwvvvvwx has quit [Ping timeout: 265 seconds]
__Sander__ has joined #nixos-dev
__Sander__ has quit [Ping timeout: 268 seconds]
xwvvvvwx has joined #nixos-dev
<adisbladis>
Do we have any examples of nix codebases developed outside of nixpkgs and then dumped inside?
<yorick>
adisbladis: nixos? :D
<adisbladis>
yorick: I was thinking more like 2nix implementations developed outside of nixpkgs
<adisbladis>
I know this is something flakes would be perfect for, but we're not quite there yet
<yorick>
adisbladis: they all require IFD or builtins.fetchGit so are not allowed in nixpkgs
<adisbladis>
yorick: I'm aware :) That's why I wanted some examples to see what others are doing
<yorick>
adisbladis: we just have them in separate repos and fetchGit them in when needed
<adisbladis>
yorick: Not OK for nixpkgs :)
<yorick>
adisbladis: yes, this is what flakes might help with in the future, the only thing that ever made it into nixpkgs is the go/rust fixed-output derivation thing
<yorick>
but I don't think that was developed outside of it
<adisbladis>
I'm leaning towards a make command that can output a minimal set of files and just bung them into nixpkgs
<yorick>
adisbladis: we meant to put some stuff in nixpkgs for external users only
<FRidh>
adisbladis: is your intention that it is also used in nixpkgs for applications? In that case, is there an intention to add support for package tests?
kcalvinalvnn has quit [Quit: ZNC 1.7.4 - https://znc.in]
<jtojnar>
I hate bash so much
kcalvinalvin has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
drakonis has joined #nixos-dev
drakonis has quit [Ping timeout: 265 seconds]
<worldofpeace>
Jan Tojnar: bash is soo easy to mess up
<jtojnar>
I think I like even C more
<jtojnar>
one of these days I will just leave for GuixSD
<lassulus>
I think its just guix now
<worldofpeace>
Jan Tojnar: noooo, I hope that's sarcasm 😁 I personally think nix/nixos has a lot going for it, aside from the bash.
<niksnut>
the (only) advantage of bash is that it's the one language that everybody knows
<jtojnar>
based on my experience with setup hook issues, almost nobody knows it
<jtojnar>
or they make bugs as if they did not know it
<niksnut>
yes
<worldofpeace>
Yeah, I think when the set -u changes landed it was with a lot of regressions. But there's some things we could do to alleviate that
<jtojnar>
the only reasonable way forward if we do not want to create new shell language is restricting bash even more and applying external checking like shellcheck
<jtojnar>
but bash is so terrible that checking it is hard problem in itself
ixxie has joined #nixos-dev
<adisbladis>
pythonStdenv you say? ;)
<FRidh>
jtojnar: same here, also at times consider to just avoid bash.
<adisbladis>
^ Only half-joking
<FRidh>
adisbladis: it came up a while ago as well for windows support. With structured attrs it becomes even more tempting to switch.
<jtojnar>
not something I would want stdenv to be written in
<gchristensen>
FYI: today's NixOS office hours (starting in about 3h15min) will be about how some of Nix has been written in Rust already. niksnut is coming :) more info: https://github.com/worldofpeace/events/tree/master/office-hours come chat and ask questions!
<jtojnar>
ooh, it is friday already
<qyliss>
jtojnar: not stdenv probably, but all the little shell scripts and stuff we generate for wrappers and systemd services and stuff would be much better served by execline I reckon
<Profpatsch>
jtojnar: It’s not a hack, it’s actually really elegant.
<Profpatsch>
Being a hack would mean it has failure cases outside of the happy path. execline is correct as far as I can tell.
<qyliss>
Well, the one obvious one is you can't have scripts bigger than ARGV_MAX
<qyliss>
or whatever it's called
<Profpatsch>
You don’t want to write any tight loops in it, that is true. exec has an overhead of 2–5ms
__Sander__ has quit [Quit: Konversation terminated!]
drakonis1 has joined #nixos-dev
pie_ has joined #nixos-dev
<drakonis1>
zimbatm: have the results of the london nixos hackathon gone up somewhere?
ajs124 has quit [Quit: Gateway shutdown]
ajs124 has joined #nixos-dev
gustavderdrache has joined #nixos-dev
<gchristensen>
I like that the execline page has docs for commands and an example .profile replacement (something execline isn't for, since it isn't interactive) and also 3 quines but no practical getting started docs
Synthetica has quit [Quit: Connection closed for inactivity]
<qyliss>
I've yet to see a scripting language with useful getting started docs tbh
<qyliss>
But execline could benefit from more "this is something in shell, this is it in execline"
<gchristensen>
even just an example of doing a trivial thing
<qyliss>
The execlineb page links to an example
<qyliss>
And goes over the syntax and stuff
<gchristensen>
the examples are to .profile replacements, which seem to be off topic?
<qyliss>
No, the one linked as "You can see an example of distinct execlineb components here. "
<qyliss>
Which isn't really an example, I guess, but more an explanation of the syntax
<gchristensen>
oh cool thank you
Jackneill has quit [Remote host closed the connection]
<cransom>
the one thing i gripe about execline is that the documentation says what it is, but not why it exists. what's the problem it's solving?
<cransom>
is that buried in the 'why not use /bin/sh' link?
<gchristensen>
oh wow yeah that page is good
<cransom>
reading that page, i see the point. i don't think i have a problem that it solves, but i'll tuck that away for later.
<gchristensen>
it is a bit annoying that you can't edit a long-running, long bash script while it is executing
<gchristensen>
so maybe execline fixes that
<samueldr>
gchristensen: I think it's bash 3 that re-reads the script during execution, but it keepts its byte offset, so if you prepend stuff you're in for a world of hurt
<samueldr>
or maybe it was platform-dependent
<samueldr>
not that what I said is useful, but it's a monkey paw wish :)
<gchristensen>
bash4 does too
<gchristensen>
unless you force it to read the whole thing
<jtojnar>
What version of zoom client are you running? When I try to test computer audio in the zoom client it just shows empty settings window.
<worldofpeace>
Jan Tojnar: Have never seen that before.
jtojnar_ has joined #nixos-dev
MichaelRaskin has joined #nixos-dev
tilpner has quit [Quit: tilpner]
<jtojnar>
I feel like there should be a simple GTK app for testing microphone
<MichaelRaskin>
Doesn't pavucontrol show you the input levels?
<jtojnar>
something more convenient than Audacity
<MichaelRaskin>
With alsa I just feed arecord to aplay
psyanticy has quit [Quit: Connection closed for inactivity]
<jtojnar>
the same blank settings in Ubuntu with Zoom from Flatpak
drakonis1 has quit [Ping timeout: 265 seconds]
<samueldr>
part of it is llvm_9 not cross-compiling right now
<samueldr>
oops
orivej has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis1 has quit [Ping timeout: 250 seconds]
drakonis1 has joined #nixos-dev
jtojnar_ has quit [Quit: jtojnar_]
jtojnar_ has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis1 has quit [Ping timeout: 268 seconds]
<jtojnar>
worldofpeace it looks like the settings work if I sign in
<jtojnar>
but if I sign out and restart, it is blank again
mcfrank has joined #nixos-dev
<samueldr>
am I right in understanding that when a nix build is writing to $out it's directly writing to $out, while /build is a temporary location, which could be tmpfs?
<samueldr>
(well $NIX_BUILD_TOP)
<samueldr>
(though thinking a bit more in this particular case it shouldn't change much I think)
<clever>
samueldr: also, if you make the thing in $NIX_BUILD_TOP, then cp to $out, it will be an expensive copy
<clever>
samueldr: if you instead make it directly in $out, it will be much cheaper, io-wise
<samueldr>
yeah
<samueldr>
good points
<clever>
related, if you build in $NIX_BUILD_TOP, then mv to $out, it will still be expensive
<samueldr>
(though here my example was a contrived one)
jtojnar_ has quit [Quit: jtojnar_]
<clever>
because its an inter-device move, which gets translated to cp + rm
<samueldr>
yep
jtojnar_ has joined #nixos-dev
<clever>
fetchurl also writes directly to $out
<clever>
but fetchzip calls fetchurl, and sets a flag to write the file to $NIX_BUILD_TOP instead
<clever>
because fetchzip then uses unzip,
gustavderdrache has left #nixos-dev [#nixos-dev]
jtojnar_ has quit [Client Quit]
jtojnar_ has joined #nixos-dev
jtojnar_ has quit [Read error: Connection reset by peer]
<qyliss>
The main problem execline solves for me is that it's simple, easy to understand what it's doing, and its syntax is readable
<gchristensen>
qyliss: do you have some example cases you've used it? I'd love to see some real uses :)
<qyliss>
Sure
<qyliss>
I use it for my swaybar
<qyliss>
one sec
<simpson>
qyliss: Those aren't really problems to solve, though. I could (and will!) argue that the {cake k} pair of concatenative combinators is *also* simple, easy to grok, and very readable.
<qyliss>
It is when the alternative is bash
<gchristensen>
oh cool
<qyliss>
It also can do neat things with file descriptors that bash can't
<qyliss>
I don't remember the details
<simpson>
Sure. I'm just pointing out how that's not enough. Traditionally (using evolutionary theory~) we'd have to expect either that execline can outcompete bash *in its niche*, or that bash is fatally flawed and dying due to ecosystem changes.
<simpson>
execline looks fun, for sure, but I'm weighing that against the silly-good ubiquity of bash.
<simpson>
qyliss: One thing that sticks out to me about execline's design is that it has composition-oriented commands which are designed to be used to glue together smaller commands. bash has some of this stuff, but only awkwardly; the pipe is really about it for bash.
<simpson>
Huh. Such a curious language to read. Did it start out as a flavor of TCL or something?
<qyliss>
I doubt it
<qyliss>
It's really just whitespace-seperated argv elements, except for the block syntax
<qyliss>
The blocks were added when it became apparent there was a need for them, I believe
<qyliss>
And the resulting language is just what you end up with after that
<gchristensen>
this is cool, qyliss!
<qyliss>
Bash is full of magic and misfeatures, and still manages to have missing features like piping stderr, which is just impossible I believe without combining with stdout
<gchristensen>
you can redirect thinsg to handle 3 and then redirect 3 around elsewhere
<qyliss>
Can you replace stdout with handle 3 after having redirected original stdout elsewhere?
<gchristensen>
I think so..? I don't know, that gets too magical and I don't do it
<qyliss>
exactly :P
<qyliss>
no magic in execline
<qyliss>
except blocks, maybe. but that's one thing.
<simpson>
qyliss: Another fun feature, which I don't have a good name for but I'm gonna call a "useful prefix", is that the head of the script necessarily constrains the behavior of the rest of the script. For example, in your chosen script, it looks like the script repeats forever, right? I'm deducing that from `loopwhilex` and the lack of stored state to break the loop.
<gchristensen>
this potentially fits my desire for "bash but not bash"
<qyliss>
I just like how much "not magic" it feels
<qyliss>
I know exactly what's going on here from a language point of view, because there's barely a language at all
<qyliss>
In Bash I'm constantly coming across new and surprising language "features" and weird subtleties of built-in functionality that seem designed to get me to shoot myself in the foot
<gchristensen>
okay now I'm invested enough to read the man page
<gchristensen>
like coproc, qyliss
<qyliss>
coproc?
<simpson>
qyliss: Yeah, this is why I was thinking about TCL, where this style of ad-hoc DSL is really common. What's your command do? Well, just pass it a block, and do the thing with the block, y'know?
<gchristensen>
check out the bash feature "coproc"
<gchristensen>
"$ man execline" => "No manual entry for execline" surprising!
<qyliss>
Yeah, the documentation is only HTML for some reason
drakonis has quit [Ping timeout: 252 seconds]
<qyliss>
But it's nice simple HTML that renders well in a terminal, so whatever
<qyliss>
I also like that execline doesn't trouble itself with being an interactive shell at the same time
drakonis has joined #nixos-dev
<worldofpeace>
think qyliss mentioned it could benefit from a "in shell" in "execline" compare and that is sorta like that
<qyliss>
Turns out the features that you want between scripts and interactive shells are kind of different often
<qyliss>
Oh yeah this looks pretty nice
<qyliss>
worldofpeace++
<{^_^}>
worldofpeace's karma got increased to 49
* simpson
tests rlwrap on execline
<gchristensen>
importas home HOME cd $home ls <- are env vars not availabelby default?
<qyliss>
No
<gchristensen>
graham-with-heart-eyes.jpg
<qyliss>
execline doesn't mess with the argv you've written at all (except blocks)
<simpson>
Oh, no, wait, it's not even the kind of batchy where rlwrap fixes it. Dang, that's too bad. But also understandable. Indeed, a REPL usually has different demands from a batch compiler.
<qyliss>
It doesn't even handle arguments by default
<qyliss>
When you want that you give the interpreter a flag, or call a program explicitly, and it can either substitute $0, $1, $@, etc in your argv, or just set those in the environment
<worldofpeace>
gchristensen: found the article a nice 15 min read, like a taste before you even try it.
<qyliss>
Like, set an environment variable called "@"
<qyliss>
Usually that's not what you want, but...
<qyliss>
(Usually the substitution is what you want)
<qyliss>
As a result of this, there's barely any quoting/escaping pain in execline
<qyliss>
The only things you need to escape ever are " or \
<gchristensen>
ls /nix/store/qbw7gifrahd4spjz62d15w2f2hkc7vi7-execline-2.5.1.0-bin/bin/ => :O :O :O :O
<qyliss>
Because there's a cd executable and stuff?
<gchristensen>
yeah I didn't expect it to be literally just ... execing the things.
<qyliss>
yeah
<qyliss>
It has to, because there's no interpreter running once it starts executing