ChanServ changed the topic of #glasgow to: glasgow debug tool · code https://github.com/GlasgowEmbedded/glasgow · logs https://freenode.irclog.whitequark.org/glasgow · discord https://1bitsquared.com/pages/chat · production https://www.crowdsupply.com/1bitsquared/glasgow · no ETAs at the moment
furan- has quit []
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #glasgow
Getorix has quit [Quit: Textual IRC Client: www.textualapp.com]
Getorix has joined #glasgow
_whitelogger has joined #glasgow
x56 has quit [Remote host closed the connection]
x56 has joined #glasgow
x56 has quit [Remote host closed the connection]
x56 has joined #glasgow
rappet has quit [Remote host closed the connection]
rappet has joined #glasgow
thaytan has quit [Ping timeout: 256 seconds]
thaytan has joined #glasgow
bvernoux has joined #glasgow
<marcan> whitequark: glad to see I'm not the only one who thinks that terminology works much better
<whitequark> it is really unambiguous for i2c
<whitequark> regardless of any other opinions one might have, even
<marcan> yes
<whitequark> for spi i still don't know what to do with mosi/miso
<marcan> USD/DSD
<whitequark> i prototyped in a branch and using di/do was really fucking confusing
<whitequark> hrm
<whitequark> not an awful choice but literally no one else uses this
<marcan> it's SPI
<marcan> everyone and their mom reinvents it with different terms
<whitequark> well
<whitequark> i ... don't have a counterargument
<whitequark> we can do that, sure.
<whitequark> should be in nmigen-stdio too i guess.
<marcan> you can also consider DDS/DUS or DD/DU
<whitequark> i like DD/DU
<whitequark> it's like DI/DO but unambiguous
<marcan> I find USD/DSD more readable, but prefixing with D is more conventional, and if you're doing that might as well go with the 2-char version
<marcan> so sure
<marcan> works well as a parallel to DI/DO
<tnt> what does USD or DSD supposed to stand for ?
<marcan> upstream/downstream data
<tnt> and upstream is miso ?
<marcan> yes
<marcan> downstream is host->device (parallel to clock/chipsel)
Getorix_ has joined #glasgow
<marcan> and upstream is the other way around
janhenrik has quit [Quit: No Ping reply in 180 seconds.]
anuejn has quit [Quit: No Ping reply in 180 seconds.]
Getorix has quit [Read error: Connection reset by peer]
anuejn has joined #glasgow
janhenrik has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 240 seconds]
Stormwind_mobile has joined #glasgow
<whitequark> PSA: https://yowasp.github.io/
<whitequark> just built a glasgow applet with 100% wasm tools for the first time
<gruetzkopf> neat
<tnt> Has anyone looked into a webassembly softcore ?
<tnt> nevermind, just took a glance at the specs ...
<awygle> excellent work as always whitequark!
<Lofty> tnt: if people can parse x86 in hardware, they can manage wasm /s
<tnt> Lofty: well I saw "stack based" so I figured, maybe it's "simple / small" ... but requiring float/int 32/64 is a bad start :p
<d1b2> <TiltMeSenpai> not quite glasgow related but is there a reason why nmigen uses the older generator style async syntax instead of the newer async/await style syntax?
<Lofty> TiltMeSenpai: nmigen's minimum Python version is 3.6
<d1b2> <TiltMeSenpai> ok cool
<Lofty> async/await is 3.7, right?
<d1b2> <TiltMeSenpai> wait, I think 3.4 has yield from, 3.5 introduced async/await, and about 3.7-ish, async/await became preferred
<d1b2> <TiltMeSenpai> I don't remember exactly the order
<d1b2> <TiltMeSenpai> https://www.python.org/dev/peps/pep-0492/ yeah, if we target 3.5, we could migrate to the async/await syntax. I think it's a big migration though
<d1b2> <TiltMeSenpai> 3.5+*
<electronic_eel> IIRC minimum python for glasgow currently is 3.6. it was once raised to 3.7, but I think that was a misunderstanding about argparse features and was then lowered to 3.6 again
<tnt> And it's 3.7 again now :p
<d1b2> <TiltMeSenpai> there's nothing functionally wrong with await from syntax, although I personally find it harder to read. I'd be willing to help with the migration to async/await but because it's a fairly major change without any serious functional improvement, I don't want to force this change on anyone
<d1b2> <TiltMeSenpai> but 3.6 has async/await, so we could use it if we wanted
<electronic_eel> tnt: ok, then I misremembered. thanks for correcting me
<awygle> glasgow is 3.7 and nmigen is 3.6 iirc. i just talked to wq about this the other day
<sorear> wasm is really remarkably hostile to hardware implementation, more so than even java
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #glasgow
bvernoux has quit [Quit: Leaving]