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
ylamarre has quit [Read error: Connection reset by peer]
ylamarre has joined #m-labs
fengling_ has joined #m-labs
ylamarre has quit [Ping timeout: 246 seconds]
Mon_ has joined #m-labs
Mon_ is now known as Guest22347
Guest22347 has quit [Client Quit]
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 Guest28624
Guest28624 has quit [Quit: This computer has gone to sleep]
rohitksingh has joined #m-labs
fengling_ has quit [Ping timeout: 245 seconds]
fengling_ has joined #m-labs
Mon_ has joined #m-labs
Mon_ is now known as Guest10373
Guest10373 has quit [Quit: This computer has gone to sleep]
<whitequark>
found the conda bug
<cr1901_modern>
whitequark: Should we have pyqt and qt5 in m-labs conda repo as well? The pyqt provided by conda (I THINK anaconda provides pyqt) has a version conflict with py3.5 at least on Windowss
<whitequark>
well, yes, that's broken in anaconda
<cr1901_modern>
I can confirm that pyqt builds fine with python3.5. Unfortunately, this would also bring in Qt5 itself as a dependency b/c Qt doesn't provide a VS2015 package
<cr1901_modern>
so it has to be built from source (which I can confirm works as well)
<whitequark>
I would rather anaconda fix that
<sb0>
I think Joe got the GUI to work on windows ...
<sb0>
not totally sure what version it was
<cr1901_modern>
HDF5 (not h5py) is kinda broken on VS2015... only 77% of test pass, and the build system won't actually provide the installer
<cr1901_modern>
I suppose the easy thing here would be to blame Windows for having broken library path management (not like any *nix would have problems find external libraries that Python packages depend on)
nicksydney has quit [Remote host closed the connection]
<whitequark>
fortunately I think I can work around that locally
<GitHub178>
[artiq] whitequark pushed 1 new commit to master: http://git.io/vWofq
<GitHub178>
artiq/master f384142 whitequark: conda: work around conda/conda@1740.
rohitksingh has quit [Ping timeout: 256 seconds]
travis-ci has joined #m-labs
travis-ci has quit [Client Quit]
<whitequark>
haha, amazing, now it just gets into an infinite recursion loop
<whitequark>
I wish we could just ship conda in m-labs channel... that would solve everything
<whitequark>
hm, actually, can't we?
<sb0>
how responsive are they?
<whitequark>
I have no idea. no one has ever answered any of the previous issues I've opened
<whitequark>
they did apologize when I ranted about the outage on twitter so that's ... something? I dunno
<GitHub94>
[artiq] whitequark pushed 1 new commit to master: http://git.io/vWoYV
<GitHub94>
artiq/master 372bc90 whitequark: Revert "conda: work around conda/conda#1740."...
fengling_ has quit [Ping timeout: 245 seconds]
Mon_ has joined #m-labs
Mon_ is now known as Guest87057
travis-ci has joined #m-labs
travis-ci has quit [Client Quit]
Guest87057 has quit [Quit: This computer has gone to sleep]
ylamarre has joined #m-labs
Mon_ has joined #m-labs
Mon_ is now known as Guest50389
rohitksingh has joined #m-labs
<mithro>
sb0: what is your thoughts on "real operating systems" on MiSoC? RTEMS seems to be what you used for milkymist? Is uClinux or NetBSD a better option?
<cr1901_modern>
NetBSD requires an MMU, but I would be immensely interested in seeing a port of that for LM32 or or1k
<cr1901_modern>
(More correctly, porting NetBSD to an MMU-less system is an open project)
<ysionneau>
mattt@netbsd started a port of NetBSD on OpenRISC but I don't know the status of that
<sb0>
mithro, there's nothing really good. artiq uses bare metal.
<sb0>
mithro, nuttx maybe ...
<cr1901_modern>
sb0: Would a bare metal Lisp interest you? lol
<mithro>
sb0: I'm after something which can do some simple telnet+http
<sb0>
the bare metal API of lwip is a pain to use in plain C
<sb0>
also, lwip breaks in the most obscure ways possible should the magic numbers in lwipopts.h be wrong
<sb0>
which is a horrible PITA to debug and cost me maybe a week on artiq already
<mithro>
RTEMS has the advantage of already having DMX / MIDI :)
<cr1901_modern>
sb0: My plan was to read a bunch of papers on Lisp starting with McCarthy's original implementation, and then implement a Lisp in LM32 assembly
<cr1901_modern>
since C is utterly broken for the type of fine level of jump control that you need
<ylamarre>
cr1901_modern: You know MIT did release the verilog for their original LISP machine?
<whitequark>
why? just compile one of the bajillion scheme implementations
<cr1901_modern>
On bare metal?
<whitequark>
sure, plenty of those, decent ones too
<whitequark>
I personally ported PICOBIT to STM32
<whitequark>
(but it's ridiculously underpowered for the kind of hardware ARTIQ has)
<cr1901_modern>
And what about the speed loss b/c C has to implement continuations in a manner that guarantees tail recursion?
<sb0>
the macros you find in some lwipopts.h examples also are subtly wrong due to floating point rounding errors, too
<whitequark>
you just write nonportable code
<cr1901_modern>
Lol, fair enough
<whitequark>
anyway, the issue is speed loss, but for other reasons
<whitequark>
ARTIQ is realtime so you need a realtime GC
<whitequark>
there's the treadmill, but the treadmill is only realtime when all you have is cells
<whitequark>
and cells are ridiculously inefficient for... pretty much anything
<cr1901_modern>
You linked me a paper a while back with a realtime GC
<cr1901_modern>
MYCFA algorithm
<whitequark>
like, structure access is linear in structure size. string access is linear in string size.
<sb0>
so you are debugging crap like your TCP sockets running at 10 bytes per second on 100M ethernet for no apparent reason, and you have to trace that back to a rounding error in a macro in some crap example that worked for their numbers but not yours
<mithro>
sb0: Has anyone used RTEMS with misoc (rather then the older milkymist firmware?)
<cr1901_modern>
whitequark: is MYCFA == treadmill, or different algorithm?
<whitequark>
if you /have/ to use a fancy language for this, go for rust. it explicitly supports bare metal, has existing libraries, and does not mess with ARTIQ's intrinsic constraints
<whitequark>
at this point rust is stable enough, in my opinion, to be used for this for real
<cr1901_modern>
Is the lm32 port of LLVM ready? I do know that just b/c an LLVM backend exists doesn't imply that Rust can use it properly (MSP430 comes to mind)
<whitequark>
lm32 port of LLVM will not be ready in foreseeable future, use or1k
<sb0>
mithro, no
<whitequark>
the existing code is worthless and i do not currently see anyone with the capability of quickly producing a decent backend
<sb0>
mithro, I also have interesting RTEMS debugging stories
<whitequark>
would take me 3-4 months, optimistically
Guest50389 has quit [Quit: This computer has gone to sleep]
<sb0>
mithro, that being said, if you copy the lwipopts from artiq, it should run correctly on misoc
<whitequark>
nothing, writing a compiler backend just takes time
<sb0>
and the lwip code isn't as dirty as rtems
<whitequark>
especially if you're writing it in C++
<mithro>
Are you using lwip with liteeth, or?
<sb0>
yes
<mithro>
sb0: okay
<cr1901_modern>
I gotta say, I made it further into understanding GCC's backend than I did LLVM (this is NOT saying much, btw); must be a learning curve problem.
<cr1901_modern>
ylamarre: No wasn't aware of that. I'm just interested in how a Lisp MIGHT be implemented internally.
<cr1901_modern>
McCarthy's original paper more or less describes it, but of course it's slow as hell
fengling_ has joined #m-labs
<sb0>
we also found a remarkable race condition with ISRs in the kernel implementation of queues, that had been there for years and was surprisingly easy to reproduce
<sb0>
in the end we got that damn thing to work, but it had not been easy
<sb0>
*has
<sb0>
the nice thing about it, though, is a lot of linux software will compile for it
<mithro>
Yeah, the fact you already have the older Milkymist stuff working is what makes it attractive.
<sb0>
mithro, i'd be interested to see how far one can go with lwip+picoro
<ylamarre>
IIRC, the CADR was pretty much a custom processor made to run LISP binairies faster. The lisp machine was a computer using a CADR. You'd still need their interpreter.
<mithro>
I'm looking to optimise for developer time at the moment - not enough people and such :-)
fengling_ has quit [Ping timeout: 245 seconds]
<sb0>
well, lwip works on misoc
<mithro>
Reusing what artiq uses is attractive from leeching off your efforts
<sb0>
picoro should be portable
<sb0>
writing an asyncio-style system with picoro and lwip should be fun
<cr1901_modern>
sb0: Picobit should be portable to MiSoC as well, taking a cursory glance. Or Rust.
<whitequark>
there's no point in porting picobit, it would not be useful for any tasks artiq needs
<sb0>
cr1901_modern, do those have working tcp/ip implementations?
<mithro>
Guess I'm getting ahead of myself, still got while bunch of other stuff to finish first :-(
<cr1901_modern>
sb0: Yes, it does but to add to whitequark's point... is adding this support specifically for Artiq, or in general?
<sb0>
?
<whitequark>
it appears that, surprisingly, there is no usable pure-scheme tcp stack
<cr1901_modern>
why? o.0;
<whitequark>
however, there is one for rust, rust-net
<whitequark>
*shrug* as i'm saying, your best chance at getting something actually useful for artiq is rust
<whitequark>
anything else is either too immature or doesn't have any reusable code
<whitequark>
(or doesn't work on bare metal anyway)
<cr1901_modern>
"whitequark: there's no point in porting picobit, it would not be useful for any tasks artiq needs" <-- sure, I thought sb0 was referring to just adding a REPL or coding environment to MiSoC in general.
<cr1901_modern>
Not just for artiq
<whitequark>
picobit does not have a REPL
<whitequark>
it's purely compiled
<cr1901_modern>
... oh
<whitequark>
read the paper
<cr1901_modern>
Hmmm, I'm very surprised if there's no pure Scheme TCP/IP stack. You'd think that'd be the first thing to implement with your shiny new environment.
<whitequark>
PICOBIT has one, but it's a toy
<whitequark>
I observe no others
<mithro>
The HDMI2USB firmware is rapidly growing features and at some point I think we will be forced to go to an OS to manage the complexity
<cr1901_modern>
mithro: unikernels seem to be gaining traction. Personally, they sound like a much better idea to me for embedded systems than a Linux
<cr1901_modern>
whitequark: If you know offhand, what does Picobit's TCP/IP stack lack that you'd want (I'm not expecting great performance from a TCP/IP stack in Scheme on a 8-bit micro anyway)? For my own future notes.
<mithro>
cr1901_modern: if Linux was already running, I'd be using that in a heart beat - the mindshare is just too big
<whitequark>
read the paper.
<cr1901_modern>
okay, I see it now
<cr1901_modern>
mithro: That's what I was afraid of :P
<mithro>
Might still end up using Linux because I'm more likely to find people who are willing to hack on that
<cr1901_modern>
Looks like picobit's TCP/IP doesn't buffer packets for code size reasons, so reliability will suffer.
<sb0>
mithro, it's surprisingly hard to find people to hack on the icky parts of linux that always break on minority architectures, e.g. the dynamic linker
<mithro>
sb0: Luckily I'm friends with quite a few Linux kernel hackers who like beer ;-)
<sb0>
ok so Joe is actually running X11 on windows and the GUI on a linux box
<mithro>
well, I should have been in bed 2 hours ago
<mithro>
thanks for the feedback / advice
<ysionneau>
mithro: you could use rump
<ysionneau>
and then use NetBSD drivers on top of that
<ysionneau>
rump does work on numerous environments, such as bare metal for instance
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined #m-labs
ylamarre has quit [Ping timeout: 255 seconds]
ylamarre has joined #m-labs
rohitksingh has quit [Ping timeout: 250 seconds]
<ysionneau>
mithro: wow, all the milkymist compatibility boards are already gone
rohitksingh has joined #m-labs
<sb0>
ysionneau, gone?
<ysionneau>
ah no
<ysionneau>
if I refresh the page now it's OK
<ysionneau>
it showed "all gone" before
Mon_ has joined #m-labs
Mon_ is now known as Guest92019
fengling_ has joined #m-labs
fengling_ has quit [Ping timeout: 245 seconds]
stekern has quit [Ping timeout: 264 seconds]
stekern has joined #m-labs
Guest92019 has quit [Quit: This computer has gone to sleep]
fengling_ has joined #m-labs
ylamarre has quit [Ping timeout: 244 seconds]
mumptai has joined #m-labs
fengling_ has quit [Ping timeout: 245 seconds]
fengling_ has joined #m-labs
fengling_ has quit [Ping timeout: 245 seconds]
ylamarre has joined #m-labs
mumptai has quit [Quit: Verlassend]
ylamarre has quit [Remote host closed the connection]