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> cr1901_modern, what's your plan?
<sb0> mithro, lwip?
<sb0> if you're feeling experimental, you could try mixing it with http://dotat.at/cgi/git?p=picoro.git;a=summary
<sb0> and do something a bit like asyncio
<mithro> nuttx looks kind of interesting
<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
<cr1901_modern> What's specifically difficult re: LM32?
<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.
<sb0> you can have a look at this folder https://github.com/RTEMS/rtems/tree/master/cpukit/libfs/src and figure out how the "path evaluation" works (or doesn't)
<sb0> that should scare you away from rtems
<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]
ylamarre has joined #m-labs
fengling_ has joined #m-labs
fengling_ has quit [Ping timeout: 245 seconds]
Gary__ has joined #m-labs
Gary__ has left #m-labs [#m-labs]
fengling_ has joined #m-labs
fengling_ has quit [Ping timeout: 245 seconds]
rohitksingh has quit [Quit: Leaving.]
stekern has quit [Ping timeout: 240 seconds]