adisbladis has quit [(Remote host closed the connection)]
adisbladis has joined joined #nixos-dev
MichaelRaskin has quit [(Quit: MichaelRaskin)]
goibhniu has joined joined #nixos-dev
<zimbatm>
any1 wants to co-manage the talks with me at nixcon?
<zimbatm>
presenting people and doing the time nazi
<zimbatm>
not sure if I sell this properly :p
goibhniu has quit [(Remote host closed the connection)]
goibhniu has joined joined #nixos-dev
<gchristensen>
zimbatm: what does it involve? is there like a timer-ipad timer-cards about how much is left?
<zimbatm>
yeah some sort of time-tracking system would be helpful
<zimbatm>
the role is to keep the conference on track
<zimbatm>
so it means intro-ing the people before the talk, let them speak for a while
<zimbatm>
5 minutes before the end, notify them that they need to wrap things up
<zimbatm>
then be rude and interrupt people if they're going over time
<zimbatm>
then give some time for the questions
<zimbatm>
sprinkled with some jokes if you feel like it :)
<zimbatm>
we also might have to announce stuff like when is lunch time, if there are any changes of plans, ...
<gchristensen>
I think it might be good for me, to wear down some of the stage fright before my talks :P
<zimbatm>
cool! we're all quite friendly you'll see :)
<zimbatm>
thanks a lot for helping out, I wasn't looking forward to do that for 2 days straight
<goibhniu>
on the plus side ... you get to smash the gong :D
<gchristensen>
no!
<zimbatm>
gchristensen: are you going to be at the workshop too?
<gchristensen>
mon/tue?
<goibhniu>
could you both also help out with clipping the mic to people?
<goibhniu>
... and getting people hooked up to the projector etc.
<goibhniu>
actually, I'll ask on #nixos, it would be good to have extra help there
<gchristensen>
yeah
<gchristensen>
also ... we're going to have a bunch of nixos users plugging in nixos laptops to present. how well does nixos handle this? :)
<goibhniu>
really well IME
<gchristensen>
what DE/etc?
<goibhniu>
but we'll probably need everything-to-HDMI adapters
<goibhniu>
yeah, if they're not using a DE, they'll need to know some xrandr commands
<gchristensen>
I might switch to gnome for the day :P
<goibhniu>
perhaps there's a generic enough xrandr command we can keep handy, I'm not familiar with that stuff myself
<gchristensen>
niksnut: (friendly bump to check your PMs)
<clever>
gchristensen: my nixos desktop (amd graphics) will lock xorg up solid if i unplug any hdmi display
<clever>
i have to turn it off via the gui before i unplug it
<clever>
but it also re-enables itself upon being plugged in
<gchristensen>
hilarious ...
<clever>
so its very risky to go near those cables
<goibhniu>
oh gosh
<clever>
any contact bounce when plugging in it, and it might enable itself, come unplugged, and crash
<clever>
and i think the open source driver will just crash instantly upon enabling dual-monitor setup
<goibhniu>
at the last NixCon there were hardly any issues at all
<clever>
but xfce saves the config before applying, so when you relog, it re-crashes
<goibhniu>
I think one person had trouble
<clever>
goibhniu: i'm also reminded of a defcon talk, where they where talking about pci-e DMA attacks and how thunderbolt does pcie+hdmi
<clever>
goibhniu: and at the end of the talk, they show how you can cut up a thunderbolt->hdmi adapter, and put the peices around a normal thunderbolt cable, that leads to an external pcie box
<clever>
goibhniu: so the "dumb hdmi adapter" is actualy a full thunderbolt cable, able to do dma
<clever>
oh, and they left it at the podeium lastnight, and have ram dumps from the previous presenter :P
<gchristensen>
clever: I do have a soft spot for video standards which also come with full arbitrary memory access
<clever>
gchristensen: its more that they tried to multi-purpose the port, but you can use a passive adapter to strip out just a dumb hdmi signal
<gchristensen>
I know :)
<gchristensen>
but use-case-specific cables are a good thing I think
<clever>
gchristensen: and its trivial to glue the pieces of an adapter around a cable to fool even defcon presenters
<clever>
which reminds me of something ive done before, that could help detect this
<clever>
many years ago, i had setup udev rules to run "beep" with different beep counts and freq, based on various events
<clever>
certain usb devices coming online
<clever>
the wpa coming up/down
<clever>
cron, just to give hourly chimes
<gchristensen>
til `beep`
<clever>
you could just add another, to alert you to pci devices being hot-plugged
<goibhniu>
fascinating!
<clever>
the 'beep' program will poke at the motherboard speaker
<clever>
though modern hardware may not really support it anymore
<clever>
but it gives you a lot more control then "tput bel"
<gchristensen>
gotta make a kernel driver that creates a hardware speaker and just pipes to also
<gchristensen>
gotta make a kernel driver that creates a hardware speaker and just pipes to alsa
<clever>
bel doesnt even make a noise on my machines
<clever>
gchristensen: there already are some drivers that do that
<clever>
gchristensen: i also did something else, to keep the beeps from anoying my dad
<clever>
gchristensen: i programmed the system to beep at 20khz, whenever my name was said on irc
<clever>
my dad couldnt hear it :P
<gchristensen>
>.>
<clever>
it was practically a phycic link, lol
<clever>
i can hear things nobody else can
<clever>
[root@eeepc2:~]# nix-shell -p beep
<clever>
these paths will be fetched (32.28 MiB download, 112.95 MiB unpacked):
<clever>
gchristensen: also, its strange that a normal shell depends on the bootstrap
<gchristensen>
it didn't for me
<clever>
oh, interesting, the netbook lacks any alsa devices
* clever
scratches head, its not in lspci
<gchristensen>
beep should be setuid
<clever>
yeah
<gchristensen>
man beep -> IOCTL WACKINESS is a good read
<clever>
oh, wait
clever is now known as clever-afk
__Sander__ has joined joined #nixos-dev
<__Sander__>
whoa
<__Sander__>
never underestimate the power of "separation of concerns"
<__Sander__>
just overhauled the entire internal structure of node2nix
<__Sander__>
with the new design it is a lot easier to get a grasp on the generation process
<__Sander__>
now a couple packages that always used to fail now succeed
<__Sander__>
due to some odd corner cases with bundled dependencies that I previously could not detect
<fadenb>
May I print those 6 lines, frame them and hang them in the office of some of our developers? :P
<__Sander__>
sure :D
<__Sander__>
I guess I should also this here :D
<__Sander__>
but convincing my boss to take 3 weeks restructuring one of our company projects is quite hard
<__Sander__>
hard
<__Sander__>
impossible I would say :D
<copumpkin>
niksnut: if I run a nix-instantiate with -vvvvv it tells me stats at the end with "time elapsed: 5.1884" but under the time program, total time is 52s. I'm guessing the rest is writing out .drvs or something? Feels awkwardly slow for something comparatively straightforward but I'm not sure how to track it down
goibhniu has quit [(Remote host closed the connection)]
goibhniu has joined joined #nixos-dev
<gchristensen>
there seems to be a steady-state rate of events on nixos/nixpkgs at one event every 10 seconds
jtojnar has quit [(Quit: jtojnar)]
__Sander__ has quit [(Quit: Konversation terminated!)]
zarel has joined joined #nixos-dev
Sonarpulse has joined joined #nixos-dev
Sonarpulse has quit [(Quit: Leaving)]
Sonarpulse has joined joined #nixos-dev
clever-afk is now known as clever
<clever>
gchristensen: thats a lot more then i would have expected
<gchristensen>
I might be misinterpreting the data
<gchristensen>
I'll have better info in ~a while
<clever>
copumpkin: there is also the round-trip times when it has to ask nix-daemon over the unix socket, and wait for sqlite db changes
<copumpkin>
yeah
<copumpkin>
probably not major factors though
<copumpkin>
is there a way to ask for build-use-sandbox=true, but with networking exceptions (temporarily while I develop something)?
<clever>
copumpkin: there is a relaxed mode
<copumpkin>
I thought that only affected how it behaved with individual derivations requesting exceptions
<copumpkin>
at least that's how it is on macOS
<clever>
copumpkin: yeah, if you set build-use-sandbox = relaxed, then a build can request that the sandbox just be turned off
<copumpkin>
yeah, I don't want it off
<copumpkin>
I care about local access but not networking 😇
<clever>
copumpkin: what kind of access are you doing?
<copumpkin>
a build that wants to retrieve some JVM dependencies that I haven't written a wrapper for yet
<niksnut>
Sonarpulse: sorry, not much time to review stuff this week
<Sonarpulse>
niksnut: fair enough
<clever>
copumpkin: a nar containing a single file still has a header, stating that the entry is of type file, and its length
<clever>
copumpkin: but there is no name attached to that entry
<Sonarpulse>
nixcon and the hackathon is just around the corner, I suppose
<copumpkin>
I see, makes sense
<copumpkin>
Sonarpulse: I forget, are you coming?
<Sonarpulse>
copumpkin: yes!
<copumpkin>
yay
<Sonarpulse>
niksnut: but if you feel confortable signing off on the idea, all it does is add a stdenv.cc.bintools = binutils, and use that instead of binutils directly in a bunch of places
<Sonarpulse>
since on darwin we aren't actually using real binutils
<clever>
copumpkin: also, 2017-02-22 22:23:23< clever> $ nix-store --dump a | nix-store --restore b
<clever>
copumpkin: this will copy a -> b, recursively (if needed)
<clever>
copumpkin: you can also just pipe it into hexdump -C to inspect the format, and store it to a file or pipe thru ssh to implement scp
<clever>
copumpkin: when i run this, i can see a "nix-archive-1" tag, a ( and ) marking the borders of a single entity, type=regular, contents=content
<clever>
copumpkin: each string is in the form of a length prefix, followed by the string, and some padding to ensure all fields start on an 8 byte boundary
<clever>
and pairs of strings form key=value pairs
<clever>
the contents of the file are just a single "string" that follows the contents string
<MichaelRaskin>
(while building a package with non-default builds of boost, boehmgc and clang as dependencies) I wonder if it is a good idea to have some kind of boost.static, boehmgc.static and clang.with-rtti on the top level.
<clever>
copumpkin: and if your wondering how i can read this hex, ive written a parser for nar from scratch in haskell
<copumpkin>
hah :)
<clever>
copumpkin: i originally wrote a c++ fuse layer, that would take a directory full of <hash>-<name>.nar and make it look like it had been unpacked to /nix/store/, this version used the nix library to parse the NAR's: https://github.com/cleverca22/fusenar
<clever>
copumpkin: but the problem, is that you have to parse the entire entity, including the ) at the very end of the file, to even know if the nar represents a file or directory
<clever>
so "ls -l /nix/store" winds up parsing every single byte of every single store path
<MichaelRaskin>
And then at some point module system's type system will reach Turing completeness.
<Profpatsch>
YES, EXACTLY. :DD
<gchristensen>
please god no
<Profpatsch>
MichaelRaskin: Well, it already is turing complete.
* gchristensen
cries
<Profpatsch>
We basically got dependent types already.
<Profpatsch>
In a very crude way, but yes.
<copumpkin>
types.sigma would just take an arbitrary function instead of an attrset :)
<Profpatsch>
copumpkin: Do you have an example?
<Profpatsch>
Maybe we can add it later if it’s needed.
<LnL>
gchristensen: :p
<copumpkin>
it wouldn't necessarily be enumerable
<copumpkin>
the enumerable version is types.taggedUnion
<Profpatsch>
But no idea if that can be sensibly integrated in the existing module system.
<Profpatsch>
I’m not sure with taggedUnion to be honest.
<Profpatsch>
But I know that we need it direly.
<copumpkin>
Profpatsch: it's just a trivial generalization of what you have, really. Instead of looking up the "tag" in the attrset, you'd just apply the function to it. This would let you construct as a contrived example, a listOfSize type, for example
<copumpkin>
not that it's a particularly enjoyable one :)
<Profpatsch>
I suspect that would make error messages abysmal?
<copumpkin>
it doesn't have to, but yes it could
<copumpkin>
anyway, don't let me distract you from the more useful on e
<copumpkin>
just figured it wouldn't be much more work given this
<Profpatsch>
hehe
<copumpkin>
it seems good to explicitly separate the tag name from the "body" though
<Profpatsch>
You can always insert it later and retroactively use it to implement taggedUnion.
<copumpkin>
to avoid field overlap confusion
<copumpkin>
yeah, I might do that
<copumpkin>
"teach Agda via Nix"
* copumpkin
runs
<Profpatsch>
copumpkin: What do you mean by field overlap?
<Profpatsch>
My current idea is to implement values of a taggedUnion as { tag = value; }
<copumpkin>
like if my tag is called "foo" and the submodule in question also defines foo
<clever>
Profpatsch: oh, do you know how to inspect the options tree of the module system?