<cr1901_modern>
Very nice :D. Saves me the trouble.
sj_mackenzie has quit [Ping timeout: 250 seconds]
Mon_ has joined #m-labs
Mon_ is now known as Guest8561
<mithro>
cr1901_modern: The TimVideos conda repo has an openocd version with miniSpartan6+ support pushed now
Guest8561 has quit [Quit: This computer has gone to sleep]
sb0_ has joined #m-labs
Mon_1 has joined #m-labs
sb0_ has quit [Read error: Connection reset by peer]
Mon_1 has quit [Quit: This computer has gone to sleep]
Mon_ has joined #m-labs
Mon_ is now known as Guest93039
Guest93039 has quit [Quit: This computer has gone to sleep]
Mon_1 has joined #m-labs
Mon_1 has quit [Client Quit]
<GitHub142>
[artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/vBTxS
<GitHub142>
artiq/new-py2llvm af43c66 whitequark: artiq_compile: set file_import prefix, like in artiq_run.
<GitHub142>
artiq/new-py2llvm 7384527 whitequark: transforms.interleaver: determine when inlining is not necessary.
<GitHub4>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vBkqS
<GitHub4>
artiq/new-py2llvm 9fc7a42 whitequark: pipistrello: expose LED{1..4} as RTIO channels.
<GitHub79>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vBkmV
<GitHub79>
artiq/new-py2llvm 03b4e40 whitequark: transforms.interleaver: fix IR type/value mismatch.
ysionnea1 is now known as ysionneau
Mon_1 has joined #m-labs
Mon_1 has quit [Quit: This computer has gone to sleep]
Mon_ has joined #m-labs
Mon_ is now known as Guest9627
Guest9627 has quit [Quit: This computer has gone to sleep]
<sb0>
whitequark, i think google chrome also has the "multiple processes one window" problem. you may want to look at how they do it.
<whitequark>
opengl
<whitequark>
chrome doesn't let child processes call WinAPI, because that would be incredibly insecure
<sb0>
whitequark, for the tab processes? which are running trusted google chrome code?
<sb0>
it seems qt supports opengl output, so we could use it too, but then we have to forward mouse/keyboard events through IPC and it sounds hairy to me
<sb0>
it might involve c++. eek.
<whitequark>
sb0: yes, of course
<whitequark>
because trusted chrome code contains vulnerabilities in e.g. DOM implementation
<whitequark>
so, unless you sandbox it, this is how malware will escape
<whitequark>
it's not enough to sandbox untrusted code, you have to sandbox everything that can take untrusted input at all
<sb0>
so the chrome subprocesses are barred access to the filesystem and all?
<sb0>
ok. anaconda will again get in the way as it only ships qt4, plus qt5 introduces a minor qtreeview display bug that artiq tickles
<sb0>
artiq gui is otherwise compatible with both 4 and 5
<cr1901_modern>
Oh... I thought artiq was a purely qt5 thing. That's okay. I'll just use the Qt 4.8 documentation as a reference.
<sb0>
i'm not sure what to do with the qt bugs. they seem painful to fix...
<cr1901_modern>
I've... just accepted that Qt has bugs/work around them. None of the widget toolkits are exceptionally great, IMO.
<whitequark>
qt is pretty great
<cr1901_modern>
I do think Qt is the best (by a large margin). I still would rather use native toolkits, but I understand why that's not ideal in many cases.
<whitequark>
if you want to use native toolkit on Windows, you pretty much have to use .net
<cr1901_modern>
You can still use C/C++. Or did that change for Windows 8 and up?
<cr1901_modern>
I know Microsoft REALLY wants me to use .net, but the full API is available through C++ (and it's relaxed interpretation of C).
<whitequark>
no, I mean, you have to use .net to stay sane
<whitequark>
and from win10 onwards in some cases you only have managed code, too
<cr1901_modern>
Do you have an example offhand? That's concerning.
<whitequark>
use google
<cr1901_modern>
I'm way past the point of sanity. But I understand what you mean.
<whitequark>
and besides, it's long overdue, it's ridiculous to not use managed code for most things...
<cr1901_modern>
Okay looks like for now you're able to choose which parts are managed/which parts are unmanaged. I guess in the future, Qt will ask for access to parts that aren't available using unmanaged code.
Mon_ has joined #m-labs
Mon_ is now known as Guest2201
<cr1901_modern>
"whitequark: and besides, it's long overdue, it's ridiculous to not use managed code for most things..." Sure, for the presentation component of a GUI application. With my experiences with Mono however, I'm going to hold out if Windows idea of "cross-platform" is to write everything in C#/.NET and make everyone else run Mono.
Guest2201 has quit [Client Quit]
<whitequark>
there's nothing wrong with mono, and besides, *all* platforms run a .net runtime, not just non-windows
Mon_1 has joined #m-labs
<cr1901_modern>
Alright I'll take your word for it that there's "nothing wrong with mono". It's possible that it was my fault that the application didn't run properly, or the code I received was poorly written/out of date. Was not an enjoyable experience lol
ylamarre has joined #m-labs
<GitHub195>
[artiq] whitequark pushed 3 new commits to new-py2llvm: http://git.io/vBIJV
<GitHub195>
artiq/new-py2llvm 0bf425e whitequark: compiler.ir: maintain use lists while mutating instructions.
<GitHub195>
artiq/new-py2llvm d92b343 whitequark: compiler.ir: print basic blocks in reverse postorder for readability.
<ysionneau>
on Linux, Chromium (and to some extend Firefox) use seccomp to limit syscalls from "content" process
<ysionneau>
that's how they implement the sandbox
<larsc>
seccomp-bpf
<GitHub168>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vBItQ
<GitHub168>
artiq/new-py2llvm 8e96117 whitequark: compiler.ir: print even blocks without predecessors.
Mon_1 has quit [Quit: This computer has gone to sleep]
Mon_ has joined #m-labs
Mon_ is now known as Guest19026
rohitksingh has joined #m-labs
<felix_>
can i assume that the xon and xoff characters are never sent by the application running on the board? thats true for ppp over serial and the test prompt, but would break if someone tries to transfer binary data directly over the uart
Guest19026 has quit [Quit: This computer has gone to sleep]
<whitequark>
no, you cannot, RPC will send those
<whitequark>
ah wait, ppp filters those out? hm
Mon_1 has joined #m-labs
<felix_>
yes, ppp escapes those
<whitequark>
I think this might come up if you're loading a runtime via UART?
<felix_>
i'll have a look
Mon_1 has quit [Quit: This computer has gone to sleep]
rohitksingh has quit [Ping timeout: 264 seconds]
Mon_1 has joined #m-labs
<sb0>
felix_, you could add a CSR to the core that enables/disables xon/xoff and enable it only right before starting ppp
<sb0>
when the application enables it, it should escape xon/xoff
<felix_>
i was planning to implement that in the uart driver, so no additional csr needed. but having functions to enable and disable xon/xoff sounds like the way to go
rohitksingh has joined #m-labs
<sb0>
how can the uart driver do that nicely? there are fifos in the core
<felix_>
hmm, yes that would introduce additional latency
<felix_>
when using ppp with hdlc-like framing the hardware shouldn't escape xon/xoff, as ppp doesn't emit any xon/xoff bytes, but uses the byte which is normally used to escape xon xoff characters
<sb0>
did you mean: the uart driver escapes xon/xoff? or the uart driver generates xon/xoff for the purpose of flow control?
<felix_>
i'd definitely do the escaping in the uart driver, but i'm not sure where to do the flow control
<felix_>
so a csr for enabling xon/xoff flow control and doing flow control in hardware, but do the escaping in software would be the solution you prefer?
<GitHub98>
[artiq] whitequark force-pushed new-py2llvm from 8e96117 to a4525b2: http://git.io/vmI6O
<GitHub98>
artiq/new-py2llvm a4525b2 whitequark: compiler.ir: print even blocks without predecessors.
<sb0>
i think you cannot do xon/xoff flow control properly in software, considering there are fifos in the core
<sb0>
and yes, doing escaping in software, but it doesn't need to be supported now
<felix_>
there are bigger buffers in the driver, which can easily compensate that
<sb0>
just disable xon/xoff flow control in the hardware until you run ppp
<sb0>
so why is ppp failing?
<felix_>
the ring buffer in the driver looses butes
<felix_>
*bytes
<felix_>
the 8k one
<felix_>
not the hardware one
<felix_>
at least incerasing the hardware buffer didn't change the packet loss rate much
<GitHub79>
[artiq] whitequark pushed 3 new commits to new-py2llvm: http://git.io/vBLJN
<GitHub79>
artiq/new-py2llvm f3da227 whitequark: compiler.ir: change argument order for BasicBlock.insert.
<felix_>
i write some test program toggeling a led when the software ring buffer overruns to be sure, ok? i highly doubt that the hardware buffers are the problem here, since the getting the bytes from the hardware buffer into the software buffer is interrupt-driven
Mon_1 has quit [Quit: This computer has gone to sleep]
<GitHub41>
[artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/vBLTk
<felix_>
i wonder if i just have missed jtag debugging support of the cores in misoc or if it isn't implemented. something like semihosting via jtag would be quite nice
<sb0>
felix_, how would jtag for the cores work?
<felix_>
there are some hardwaere block inside the fpga, which can be accessed via jtag and some projects use taht to debug softcore inside an fpga
<felix_>
let me look up which project that used
<GitHub159>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vBLuY
<sb0>
whitequark, cool. can you merge it into master?
<sb0>
i'll do some testing tomorrow
<whitequark>
no, it doesn't work on embedded functions
<whitequark>
the *interleaving* works
<whitequark>
the devirtualizer doesn't
<whitequark>
and it will not work today, because I'm already past MTR's service hours.
<felix_>
the hardware block inside the s6 fpga is called BSCAN_SPARTAN6; at least microblaze, openrisc and leon3 can use that for debugging over the same ftdi jtag interface which is used for configuration of the fpga
<felix_>
i've only used that with microblaze and the xilinx toolchain though
<felix_>
openocd has support for openrisc debugging via xilinx bscan port
<whitequark>
assuming you have unlimited experience, yes
<cr1901_modern>
Hah, reminds me of how watchmakers used to contract out to people to make the gears, and how gears were made back in the 1600's were trade secrets/carried to the grave.
<cr1901_modern>
So yea, can be done, only if you have access to the knowledge of every machinist prior
<whitequark>
no, you just need to be a competent machinist & engineer. typical DIYer will probably not accomplish this task in reasonable time
ylamarre has joined #m-labs
mumptai has joined #m-labs
<whitequark>
sb0: ok, I guess you can start testing it now.