<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>
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)
<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
<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.
<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
<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.
<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