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
fengling has joined #m-labs
<sb0>
cr1901_modern, so what is the decision regarding the xilinx settings file on windows?
_rht has joined #m-labs
evilspirit has joined #m-labs
mumptai has joined #m-labs
<cr1901_modern>
sb0: The call is correct
<cr1901_modern>
In addition, I also added something else as a separate patch >>
<cr1901_modern>
Windows doesn't have a "set -e" like sh does. I added code for the generated batch file to fail gracefully if there's an error instead of continuing
<cr1901_modern>
sb0: I'll prepare the patches. Forgot to do it earlier b/c trying to debug a reproducible crash on my MiSoC target
fengling has quit [Ping timeout: 240 seconds]
evilspirit has quit [Ping timeout: 260 seconds]
<mithro>
sb0: How does the "mor1k" in use in misoc differ from the stock/upstream or1k?
sb0 has quit [Ping timeout: 248 seconds]
fengling has joined #m-labs
FabM has joined #m-labs
evilspirit has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
sb0 has joined #m-labs
mumptai has quit [Quit: Verlassend]
<sb0>
it does not
<sb0>
or well, misoc uses upstream mor1kx
<sb0>
mor1kx is a complete reimplementation of or1k which unlike the original does not suck in any major way
sb0 has quit [Quit: Leaving]
evilspirit has quit [Ping timeout: 240 seconds]
evilspirit has joined #m-labs
evilspirit has quit [Ping timeout: 276 seconds]
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
<GitHub151>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vVQiE
<GitHub151>
artiq/master 56af4e9 Sebastien Bourdeauducq: doc/installing: add note about example dependencies
<sb0>
52MHz on spartan6 isn't ridiculous like on virtex7, but not great either
_rht has quit [Quit: Connection closed for inactivity]
<sb0>
threads (at least in python) are ridiculous, as always
<sb0>
when a thread is blocking on recvfrom(), closing the socket from another thread does not cancel the operation
<sb0>
and even if python gave us pthread_kill(), which is almost a reasonable API, that would not work on windows
<whitequark>
you need to call shutdown first
<whitequark>
killing threads is impossible.
<sb0>
with pthread and signals, it works
<whitequark>
no, it doesn't.
<sb0>
it's a bit tricky, but doable
<whitequark>
it might look like it works, but it cannot possibly work, and there doesn't exist an environment where it works
<whitequark>
if you think it works, you're wrong
<sb0>
what's the problem with it?
<whitequark>
a thread owns resources and killing a thread will not release those
<sb0>
if the thread installs a signal handler, it can release them
<larsc>
it's still a bad concept
<whitequark>
sb0: no, it cannot
<sb0>
it can.
<whitequark>
nope. there is an inherent race condition
fengling has quit [Ping timeout: 240 seconds]
<whitequark>
a signal handler can always arrive in between acquiring a resource and recording it in some form of storage where the signal handler can release it
<whitequark>
and if you block signals using pthread_sigmask, then we're back on square one
<whitequark>
because it's basically the same as asking the thread nicely (by setting some flag), except nonportable and far more error prine
<whitequark>
prone
<sb0>
ok, yes there is the same issue as this idiotic asynchronous KeyboardError on python
<sb0>
but you can interrupt system calls with pthread_kill
<sb0>
*KeyboardInterrupt
<whitequark>
KeyboardInterrupt actually sets that flag, it doesn't jump out of the signal handler
<whitequark>
exactly because of what I elaborated above
<whitequark>
it looks asynchronous to Python code though, so the problem is repeated
<whitequark>
anyway, none of this is relevant in your case, simply call shutdown(O_RDWR)
<sb0>
yes, shutdown() does something, thanks
<whitequark>
Thread.kill is a """safe""" construct in, say, Java, because Java automatically inserts GC safepoints
<whitequark>
and it actually sets a flag and polls it on every safepoint
<whitequark>
much like Python, where there's an implicit safepoint after every instruction
<whitequark>
it still breaks if you kill something while it's inside a mutex and there's nothing you can possibly do to fix that if you want a kill that actually kills the thread in all cases, by design
<sb0>
so, shutdown() makes the thread recvfrom() fail, but it also does OSError: [Errno 107] Transport endpoint is not connected in the caller
<whitequark>
yes, that's exactly what should happen
<whitequark>
oh, you mean in the thread that calls shutdown?
<sb0>
yes
<whitequark>
sorry, SHUT_RDWR, not O_RDWR
<whitequark>
and try SHUT_RD instead of RDWR
<sb0>
yup, it's SHUT_*
<sb0>
I already tried...
<sb0>
I guess I could just ignore the OSError; after all, it's thread code in python, so of course it sucks
<whitequark>
this all has nothing to do with python whatsoever
<whitequark>
it's just unix
<sb0>
it's a mess of different things. if udp worked with asyncio and windows, I would not have to use threads. if pthread_kill() was available, I could terminate the thread in another way.
<whitequark>
no, you could not use pthread_kill safely
<whitequark>
at best, it's just exchanging one problem for another, not even a smaller one
<whitequark>
or1ksim is an instruction accurate simulator with a lot of features including flexbile configuration and gdb debugging
<whitequark>
>flexbile
<whitequark>
also, no mention of clang?
<sb0>
on windows, recvfrom raises OSError when another thread shutdows/closes the socket. on linux, it returns (b"", None)
<sb0>
it would have been too easy if both platforms had the same behavior
<whitequark>
this behavior is not specified in POSIX
<GitHub154>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vV7U3
<GitHub154>
artiq/master dbba41b Sebastien Bourdeauducq: dashboard/moninj: fix windows problems
<cr1901_modern>
And Winsock DEFINITELY doesn't return the same error codes/reasons as Linux/BSD, etc
<sb0>
i don't care what the excuse it. i just notice it sucks.
<sb0>
*is
<GitHub164>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vV7US
<GitHub164>
artiq/master 7d590af Sebastien Bourdeauducq: dashboard/moninj: use ephemeral UDP port
evilspirit has joined #m-labs
<whitequark>
"it sucks", also known as "i can't be bothered to learn how the API works"
<whitequark>
next step is usually reinventing the API, badly
<sb0>
absolutely. having to deal with different APIs on different OSes for no reason is a waste of time.
<sb0>
yes, there is a xkcd comic about this
<cr1901_modern>
Well, Windows has yet to finish evolving into a Unix
<whitequark>
you mean devolving
<whitequark>
Unix APIs are a collection of garbage even worse than WinAPI
<whitequark>
and the socket ones in particular
<whitequark>
well, not socket, file descriptor ones
<cr1901_modern>
I would love to see something different. I'm not optimistic, but it would be interesting
<whitequark>
it's not very hard to achieve, just run your software as a unikernel inside Xen
<sb0>
okay, one good thing today
<sb0>
git cherry-pick correctly handled file renamed across branches
key2 has joined #m-labs
<cr1901_modern>
Hmmm, that would be one way to make unikernels more usable as desktop OSes :P. Each app is essentially its own OS
<larsc>
one of the major problems with the Unix/Linux APIs is that there is no abstraction of events. E.g. you can wait on either a child process, a pthread condition or file IO, but not so that you wake up when either of the events happen
<GitHub135>
[artiq] sbourdeauducq pushed 3 new commits to release-1: https://git.io/vV7TB
<GitHub135>
artiq/release-1 e4833a3 Sebastien Bourdeauducq: dashboard/moninj: use thread instead of asyncio UDP (#39)
<GitHub135>
artiq/release-1 a6c17d3 Sebastien Bourdeauducq: dashboard/moninj: fix windows problems
<GitHub135>
artiq/release-1 e7d448e Sebastien Bourdeauducq: dashboard/moninj: use ephemeral UDP port
<larsc>
Windows actually can do that
<whitequark>
exactly
<whitequark>
you can use epoll+signalfd+timerfd+eventfd
<whitequark>
or, you can use kqueue, which has all that built in
<whitequark>
or, you're on some OS which has neither, and then you're screwed
<whitequark>
but not even any of those APIs allows you to wait on files being read from disk
<larsc>
the problem with kqueue is that everything is a special case
<larsc>
new type of a event? update kqueue ABI
<whitequark>
this is especially moronic in case of FUSE, because FUSE inherently blocks a lot
<whitequark>
not necessarily, .net handles it pretty nicely
<whitequark>
they have both asynchronous programming and lightweight threads (kernel threads with userspace scheduling)
<whitequark>
the latter concept was even ported to linux, with fairly large performance gains, but never upstreamed AFAIK
<larsc>
and even if you were to implement a proper framework with a good userspace ABI people would say you already have epoll() and friends just use that
<cr1901_modern>
Why would you use lightweight threads, as opposed to, cooperative multitasking?
<whitequark>
most unix people have not a shred of understanding of good API design
<whitequark>
probably self-selection
<whitequark>
cr1901_modern: external libraries, for one
<whitequark>
cooperative multitasking has no advantages over lightweight threads and many drawbacks
<whitequark>
most of which stem from the fact that lightweight threads are true kernel threads and cooperative threads / fibers are just a figment of imagination of some specific library
<whitequark>
they break TLS, blocking system calls, various identifiers...
<whitequark>
... instrumentation such as performance counters, profilers, etc, etc
<cr1901_modern>
Hmmm... *goes to learn more*
<larsc>
so what's the difference between the LWT and a regular thread then?
<cr1901_modern>
I'm having trouble visualizing how they break TLS (unless you meant that TLS is essentially impossible b/c there's no place to actually properly store TLS)
<whitequark>
you can create as many LWTs as you want without impacting scheduling time
<whitequark>
the only resources they intrinsically consume is 1) kernel objects and 2) stacks
<whitequark>
since stacks are lazily allocated, you get 4k+sizeof(kern_thread) per thread
<whitequark>
cr1901_modern: TLS is an OS interface, if a library stores something in TLS it expects to get it back in the same logical thread then
<whitequark>
cooperative threading libraries do an n:m mapping from cooperative to OS threads, with hilarious results
<cr1901_modern>
whitequark: "with hilarious results"? You mean coop libraries attempt to store multiple coop threads "TLS" (quotes intentional) in the same OS-level TLS?
<whitequark>
no
<whitequark>
external libraries that are unaware of cooperative threading
<whitequark>
they may use TLS even if they never use blocking syscalls. TLS has lots of uses. errno, for example
<cr1901_modern>
Oh... I see o.0;
<whitequark>
well, errno is unlikely to break, but other things well might
<cr1901_modern>
Well, you have brought up some excellent points.
<cr1901_modern>
Whatever replaces Unix, I do hope it at least inherits home directories and a way to prevent the PATH from blowing up
* cr1901_modern
glares at Windows on the latter count
<whitequark>
that's not an OS feature
<whitequark>
well, neither of these is, largely
<cr1901_modern>
UI feature?
<whitequark>
the first is UI, the second is libc
<cr1901_modern>
(My comment was inspired by the fact that I broke my Windows Path this morning and had to download a Path manager)
<larsc>
errno is already broken ;)
<whitequark>
well, yeah
<whitequark>
the things I had in mind were more along the lines of, say, OpenGL contexts
<larsc>
but to be fair it probably looked like a good idea 40 years ago
<whitequark>
... arguably, OpenGL is broken too
<cr1901_modern>
I always wanted an error variable that returned 3 possible values
<whitequark>
there shouldn't be any error variables.
<whitequark>
there should be a return value, which indicates a success or an error. error_or<Error, Value> or something
fengling has joined #m-labs
<cr1901_modern>
In GL, you call a function after getting the return value to get the error reason. Idk many C/C++ APIs that return structs with an embedded union to simulate variants.
<whitequark>
yes, because it's very awkward in C, and also unsafe
<whitequark>
yet another reason why C is a bad idea
<larsc>
but it probably looked like a good idea 40 years ago ;)
<whitequark>
MK is 43 years old, C is 44 years old
<whitequark>
*ML is
<whitequark>
so... no, I don't think that's a good excuse
<whitequark>
and ML wasn't even particularly pioneering in that area
<cr1901_modern>
And no doubt the concepts of ML predate high level langs
fengling has quit [Ping timeout: 240 seconds]
<cr1901_modern>
I guess the Unix guys needed something that didn't suck as much as assembly language, but still left "little" (quotes intentional) to the imagination.
<sb0>
whitequark, sooo...
<sb0>
you like qt, right? :)
<whitequark>
sure
<whitequark>
do you have a particularly obscure bug?
<sb0>
when the last row of a model is deleted, and selected, qt tries to select the next one when I call beginRemoveRows()
<sb0>
but since it is the last one, there is no next one, and it calls my index() method with an invalid row number
<sb0>
what should I return then?
<whitequark>
oh, that's easy
<whitequark>
QVariant()
<sb0>
is it even supposed to do that?
<whitequark>
mhm
<sb0>
it's pretty nasty behavior to call index with row >= rowCount()
<sb0>
unless my rowCount is broken. let me check...
<sb0>
nope. Qt did call index with row == rowCount()
<sb0>
okay, that works, and qt selects the row above instead
<whitequark>
index()Given a model index for a parent item, this function allows views and delegates to access children of that item. If no valid child item - corresponding to the specified row, column, and parent model index, can be found, the function must return QModelIndex(), which is an invalid model index.
<sb0>
qt is very annoying
<whitequark>
no, you just can't be bothered to read the documentation
<whitequark>
funny, given how much you insist I write it for ARTIQ...
<sb0>
what purpose does calling index() with invalid inputs serve?
<whitequark>
the purpose of defining calling index() with invalid inputs to return an invalid model index is that it's better than a crash or returning nonsense data
<sb0>
qt knew that row was invalid. it called rowCount() just before.
* whitequark
shrugs
<whitequark>
if it's defined, it can be called
<GitHub102>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vV7Z1
<sb0>
if this were artiq, 1) i would have tried to avoid calling user code with deliberately wrong inputs 2) if that could not be avoided, there should have been a big fat warning in the docs "artiq _will_ call your code with garbage, and you must handle it"
<whitequark>
yeah, and it's clearly documented to do so
<whitequark>
have you read the model/view programming guide before doing model/view programming?
<sb0>
I don't call this little phrase a "big fat warning"
<sb0>
and MVC doesn't necessarily implies all those nasty qt idiosyncrasies
<whitequark>
hm?
<whitequark>
Qt has an explanation of how specifically to use its model/view classes
<whitequark>
if you haven't read it, you have no moral right to complain when the API doesn't work as you expect