sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
mindrunner has quit [Ping timeout: 240 seconds]
FabM has quit [Ping timeout: 240 seconds]
kaalia has quit [Ping timeout: 240 seconds]
acathla has quit [Ping timeout: 240 seconds]
_florent_ has quit [Ping timeout: 240 seconds]
FabM_ is now known as FabM
mindrunner has joined #m-labs
kaalia has joined #m-labs
_florent_ has joined #m-labs
<cr1901_modern>
sb0: I've run into a bug with the widget where moving the sliders is not honored at extreme zoom-outs (on the order of one screen pixel = 1e-12). rjo says that the widget needs to support up to 1e+/-15. Not sure what is causing this, but I'm looking into it (floating point error?). Perhaps it would be better if I do a coordinate system transformation to logscale after a specific zoom-out?
<cr1901_modern>
i.e. one pixel on the screen equals log(actual value the slider should increment/decrement)
<cr1901_modern>
Hrm, tbh this is probably what I should have done from the beginning
awallin_ has quit [Ping timeout: 250 seconds]
<sb0>
why do people use scramblers over e.g. 8b/10b? they just sound harder to debug, and the DC balance is only statistical and not bounded
<sb0>
statistically the EMI is spread?
<sb0>
cr1901_modern, how does the log scale help?
<sb0>
you mean do all drags in pixels, and then update the value by number of pixels*scale?
<cr1901_modern>
Yes.
<sb0>
but when there is no drag the value is untouched, right?
<cr1901_modern>
I suspect that at extreme zoom outs like the ones I had, floating point precision errors are creeping in, so a drag actually does not move the slider
<sb0>
is that double or single precision?
<cr1901_modern>
Right; Qt internally keeps track of which item has control of the mouse
<cr1901_modern>
Am not sure
<cr1901_modern>
I
<sb0>
well, where are your floats?
<cr1901_modern>
It's whatever the precision of a QFloat is in PyQt
<cr1901_modern>
I'll check
<sb0>
all python floats are doubles, do you pass them into non-python code at some point?
<cr1901_modern>
No. There is no non-python code. I'm assuming the Python to C++ code doesn't do anything fancy either
<cr1901_modern>
(when calling into Qt*)
<cr1901_modern>
Mouse clicks and drag events *are* delivered, so I think this lends credence to a float issue
<sb0>
where does QFloat come in?
<cr1901_modern>
QFloat is what Qt internally uses to represent a scene with graphical elements
<sb0>
anyway, the solution of doing drags in pixels and then updating the value sounds ok to me
<sb0>
what exactly are the problematic zoom level and drag amounts you have right now?
<sb0>
you drag by 1e-12, but what was the value to begin with?
<cr1901_modern>
I didn't actually store that information... let me add a print statement for that
<cr1901_modern>
The zoom level where I start having problems is approx 1px == 1e10
<sb0>
so you zoom out, and cursors at at zero, and you cannot move them anymore?
<cr1901_modern>
C. I was testing the range of zooms to make sure everything worked correctly and then ran into that problem.
<cr1901_modern>
So I set one of the sliders to 1e15, and then zoomed out until both sliders were in view
<cr1901_modern>
(according to my commented out test code anyway :P)
<sb0>
anyway, even with double precision 1e15 + 1e-15 == 1e15
<cr1901_modern>
Mousemoves stop being honored somewhere between a zoom-out of 1.1e-12 and 9.21e-13
<sb0>
so if you rely on the exactness of FP for cursor moves, it will definitely break in the pathological case where one cursor is at 1e15, you zoom in on it all the way, and try to move it
<sb0>
what worries me with the "drag in pixels + update value later" is that the value and the cursor position can accumulate errors
<sb0>
e.g. you do many small drags and all get rounded to zero, so the value fails to change
<sb0>
what about keeping an internal representation with higher precision, e.g. using Fraction or Decimal?
<cr1901_modern>
Hold that thought for a second...
<sb0>
you keep a single high-precision state, and convert that to float or pixels when appropriate
<cr1901_modern>
I just found out that zoom-in is even worse; mouse events continue to be honored at zoom ins of 1e13 or more. However, starting at approximately 6e12, drags will not move the slider to the next pixel. In fact, the slider won't be moved until I have dragged either slider for a number of pixels!
<cr1901_modern>
This is in spite that during further zoom-ins, Qt will move each slider to the correct pixel location
<cr1901_modern>
So at large zooms, mouse drag loses pixel-level precision, and at far zooms, mouse drag doesn't work at all
<cr1901_modern>
I think using a high-precision state and converting to the proper coordinate system might be for the best, as you say
<cr1901_modern>
I have a feeling I'm not using QGraphicsView in a way that's intended.
<sb0>
the state can be an integer in units of 1e-13 (or similar), since python has bigints...
<sb0>
*1e-15
<sb0>
though Fraction/Decimal may be easier to use anyway, and won't introduce an arbitrary constant
<cr1901_modern>
Arbitrary constant?
<sb0>
that 1e-15 unit.
<sb0>
hm actually Decimal isn't arbitrary precision. but Fraction is
<sb0>
plus it has this ugly global context that feels like doing asm fpu programming
<cr1901_modern>
The only FPU I've ever programmed was... errr, nevermind. You mean bigint/decimal have global state? I've never actually used them
<sb0>
Decimal has global state, python ints and Fractions don't
<cr1901_modern>
I added some more print statements: Yea, GraphicsView gets utterly fucked at extreme zooms. At large zoom outs, Qt will only move the slider by one unit in the X-direction. When one pixel represents ~9e11!
<cr1901_modern>
At large zoom-ins, Qt will move the slider by the correct floating point fraction of units, but won't update the display properly
<sb0>
can you make Qt not know anything about the zoom?
awallin has joined #m-labs
rohitksingh has joined #m-labs
acathla` is now known as acathla
acathla has quit [Changing host]
acathla has joined #m-labs
<sb0>
@#>$@!! pyqt
<sb0>
create a QMainWindow in a function, if your only reference to it is in the function's local namespace, that window mysteriously disappears
<whitequark>
did you return from the function?
<sb0>
yes
<whitequark>
well, duh
<whitequark>
its destructor got called. what do you expect?
<sb0>
that stuff that is shown on the screen doesn't disappear because of GC concerns?
<whitequark>
that's a wrong thing to expect
<sb0>
what's difficult with keeping an active reference to every widget that is currently shown?
<whitequark>
"shown/hidden" is irrelevant to "created/destructed"
<whitequark>
this is the exact same behavior as, for example, if you opened a socket in raw Python
<sb0>
yes but that makes sense, because you need the socket to do anything with it
<sb0>
whereas a window shown on the screen should be capable of continued interaction with the user
<sb0>
no matter if the goddamn function that created it returned it or not
<whitequark>
that behavior still doesn't make sense
<whitequark>
you've created a graph of objects that's not connected to anything else in your program
<sb0>
and?
<whitequark>
and they should be deleted. that's how memory management in python works
<sb0>
i just want a window that sits there, displaying something static. why do i need to keep a reference to it?
<whitequark>
because you want it to keep sitting there?
<sb0>
i wonder if it wouldn't get GC'd even, if I put it in a separate object graph from the rest of the python program, with some of its own callbacks etc.
<whitequark>
it should be
<whitequark>
anyway, there are more issues, for example, what if you set a timer?
<sb0>
well that's silly then, i called widget.show(), and it should stay there and not get GCd until I call widget.hide() or similar
<whitequark>
it shouldn't get deleted just because your window got hidden
<whitequark>
again, the hidden state is completely irrelevant to memory management
<whitequark>
I don't know where you get the strange idea that it should be
<sb0>
yes, it should get deleted because it's hidden *and* the program doesn't have active references to it, of course
<whitequark>
it doesn't matter that it's hidden
<whitequark>
"hidden" is just a state. maximized, minimized, hidden
<sb0>
I understand how they implemented that and I find it silly
<whitequark>
I find the idea that a UI system should keep some hidden internal references to any object just because of its state even more silly
<whitequark>
anyway, if I set up a timer, it should fire until forever, not until someone hides the window
<whitequark>
it's not like keeping a reference to your windows is hard, anyway
<sb0>
no, but it paves the way for some obscure bugs
<whitequark>
that's exactly my point, adding that hidden reference thing would produce *even more* obscure bugs
<sb0>
what if some part of your application suddenly disappears because the cyclic GC kicked in?
<whitequark>
e.g. the one with the timer...
<sb0>
yeah? same treatment, keep an active reference to the timer until it is stopped?
<sb0>
that's what the user would need to do manually otherwise anyway
<whitequark>
sb0: there's something broken with kc705 and flterm
<sb0>
I vaguely remember that it worked with older packages
<whitequark>
I have very little surprise at conda's brokenness
<sb0>
it is useful, helps me check that i flashed/loaded a recent version and not using the months-old one in flash
<sb0>
it helps with the way i do development, i'd be ok with a git id as well
<sb0>
it'll be even better, obviously
<whitequark>
ok, I'll leave it for now
<whitequark>
wtf
<whitequark>
oh, just shadowing
rohitksingh has quit [Ping timeout: 260 seconds]
rohitksingh has joined #m-labs
<whitequark>
sigh. llvmlite is garbage
<whitequark>
their whole approach is trash
<whitequark>
it doesn't work decently
bentley` has quit [Ping timeout: 240 seconds]
<whitequark>
sb0: ping
<sb0>
whitequark, pong
<whitequark>
well, the story goes like this
<whitequark>
i implemented the attribute writeback system
<whitequark>
i even added support for fire-and-forget RPCs, given that it was like 10 LOC
<sb0>
good!
<whitequark>
on top of that, i made a very clever little system utilizing shadow memory that only writes back modified attributes
<whitequark>
with overhead of six instructions per attribute write (one store and one load)
<whitequark>
... except, well
<sb0>
what is the slowdown for ttl.pulse()?
<whitequark>
12 instructions
<sb0>
seriously, that function is already borderline as I understand, adding any instruction to it is highly unwelcome
<whitequark>
(less if it's inlined)
<whitequark>
but that's not the issue, unfortunately
<whitequark>
see, true to its name, it only writes back /modified attributes/
<whitequark>
when you do something like self.ts[1] = 1.0, it does not modify any attribute.
<whitequark>
(or any other construct with interior mutability)
<whitequark>
shall I scrap it, or do you have any idea how to fix that?
<sb0>
please scrap it, i'm worried about the general slowdown that this bring, the additional compiler code complexity, and the time it takes to sort out details like this mutation issue
<whitequark>
complexity is not the issue here, it's very simple
<sb0>
well, it all adds up...
<whitequark>
there is a byte per attribute, and the object id plus attribute index are used to store 1 there
<sb0>
I mean the compiler LOC and its maintainability
<whitequark>
yes
<whitequark>
it is not complex to do the above
<whitequark>
the rest of attribute writeback system is much more complex, for that matter
<whitequark>
but I can't imagine any easy way to fix the mutability issue anyway.
<whitequark>
and it's specifically on lists, which will be the major cause of slowdown.
<whitequark>
oh, wait, no, it's even worse.
<whitequark>
it means I cannot even rely on a "appears on the lhs of an assignment" heuristic
<whitequark>
because you can do x = self.ts; x[0] = 1
<whitequark>
I have to write back ALL attributes
<sb0>
ah, yes, object support complicates things again...
<whitequark>
that's not really object support
<sb0>
my compiler didn't have objects, therefore no aliases, therefore not this problem
<whitequark>
of course it had, attributes are part of objects
<sb0>
runtime objects I mean
<whitequark>
sure
<sb0>
x = self.ts would work, but resolved at compile time
<whitequark>
so it's variable support then
<whitequark>
you really should have went with ML ;p
<sb0>
hmm not sure what the acceptability of ocaml is in this user base
<sb0>
but we can in the very far future support multiple languages on the device, why not
<whitequark>
that's the main problem, yes
<whitequark>
the other one is elegantly embedding ML into Python
<whitequark>
multiple languages on the coredevice is a very bad idea
<whitequark>
because you get a combinatorial explosion of features you have to support and test.
<whitequark>
inevitably, one language will be dominant, and the rest will bitrot
<whitequark>
happens basically every time someone attempts that
<cr1901_modern>
sb0: can you make Qt not know anything about the zoom? < Sure that's no problem if I use a Fraction or a bigint (I think I'm going to need both) to represent the current increment in 1e-15 units. I just thought it made sense to have Qt handle the zoom b/c yay built-in. Apparently, Qt and I have different definitions of "unlimited".
<cr1901_modern>
Oh sorry, didn't see the convo was still going :(
<sb0>
whitequark, at this point excise the bitrotten part. hopefully python :p
<whitequark>
sb0: yes, that will work
<whitequark>
then rewrite the runtime in Rust and the compiler in OCaml either, and we're talking about something
<whitequark>
(unfortunately not a realistic proposal)
<GitHub149>
[artiq] whitequark pushed 1 new commit to master: http://git.io/vuIHU
<sb0>
reading all this language stuff I keep thinking that LISP (and especially LISP machines) failed, while SAP makes 17+ billion a year selling crap such as ABAP
<sb0>
it's pretty disturbing
<whitequark>
speaking of SAP, take a look at Jane Street
<whitequark>
they implemented a domain-specific language for formally describing contracts (like futures and such) on top of OCaml
<sb0>
runtime in Rust, pretty sure the OR1k toolchain will crap out all over the place again =]
<whitequark>
Rust generates pretty boring code
<sb0>
and there is the problem of the TCP stack, though I'd be happy to see lwip replaced
<whitequark>
more boring than C++, in fact
<cr1901_modern>
I've talked to ppl in #rust-internals, and they say just having an LLVM port (or1k) is the simple part of porting Rust to a new backend. And a LLVM port is bad enough
<whitequark>
speaking of lwip, I want a proper TCPv6 stack in Rust anyway... for the vacuum stuff
<whitequark>
I've looked at porting Rust, there's no reason it won't run on OR1K with very little work
<whitequark>
we need to upstream OR1K first if we want to merge that though
<whitequark>
I'll do this after the deadline...
<sb0>
cr1901_modern, why would you need both?
<cr1901_modern>
need both what?
<sb0>
Fraction + int
<cr1901_modern>
oh, bigint and fraction
<cr1901_modern>
B/c the units are in increments of 1e-15, and the sliders can navigate up to 1e15. Let's assume the max zoom out is one pixel = 1e14 That's a range of num_pixels_on_axis*1e14/1e-15
<sb0>
nothing forces you to make the units in increments of 1e-15
<sb0>
the point of Fraction over int is it may help you get rid of this arbitrary constraint
<cr1901_modern>
Ahhh, I see what you mean now. I should probably keep three fractions around: one that represents the value at center of the screen, and another that represents the offset of the two sliders from the center
<cr1901_modern>
Add them together and convert to an appropriate representation, and that's what the spinboxes show
bentley` has joined #m-labs
<sb0>
whitequark, speaking of qt timers and GC: asyncio.ensure_future() also doesn't cancel the task just because you ignored its return value...
<sb0>
and if the timers were implemented in python they would have the behavior I want, not yours, unless someone made an explicit effort to use weakref
<sb0>
so I maintain that this GC stuff is an unwelcome seam of the qt binding
<whitequark>
hrm
<whitequark>
I guess you're right, yes
<sb0>
and btw, open sockets complain when they are GCd. like that minor bug we are seeing with the unittests right now...
<whitequark>
ok, yes, I agree
ylamarre has joined #m-labs
<GitHub107>
[artiq] sbourdeauducq pushed 3 new commits to master: http://git.io/vuLYR