• joepie91
        Profpatsch: also, I'd argue that a good layout system would need to be based on not just flexbox but also CSS grids, and that a few performance issues with that remain to be solved
      • namely, relatively speaking, layouting the way a browser does it is pretty expensive
      • Profpatsch
        joepie91: Did you know that it’s hard even for Qt to render long lists?
      • NOTICE: [nixpkgs] @proteansec opened pull request #37365 → bacula: 5.2.13 -> 9.0.6 → https://git.io/vxsIM
      • joepie91
        so ideally you'd want some small simplifications to take off the edge of the layout calculations
      • Profpatsch
        The Tomahawk people had lots of problems with long playlists afaik.
      • joepie91
        Profpatsch: oh yeah, I'm sure. it still boggles my mind how nobody seems to have optimized large elements beyond a few text editors and a few websites
      • it's *not that difficult*
      • Profpatsch
        When you do arbitrary mutations it pretty much is.
      • joepie91
        a bit of viewport magic and cheating on size estimations should be enough to implement it performantly
      • Profpatsch: 'perfect is the enemy of good' applies here :P
      • Profpatsch
        Well, it’ll be really annoying if your users click the wrong elements all the time because your estimations are off by a few pixels.
      • joepie91
        Profpatsch: example: if you're displaying a long list of items, then you don't want to actually calculate the height of each element in the list, but rather just the elements that are visible and those that can be scrolled to quickly; and then you want to make a simplified estimate of the total length of the entire list without actually calculating every other element
      • Profpatsch: and if your scrollbar position ends up being off in such a way that the last pixel takes three scrolls to get to rather than two, well, oh well
      • testuser has quit
      • once you implement simplifications like that, you can get it way more efficient, loading data and calculating stuff as it's accessed
      • (I did a PoC of this a Long Time ago in HTML/CSS/JS)
      • Profpatsch
        Better give your programmers an infinite list abstraction over that.
      • joepie91
        (with a height and translation hack to make the positioning work out)
      • Profpatsch
        Or you are in for a fun time.
      • joepie91
        Profpatsch: how do you mean?
      • Profpatsch
        Well, your model should not suffer from view optimizations down the line.
      • I’d argue today’s paging of REST responses is a pretty clear sign of not enough abstraction.
      • flugsio has quit
      • Or even: a leaky one.
      • joepie91
        oh, in that sense
      • sec
      • Profpatsch: excellent read on this topic: https://tumbledry.org/2011/05/12/screw_hashbang...
      • PeterRomfeld[m] has quit
      • ConorCurry[m] has quit
      • Obscurity[m] has quit
      • Profpatsch
        Fuck me, you get a network request between every few elements.
      • That’s the ultimate IO trap.
      • M-Dan has quit
      • But then again, POSIX has the same problem: man 2 recv
      • joepie91
        I mean, there's necessarily going to be a tradeoff here
      • either you send a lot of data or you send little data a lot
      • inherent tradeoff, can't really solve that, no matter the situation
      • other than trying to do your best guess at estimating the optimal amount of data to be sent
      • Profpatsch
        Hm, it’s really the same problem as with other protocols.
      • midchildan[m] has quit
      • Can send length first of course.
      • joepie91
        it applies even for things that don't go over the network
      • see eg. IPC
      • jluttine joined the channel
      • M-Dan joined the channel
      • Profpatsch
        Yeah, as I said recv from socket basically
      • joepie91
        hell, 0mq has some pretty bizarre batching logic
      • to work around this problem
      • and even that is, afaik, just twiddling the sliders until it performs well
      • weirdly, 0mq's batching logic apparently works *so* well that neither sending raw UDP packets nor writing your own batching logic is likely to outperform 0mq in sheer throughput
      • Neo-- joined the channel
      • I should really read its implementation some day :P
      • trikl[m] has quit
      • paraseba joined the channel
      • Obscurity[m] joined the channel
      • PeterRomfeld[m] joined the channel
      • dkibi joined the channel
      • AllanDaemon has quit
      • trikl[m] joined the channel
      • flugsio joined the channel
      • leat has quit
      • tfc[m]
        hi there. does anyone have an idea regarding this issue description? https://github.com/edolstra/nix-serve/issues/9
      • jensens joined the channel
      • AllanDaemon joined the channel
      • knupfer joined the channel
      • ConorCurry[m] joined the channel
      • kriztw_ is now known as kriztw
      • rardiol1 joined the channel
      • clefru joined the channel
      • midchildan[m] joined the channel
      • Fare has quit
      • NOTICE: [nixpkgs] @dotlambda merged pull request #37155 → archivemount: 0.8.7 -> 0.8.9 → https://git.io/vxq2r
      • NOTICE: [nixpkgs] @dotlambda pushed 2 commits to master: https://git.io/vxstM
      • NOTICE: → 8cf0f49e by @ryantm: archivemount: 0.8.7 -> 0.8.9
      • NOTICE: → b451519e by @dotlambda: Merge pull request #37155 from ryantm/auto-update/archivemount
      • NOTICE: [nixpkgs] @romildo opened pull request #37367 → enlightenment: 0.22.1 -> 0.22.2 → https://git.io/vxsty
      • coot has quit
      • leat joined the channel
      • MercurialAlchemi has quit
      • MercurialAlchemi joined the channel
      • civodul has quit
      • kerrhau has quit
      • civodul` joined the channel
      • woffs
        tfc[m]: I get the same here and am now running the nixos-17.09 version instead, which works
      • tfc[m]
        woffs: i am not running nixos on both machines. it's just a nix 2.0 single user installation
      • civodul` is now known as civodul
      • larsvm joined the channel
      • woffs: i would be happy to know how to debug what's wrong with my keys so i can get a step further. do you have any idea?
      • NOTICE: [nixpkgs] @jokogr opened pull request #37368 → Minor JetBrains products update → https://git.io/vxsY2
      • NOTICE: [nixpkgs] @jokogr closed pull request #37368 → Minor JetBrains products update → https://git.io/vxsY2
      • NOTICE: [nixpkgs] @dotlambda merged pull request #35056 → pythonPackages.requests-unixsocket: init at 0.1.5 → https://git.io/vACxW
      • NOTICE: [nixpkgs] @dotlambda pushed 2 commits to master: https://git.io/vxsYS
      • NOTICE: → 04c37137 by @catern: pythonPackages.requests-unixsocket: init at 0.1.5
      • NOTICE: → 196b4863 by @dotlambda: Merge pull request #35056 from catern/master
      • nschoe joined the channel
      • rardiol1 has left the channel
      • pkill9 has quit
      • NOTICE: [nixops] @AmineChikhaoui pushed to master « be more consistent with EC2 backend: don't raise exceptions if the user »: https://git.io/vxsOB
      • nuncanada joined the channel
      • periklis has quit
      • mudri has quit
      • woffs
        tfc[m]: no idea yet. Just added nixos-17.09 as channel and run nix-serve with that channel with something like nix-shell -I nixpkgs=$HOME/.nix-defexpr/channels/nixos1709 -p nix-serve
      • tfc[m]
        woffs: ok this is completely weird. i reinstalled `nix-serve` and now it accepts the secret key on the server side. client side still does not accepts the signatures, but this looks like a different kind of errir. i am closing the old and opening a new ticket.
      • woffs
        Something different: how to run local nixos tests? I try to fix and debug quagga with "nix-build nixos/tests/quagga.nix" but it fails and "nixos/tests/networking.nix" also fails and I guess I do something wrong or an i3 is not enough to run those tests even with prolonged timeouts
      • clever
        woffs: they are attributes of nixos/release.nix
      • NOTICE: [nixpkgs] @matthewbauer pushed 5 commits to master: https://git.io/vxs30
      • NOTICE: → 4cc1cd85 by @matthewbauer: cmake-2.8: supports darwin
      • NOTICE: → 80b8caf4 by @matthewbauer: opencolorio: fix on darwin
      • NOTICE: → 397532de by @matthewbauer: openimageio: supports darwin
      • zzamboni has quit
      • zzamboni joined the channel
      • kerrhau joined the channel
      • kerrhau has quit
      • kerrhau joined the channel
      • unlmtd
        neovim looks for every plugin in every individual store path ... the start time is horrible. is that the expected behavior?
      • im talking 3-5 seconds sometimes
      • testuser joined the channel
      • kerrhau has quit