<GitHub156>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vYmzw
<GitHub156>
artiq/new-py2llvm 9db199c whitequark: Handle closure effects appropriately in LocalAccessValidator.
cr1901_modern has quit [Remote host closed the connection]
<whitequark>
argh, python slice syntax is COMPLEX
<whitequark>
it does so many things at once
<whitequark>
so many things can go wrong
ylamarre1 has quit [Ping timeout: 244 seconds]
<whitequark>
like... one, two, three, four exception sites per [:]
cr1901_modern has joined #m-labs
<rjo>
python slice syntax is the best thing for numerics since sliced bread!
<rjo>
it is simply awesome. look at what you can do with it in numpy.
<rjo>
but for APython i think you can drop most of it: bounds checks, negative indices and non 1-stepsize. and forget about extended indices (index by array)
<whitequark>
well, i already almost implemented the first three
<whitequark>
as for extended indices, these don't work on lists anyway
<rjo>
for some things in numerics python slice syntax is is actually too simple. it would have been great it if beaties like numpy.einsum could have been done within the slice syntax alone.
<rjo>
*beauties
<sb0>
rjo, pyqtgraph can remember dock layout. every other saved item needs to be implemented manually one-by-one, of course.
<cr1901_modern>
whitequark: How do you know there's 4+ different exceptions from ":" (I guess looking at the Python source code, but maybe it's documented?)
<whitequark>
I looked at the code I generate for the slice.
<whitequark>
How do I know it's correct? Obviously, that's because I wrote it.
<cr1901_modern>
I thought throwing those exceptions was based on some behavior that Python mandated, not necessarily due to your implementation. But if I still misunderstand, I'll let the question go... not enough energy to parse explanation.
<whitequark>
sure, it's based on what CPython does
<whitequark>
there's no real spec. you can read the source but i prefer enumerating every possible case and poking the interpreter with it. it's faster
<cr1901_modern>
Lol, certainly a valid way to get the answers you seek
<rjo>
Qt has saveState() and saveGeometry() and QSettings which would also automatically save dock state and geometry but not for us since the QtDock* is pretty much bypassed by pyqtgraph dockarea.
<sb0>
pyqtgraph has a similar function. but all other state (e.g. content of text entries) needs manual saving
<rjo>
yes. but apart from geometry we would only need the state of the dynamic experiment pages' widgets.
<rjo>
damn visual studio took 6 hours to install a simple update...
<sb0>
plus the display (plot) settings
<rjo>
ack.
<GitHub127>
[artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/vYYR3
<GitHub127>
artiq/new-py2llvm 2b9ac34 whitequark: Verify LLVM module in compiler.textbench.jit.
<GitHub127>
artiq/new-py2llvm 65121b4 whitequark: Rework internal logic of slices.
<whitequark>
sb0: the way I would recommend solving it is looking whether the cursor is at the last column when you are adding text
<whitequark>
and if it is, moving it to the last column after adding text
<sb0>
it's a QTableView, but yes, I'm looking at doing that right now ...
<whitequark>
(s/cursor at the last column/view position at the last row/ or something)
<sb0>
I wish it would be built into Qt instead of e.g. this stupid "what's this" that no one uses
* whitequark
shrugs
<whitequark>
i don't think every three-line feature should be built into the public API and bloat it
<sb0>
this one definitely should. many applications (and particularly open source ones) have irritating autoscroll behavior that fights against the user when data is added
ylamarre has quit [Quit: ylamarre]
<sb0>
also it may be 3-line, but those 3 lines require digging into Qt and why, for example, there is a rowsAboutToBeRemoved callback but no rowsAboutToBeInserted
stekern has joined #m-labs
<sb0>
this last point is pretty annoying
<whitequark>
hm that's true I guess
<whitequark>
didn't "trolltech" give you a hint :p
key2 has quit [Quit: Page closed]
kyak has quit [Ping timeout: 240 seconds]
<sb0>
unlike the view, the model has both signals (note signal, not callback... another typical qt annoyance) so I guess I'll use that
<whitequark>
sb0: opinion: misoc should do out-of-tree builds
<whitequark>
also yay i brought pipistrello up
<rjo>
whitequark: yes. misoc needs to be cleaned up. remove source code/documentation/empty stubs/repeated code from the python modules and make the python stuff a module. and out-fo-tree builds.
<rjo>
make the python stuff a package.
<rjo>
and flatten the namespace. the imports from misoc look like java.
<cr1901_modern>
On a possibly related note, I'm curious as to why mibuild was merged into migen
<cr1901_modern>
(well I guess since it's a separate package, it is technically still is a separate project, giving it some thought)
<whitequark>
hm
<rjo>
why would you _not_ merge it? migen is predominantly used with mibuild and the other way around. and mibuild does not add further dependencies. it just frees you of keeong track of more packages and keeping them in sync.
<rjo>
keeping
<whitequark>
hm, the user_leds 2-4 do not work on pipistrello
<whitequark>
2-3
<whitequark>
i wonder why
<cr1901_modern>
rjo: My logic was: Migen: core language + simulation, mibuild: Provides synthesis, MiSoC: Uses Migen/mibuild to create a SoC framework
<cr1901_modern>
Not saying it's *sound* logic, but it was my logic
ohama has quit [Ping timeout: 255 seconds]
ohama has joined #m-labs
<rjo>
with that logic you would also suggest python splits itself into ~100 packages, one per stdlib component. that does not help. and there it is even worse: `telnetlib` has little to do with `fraction`.
<whitequark>
some languages do this, e.g. rust
<rjo>
yes. for python the fat stdlib has been a great advantage.
<whitequark>
well, you need a functional package manager
<whitequark>
python has what, three, none of which completely work?
balrog has joined #m-labs
<rjo>
at least four package formats. that is a mess.
<cr1901_modern>
rjo: Yes, all things being equal, I'd prefer a minimal stdlib to a big one. However, I've noticed that regardless of the language I try to only use the OS-/implementation-provided stdlib.