<ktemkin>
but I agree; not paying someone who takes on major tasks feels exploitative to me
<ktemkin>
and there’s enough of that in FOSS already without our projects having opportunities for more
<whitequark>
viewsb has so little code total that my brain refuses to accept there could be major tasks in it, heh
<whitequark>
although i do know that it's illusory
<ktemkin>
also once you touch something you’ll want to fix everything
<ktemkin>
=P
<whitequark>
mhmmmmm
<whitequark>
would be nice to figure out why DFU is broken~
<Qyriad>
what is the whole problem we were trying to solve in the first place? Exception handling in the TUI?
<whitequark>
no, hang on exit
<Qyriad>
Ahhh
<whitequark>
caused by a read syscall that wasn't terminating
<whitequark>
i'm not familiar with viewsb backend architecture yet so i'm not sure what's best there
<Qyriad>
I haven't looked at the usbmon backend almost at all so idk either
<Qyriad>
ktemkin wrote that entirely herself heh
<whitequark>
i have looked at the usbmon kernel code and i would very much like to forget
Foxyloxy has quit [Read error: Connection reset by peer]
<ktemkin>
it’s designed so backends can take the full CPU and just squish whatever into the analysis queue
<whitequark>
ok dumb question
<whitequark>
why are there 3 processes?
<whitequark>
aren't 2 enough?
<ktemkin>
I wanted it to be set up so hardware people didn’t have to worry about literally anything else other than grabbing their data and squishing it into the queue
<ktemkin>
and I wanted frontend designers not to have to give a damn about anything other than the frontend
<whitequark>
FFY00: nice!
<whitequark>
ktemkin: fair
<Qyriad>
Which, given *urwid*, might be a particularly good thing
<whitequark>
my understanding so far is that we don't need to worry about the frontend or the middleend
<whitequark>
the only problem is middleend waiting for the backend waiting for the read that might never come
<FFY00>
now, the TUI frontend exception still don't show
<FFY00>
they get printed but the TUI writes over them
<FFY00>
s/TUI loop/urwid loop/
<ktemkin>
there's a way to do a popover using urwid
<ktemkin>
good luck figuring that out
<whitequark>
imo if the frontend ever throws an uncaught exception it means a frontend bug
<whitequark>
thus: kill the frontend, print the exception to the terminal, done
<ktemkin>
yep
<FFY00>
ktemkin, I used an overlay for that
<Qyriad>
whitequark: I agree
<FFY00>
we can override Python's exception handler to kill the urwid loop first and then print the exception
<whitequark>
i mean, arguably it's also true about backends, but backends have way more failure modes and they seem like they'd be written by hardware people
<ktemkin>
I'd be of more use, but I'm running a fever and vaguely contemplating that I hallucinated urwid in the first place
<FFY00>
don't worry :)
<whitequark>
urwid's programming model is not unlike a fever dream
<FFY00>
I dislike how dynamic it is
<FFY00>
actually, I dislike how dynamic Python is lol
<Qyriad>
Also backends can have reasonable errors like "failed to open the usbmon file", though until the frontend can tell the backend to retry I'm still not sure that there's any point to not crashing there too
<FFY00>
that's why I use type hints
<ktemkin>
too bad type hints are broken in Python, still -_-
<whitequark>
i use uh... lots of asserts
<whitequark>
this seems to infuriate the type hint people and the dynlang people
* ktemkin
shrugs
<FFY00>
ktemkin, how so?
<whitequark>
fortunately it's not my problem! i can just live knowing that my code will explode straight away rather than 20 minutes later in a completely unrelated place
<Qyriad>
Iirc type annotations are only broken in class/method definitions, not in bodies
<Qyriad>
Unfortunately, that's where they're arguably needed the most
<ktemkin>
FFY00: a few ways; but the most major is just that that it's often impossible to import the types to where you need them
<whitequark>
yep
<FFY00>
from __future__ import annotations
<FFY00>
:P
<FFY00>
that changed
<Qyriad>
Iirc Python 3.10 is fixing that, so in 20 years we can rely on Debian having that
<whitequark>
oh wow, they fixed it
<whitequark>
holy shit
<FFY00>
and it was backported to older versions with __future__
<FFY00>
you could already just wrap them in strings, the typing api would figure it out
<whitequark>
like, i still find it vaguely offensive that they shipped type hints the way they did, but, props for actually fixing them
<whitequark>
the string hack was horrendous
<ktemkin>
I consider the string hack "broken"
<FFY00>
well, it was an incremental progress
<ktemkin>
if you have to work around something, that thing is probably broken =P
<whitequark>
i think early on in nmigen's history a friend tried to typify it and gave up because of all the strings, and also somethin about enums i no longer recall
<FFY00>
I mean, the typing api would resolve them
<FFY00>
so it's not my issue
<FFY00>
changes absolutely nothing when consuming type hints
<FFY00>
just writing
<ktemkin>
right, but now there's a whole 'nother place for me to typo
<whitequark>
>Instead of compiling code which executes expressions in annotations at their definition time, the compiler stores the annotation in a string form equivalent to the AST of the expression in question.
<whitequark>
what in tarnation
Foxyloxy has joined #glasgow
<ktemkin>
I was good with that sentence for about 75% of it
<ktemkin>
and then I got to the end and my eyebrows just kind of monotonically raised clear off my face
<whitequark>
>Annotations can only use names present in the module scope as postponed evaluation using local names is not reliable (with the sole exception of class-level names resolved by typing.get_type_hints()).
<whitequark>
aaaaaaaaaaaaaaaaaaaargh
<whitequark>
they did not in fact fix them
<whitequark>
they made them more subtly broken
<Qyriad>
What
<ktemkin>
oh no
<whitequark>
i officially hate python again
<whitequark>
nevermind
<Qyriad>
I thought they changed it so the hints were totally meaningless and effectively just strings
<Qyriad>
I feel lied to
<Qyriad>
Python why
<whitequark>
why can't you just use a fucking lambda there
<whitequark>
you're python, not tcl
<Qyriad>
~~brb rewriting viewsb in rust~~
<ktemkin>
I'm starting to think the miasma theory of medicine wasn't wrong
<ktemkin>
some of these code smells are making me feel ill
<whitequark>
ok well reading that PEP raises my blood pressure too much
<FFY00>
well, Python was never designed to have type hints in the first place
<FFY00>
maybe they'll reword this in Python 4, whenever that happens
<FFY00>
*rework
<whitequark>
at this point i suspect that i might be able to get nmigen work with types if i ditch all of the established conventions around them and start over
<whitequark>
like, there's probably *some* well-defined semantics that can be squeezed out of this
<ktemkin>
I don't see type-annotations as so critical
<whitequark>
for the most part, they are not critically important
<whitequark>
but the Interfaces feature as i envision it would rely on type annotations in classes
<whitequark>
i *think* i can use the 3.10 annotations semantics to make that work with parametricity (like over signal widths) without workarounds that are too horrifying
<whitequark>
there is also a separate question of adding ordinary typing annotations to non-DSL nmigen APIs, which is basically ok except it would be very strange to have types for everything *except* for the core language, and i feel like it would end up in frustration downstream moreso than just not having types anywhere
<FFY00>
whitequark, yes, I would very much like to help out with that
<FFY00>
if you end up doing it
<whitequark>
i would strongly prefer to be able to use pep-563 annotations firt
<whitequark>
what was the pre-3.10 version that made them available via __future__?
<vup>
3.7
<whitequark>
we can do it in 2022 then
<FFY00>
yup, 3.7
<whitequark>
since nmigen's MSPV is 3.6 and that EOLs at the end of 2021
<FFY00>
there's also PEP 593 which would be very helpful
<whitequark>
Qyriad: it basically implements non-hygienic macros
<whitequark>
you can refer to symbols in scope within the annotations, but you have no way to bind the annotation to the scope
<whitequark>
and at the same time, the way annotations are used is through eval()
<whitequark>
if annotations captured the scope, you could bind them. if annotations were symbolic with a well-defined grammar, you could effectively place them in a different namespace. but as it is, it's the worst possible semantics
<whitequark>
free variables within the annotation refer to symbols from the annotation's scope, but you don't actually have that scope
<Qyriad>
that's horrible
<whitequark>
and what the PEP tells you to do is basically use a few heuristics to try and guess what might have been in scope at the time the annotation was parsed
<Qyriad>
does/can that actually cause concrete problems, though?
<whitequark>
consider this hypothetical nMigen code:
<FFY00>
if you use type hints as they are intended, no
<FFY00>
because they shouldn't be dynamic, hence, scope dependent
<FFY00>
but if you want to do something with them other than just type checking, possibly
<whitequark>
this could *probably* be addressed to some extent by requiring every such parametric function to be wrapped in a decorator that uses inspect to grab its caller's scope, pull the locals out of there, then substitute free variables in the annotations
<Qyriad>
if I understand correctly, this only causes problems if you have code that actually *does something* with the annotations, instead of just having them there for the user (and potentially their language server)?
<ktemkin>
I mean
<FFY00>
not necessarily
<Qyriad>
s/user/other programmer
<whitequark>
if you use type annotations as comments with syntax highlighting, yes, it doesn't matter
<whitequark>
but... that's just settling for so little?
* Qyriad
nods
<ktemkin>
if you want something that's only used by the user and their language server, there are plenty of docstring formats that are standardized to the point of language-server understanding
<Qyriad>
now I understand, I think
<whitequark>
^ what ktemkin says
<whitequark>
mypy used to parse docstrings iirc
<whitequark>
the point of having __annotations__ in the interpreter is exactly so that you can do something with them
<FFY00>
I have no issues there because the type hints aren't dynamic
<whitequark>
i feel like we shouldn't call them "hints" when in fact they are very much semantic and required for correctness
<whitequark>
such as in your dbus example
<whitequark>
it's like calling integers "literal hints"
<FFY00>
but if they are, you will run into trouble
<FFY00>
^
<FFY00>
yup
<Qyriad>
the decorator solution whitequark mentioned feels like the best way around that, but that's still *far* from ideal
<whitequark>
in fact i don't think any of the python interpreters actually use type hints for, well, *hinting*
<FFY00>
yeah, I should call them type annotations
<FFY00>
they don't :P
<whitequark>
because either your interpreter is too crude to do any seirous optimization, or your interpreter has all that information and then much more
<Qyriad>
*if* I recall correctly the relevant PEPs use 'type hint' and 'type annotation' interchangeably which does not help the problem
<FFY00>
yes
<ktemkin>
even as annotations, if they're not doing more than an assert or documentation there's not much point to 'em
<FFY00>
pretty much
<Qyriad>
I feel like they're valuable as documentation, which is at least now possible with 3.10 annotations, but ugh
<ktemkin>
I view their real potential in being able to do things like dataclasses
<whitequark>
i feel like a lot of the issues with the annotations stem from the fact that many people think of them as "go faster stripes"
<FFY00>
this feature was basically designed for mypy
<whitequark>
c has types, therefore types make things fast
<FFY00>
they used to be comments
<FFY00>
# type: (int, str) -> bool
<whitequark>
since in no other context it makes sense to call them "hints"
<FFY00>
then evolved to inline annotations
<whitequark>
Qyriad: i actually think they're slightly worse for documentation than plain docstrings
<FFY00>
I use both
<FFY00>
my documentation gets the types from the type hints
<Qyriad>
"I view their real potential in being able to do things like dataclasses" <-- dataclasses don't actually do anything with the actual content of the annotation; they just operate on any attribute that *has* an annotation at all
<FFY00>
I use the type hints for type checking
<whitequark>
right, i meant that if you use them *only* for documentation, you don't gain much but you lose the ability to document the type of something in a way that is more concise or less formal than python's syntax
<ktemkin>
Qyriad: I mean, you can use dataclasses to structure declarative code by embedding semantic meaning in the type hints
<Qyriad>
ah, yeah
<Qyriad>
whitequark: I think that's why the wonk ClassName[Argument] syntax exists, but it's, well, wonk, so that's fair
<whitequark>
yes, that's what i mean
<whitequark>
and then you get to Union[]
<whitequark>
what's better: Union[A,B] or A|B ?
<whitequark>
wait, i think they have the second one now
vup has quit [Remote host closed the connection]
vup has joined #glasgow
<Qyriad>
for me I would only use type annotations as documentation in *addition* to docstrings, and simply elide them when it would make things less readable rather than more, but that does introduce duplication
<whitequark>
it's a very harmless way to use them
<whitequark>
little risk, little reward
<Qyriad>
(er, I meant *if* I'm using them as documentation, not that I would only ever use them as documentation, but yeah)
* Qyriad
nods
<FFY00>
you could also provide them in public API so that your users can do type checking
<FFY00>
there are other uses, having a fully typed codebase allows you to convert your Python code to C, using the C Python API ofc, because you have all the required type information
<FFY00>
mypyc is a thing
<FFY00>
mypyc takes your fully typed code a generates an equivalent C Python module
<FFY00>
which of course compiles to native code and is faster
<whitequark>
how much of that is just because they eliminate unnecessary dict lookups?
<ktemkin>
often when people say they want to do type checking with python, what I they often mean is "I want to make python behave more like another language", or "I'm inferring that things will be safer/saner with these checks", or "I want to make my code faster", and I find they rarely do any
<whitequark>
i mean, you can compile any arbitrary python code to c
<ktemkin>
*what they often
<whitequark>
cruby's jit works that way
<whitequark>
no types, just ruby→c
<FFY00>
ktemkin, kind of, but I enjoy the how dynamic Python is, which is something I don't really have in other languages
<whitequark>
mypyc has the advantage of actually enforcing the type annotations, which is nice, but this is a particularly roundabout way to achieve that
<whitequark>
same with class layout optimizations
<FFY00>
Python gives me an option to do typing or not
<ktemkin>
somewhere in my fever-addled brain, I have a terrible vision of some old IBM engineer peering over a C++ program and going "hey, don't use `virtual`, it'll make everything slower"
<FFY00>
I don't like untyped Python as it is too dynamic, I don't like fully typed languages because they are not dynamic
<whitequark>
i don't like typed python because it is unsound by design
<Qyriad>
I guess I was just under the impression that Python's type annotations would at best just effectively be strings that are useful to the eye and language server and never had any hopes of being able to do anything actually Nice with them to begin with =P
<FFY00>
eh
<FFY00>
at the end of the day, I am more productive with it
<whitequark>
when you say "typed" you actually mean something completely unrelated to that term as it's used elsewhere
<whitequark>
which isn't inherently bad but it leads to miscommunication
egg|laptop|egg has joined #glasgow
<whitequark>
FFY00: try typed racket
Stormwind_mobile has quit [Remote host closed the connection]
Stormwind_mobile has joined #glasgow
<whitequark>
lets you mix typed and untyped code, *and* the typed parts are actually sound
<FFY00>
hum
<whitequark>
it used to be two orders of magnitude slower than normal racket (yes, slower), but they managed to fix that like two years ago with some kind of wizardry i've never seen before
<whitequark>
like it's still slower, just not pathologically so
Stormwind_mobile has quit [Remote host closed the connection]
<FFY00>
my main problem there is adoption
<d1b2>
<timonsku> @whitequark I came around now to test the led firmware you send me. It seems to error during the selftest at that point, not sure what that means E: g.applet.internal.selftest: mode pins-int is broken on device revision C1 https://pastebin.com/V1xVn7CG
<whitequark>
timonsku: yes, that is expected
<whitequark>
FFY00: it's lisp. why would you expect adoption
<whitequark>
typed racket is one of the languages that you will probably never use for a major project, but would study and therefore avoid the mistakes that e.g. python made
<d1b2>
<timonsku> ah ok but should all LEDs light up still? right now it only lights up the user leds, PWR, FX2 and ICE
<whitequark>
timonsku: have you flashed the firmwarE?
<d1b2>
<timonsku> yes with glasgow flash --firmware glasgow-led.ihex
<whitequark>
hm. power-cycle it?
<d1b2>
<timonsku> right
<d1b2>
<timonsku> hah yea that lights up all the front leds :) any way to get those vio leds to light up too?
<whitequark>
glasgow run uart -V 3.3
<whitequark>
(can't use `glasgow voltage` yet...)
<d1b2>
<timonsku> glasgow run uart: error: the following arguments are required: OPERATION ?
<whitequark>
er
<d1b2>
<timonsku> help text says ... for available operations, so not sure what is wanted there 🙂
<d1b2>
<timonsku> its really fiddely to insert though, not sure if thats reasonable for the average user. Might have to see if increase the size even further to make it easier to handle
<d1b2>
<esden> WOW that looks great!!!
Getorix_ has joined #glasgow
<d1b2>
<esden> Like radioactive candy
<d1b2>
<esden> I love it
<d1b2>
<timonsku> hehe
<d1b2>
<timonsku> its a bit less crazy saturated in RL :p
<whitequark>
With postponed evaluation, this would require keeping a reference to the frame in which an annotation got created. This could be achieved for example by storing all annotations as lambdas instead of strings.
<whitequark>
This would be prohibitively expensive for highly annotated code as the frames would keep all their objects alive. That includes predominantly objects that won't ever be accessed again.
<whitequark>
i've been re-reading that a few times
<d1b2>
<timonsku> but even without its ok visible I would say, so maybe its not the end of the world if a user just doesnt wanna install them because fiddely
<d1b2>
<timonsku> just not that pretty
<d1b2>
<TiltMeSenpai> yeah, I'd say knowing how cameras tend to dislike the blinkenlights, that's probably plenty fine irl
Getorix has quit [Ping timeout: 264 seconds]
<d1b2>
<TiltMeSenpai> the insert does look super nice though
<d1b2>
<timonsku> yea I would definitely have it, just thinking about how much effort I should put into making the insertion fool proof
<d1b2>
<timonsku> so its good if its not essential, would be bad if it wasn't very usable without the light pipe and then lots of people end up skipping installing it because they hate doing fiddely things and then can't use the case all that well
<d1b2>
<TiltMeSenpai> what does the other side of the case look like
<d1b2>
<timonsku> but it might actually be easier once the top sits on the glasgow, I installed it with just the top piece so the support from the connector was missing so it tented to tilt away
<whitequark>
what they're saying there is that CPython cannot capture environments precisely, and because of that they do not even consider that possibility
<whitequark>
which is just ugh... such an unforced error
<whitequark>
it wouldn't even be that hard to implement in CPython
<d1b2>
<timonsku> it not the latest state though, I have increased the length of the pipes there
<d1b2>
<timonsku> the blue led on the left is not so well visible in this rev.
<d1b2>
<TiltMeSenpai> oh, that's really nice. I sorta was wondering if the back side had enough room to make the light pipes less fiddly, but that's still a nice pic 😛
<d1b2>
<timonsku> not sure what you mean then, the inside? 🙂
<d1b2>
<TiltMeSenpai> like how the light pipes attach to the case
<d1b2>
<timonsku> so you just push it in there with your fingers or a little nudgie thing like a screwdriver
<d1b2>
<TiltMeSenpai> mmm
<d1b2>
<TiltMeSenpai> you could probably get away with adding like a base to the light pipe. Idk if that would make it less fiddly to install
<d1b2>
<timonsku> not really possible, they are getting laser cut
<d1b2>
<TiltMeSenpai> oh, yeah that's not possible for laser cut
<d1b2>
<TiltMeSenpai> you would have to do like injection mold or sla
<d1b2>
<TiltMeSenpai> I doubt making the light pipes more complex is the answer
<d1b2>
<timonsku> its fine took me about 10 seconds to install but not sure how well I can map my experience to others
<d1b2>
<timonsku> yea nah, if at all I would just make the opening larger so there is a larger piece to grab onto
<whitequark>
is the plan to ship cases disassembled?
<d1b2>
<timonsku> that was @esden plan yea
<d1b2>
<timonsku> having it fully assembled with glasgow in it would make it a lot more expensive but maybe an option to have for those willing to pay the premium? 🤷♂️ Assembly would currently mean: 1. Press acrylic pieces into place 2. Place glasgow on bottom plate 3. Place top plate on top 4. Tighten all 4 screws
egg|laptop|egg has quit [Remote host closed the connection]
<whitequark>
hum
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #glasgow
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 256 seconds]
PyroPeter_ is now known as PyroPeter
Getorix has joined #glasgow
Getorix_ has quit [Ping timeout: 256 seconds]
Getorix_ has joined #glasgow
Getorix has quit [Ping timeout: 256 seconds]
_whitelogger has joined #glasgow
samlittlewood has quit [Quit: samlittlewood]
bvernoux has joined #glasgow
gillesmauve has quit [Quit: Bridge terminating on SIGTERM]
promach3 has quit [Quit: Bridge terminating on SIGTERM]
jschievink has quit [Quit: Bridge terminating on SIGTERM]
emily has quit [Quit: Bridge terminating on SIGTERM]
fridtjof[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark[m] has quit [Quit: Bridge terminating on SIGTERM]
disasm[m] has quit [Quit: Bridge terminating on SIGTERM]
ZerataX has quit [Quit: Bridge terminating on SIGTERM]
jevinskie[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark[m] has joined #glasgow
ZerataX has joined #glasgow
disasm[m] has joined #glasgow
fridtjof[m] has joined #glasgow
gillesmauve has joined #glasgow
emily has joined #glasgow
jschievink has joined #glasgow
promach3 has joined #glasgow
jevinskie[m] has joined #glasgow
sambristow_nz[m] has joined #glasgow
samlittlewood has joined #glasgow
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
Foxyloxy has quit [Ping timeout: 264 seconds]
Foxyloxy has joined #glasgow
umarcor|2 has quit [Read error: Connection reset by peer]
feldim2425 has quit [Ping timeout: 260 seconds]
feldim2425 has joined #glasgow
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
umarcor has joined #glasgow
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
FFY00 has quit [Remote host closed the connection]