<infinisil>
Xcode *still* crashes all the time.. After 4 years since the initial stable release of Swift
<infinisil>
Swift is a pretty good language I have to say, but Xcode is pathetic
<manveru>
well, i completely understand why we don't use travis... and since there's no other suitable tool i COMPLETELY understand why we're using hydra :)
<manveru>
does that count?
<sphalerite>
<-- | grahamc (gchristens@gateway/shell/matrix.org/x-thbaeixlviyyeasx) has quit (Quit: removing from IRC because user idle on matrix for 30+ days)
<gchristensen>
bye, friend
<sphalerite>
given up on matrix, have we? :p
matthewbauer has quit [Read error: Connection reset by peer]
<joepie91>
manveru: possible, but I find Elm and Nix to look much more alike than either looks like Haskell
<joepie91>
unsure about ocaml
matthewbauer has joined #nixos-chat
atu has joined #nixos-chat
atu has quit [Ping timeout: 268 seconds]
matthewbauer has quit [Read error: Connection reset by peer]
matthewbauer has joined #nixos-chat
Sonarpulse has joined #nixos-chat
jD91mZM2 has joined #nixos-chat
matthewbauer has quit [Read error: Connection reset by peer]
matthewbauer has joined #nixos-chat
matthewbauer has quit [Read error: Connection reset by peer]
matthewbauer has joined #nixos-chat
katona has quit [Quit: Connection closed for inactivity]
matthewbauer has quit [Read error: Connection reset by peer]
matthewbauer has joined #nixos-chat
<Synthetica>
Just a thought: would it be feasible to add an option to Nix that warns when a set is declared with `rec` when it doesn't need to be?
<infinisil>
Synthetica: I don't think such language level warnings should be part of it. An external program like a linter is more fitting
<Synthetica>
Is there a linter for Nix?
<infinisil>
I don't know of one, but hnix is probably in a good enough state to create one
<infinisil>
Maybe I'll have a go at a Nix LSP server eventually, with lots of IDE like features and a linter and stuff :D
<Synthetica>
Oooh, I didn't know about hnix
<Synthetica>
Looks interesting
<infinisil>
There's been a lot of work on it recently, I may try to integrate it into my nixbot soon
<Synthetica>
Might be cool to have a nix linter bot to yell at people automatically if they messed up their spacing :P
<gchristensen>
yes
<samueldr>
not yelling, but formatting it for them :3
<infinisil>
I've been trying to look into how a Nix formatter would work using hnix
<infinisil>
But a problem I didn't see a solution to is: hnix parses the language, and the comments are *not* included in the language (which makes sense). But to pretty print something, you don't want to remove all comments
<infinisil>
If I go default.nix ->(parse) hnix ->(prettyprint) default.nix it would be stripped of all comments
<Synthetica>
Yeah, that's rather suboptimal
<Synthetica>
Ideally you'd want an extended source tree that can also can include comments, postition info, etc
<Synthetica>
(Which is way easier in a fully dependent language like Idris, but 🤷)
<samueldr>
include everything!
<samueldr>
even the type of comments
<samueldr>
e.g. /* vs. #
<Synthetica>
Yeah, sure
<Synthetica>
Why not
<samueldr>
(it's easier not to sometimes )
<Synthetica>
And just have a QuickCheck test that parse . pprint == id
<samueldr>
not obvious, but even whitespace information has to be kept in the source tree
<samueldr>
were they newlins, or spaces?
<Synthetica>
Couldn't you infer that from the position info?
<samueldr>
possibly
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined #nixos-chat
<infinisil>
Synthetica: Yeah maybe, hnix does keep position info
<infinisil>
But I'd ideally also like to reformat comments
<infinisil>
So e.g. transform a 160 line comment into 2 80 line ones
<samueldr>
that's a lot of lines :)
<ldlework>
s/line/character perhaps
<infinisil>
Or you know how when you write a git commit with multiple lines it nicely wraps around in vim, but when you change something within the text, it gets all messed up? A formatting tool could normalize the line length, shift text so it looks all neat
<infinisil>
Hmm.. I kind of have a lot of other stuff to do I consider more worthwhile
<ldlework>
fair enough
<infinisil>
Like explaining the cool Nix pattern I now have ready for showcase!
<infinisil>
So the idea is to define something like this:
<infinisil>
actions = { null = x: "is null!"; string = x: "your string is ${x}"; int = x: "number is ${toString x}"; }
<infinisil>
And then processing some input like this: actions.${builtins.typeOf input} input
<infinisil>
This essentially does pattern matching on the type of the input
<ldlework>
infinisil: neato
<ldlework>
not sure what you would use it for, but that is cool
<infinisil>
This is a nicer alternative to something like `if builtins.isNull input then "is null!" else if builtins.isString input then "your string is ${input}", ...
<infinisil>
ldlework: I actually used it for the znc module rewrite :)
<infinisil>
ldlework: You could have like a template.nix file that defines some option foo.enable along with a configuration block that gets included when you set it to true
<infinisil>
Then copy that file when you need a new option
<infinisil>
And I'm including all files in a certain directory automatically, so I don't even need to add this file to some other place to have it work
<infinisil>
See the default.nix file within it to see how it works
<ldlework>
infinisil: hmm, I'm still on the fence regarding adding some simple boolean option, and then having a fuckton of configuration be applied if it is true
<ldlework>
that isn't exactly overridable is it?
<ldlework>
like in the case of your console.nix
<infinisil>
You can set/override the console option when you need your console config. And you can still override all the set options like normal
<infinisil>
I could still do `programs.zsh.enable = mkForce false;`
<infinisil>
But if I e.g. add a server I don't even ssh into at some point, I can just `mine.console.enable = false;` and not have all those things
<infinisil>
Also, you could have an option `mine.console.minimal`, and other ones
<andi->
whats the goal? Current hardware with AMT? Any hwardware with AMT? For about 250E you get a few year old decently equipped AMT enabled notebooks
<samueldr>
a good tip: track down the manual for pre-built hardware
<samueldr>
(that's how I validated I could enable AMT on what I bought)
<gchristensen>
andi-: to try out an automatic real hardware installation test
<andi->
mhm, yeah.. would use notebooks from my stash of old devices
<samueldr>
the manual for the lenovo M82 says: • Intel Active Management Technology (AMT) (available on some models)
<samueldr>
and the CPU says vpro, so it looks like a contender
<ldlework>
Interesting indeed. simpson you seen this gist?
<simpson>
No. Interesting.
<LnL>
yeah, not sure I like everything but there are some really cool ideas in there
<ldlework>
yeah, that's my thoughts exactly
<ldlework>
I'm not finished though.
<infinisil>
I always thought of ways to make the module system better with the current Nix, but I never thought to extend the language itself for that
<infinisil>
Really nice ideas, I'm already convinced that something like this is the way forward
<ldlework>
Yeah extensible attrsets sound like a great idea.
<ldlework>
I also like the include idea, and how you don't have to have everything be a module function
disasm has quit [Ping timeout: 240 seconds]
<ldlework>
LnL are you intune with nix development at all? How likely is any of this kind of thing in the next 10 years?
disasm has joined #nixos-chat
matthewbauer has quit [Remote host closed the connection]
matthewbauer has joined #nixos-chat
matthewbauer has quit [Ping timeout: 256 seconds]
__monty__ has quit [Quit: leaving]
matthewbauer has joined #nixos-chat
<joepie91>
it's... not entirely clear to me what problem `package` solves there
<joepie91>
the gist has some interesting ideas (I've not finished reading it yet) but it seems to skip over a few steps of reasoning towards solutions :/
<ldlework>
joepie91: it allows tooling to introspect the metadata of a package without evaluating the associated derivation
<ldlework>
that's my take
<joepie91>
okay, but that same problem can be solved with `foo = { name = "bar"; build = buildable ...; }`?
<gchristensen>
ldlework: I would be surprised if this work wasn't done in the next 10 years
<joepie91>
like, 'buildable' as a "don't evaluate this unless specifically needed" kind of type I can understand
<joepie91>
I just don't see why a specific `package` type is needed, as opposed to just an attrset with a buildable attribute at a known path that can be used to trigger the build
<ldlework>
joepie91: doesn't their description of the `package` function essentially return an extendable attrset with a type attr?
<ldlework>
I'm not sure that a package /is/ more than an attrset with some specific schema, but I'm not certain
<joepie91>
but it seems to argue for the package function to be implemented in a language level?
<joepie91>
not sure what the point of that is :p
<joepie91>
like, you'd generally want to keep a language lean
* ldlework
motions his hand in the style of a Belter shrug.
<ldlework>
dunno.
<joepie91>
and provide useful primitives for 'userland' code to use and implement
<joepie91>
so I guess my argument is really "I don't see why `package` would be a primitive rather than a userland function"
<joepie91>
(incidentally, I'd like to see a better mechanism for using third-party abstractions without pulling in or relying on all of nixpkgs or some other package repo)
<joepie91>
(something that is functionally equivalent to package management for third-party libraries)
<joepie91>
gchristensen: not immediately obvious to me how that relates to what I said
<gchristensen>
it makes package descriptions pure data, converted to a derivation at the last moment
<joepie91>
still having trouble placing it in context :P
<gchristensen>
<joepie91> okay, but that same problem can be solved with `foo = { name = "bar"; build = buildable ...; }`?
<gchristensen>
it _is_ that, basically
<joepie91>
ah, right
<joepie91>
extensible attrsets make total sense to me
<joepie91>
the concept of annotations as well, although I'm not yet convinced that the syntax demonstrated there is ideal
<joepie91>
(neither the 'full' syntax nor the proposed shorter syntax)
<joepie91>
wondering if that syntax can be improved by making it postfix syntax
<joepie91>
partial ordering rather than numeric priorities is a good one also; but not sure if that requires language support
<ldlework>
it all seems like a lot of work
<joepie91>
oof, deep merges are probably not a good default for extensible attrsets
<joepie91>
the include mechanism makes me sad :|
<joepie91>
basically loses you the property of explicit references
boxofrox has quit [Ping timeout: 276 seconds]
<joepie91>
which is extremely helpful in navigating code
<joepie91>
as for plugins, I don't think that can be meaningfully solved on a language level, but will rather have to be a packaging 'interface standard'; plugins are loaded/managed differently in each application, and often require that the plugins themselves are located directly in the prefix of the application itself; if nothing else, I think Nix would benefit from a 'partial build' model of some sort, where a derivation can be easily composed of
<joepie91>
multiple other derivations, ideally without duplicating data (this is currently an issue for eg. games, where you have to pick between either duplicating large assets, or very long build times and the assets being inherently tied to the source build - ie. the reason several games are excluded from Hydra at the moment)
<joepie91>
package options - great idea; but probably generically implementable using annotations?
<joepie91>
hmm, what's the idea behind delayed functions? what problem do they solve?