Monday, 2017-09-25

*** tpb has joined #timvideos00:00
tpbTitle: Snippet | IRCCloud (at
*** Kamilion has quit IRC03:07
*** Kamilion has joined #timvideos03:17
*** rohitksingh_work has joined #timvideos04:01
*** sb0 has quit IRC04:18
tpbTitle: flterm/flterm.c at master · timvideos/flterm · GitHub (at
tpbTitle: Fix parsing of line-ending option by shenki · Pull Request #4 · timvideos/flterm · GitHub (at
*** Kamilion has quit IRC06:07
mithrocr1901_modern: ping?06:12
*** sb0 has joined #timvideos06:12
*** Kamilion has joined #timvideos06:18
tpbTitle: litex/ at master · enjoy-digital/litex · GitHub (at
*** CarlFK has quit IRC07:49
cr1901_modernmithro: Pong. Sorry, I saw your message almost immediately, but didn't want to respond till I had some good news. First the bad news:08:49
cr1901_modernI didn't get much done the past week. libmodem still miscompiles and crashes at the tip of my HDMI2USB-litex-firmware tree.08:49
cr1901_modernGood news: I know for a fact that I introduced a compile option somewhere by accident that's causing the crash- idk what. In the interim, I forced using a known-to-work version of libmodem on the Opsis, otherwise compiling using the tip of my HDMI2USB-litex-firmware tree08:51
cr1901_modernOpsis firmware upload works!! Dual/Quad SPI bitbang works08:51
cr1901_modernSo all I have to do is fix the miscompilation error (and add working timer to qemu) and we're good to go!08:51
*** sb0 has quit IRC12:12
*** rohitksingh_work has quit IRC12:29
*** valessio has joined #timvideos13:06
*** sb0 has joined #timvideos14:11
*** rohitksingh has joined #timvideos14:45
*** CarlFK has joined #timvideos15:17
*** ChanServ sets mode: +v CarlFK15:17
*** rohitksingh has quit IRC15:30
mithrotumbleweed: ping?20:17
tumbleweedmithro: pong20:23
mithrotumbleweed: So regarding, your new line pull request20:24
mithrotumbleweed: I'm pretty sure the change to firmware/stdio_wrap.c is wrong?20:25
mithrotumbleweed: Either we should change firmware/stdio_wrap to do "\n" to "\r\n" replacement and remove "\r\n" from all the strings - or firmware/stdio_wrap shouldn't touch the strings and we should use "\r\n" everywhere?20:26
tumbleweedoh, LF,CR?20:26
mithrotumbleweed: Hrm?20:27
mithrotumbleweed: I'm talking about this pull request ->
tpbTitle: Use CRLF line-endings by stefanor · Pull Request #341 · timvideos/HDMI2USB-litex-firmware · GitHub (at
tumbleweedI'm asking what you think about that change is wrong20:28
tumbleweedand I'm guessing it does LFCR20:28
tumbleweedto answer your more general questino: yeah, there's no reason to use CRLF internally, if there's some kind of io driver for network or serial termianls that translates to CRLF20:28
mithrotumbleweed: Either we should change firmware/stdio_wrap to do "\n" to "\r\n" replacement always (and remove "\r\n" from all the strings) -- **or**  we should use "\r\n" everywhere and firmware/stdio_wrap shouldn't touch the strings.20:29
tumbleweedyes, I agree about that20:29
tumbleweedbut that does need coordination with the submodules20:29
tumbleweedbecause there are prints all over the place20:29
*** Ravenheart has quit IRC20:32
mithrotumbleweed: I like the idea of firmware/stdio_wrap doing the translation because of the prints all over the place20:32
mithrotumbleweed: So, do you want to change that pull request to do that?20:34
tumbleweedthat is pretty much what it's doing20:35
tumbleweedjust not very elegantly20:35
tumbleweedit changes all the (non-wrapped) printfs20:35
tumbleweedif it did a little more inspection and translated '\r?\n' -> '\n' in the wrapper, then I could drop the changes to mdio.c20:36
mithrotumbleweed: Hrm? If you are doing the translation in stdio_wrap, we should remove all the other \r\n right?20:57
tumbleweedno, because not everything uses the wrappers21:00
tumbleweedthe wrappers provide wprintf, but there are some printfs scattered around21:00
mithrotumbleweed: Where wprintf isn't used there is normally a special reason?21:01
mithrotumbleweed: But the wprintf related should be fixed then?21:04
tumbleweednot sure what you're asking21:05
mithrotumbleweed: If the wrapping functions are doing '\r\n', then we should remove all '\r\n' from the strings which are being sent to the functions?21:07
mithrotumbleweed: Happy to merge it then21:14
tumbleweedOK, I'll have a shot at it21:14
tumbleweedstring manipulation in C. So much fun21:15
tumbleweedesp without dynamic memory allocation21:15
tumbleweedthe other way around (have everyone do CRLF everywhere, and translate to LF if needed) would be far simpler memory-wise :)21:16
mithrotumbleweed: Use static buffers?21:20
tumbleweedyeah, I have to21:20
tumbleweed(or call the wrapped prints multiple times)21:20
tumbleweedI guess I'll crib the buffer size from the telnet bit21:21
mithrotumbleweed: Yeah - you can't call a function with va_list multiple times21:21
tumbleweedthat's true21:21
mithrotumbleweed: It appears to work at first until it doesn't21:21

Generated by 2.13.1 by Marius Gedminas - find it at!