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
<rjo> whitequark: thanks!
<rjo> hmm memory usage still varies but the first three tests look good. will run it over night for more statistics.
<whitequark> wtf, llvm-or1k is ancient
<whitequark> apr 14
<cr1901> that's ancient?
<whitequark> that's 10 in LLVM years
<whitequark> generally, i would consider anything more than a month behind master as ancient
<cr1901> I wonder how they keep the Cpu0 tutorial up to date (they probably don't)
<whitequark> cpu0 is a completely third party project
<cr1901> I know, but at this point even the main website links to it as the canonical "how to port" reference. The official documentation is very out of date.
<whitequark> (anything outside of LLVM's SVN is)
<whitequark> the official documentation was never very useful
<cr1901> I've noticed
<cr1901> XD*
<whitequark> how to port: copy some of the existing backends, adjust until it works
<cr1901> It feels like modern archs can be divided into two categories- MIPS-like-minimalism and everything-else
<mithro> morning people
<mithro> well, really evening - but it is always morning on the internet! :)
<cr1901> I've slept maybe 2 hours? I suspect I won't be going back to sleep.
<mithro> cr1901: :(
<cr1901> Well, maybe I'll try in a bit. Just installing some software/watching YT videos to pass the time
<mithro> whitequark: yeah - I've seen that before :)
<mithro> whitequark: apparently you where/are working on a "JTAG UART" ?
<whitequark> um
<whitequark> JTAG UART?
<whitequark> do you mean that openocd bridge thing?
<mithro> whitequark: I mean a UART which you can access via your jtag cable
<whitequark> mithro: I'm like 90% sure you're not talking about me
<whitequark> it is not /inconceivable/ that I have a memory blackout and I have in fact worked on a device like that. but I certainly don't remember it.
<cr1901> mithro: that's rjo I believe
<mithro> cr1901: actually said it was rjo but for some reason I completed to whitequark
<sb0> ysionneau, your artiq_coreconfig did not close the comm device ...
<GitHub187> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vmwoz
<GitHub187> artiq/master 39c6bc9 Sebastien Bourdeauducq: coreconfig: use new database API (closes #75)
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#314 (master - 39c6bc9 : Sebastien Bourdeauducq): The build passed.
travis-ci has left #m-labs [#m-labs]
mumptai has joined #m-labs
<ysionneau> 01:17 < cr1901> Why doesn't the application crash on the next page fault where the library's page is not kept in the page cache? < library page is in main memory, if it is swapped out, it goes in the swap, then it can be retrieved from the swap. It is not retrieved from the FS
<ysionneau> so as long as you don't restart the process, it won't need or use the new library
<ysionneau> and it won't need to fetch again the old lib from the FS
<whitequark> not true, actually, program pages aren't mlock()ed and can be swapped out back into the filesystem
<whitequark> it's just an mmap(), not unlike any other mmap()
<whitequark> if that were true, you could DoS a multiuser system by building an executable with 100GB of .text and running it
<whitequark> instead, what happens is that mmap() maps an inode, and during upgrade, the file is unlinked and a new one is placed there under the same name
<ysionneau> so when removing a library you can make an already running program crash?
<whitequark> if you truncate it and rewrite instead of doing rm, in principle, yes
<ysionneau> when you say it's not mlocked, it means it's not going to stay in main memory
<ysionneau> it does not mean it won't go to swap
<whitequark> swapped *out* into disk
<whitequark> I mean, there's no difference between swap file and your executable file
<whitequark> swap file is used when you map anonymous pages
<ysionneau> well if it's put in the swap, then you can retrieve it, you don't care if the original was deleted or modified
<ysionneau> that's what I meant
<whitequark> oh, double negative
<whitequark> in practice some unixes return -ETXTBSY if you try to modify a .text section inside a file
<whitequark> but not Linux
<ysionneau> 10:48 < sb0> ysionneau, your artiq_coreconfig did not close the comm device ... < oops, indeed, sorry about that
<whitequark> ah, no, linux does it too
<whitequark> so that answers it: you can't modify it.
<ysionneau> well, I don't understand, I already updated openssl via apt-get while other programs were using it
<whitequark> ysionneau: you cannot modify a file
<whitequark> but you can unlink it and place something else under that name
<ysionneau> oh ok
<whitequark> unlinking a file doesn't remove it. that's why it's called "unlink"
<ysionneau> ok so cr1901 was right then
<whitequark> sure
<ysionneau> the file is not accessible from user space anymore but the kernel can still access it (by inode?)
<whitequark> well, of course it's accessible from userspace
<whitequark> you can access it via any fd you have open, or any memory mapping you still have
<whitequark> alternatively you can access it via any other name ('hard link')
<whitequark> and yes all that happens via inode
<ysionneau> ah yes, ok, thanks it's more clear
bentley` has quit [Ping timeout: 265 seconds]
<whitequark> I don't understand the purpose of else: in python's try:
<whitequark> "code ran when no exception is raised" so is it just... appended to body?
<sb0> no. in a try/except/else (that catches all exceptions), the else clause is ran if there is no exception
<sb0> *run
<sb0> whereas the body is run in all cases
<whitequark> if you append the content of else to the body, the exact same thing will happen
<sb0> no
<whitequark> example when not?
<sb0> prints hello2 and not hello1
<whitequark> appended to the *body*
<whitequark> that is, the statements inside try
<whitequark> not statements after try
<whitequark> anyway, the answer is that the exceptions raised inside the else clause will not be caught
<sb0> ah. yes
<whitequark> ugh. finally is incredibly annoying to implement correctly
<whitequark> annnnd... it's the last thing left to implement (excluding interleaving)
stekern_ has quit [Ping timeout: 264 seconds]
stekern has joined #m-labs
<sb0> whitequark, are you settled on libunwind?
<whitequark> sb0: why?
<sb0> just wondering if you tried it and how it went
<whitequark> ah. no, not yet, I don't have LLVM IR generation yet anyway
stekern has quit [Ping timeout: 255 seconds]
<whitequark> the roadmap is to finish the 'finally' clause, add source location support, add LLVM IR generation, including libunwind support, fix ARTIQ's dynamic linker, build libunwind for or1k, and finally add interleaving
<whitequark> thankfully the ARTIQ IR to LLVM IR transform is very simple, almost 1:1
<GitHub82> [artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/vmoUp
<GitHub82> artiq/new-py2llvm 3b661b2 whitequark: Fix environment corruption by ExceptHandler without a name.
<GitHub82> artiq/new-py2llvm f28549a whitequark: Add builtins.is_exception.
cr1901 has quit [Ping timeout: 260 seconds]
cr1901 has joined #m-labs
cr1901 has quit [Ping timeout: 260 seconds]
cr1901 has joined #m-labs
cr1901 has quit [Ping timeout: 246 seconds]
cr1901 has joined #m-labs
cr1901 has quit [Ping timeout: 246 seconds]
cr1901 has joined #m-labs
cr1901_modern has joined #m-labs
<cr1901> quit
cr1901 has quit [Quit: leaving]
<cr1901_modern> Now let's see if Pidgin, in spite of libpurple, is better behaved than irssi...
bentley` has joined #m-labs
kristian1aul has quit [Quit: leaving]
kristianpaul has joined #m-labs
kristianpaul has joined #m-labs
stekern has joined #m-labs
imrehg has joined #m-labs
kristianpaul has quit [Quit: leaving]
kristianpaul has joined #m-labs
kristianpaul has joined #m-labs
imrehg has quit [Quit: Leaving]
ylamarre has joined #m-labs
imrehg has joined #m-labs
imrehg has quit [Client Quit]
stekern has quit [Ping timeout: 246 seconds]
<sb0> whitequark, when will all this be done?
<whitequark> first two: today
<whitequark> IR generation: a day or two for everything except EH, plus some time for EH
<whitequark> I recall you wanted runnable code soon
<sb0> yes. set_results() still doesn't work from the device, for example.
<whitequark> ok, let me get non-EH parts out and I will add the syscalls and stuff
stekern has joined #m-labs
<sb0> god i hate qt so much
<cr1901_modern> Join the club
<sb0> even getting a callback when a selection is changed in a list is a pain
<cr1901_modern> I like the part where they reinvent half of the STL in 2015
<whitequark> no, they reinvented half of STL before you could expect STL to work at all
<whitequark> in early 90s
<cr1901_modern> I know. And they broke backwards compatibility with that design in Qt3
<whitequark> before, I dunno, 2005, STL was, broadly speaking, shit
<cr1901_modern> so why is it still around?
<sb0> sometimes you have to use signals, sometimes you need to overload a method
<whitequark> Qt 4 was released in, well, 2005
<cr1901_modern> Huh. Fair enough. I guess it's "unfortunate compatibility baggage", then.
<whitequark> that's had to be compatible with what, visual c++ 2003?
<whitequark> even VS2010 had barely usable STL
<cr1901_modern> Don't they just use Dinkumware's port now?
<sb0> ListView.selectedIndexes() returns a list of QModelIndexes, whereas the selection callback gives you a QItemSelection to describe what has been selected and you must call indexes() on it
<sb0> yay consistency
<sb0> and it's a selection *callback* for QListView, and selection *signal* for QListWidget. go figure.
<whitequark> yeah, list views are really annoying in Qt
<cr1901_modern> whitequark: Assuming you were around back then, can you confirm this :P? https://twitter.com/cr1901/status/622090905210613760
<whitequark> dunno
<whitequark> never actually cared to figure out
<cr1901_modern> Swapfiles for preemptive multitasking OSes must've been a very painful experience back in the 80's-mid 90's.
<whitequark> sb0: oh, also requires an analysis to catch uninitialized variable access
<cr1901_modern> It's hour 4 and Qt is still compiling. What was I thinking? I just wanted TeXMaker T_T. Well at least it's optimized for my current CPU I guess.
<cr1901_modern> Though I feel like I should be worried that there's a need to optimize a widget toolkit for e.g. AVX in the first place.
<whitequark> don't use gentoo
<cr1901_modern> Haha /s. I'm not.
<sb0> mh
<whitequark> so, uh. else: is not covered by except:, but *is* covered by finally:
ylamarre has quit [Quit: ylamarre]
<cr1901_modern> There's a good (one of many) article on somebody's website about why Gentoo is bad (no, I don't think compiling from source will automatically get me faster binaries), but can't find the link to it.
<whitequark> like except itself
<whitequark> god I hate this semantics
<whitequark> anyway, IR generator finally done
<whitequark> 2 files changed, 1607 insertions(+), 80 deletions(-)
<GitHub65> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vm6lX
<GitHub65> artiq/new-py2llvm e96bc3c whitequark: Add complete IR generator.
<cr1901_modern> Found it finally: http://fun.irq.dk/funroll-loops.org/
<sb0> " the result is undefined but the program will still be well-behaved"
<sb0> <3 Qt
<cr1901_modern> I wish it didn't take me so much concentration/energy just to grok modern CPUs, OS technologies, etc. Long gone are the days one can fully understand their platform it seems.
<GitHub147> [artiq] sbourdeauducq pushed 4 new commits to master: http://git.io/vm6yG
<GitHub147> artiq/master 4907991 Sebastien Bourdeauducq: sync_struct: docstring cleanup
<GitHub147> artiq/master 6b36d93 Sebastien Bourdeauducq: master,client: support repository rescan
<GitHub147> artiq/master 2576036 Sebastien Bourdeauducq: language,worker: preserve order of arguments
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#315 (master - dd7920f : Sebastien Bourdeauducq): The build passed.
travis-ci has left #m-labs [#m-labs]
<ysionneau> so, see you folks in 3 weeks!
<ysionneau> sb0: hires rtio is refactored but would still need cleanup ... it's very rough to say the least, and untested, it does synthesize though
<ysionneau> inout tests still pass
<ysionneau> I would need to add tests to output-only as well
<ysionneau> (and I added the override stuff)
<ysionneau> going to sleep, see you! :)
<rjo> see you! enjoy the vacation (i presume)!
mumptai has quit [Quit: Verlassend]