<ekleog>
(that's not specific to JS, though, but I'd guess JS JITs are among the most optimized ones -- never worked on any other interpreted language JIT, though)
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
infinisil has joined #nixos-chat
<sphalerite>
I found a website that explains how netboot works about a year ago and can't find it again
<sphalerite>
does anyone know where it might be?
<joepie91>
I feel like that's the kind of thing clever might know
<sphalerite>
clever: *summon*
<sphalerite>
damn it didn't work
<joepie91>
lol
<joepie91>
patience, young padawan
<joepie91>
sphalerite: more seriously, are you looking for any accessible explanation, or the specific one you remember?
<sphalerite>
I suppose any accessible explanation will do
<gchristensen>
netboot is in the motherboard, where the firmware looks for a dhcp server which is offering a file over usually tftp. the firmware fetches it and exec's it. usually that file it first fetches is iPXE which is faster at fetching big images.
<sphalerite>
gchristensen: I want something fairly comprehensive that I can send to a guy who's taking over the strathtech infra from me :p
<gchristensen>
how much do they need to know?
<sphalerite>
how the whole thing works. I could explain it myself, but I'd much rather just link them some docs where somebody's gone to all the effort already :')
<sphalerite>
gchristensen: networkboot.org, listed there, is what I was looking for!
<sphalerite>
great
<infinisil>
Damnit, I think I'll have to run emacs in nix-shell
<infinisil>
I can't see any other way to get HIE to work with cabal projects
<gchristensen>
have you tried emacs' direnv support?
<gchristensen>
direnv is the go-fast button for Nix integration
* infinisil
checks that out
<joepie91>
ekleog: having read through that slidedeck (which isn't easy without the accompanying presentation...) I can't say that I'm really convinced; that slide deck seems to effectively work out to "optimizers are complex and allow for new kinds of bugs" which... is not exactly news? and not exclusive to JITs nor to JS
<infinisil>
gchristensen: Oh that looks neat, I'll try that thanks
<joepie91>
that's not to say that the slide deck itself isn't useful/interesting, but it doesn't seem to support the claim you're deriving from it :P
<infinisil>
Wanted to try out direnv before actually
<gchristensen>
I don't love it in my normal terminal
<gchristensen>
but I think I could find a way to :)
<infinisil>
I'm a bit annoyed that I have to use bash with nix-shell to get the correct vars, direnv apparently can make it be zsh
<gchristensen>
yes
<joepie91>
ekleog: like, it's generally true that the more complex the runtime/interpreter/compiler/whatever, the more chance there is of bugs there; however, moving complexity *to* the runtime is also often a good way to remove complexity from application, and the more centralized a bug is, the better... because it means it can be solved at once for everybody (related: waterbed theory)
<joepie91>
from application code *
<ekleog>
joepie91: the difference with JITs is that they optimize untrusted code :)
<joepie91>
there are plenty of language-level sandboxing mechanisms that are in the exact same position
<joepie91>
for many languages
<simpson>
ekleog: It depends on the style of JIT. The JIT toolkits, like RPython, trace only runtime actions, and not user-level actions.
<ekleog>
and usual compilers just compile language that have builtins like system() so it's trusted code anyway
<joepie91>
plus, even if this *were* true, it'd only apply in untrusted environments (eg. browsers); it'd not be a point against the language as a whole
<simpson>
V8 is a big pile of C++ with completely bespoke JIT. It shouldn't be surprising that there's bugs; it wasn't designed to be correct-by-construction.
<ekleog>
joepie91: I'm not saying it's a point against the language as a whole :) was sending that just to show the other side from the one of the language user, and the generated code is just a mess by necessity due to the language definition :)
<ekleog>
(like, proxies for .prototype, [0] or the like)
<joepie91>
ekleog: I'm aware of the other side :P I just don't consider it a reason to 'hate JS'
<ekleog>
simpson: I don't know V8 internals, but my little experience of SpiderMonkey is not much better, and JSC is attacked by the said slide deck :)
<ekleog>
I hate JS as a JS implementor :p
<ekleog>
like, it's imposing stupid constraints
<gchristensen>
any of y'all taken a look at HolyJIT?
<ekleog>
that ban swathes of optimizations
<ekleog>
gchristensen: if that could ever come true… :D
<simpson>
ekleog: Sure. At the same time, this is a tragedy that could have been avoided had people sat up and listened over a decade ago to the correct-by-construction crowd.
<simpson>
gchristensen: Yes. Waiting for Rust to become stable enough that HolyJIT works OOTB.
<gchristensen>
on TravisCI you can now specify a matrix of Nix versions to test against
<ekleog>
simpson: I would think having a language definition that's less actively trying to prevent optimizations with people that expect JS to run as fast as C would also have helped :)
<simpson>
ekleog: It's true, JS wasn't designed to go fast, but that's not even close to the least of its problems. As has happened before, the popularity of JS has little to do with its utter lack of Quality as a language.
<joepie91>
gchristensen: excellent, that looks precisely like what I was looking for
<gchristensen>
oh?
<joepie91>
gchristensen: )HolyJIT)
<joepie91>
(*
<gchristensen>
oh!
* joepie91
flips paren
<gchristensen>
I was going to say ... seems very niche to actually want to test some stuff against a matrix of nix versions :)
<ekleog>
simpson: can't parse
<joepie91>
haha
<ekleog>
HolyJIT will be life, HolyJIT will be love
<ekleog>
All will hail HolyJIT
<simpson>
ekleog: JS is shit but it's not a problem or failure, just business as usual.
<ekleog>
oh yeah :)
<ekleog>
it's all a matter of network effect, the more developers the more libraries, thus the more users
<ekleog>
hence everyone has to maintain FFI to C for systems programming, and has to compile to JS for web programming
<simpson>
Maybe. Monte has no FFI and doesn't compile to JS, but we're looking at maybe targeting WASM instead.
<simpson>
On one hand, the endless libraries of the commons are available. OTOH, they're overwhelmingly shit.
<ekleog>
yeah, WASM is an alternative nowadays, but you still have to FFI to JS for accessing the DOM :)
<ekleog>
(well, until maybe the WASM group will manage to make a WASM-native DOM manipulator?)
<simpson>
With WASM-GC, arbitrary native capabilities should become available.
<ekleog>
(should rebase that btw, the dependency has been merged)
<ekleog>
ooooh garbage-collector extension :(
<simpson>
Don't be sad. You want this; you just don't know that you want it yet.
<ekleog>
Nah, I know I don't want this, because I'm on the implementing side again :p
<ekleog>
and I really, really don't want to write a GC (and we're not supporting JS so we don't have one anyway)
<simpson>
Okay, well, it's an important building block for capabilities.
<simpson>
Just grab a GC off the shelf. There's umpteen of them. I mean, maybe there aren't any good ones for Rust yet because Rust is still so immature, but eventually. And in the meantime there's boxing with Rc.
<ekleog>
errrhm I'm pretty sure I can't grab a GC, then my constraints are… peculiar :)
<ekleog>
(and it's not Rust, unfortunately)
<ekleog>
like, not having native 32-bit integer support makes supporting even a subset of WASM a fun challenge
jtojnar has quit [Quit: jtojnar]
<ekleog>
so a GC… will most likely stay out of the realm of what will be done, but so long as language allow compiling to WASM\{GC}, it's OK :)
<simpson>
You could read the link I dropped. "Pay as you go; in particular, no effect on code not using GC"
<ekleog>
well, this depends on how languages compile to WASM, but I'd hope eg. Rust wouldn't force usage of a GC :)
<ekleog>
(C++ could according to C++14, but… ^^')
jtojnar has joined #nixos-chat
<simpson>
(And it should, for performance!)
<simpson>
(Also for sanity. C++'s attitude towards memory management is pretty tortorous.)
<ekleog>
hmm…? for sanity I do get it, but for performance?
<ekleog>
oh, assuming the host alloc will be faster than the guest alloc, gotcha
<simpson>
More importantly, assuming that WASM has a JIT behind it. JITs are great at removing temporary allocations.
<ekleog>
yeah indeed
<ekleog>
though I'd hope people writing code in C++ wouldn't do temporary allocs on the heap anyway :)
<ekleog>
(also, the compiler could already optimize them out)
makefu has quit [Ping timeout: 240 seconds]
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
infinisil has joined #nixos-chat
ekleog has quit [Quit: WeeChat 2.0]
ekleog has joined #nixos-chat
<clever>
sphalerite: it was 9am, i only wake up at noon :P
<gchristensen>
do you wake up at a consistent time?
<clever>
gchristensen: somewhat, i have daily meetings at noon
<gchristensen>
ah
jD91mZM2 has joined #nixos-chat
<infinisil>
Humm..
<infinisil>
direnv doesn't seem to propagate unpackPhase, buildPhase, etc.
<LnL>
no those are functions
<infinisil>
But I need those!
<LnL>
that's what nix-shell is for
<infinisil>
Meh, I don't wanna use bash
<LnL>
the stdenv and thus it's functions only work in bash
<infinisil>
:(
<infinisil>
It could make bash run those functions
<gchristensen>
bash functions in a separate process is rarely, semantically, what is wanted
<infinisil>
Oh right..
<LnL>
no, phases and setup hooks can mutate variables, etc.
<LnL>
or might depend on eg. bash arrays which are not exported
<infinisil>
How about bash starting zsh, then being able to call the parent bash processes functions
<gchristensen>
lol
<LnL>
eh??
<gchristensen>
you're just going to have to put up with bash
<infinisil>
Um
<LnL>
you could start a bash shell in the background and send/receive commands over a unix socket
<infinisil>
Yeah something like that
<infinisil>
Or just via a file
<LnL>
I euh... think my sarcasm wasn't clear enough
<gchristensen>
you could start a bash shell and send / receive commands over a tty
<samueldr>
madness
<LnL>
I did try to make a sane implementation of myEnvFun that has the same functionality as nix-shell a while back
<LnL>
not sure what you're trying to do, but that makes much more sense to me
drakonis__ has joined #nixos-chat
drakonis__ is now known as drakonis
adisbladis has joined #nixos-chat
__Sander__ has quit [Quit: Konversation terminated!]
<infinisil>
Hehehe
<infinisil>
I got it working, more or less
<sphalerite>
qemu is amazing
<sphalerite>
actually there's a lot of amazing software out there in general
<sphalerite>
but yeah qemu is one such piece of software
<jD91mZM2>
sphalerite: Yeah, but they kinda make you sad sometimes
<jD91mZM2>
All your hard work :(
<gchristensen>
out with the old,in with the new :)
<jD91mZM2>
Got a lot of that with my RSoC project. 1: Write compatibility code that works arounds Redox' issues. 2: Fix Redox' issues. 3: Delete all the thousands of lines of compatibility code
<jD91mZM2>
5 lines*
<jD91mZM2>
STILL
jD91mZM2 has quit [Quit: WeeChat 2.0]
drakonis has quit [Remote host closed the connection]
__monty__ has joined #nixos-chat
drakonis_ has joined #nixos-chat
tertle||eltret has joined #nixos-chat
<infinisil>
I have achieved enlightement
<infinisil>
The (almost) ultimate haskell dev setup for nix
<infinisil>
Along with a `.envrc` with contents `use_nix`
<infinisil>
And boom!
<infinisil>
All dependencies come from Nix, works with new-style builds, HIE works, works with whatever ghc version you specify in the default.nix
<infinisil>
And nix-build works too of course
<infinisil>
Although, there's one problem I'm noticing: If you're using direnv and it enters the directory (opens a nix-shell), you calling nix-build within that won't work
<infinisil>
Because it inherited IN_NIX_SHELL from the parent nix-shell :/
<infinisil>
Was able to solve that with a small trick using direnv's env vars (same link as above)
<LnL>
the if inNixShell then drv.env else drv is bad IMHO
<LnL>
there should either be a builtin that only changes for nix-shell or expressions shouldn't use it
<gchristensen>
+
<gchristensen>
inNixShell makes nix-build break inside a nix-shell which is evil
<infinisil>
LnL: Agreed
<infinisil>
But that's all we have as of now :)
<LnL>
exactly, it's ok for using in eg. a prompt but not something that influences evaluation because it doesn't mean anything there
<LnL>
infinisil: -A env
<infinisil>
Oh hmm, I guess I could make a shell.nix to use .env
<LnL>
echo 'use_nix -A env' > .direnv
<LnL>
if that's why you want it
<infinisil>
Ah yeah, but I need to customize the env a bit
<infinisil>
Need to add cabal to buildInputs
obadz has quit [Quit: WeeChat 2.1]
__monty__ has quit [Quit: leaving]
{^_^} has quit [Remote host closed the connection]