triallax changed the topic of #numbat to: The Official Numbat channel https://numbat.dev | This channel is publicly logged at https://libera.irclog.whitequark.org/numbat | Please read https://workaround.org/getting-help-on-irc/ if you're new to IRC!
sharkdp has joined #numbat
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
<triallax> okay finished my weekly monday habit of debugging segfaults in my desktop environment, now it's numbat time :D
<triallax> there's no error handling or anything yet, if you put in something invalid numbat will just crash
<triallax> but the general idea works
<triallax> pushed, feel free to try it out https://github.com/sharkdp/numbat/pull/312
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
<sharkdp> Nice! Writing a few review comments ..
<triallax> thanks
<sharkdp> It looks great!
<sharkdp> For invalid format specifiers, I think we can introduce a new RuntimeError
<triallax> why a runtime error?
<triallax> i was thinking we could do a test strfmt call at compile time
<sharkdp> Right, we discussed that. Hm, but now that format specifiers are runtime values... is that still the way to go? Most languages have support for dynamic format specifiers..
<triallax> i don't recall seeing that before, how would it look like?
<triallax> (i find it ironic that rust is not one of these languages :D)
<sharkdp> you can only vary parameters though
<sharkdp> Sorry, should have thought about it earlier. That would allow us to get rid of strfmt if we parse format specifiers ourselves. Not sure if it's worth it though
<triallax> but can you vary format specifiers?
<triallax> i was under the impression that format! and such parsed specifiers at compile time
<sharkdp> I mean... you can vary all parts of the format specifier. But you can't change from, say, ".3" to "<20".
<triallax> right, and i guess you want us to have that?
<triallax> that'd be nice i guess yeah
<triallax> (being able to vary parts of the specifier)
<sharkdp> I mean.. it's a niche feature. But we already enabled Numbat for it in your implementation. So I'd prefer we keep it
<triallax> i don't think that works with my current pr?
<sharkdp> Sorry, I meant: now that fmt specifiers are runtime values, you've already set us up to implement this later
<triallax> yeah true
<sharkdp> If we check fmt specifiers at compile time, that might go against this goal. But I'm not sure
<triallax> yeah
<triallax> i mean, we can still check them
<triallax> since numbat is typed, we should be able to replace each dynamic part with a sensible value
<triallax> right?
<triallax> but then there are generics i guess...
<triallax> it's more complicated than it sounds
<sharkdp> you don't have to worry about generics at this point
<sharkdp> If you have something like "{x:…}", the type checker will be able to give you a concrete type for x.
<sharkdp> Something like checked_expr.get_type()
<triallax> and then i should be able to generate a reasonable example value for x
<sharkdp> I think so
<sharkdp> Making some progress on the mobile app: https://i.imgur.com/Qksos8I.png - the individual history elements can be tapped to re-insert the expression into to query field.
<triallax> very nice
<sharkdp> https://i.imgur.com/JG7IABu.png - inputs are evaluated on every key press. if enter something invalid, you can not 'submit' it to the history. and the input itself turns red. The horizontal scrolling is not nice, obviously...
sharkdp has quit [Remote host closed the connection]