<srk>
is there an easy way to run ruby application which is not registered on rubygems? (bundix -l can still pull its deps)
disasm has joined #nixos-chat
lassulus_ has joined #nixos-chat
lassulus has quit [Ping timeout: 256 seconds]
lassulus_ is now known as lassulus
<ldlework>
Anyone playing EXAPUNKS
Drakonis has joined #nixos-chat
jD91mZM2 has joined #nixos-chat
<jD91mZM2>
gchristensen: Made it preserve multiline vs not multiline :D
Drakonis has quit [Remote host closed the connection]
<manveru>
srk: yeah, which app?
<ldlework>
if anyone wanted to help me deploy my emacs based service with nixops I'd be really grateful
<jD91mZM2>
I made a thing that can highlight AST nodes in the original code using rnix, check it out: https://i.imgur.com/pUxX4wj.png
<jD91mZM2>
samueldr: You could use something like this to only format specific parts of an AST if you like :D
<jD91mZM2>
Also could be used for syntax highlighters, although in that case highlighting tokens might be preferred over full-on parsing, so even invalid syntax highlights.
<jD91mZM2>
joepie91: Syntax highlighters is one reason I can think of why having a separate tokenizer is useful
<jD91mZM2>
... maybe the only reason on the top of my head ...
<sphalerite>
jD91mZM2: niiiiiice
<sphalerite>
jD91mZM2: how did you make the UI?
<sphalerite>
I've implemented a little game in Rust and it currently only has a command-line interface and prints the board to the terminal on each action
<sphalerite>
was hoping to get something more graphical (but still in the terminal)
<jD91mZM2>
sphalerite: That's Cursive :D
<jD91mZM2>
I normally like drawing stuff out myself with termion to get a nice and clean interface, but if you're doing something big, Cursive is amazing
<joepie91>
jD91mZM2: hm. I think you're better off with an error-tolerant AST parser there as well, given that syntax highlighting is sometimes structural and not merely token-based
<joepie91>
(eg. an 'identifier' token may have different semantic meanings depending on where it is used)
<joepie91>
also, nice, re: AST highlighting
<joepie91>
was working on a similarish thing a while ago for JS
<joepie91>
never did get very far before other priorities took over, though
<jD91mZM2>
You have other priorities??! Over nix??
<jD91mZM2>
(jk :D)
<jD91mZM2>
Wait no your thing was for JS, my joke doesn't work. Darn.
<joepie91>
of all the things that could have broken... it was the screw threads for the screws that hold the handle of the basket together
<joepie91>
I'm guessing it's due to poorly-specced screws, being screwed directly into plastic, and under regular thermal stress
<joepie91>
oh well, warranty email is sent
<joepie91>
let's wait and see what happens
schmittlauch[m] has joined #nixos-chat
schmittlauch[m] has left #nixos-chat ["User left"]
__monty__ has joined #nixos-chat
<MichaelRaskin>
Just a miscalculated right-after-warranty breakage happenned before warranty ran out…
<joepie91>
MichaelRaskin: not likely :) it has a 3 year warranty and I'm nearing the end of the second year, and this is very much an alibaba-supplied product
<joepie91>
it's Lidl stuff, they don't make a habit of engineering stuff to break, they just try to get it as cheap as possible without compromising *too* much on quality or longevity
<joepie91>
it's more "alibaba, but with QA and 3 years warranty" than anything
<samueldr>
neat jD91mZM2, this could be used for showing the "issue points" as a linter if desired
<samueldr>
(unnecessary parens)
<jD91mZM2>
samueldr: Also see the error-report example, it does almost exactly this :D
<samueldr>
:D, can't wait for the moment I have time and check this (circa 2032)
<jD91mZM2>
I also tried running it myself, not in a recursive import-detecting way this time, but actually on every single nix file (**/*.nix) in nixpkgs lib and pkgs dir. No errors. Wow.
<jD91mZM2>
Looks like I didn't have to solve that many edge cases yet!
<sphalerite>
jD91mZM2: I think there are also some slightly obscure tests in the nix source/tests
<jD91mZM2>
(Although that said, I haven't actually checked the validity of the produced AST)
<jD91mZM2>
sphalerite: Nice, thanks! Will take a look!
<jD91mZM2>
sphalerite: All lib/tests files parse if that's what you mean
<samueldr>
your lets and this being nix* I was throughly confused reading this
<jD91mZM2>
samueldr: Oh, you didn't know about this very strange nix syntax? It's legacy to be compatible with the deepest and ugliest parts of nixpkgs /jk
<joepie91>
lol
<joepie91>
seriously though
<joepie91>
why can we still not roundtrip date objects
<joepie91>
(in JS)
<jD91mZM2>
Why are date objects even a thing in JSON?
<samueldr>
probably part of the spec that can't be changed?
<samueldr>
I mean, there are *no* dates in the ECMA json AFAIK
<maurer>
jD91mZM2: They aren't, that's the problem he's running into
<maurer>
Because JSON doesn't have dates, the get serialized as string
<jD91mZM2>
Oh. Good.
<maurer>
then, when you go to deserialize, they come back as strings
<jD91mZM2>
Well that's impossible to fix without adding types to the JSON spec
<maurer>
No, you can actually do this just fine
<maurer>
your language just needs to be statically typed
<maurer>
so that it can know in the output type what kind of parser to use on top of json
<ivan>
joepie91: you can with cognitect's transit
<samueldr>
maurer: you can do it just fine if you know the schema of json, without statically typed languages
<maurer>
samueldr: Yeah, which is what the reviver is for, in the post I linked
<maurer>
samueldr: but then you need to write it out
<jD91mZM2>
maurer: Oh, or that
<samueldr>
it's for schema-less jsons where it gets harder :/
<samueldr>
(I mean in the general meaning of schema, not a particular implementation)
<maurer>
I'm still of the opinion that a schema-less json object is meaningless json object
<samueldr>
even just static typing "creates" a schema
<maurer>
Yeah, that's the point
<samueldr>
and you're pretty right
<samueldr>
there will always be an implicit schema
<samueldr>
both out and in
<samueldr>
(implicit in that it can cause surprises!)
<jD91mZM2>
btw, fun fact: Posted rnix to /r/rust and now I'm being told to try libsyntax instead of some of own whitespace preserve madness, to get true preservation. They make some really good points... which means I'll have to rewrite most of rnix. Ugh.
<jD91mZM2>
Well, not rewrite the parsing logic itself I don't think, but rewrite the AST handling
<jD91mZM2>
Anyway, I'm heading off to bed. See you!
jD91mZM2 has quit [Quit: WeeChat 2.0]
<joepie91>
maurer: the underlying problem is that a custom serializer will get *the JSON representation of the Date* and not the Date itself, meaning that you cannot encode date types into your JSON yourself and then unpack it in a reviver
<joepie91>
(also the reviver is path-unaware afaik so even with schema enforcement you can't really figure this out)
<joepie91>
(the JSON representation of a Date is the dreaded ISO string that is useless to me...)
Ericson2314 has quit [Ping timeout: 244 seconds]
<joepie91>
maurer: "The problem with dates in JSON – and really JavaScript in general – is that JavaScript doesn’t have a date literal. "
<joepie91>
from the article you linked
<joepie91>
this... makes no sense :)
<LnL>
just use unix timestamps, unless it's used for representation _only_ IMHO
<joepie91>
I think the author doesn't fully understand the distinction between JSON and JS...
<joepie91>
LnL: the core of the problem here is that I cannot control how the Date objects are represented in the resulting serialized JSON
<joepie91>
so any points on how to represent the date are moot :P
<LnL>
just stating my opinion, it probably isn't useful indeed :)
<maurer>
joepie91: JavaScript indeed does not have a date literal, and JSON was designed originally to be eval'able by js
<maurer>
before everyone realized that was dumb
<maurer>
It has a date object
<maurer>
but not date literals
<maurer>
basically, json was supposed to be the constant fragment of js
<maurer>
then we started using it general purpose
<maurer>
to create a date in js, you need to call a function, there's no literal form
<joepie91>
maurer: JSON has never been a strict subset of JS though, due to encoding caveats
<LnL>
to be fair the way our date/time works is basically madness
<joepie91>
it's possible to produce valid JSON that does not evaluate in a spec-compliant JS runtime
<joepie91>
either way, even with an eval-ability requirement that doesn't necessitate a date literal
<joepie91>
you just need to specify an encoding format that, when eval'ed, results in a Date with the correct contents
<joepie91>
eg. `new Date("<iso string here>")` (defined as such in JSON spec)
<joepie91>
that would work even under the eval-ability constraint even if it cannot represent all possible `new Date` invocations
<joepie91>
so either way the 'no date literal' point makes no sense :p
<maurer>
joepie91: It was supposed to be the _constant fragment_
<maurer>
so that you can check that evalling it won't cause problems
<maurer>
as soon as you call a function, or set a variable, you're done
Drakonis has joined #nixos-chat
<joepie91>
maurer: you're misunderstanding my point, I think
<joepie91>
I am not at all talking about allowing arbitrary function calls
<joepie91>
I am talking about a very specific date representation that is formatted as `new Date("<ISO string format goes here>")`
<joepie91>
ie. it is no more or less analyzable than the exactly specified number or string representations
<joepie91>
it just so happens that the way you eval it results in it being executed as a function call rather than interpreted as a literal
<joepie91>
well then I guess I'll have to write my own JSON stringifier
* joepie91
shudders
<srk>
manveru: copied your drv as default.nix to that repo and it wurkz \o/ ./result/bin/redzone generate --zones=./zones.yml.example ./tmp
Sonarpulse has joined #nixos-chat
Ericson2314 has quit [Ping timeout: 244 seconds]
Sonarpulse has quit [Ping timeout: 240 seconds]
<__monty__>
quit
<__monty__>
Ups
__monty__ has quit [Quit: leaving]
<ldlework>
infinisil: heh ok it is official - in order to get my bot onto freenode from AWS, it needs to authenticate with SASL, which is probably too hard to implement myself, meaning that I need to stand up ZNC infront of my bot
<ldlework>
lmao
<samueldr>
ldlework: free restart of your bots include d:)
<clever>
,profiling
<{^_^}>
Use NIX_COUNT_CALLS=1 and/or NIX_SHOW_STATS=1 to profile Nix evaluation
<ldlework>
samueldr: what do you mean? :)
<samueldr>
restarting your bot won't kill the freenode connection
<ldlework>
Oh they wont dissapear
<ldlework>
Good point
<samueldr>
you also can do "administrative miscellanea" using the bouncer
<samueldr>
e.g. login to nickserv, authenticate it to another service
<samueldr>
the biggest issue: dropped messages
<ldlework>
samueldr: infinisil wrote an awesome new ZNC nix module so I'm just waiting for that to land in unstable
<samueldr>
:)
<infinisil>
It's not gonna land anywhere if I don't finish it..
<ldlework>
infinisil: is there a simple way I can take a copy of it and stick it somewhere such that i'd be able to deploy it with nixops?
<ldlework>
I forgot how we hotwired it last time (since I deleted it without commit :( :( :( )
<samueldr>
you probably can do as with other nixos modules
<ldlework>
so just copy it somewhere, format it as a module, then add it to imports list
<ldlework>
?
<samueldr>
1. disable the nixos one (if you don't remember I can find you the doc)
<samueldr>
2. what you just said
<ldlework>
samueldr: I don't think they collide actually
<ldlework>
isn't that right infinisil?
<samueldr>
if they don't then you can skip 1 :)
<ldlework>
Because it uses a diffenrent attribute I think
<samueldr>
do it's probably: clone the branch, copy that folder, {}: { imports = [ ./that/folder/that_file.nix ]; }
<infinisil>
Different path
<samueldr>
so*
<ldlework>
infinisil: do you have a link handy? (sorry)
<infinisil>
I'll try to finish it soon, after my exams :)
* ldlework
tries to remember that he has to set sasl auth manually by first connecting to znc and telling it what to do
Drakonis has quit [Remote host closed the connection]
<ldlework>
infinisil: :(
<ldlework>
error: The option `services.znc.enable' in `/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/services/networking/znc.nix' is already declared in `/nixcfg/external/infinisil/nixos/modules/services/networking/znc'.
<infinisil>
Just checkout nixpkgs already
<ldlework>
infinisil: what do you mean exactly, and how does it fix what happened?
<infinisil>
Apply my PR to a git checkout of the branch you're using
<ldlework>
it just seems antithetical to composability
<infinisil>
You keep thinking that, but have you actually done this?
<andi->
So what do you guys do while you wait for stuff to be compiled? Building on 3 boxes, running tests and I have a few more things scheduled but I am blocked due to lack of CPU power..
<ldlework>
infinisil: it means in addition to my own configuration I have to maintain a fork of nixpkgs and maintain it
<ldlework>
instead of being like "override this attribute with this module from this remote fork of nixpkgs"
<ldlework>
seems so much better
<ldlework>
I'm not trying to argue
<simpson>
andi-: I went to a meeting. Not sure if it was a good call, but now I can do something while my PyPy builds.
<ldlework>
andi-: pick up the ancient game of Go
<ldlework>
andi-: package up licecap :)
<samueldr>
I would be fine with deprecation à la jwz *if it was somehow at build time*
<samueldr>
(impurities ahoy!)
<infinisil>
ldlework: It's really not that big of a deal
<ldlework>
infinisil: it just seems like a better practice - is it even possible?
<andi->
ldlework: haha, not packaging more.. my poor multitasking skills already make those 3 in-flight changes difficult to not forget about (+ backports..)
<ldlework>
andi-: ah well let me know if you want to play a game of Go then ;)
<andi->
the VM tests just finished, next time ;)
<ldlework>
infinisil: I'll even add it to the cookbook if we can figure it out! :)
* ldlework
grumbles and forks nixpkgs in the meantime
<infinisil>
Eh sorry I don't want to be bothered trying to figure this out right now
<sphalerite>
samueldr: IMHO it's just wrong overall. Who cares if you're building the package now or 4 years ago, really? Maybe you're building from source because you want to reproduce an old system but the distro binaries have been dropped
<samueldr>
yeah
<samueldr>
it's kinda hard
<samueldr>
I see what they mean
<samueldr>
I'm fine with the idea jwz wants: not ancient packages
<samueldr>
but damn that's an annoying thing to actually fix
<samueldr>
at compile time wouldn't fix using an ancient version
<infinisil>
Oh lol, how about that: We add a file nixpkgs/time.nix which contains "builtins.currentTime" in master. But when a release gets forked off, we change it to "1523656456" (whatever the time was at that point). To get the time we always use that file then
<samueldr>
but it would at least show the maintainers: hey there, maybe check for new versions?
<infinisil>
Therefore we "freeze" a release at a point in time
<MichaelRaskin>
Well, of all packages XScreenSaver _is_ a package that can be Just Upgraded instead of cherry-picking the bugfixes
<samueldr>
and it's kinda security-sensitive
<sphalerite>
samueldr: it's not that they're not checking for new versions
* infinisil
is full of crazy ideas today
<MichaelRaskin>
I mean, jwz does care about compatibility
<sphalerite>
samueldr: it's that in a stable distro, major version updates do not happen.
<samueldr>
(maybe I missed something haven't re-read, using my memory)
<sphalerite>
samueldr: and debian *does* backport security fixes
<samueldr>
the dichotomy major/minor maybe is to be re-evaluated in that case
<samueldr>
jwz could release all updates with a monotonically increasing number
<sphalerite>
oh yes, because debian stable desperately needs new display hacks.
<MichaelRaskin>
They did skip some non-security but clear bug
<samueldr>
you see, that's another issue: hacks maybe shouldn't be built-in?
<samueldr>
but now that's not debian's issue
<MichaelRaskin>
In what sense? They are separate programs with clearly separated source code.
<samueldr>
package-wise, and release-wise
<samueldr>
but then, comes all kind of other issues
* samueldr
isn't good a thinking on his feet like that
<samueldr>
I need to see the fractal before talking about it :/
<sphalerite>
MichaelRaskin: debian stable is bug-for-bug compatible :)
<MichaelRaskin>
Most of the packages are much more risky to update than XScreenSaver
<MichaelRaskin>
XScreenSaver is safe, which is a rarity. Debian cannot handle such rarity, so they keep shipping long-fixed bugs.
<ldlework>
infinisil: ok I cloned nixpkgs and merged in your change, how do I move from channels to this
<ivan>
one of these, I think <ivan>nixos-rebuild switch -I nixpkgs=/root/nixpkgs